見積書を前に固まった、ある後継社長の朝
先代が急に体調を崩し、専務だった自分が社長を引き継いでから八ヶ月。取引先への挨拶回りも一巡し、ようやく社内の仕事が落ち着いてきた頃、営業部長から「うちのホームページ、もう十年近く更新してませんよ。今どきスマホで見づらいと若い子に採用面接で言われました」と相談を受けた。ちょうど基幹システムの見積もりももらったところで、社長は思い切って「まとめて全部やってもらおう」と決めた。
知り合いの紹介で来た開発会社の営業担当は、物腰が柔らかく、説明も分かりやすかった。「御社の業務は全部お任せください、我々がプロですから」という言葉に、社長は心から安心した。専門知識がない自分が細かい注文をつけるより、プロに全部委ねる方が良い結果になるはずだ、そう思っていた。契約書に印を押し、着手金を払い、あとは完成を待つだけだと考えていた。
三ヶ月後、初めてのデモを見せられた社長は言葉を失った。画面は綺麗だが、現場が毎日使っている在庫管理の独自ルールがまるで反映されていない。得意先ごとに違う単価掛け率も、先代の時代からの「あの取引先だけは特別扱い」という慣習も、どこにも組み込まれていなかった。開発会社に問うと、「そこは要件定義書に書かれていなかったので、標準機能で作りました」と平然と返された。要件定義書というものがそもそも何なのか、社長は初めて意識した。
追加改修の見積もりは当初予算の一・五倍。工期はさらに二ヶ月延びるという。古参の工場長からは「社長、これはもう最初から現場に聞くべきだったんじゃないですか」と、静かな、しかし重い一言を投げかけられた。社長は返す言葉がなかった。丸投げしたつもりはなかった。ただ、「お任せします」と言った瞬間から、実質的にすべてを丸投げしていたことに、今になって気づいたのだった。
この記事では、なぜ「丸投げ発注」が失敗するのか、その構造的な理由を解き明かし、事業を先代から引き継いだばかりの承継社長が、開発会社に対してどのような発注者としての役割を果たすべきかを、具体的なステップとチェックリストで整理していく。専門知識がないことは恥ずかしいことではない。専門知識がないまま何もしないことが、経営リスクになるのだ。なお、古参社員が「今のままでいい」と現状維持を望む姿勢とどう向き合うかは、古参社員の「今のままでいい」が招く停滞と、向き合い方の最低ラインで扱っている。
なぜ丸投げ発注は構造的に失敗するのか
「プロに任せる」という言葉が隠す責任の空白
丸投げ発注が失敗する最大の理由は、発注者と開発会社の間で「誰が何を決めるか」という責任の所在が曖昧になったまま契約が進んでしまうことにある。開発という営みは、突き詰めれば無数の小さな意思決定の積み重ねだ。この画面のボタンはどこに置くか、この数値は誰が入力するか、承認は何段階必要か、締め日はいつか、例外処理はどう扱うか。これらの決定を積み重ねて初めて、業務に合ったシステムが立ち上がる。
ところが開発会社は、発注者の会社の業務を最初から知っているわけではない。彼らが知っているのは一般的な業務パターンであり、御社固有の慣習ではない。得意先ごとの特別な掛け率、先代が口約束で決めた例外ルール、現場が長年かけて編み出した独自の在庫管理の工夫。これらは文書化されていないことが多く、社長自身も細部までは把握していないことすらある。開発会社が「お任せください」と言うとき、実際に任せられるのは一般的な業務知識の範囲だけであり、御社固有の暗黙知までは任せられない。この構造的なギャップこそが、丸投げ発注が失敗する根本原因だ。
発注者が「決めるべきこと」を決めずに開発会社に投げると、開発会社は自分たちの持つ一般的な知識や、業界標準のテンプレートを使って空白を埋める。これは開発会社が手抜きをしているわけではない。契約上、要件定義書に書かれていないことは「標準的な処理」で実装するのが通常のやり方であり、逆に言えば、書かれていないことについて開発会社が御社の意図を正確に読み取る義務はない。承継社長が陥りやすい誤解は、この責任の所在を「プロだから当然分かってくれるはず」という期待でごまかしてしまうことだ。プロであることと、御社の内部事情を知っていることは、まったく別の話である。
先代経営者との比較が生む心理的な引け目
事業承継の直後という時期には、この構造的な問題がさらに深刻化しやすい特有の事情がある。先代経営者は多くの場合、長年の経験の中で現場のあらゆる業務プロセスを体で理解していた。誰よりも早く出社して工場を回り、営業の商談に同行し、経理の帳簿を自分で確認していた時代を経て、業務のすみずみまで把握していることが多い。だからこそ先代は、開発会社に対しても「ここはこうしてほしい」という具体的な要求を出すことができ、たとえ専門知識がなくても発注者としての役割を自然に果たせていた。
一方、承継社長は多くの場合、先代に比べて現場の細部への理解が浅い。営業畑出身であれば工場の生産管理の細部を知らず、財務畑出身であれば営業現場の商習慣を知らない。この「知らないことの引け目」が、承継社長を丸投げ発注に向かわせる心理的な圧力になる。細かい注文をつけようとしても、そもそも何を注文すればいいのか分からない。恥をかきたくない、無知を露呈したくないという気持ちが、「プロに任せます」という言葉の裏に隠れていることが少なくない。
さらに、承継社長は古参社員や現場の従業員からも「先代ならもっと的確な指示を出していた」という無言の比較にさらされやすい立場にある。この比較を意識するほど、社長は開発会社との折衝という不慣れな領域で自信を持って発言することができなくなり、結果として「専門家に丸投げする」という選択を、責任放棄ではなく謙虚さだと自分に言い聞かせてしまう。しかし実際には、発注者が担うべき役割を放棄した状態にほかならない。開発の専門知識がないことと、自社の業務を定義する責任があることは、両立する。むしろ承継社長こそが、先代の暗黙知を言語化し、開発会社に伝えるべき立場にある。
発注者の役割と開発会社の役割の線引き
開発プロジェクトには、大きく分けて二つの役割がある。一つは「何を作るべきかを決める役割」であり、これは発注者側の責任である。もう一つは「決められたものをどう作るかを設計し実装する役割」であり、これは開発会社側の専門性が生きる領域である。丸投げ発注の問題は、この前者の役割を発注者が果たさずに後者の会社にすべて委ねてしまうことにある。
「何を作るべきか」を決めるためには、自社の業務プロセスを言語化する必要がある。誰が、いつ、どの情報を使って、どう判断し、何を入力するのか。この一連の流れを説明できるのは、御社の中の人間だけである。開発会社がヒアリングを重ねてくれることはあっても、御社の暗黙知をゼロから発見してくれるわけではない。ヒアリングに答える側、つまり発注者側が、自社の業務を語れる状態を用意しておかなければ、ヒアリング自体が機能しない。
承継社長がまず理解すべきは、「発注者として決めるべきことを決める」という役割そのものが、専門知識の有無とは関係なく発注者に課された責務だということである。技術の中身は分からなくてよい。しかし、「何のためにこのシステムを作るのか」「誰が使うのか」「何が成功で何が失敗か」という判断は、発注者にしか下せない。この線引きを最初に理解しておくことが、丸投げ発注から抜け出す第一歩になる。
情報の非対称性がもたらす追加コストの構造
丸投げ発注が失敗すると、金銭的な損失も発生する。これは偶然ではなく、情報の非対称性という構造から必然的に生じる現象だ。開発会社は発注者が提示した情報の範囲でしか要件を把握できない。要件が不足していれば、開発会社は自分たちの標準的な解釈で機能を作り込む。しかしその解釈が発注者の実際の業務とずれていれば、納品後や開発途中で「これでは使えない」という指摘が発生し、変更や追加開発が必要になる。
ここで問題になるのが、多くの開発契約では、契約後に発生する要件の追加や変更は「追加開発」として別途費用が発生する仕組みになっているという点だ。当初の見積もりに含まれていた作業と、後から追加された作業は別物として扱われる。仕様変更を追加費用のトラブルなく伝える手順については仕様変更を伝えるとき、追加費用でもめないための手順で詳しく解説している。丸投げ発注では、要件の詰めが甘いまま契約が進むため、開発が進むにつれて「これも必要だった」「あれも足りない」という発見が続き、その都度追加費用が積み重なっていく。冒頭のエピソードで社長が経験した「当初予算の一・五倍」という数字は、決して特殊な例ではなく、要件定義が不十分な状態で契約したプロジェクトにおいてよく見られる典型的な結果である。
さらに厄介なのは、工期の遅延が単なる時間の問題では済まないことだ。ホームページ制作であれば、次の商戦期に合わせて公開したいという事業上の狙いがあったはずだ。基幹システムの改修であれば、次の決算期や税制改正のタイミングに合わせる必要があったかもしれない。工期の遅延は、こうした事業上のタイミングを逃すという形で、見えないコストを発生させる。丸投げ発注のリスクは、開発コストの増大だけでなく、経営判断のタイミングそのものを狂わせるリスクでもあるのだ。
具体的なケーススタディで見る丸投げ発注の落とし穴
ケース一 基幹システム改修で現場の慣習が消えた金属加工業の事例
ある金属加工業の後継社長は、先代から会社を継いで二年目に、老朽化した受発注システムの入れ替えを決断した。先代の時代から使っていたシステムは動作が不安定で、担当者からの不満も多く、刷新は避けられない課題だった。社長は開発会社を選定する際、「うちは製造業なので、専門的なことは分からないから、標準的な受発注システムのパッケージをベースに、御社のノウハウで組んでほしい」という方針で発注した。
開発会社は真摯に対応し、一般的な受発注業務のフローに基づいたシステムを構築した。ところが実際に稼働させてみると、現場から次々と不満が上がった。この会社では長年、特定の大口顧客からの注文について、通常の受注フローとは別に、営業担当者が独自の判断で優先出荷の順番を調整する運用が行われていた。これは文書化されたルールではなく、営業担当者たちの間で長年培われてきた暗黙の了解だった。新システムにはこの調整機能がなく、担当者は結局、システムの外で電話とメモを使って優先順位を管理せざるを得なくなった。
さらに問題は、原材料の仕入れ先ごとに異なる納期の見込み方があり、先代の時代の経験則で「この仕入れ先は表示納期より三日早く手配しないと間に合わない」という調整が現場の頭の中だけで行われていたことだった。新システムはこの調整を反映していないため、納期遅延のトラブルが続発した。開発会社に相談すると、「そのようなルールは伺っておりませんでした」という回答が返ってきた。当然である。社長自身もこの暗黙の調整ルールの存在を、トラブルが起きるまで正確には把握していなかったのだ。
このケースが示しているのは、承継社長が現場の暗黙知を十分に把握していない状態で「標準的なもので良い」と発注してしまうと、その暗黙知がシステムから漏れ落ち、結果として現場が二重の業務負担を強いられるという構造である。修正のための追加改修には三ヶ月を要し、その間、営業担当者はシステムと手作業を並行して回すという非効率な状態を強いられた。この事例の教訓は明確だ。承継社長は、自分が把握していない業務ルールが現場に存在する可能性を前提に、現場の従業員から直接ヒアリングする機会を、開発会社に会わせる前に自分自身で設けるべきだったということである。
ケース二 ホームページ制作で経営判断を丸ごと預けてしまった卸売業の事例
食品卸売業を営むある会社の後継社長は、先代から引き継いだ翌年、老朽化したホームページのリニューアルを決めた。社長は開発会社との初回打ち合わせで、「今どきのデザインで、おしゃれな感じにしてほしい」という要望だけを伝えた。デザインの好みや業界のトレンドについて詳しくないという自覚があったため、細かい注文をつけるより開発会社の提案力に期待する方が良い結果を生むと考えたのだ。
開発会社は洗練されたデザイン案を提示し、社長もその見た目の完成度に満足して契約を進めた。ところが公開後、既存の得意先から「前のホームページにあった取引実績の一覧がなくなっている」「電話番号が小さすぎて見えない」という指摘が相次いだ。実はこの会社にとってホームページの最大の役割は、新規の見込み客に対して、長年の取引実績と業界内での信頼を示すことだった。しかし社長が「おしゃれな感じ」という抽象的な要望しか伝えなかったため、開発会社はデザイン性を優先した構成を作り、実績紹介は簡素化され、電話番号は洗練されたデザインの中に埋め込まれる形で縮小されてしまった。
問題の根本は、社長が「このホームページが何のために存在し、誰に何を伝えるためのものか」という、事業上最も重要な判断を、開発会社に委ねてしまったことだった。デザインの見た目については開発会社の専門性に頼るのが正しい。しかし「何を最優先で伝えるべきか」という判断は、自社の商売のあり方を知る発注者側にしか下せない経営判断であり、これを丸投げしてしまった結果、見た目は良いが事業目的を果たさないホームページが出来上がってしまった。
修正には追加の打ち合わせと改修費用が発生し、さらに得意先からの信頼にも一時的に影響が出た。この事例が示すのは、「専門知識がないから任せる」という判断が許されるのは、あくまで表現方法や技術的な実装手段の領域であって、「何のために作るのか」という目的設定の領域まで委ねてしまうと、事業の実態とかけ離れた成果物が生まれてしまうという線引きの重要性である。
ケース三 追加要望の応酬で工期が二倍に延びた建設関連業の事例
建設関連の会社を継いだある後継社長は、勤怠管理と工事の進捗管理を一体化させる社内システムの開発を発注した。当初の要件定義の場では、社長は「現場の細かい話は分からないので、現場監督たちと直接やり取りしてほしい」と伝え、開発会社と現場監督との打ち合わせに、自身は基本的に同席しないことにした。
現場監督たちはそれぞれ独自のやり方で工事を管理しており、ある監督は紙の日報を重視し、別の監督はグループチャットでの報告を好んでいた。開発会社は個々の監督の要望を聞くたびに、それぞれの好みに合わせた機能を追加で作り込んでいった。誰も「全体としてどのような運用に統一するか」という方針を示さなかったため、開発会社は現場から上がってくる要望を断る立場になく、要望のたびに機能が積み上がっていった。
三ヶ月ほど経った頃、社長が久しぶりに進捗を確認すると、当初想定していたシンプルな進捗管理システムが、あらゆる例外パターンに対応した複雑なシステムへと変貌していた。工期は当初の二倍に延び、費用も大幅に膨らんでいた。開発会社側からすれば、現場からの要望をすべて丁寧に反映した結果であり、決して不誠実な対応をしたわけではない。しかし、経営者としての優先順位づけや方針決定が誰からも示されなかったために、収拾のつかない開発になってしまったのだ。
このケースの教訓は、現場の意見を聞くこと自体は正しい判断だが、複数の現場の意見が対立したり、要望が膨らみ続けたりする場面で「最終的にどうするか」を決める役割は、現場に委ねてはならず、発注者である社長自身が引き受けなければならないということだ。現場に「分からないから直接話してくれ」と丸投げした瞬間、社長は自社の中で下されるべき経営判断の主体を失ってしまった。開発会社との折衝以前に、社内の意見をまとめる役割こそが、承継社長が果たすべき発注者の役割の核心なのである。
承継社長が果たすべき発注者の役割 実務ステップとチェックリスト
丸投げ発注の失敗パターンを理解した上で、ここからは承継社長が発注者として具体的にどう動けばよいかを、段階を踏んで整理する。技術的な知識は不要である。必要なのは、自社の業務と目的を言語化し、判断を下す姿勢である。
ステップ一 目的を一文で言い切る
開発会社に会う前に、まず「このシステムやサイトを作る目的は何か」を一文で言い切れるようにしておく。「ホームページを新しくする」ではなく、「既存の得意先に対して取引実績と信頼性を示し、新規の見込み客からの問い合わせを増やす」というように、誰のために何を達成するのかを明確にする。この一文が曖昧なままだと、開発会社はデザインや機能の優先順位を決める判断材料を持てず、一般的な標準仕様に頼るしかなくなる。目的を言い切ることは技術知識を必要としない、経営者だからこそできる仕事である。この一文は、後の要望の対立が起きたときに立ち返る判断基準にもなる。
ステップ二 現場の暗黙知を洗い出す聞き取りを自分で行う
開発会社との打ち合わせの前に、現場の古参社員や各部署の責任者に対して、社長自身が聞き取りを行う。「先代の時代からの独自ルールで、文書には残っていないものは何かありますか」という問いを投げかけ、得意先ごとの特別対応、季節ごとの例外処理、担当者の頭の中にだけある判断基準などを一つずつ書き出す。ケーススタディで見た金属加工業の事例のように、こうした暗黙知は現場が「当たり前すぎて言うまでもない」と思って口にしないことが多いため、聞き手が意識的に掘り出す姿勢を持たなければ表に出てこない。この聞き取りは開発会社に任せてはならない。社内の人間関係や信頼関係の中でしか出てこない情報だからである。
ステップ三 業務の流れを図か表にして書き出す
聞き取った内容を、簡単な図や表にまとめる。誰が、いつ、どの情報を使って、何を判断し、次に誰に渡すのか。この流れを可視化しておくことで、開発会社との打ち合わせが格段にスムーズになる。凝った図でなくてよい。手書きのメモや簡単な表でも構わない。重要なのは、口頭での説明だけに頼らず、後から見返せる形にしておくことである。打ち合わせの場で思いつきの説明をすると、聞き漏らしや誤解が発生しやすい。事前に整理された資料があれば、開発会社側も正確に理解しやすくなり、結果として要件のずれを防げる。
ステップ四 譲れないことと譲れることを分けておく
要望をすべて同じ重要度で扱うと、ケーススタディの建設関連業の事例のように、際限なく機能が膨らんでいく。事前に「これは絶対に必要」「これはできれば欲しいが、なくても業務は回る」「これは今回は見送ってよい」という三段階の優先順位を自分の中で整理しておく。この整理があれば、開発会社から追加コストや工期延長の相談があったときも、迷わず判断できる。優先順位づけは経営判断そのものであり、開発会社に代わりに決めてもらうことはできない。
ステップ五 社内の意見をまとめる場を自分で主催する
複数の部署や担当者から異なる要望が出ることは避けられない。この対立を開発会社との打ち合わせの場に持ち込んでしまうと、ケーススタディで見たように、開発会社は誰の意見を優先すべきか判断できず、結局すべてを反映しようとして収拾がつかなくなる。社長は開発会社との打ち合わせの前に、社内の関係者を集めて意見を出し合う場を自分で主催し、対立点があれば自分の責任で結論を出す。この結論を持って開発会社に向かうことで、打ち合わせの場では「決まったこと」を伝える立場になり、話がスムーズに進む。
ステップ六 成功の基準を数字か具体的な状態で決めておく
「使いやすくなればいい」という抽象的な目標では、完成後に「思っていたものと違う」という食い違いが生じやすい。「入力時間が現在の半分になる」「問い合わせ件数が月に一定数増える」「特定の作業が二人体制から一人体制でできるようになる」など、できるだけ具体的な基準を事前に決めておく。この基準は開発会社との契約時にも共有し、双方が同じゴールを見て進められるようにする。基準が明確であれば、開発の途中で方向性がずれたときにも早期に気づくことができる。
ステップ七 進捗確認の場を定期的に自分で設ける
契約後、開発会社からの報告を待つだけの姿勢ではなく、あらかじめ「二週間に一度、進捗を確認する場を設けてほしい」と自分から要望する。ケーススタディの建設関連業の事例のように、放置しているうちに当初の方針から大きく外れてしまうことは珍しくない。定期的に画面や試作品を見せてもらい、想定していた業務の流れと合っているかを自分の目で確認する。専門的な技術評価はできなくても、「これは自社の実際の業務と合っているか」という視点での確認は、発注者である社長にしかできない仕事である。
ステップ八 契約前に変更や追加の扱いを確認しておく
要件が後から変わった場合、追加費用や工期の扱いがどうなるのかを、契約前に開発会社に確認しておく。多くの場合、契約後の要件変更は追加費用の対象になるが、その計算方法や単価は会社によって異なる。このルールを事前に理解しておけば、開発中に追加要望が出た際にも、コストと工期への影響を見積もった上で優先順位を判断できる。契約後に初めてこのルールを知ると、想定外の費用増加に驚くことになり、開発会社との関係にも不要な摩擦が生まれる。
チェックリスト 発注前に自問すべき八つの項目
以下の項目は、開発会社と契約を結ぶ前に、承継社長が自分自身に問いかけるべき確認事項である。すべてに答えられる状態になってから発注するのが望ましい。
一つ目、このシステムやサイトを作る目的を、他人に一文で説明できるか。説明できなければ、目的が固まっていない証拠であり、開発会社に丸投げする土台ができてしまう。
二つ目、現場の古参社員や各部署の責任者から、文書化されていない業務ルールについて直接聞き取りを行ったか。聞き取っていなければ、暗黙知が漏れ落ちるリスクが高い。
三つ目、業務の流れを図や表など、後から見返せる形で整理したか。口頭だけの理解は、打ち合わせの場での誤解を招きやすい。
四つ目、要望の優先順位を三段階程度で自分の中で整理したか。整理していなければ、開発中の要望膨張に対処できない。
五つ目、社内で意見が対立しそうな部署やテーマをあらかじめ想定し、自分が結論を出す準備をしているか。準備がなければ、対立を開発会社に持ち込んでしまう。
六つ目、成功の基準を具体的な言葉や数字で決めたか。決めていなければ、完成後の評価がすれ違う。
七つ目、進捗確認の頻度と方法を、契約前に開発会社と合意したか。合意していなければ、放置期間が生まれ、方向のずれに気づくのが遅れる。
八つ目、要件変更や追加が発生した場合の費用と工期の扱いを、契約前に確認したか。確認していなければ、想定外のコスト増に直面したときに冷静な判断ができなくなる。納品物をどう検収し「完成」と判断するかの基準は、納品物は何をもって「完成」とするか、検収の基準を決めるで整理している。
よくある失敗パターン三つ
失敗パターン一 打ち合わせへの不参加を謙虚さだと思い込む
承継社長にありがちな失敗の一つが、「専門的な話は自分には分からないから」という理由で、開発会社との打ち合わせに現場担当者だけを出席させ、自分は距離を置いてしまうことである。これは謙虚な姿勢のように見えるが、実際には発注者としての最終判断者が打ち合わせの場にいないという状態を生み出す。現場担当者は自分の担当領域については詳しいが、会社全体の経営判断や部署間の優先順位づけを行う権限は持っていない。そのため、打ち合わせの場で意見の対立が起きても、誰も結論を出せず、開発会社は板挟みになる。あるいは、現場担当者の個別の要望がそのまま反映され続け、全体としての整合性が失われていく。社長が同席することは、技術的な話を理解するためではなく、経営判断が必要な場面で即座に決断を下すために必要なのだと理解しておくべきである。少なくとも要件定義の初期段階と、方針が固まる重要な打ち合わせには、社長自身が同席する体制を整えることが望ましい。
失敗パターン二 見積もりの安さだけで開発会社を選んでしまう
もう一つの典型的な失敗は、複数の開発会社から見積もりを取った際に、金額の安さだけを基準に選定してしまうことである。見積もり金額は、開発会社がどこまでの作業を前提に算出したかによって大きく変わる。要件定義が浅い状態で見積もりを依頼すると、開発会社によって想定する作業範囲の解釈が異なり、見積もり金額の単純比較が成立しなくなる。安い見積もりを出した会社は、実は最小限の標準機能しか想定していないことがあり、後になって「それは追加費用です」という項目が次々と出てくることがある。承継社長は、見積もりを比較する際には金額だけでなく、その金額にどこまでの作業が含まれているのか、要件のヒアリングをどの程度丁寧に行う前提になっているのかを確認する必要がある。安さの裏にある前提条件を見抜く目を持たなければ、契約後に想定外の追加費用に苦しむことになる。
失敗パターン三 契約後は完成を待つだけという姿勢になる
三つ目の失敗パターンは、契約を結んだ後、開発が完成するまで特に何もせず、報告を待つだけの姿勢になってしまうことである。開発会社から特に連絡がなければ、順調に進んでいるのだろうと安心してしまい、実際に画面や試作品を確認するのは納品直前になってからということが少なくない。しかし、開発が進む過程で当初の想定とずれが生じることは珍しくなく、そのずれは早い段階で発見できれば小さな修正で済むが、発見が遅れれば大規模な作り直しが必要になる。冒頭のエピソードで社長が三ヶ月後に初めてデモを見て愕然としたのも、この失敗パターンの典型例である。契約後の社長の仕事は、完成を待つことではなく、定期的に進捗を確認し、想定とのずれを早期に見つけ出すことである。この確認作業を怠ることは、発注者としての責任を途中で放棄することに等しい。
よくある質問
専門知識がまったくない状態でも、発注者としての役割は果たせますか
果たせる。発注者が担うべき役割は、技術的な実装方法を決めることではなく、自社の目的や業務の実態を言語化し、優先順位や成功の基準について判断を下すことである。これらはいずれも、自社の内部事情を最も知る立場にある経営者だからこそできる仕事であり、技術の専門知識とは別の能力である。むしろ技術に詳しくないことを理由に、目的や優先順位の判断まで開発会社に委ねてしまうことが、丸投げ発注という失敗を生む。専門知識がないことは、発注者としての役割を放棄する理由にはならない。
現場の従業員に直接ヒアリングしてもらう方が効率的ではありませんか
現場の従業員から詳しい情報を聞き取ること自体は有効だが、それを開発会社に任せきりにしてしまうと、複数の現場から異なる意見が出た際に誰も結論を出せなくなるという問題が起きる。現場からの情報収集は積極的に行うべきだが、収集した情報をどう扱うか、意見が対立した場合にどちらを採用するかという最終判断は、社長自身が引き受ける必要がある。ヒアリングの実施と、判断の主体を分けて考えることが重要である。
先代が生きていた頃の資料やルールが残っていない場合、どうすればよいですか
多くの中小企業では、業務ルールが文書化されておらず、先代や古参社員の頭の中にしか残っていないことが多い。この場合、承継社長がまず行うべきは、古参社員への聞き取りを通じてこれらの暗黙知を言葉に落とし込む作業である。時間はかかるが、この作業を怠って開発会社との打ち合わせに進むと、ケーススタディで示した金属加工業の事例のように、重要なルールがシステムから漏れ落ちるリスクが高まる。文書がなくても、聞き取りによって整理することは可能である。
開発会社との打ち合わせで、自分が何を言えばいいか分からず不安です
打ち合わせで話すべき内容は、技術的な提案ではなく、自社の目的、業務の流れ、優先順位、成功の基準といった、経営者しか答えられない情報である。事前にこの記事のステップとチェックリストに沿って準備を整えておけば、打ち合わせの場では「決まっていること」を伝える立場になり、身構える必要はなくなる。分からないことは正直に「分からないので教えてほしい」と伝え、逆に自社の業務については自分が説明する側に立つという役割分担を意識するとよい。
まとめ
丸投げ発注が失敗するのは、開発会社の能力不足が原因ではない。発注者が本来担うべき「何を作るべきかを決める」という役割を果たさずに、専門家に委ねてしまうことで、御社固有の業務知識や経営判断が抜け落ちたまま開発が進んでしまう構造的な問題である。承継社長は、先代のように現場の細部まで体で覚えているわけではないことに引け目を感じやすいが、専門知識の有無と、発注者としての判断責任は別の話である。目的を一文で言い切り、現場の暗黙知を自ら聞き取り、業務の流れを可視化し、優先順位と成功の基準を決め、社内の意見をまとめ、進捗を定期的に確認する。これらはいずれも技術知識を必要としない、経営者だからこそ果たせる役割である。丸投げをやめることは、開発会社を信頼しないという意味ではない。むしろ発注者としての責任を引き受けることで、開発会社との協力関係がより実のあるものになり、結果として先代から受け継いだ会社に本当に合ったシステムやサイトが生まれる。専門知識がないことを理由に判断を放棄するのではなく、経営者としての判断を粘り強く重ねていくことこそが、承継社長に求められる発注者の役割である。刷新を社内主導で進めるか外注に任せきりにするかの判断そのものについては、刷新を社内主導で進めるか外注に任せきりにするかの決め方も参考にしてほしい。
