「要件が固まっていないと開発に入れない」。これは正しいが、AI導入案件では話が逆になることが多い。要件は、動くプロトタイプを見せて初めて固まる。
とはいえ、ヒアリングもなしにいきなり作り始めていいわけではない。ここでは、私が実際に使っている「顧客ヒアリングからプロトタイプまでを最短で回す型」を書く。
目次
なぜ「要件を固めてから作る」がAI案件では機能しないのか
従来型のシステム開発では、要件定義書を作り、レビューし、承認を得てから実装に入る流れが一般的だ。これは要件が言語化しやすい業務であれば機能する。
だがAI導入案件、特に生成AIを使う案件では、依頼する側自身が「何ができるのか」を正確にイメージできていないことが多い。「AIでなんとかしたい」という漠然とした課題感はあっても、それを要件書に落とし込める粒度の言語化は、多くの場合まだできていない。この状態で要件定義書を作ろうとすると、時間ばかりかかって精度の低いものが出来上がる。
だから、要件を「固めてから作る」のではなく「作りながら固める」方向に発想を切り替える必要がある。
型: ヒアリング→仮プロトタイプ→再ヒアリングの3ステップ
ステップ1: 最小限のヒアリングで「何に困っているか」だけを掴む
最初のヒアリングでは、詳細な要件を聞き出そうとしない。聞くのは基本的に3つだけだ。
- 今、何に困っているか（できれば具体的な業務の場面で）
- 誰が困っているか（担当者個人か、チーム全体か）
- 困っている頻度・規模はどれくらいか
ここで詳細な仕様を詰めようとすると、相手も「まだ考えがまとまっていない」という理由で答えに詰まり、ヒアリングが長引く。最初は「困りごとの輪郭」だけ掴めれば十分だ。
ステップ2: 仮プロトタイプを最短で作る
輪郭を掴んだら、すぐに手を動かす。完成度は求めず、「困りごとの一部が解決される様子」が伝わる最小のものを作る。生成AIのプロトタイピングは、従来の開発より圧倒的に速く形にできるのが強みなので、ここを最大限活かす。
このとき意識するのは「間違っていてもいいから、具体的な形にする」ことだ。抽象的な提案書より、多少ズレていても動くものの方が、相手からの反応を引き出しやすい。
ステップ3: プロトタイプを見せて再ヒアリングする
出来上がった仮プロトタイプを見せると、最初のヒアリングでは出てこなかった反応が返ってくる。「そうそう、これなんだけど、実はこの部分も」「ここはちょっと違って」——具体物を前にすると、人は言語化しやすくなる。
このステップ3が要件定義の実質的な本体になる。抽象的な議論で仕様を積み上げるより、動くものを触ってもらいながら要件を引き出す方が、精度も速度も高い。
この型を回すときの注意点
「仮」であることを最初に明示する
プロトタイプを見せる前に、「これは仮のもので、今日の反応をもとに作り直します」と伝えておく。これを省くと、仮のものを完成品だと誤解されて、期待値がズレたまま先に進んでしまう。
1〜2周で収束させる
このループは何周でも回せてしまうが、実務では1〜2周で大枠を固めるのが目安になる。回しすぎると「作っては壊し」が延々続き、いつまでも前に進まない。輪郭が見えてきたら、そこから先は実装を進めながら微調整する段階に移る。
ヒアリング相手と決裁者が違う場合は要注意
現場担当者へのヒアリングで盛り上がっても、決裁者が別にいる場合は、そこで固めた要件がそのまま通るとは限らない。この論点は稟議の話と直結するので、別記事で詳しく書いている。
まとめ
AI導入案件では、要件を固めてから作るのではなく、作りながら固める方が速く、精度も高い。
- 最小限のヒアリングで「困りごとの輪郭」だけ掴む
- 完成度を求めず、最短で仮プロトタイプを作る
- プロトタイプを見せて、具体物を前に再ヒアリングする
このサイクルを1〜2周で収束させることが、要件が固まっていない案件を前に進める最短ルートだ。
企業のAI導入をFDEとして支援しています。ご相談はサービス紹介ページから。
