【AIエージェント時代のSES・受託開発を考える⑩】AIはヒアリングミスをどこまで救えるのか

受託開発やSES、フリーランスでの参画そのものを否定したいわけではありません。
ただ、AIを入れたときに、情報分断や権限分断がより見えやすくなるのではないか、という話です。

はじめに

前回の記事では、SESや多重下請けのような現場では、AIを入れても開発がすぐにうまくなるとは限らない、という話を書きました。

今回は、その中でも特に大きいと感じている「ヒアリングミス」について考えてみます。

AIエージェントを使うと、実装はかなり速くなります。
仕様書を読ませて整理することもできます。
抜け漏れの確認や、設計案の比較もできます。

これは本当に便利です。

ただ、それでも限界があると感じる場面があります。

それは、そもそも最初のヒアリングや要件理解が間違っていた場合です。

AIは、与えられた情報をもとに考えることは得意です。
しかし、与えられていない業務背景や、聞き取れていない現場の事情まで、完全に補えるわけではありません。

むしろ、間違った前提をもとに、かなり自然な設計やコードを出してしまうことがあります。

この記事では、AI時代の開発でヒアリングミスがどういう問題になるのか、自分なりに整理してみます。

AIは情報の整理が得意

まず、AIはヒアリングや要件整理にかなり役立つと思っています。

たとえば、次のような作業です。

• 議事録の整理
• 仕様書の要約
• 確認事項の洗い出し
• 業務フローのたたき台作成
• 画面項目の抜け漏れ確認
• APIやDB設計への落とし込み
• テスト観点の洗い出し

こういう作業では、AIはかなり強いです。

人間だけで仕様を読んでいると、見落としてしまうことがあります。
AIに仕様書や議事録を読ませると、「この条件のときはどうなりますか」「この項目はどこで更新されますか」といった確認事項を出してくれることがあります。

これは、従来の開発よりもかなり良い方向だと思います。

特に、受託開発やSESの現場では、仕様の確認漏れが後で大きな手戻りになることがあります。
そのため、実装前にAIで確認事項を洗い出すだけでも、一定の効果はあると思います。

ただし、聞けていないことはAIにも分からない

一方で、AIにも分からないことがあります。

それは、そもそも聞けていないことです。

たとえば、お客さんの現場では当たり前に行われている作業がある。
しかし、それが仕様書には書かれていない。
ヒアリングでも話題に出ていない。
議事録にも残っていない。

この場合、AIはその作業を前提に考えることができません。

もちろん、AIが「こういう例外作業はありませんか」と質問候補を出してくれることはあります。
そこは非常に有効です。

しかし、質問候補を出せることと、実際の答えを知っていることは違います。

AIは、現場で何が起きているかを直接見ているわけではありません。
お客さんが何に困っているのかを、勝手に正しく理解できるわけでもありません。

そのため、最初のヒアリングで大事な情報が抜けていると、AIもその抜けた前提の上で考えることになります。

間違った前提でも、AIはそれらしく進めてしまう

ここが少し怖いところだと思っています。

AIは、情報が不足していても、それらしい答えを出せます。

たとえば、次のようなことが起きます。

• 間違った要件をきれいに整理する
• 足りない仕様を自然に補完する
• もっともらしい業務フローを書く
• それっぽい画面設計を作る
• 動くコードを実装する
• テストケースまで用意する

人間が見ると、かなり完成度が高く見えることがあります。

しかし、前提が間違っていれば、その完成度はあまり意味を持ちません。

たとえば、本当は承認フローが2段階あるのに、1段階だと思って設計してしまう。
本当は月末だけ特別処理があるのに、通常処理だけで作ってしまう。
本当は手作業で補正している業務があるのに、システム上は存在しないものとして扱ってしまう。

この場合、AIがどれだけきれいに実装しても、実際の業務には合いません。

AIの出力が自然に見えるほど、前提が間違っていることに気づきにくくなる可能性もあります。

ヒアリングミスは、実装ミスよりも見つけにくい

実装ミスは、比較的見つけやすい場合があります。

テストが落ちる。
画面でエラーが出る。
型チェックが通らない。
APIのレスポンスが想定と違う。

こういう問題は、ツールやレビューで発見できることがあります。

しかし、ヒアリングミスは少し違います。

仕様書どおりに作れている。
テストも通っている。
画面も動いている。
レビューでも大きな問題は見つからない。

それでも、お客さんに見せると「そういう意味ではなかった」と言われることがあります。

これは、コードの品質の問題というより、理解していた業務や目的がずれていたという問題です。

AIを使うと、実装ミスは減らせるかもしれません。
しかし、業務理解のずれまで自動で消えるわけではありません。

むしろ、実装速度が上がることで、ずれた理解のまま先へ進みやすくなることがあります。

SESや多重下請けでは、質問が届きにくい

自社プロダクトであれば、仕様が怪しいときにすぐ確認できることがあります。

プロダクトオーナーに聞く。
業務担当者に聞く。
隣のチームに聞く。
過去の意思決定を知っている人に聞く。

もちろん自社開発でも簡単ではありませんが、質問先が見えていることは多いです。

一方で、SESや多重下請けの現場では、質問が届きにくいことがあります。

たとえば、開発者が疑問に思っても、直接お客さんに聞けない。
質問はリーダーを通し、元請けを通し、さらに別の窓口を通る。
返ってきた回答も、背景が削られた短い文章になっている。

こうなると、AIが良い確認事項を出してくれても、それを正しく解消するのが難しくなります。

AIが「ここを確認した方がよいです」と言う。
しかし、現場の構造上、簡単には確認できない。

この状態では、AIの力だけでは限界があります。

問題はAIの性能というより、質問が流れる経路や、判断が戻ってくるまでの構造にあるのだと思います。

仕様書に書かれない情報がある

開発で重要な情報は、必ずしも仕様書にきれいに書かれているとは限りません。

たとえば、次のような情報です。

• なぜその機能が必要なのか
• どの業務が一番困っているのか
• 何を変えると現場が困るのか
• どの例外ケースがよく起きるのか
• 過去にどんな運用で失敗したのか
• 今回は何をあえて諦めているのか
• 将来的にどの方向へ拡張したいのか

こういう情報は、画面項目やAPI仕様よりも文章にしづらいです。

しかし、設計や実装の判断ではかなり重要です。

AIに仕様書だけを読ませると、仕様書に書かれている範囲ではよく考えてくれます。
でも、仕様書に書かれていない背景までは分かりません。

そのため、AI時代には、仕様書そのものも少し変える必要があるのかもしれません。

単に「何を作るか」だけではなく、「なぜ作るか」「何を避けたいか」「どこが未確定か」まで書く。

そうしないと、AIは不足した背景を自分で補完しながら進んでしまいます。

AIに実装させる前に、質問させる

では、AIはヒアリングミスに対して無力なのでしょうか。

そこまで悲観する必要はないと思います。

AIは、正しい答えを勝手に知ることはできません。
しかし、確認すべきことを洗い出す用途ではかなり使えます。

たとえば、実装前に次のように依頼します。

この仕様をもとに実装する前に、
業務上確認すべき点、仕様が曖昧な点、
後から手戻りになりそうな点を洗い出してください。

特に以下の観点で確認してください。

- 業務フロー
- 例外ケース
- 状態遷移
- 権限
- データの正
- 既存運用との違い
- 画面と帳票の項目差異
- APIやDBへの影響

このように、いきなりコードを書かせるのではなく、まず質問を出させる。

これだけでも、かなり変わると思います。

AIは実装者としてだけでなく、仕様レビューの相手として使う方がよい場面があります。

「確認事項」を成果物にする

個人的には、AI時代には「確認事項」をもっと正式な成果物として扱った方がよいのではないかと思っています。

従来の開発では、確認事項はチャットや口頭で流れてしまうことがあります。
しかし、AIを使うなら、確認事項がかなり大量に出ます。

それをその場で消化するだけではなく、以下のように残しておくとよさそうです。

• 確認したい内容
• なぜ確認が必要なのか
• 確認先
• 回答
• 回答によって変わる設計
• 未回答の場合の暫定対応

ここまで残しておくと、後から「なぜこの実装にしたのか」を追いやすくなります。

また、AIに再度読ませることもできます。

AIは会話の中では前提を忘れることがあります。
しかし、確認事項と回答がドキュメントとして残っていれば、それを読ませて作業を続けやすくなります。

「作ってから確認」では遅くなることがある

AIを使うと、すぐに動くものを作れます。

これは大きな利点です。
早めに画面を見せて、フィードバックをもらうこともできます。

ただし、何でも「作ってから確認」でよいとは限らないと思います。

特に、業務フローやデータ構造の前提が間違っている場合、後から直すのは大変です。

画面の文言や配置なら、後から直しやすいです。
しかし、状態管理、DB設計、権限設計、外部連携、帳票の前提がずれていると、手戻りが大きくなります。

AIで実装が速くなるほど、「先に確認すべきこと」と「作ってから確認してよいこと」を分ける必要があると感じます。

すべてを最初に完璧に決める必要はありません。
ただ、後から変えると痛い前提だけは、実装前に確認した方がよいです。

受ける側だけが頑張っても限界がある

ここで難しいのは、ヒアリングミスを防ぐ責任を、仕事を受ける側だけに寄せすぎるのも違うということです。

もちろん、受ける側にも確認する責任はあります。
曖昧な仕様をそのまま実装せず、質問を出すことは大事です。

しかし、仕事を出す側が背景を渡せないままだと、受ける側だけでは限界があります。

特に、SESや多重下請けでは、実際にコードを書く人が業務の背景にアクセスしづらいことがあります。

その状態で「AIを使えば分かるでしょ」となってしまうと、かなり危ないです。

AIを使うなら、発注側や上流側も、AIに読ませられる形で情報を渡す必要があります。

たとえば、次のような情報です。

• 業務背景
• 現状の困りごと
• 既存運用
• 例外ケース
• 変更してはいけないこと
• 判断基準
• 未決事項

こうした情報があると、AIはかなり使いやすくなります。

逆に、これらがないまま実装だけを急ぐと、AIの速度が手戻りの速度にもなってしまいます。

AI時代のヒアリングは、質問力がより重要になる

AI時代には、ヒアリングの価値が下がるどころか、むしろ上がるのではないかと思っています。

なぜなら、実装が速くなるほど、前提の間違いがそのまま大きな差分になってしまうからです。

AIがコードを書いてくれるなら、人間はコードを書かなくてよくなる。
そう考えたくなる場面もあります。

しかし、実際には、人間がやるべきことは別の場所に移るのだと思います。

• 何を確認すべきか考える
• 誰に聞くべきか判断する
• 回答の意味を解釈する
• 業務上の優先順位を理解する
• 仕様の背景を記録する
• AIに渡す前提を整える

このあたりは、AIに任せきるのが難しい部分です。

AIは質問を作ることはできます。
しかし、その質問を誰に投げるか、回答をどう解釈するか、どこまで仕様に反映するかは、人間側の仕事として残ります。

おわりに

AIは、ヒアリングミスを完全に消してくれるものではないと思います。

ただし、ヒアリングミスを減らすための補助としては、かなり使えると思います。

仕様を整理する。
確認事項を出す。
例外ケースを洗い出す。
業務フローの矛盾を探す。
実装前に危ない前提を見つける。

こうした使い方をすれば、AIはかなり役立ちます。

一方で、そもそも聞けていない情報や、現場にしかない暗黙知を、AIが勝手に正しく補ってくれるわけではありません。

間違った前提を渡せば、AIはその前提の上で自然な答えを出します。
そして、その答えは一見するとよくできているように見えることがあります。

だからこそ、AI時代には、実装前の確認がより重要になるのだと思います。

AIにコードを書かせる前に、AIに質問させる。
仕様を確定させる前に、曖昧な点を洗い出す。
作業を受ける側だけでなく、出す側も背景を渡す。

AIをうまく使うためには、プロンプトの書き方だけではなく、AIに渡す前提の作り方を見直す必要があるのではないでしょうか。

シリーズ構成

• 【AIエージェント時代のSES・受託開発を考える⑨】SESや多重下請けの現場では、AIだけでは開発はうまくならない
• 【AIエージェント時代のSES・受託開発を考える⑩】AIはヒアリングミスをどこまで救えるのか
• 【AIエージェント時代のSES・受託開発を考える⑪】共通ルールを配っても、AIの出力はなぜ揃わないのか
• 【AIエージェント時代のSES・受託開発を考える⑫】機能ごとに人を割り振ると、AIの強みが消えるのではないか
• 【AIエージェント時代のSES・受託開発を考える⑬】仕事を出す側が背景を渡せないと、AIも判断できない
• 【AIエージェント時代のSES・受託開発を考える⑭】判断権限のない現場で、AIの提案はどこまで活かせるのか
• 【AIエージェント時代のSES・受託開発を考える⑮】SES現場でAIを使う前に揃えたい前提
• 【AIエージェント時代のSES・受託開発を考える⑯】AIを入れても改善しにくい現場の特徴