システムの品質が低いと感じたとき、古参のベンダーへの伝え方
先代の社長が亡くなって半年。あなたは会社の基幹システムを毎日触るようになって、ようやく違和感の正体に気づいた。受発注の画面は同じ商品を三回検索しないと登録できない。在庫数はエクセルと突き合わせるたびに数字がずれている。得意先から電話がかかってきて、担当者が「少々お待ちください」と言ったまま二分も待たされる。パソコンの前で、担当者が同じ画面を何度もクリックしているのが見える。月末の締め処理になると、事務所の照明が消えるのはいつも一番遅い日で、経理担当のベテラン社員が「今月も数字が合わない」とつぶやきながら、システムの出力とエクセルの手集計を何度も見比べている。
先代の時代からこのシステムを作り続けてきたベンダーは、創業社長と付き合いが長く、月次の請求書だけがきちんと届く。担当者は「昔からこうなっています」と言う。あなたは「これは直せないのか」と聞きたいが、聞き方を間違えれば「新しい社長は何もわかっていないのに口を出す」と現場からも先代の代からの付き合いのベンダーからも思われかねない。かといって黙っていれば、非効率なシステムのまま会社は回り続け、若手社員は「この会社のシステムは古い」と言って辞めていく。実際、後継社長として現場を回り始めてから、若手の中途社員が面談で「前の会社ではもっと楽に処理できていた」と漏らしたことも一度ではないはずだ。
さらに厄介なのは、先代がこのベンダーを高く評価していたという記憶が、社内のあちこちに残っていることだ。年始の挨拶回りでは毎年ベンダーの担当者が真っ先に顔を出し、先代の遺影に手を合わせてくれた。総務の古参社員は「先代がいつも褒めていた会社だから」という理由で、システムへの疑問を口にすることすら遠慮している。あなた自身も、先代の位牌の前で「会社を守ります」と誓ったばかりの身で、その先代が選び、信頼していた相手に対して「品質が低い」という言葉を投げかけることに、後ろめたさに近い感情を覚えている。
それでも、日々の業務は待ってくれない。取引先からのクレームは増え、若手の離職も止まらない。事業承継後の後継社長が最初にぶつかる壁のひとつが、まさにこの「システムの品質への疑問をどう言葉にして、誰にどう伝えるか」という問題だ。先代が長年築いた人間関係、ベンダーとの契約の経緯、社内の使い慣れた運用――そのすべてを尊重しながら、経営者として必要な改善を求めなければならない。この記事では、なぜこの問題が起きやすいのか、実際にどう進めればよいのか、失敗しやすいパターンとその回避策を、事業承継特有の力学に即して具体的に整理する。
なぜ「品質が低い」と感じても言い出しにくいのか
承継直後の後継社長が置かれている立場
事業承継直後の後継社長は、いくつもの制約に同時に縛られている。まず、先代との比較を常に意識せざるを得ない立場だ。先代が選び、先代が育てた取引関係にメスを入れることは、社内的には「先代の判断を否定する」という意味を持ちやすい。古参の社員や取引先は、後継社長の一つひとつの発言を「この人は先代とどう違うのか」というフィルターを通して見ている。システムベンダーへの物言いも、その例外ではない。
次に、技術的な知識の非対称性がある。先代の時代からシステムを担当してきたベンダーは、業務知識もシステムの内部構造も深く理解している。一方、後継社長の多くは、経理や営業といった事業側の出身であり、システムの中身を細かく検証する時間もスキルもない。「品質が低い気がする」という直感はあっても、それを「具体的にどこが、どういう基準で、どの程度低いのか」という言葉に翻訳する手段を持っていないことが多い。この翻訳ができないまま相手に伝えると、ベンダー側には「感覚的な不満」としか受け取られず、まともな改善提案として扱われない。
さらに、契約関係の構造的な問題もある。長年同じベンダーに発注し続けてきた会社では、多くの場合、要件定義書や仕様書といった一次資料が整理されておらず、口頭の合意や過去のメールのやり取りだけで運用が続いている。何を発注し、何を検収し、何が「仕様」で何が「バグ」なのかの境界が曖昧なまま、システムは増改築を重ねてきた。この状態で「品質が低い」と指摘しても、ベンダー側は「それは最初からの仕様です」「その時はそうお願いされました」と応じることができてしまう。契約と仕様の記録が薄いことが、後継社長の交渉力を弱めている。
「品質が低い」という言葉の解像度が低いことの弊害
後継社長が抱く「品質が低い」という感覚は、実際には複数の異なる問題が混ざっていることが多い。整理すると、おおよそ次の四つに分解できる。
一つ目は、機能的な不備だ。本来できるはずの操作ができない、必要なはずの機能が存在しない、という状態。二つ目は、性能・信頼性の不備だ。動作が遅い、頻繁に落ちる、データが時々おかしくなる、という状態。三つ目は、使いやすさ(ユーザビリティ)の不備だ。動くけれども、操作が煩雑で人的ミスを誘発しやすい、という状態。四つ目は、保守性・拡張性の不備だ。ちょっとした変更を頼んでも高額な見積もりが出る、変更のたびに他の箇所が壊れる、という状態。
この四つを区別せずに「品質が低い」とひとまとめに伝えてしまうと、ベンダー側は最も対応しやすい一つ目の「機能的な不備」だけに反応して、「その機能はご要望があれば追加開発として対応します」という回答を返してくる。後継社長が本当に問題にしたかった「使いにくさ」や「変更コストの高さ」は素通りされてしまう。この解像度の低さが、後継社長とベンダーの間で会話が成立しない最大の原因になっている。
古参ベンダー側の事情も理解しておく
伝え方を考える前に、相手側の事情も理解しておく必要がある。古参のベンダーが品質改善に及び腰になるとき、そこには単なる怠慢だけでなく、いくつかの構造的な事情が絡んでいることが多い。
第一に、技術的負債の存在だ。長年の改修を重ねたシステムは、最初の設計思想から逸脱した増改築の跡が積み重なっている。ある機能を直そうとすると、思いがけないところで別の機能が壊れる。ベンダーの担当者自身も、システムの全体像を正確に把握できていない可能性がある。品質改善を渋る背景に、「下手に触ると収拾がつかなくなる」という技術的な恐怖があることは珍しくない。
第二に、価格構造の問題だ。先代の時代に結ばれた保守契約は、多くの場合、月額固定の低い金額で「軽微な修正」だけをカバーする内容になっている。品質改善のための本格的な見直しは、この保守契約の範囲を超える。ベンダーとしては、既存の契約単価のままで大きな改善作業をすることは経営的に成立しない。だからこそ「予算がつけば対応できる」という反応になりがちだが、それを後継社長にうまく説明できていないケースが多い。
第三に、担当者の異動や高齢化だ。先代の時代にシステムを設計した技術者が既に退職していたり、ベンダー社内でも別部署に異動していたりして、現在の担当者はシステムの経緯を正確に知らない。「昔からこうなっています」という回答は、多くの場合、本当に「わからない」からそう言っているだけであり、悪意で逃げているわけではない。
第四に、関係性への配慮だ。先代社長との長年の付き合いの中で、ベンダー側も「言われたことだけをきちんとやる」という受け身の姿勢を身につけてしまっていることがある。先代が細かい品質要求をしてこなかった場合、ベンダーにとって「品質を積極的に提案する」という習慣そのものが育っていない可能性がある。
これらの事情を理解した上で伝え方を組み立てることが、感情的な対立を避け、実務的な改善を引き出すための出発点になる。こうした伝え方の姿勢は、承継社長が良い発注者になるための7つの習慣で紹介している習慣とも重なる部分が多い。逆に言えば、後継社長がこうした事情を知らずに「なぜ改善してくれないのか」とだけ問い詰めてしまうと、ベンダー側は「先代の代からの取引先なのに、この程度の事情説明もわかってもらえないのか」という不満を密かに抱えることになる。表面上は「検討します」と答えながら、実際の対応が後回しにされ続けるという、静かな停滞が起きやすいのはこのためだ。伝え方の技術以前に、まず相手の置かれている立場を想像する姿勢そのものが、後継社長に求められる最初の一歩だと言える。
先代の存在が交渉のテーブルに常に同席している
もう一つ、事業承継という状況に特有の力学として無視できないのが、交渉の場に先代の存在が「不在の同席者」として常につきまとうという点だ。後継社長がベンダーの担当者と向き合うとき、担当者の脳裏には必ず先代とのやり取りの記憶がある。先代が生前どう振る舞い、どう発言し、どこまでを許容していたか。後継社長がそれと異なる態度を示した瞬間、担当者は無意識のうちに「先代とは違う」という評価を下し、それが良い意味であれ悪い意味であれ、その後の関係性の基調を決めてしまう。後継社長自身も、先代の代からの付き合いを大切にしたいという気持ちと、経営者として必要な改善を求めたいという気持ちの両方を抱えながら発言せざるを得ず、言葉選びに慎重にならざるを得ない。この「不在の同席者」を意識しているかどうかが、実は伝え方の巧拙を大きく左右している。
ケーススタディで見る、よくある三つの局面
ケース1:受発注システムの「重複入力」問題
ある製造業の後継社長は、承継後三か月目に、営業事務のパート社員が受注データを二つの画面に別々に手入力していることに気づいた。基幹システムと出荷管理システムが連携していないため、同じ受注情報を二度打ちしなければならない。この作業には一件あたり五分ほどかかり、一日に六十件ある受注では実に五時間分の人件費が重複入力だけに費やされていた。
後継社長がベンダーに「この二重入力を何とかしてほしい」と伝えたところ、担当者は「連携機能を新規に作る必要があるので、追加開発として見積もりを出します」と回答した。見積もりは三百万円。後継社長は高すぎると感じ、いったん保留にした。
数か月後、改めて経理データと突き合わせて、二重入力の作業時間をパート社員の時給で計算し直してみると、年間で約百二十万円分の人件費に相当することがわかった。三百万円の投資は、二年半で回収できる計算になる。この数字を持って再度ベンダーと交渉したところ、当初の見積もりには含まれていなかった「テストデータの移行作業」を除外することで、実際の作業範囲を絞り、見積もりを二百十万円まで下げることができた。
このケースの教訓は、感覚的な「不便だ」という訴えだけでは投資判断も交渉も進まないという点だ。作業時間や人件費という数字に変換して初めて、投資対効果の議論ができる土台が整い、ベンダーとの見積もり交渉においても、どの作業が本当に必要でどれが過剰かを切り分けられるようになった。
さらに、この後継社長が意識的に行ったのは、交渉の場に必ず現場のパート社員本人の言葉を持ち込むことだった。後継社長が一人で「困っている」と伝えるよりも、「実際にこの作業をしている社員が、こう言っている」という具体的な証言を添えることで、ベンダー側の担当者も「経営者の思い込みではなく、現場の実態だ」と認識を切り替えやすくなった。加えて、二重入力の作業がミスの発生源にもなっており、過去半年間で三件、転記ミスによる出荷先の誤りが発生していたことも合わせて伝えた。単なる作業効率の問題ではなく、顧客対応リスクでもあるという二つの側面から説明したことで、ベンダー側の営業責任者も「これは早めに手を打つべき案件だ」と社内的に位置づけやすくなったという。
この事例が示すのは、数字による説明と、現場の声による説明を組み合わせることの効果だ。数字だけでは「経営者の理屈」として受け取られがちだが、現場の生の声が加わることで、ベンダー側にとっても「これは早く対応しないと自社の評判にも関わる」という危機感に変わりやすい。
ケース2:在庫データの不整合と「誰の責任か」問題
小売業を営む後継社長のケースでは、店舗の在庫数とシステム上の在庫数が定期的にずれることが長年の悩みだった。先代の時代から「まあ、そんなもんだ」と諸事情で片付けられてきたが、後継社長は棚卸のたびに発生する数時間の突き合わせ作業に疑問を持った。
ベンダーに問い合わせると「入力タイミングの問題ではないか」という回答が返ってきた。しかし、具体的にどのタイミングでずれが発生しているのか、ベンダー側も明確に把握していなかった。後継社長は現場のパート社員に頼み、二週間だけ「在庫を動かす操作をしたら、その都度、時刻と操作内容をメモする」という記録を取ってもらった。
その結果、複数の店舗スタッフが同時に同じ商品の在庫を更新した際、後から保存した操作が先の操作を上書きしてしまう、という排他制御の欠陥が浮かび上がった。これは「入力ミス」ではなく、システムの設計上の欠陥だった。この記録を持ってベンダーに再度説明したところ、担当者は初めて「そういう報告は今まで受けたことがなかった」と認め、修正に応じた。
このケースが示すのは、現象を自分の言葉で説明する前に、まず「いつ、どういう操作をしたときに、何が起きるか」という再現条件を記録しておくことの重要性だ。ベンダー側も原因を特定できていない場合、後継社長側が観察記録という一次情報を提供することで、初めて技術的な議論が前に進む。感情的に「システムが悪い」と主張するのではなく、事実を淡々と積み上げる姿勢が、結果的にベンダーの協力を引き出した。
この後継社長は、記録を取っている期間中、あえてベンダーには何も伝えなかったという点も興味深い。事前に「調査しています」と伝えてしまうと、担当者が身構えて、いつもとは違う説明をしてくる可能性を懸念したためだ。記録が十分に集まった段階で、初めて資料としてまとめ、ベンダーに提示した。この二週間の記録の中には、排他制御の欠陥以外にも、閉店直前の時間帯に店舗のネットワーク回線が混雑し、システムの応答が極端に遅くなるという別の問題も見つかった。これは当初の疑問とは別の論点だったが、記録という形で残していたおかげで、後から「実はこれも問題だった」と気づくことができた。感覚だけで訴えていた場合には、この二次的な発見は埋もれてしまっていた可能性が高い。
もう一つ付け加えておきたいのは、この排他制御の欠陥が実は先代の時代から発生していた可能性が高いという事実だ。棚卸のたびに数時間かけて手作業で在庫を合わせるという「儀式」が、実は毎回のシステムの欠陥の埋め合わせだったと分かったとき、後継社長は複雑な感情を抱いたという。先代の時代にはこの欠陥は放置され、結果として現場の負担でカバーされ続けてきた。この発見は、後継社長にとって「先代の判断が誤っていた」という単純な結論ではなく、「先代の時代には、これを追及するだけの情報も時間もなかったのだろう」という理解に落ち着いた。この視点の持ち方が、ベンダーへの伝え方にも、批判ではなく前向きな改善提案としての語調を選ばせる助けになった。
ケース3:「先代の頃からの担当者」との関係性の壁
建設関連業の後継社長は、先代の時代から二十年以上システムを担当してきた個人事業主の技術者に頭を悩ませていた。この技術者は、先代とは飲み仲間でもあり、システムの仕様はすべて技術者の頭の中にあり、ドキュメントは一切残されていなかった。後継社長がシステムの改善を求めても、「今それをやると他が動かなくなる」という説明が繰り返され、具体的な計画も見積もりも出てこなかった。
後継社長は、まず技術者本人を否定するのではなく、「これから会社を長く引き継いでいくために、システムの状態を一度きちんと整理させてほしい」という趣旨の依頼を、感謝の言葉とともに伝えた。技術者個人の能力や過去の仕事を非難する言い方は一切せず、「今後も長くお付き合いをお願いしたいからこそ、今のシステムの状態を書面で共有してほしい」という前向きな依頼として位置づけた。
その上で、外部の第三者(別の中小のシステム会社)に依頼し、現行システムの技術的な状態を評価してもらう「セカンドオピニオン」を取った。これは技術者を切るための材料ではなく、「客観的に今の状態を把握したい」という後継社長自身の説明責任のためだと明確に伝えた。結果として、セカンドオピニオンの報告書には、想定通りドキュメント不足やブラックボックス化のリスクが指摘されたが、それを技術者本人にも共有し、今後のドキュメント化を一緒に進める合意を取ることができた。
このケースの教訓は、長年の関係性がある相手には、まず「今後も続けたい」という意思を先に示すことが交渉の土台になるという点だ。品質への疑問を伝えることと、相手との関係を断つことは同じではない。後継社長が最初にすべきなのは、関係を維持しながら透明性を高めるための仕組みを作ることであり、それには外部の視点を借りることが有効な場合がある。
この後継社長がもう一つ工夫したのは、セカンドオピニオンの依頼先を選ぶ段階で、既存の技術者と直接の競合関係にならない事業者を意識的に選んだことだった。同じ地域で同業のシステム開発を手がける会社に依頼すれば、既存の技術者は「仕事を奪われるのではないか」という疑念を強く持ってしまう。そこで、業界も業務範囲もやや離れた、あくまで技術的な健全性の評価だけを行う専門家に絞って依頼した。この配慮によって、技術者本人にセカンドオピニオンの実施を伝えた際も、比較的落ち着いた反応を得ることができたという。
半年後、この会社では技術者と後継社長が共同で、システムの主要な機能について簡単な仕様書を作成するプロジェクトを始めている。全てを一度にドキュメント化するのではなく、まずは最も業務影響の大きい受発注機能から手をつけ、月に一回、一時間程度の打ち合わせを重ねる形で進めているという。技術者の高齢化を踏まえれば、この作業はいずれ避けられないものだったが、後継社長が「否定」ではなく「継承」の文脈でこの作業を依頼したことが、二十年来の関係を壊さずに前進させる鍵になった。
なぜこの問題が起きるのか、構造から理解する
ここまでのケースに共通する構造を、もう少し丁寧に分解しておきたい。事業承継後にシステム品質の問題が表面化しやすいのには、承継という出来事そのものに起因する、いくつかの構造的な要因がある。
要因1:評価基準の世代交代
先代の経営者が現役だった時代、システムに対する評価基準は「動けばよい」「先代が納得していればよい」というものだったケースが多い。特に、先代自身がシステムに詳しくない場合、ベンダーからの説明を鵜呑みにし、細かい品質検証をしてこなかったことがある。後継社長は、多くの場合、先代よりも若く、デジタルツールに日常的に触れてきた世代であるため、評価基準が自然と厳しくなる。この評価基準のギャップそのものが、「品質が低い」という感覚の発生源になっている。これは必ずしもシステムが劣化したという意味ではなく、評価する側の目が変わったことによる相対的な変化であることも多い。この点を後継社長自身が理解しておくことは重要だ。すべてを「先代の失敗」や「ベンダーの怠慢」と捉えるのではなく、「時代とともに求められる基準が変わった」という前提を持つことで、伝え方のトーンも変わってくる。
要因2:情報の非対称性の固定化
長期間同じベンダーに発注してきた会社では、ベンダー側に業務知識とシステム知識の両方が蓄積される一方、発注側の社内には知識が残らない、という非対称性が固定化しやすい。先代の時代の担当者が引退・退職していたり、システム部門自体が存在しない中小企業では、この非対称性が特に大きい。後継社長が「これは変えられるはずだ」と思っても、それを技術的に裏付ける根拠を社内に持たないため、ベンダーの回答をそのまま受け入れるしかない状況に陥りやすい。この非対称性を放置したまま交渉に入ると、後継社長側が常に不利な立場からの発言しかできなくなる。
要因3:契約と検収の記録が薄いことによる「仕様」の曖昧化
多くの中小企業では、システム開発やその後の改修について、正式な要件定義書や検収書が整備されていない。口頭でのやり取りやメールでの簡単な依頼だけで改修が進み、その結果を正式に検収するプロセスも省略されがちだ。この状態が長く続くと、「これは仕様として合意されたものなのか、単なる作りっぱなしの未完成部分なのか」という境界が曖昧になる。後継社長が品質の低さを指摘したとき、ベンダーが「それは元々そういう仕様でした」と回答できてしまう背景には、この記録の薄さがある。逆に言えば、この記録を整備すること自体が、後継社長にとっての交渉力の源泉になる。
要因4:保守契約の範囲と実際のニーズのズレ
先代の時代に結ばれた保守契約は、多くの場合「軽微な不具合対応」や「電話サポート」といった限定的な範囲で価格設定されている。事業環境が変化し、システムに求められる機能や性能の水準が上がっているにもかかわらず、契約の範囲と価格は当時のまま固定されている。後継社長が品質改善を求めても、それが保守契約の範囲を超える「追加開発」に分類されてしまい、別途の予算措置が必要になる。この構造を理解していないと、後継社長は「保守料を払っているのに、なぜ改善してくれないのか」という誤解を抱きやすく、ベンダー側は「それは契約範囲外です」という説明に終始し、双方の話がすれ違う。
要因5:心理的な負い目と忠誠心の混在
後継社長自身の内面にも、この問題を難しくする要因がある。先代が選んだベンダーを変えることや、そのベンダーに苦言を伝えることが、先代の判断や人間関係への「否定」につながるのではないかという負い目を抱きやすい。特に、先代が創業者であり、そのベンダーとの関係が個人的な友情や恩義に基づいている場合、後継社長は「経営判断」と「人間関係への配慮」の間で引き裂かれる。この心理的な負担が、品質への疑問を言葉にすることを遅らせ、結果として問題が長期化する一因になっている。経営者としては、品質改善の要求と、先代への敬意や人間関係の維持は、両立可能なものとして切り分けて考える必要がある。
要因6:古参社員側の「慣れ」による抵抗
システムの使いにくさを最も強く感じているはずの現場の古参社員が、実際には改善に消極的なことがある。長年同じ操作方法に慣れてしまっており、「今のままでいい」「変えるとかえって覚えるのが大変」という声が上がることは珍しくない。後継社長がベンダーに改善を依頼しても、現場から「余計なことをしないでほしい」という反発が出ると、改善プロジェクトそのものが停滞する。この種の抵抗にどう向き合うかは、古参社員の「今のままでいい」が招く停滞と、向き合い方の最低ラインで詳しく扱っている。この現場の抵抗は、システムの品質問題を伝える際に、ベンダーだけでなく社内にも目を向ける必要があることを示している。
これらの要因が複合的に絡み合うことで、後継社長が「品質が低い」と感じてから、実際に改善が動き出すまでに長い時間がかかる。
要因7:承継のタイミングと業務の繁忙期が重なることによる後回し
もう一つ見落とされがちな要因として、事業承継そのものが会社の年間サイクルの中で最も慌ただしい時期に発生しやすいという点がある。相続や株式の移転、取引先への挨拶回り、金融機関との関係の再構築など、承継直後の後継社長は経営の根幹に関わる作業に忙殺される。システムの品質という、緊急性は低いが重要度の高い課題は、この時期にはどうしても後回しにされやすい。結果として、品質への疑問を感じてから実際に行動に移すまでに半年、一年という時間が空いてしまうことが多く、その間に問題は放置され、現場の不満は静かに蓄積していく。この時間差そのものが、後になって「なぜもっと早く言わなかったのか」という社内の不満を招く一因にもなる。後継社長としては、承継直後の忙しさの中でも、システムに関する事実の記録だけは早期に始めておくことが、後の交渉を有利にする布石になる。
要因8:属人化した業務知識とシステムの一体化
長年の運用の中で、システムの使い方そのものが、特定の古参社員の個人的な工夫やノウハウと一体化してしまっていることも、問題の構造を複雑にしている。たとえば、あるベテラン社員だけが知っている「この画面ではこの順番で入力しないとエラーになる」という回避策が、マニュアル化されずに個人の頭の中だけに存在している。このような属人化した回避策は、システムそのものの欠陥を見えなくしてしまう効果を持つ。後継社長が「品質が低い」と感じても、その社員が長年の経験でうまく回避しているため、表面上は大きな問題として顕在化しない。しかし、その社員が異動や退職をした瞬間に、隠れていた品質問題が一気に噴出する。この構造を理解しておくことで、後継社長は「今は大きな問題が起きていないから大丈夫」という判断を過信せず、属人化している部分を早めに洗い出しておく必要性に気づくことができる。
次の章では、これらの構造を踏まえた上で、実際にどう進めればよいかを、具体的なステップとチェックリストの形で整理する。
実務対応のステップとチェックリスト
品質への疑問を、感情的な対立ではなく、実務的な改善プロセスに落とし込むための手順を、七つのステップに分けて説明する。それぞれのステップには、確認すべき項目をチェックリストとして添えた。
ステップ1:事実を記録する(感覚を事実に翻訳する)
最初にやるべきことは、「品質が低い」という感覚を、具体的な事実の記録に翻訳する作業だ。これをしないまま相手に伝えると、水掛け論になりやすい。記録すべき事実には、次のようなものがある。
- どの業務・どの画面で問題が起きているか(部署名・業務名・画面名を具体的に特定する)
- 問題が起きる頻度(毎日、週に何回、月に何回か)
- 問題が起きたときの具体的な症状(エラーメッセージ、データのずれ方、動作の遅さの度合いなど)
- その問題によって発生している追加の作業時間や、手戻りのコスト
- 問題に気づいている社員の数と、その社員たちの受け止め方(諦めているか、日常的に苦情を言っているか)
これらの記録は、可能であれば一週間から二週間程度、実際に現場の担当者に協力してもらいながら取ると精度が上がる。後継社長自身がすべての現場作業を見ることは難しいため、現場のキーパーソンに協力を依頼し、簡単なメモやチェックシートで記録してもらう方法が現実的だ。この段階でのポイントは、原因を決めつけず、あくまで「何が起きているか」という現象の記述に留めることだ。原因の分析は次のステップで行う。
記録の取り方としては、専用のツールを新たに導入する必要はない。スマートフォンのメモ機能や、既存のエクセルシートに簡単な入力フォームを作るだけで十分だ。むしろ、複雑な仕組みを新たに導入すること自体が現場の負担になり、協力を得にくくなる。記録の項目は「日時」「担当者」「発生した業務」「症状の簡単な説明」の四つ程度に絞り、五秒から十秒で入力できる粒度にすることが、継続的な記録を得るための現実的な工夫になる。
またこの段階で、後継社長自身がベンダーに対して何も伝えていないことが、むしろ有効に働く場合がある。事前に問題意識を伝えてしまうと、ベンダー側が身構えて説明の準備をしてしまい、ありのままの現象が観察しにくくなることがあるためだ。まずは静かに事実を積み上げ、十分な根拠が揃った段階で初めて対話に入る、という順序を意識するとよい。
ステップ2:問題を分類する(四種類のどれに当たるか)
先述した「機能的な不備」「性能・信頼性の不備」「使いやすさの不備」「保守性・拡張性の不備」の四分類に、記録した事実を当てはめていく。一つの問題が複数の分類にまたがることもあるが、それでも構わない。分類することの目的は、ベンダーに伝える際に「これは機能追加の話なのか、それとも既存機能の欠陥の話なのか」を明確にすることにある。
チェックリストとしては、次の観点で自問するとよい。
- この問題は、そもそも要求した機能が実装されていないのか、それとも実装されているが不具合があるのか
- この問題は、特定の条件でだけ起きるのか、常に起きるのか
- この問題は、操作方法を変えれば回避できるのか、それとも回避策がないのか
- この問題は、他の機能や他のシステムとの連携に起因するのか、単体の機能の中で起きているのか
この分類作業を通じて、「不具合の修正として無償対応を求められるもの」と「追加開発として予算が必要なもの」の区別も、おおよそ見えてくる。この区別を自分の中で持っておくことは、後の交渉で非常に重要になる。
ステップ3:金額に翻訳する(投資対効果の言語で話す)
記録した事実を、可能な限り金額に翻訳する。人件費、機会損失、顧客対応の遅延によるクレームリスクなど、定量化できるものはすべて数字にする。この作業は手間がかかるが、ベンダーとの交渉においても、社内の他の経営陣や後継者自身の判断材料としても、非常に強力な武器になる。
具体的には、次のような計算を行う。
- 重複作業や手戻り作業にかかっている時間 × 該当する社員の時給(または人件費レート) × 発生頻度 = 年間コスト
- システムの不具合によって発生した過去のクレーム件数や、それに対応した時間
- システムが原因で発生した誤出荷・誤発注などのミスと、その修正にかかったコスト
- もし改善した場合に削減できる作業時間を、金額に換算した見込み効果
この金額の翻訳ができていると、ベンダーからの見積もりが高いか安いかを判断する基準ができる。また、感覚的な「品質が低い」という表現ではなく、「この問題によって年間これだけのコストが発生している」という表現で伝えることができ、ベンダー側も経営課題として受け止めやすくなる。
ステップ4:伝える相手と場を設計する
事実と金額の整理ができたら、次に「誰に、どういう場で伝えるか」を設計する。古参のベンダーの場合、日常的にやり取りしている担当者と、その担当者の上司(営業責任者や経営者)とでは、受け止め方も権限も異なる。
- 日常業務の担当者だけに伝えると、担当者個人の裁量を超える判断ができず、話が進まないことが多い。
- 品質改善のような経営判断を伴う話は、ベンダー側の意思決定者(営業責任者・役員・代表者)を交えた場を設定するべきだ。
- 場を設定する際には、「クレーム」としてではなく、「今後の付き合いを前提とした改善の相談」という位置づけを明確に伝える。
- 可能であれば、事前に記録した事実と金額の資料を共有しておき、当日は感情的なやり取りにならないようにする。
このステップで重要なのは、「不満をぶつける場」ではなく「今後どうするかを一緒に決める場」として設計することだ。この違いは、場の空気だけでなく、その後の関係性そのものに影響する。
ステップ5:改善の優先順位と選択肢を一緒に作る
場を設定したら、いきなり「全部直してほしい」と要求するのではなく、記録した問題を優先順位付けし、対応の選択肢を一緒に検討する姿勢を取る。優先順位の付け方としては、次のような基準が実務的だ。
- 影響範囲の大きさ(関わる社員数、関わる業務の重要度)
- 発生頻度の高さ
- 金額換算したコストの大きさ
- 対応の技術的な難易度(ベンダー側の見立ても踏まえる)
- リスクの重大さ(データ消失や誤出荷など、事業継続に直結するリスク)
これらを踏まえて、「まずこの三つから着手したい」という形で絞り込んで提示すると、ベンダー側も現実的な計画を立てやすくなる。すべてを一度に要求すると、見積もりも膨らみ、ベンダー側の対応能力を超えてしまい、結局何も進まないという事態を招きやすい。
ステップ6:合意事項を文書に残す
口頭でのやり取りだけで終わらせず、合意した改善内容、対応の範囲、スケジュール、費用について、簡単でも文書に残すことを徹底する。長年の付き合いのあるベンダーほど、口頭のやり取りだけで済ませがちだが、これが将来的な「仕様の曖昧化」を再び生む原因になる。
文書化すべき最低限の項目は次の通りだ。
- 対応する問題の具体的な内容(どの画面・どの業務のどういう不具合か)
- 対応の範囲(どこまでを直すのか、直さない部分はどこか)
- スケジュール(いつまでに、どの段階で完了するか)
- 費用(既存の保守契約範囲内か、追加費用が発生するか、その金額)
- 検収の方法(誰が、どう確認して完了とするか)
この文書は、契約書のような堅い形式でなくても構わない。メールやメモの形式でも、双方が確認した記録として残ることが重要だ。この積み重ねが、将来同じような問題が起きた際の交渉の土台になり、次の契約更新の場面でも役立つ。契約更新の前に何を確認し、何を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにまとめている。
ステップ7:改善後の効果を検証し、フィードバックする
改善が実施された後、それで終わりにせず、実際に効果が出たかどうかを検証するステップを組み込むことも重要だ。ステップ1で記録した事実や、ステップ3で計算した金額と同じ基準を使って、改善後の状況を再度測定する。作業時間が実際に短縮されたか、不具合の発生頻度が実際に減ったかを確認し、その結果をベンダーにも共有する。
この検証とフィードバックのステップには、二つの意味がある。一つは、投資した費用に対して実際に効果が出ているかを確認し、今後の追加投資の判断材料にすることだ。もう一つは、ベンダーに対して「改善してもらったことで、こういう効果が出た」という感謝と評価を伝えることで、今後も良好な関係を維持し、次の改善にも協力的に取り組んでもらう土台を作ることだ。効果検証を怠ると、ベンダー側は自分たちの対応がどう評価されたのかを知る機会がなく、次の改善提案に対する意欲も上がりにくい。逆に、小さな改善でも効果を数字で示して感謝を伝えることは、今後の関係構築において非常に効果的な投資になる。
このステップを踏むことで、品質改善の取り組みは一度きりの対応で終わらず、継続的な改善サイクルとして社内にも定着していく。後継社長が、単発の交渉術としてこれらのステップを使うのではなく、経営の仕組みの一部として根付かせることができれば、次に同じような品質の問題が発生したときにも、社内とベンダーの双方が同じ手順で対応できるようになる。
よくある失敗パターン
失敗パターン1:感情的な言葉で一方的に不満をぶつける
後継社長が最も陥りやすい失敗は、記録や整理をせずに、感情的な言葉でベンダーに不満をぶつけてしまうことだ。「このシステムは使いにくすぎる」「今の時代にこんな古いままでいいと思っているのか」といった言い方は、たとえ内容が正しくても、相手を防御的にさせてしまう。特に、長年先代と付き合いのあった担当者にとって、後継社長からの直接的な批判は、これまでの自分たちの仕事全体を否定されたように受け取られやすい。防御的になった相手は、具体的な改善提案よりも、自己弁護のための説明に終始するようになり、結果として建設的な議論にならない。感情的な発言を避けるためには、事前にステップ1からステップ3までの準備を必ず済ませておくことが有効だ。事実と数字を先に用意しておけば、その場で感情に流されずに話を進めやすくなる。
失敗パターン2:いきなり全面的なシステムの入れ替えや他社への切り替えを口にする
品質への不満が高まると、後継社長は「もう全部作り直したほうがいいのではないか」「別のベンダーに切り替えたほうがいいのではないか」という結論に飛びつきやすい。しかし、長年運用されてきた基幹システムには、表には見えていない業務ロジックや、過去の特殊対応が積み重なっていることが多く、全面的な入れ替えは想定を超える費用と時間、そして業務停止のリスクを伴う。また、いきなり「切り替える」という前提で交渉を始めると、既存のベンダーは態度を硬化させ、それまで協力的だった関係が壊れ、必要な情報開示(仕様の詳細や過去の経緯)すら得られなくなることがある。品質の問題を伝える初期段階では、「今の関係を前提に、まず改善できることから進めたい」という姿勢を基本とし、全面的な切り替えは、あくまで最終手段として、十分な情報収集と比較検討を経た上で検討するべき選択肢として位置づける必要がある。
失敗パターン3:社内の合意形成を後回しにして、ベンダーとの交渉だけを進める
品質改善の話をベンダーとだけ進め、社内の古参社員や現場の合意形成を後回しにしてしまう失敗も多い。現場の社員は、長年慣れた操作方法に愛着や慣れを持っており、後継社長が主導する改善が、自分たちの仕事のやり方を否定するものとして受け止められることがある。ベンダーとの交渉が進み、いざ改修が実施される段階になって、現場から「聞いていなかった」「使い方が変わるのは困る」という反発が出ると、それまでの交渉が水泡に帰すことになる。品質改善のプロセスは、ベンダーとの二者間の話ではなく、現場を含めた三者の合意形成として設計する必要がある。ステップ1の事実記録の段階から現場を巻き込み、改善の必要性を現場自身にも実感してもらうプロセスを組み込むことで、この失敗を避けやすくなる。
失敗パターン4:一度の交渉で全ての問題を解決しようとする
最後によく見られる失敗が、一度の交渉の場で、これまで蓄積してきた不満のすべてを一気にぶつけてしまうことだ。長年溜め込んできた不満があると、ようやく機会が来たときに「実はこれも困っている、あれも困っている」と次々に問題を並べたくなる気持ちは理解できる。しかし、ベンダー側の立場からすると、一度に多くの問題を提示されると、どこから手をつければよいのか判断がつかず、結果として全体の対応が曖昧なまま先延ばしにされてしまうことが多い。また、後継社長自身も、多くの問題を一度に抱えると、優先順位をつけられずに交渉全体の主導権を失いやすい。品質改善は、一度の交渉で全てを解決するものではなく、優先順位の高いものから順番に、小さな成功体験を積み重ねていくプロセスとして捉えるべきだ。最初の改善がうまく進み、実際に効果が出たという実績ができれば、その後の交渉はより信頼関係に基づいたものになり、次の課題への着手もスムーズになる。逆に、最初から大きな要求を突きつけて交渉が停滞すると、その後の小さな改善提案すら「また面倒なことを言われるのではないか」という警戒心を招き、関係全体がぎくしゃくしてしまう。
よくある質問
Q1. 古参のベンダーに品質改善を求めたら、逆に機嫌を損ねて対応が悪くなるのではないかと心配です。どう配慮すればいいですか。
配慮のポイントは、伝える内容そのものよりも、伝え方の構成にある。まず、これまでの仕事に対する感謝や敬意を最初に言葉にすること。次に、批判ではなく「事実の共有」という形式で伝えること(「使いにくいと感じる」ではなく「このような作業に何分かかっている」という記録ベースの伝え方)。そして、今後も長く付き合いたいという前向きな意思を明確にすることだ。この三点を押さえれば、多くの場合、ベンダー側も防御的にならずに話を聞いてくれる。それでも態度が変わらない、あるいは明らかに対応が悪化するようであれば、それはベンダー側の姿勢の問題であり、今後の取引継続そのものを検討する材料にすべきだ。
Q2. 先代とベンダーの個人的な関係が深く、切り替えを口にすることすら難しい雰囲気があります。どうすればいいですか。
このような場合、まずは「切り替え」を前提とせず、「現状の可視化」を目的とした行動から始めるとよい。外部の第三者に現行システムの技術的な状態を評価してもらう、いわゆるセカンドオピニオンを取ることは、ベンダーを否定する行為ではなく、経営者としての説明責任を果たすための行動として位置づけられる。この評価結果は、ベンダーとの今後の改善交渉における客観的な根拠にもなるし、万が一将来的に切り替えを検討する必要が生じた場合の判断材料にもなる。個人的な関係への配慮と、経営判断としての情報収集は、両立させることができる。
Q3. ベンダーに相談しても「昔からこの仕様です」「今更変えるのは難しい」と言われて話が進みません。どう対応すればいいですか。
この回答が返ってくる背景には、担当者自身がシステムの経緯を正確に把握していない、あるいは変更に伴うリスクを恐れている、という事情がある可能性が高い。この場合、感情的に食い下がるのではなく、「その仕様に至った経緯を示す資料はあるか」「変更した場合に具体的にどのリスクがあるのか」を、書面や見積もりの形で提示してもらうよう依頼するとよい。資料が出てこない場合、それは仕様として正式に合意されたものではなく、単に長年見直されていない未整理な部分である可能性が高い。この状況を明確にすること自体が、次の交渉のステップにつながる。
Q4. 品質改善のためにどの程度の予算を確保すればいいのか、見積もりの妥当性がわかりません。
見積もりの妥当性を判断するためには、まずステップ3で計算した「その問題によって発生している年間コスト」と、提示された見積もり額を比較することが基本になる。加えて、可能であれば同種の改修について、別のベンダーや専門家に概算の意見を聞く(セカンドオピニオン)ことも有効だ。ただし、既存システムへの改修は、システムの内部構造への理解度によって難易度と費用が大きく変わるため、単純な金額の比較だけでなく、見積もりの根拠(作業内容の分解、想定される工数)を必ず確認し、範囲が明確になっているかどうかを重視するべきだ。範囲が不明確な見積もりは、後から追加費用が発生するリスクが高い。
まとめ
事業承継後にシステムの品質の低さに気づいたとき、後継社長がまず取り組むべきは、感覚的な不満をそのままベンダーにぶつけることではなく、事実の記録、問題の分類、金額への翻訳という準備を経て、今後も関係を続けることを前提とした改善の相談として伝えることだ。古参のベンダーには、技術的負債、価格構造、担当者の世代交代、先代との関係性への配慮といった、単純な怠慢とは言い切れない事情が存在していることも多い。その事情を理解しつつ、事実に基づいた対話を積み重ねることが、感情的な対立を避け、実際の改善を引き出す最も確実な道筋になる。
品質改善の要求と、先代が築いた人間関係への敬意は、対立するものではない。むしろ、先代が築いた関係を今後も長く続けていきたいという思いがあるからこそ、今のうちに透明性を高め、記録を整え、双方が納得できる形で改善を進めておく必要がある。先代が築いた開発会社との関係をどう長期的に維持していくかについては、先代の顔を立てながら、開発会社と長期的にうまく付き合う方法も参考にしてほしい。関係を大切にすることと、現状に問題があると認識して声を上げることは、矛盾しない両立可能な態度だ。この両立を実現するための道具立てが、本記事で示した事実の記録、四分類での整理、金額への翻訳、場の設計、優先順位付け、文書化、そして効果検証という一連のステップである。
これらのステップを一度に完璧に実行する必要はない。むしろ、最初の一歩は小さくてよい。今日、現場で一つだけ気になっている操作の不便さについて、いつ、どのくらいの頻度で、どれくらいの時間がかかっているのかをメモに残すことから始めればよい。その小さな記録の積み重ねが、いずれベンダーとの建設的な対話の土台になり、社内の古参社員との信頼関係を築く材料にもなる。
事業承継とは、先代が築いた資産を引き継ぐと同時に、先代が見過ごしてきた課題にも向き合う過程でもある。システムの品質という、地味で目立たないテーマではあるが、これに丁寧に向き合う姿勢そのものが、社内外の関係者に対して「この後継社長は、感情論ではなく事実に基づいて経営を進める人だ」という印象を残す。目の前のシステムの不具合一つひとつへの対応が、実は後継社長としての立ち位置を社内に示す機会にもなっているということを、忘れないでおきたい。焦らず、記録を積み重ね、関係を大切にしながら、一つずつ前に進めていくことが、結果的に最も早く品質改善にたどり着く道でもある。
