開発請負の仕事をしていると、技術的に難しい案件以上に、認識合わせが難しい案件に出会うことがあります。
特に難しいのは、依頼者側では「伝わっているはず」と思っていても、開発者側から見ると、仕様としてはまだ決まっていない状態になっているケースです。
たとえば、次のような表現です。
- 普通はこうすると思っていた
- いつもの形で処理してくれると思っていた
- そこまで説明しなくても分かると思っていた
- いい感じに自動で判断してほしかった
ただし、これは依頼者だけの問題ではありません。人間であれば誰でも、自分にとって当たり前のことを、相手も知っている前提で話してしまうことがあります。
この記事では、開発請負や要件定義の現場で起きる「認識ズレ」について、実務と認知バイアスの観点から整理します。
「普通」「いい感じ」は仕様にならない
業務の中では「普通に」「いつもの感じで」「現場が使いやすいように」という言い方は自然です。
しかし、開発仕様として見ると、これらはまだ未定義です。
たとえば、重複データがある場合だけでも、次のような処理が考えられます。
- 最新データを使う
- 一番上のデータを使う
- エラーとして止める
- 複数候補として表示する
- 手動確認に回す
どれも実装としてはあり得ます。つまり、「普通に処理してください」だけでは、プログラムがどの条件でどう動けばよいのかは決まりません。
説明不足よりも「説明したつもり」が危険
最初から完璧に仕様を説明できる依頼者は多くありません。説明が足りないこと自体は、開発請負では自然に起こります。
問題になりやすいのは、説明していないことに気づかないまま、「相手には伝わっているはず」と思ってしまう状態です。
この状態では、開発者が確認質問をしても、次のように受け取られることがあります。
- そんなことまで聞くのか
- 普通に考えれば分かるだろう
- 細かい確認が多くて面倒
しかし、プログラムは曖昧なままでは動きません。未入力、重複、例外、上書き、追記、エラー表示、警告表示など、どの条件でどう処理するかを決める必要があります。
認識ズレはなぜ起きるのか
認識ズレは、相手の悪意や性格だけで説明できるものではありません。人間に起こりやすい認知のクセとして見ると、対応策を考えやすくなります。
ここでは、実務で特に関係しやすい4つの要因を整理します。
偽の合意効果
偽の合意効果とは、自分の考え方や判断が、実際以上に他人にも共有されていると考えやすい傾向です。
開発現場では、次のような形で現れます。
- 自社では当たり前だから、相手も分かると思う
- この業界では普通だから、説明しなくてもよいと思う
- 自分が自然だと思う処理を、相手も自然だと感じると思う
しかし、外部の開発者は、その会社の業務ルールや暗黙知を共有していません。依頼者の中では一つに決まっていても、開発者から見ると複数の解釈があり得ます。
知識の呪い
知識の呪いとは、知っている人ほど、知らない人の視点に戻りにくくなる現象です。
依頼者は、自社の業務を毎日見ています。そのため、本人にとっては当たり前すぎて、説明する必要がある情報だと気づきにくいことがあります。
一方で、開発者はその現場を見ていません。社内用語、業務フロー、例外条件、現場判断の基準は、言葉にしてもらわない限り分かりません。
説明深度の錯覚
説明深度の錯覚とは、人は複雑な仕組みについて、実際よりも深く理解していると思い込みやすい現象です。
業務を毎日行っていると、「自分はこの業務を理解している」と感じます。しかし、開発仕様として落とし込むには、入力、出力、条件分岐、例外処理、優先順位まで決める必要があります。
そこで初めて、次のようなことに気づく場合があります。
- この場合はどうしていたか決まっていなかった
- 担当者によって判断が違っていた
- 例外時は経験で処理していただけだった
- 実は明確なルールがなかった
メタ認知の弱さ
メタ認知とは、自分の理解状態や説明状態を自分で把握する力です。
要件定義では、「自分が何を説明できていないのか」に気づく力が重要になります。
この力が働くと、次のように考えられます。
- これは社内独自のルールかもしれない
- この言葉は外部の人には伝わらないかもしれない
- この例外条件は明文化しておいた方がよい
逆に、そこに気づきにくい場合、「説明したつもりなのに、なぜ分かってくれないのか」という状態になりやすくなります。
開発者側ができる確認の設計
認識ズレを完全になくすことはできません。ただし、ズレを起こしにくくする確認の仕組みは作れます。
大切なのは、相手の頭の中を察することではなく、曖昧な部分を見つけ、答えやすい形で確認することです。
1. 曖昧な表現を拾う
次のような表現が出たら、そのまま流さない方が安全です。
- 普通に
- いい感じに
- いつもの形で
- 適当に
- 自動で判断
- 前と同じ感じ
- 現場が使いやすいように
これらは会話としては自然ですが、開発仕様としては曖昧です。裏側に未定義の条件がある可能性があります。
2. 仮説を立てる
「どうしますか？」と聞くだけでは、依頼者側の負担が大きくなります。
そのため、開発者側でA案、B案、C案のように仮説を立てて確認する方が進みやすくなります。
この場合、次の3パターンが考えられます。
A: 空白のままにする
B: エラー表示にする
C: 前回値を使用する
今回はAでよろしいでしょうか？
この聞き方なら、依頼者はゼロから仕様を考える必要がありません。選択肢を見ながら、自分の業務に近いものを選べます。
3. 選択肢で質問する
自由回答の質問は、相手が慣れていないと答えにくいことがあります。
たとえば「重複時はどうしますか？」よりも、「最新を使う、エラーにする、一覧から選ぶ、のどれが近いですか？」と聞いた方が、確認が進みやすくなります。
選択肢を出すことで、依頼者側も「そういう分岐があるのか」と気づきやすくなります。
4. サンプルで擦り合わせる
文章だけでは、画面や帳票のイメージがズレることがあります。
その場合は、早い段階でサンプルを見せる方が安全です。
- 画面モック
- 入力例
- 出力例
- 帳票サンプル
- エラー表示例
- CSVやExcelのサンプルデータ
「この場合はこうなります」と見える形にすると、依頼者側も違和感に気づきやすくなります。
5. 記録し、限界も見極める
決まった内容は、チャット、仕様メモ、チェックリスト、画面サンプルなどに残します。
記録があると、後から「どの前提で進めたか」を確認できます。また、確認への協力が得にくい場合は、そのリスクも共有する必要があります。
開発請負では、すべてを完璧に聞き切れるとは限りません。だからこそ、確認できたこと、未確認のこと、追加費用や手戻りにつながりやすいことを分けて扱うことが重要です。
AI時代でも同じ問題は残る
生成AIを使う時代になっても、「伝わっているはず」の問題は残ります。
人間相手でもAI相手でも、前提、目的、制約、入力条件、出力形式を言語化しないと、期待と違う結果になりやすいからです。
たとえば、AIに「いい感じに資料を作って」と依頼すると、出力は出ます。しかし、それが業務目的に合うとは限りません。
良い結果に近づけるには、次のような情報が必要です。
- 何のための資料か
- 誰が読むのか
- どこまで詳しく書くのか
- どの表現を避けるのか
- 出力形式は文章か、表か、箇条書きか
- 判断に使う前提条件は何か
これは、開発請負の要件定義とよく似ています。
プロンプト設計は、AIに対する要件定義のようなものです。目的、前提、制約、出力形式を伝えるほど、期待に近い結果になりやすくなります。
重要なのは「AIが賢いか」だけではありません。何を、どこまで、どう出してほしいかを伝えられるかです。
発注者側にもできること
発注者側も、最初から完璧な仕様書を用意する必要はありません。
ただし、次の情報があると、開発者はかなり判断しやすくなります。
- 現在の業務の流れ
- 使っているExcelや帳票のサンプル
- 入力する人と確認する人
- 完成後に出したい結果
- 例外時の扱い
- 絶対に変えたくない運用
- できれば改善したい不満点
「まだ決まっていないこと」を正直に共有することも重要です。未定義の部分が分かれば、開発者側は仮説や選択肢を出せます。
反対に、決まっていないことを「普通に分かるはず」として扱うと、後からズレが大きくなります。
関連記事
- 現場DXの理想と現実: スマホ入力化が必ずしも効率化になるとは限らない
- 紙をなくす前に考えるべきこと: 選挙・契約書・経理証憑から見るDXの本質
- 生成AIを活用した新しいシステム導入サービスの考え方
- AIは考えられる。でも、感じられるか？ 生成AI時代の「Don’t think. Feel.」
- Googleスプレッドシートを簡易DBにするアイデア
- 古物商の現場入力をスマホ化したGAS Webアプリ開発対応事例
- GASで作る工事現場向け写真付き報告書Webアプリ
まとめ
開発請負は、単にコードを書く仕事ではありません。
依頼者の頭の中にある暗黙知を言語化し、入力、出力、条件、例外、優先順位として共有できる形にする仕事でもあります。
「伝わっているはず」ではなく、「伝えないと伝わらない」という前提を持つことが、要件定義の精度を大きく左右します。
そしてこれは、人間相手の開発請負だけでなく、AIを使った開発や業務改善にもつながります。相手が人でもAIでも、前提を言語化し、確認し、記録しながら進めることが、認識ズレを減らす一番現実的な方法です。