月曜の朝、見積書を前に固まる
月曜の朝八時、後継社長は事務所の自席で一枚の見積書を前に固まっていた。先代が懇意にしていた開発会社から届いた、基幹システム改修の見積書だ。金額は前回の改修より三割高い。工数の内訳を見ても「要件定義」「設計」「開発」「テスト」という四行の箱があるだけで、何にどれだけの時間がかかっているのか、正直よく分からない。
先代であれば、電話一本で「まあ、いつも通り頼むわ」と発注していただろう。長年の付き合いの中で、金額の妥当性も、開発会社の言い分も、体で分かっていたはずだ。しかし後継社長にはその蓄積がない。先代が退いてからまだ半年。開発会社の担当者とは数回顔を合わせただけで、向こうがどんな体制でどんな判断基準で仕事をしているのかも見えていない。
社内に目を転じても、状況は変わらない。長年システムを使い続けてきた古参の従業員は「前はこうだった」「あの機能は今のままでいい」と言うが、その要望が本当に業務上必要なのか、単に慣れの問題なのか、後継社長には判断がつかない。開発会社に何かを頼むにしても、社内の意見を一つにまとめる自信もない。結局、見積書は決裁されずに三日間机の上に置かれたままになった。
これは特別な話ではない。事業承継後の社長が最初にぶつかる壁の多くは、実は「発注」という行為そのものにある。技術的な知識が足りないからではない。発注者としての振る舞い方、開発会社との関係の作り方、社内の要望を整理して伝える手順、そうした「習慣」が先代から引き継がれていないからだ。本稿では、承継社長がシステム発注において信頼される「良い発注者」になるための七つの習慣を、具体的な場面とともに解説する。
なぜ承継直後の社長は「発注」でつまずきやすいのか
属人化した関係が承継で断絶する
中小企業のシステム発注は、多くの場合、契約書や仕様書ではなく「人と人の関係」で成立している。先代社長と開発会社の担当者、あるいは開発会社の社長同士が、長年の付き合いの中で暗黙の了解を積み上げてきたケースが非常に多い。値引きの相場感、急な依頼にどこまで応じてもらえるか、支払いのタイミング、トラブル時の対応スピード。これらはすべて契約書に明文化されているわけではなく、人間関係という土台の上に成り立っている。
事業承継が起こると、この土台がいったん崩れる。開発会社側からすれば「新しい社長は何を求めているのか分からない」「先代のときと同じ条件で続けられるのか分からない」という不安を抱く。逆に後継社長側からすれば「この開発会社は本当に適正な価格でやってくれているのか」「先代だから大目に見てもらっていた部分はないか」という疑念を抱きやすい。この双方の不安と疑念が、承継直後の発注関係をぎこちなくする最大の要因である。
さらに厄介なのは、この関係の断絶が「言語化されないまま」進行することだ。先代は引退時に「あの会社とは長い付き合いだから、任せておけば大丈夫」としか言い残さない。開発会社との過去のやり取り、価格交渉の経緯、トラブルの記録などが体系的に引き継がれることはほとんどない。後継社長は白紙の状態から関係を再構築せざるを得ないのに、周囲は「もう関係はできている」という前提で動いてしまう。この認識のズレが、最初の発注でつまずく構造的な原因になる。
技術的な非対称性が判断を萎縮させる
発注者と開発会社の間には、常に情報の非対称性が存在する。開発会社は技術に詳しく、後継社長の多くは技術に詳しくない。この非対称性自体は珍しいことではなく、どの業界の発注関係にも存在する。問題は、承継直後の社長がこの非対称性を「自分には発言権がない」という誤った結論に結びつけてしまうことだ。
先代であれば、技術的な詳細は分からなくても「この会社は信頼できる」という長年の実績に基づく確信があった。だから多少高い見積もりが出てきても、大きな不安なく決裁できた。後継社長にはその確信の土台がない。技術も分からず、信頼の実績もない状態で見積書を前にすると、「言われた通りに払うしかない」という受け身の姿勢になりがちだ。
この受け身の姿勢は、実は開発会社にとっても望ましいものではない。良い開発会社は、発注者が要件を明確にし、優先順位を示し、疑問点をきちんと質問してくれることを望んでいる。発注者が黙って言われた通りに支払うだけの関係は、短期的には楽に見えても、長期的には開発の精度を落とし、双方の信頼関係を薄くする。技術が分からないことと、発注者としての役割を放棄することは、まったく別の問題なのだ。
社内の「声の大きい人」が要件を歪める
システム発注のもう一つの構造的な問題は、社内の要望の集約にある。多くの中小企業では、システムに対する要望が現場から社長に直接上がってくる。しかし、その要望は必ずしも会社全体の利益を代表しているわけではない。長年勤めている古参の従業員の意見が強く反映されやすく、逆に新しく入った従業員や、声を上げにくい立場の従業員の意見は反映されにくい。
先代であれば、古参の従業員との関係が深く、どの要望が本当に業務上必要で、どの要望が単なる慣れや好みの問題かを、経験的に見分けることができた。後継社長には、その見分ける力がまだない。結果として、声の大きい人の要望がそのまま開発会社への発注内容になってしまい、後から「本当に必要だったのはこの機能ではなかった」という手戻りが発生する。
さらに、事業承継期は組織内の力関係が最も不安定になる時期でもある。古参の従業員は「新しい社長がどこまで自分たちの意見を尊重してくれるか」を試すような態度を取ることがあり、逆に若手は「今のうちに改善を訴えよう」と積極的に声を上げることがある。この不安定な力関係の中で発注要件を固めようとすると、要件そのものが社内政治の道具になってしまう危険がある。良い発注者になるためには、この力学を理解し、要望を公平に整理する仕組みを持つことが不可欠だ。
「値切ればいい」という誤解
承継社長が陥りやすい誤解の一つに、「発注者として強い立場に立つとは、価格を厳しく交渉することだ」という考え方がある。これは半分正しく、半分間違っている。適正な価格交渉は発注者の当然の権利だが、価格だけに焦点を当てた交渉は、開発会社との関係を短期的な取引に変質させてしまう。
開発会社にとって最も避けたい発注者は、価格には厳しいが要件は曖昧で、後から追加要望を無償で求めてくるタイプだ。逆に開発会社が最も長く付き合いたいと思う発注者は、要件を明確に示し、優先順位を伝え、変更が発生した場合には追加コストを理解してくれる発注者である。価格交渉に力を入れる前に、まず要件を明確にする力を身につけることが、結果的に価格の適正化にもつながる。
コミュニケーションの頻度と質のバランス
もう一つの構造的な問題は、コミュニケーションの取り方だ。承継直後の社長は、開発会社との関係に不安を抱くあまり、些細なことまで頻繁に連絡を入れてしまうか、逆に関係が気まずくて連絡を最小限にしてしまうか、どちらか極端に振れやすい。
頻繁な連絡は、開発会社の稼働時間を消耗させ、結果的にコストや納期に影響する。一方で連絡を控えすぎると、要件のズレや進捗の遅れが発覚するタイミングが遅くなり、手戻りが大きくなる。適切な頻度と質のコミュニケーションを設計することは、発注者としての基本動作でありながら、承継直後の社長が最も苦手とする部分の一つだ。
ケーススタディ一 — 先代の口約束を引き継いだ製造業の後継社長
地方都市で金属加工業を営む企業の後継社長は、先代の急な引退により、準備期間が二か月足らずで社長に就任した。会社の受発注管理システムは、先代が個人的に懇意にしていた小規模な開発会社に十年以上前から発注しており、契約書は簡素な業務委託契約のみで、具体的な業務範囲や対応時間は口約束が中心だった。
就任直後、システムに不具合が発生した。開発会社に連絡すると「先代からは月額保守料の中で対応する約束だった」という回答が返ってきたが、後継社長の手元にある契約書には保守の範囲が明記されていなかった。開発会社の担当者は困惑した様子で「今まで通りにやらせてもらってきただけです」と説明した。ここで後継社長は、口約束に頼った関係の脆さを痛感した。
この社長が最初に取った行動は、感情的に問い詰めることではなく、これまでの経緯を丁寧に聞き取ることだった。開発会社の担当者に時間を取ってもらい、過去の対応履歴、月額保守料の中で行ってきた作業の実態、先代とのやり取りの記憶を、できる範囲で書面化してもらった。そのうえで、これから先の関係については新たに保守範囲を明文化した覚書を交わすことを提案した。
開発会社側もこの申し出を歓迎した。担当者は「今まで曖昧なままやってきて、こちらも不安だった。明文化してもらえるなら、こちらも安心して対応できる」と話した。結果として、月額保守料に含む作業範囲と、範囲外の作業に対する追加費用の基準が明確になり、以後の不具合対応がスムーズになった。この事例が示すのは、口約束の関係を無理に壊すのではなく、丁寧な聞き取りを通じて明文化する姿勢が、開発会社との信頼を保ったまま関係を刷新する道になるということだ。契約更新の際に開発会社から何を受け取っておくべきかは、保守契約を更新する前に、開発会社から受け取っておくべきものにも整理している。
ケーススタディ二 — 古参社員の要望に振られた小売業の後継社長
複数店舗を展開する小売業の後継社長は、就任後まもなく、店舗の在庫管理システムの改修を検討することになった。改修の発端は、長年勤める店長からの「レジ画面が使いにくい、以前のバージョンに戻してほしい」という強い要望だった。後継社長はこの要望をそのまま開発会社に伝え、旧バージョンへの巻き戻しを依頼した。
ところが、開発会社が調査を進めると、旧バージョンには在庫の二重登録を防ぐ仕組みが入っておらず、過去に実際にトラブルが発生して現行バージョンに改修されていたことが判明した。つまり店長の要望は、単なる操作の慣れの問題であり、業務上の必要性に基づくものではなかった。開発会社からこの経緯を知らされた後継社長は、店長の要望をそのまま発注に反映させたことを反省した。
この社長はその後、要望を受け取る際に「なぜその変更が必要なのか」を必ず一段掘り下げて確認する習慣を導入した。店長の要望に対しても「使いにくいと感じる具体的な場面はどこか」「その場面で業務にどんな支障が出ているか」を聞くようにし、要望の背景を自分の言葉で説明できる状態にしてから開発会社に伝えるようにした。
半年後、同じ店長から別の改修要望が上がった際、後継社長はこの手順を踏んで要望を整理し、開発会社にも背景情報を添えて伝えた。開発会社の担当者は「今回は要件がクリアで、こちらも提案しやすかった」と評価し、実際に想定より少ない工数で改修が完了した。この事例は、社内の要望を鵜呑みにせず、背景を確認してから発注に反映させる習慣が、手戻りの防止と開発会社からの信頼獲得の両方につながることを示している。
ケーススタディ三 — 価格交渉に固執した建設関連企業の後継社長
建設関連の中小企業を継いだ後継社長は、就任直後に届いた基幹システムの改修見積もりを見て、前年より高いという理由だけで開発会社に強く価格交渉を求めた。開発会社は工数の内訳を示して説明を試みたが、後継社長は「先代の時よりも高いのはおかしい」という一点で押し通し、結果的に見積もりを二割下げさせることに成功した。
しかし、実際の開発が始まると問題が次々と表面化した。開発会社は削減されたコストの中で対応するため、テストの工程を簡略化し、要件定義の打ち合わせ回数も減らした。結果、リリース後に複数の不具合が発生し、追加の修正対応にかえって当初の見積もり差額以上のコストがかかった。後継社長は価格交渉に成功したつもりだったが、総合的なコストでは損失を出す結果になった。
この経験から、後継社長は価格だけを見て交渉することの危うさを学んだ。次の発注では、見積もりの内訳を細かく確認し、どの工程にどれだけの時間がかかっているのかを開発会社に説明してもらい、削れる部分と削れない部分を切り分けて交渉するようにした。テストや要件定義の工程を削るのではなく、機能の範囲を絞ることでコストを調整する方向に交渉の軸を変えたところ、開発会社も納得しやすい形で価格調整に応じてくれた。この事例は、価格交渉そのものが悪いわけではなく、交渉の対象を工程の質から機能の範囲に変えることが、良い発注者への転換点になることを示している。
良い発注者になるための七つの習慣
以下では、承継社長が実践すべき七つの習慣を、具体的な行動レベルで解説する。単なる心構えではなく、日々の業務の中で実行できる手順として整理した。
習慣一 — 発注の背景を自分の言葉で説明できるようにする
見積書や提案書に対して決裁のサインをする前に、「なぜこの改修が必要なのか」を自分の言葉で誰かに説明できる状態を作る。これができない場合、それはまだ発注する準備が整っていないという合図だと考える。
具体的な手順としては、開発会社からの提案を受けた後、必ず一晩置いてから、要件と背景を自分でノートに書き出す。書き出す際に言葉が出てこない部分があれば、それが理解不足の箇所であり、翌日改めて開発会社に質問する対象になる。この習慣を続けることで、決裁の質が上がるだけでなく、開発会社に対しても的確な質問ができるようになり、結果的に相手からの信頼も高まる。
習慣二 — 見積もりは金額でなく内訳と前提条件を見る
見積書を受け取ったら、まず総額ではなく内訳と前提条件を確認する。前提条件とは、その見積もりがどの範囲までを対象としており、どこからが追加費用の対象になるのかという境界線のことだ。この境界線が曖昧なまま発注すると、後から「これは想定していなかった追加作業だ」という揉め事が発生しやすい。
実務としては、見積書を受け取った際に「この金額に含まれる作業と含まれない作業を教えてほしい」と必ず質問する習慣を持つ。開発会社によっては、この質問をされることで初めて自社の見積もりの説明責任を意識し、より丁寧な提案書を作成するようになることもある。金額の妥当性を判断する土台は、内訳と前提条件の理解から始まる。
習慣三 — 社内の要望は「誰が」ではなく「なぜ」で拾う
社内から上がる要望を発注内容に反映する際は、誰が言ったかではなく、なぜその要望が出てきたのかという背景を必ず確認する。声の大きい従業員の要望だからといって優先度を上げるのではなく、業務上どれだけの影響があるのかという軸で整理する。
具体的には、要望を受けたときに「その状況で今、どんな困りごとが起きているか」「その困りごとが起きる頻度はどれくらいか」の二点を必ず聞くようにする。この二点さえ整理できれば、開発会社に伝える要件の質が大きく上がり、開発会社側も優先順位をつけた提案がしやすくなる。社内の声を拾う仕組みを持つことは、良い発注者の土台となる習慣だ。
習慣四 — 契約と口約束の境界を定期的に確認する
先代の時代からの取引がある場合、契約書に明記されていない口約束のような取り決めが存在することが多い。これを放置せず、就任後の早い時期に一度、開発会社と一緒に「今まで口約束でやってきたことは何か」を確認し、必要なものは書面に落とし込む。
この作業は開発会社にとっても歓迎されることが多い。曖昧な取り決めのまま対応を続けることは、開発会社側にとってもリスクであり、明文化されることで双方が安心して仕事を進められるようになる。年に一度程度、この境界を見直す時間を設けることで、認識のズレが蓄積することを防げる。
習慣五 — 質問は恥ずかしがらず、分からないことを明示する
技術的な用語や仕組みが分からないとき、それを隠さずに「分からないので説明してほしい」と伝える習慣を持つ。分からないことを隠して曖昧に頷いてしまうと、後で要件のズレが発覚したときに責任の所在が不明確になる。
良い開発会社は、発注者の理解度に合わせて説明の仕方を調整してくれる。逆に、質問しても丁寧に説明しようとしない開発会社であれば、それ自体が関係を見直すべきサインになる。分からないことを明示する習慣は、発注者としての誠実さを示すと同時に、開発会社の対応の質を見極める手段にもなる。
習慣六 — 変更や追加が発生したら都度コストと期限への影響を確認する
開発の途中で新たな要望や変更が発生することは避けられない。そのたびに、その変更が費用と納期にどう影響するのかを開発会社に確認する習慣を持つ。確認せずに変更を依頼し続けると、後から「積み重なった変更分のコストが想定より大きい」という状況に陥りやすい。
この習慣を実践するには、変更や追加を依頼する際に「これを追加すると納期や費用にどれくらい影響しますか」という一文を必ず添えることを社内のルールにするとよい。この一文があるだけで、開発会社側も変更の影響を都度整理して回答するようになり、双方の認識のズレを防ぐことができる。仕様変更のたびに費用面で揉めないための具体的な伝え方は、仕様変更を伝えるとき、追加費用でもめないための手順で詳しく解説している。
習慣七 — 感謝と評価の言葉を具体的に伝える
発注者と開発会社の関係は、指示と対応の一方通行ではなく、双方向の協力関係であるべきだ。良い対応をしてもらったときには、抽象的な「ありがとう」ではなく、「あの場面での対応が早くて助かった」というように具体的に伝える習慣を持つ。
この習慣は些細に見えるが、長期的な関係の質を大きく左右する。具体的な感謝の言葉は、開発会社の担当者にとって、自分たちの仕事がどのように評価されているかを知る手がかりになり、次の仕事への意欲にもつながる。承継社長が先代から引き継ぐべき最も重要な資産の一つは、こうした人間関係を育てる姿勢そのものだ。
実務チェックリスト — 発注前・発注中・発注後
以下のチェックリストは、実際の発注業務の各フェーズで確認すべき項目をまとめたものだ。項目ごとに、なぜ確認が必要かの説明を添えている。
発注前フェーズ
一つ目は、要望の出どころと背景の整理である。社内から上がってきた要望について、誰がどんな場面でその要望を持ったのか、業務上の影響度はどれくらいかを書面に整理する。この整理を怠ると、後から要望の妥当性を検証できず、開発会社への説明も曖昧になる。
二つ目は、過去の取引履行の確認である。先代の時代からの契約書、口約束の内容、過去のトラブル対応の記録があれば集め、なければ開発会社に確認して書面化を依頼する。この確認を怠ると、既存の関係の前提が分からないまま新しい発注を進めることになり、双方の認識ズレの温床になる。
三つ目は、複数の選択肢の比較検討である。長年同じ開発会社に発注し続けている場合でも、少なくとも数年に一度は他社の見積もりや提案を聞く機会を作る。これは必ずしも発注先を変えることを目的とするのではなく、自社の発注内容や価格感覚を相対的に把握するための行為である。刷新の規模が大きくなる局面では、社内主導で進めるか外注に任せるかという選択そのものも論点になる。この判断軸は刷新を社内主導で進めるか外注に任せきりにするかの決め方で扱っている。
発注中フェーズ
四つ目は、見積もりの内訳確認である。総額だけでなく、要件定義、設計、開発、テストといった各工程にどれだけの時間と費用が配分されているかを確認する。工程間の配分が極端に偏っている場合、その理由を質問する。
五つ目は、進捗確認の頻度設計である。開発規模に応じて、週次または月次の進捗報告の場を設定する。頻度が高すぎると開発会社の稼働を圧迫し、低すぎると問題の発覚が遅れる。適切な頻度は開発規模や重要度によって異なるため、開発会社と相談して決める。
六つ目は、変更管理のルール確認である。要件変更や追加が発生した場合の対応手順、費用と納期への影響の伝達方法を、発注の初期段階で開発会社と合意しておく。このルールがないまま開発が進むと、変更の積み重ねが後から大きな費用増につながる。
発注後フェーズ
七つ目は、納品物の検証手順の実施である。納品されたシステムが要件通りに動作するかを、実際の業務フローに沿って確認する、いわゆる検収の工程だ。担当者一人だけでなく、実際に業務で使う従業員にも試用してもらい、現場目線での問題点を洗い出す。
八つ目は、保守・運用体制の確認である。納品後の不具合対応やアップデート対応が、どの契約範囲でどのように行われるのかを確認する。保守契約の範囲が曖昧なままだと、後から追加費用の発生でトラブルになりやすい。
九つ目は、振り返りの実施である。発注が完了した後、開発会社との間で今回のプロジェクトの良かった点と改善すべき点を振り返る機会を設ける。この振り返りを継続することで、次の発注の質が徐々に向上していく。
十つ目は、社内への結果共有である。要望を出した従業員に対して、システムがどのように改善されたのか、なぜその形になったのかを説明する。この共有を怠ると、要望を出した従業員が「自分の声が届いていない」と感じ、次回以降の要望の質が下がる可能性がある。
よくある失敗パターン三つ
失敗パターン一 — 先代との比較でしか判断しない
承継直後の社長が最も陥りやすい失敗は、すべての判断基準を「先代だったらどうしていたか」に置いてしまうことだ。見積もりが先代の時より高いか安いか、対応が先代の時と同じかどうか、そうした比較だけで発注の良し悪しを判断してしまうと、状況の変化や技術の進歩を正しく評価できなくなる。
先代の時代と現在では、システムの規模、業務の複雑さ、開発会社側の体制も変化している。単純な金額比較だけで判断すると、必要な投資を渋ってしまったり、逆に不要な支出を見逃してしまったりする。先代の判断は参考にはなるが、絶対の基準にはならない。承継社長は、自社の現在の業務実態に基づいて、独自の判断基準を作り直す必要がある。この作業を怠ると、いつまでも先代の影に判断を委ねる発注者から脱却できない。
失敗パターン二 — 社内の声を無条件に代弁する
二つ目の失敗パターンは、社内から上がった要望をそのまま開発会社への発注内容として代弁してしまうことだ。後継社長は就任直後、社内の信頼を得ようとするあまり、従業員の要望をできるだけ聞き入れようとする傾向がある。この姿勢自体は悪いことではないが、要望の妥当性を検証せずに右から左へ流すだけの窓口になってしまうと、開発の方向性がぶれる。
ケーススタディ二で示したように、要望の背景を確認しないまま発注すると、業務上不要な改修に費用と時間を使ってしまうことがある。さらに、複数の従業員から矛盾する要望が上がった場合、その調整を行わずにすべてを開発会社に伝えると、開発会社側も優先順位をつけられず、混乱した提案しか出せなくなる。良い発注者は、社内の声を集める窓口であると同時に、その声を整理し優先順位をつける役割も担う必要がある。
失敗パターン三 — トラブルを開発会社との関係悪化と直結させる
三つ目の失敗パターンは、システムの不具合やトラブルが発生した際に、それを即座に開発会社との関係の問題として捉え、感情的な対応をしてしまうことだ。特に承継直後は、開発会社への信頼がまだ確立していないため、小さな不具合でも「この会社は大丈夫なのか」という疑念が急速に膨らみやすい。
しかし、システム開発においてトラブルや不具合の発生自体は珍しいことではなく、その対応の速さと質こそが評価すべき対象だ。トラブルが起きた瞬間に関係を疑うのではなく、対応のプロセスを冷静に観察し、そのうえで関係の継続を判断するべきだ。ケーススタディ一で示したように、曖昧な取り決めが原因のトラブルであれば、感情的に問い詰めるのではなく、丁寧な聞き取りと明文化によって関係を刷新する道を選ぶべきである。トラブル対応の質を見誤ると、本来長く付き合うべき良い開発会社との関係を、承継直後の不安から手放してしまうことになりかねない。
FAQ
質問一 先代が使っていた開発会社との関係を見直すべきか迷っています。どう判断すればいいですか。
まずは関係を断つかどうかを急いで判断するのではなく、これまでの取り決めを明文化する作業から始めることを勧める。口約束や慣習で成り立っている部分を書面化する過程で、開発会社側の対応の姿勢や説明の丁寧さが見えてくる。その過程を通じて、関係を継続すべきか見直すべきかの判断材料が自然に集まってくる。
質問二 社内の要望が多すぎて、どれを開発会社に伝えるべきか整理できません。
要望を受け取る際に、誰が言ったかではなく、その要望が発生した業務上の背景と頻度を確認する習慣を持つことを勧める。背景と頻度が明確な要望から優先順位をつけていくと、伝えるべき要望が自然に絞られていく。すべての要望を等しく扱おうとすると、優先順位がつけられなくなる。
質問三 見積もりの内訳を聞いても、開発会社があまり詳しく答えてくれません。どうすればいいですか。
内訳の質問に対して丁寧に答えようとしない開発会社は、それ自体が注意すべきサインだと捉えてよい。良い開発会社は、発注者の理解度に応じて説明の仕方を調整し、質問されることを歓迎する。回答が曖昧な場合は、複数回にわたって具体的に質問を重ねるか、他の開発会社の見積もりも並行して取得し、比較対象を持つことを勧める。
質問四 価格交渉をすると開発会社との関係が悪くなるのではと不安です。
価格交渉そのものが関係を悪化させるわけではない。関係が悪化しやすいのは、交渉の対象が工程の質を削ることに向いてしまう場合だ。価格を調整する際は、機能の範囲を絞る、優先度の低い要件を次回に回すといった形で、工程の質を保ったまま調整する方向を開発会社と一緒に探ることを勧める。この姿勢で交渉すれば、多くの開発会社は前向きに応じてくれる。
まとめ
承継直後の社長がシステム発注でつまずくのは、技術知識の不足そのものが原因ではない。先代が長年かけて築いた開発会社との人間関係が承継とともに一度断絶し、社内の要望を整理する経験も蓄積されていない、という構造的な状況に置かれているからだ。この状況を正しく理解することが、良い発注者への第一歩になる。
本稿で示した七つの習慣は、いずれも特別な技術知識を必要としない。発注の背景を自分の言葉で説明できるようにすること、見積もりの内訳と前提条件を確認すること、社内の要望を誰が言ったかでなくなぜ出てきたかで拾うこと、契約と口約束の境界を定期的に確認すること、分からないことを恥ずかしがらずに質問すること、変更や追加のたびにコストと期限への影響を確認すること、そして感謝と評価の言葉を具体的に伝えること。これらはすべて、日々の業務の中で少しずつ積み重ねていける行動だ。
ケーススタディで示した三つの事例が示すように、承継社長が最初につまずくポイントは似通っている。曖昧な口約束、社内の声の鵜呑み、価格だけを見た交渉。しかしこれらのつまずきは、丁寧な聞き取りと明文化、要望の背景確認、交渉対象の見直しによって、いずれも修正が可能だ。失敗を恐れる必要はない。重要なのは、失敗したときにそれを先代との比較や感情的な関係悪化に結びつけず、構造的な問題として捉え直し、次の発注に活かす姿勢を持つことだ。
事業承継は、経営のあらゆる場面で「先代の蓄積をどう引き継ぎ、どう自分なりに再構築するか」という問いを社長に投げかける。システム発注という一つの実務も、その問いの縮図である。良い発注者になることは、開発会社との良好な関係を築くだけでなく、社内の従業員からの信頼を得て、会社全体の意思決定の質を高めることにもつながる。七つの習慣を日々の実務の中で少しずつ試し、自社に合った形に育てていってほしい。
