「仕様書には書いてあったはずだ」「いや、そんな話は聞いていない」──システム開発の現場で繰り返される「言った言わない」の議論は、発注者と開発者の両方を疲弊させ、プロジェクトを失敗に導きます。本記事では、なぜシステム開発でこの問題が頻繁に起きるのか、典型的なパターンとは何か、そして根本的に防ぐための5つの方法を解説します。
結論：「言った言わない」は人の問題ではなく構造の問題
結論から言えば、システム開発における「言った言わない」は、特定の担当者が悪いわけでも、コミュニケーション能力の問題でもありません。仕様書という文書だけを介して認識を揃えようとする構造そのものに、原理的な限界があります。
「使いやすい画面」「シンプルなUI」「業務に合った機能」といった言葉は、誰もが知っている単語の組み合わせです。しかし、その言葉が指す具体的なイメージは人によって全く異なります。発注者が頭の中で描いている完成像と、開発者が頭の中で描いている完成像は、同じ仕様書を読んでもズレるのが当然なのです。
典型的な「言った言わない」パターン3選
パターン1：曖昧な形容詞の解釈ズレ
最も多いのが「シンプルに」「使いやすく」「直感的に」といった形容詞をめぐる解釈ズレです。発注者は「項目を絞った簡潔な画面」をイメージしていたのに、納品されたのは「機能をすべて1画面に詰め込んだ画面」だった、というケースです。どちらも「シンプル」という解釈は成立しますが、求めていたものは違います。
パターン2：「常識」と思っていた仕様の見落とし
「言うまでもないこと」が仕様書に書かれていないために起きるパターンです。発注者は「請求書発行機能なんだから、過去の請求履歴を見られて当然」と思っていたのに、納品されたシステムには履歴閲覧機能がなかった、というケース。開発者の側は仕様書に書かれていない以上、優先度の判断材料がありません。
パターン3：業務の暗黙ルールが反映されない
「この場合は例外的に手作業で処理する」「あの取引先だけは特別対応している」といった、現場の暗黙ルールが仕様化されないまま開発が進むパターンです。これは発注者自身も意識していないことが多く、システムが完成して実業務に投入してから「あれ、このケースが処理できない」と発覚します。
なぜシステム開発では認識齟齬が起きやすいのか
理由1：完成物が抽象的すぎる
建築物や工業製品と違い、ソフトウェアは触ってみるまで完成像が掴みにくい性質があります。図面や設計書を読み解ける専門家でも、実際に動くものを見るまで具体的な使用感は予測できません。発注者が業務の素人ではなく専門家であっても、システムの完成像までは正確に予測できないのが普通です。
理由2：発注者と開発者の語彙が違う
業務側の言葉（「与信」「与信枠」「掛け」「掛け払い」など）と、技術側の言葉（「テーブル」「ステータス」「トランザクション」など）は、同じ業務を指していても異なる粒度・異なる切り口で語られます。両者が翻訳されないまま会話が進むと、表面的には合意したように見えて、中身は別物になります。
理由3：時間が経つと前提が忘れられる
開発期間が長くなるほど、初期に決めた前提条件が記憶から薄れます。「あのとき、こういう議論をしてこう決めたはず」が後になって思い出せなくなり、議事録を見ても文脈が再現できないため、結果として「言った言わない」が発生します。
認識齟齬を防ぐ5つの方法
方法1：動くプロトタイプを早期に作る
最も効果的な方法は、仕様書ではなく動くプロトタイプで認識を合わせることです。実際に画面を操作してデータを入力してみれば、「ここは違う」「これが必要だった」がすぐに分かります。AI を活用した開発手法の登場により、プロトタイプを1〜2週間で用意することが現実的になりました。
方法2：業務フローを図解する
文章ではなく、業務の流れを図にして共有することで、暗黙の例外処理が見える化されます。「通常はこのフローで進むが、Aの場合だけは別ルート」「Bの取引先は特別対応」といった例外が、図にすると一目で分かります。発注者自身も自分の業務を見直す機会になります。
方法3：形容詞ではなく具体例で語る
「シンプルに」と言う代わりに「メルカリの出品画面のように」「Slack のサイドバーのように」と具体例で語ります。実在するシステムを参照すれば、双方が同じイメージを共有できる確率が上がります。「使いやすい」も「3クリック以内で目的の画面に着けるように」のような測定可能な表現に置き換えます。
方法4：意思決定を議事録ではなく動くものに残す
議事録は時間が経つと文脈が消えます。「あの議論の結果こう決まった」を残すには、プロトタイプや画面遷移図といった「動くもの」「見えるもの」に意思決定を反映させていく方が、後から見返しても意図が伝わります。
方法5：契約のタイミングを後ろにずらす
仕様書ベースで契約を結ぶと、その後の認識齟齬の発覚はすべて「追加費用」のリスクになります。これを構造的に避けるには、プロトタイプを確認してから契約するという順序にすることです。情報量が揃った時点で契約することで、不要な追加費用とトラブルを避けられます。
根本解決としての「並走型システム開発」
上記5つの方法のうち、特に「方法1：動くプロトタイプ」と「方法5：契約タイミング」を構造的に組み込んだ開発手法が「並走型システム開発」です。並走型開発では、発注者は契約前に動くプロトタイプを実際に触って確認できるため、認識齟齬を構造的に解消できます。
並走型開発について詳しくは、関連記事をご参照ください。
関連記事：「並走型システム開発」とは？発注前に動くプロトタイプを見られる開発手法を徹底解説
関連記事：「初期費用0円のシステム開発」は本当に得なのか？仕組みと条件を正直に解説
よくある質問
Q. 仕様書をしっかり作れば認識齟齬は防げますか？
仕様書の質を上げることで認識齟齬は減らせますが、完全にはなくせません。文書という手段自体に「読み手による解釈の幅」が必ず残ります。動くプロトタイプを併用することで、この解釈の幅を大幅に狭められます。
Q. 開発が進んでから「言った言わない」になった場合、どう対処すべきですか？
発覚した時点で過去の議論を蒸し返すよりも、これから何を作るかを再合意することに集中するのが建設的です。プロトタイプを作って双方の認識を可視化し、追加費用や納期影響を含めて合意し直すのが現実的です。可能であれば、次回以降のプロジェクトではプロトタイプを契約前に作る方式へ切り替えることをお勧めします。
Q. プロトタイプを作るにも費用がかかるのではないですか？
従来は確かにプロトタイプ作成自体に数十万〜数百万円かかっていました。しかし、近年の AI 活用により、プロトタイプ作成のコストは大幅に下がっています。開発側がプロトタイプ作成コストを負担できる「初期費用0円」のサービスも登場しており、発注者は無料でプロトタイプを確認してから契約判断できるようになっています。
Q. 既存のベンダーと「言った言わない」が頻発しています。乗り換えるべきですか？
必ずしも乗り換えが正解とは限りません。ベンダーを変えても、開発手法そのものが従来型のままであれば同じ問題が再発する可能性があります。乗り換えを検討するなら、「プロトタイプを契約前に確認できる」「稼働後の改善対応が月額に含まれる」といった、構造的に認識齟齬を防ぐ仕組みを持つ開発手法を提供しているかを基準にすることをお勧めします。
まとめ：「言った言わない」を構造的に防ぐ
本記事の要点を整理します。
- システム開発の「言った言わない」は人の問題ではなく、仕様書という文書だけで認識を揃えようとする構造の問題
- 典型パターンは「曖昧な形容詞の解釈ズレ」「常識と思っていた仕様の見落とし」「業務の暗黙ルールが反映されない」の3つ
- 防ぐための5つの方法は「動くプロトタイプ」「業務フロー図解」「具体例で語る」「動くものに意思決定を残す」「契約タイミングを後ろにずらす」
- これらを構造的に組み込んだ開発手法が「並走型システム開発」
「言った言わない」で疲弊するシステム開発から脱却するには、個々の担当者の努力に頼るのではなく、認識齟齬が起きにくい開発手法そのものを選ぶことが本質的な解決策となります。
関連記事：「使われないシステム」を作らないために発注者が確認すべき7つのチェックポイント
関連記事：システム開発で実際にあった3つの失敗ストーリー｜契約構造で防げた共通の原因
無料相談のご案内
過去のシステム開発で「言った言わない」を経験した経営者・担当者の方からのご相談を多くいただいています。並走型システム開発が御社の業務にどう適用できるか、30分のオンライン無料相談でお話しできます。
毎月2社限定の受付となっておりますので、お早めにご相談ください。