何度も打ち合わせをして、要件定義書も承認したのに、納品されてみたら「思っていたのと違う」——システム開発の現場で最もよく聞く悲しいフレーズです。発注側は「ちゃんと伝えた」、ベンダー側は「言われた通りに作った」と双方が主張し合い、責任の所在がはっきりしないまま追加費用の請求が始まります。本記事では「思っていたのと違う」が起こる根本原因を、認識ズレ・期待値ズレ・想像の解像度ズレの3観点で整理し、経営者が発注前から使える対策をお伝えします。
この記事の結論（3行）
- 「思っていたのと違う」は「言葉の認識ズレ」「期待値ズレ」「想像の解像度ズレ」の3要素から生まれる
- 文章ベースの要件定義書では3つのズレを埋めきれない。画面モック・プロトタイプ・動作デモが必須
- 経営者は「見て触って判断する」プロセスを発注時から組み込むことで、リリース後の絶望を防げる
なぜ何度打ち合わせをしても「思っていたのと違う」が起こるのか
「思っていたのと違う」は、発注側もベンダー側も悪意なく真面目に取り組んだ結果として起こる現象です。複数回の打ち合わせを重ね、要件定義書もきちんと作成したのに、納品物を見ると違和感が拭えない。この構造には、人間の認知の限界が深く関係しています。
- 同じ言葉でも、人によってイメージするものが違う
- 「動いている姿」を見るまで、本当の評価ができない
- 業務の経験値が違うと、「当たり前」の前提が違う
この3つは、どれだけ優秀なベンダーでも避けられない人間の認知特性です。「言葉の打ち合わせ」だけで完璧に仕様を伝えるのは原理的に不可能で、見て触って評価するプロセスを設計に組み込まなければ、ズレは必ず残ります。
同じ言葉でも、人によってイメージするものが違う
「使いやすいUI」「シンプルな画面」「分かりやすい操作」——こうした言葉は、人によってイメージするものが大きく異なります。発注側は「Excelのような自由度の高い画面」をイメージし、ベンダーは「項目を絞ったフォーム型の画面」をイメージしている、というズレが頻発します。言葉は同じでも、頭の中に浮かぶ画像が違う状態で打ち合わせが進むと、最終納品物で初めてズレが発覚します。
「動いている姿」を見るまで、本当の評価ができない
人間は、文章で書かれた仕様だけで「使い心地」を評価できません。「商品検索画面で絞り込み機能がある」と書かれていても、実際に動く画面で操作してみないと「これでは絞り込みに時間がかかる」と気づけません。要件定義書を読んで承認した時点では問題なく感じても、動くものを触って初めて違和感が表面化します。
業務の経験値が違うと、「当たり前」の前提が違う
発注側は自社の業務に長年携わっているため、「言わなくても分かるはず」の前提が大量にあります。一方ベンダーは業界の初心者なので、それらの前提を一切持っていません。「請求書には必ず取引先の担当者名を入れる」「在庫表は色分けで状態を表示する」など、発注側にとって当たり前のことを言語化しないと、ベンダーには伝わりません。
「思っていたのと違う」を生む3つの根本原因
「思っていたのと違う」の根本原因を、3つに分類して整理します。それぞれに対応する防止策があります。
| 根本原因 | 具体的な症状 | 防止策 | |---|---|---| | 言葉の認識ズレ | 「使いやすい」「シンプル」など抽象語の解釈違い | 画面モックで視覚的に共有 | | 期待値ズレ | 「これくらいの精度・速度は当然」の前提違い | 数値基準で要件を明文化 | | 想像の解像度ズレ | 「業務の当たり前」が伝わっていない | プロトタイプで業務シナリオを試す |
3つの根本原因は独立しており、それぞれに対応する手段を打たないと埋まりません。3つを同時に防ぐ汎用的な方法は存在せず、それぞれに対応するプロセスを組み込む必要があります。自社の発注フローで3つのズレを防げる状態かを整理したい場合は、業務改善・システム見積もりAI適正診断で確認できます。
根本原因1: 言葉の認識ズレ
「使いやすい」「シンプル」「直感的」など抽象的な言葉が要件定義書に並んでいる場合、認識ズレが起きます。これらの言葉は人によって解釈が大きく違うため、文章のままでは防げません。防ぐには、画面モック（手書きでも構いません）を要件定義書に必ず添付してもらってください。視覚的なイメージを共有することで、抽象語の解釈ズレが大幅に減ります。例として、発注側が「シンプルな検索画面」を希望していたとして、ベンダーが提示するモックが「検索ボックス1つだけの画面」だった場合、発注側が想定していた「絞り込み条件を5〜10個並べた検索フォーム」とのズレがその場で発覚できます。モックがあれば30分の打ち合わせで埋められるズレが、なければリリース後の改修案件になります。
根本原因2: 期待値ズレ
「このくらいの速度なら当然」「このくらいの精度はあるはず」という暗黙の期待値が、発注側とベンダーで違うパターンです。発注側は「検索結果は1秒以内に出る」と思っていても、ベンダーは「3秒程度で出れば十分」と考えていることがあります。防ぐには、性能要件・精度要件を数値で明文化してください。「検索結果は1秒以内」「同時アクセス50ユーザーまで」「データ移行精度99%以上」のように、検証可能な数値で書くのが要点です。
根本原因3: 想像の解像度ズレ
業務の経験値が違うため、「当たり前」の前提が伝わっていないパターンです。発注側にとっては「言うまでもないこと」が、ベンダーには「初めて聞く話」だったりします。防ぐには、プロトタイプを使って業務シナリオを試すプロセスを組み込んでください。「月初の請求書発行業務を1〜30日まで実際にやってみる」のように、実際の業務シナリオでプロトタイプを動かすと、想像できていなかった抜けが表面化します。業務シナリオの数は5〜10件あれば十分で、それぞれの操作手順を1ステップずつプロトタイプ上で再現していくと、文章ベースでは想像できなかったズレが見えてきます。
経営者目線で考える「イメージ合わせ」のコスト
ここからは経営の話です。「思っていたのと違う」を防ぐためのイメージ合わせには、相応のコストと時間がかかります。画面モック作成・プロトタイプ開発・業務シナリオ検証——これらは要件定義の延長として0.5〜1人月の追加工数が乗ります。中規模システムなら追加で50〜100万円の費用と1〜2ヶ月の追加期間が必要です。
このコストを「無駄」と感じる経営者は少なくありません。「ちゃんと打ち合わせすれば十分でしょう」と判断し、イメージ合わせの工程を省略してしまいます。しかし、これを省略してリリース後に「思っていたのと違う」が発覚すると、改修費用として200〜500万円が乗ってきます。前工程の50〜100万円を惜しんで、後工程で200〜500万円を払う構造になってしまうわけです。
経営判断としては、「予防コスト50〜100万円」と「リカバリーコスト200〜500万円+業務影響」を天秤にかけ、予防に寄せる方が合理的です。さらに重要なのは、リリース後の改修には現場の業務影響と、経営者の精神的負担が乗ってくる点です。これらを定量化すると、予防の優位性はさらに大きくなります。
ぷらすわんの実例：プロトタイプ重視の開発スタイル
ぷらすわんでは、案件のサイズに関係なく「プロトタイプを早めに触ってもらう」スタイルを徹底しています。ある製造業A社のケースでは、生産管理システムの発注時に要件定義と並行してプロトタイプを2週間で組み、業務担当者に実際の業務シナリオで触ってもらうプロセスを入れました。
このプロトタイプ検証の段階で、「製品コードの体系が要件定義書とは違う」「不良品の登録フローが現場のやり方と逆」「現場で使う略号が要件に入っていない」など、文章ベースでは気づけなかった違和感が10件以上洗い出されました。これらを開発前に修正できたため、リリース後の改修依頼はゼロで、当初予算の範囲内で稼働させられました。
中小企業の現場でも、プロトタイプ検証の工程は省かないことを強くお勧めします。プロトタイプ作成に追加で50〜100万円かかったとしても、リリース後の改修費を考えれば確実に元が取れます。発注前にプロトタイプ検証の工程を項目別に整理したい場合は、現状を整理してから比較するのが現実的です。
「思っていたのと違う」を防ぐ5つの実践ステップ
「思っていたのと違う」を防ぐための、発注時から検収までの5つの実践ステップを整理します。
- 要件定義書に全画面の手書きモックを添付してもらう
- 性能・精度要件を必ず数値で明文化する
- 開発前にプロトタイプで業務シナリオを試す
- 開発中に2週間ごとに動作デモを見せてもらう
- 検収前に1ヶ月の試用期間を設ける
この5つは、発注前から検収までの全工程に分散して配置するのが効きます。1つの工程だけ強化しても3つのズレを完全には埋められないため、5つを通しで実施してください。
要件定義書に全画面の手書きモックを添付してもらう
要件定義の段階で、全画面の手書きモック（または簡易ワイヤーフレーム）を要件定義書に添付してもらってください。視覚的なイメージがあることで、言葉の認識ズレが大きく減ります。手書きで構わないため、コストはほぼかかりません。
性能・精度要件を必ず数値で明文化する
「速い」「正確」「安定」などの抽象語ではなく、「検索1秒以内」「精度99%以上」「同時50ユーザー対応」のように数値で明文化してください。これにより期待値ズレが防げます。検収時にも数値基準で判定できるため、揉め事も起きにくくなります。
開発前にプロトタイプで業務シナリオを試す
要件定義後、本格開発の前にプロトタイプ（簡易動作版）を作ってもらい、業務担当者に実際の業務シナリオで触ってもらってください。文章では気づけない「想像の解像度ズレ」がここで表面化します。プロトタイプ作成に追加で50〜100万円かかりますが、後の改修費を考えれば必ず元が取れます。プロトタイプは「全機能の3〜5割が動く版」で十分で、最も使う機能から優先的に動かしてもらうのが効率的です。業務担当者が触れる時間を1日確保しておくと、抜け漏れの発見数が大きく変わります。
開発中に2週間ごとに動作デモを見せてもらう
開発が始まったら、2週間ごとに動作デモを見せてもらうリズムを作ってください。月1回では遅すぎます。早期に違和感を発見し、軌道修正を入れることで、リリース直前の大規模な作り直しを防げます。
検収前に1ヶ月の試用期間を設ける
検収の前に、業務担当者が実際に1ヶ月使ってみる試用期間を設けてください。1〜2日のテストでは発見できない問題が、1ヶ月使うと必ず表面化します。試用期間中の改修は契約の範囲内に含めるよう、発注時に明記しておくとスムーズです。月初・月中・月末で業務サイクルが大きく変わる中小企業の場合、1ヶ月の試用期間が確保できれば月次サイクルの全てを試せるため、本稼働後のトラブル発生率を大きく下げられます。検収前の試用期間を契約条件に含める案について、他社と比較を依頼する場合も、この観点で比較してください。
まとめ
「思っていたのと違う」は、「言葉の認識ズレ」「期待値ズレ」「想像の解像度ズレ」の3つの根本原因から生まれます。これらは文章ベースの要件定義書では埋めきれないため、画面モック・プロトタイプ・動作デモという視覚的・体験的なプロセスを発注フローに組み込むことが必要です。
予防コストとして50〜100万円が乗りますが、リカバリーコスト200〜500万円と業務影響を考えれば、予防に寄せる方が合理的です。発注前の段階で、自社のイメージ合わせプロセスを診断することで、「思っていたのと違う」のリスクを未然に最小化できます。