「最初に伝えた要望と、できあがったシステムがなぜか違う」。そんな経験をした経営者は少なくないはずです。経営者の頭の中にあったイメージは、営業担当に伝わり、企画担当がまとめ、開発者が実装する——その過程で少しずつ意図が欠落し、変質していきます。まるで子どもの遊びの「伝言ゲーム」のように、最後に出てくるものが最初の意図とかけ離れてしまう。本記事では、この「システム開発の伝言ゲーム」がなぜ起きるのかを構造とデータの両面から整理し、防ぐための考え方を提示します。
システム開発の『伝言ゲーム』とは何か――要望が変質する瞬間
システム開発の現場でしばしば起きるのが、要望を伝える人数が増えるたびに本来の意図が薄れていく現象です。経営者が語った「こうしたい」という言葉は、営業担当のフィルターを通り、企画担当の解釈が加わり、開発者の実装イメージに変換されます。各段階で悪意なく情報が要約・翻訳され、結果として最初の意図とは異なる成果物が生まれてしまう。これは誰か一人のミスというより、情報が複数の人を経由する構造そのものに原因があります。
Structure
システム開発が伝言ゲームになる理由――人を挟むほど要望が変質する構造
独立行政法人情報処理推進機構（IPA）は、システム構築の上流工程において「要求（What）が正しく伝わらない」ことが開発プロジェクトの失敗やトラブルの一因になると報告書で指摘しています。要望が正しく伝わらない背景には、営業・企画・開発という役割分担に加え、さらに外部委託が重なる多重下請け構造があります。発注元から見ても、自社がどこまでを担い、委託先に何を求めるべきかが曖昧なまま進んでしまうケースは珍しくありません。発注側が果たすべき役割の詳細は、別記事「開発委託とは？プロセス・範囲の決め方と「丸投げ」トラブルを防ぐ発注側の役割【AIプロダクト開発編】」で掘り下げていますので、本記事では「人を挟むほど情報が変質する」という構造そのものに焦点を当てます。
Data
データで見る実態――失敗率47.2%とJFTCの多重下請け調査
日経クロステック（日経コンピュータ）が実施した1745件のシステム導入・刷新プロジェクトを対象とした調査では、約半数にあたる47.2%が「失敗」と判定されました。同じ調査を解説した日経ビジネスの記事では、満足を得られなかった理由の筆頭は「要件定義が不十分」だったこと（要件定義＝何を作るかを決める工程）が報告されています。これはまさに、要望が開発現場に正しく届かなかった結果とも言えます。
さらに商流の多層化もこの問題を助長します。公正取引委員会は、ソフトウェア業が多重下請構造型のサプライチェーンとなっているとして、資本金3億円以下の約2万1000社を対象に下請取引の実態調査を実施しました。この調査結果を報じた日本経済新聞の記事では、自社では作業せず利益だけを得る「中抜き」の存在を25%の下請けが認識していたと伝えています。商流が長くなるほど、要望を伝える経路も長くなり、情報の劣化が起きやすくなるのです。
Misconceptions
伝言ゲームの防ぎ方で誤解されがちな3つのポイント
誤解1：優秀な人を挟めば防げる。実際には、どれほど優秀な人であっても、人が一人増えるごとに解釈と要約が発生し、情報の欠落は避けられません。問題は個人の能力ではなく、経由する人数そのものにあります。
誤解2：議事録やドキュメントを増やせば解決する。実際には、ドキュメントは記録を残す手段にはなっても、伝達経路そのものを短くするわけではありません。書類が増えるほど読み込みや解釈の手間も増え、対症療法にとどまりがちです。
誤解3：大手に頼めば安心。実際には、大手企業ほど多重下請け構造に組み込まれやすく、要望が複数の下請け層を経由することでかえって商流が長くなるケースがあります。
まだ検討段階でも相談可能です。現状の開発体制や課題を伺いながらご提案します。
無料で相談するProcess
伝言ゲームを防ぐには――人を減らし、聞いた人がそのまま作る体制
- 人を減らす：要望を伝える人数が増えるほど情報は劣化します。まず経由する人数そのものを減らす設計を検討します。
- 聞いた本人が手を動かす：要望をヒアリングした人がそのまま開発を担当すれば、翻訳や解釈のロスを大きく減らせます。
- 現場に出向く：当社では、代表が自ら現場に出向いてヒアリングを行い、聞いた本人がそのまま形にする進め方を取っています。当社が企画から開発・運営まで自社で手がけている仕事管理のクラウドサービス「Chattus」も、このように要望を聞いた人間がそのまま手を動かす体制で生まれたプロダクトです。
代表の遠山は、3社の起業と2社の売却を経験した連続起業家です。製造業での営業、シンクタンクでのクラウドサービス開発、中堅企業の経営企画責任者などを歴任。新規事業の立ち上げから経営改革、事業成長、EXITまで、現場と経営の両面で実績を重ねてきました。こうした事業サイド・開発サイド双方の経験が、現場の要望を変質させずに形にする土台になっています。
Comparison
開発体制の違いで見る『伝言ゲーム』リスクの比較
| 開発体制 | 情報伝達の経路（要望が開発者に届くまでの層数） |
|---|---|
| 大手システム開発会社（多重下請け型） | 営業・企画・一次請け・二次請けと経由する層が多く、要望が変質しやすい |
| フリーランス・個人受託 | 経路は短いが、属人的でリソースや継続性にリスクがある |
| 社内情報システム部門 | 社内の要望吸い上げは早いが、他部署からの経由段階は残る |
| オプティソース（代表が直接ヒアリングし開発） | 経路が最短になる一方、対応できる案件規模や体制の厚みには限りがある |
FAQ
システム開発の伝言ゲームに関するよくある質問
なぜ大手に頼んでも伝言ゲームが起きるのでしょうか？
大手企業は体制が整っている一方、営業・企画・多重下請け先と経由する層が多くなりがちです。公正取引委員会の調査でも、ソフトウェア業は多重下請構造型のサプライチェーンになっていると指摘されており、規模の大きさが経路の短さを保証するわけではありません。
ドキュメントを厚くすれば伝言ゲームは防げますか？
記録を残す意味では有効ですが、伝達経路そのものを短くするわけではないため根本解決にはなりません。要望を聞いた人がそのまま作る体制のほうが、変質のリスクを構造的に下げられます。
伝言ゲームが起きると、費用や開発期間にどう影響しますか？
要件定義が不十分なまま進むと、意図のズレに気づいた段階で手戻りが発生し、その分だけ費用や期間が膨らみやすくなります。聞いた人がそのまま作る体制は、要望の変質を未然に防ぐことで手戻りを減らし、結果として費用や期間の増加を抑えることにつながります。具体的な費用感はプロジェクトの規模や内容によって異なるため、個別にご相談ください。
発注側はどのような点に気をつければよいですか？
発注範囲やプロセスを事前に明確にしておくことが重要です。詳しくは「開発委託とは？プロセス・範囲の決め方と「丸投げ」トラブルを防ぐ発注側の役割【AIプロダクト開発編】」で解説しています。
小規模なMVP開発（最小限の動く試作品づくり）でも伝言ゲーム対策は必要ですか？
むしろ小規模・短期間のMVP開発こそ、要望を聞いた人がそのまま作る体制が効果を発揮します。経由する人数が少ないほど、初期の意図を保ったまま素早く形にできます。
システム開発の失敗理由の筆頭が「要件定義不十分」であったという調査結果が示す通り、要望が正しく伝わらないことは開発プロジェクトの大きなリスクです。その根本原因は、営業・企画・開発、さらには多重下請けと人を挟むほど情報が変質してしまう構造にあります。防ぐための近道は、優秀な人材を増やすことでもドキュメントを厚くすることでもなく、経由する人数そのものを減らし、聞いた本人がそのまま手を動かす体制をつくることです。自社の開発体制に伝言ゲームの兆候がないか、一度見直してみてはいかがでしょうか。
