「経営層、現場部門、情シス、ベンダーの4者の意見が噛み合わず、プロジェクトが板挟みになって炎上してしまう…」
ITシステム開発プロジェクトにおいて、「要件の食い違い」「度重なる仕様変更」「完成後に誰も使ってくれない」といったトラブルは、業界や企業規模を問わず後を絶ちません。多くの優秀なビジネスパーソンやエンジニアが真剣に取り組んでいるにもかかわらず、なぜシステム開発はこれほどまでに迷走しやすいのでしょうか。
その根本的な原因は、技術力の不足ではなく、「プロジェクトに関わる4つの関係者（経営層・現場部門・情シス・ITベンダー）の間にある目的意識のズレと知識の壁」、そして「多層的な伝言ゲームによる情報の劣化」にあります。
本記事では、IT業界で有名な「本当に必要だったもの（顧客が説明した要件とタイヤのブランコ）」の風刺画を紐解きながら、システム開発が失敗する構造的なメカニズムを解明し、関係者の壁を乗り越えて伝言ゲームを防ぐための具体的な対話アプローチを詳しく解説します。
- 経営層・現場部門・情シス・ITベンダーが抱える「目的意識のズレ」と「知識の壁」
- 経営ビジョンが現場に伝わらずシステム導入が迷走する「伝言ゲームの構図」
- 「本当に必要だったもの」の風刺画から学ぶ現場の4大アンチパターン（要件乖離・実現不能な設計・営業の誇張・破綻）
- 伝言ゲームを排し目線を合わせる3つの実践的対話術（言い換え・可視化・素直な質問）
4つの関係者が抱える「目的意識のズレ」と「知識の壁」
システム開発プロジェクトが難航する最大の理由は、関与する関係者が多く、それぞれの立場によって「見ている景色」や「持っている前提知識」が大きく異なる点にあります。
4者の関心事と「目的意識のズレ」
システム開発に関わる主要な4者（経営層・現場部門・情シス部門・ITベンダー）は、全員が「プロジェクトを成功させたい」と考えています。しかし、成功の定義や優先順位が立場ごとに異なっているため、意図せぬ衝突やすれ違いが発生します。
| 関係者 | 主な関心事・重視する視点 | 現場で陥りがちなスタンス |
|---|---|---|
| 経営層・役員 | 投資対効果（ROI）、全社売上向上、コスト削減、競争力強化 | 「いくら儲かるのか」「いつ全社展開できるのか」と成果を急ぎ、現場の移行負荷を見落としがちになる。 |
| 現場・利用部門 | 日常業務の負担軽減、ミスの防止、現在の業務習慣の維持 | 「今のやり方を変えたくない」「入力項目が増えて面倒だ」と変化に対して防衛的になりやすい。 |
| 情シス・推進部門 | セキュリティ、既存システム連携、運用保守性、全体最適 | 「個別要望を許すと統制が崩れる」「運用規律を守ってほしい」と標準化やセキュリティを最優先する。 |
| ITベンダー・開発会社 | 契約スコープの遵守、納期・工数管理、品質基準の達成、利益確保 | 「仕様書にない要望は対応できない」「追加開発は別見積もりになる」とスコープの防衛に徹しやすい。 |
上図および表が示すように、経営層は「大きなリターン（投資対効果）」を求め、現場は「日々の業務のやりやすさ」を求め、情シスは「セキュリティと全体最適」を求め、ベンダーは「納期と契約工数の遵守」を求めます。
特に実務上、開発の主役となるのは「情シス部門」と「ITベンダー」の2者になりがちです。しかし、この2者だけで仕様を詰めると、「技術的にどう作るか」「工数内に収まるか」という細かな実装議論に視点が偏り、経営層のビジョンや現場ユーザーの使い勝手が置き去りにされてしまう危険があります。
業務知識とIT知識のギャップ（知識の壁）
目的意識の違いに加えて、関係者間に決定的なコミュニケーションの断絶を生み出すのが「業務知識とIT知識の非対称性（知識の壁）」です。
上図が示す通り、発注側である経営層や現場部門は「自社のビジネスモデルや日々の業務の流れ」には精通していますが、データベース構造やサーバー、ネットワークといった「ITの仕組みや制約」を深く理解しているわけではありません。そのため、「何ができて何が難しいのか」「どう頼めば正しく伝わるのか」を判断できません。
一方で、受注側であるITベンダーや開発SEは「プログラミングやシステム設計」の高度な専門知識を持っていますが、「顧客企業の現場で日々どんな商習慣や例外処理が動いているか」という業務の暗黙知までは持ち合わせていません。
この2者の間に「共通言語」がないまま要件定義を進めると、現場は「これくらい言わなくても分かってくれるだろう」と考え、ベンダーは「仕様書に書かれた文面通りに解釈して作ればいい」と考えます。この知識の壁こそが、後々の「こんなはずではなかった」という手戻りを生み出す根本原因です。
経営ビジョンが伝わらない「伝言ゲームの罠」
関係者の多さと知識の壁が組み合わさることで発生する最悪のアンチパターンが、「多層的な伝言ゲームによる開発目的の形骸化」です。
上図の右側に描かれているのは、多くの日本企業で日常的に繰り返されている「伝言ゲームの連鎖」です。
- 1. 経営層の曖昧な指示: 「売上を伸ばすために、我が社もデータを活用するぞ。何か良いシステムを考えろ」と抽象的な号令を現場に出す。
- 2. 現場の丸投げ: 業務部門は「データを活用できる環境を整えてほしい」と、そのままIT部門（情シス）に相談を持ち込む。
- 3. 情シスのツール先行: IT部門は「データ活用ならDWH（データウェアハウス）やBIツールを導入しよう」と、ツールの選定に思考をシフトする。
- 4. ベンダーの目的不明瞭な提案: ベンダーは「ツールの導入」だけを依頼され、「そもそも何のためにデータを使うのか」を知らないままシステムを納品する。
このように、経営層の当初の想いが何重もの人を介して伝達される過程で、「何のためのシステム導入なのか」という本質的な目的が抜け落ちてしまいます。結果として、「最新のBIツールを導入したが、現場は誰も見ず、経営の意思決定にも使われない」という高額なゴミが生まれてしまうのです。
「本当に必要だったもの」の風刺画から学ぶ現場の落とし穴
ソフトウェア開発における伝言ゲームの悲劇とコミュニケーション不全を痛烈に風刺した有名なイラストが、「木に吊るされたタイヤのブランコ（What the customer really wanted）」です。
この風刺画は、発注者が説明した要件から、プロジェクトリーダーの理解、アナリストの設計、プログラマーの実装、営業の過剰な売り込み、そして顧客が真に必要としていたものに至るまで、開発現場のすれ違いを見事に描き出しています。
ここでは、風刺画に描かれている各コマの中から、現代のDX・システム開発現場で特に頻発する4つのアンチパターンを深掘りして解説します。
顧客が説明した要件と「本当に必要だったもの」の乖離
最初の落とし穴は、開発が始まる前の段階で「顧客自身が、自分が真に必要としているものを正しく言語化・説明できていない」という問題です。
上図の左上にある「顧客が説明した要件」を見ると、木から垂らしたロープに座板が3枚も重なって通されており、どこか過剰で不自然なブランコになっています。一方、右下の「本当に必要だったもの」を見ると、木に1本のロープと古タイヤを括り付けただけの極めてシンプルな遊具です。
顧客が真に求めていたのは「木にぶら下がってゆらゆら揺れる楽しい体験」でした。しかし、発注側の担当者は「上司からシステム化しろと言われたから」「他社もやっていると会議で決まったから」といった理由で要件を固めようとするため、本来不要な座板を何枚も要望してしまうような、目的と手段がねじれた発注をしてしまいます。
発注側が「そもそも自分たちは何に困っていて、何を達成したいのか」という本質的な目的を突き詰めていないことこそが、すべての迷走の始まりとなります。
伝言ゲームによる「実現不能な仕様」と場当たり的な設計・実装
顧客の曖昧な要件を受け取った開発側が、文字通りの解釈と場当たり的なリカバリーを重ねることで、システムが破綻していくプロセスです。
上図の3つのコマは、言葉の伝言ゲームが招く典型的な連鎖を表しています。
- プロジェクトリーダーの理解: 「木の枝に2本のロープを垂らし、間に板を渡す」という顧客の言葉通りに受け止めた結果、ロープが木の幹を挟んでしまい、幹にぶつかって前後に揺れることができない「物理的に実現不可能な仕様」を描いてしまいます。
- アナリストのデザイン: 「幹にぶつかって揺れない」という問題を解決するため、アナリストは木の幹を大胆にくり抜き、木が倒れないように左右を支柱で補強するという奇抜で複雑怪奇な設計を施してしまいます。
- プログラマーのコード: 最終的な仕様書の文面だけを受け取ったプログラマーは、幹に座板を直接ロープで縛り付け、地べたについてしまい1ミリも揺れないプログラムを組んでしまいます。
どの担当者も「指示された仕様の文面」には忠実に従っています。しかし、「ブランコとして揺れて遊ぶ」という本来の目的や完成形のイメージを誰も共有していないため、手戻りや修正を重ねるたびにシステムが複雑怪奇になり、最終的には全く使い物にならない画面が出来上がってしまうのです。
営業トークと現実の実装ギャップ（絵に描いた餅）
次に起きやすいのが、発注前の提案・営業フェーズにおける「過度な期待値の吊り上げ」です。
上図にあるように、営業担当者はコンペに勝って受注を獲得するため、ふかふかのクッションが付いた「豪華なソファ付きブランコ」を約束します。現代のDXで言えば、「このツールを入れればAIがすべての業務を自動判別し、現場の手作業はゼロになります」「誰でもワンクリックで高度なデータ分析ができます」といった過剰なセールストークがこれに当たります。
しかし、実際の開発に入ると技術的な制約や予算の壁に直面し、現場に納品されるのは最低限の機能すら動かない中途半端なシステムになってしまいます。提案時の甘い言葉を鵜呑みにせず、発注側自身が「その機能は自社の実データや業務体制で本当に動くのか」を冷静に見極めるリテラシーが求められます。
コミュニケーション不全と「タイヤのブランコ」への回帰
関係者間の対話が途絶え、仕様変更の繰り返しで設計書も作られず、場当たり的なパッチ当てを繰り返した結果、最終的に木を切り倒してしまうようなプロジェクトの破綻が起きます。
上図の右下が示す通り、顧客が真に求めていたのは、豪華なソファでも幹をくり抜いた複雑な仕掛けでもなく、木に1本のロープとタイヤを吊るしただけのシンプルなブランコでした。
ユーザーの本質的なニーズは「シンプルに木からぶら下がって揺れたい」という体験そのものであり、高価な木製座板や補強支柱ではありませんでした。システム開発を成功させるためには、不要な装飾や過剰な機能を削ぎ落とし、「私たちが真に解決したい現場の課題は何か」という本質に立ち返る勇気が必要です。
伝言ゲームを打破する3つのコミュニケーション実践術
関係者間の「知識の壁」と「伝言ゲーム」を解消するためには、抽象的な言葉だけに頼るコミュニケーションを見直し、具体的な3つの工夫を取り入れることが効果的です。
自分の言葉で言い換えて確認する（解釈のすり合わせ）
相手の言葉をそのままオウム返しに復唱するだけでは、解釈のズレを発見できません。「相手の言っている言葉」と「自分が頭の中でイメージしている概念」が一致しているかを確かめるために、あえて自分の言葉に言い換えて確認する習慣を持ちましょう。
例えば、ベンダーから「ここは非同期処理でバッチ連携します」と言われたら、「つまり、画面上ですぐに反映されるのではなく、夜間に自動でまとめてデータが更新される仕組みという理解で合っていますか？」と確認します。もし解釈が間違っていれば、相手がその場ですぐに訂正してくれます。別の表現で投げ返すことは失礼ではなく、認識齟齬を防ぐための極めて誠実なステップです。
目に見える形（図解・データ・プロトタイプ）で共有する
言葉だけで抽象的な要望を伝えても、各自が頭の中で思い描くイメージには必ずズレが生じます。テキストだけの仕様書や口頭の説明では、どうしても個人の主観による解釈の違いを埋めることができません。
そこで、以下のような「目に見える共通言語」を用いて対話を進めることが推奨されます。
- 業務フロー図: 誰が、どのタイミングで、何を入力し、誰に渡すのかを図解で可視化する。
- データモデル・入出力定義: どんな項目を保存し、画面に何を表示するのかを具体例（ダミーデータ）で明示する。
- 画面モックアップ・プロトタイプ: 本格的な開発に入る前に、紙の手書き画面やFigma、ノーコードツールなどで「動く画面イメージ」を現場に見せる。
実際に操作できるモックアップを早期に提示することで、現場から「このボタンの位置だと入力しづらい」「この項目よりも顧客の電話番号を先に見たい」といった生きたフィードバックを開発初期に引き出すことができます。
「わからないことはわからない」と素直に言う心理的安全性を保つ
プロジェクトの炎上原因として非常に多いのが、会議中に飛び交う専門用語（API、DWH、要件定義書、トランザクション等）の意味が分からないまま、「恥ずかしくて質問できず、分かったふりをして流してしまうこと」です。
わからないことをその場で質問するのは恥ずかしいことではありません。むしろ、曖昧なまま放置して後から仕様変更や手戻りを発生させる方が、プロジェクト全体にとって遥かに大きな損失をもたらします。
特にプロジェクトリーダーや推進担当者は、「自分が他人に分かりやすく説明できるレベルまで腹落ちして理解すること」を徹底しましょう。「初歩的な質問で恐縮ですが、この用語はどういう意味ですか？」「現場の業務に当てはめるとどういう動作になりますか？」と素直に聞ける文化を作ることが、プロジェクトを成功に導く土台となります。
まとめ
ITシステム開発を成功させるために必要なのは、高度なプログラミング技術や最新ツールの選定だけではありません。「4つの関係者が抱える目的意識のズレと知識の壁を理解し、伝言ゲームを排した健全なコミュニケーション構造を作ること」こそが、失敗を防ぐ最大の鍵です。
- 4者の目的意識のズレを受け止める: 経営層・現場・情シス・ベンダーの関心事や優先順位の違いを前提に対話の場を設計する。
- 知識の壁を自覚する: 現場の業務知識とベンダーのIT知識の非対称性を理解し、共通言語を用いたすり合わせを行う。
- 伝言ゲームの罠を防ぐ: 経営ビジョンが形骸化してツール導入ありきにならないよう、目的を常に全員で再確認する。
- タイヤのブランコを目指す: 風刺画の教訓を胸に、曖昧な要件・実現不能な設計・営業の誇張を避け、本質的な課題解決に機能を絞り込む。
- 3つの対話術を実践する: 「自分の言葉での言い換え」「図解・モックアップによる可視化」「わからないと素直に言える安心感」で認識のズレを解消する。
システム開発の失敗要因を理解した上で、自社に最適な「方向設定」を固めたい方は、ぜひ以下の第1弾記事も併せてご覧ください。
【DX人材育成・学習ロードマップ】
全社的な教育設計やご自身の学習計画の参考として、本サイトでは3つの役割に応じた学習ロードマップを公開しています。
経営層・管理職向け
DXの定義や必要性、組織変革を支えるスポンサーシップを最短で学びます。
一般社員向け（DXリテラシー標準 DSS-L準拠）
DXリテラシー標準(DSS-L)に準拠し、デジタル技術の基礎知識や変革マインドを身につけ、身近な業務改善や自社課題の発見へ主体的に関わる土台を作ります。
ビジネスアーキテクト・推進リーダー向け
既存事業の効率化から新規事業の開拓までをリードするため、プロジェクト推進法やチェンジマネジメント手法などを体得します。
コメント