納品直前に訪れる「こんなはずじゃなかった」
システム開発において、発注者と開発者の間で最も頻繁に起こり、かつ深刻なトラブルになるのが、「思ったのと違う（認識のズレ）」という問題です。
数ヶ月かけて要件定義を行い、分厚い仕様書にハンコを押し、定例会議でも「順調です」と報告を受けていた。それなのに、いざ納品されたシステムを触ってみると、「画面の動きがイメージと違う」「現場の業務フローでは使いにくい」という不満が噴出する。
なぜ、プロ同士が話し合ったにもかかわらず、このような悲劇が起こるのでしょうか。 その原因は、コミュニケーションの不足ではなく、「合意形成の手段」にあります。
言葉と静止画には限界がある
なぜ「思ったのと違う」が起こるのか。その根本的な理由は、「人間は、動くものを触ってみるまで、自分が何を欲しかったのか分からない」という認知の特性にあります。
言葉だけでの説明では伝わらない
「使いやすい画面」「直感的な操作」といった言葉の定義は、人によって全く異なります。言葉だけで仕様を詰めようとすると、お互いが自分の都合の良いように解釈してしまい、ズレが生じやすくなります。
完成してから初めて触るリスク
多くのプロジェクトでは、画面デザイン（静止画）で合意形成を行います。しかし、綺麗なデザイン画を見せられても、人は「なんとなく良さそう」としか判断できません。 実際にボタンを押し、画面が切り替わる動き（インタラクション）を体験して初めて、「この遷移は面倒だ」「ここに入力欄がないと困る」という具体的なフィードバックが生まれます。
フィードバックのタイミングが遅い
完成直前になって初めて「動くもの」を確認し、そこで大量の要望が出てきても、エンジニアからすれば「今さら言われても困る」状態です。結果として、修正に追加費用がかかるか、使いにくいシステムを我慢して使うかの二択を迫られます。
「動くもの」で合意する3つのステップ
この「認識のズレ」を解消する唯一の方法は、開発プロセスの早い段階で「動くもの」を触ることです。以下の3つのステップで進めましょう。
ステップ1：動くプロトタイプで早期に確認
開発フェーズが始まったら、本格的なプログラムを書く前に、まずは「動くプロトタイプ（試作品）」を作成してもらってください。開発側はFigma MakeやBolt、Lovableといった生成AIツールを使えば、プロンプトによる指示だけで動作するプロトタイプを短期間で作成できます。これを開発側から見せてもらいながら、「業務の流れに合っているか」「必要なデータが入力できそうか」を、開発の初期段階（最初の1〜4週間）で検証します。この段階での修正なら、コストはほとんどかかりません。
ステップ2：週次デモで継続的にフィードバック
1〜2週間ごとの定例会議では、進捗報告書の読み合わせだけでなく、「前回から今日までに作った動く機能」の実演デモを開発側にしてもらいましょう。「ログイン機能ができました」「商品登録画面が動くようになりました」と、小さく作って小まめに確認することで、認識のズレをその場で修正できます。 エンジニアは未完成品を見せるのを嫌がる傾向がありますが、「品質チェックではなく、認識合わせのためだ」と伝えて見せてもらうことが重要です。
ステップ3：段階的に機能を追加
最初から全ての機能を完璧に作ろうとしないでください。まずは「これがないと業務が回らない」という核となる機能（MVP）だけを作り、ユーザーに使ってもらいます。そこで得られた「やっぱりこの機能も欲しい」「ここは不要だった」というリアルな反応をもとに、段階的に機能を追加・修正していきます。 システムは一度作って終わりではなく、使いながら育てていくものです。
具体例：デザイン画の罠とプロトタイプの成功
失敗ケース：静止画のデザインで合意してしまった
ある卸売業で、顧客管理システムの開発を進めていました。開発会社はワイヤーフレーム（画面の設計図）を見せてくれて、発注者は「問題なさそう」と承認しました。しかし完成品を現場の営業担当者が触ると、次の問題が発覚しました。
- 顧客を検索して詳細画面に入り、一覧に戻ると検索条件がリセットされる。1日に100件さばく担当者は「検索 → 詳細 → 戻る → 再検索」を繰り返すうちに手が止まった
- 注文入力画面で商品を10件追加した後、1件目を修正すると画面が先頭にスクロールしてしまい、どこまで確認したか見失う
どちらも静止画のデザインでは気づけない「動きの問題」でした。動くプロトタイプを早い段階で触っていれば、要件定義で「一覧の検索条件を保持する」「修正後もスクロール位置を維持する」と明文化できたはずです。
成功ケース：プロトタイプで「動きの不自然さ」に気づいた
一方、別の卸売業のプロジェクトでは、開発初期に簡易的なプロトタイプを作成しました。営業担当者に触ってもらったところ、「一覧に戻るたびに検索条件が消えて毎回入力し直すのがつらい」「商品を10件追加した後に1件目を修正すると、上までスクロールされて面倒」といった具体的なフィードバックが即座に出ました。その結果、一覧の検索条件を保持する仕様、修正後もスクロール位置を維持する仕様に早期に変更。手戻りを防ぎ、現場に歓迎されるシステムが完成しました。
まとめ
システム開発で「思ったのと違う」を防ぐポイントは以下の通りです。
• 言葉や静止画のデザインだけで合意しない。
• 開発初期に「動くプロトタイプ」を作成し、現場の利用シーンで検証する。
• 定例会議を「報告会」ではなく「デモ体験会」にし、継続的にフィードバックする。
• 最初から完成形を目指さず、重要な機能から段階的に作る。
「百聞は一見にしかず」と言いますが、システム開発においては「百見は一触（いっしょく）にしかず」です。まずは触れるものを作ることから始めましょう。
ゼロスタートなら、初期費用0円で動くプロトタイプを確認できます。本格的な開発契約を結ぶ前に、認識のズレがないかリスクなしで検証することが可能です。
--------------------------------------------------------------------------------
FAQ
Q1. プロトタイプを作るのに追加費用はかかりますか？
A. 一般的には費用がかかりますが、手戻りによる修正コストに比べれば安価です。また、ゼロスタートのようなサービスを使えば、初期費用0円でプロトタイプ作成から始めることも可能です。
Q2. 現場のスタッフに見せると混乱しませんか？
A. 「これは完成品ではなく、使い勝手を確認するための模型です」と事前に説明すれば大丈夫です。むしろ、自分たちの意見が反映される過程を見せることで、導入時の協力が得やすくなります。
Q3. エンジニアが「まだ見せられる状態じゃない」とデモを拒否します。
A. 「完成度は求めていません。方向性が合っているか確認したいだけです」と伝えてください。それでも拒否される場合は、開発体制自体に問題がある可能性があります。