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