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