システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせ

システム開発の「認識のズレ」は、担当者の能力や熱意の問題というより、言葉や書類だけで「何を作るか」を決めようとする進め方から生まれやすいものです。この記事では、ズレが起きる仕組みを整理したうえで、実物（動くもの）を見ながらすり合わせることで「作ってみたら違った」を防ぐ考え方を説明します。あわせて、発注する側が自分たちで実践できる手順と、注意点もまとめます。

「作ってみたら違った」はなぜ起きるのか

システム開発を外注したあと、完成したものを見て「思っていたものと違う」と感じた経験は、珍しいものではありません。誰かが手を抜いたわけでも、悪意があったわけでもないのに起きるところが、この問題の難しさです。

私たちは、原因を大きく3つに分けて考えています。

同じ言葉でも、頭の中の絵は人によって違う

たとえば「会員がかんたんに申し込めるようにしたい」という要望があるとします。発注側は「3分以内に終わる、スマホ中心の入力」を思い浮かべているかもしれません。開発側は「入力項目は多いが、画面は1ページにまとまっている状態」を想像しているかもしれません。どちらも「かんたん」という言葉には合っています。

このように、言葉は共通していても、具体的な画面や操作のイメージまでは共有できていないことが多くあります。打ち合わせでお互いにうなずいていても、頭の中の絵が違うまま進んでしまうのです。

文書にする段階で、抜け漏れや食い違いが入り込む

システム開発では、必要な機能や条件を整理して文書にする「要件定義」という工程があります。要件定義書は、開発の土台になる大切な資料です。

ただし、文書は読む人の解釈に左右されます。さらに、次のような点は、使ってみて初めて気づくことが多く、文書の段階では想像しにくいものです。

• 入力の手間が思ったより多い
• ボタンの位置や名前が、使う人の感覚とずれている
• エラーが出たときの動きが分かりにくい
• 画面を行き来する回数が多く、流れがつかみにくい

「使ってみて分かる『これじゃない』」は、文書のレビューだけでは拾いきれません。

新規事業では、正解が作る前に分からない

既存の業務を置き換えるシステムであれば、現行のやり方を手本にできます。一方、新規事業のシステムには、手本がありません。利用者がどう使うか、どの機能が価値になるかは、作って見せてみないと分からない部分が大きいのです。

それにもかかわらず、費用や仕様を先に固めてしまうと、あとから違いに気づいても変更しにくくなります。「仕様を決めてから作る」という順番そのものが、新規事業とは相性がよくない場合があります。

認識のズレが起きやすい4つのポイント

ズレは、開発のあらゆる場面で起きます。特に起きやすい場所を知っておくと、すり合わせの場で確認する観点が明確になります。

1. 画面と操作

もっとも分かりやすいのが、画面の見た目や操作の流れです。レイアウト、項目の並び順、ボタンの配置、入力のしかたなど、細かな違いが積み重なって「使いにくい」という印象につながります。

2. 利用者と利用場面

「誰が」「どこで」「どんな状況で」使うのかが違えば、適した設計も変わります。たとえば、外出先でスマホから使う人と、事務所のパソコンで腰を据えて使う人とでは、必要な画面がまったく異なります。利用者の想定が人によって違うまま進むと、完成後に大きなずれが見つかります。

3. 事業としての判断基準

新規事業では、経営陣（決裁者）と現場（立案者）のあいだで、判断の材料や進める速度が違うことがあります。両者とも「事業を成功させたい」という目的は同じなのに、決裁者は「投資に見合うか」を見たがり、現場は「まず動かして確かめたい」と考える、といった具合です。

私たちは、このときズレているのは目的ではなく進め方だと考えています。判断に使う材料が企画書だけだと、現場の頭にある構想が決裁者に十分伝わらず、話が噛み合わなくなります。

4. 優先順位と範囲

「最初に何を作るか」「どこまで作るか」も、ズレやすいポイントです。要望が増えるほど、どれが本当に必要なのかが見えにくくなります。あれもこれもと盛り込むと、事業の核になる機能の検証が後回しになることもあります。

実物を見ながらすり合わせるとはどういうことか

ズレを防ぐ有効な方法のひとつが、完成前に「実際に動くもの」を見ながら話し合うことです。ここでいう実物とは、プロトタイプ（試作品）のことです。本番で使う機能の一部を、実際に触れる形で先に作ったものを指します。

紙の画面案との違い

画面のイメージ図（ワイヤーフレームなど）も、すり合わせには役立ちます。ただし、静止画は「動き」を伝えられません。プロトタイプは、次のような点を実際に体験できます。

• ボタンを押したときに何が起きるか
• 画面から画面へ、どう移動するか
• 入力したデータがどう扱われるか
• 操作にどれくらい手間がかかるか

「ここはこう動いてほしい」と、触りながらその場で指摘できるのが大きな違いです。

実物があると、何が変わるのか

実物を見ながら進めると、次のような変化が期待できます。

• 言葉の解釈の違いが、早く表に出る：「かんたん」の中身が、実際の操作を通して確認できます。
• 「これじゃない」を早い段階で直せる：使ってみて分かる違和感を、作り込む前に修正できます。
• 企画書で伝わりにくい「何ができるのか」を示せる：決裁者と現場が、同じものを見て話せます。
• 契約するかどうかの判断を、実物を見てから行える：費用や仕様を先に固めてしまうことによる失敗を避けやすくなります。

なお、実物は「一発で正解を当てるためのもの」ではありません。「違いを早く見つけるためのもの」と捉えるのが適切です。違いが見つかること自体が、すり合わせが機能している証拠です。

実物ですり合わせる進め方｜発注側でできる5つの手順

実物を見る場を設けても、進め方が曖昧だと、感想を言い合うだけで終わってしまいます。発注する側で準備できる手順を整理します。

手順1：目的と判断基準を一文にする

最初に、「このシステムで何を確かめたいのか」「何が分かれば次に進むと判断できるのか」を一文で書き出します。

例：「利用者が、説明なしで最後まで申し込めるかを確かめたい」

この一文があると、実物を見たときに「目的に合っているか」という軸で評価できます。決裁者と現場の間で、判断基準をそろえる効果もあります。

手順2：最初に作る範囲を絞る

すべての機能を作ろうとせず、事業の核になる部分に絞ります。新規事業であれば、「この機能がなければ事業として成立しない」というものが、最初に見るべき範囲です。周辺の機能は、あとから追加する前提にします。

範囲を絞るほど、確認する項目が明確になり、すり合わせの密度も上がります。

手順3：触る場に、使う人と決める人の両方を呼ぶ

実物を見る場には、実際に使う人と、最終的に判断する人の両方が参加できるようにします。どちらかだけが見ると、あとで「聞いていない」「思っていたものと違う」という食い違いが再発しやすくなります。

可能であれば、画面を見せられるだけでなく、参加者自身が操作する時間をとります。見ているだけのときより、操作したときのほうが気づきは多くなります。

手順4：指摘を記録し、種類で分ける

その場で出た意見は、すべて記録します。そのうえで、次のような種類に分けると、対応の優先度を決めやすくなります。

種類	内容の例
操作・見た目の違和感	ボタンの位置が分かりにくい、文言が伝わらない
事業上の前提の違い	想定していた利用者や流れが、実際とは異なっていた
抜けていた機能	使ってみて、必要だと気づいた機能がある
新しい要望	今回の目的には含めず、あとで検討したいこと

特に「事業上の前提の違い」は、システムの作り直しにつながる可能性があるため、早い段階で見つかることに大きな価値があります。

手順5：次に作るものを決める

記録した指摘をもとに、「今回直すこと」「次に作ること」「いまは見送ること」を決めます。ここで判断基準になるのが、手順1で書いた一文です。目的から外れる要望は、無理に取り込まず、あとで検討する項目として残します。

実物ですり合わせるときの注意点

実物を使った進め方にも、気をつけたい点があります。

見た目の完成度に惑わされない

動くものを見ると、「ほぼ完成している」と感じやすくなります。しかし、プロトタイプは検証のためのものであり、本番運用に必要なすべての要素が備わっているとは限りません。たとえば、セキュリティ、大量のアクセスへの対応、運用時の保守体制などは、別途確認が必要です。「どこまでが検証済みで、どこからが未確認か」を、開発側に確認しておきましょう。

範囲を広げすぎない

実物を見ると、「これもあったらいいのでは」という要望が次々と出てきます。すべて取り込むと、範囲が膨らみ、何を確かめるためのものだったのか分からなくなります。手順1の一文に立ち戻り、目的に関係するものだけを優先しましょう。

好みと事業要件を切り分ける

「この色が好きではない」という意見と、「利用者がこの画面で迷う」という指摘は、重みが違います。前者は個人の好みである場合があり、後者は事業の成否に関わる場合があります。意見が出たときは、「それは利用者にとっての課題か、個人の好みか」を確認する習慣をつけると、判断がぶれにくくなります。

契約や責任範囲の確認は別に行う

実物を見て内容に納得できても、契約の条件、権利の帰属、納品物の範囲、保守の範囲などは、文書で確認する必要があります。実物でのすり合わせは、仕様の認識を合わせるための手段であり、契約上の取り決めを代替するものではありません。

発注先を選ぶときに確認したいこと

ここまでの内容を、開発会社を選ぶときの観点に置き換えると、次のような質問が役に立ちます。

• 契約や本格的な開発の前に、動くものを見せてもらえるか
• 実物を見せてもらえる時期は、いつ頃か
• 実物を見たあとで、内容を変更したい場合はどう扱われるか
• 指摘や要望は、どのように記録・共有されるか
• 仕様が固まっていない段階でも、相談に応じてもらえるか
• 決裁者向けの説明や、稟議に使える材料づくりにも協力してもらえるか

これらを事前に確認しておくと、「進め方の違い」によるトラブルを減らしやすくなります。開発の全体像や各段階での判断ポイントは、新規事業のシステム開発の進め方｜構想から運用までの全体像でも整理しています。

なお、AIモデルの進化が新規事業に与える影響については、Claude Sonnet 5.5の発表と新規事業への影響で取り上げています。開発のやり方を考えるうえでの参考として、あわせてご覧ください。

まとめ

「作ってみたら違った」は、担当者の力量の問題ではなく、言葉や文書だけで「何を作るか」を決める進め方から起こりやすい現象です。この記事のポイントを振り返ります。

• 認識のズレは、言葉の解釈、文書化の過程、新規事業ならではの「正解の分からなさ」から生まれる
• ズレは、画面と操作、利用者と場面、事業の判断基準、優先順位と範囲で特に起きやすい
• 実物（プロトタイプ）を見ながらすり合わせると、使ってみて分かる「これじゃない」を早い段階で直せる
• 進めるときは、目的を一文にし、範囲を絞り、使う人と決める人が一緒に触り、指摘を種類で分けて記録する
• 実物の完成度に惑わされず、契約や責任範囲の確認は別に行う

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、「先に作って、後から決める（PROTOTYPE FIRST）」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発しています。実物を見てから契約するかを判断できるため、仕様が固まっていない段階や、稟議を通す前の段階でも相談いただけます。進め方の詳細はJustFitのサービス紹介をご覧ください。