結論から書く。要件が固まっていないことは、PoCを始めない理由にならない。むしろ「要件を固めるためにPoCを使う」という順序を選べば、要件が曖昧な段階の方が着手しやすいことすらある。FDEとして複数のAI導入案件に関わる中で、要件定義書が完成するのを待ってからPoCに入る進め方と、要件が固まる前にPoCを走らせてしまう進め方の両方を経験してきた。今回は後者、つまり「要件が固まっていない段階から、どうやってPoCそのものを始めるか」という着手時点の判断と手順に絞って書く。
「要件が固まってから」を待つと何が起きるか
要件定義書が完成するのを待ってからPoCに着手する進め方には、一見すると合理性がある。何を検証するかが決まってから動いた方が、手戻りが少ないように思えるからだ。
しかし実際には、要件を固める作業自体が、AIを使ったことがない担当者にとっては未経験の作業になる。「AIに何をさせたいか」を紙の上だけで詰め切ろうとすると、議論が抽象的になり、会議は重ねるのに前に進まない状態が続く。私が経験した案件でも、要件定義のための打ち合わせを重ねているうちに、担当者の異動や予算サイクルの区切りが来て、そのまま立ち消えになったケースがあった。要件が固まるのを待つこと自体が、案件が止まる最大のリスクになり得る。
着手判断: 「何を検証したいか」ではなく「何が分かれば次に進めるか」
要件が固まっていない状態でPoCを始めるかどうかを判断するとき、私は「要件が何%固まっているか」を基準にしない。代わりに「今分かっていないことのうち、動くものを作れば分かることがあるか」を基準にしている。
要件が曖昧な案件でも、分解すると「担当者の頭の中では決まっているが言語化されていないこと」と「実際にやってみないと誰にも分からないこと」が混在している。前者は言語化の支援でどうにかなる領域だが、後者はいくら会議を重ねても答えが出ない。この「やってみないと分からないこと」が案件の中に1つでも見つかれば、それがPoCを始める合図になる。逆に、曖昧に見える部分が実は全部「言語化すれば決まること」だけなら、PoCより先にヒアリングを詰めた方が早い。
判断の目安として、私は次のようなチェックを自分に課している。
- 今のヒアリング内容だけで、担当者に「はい」か「いいえ」で答えられる質問を作れるか。作れないなら、まだ言語化の余地が残っている
- その質問に対する答えが、実際にAIを動かしてみないと得られないものかどうか。会議室で答えが出るなら、PoCを急ぐ必要はない
- 検証にかかる時間が、要件を言語化し切るのにかかる時間より短いか。短いなら、待つより動いた方が早い
最初のスコープは「1つの問い」に絞る
要件が固まっていない段階でPoCを始めると決めたら、次に決めるのはスコープだ。ここで私が徹底しているのは、最初のPoCで検証する問いを1つだけに絞ることだ。
要件が曖昧な案件ほど、関係者の頭の中には「ついでにこれも確認したい」という項目が次々と出てくる。この誘惑に負けてスコープを広げると、要件が固まっていないまま検証項目だけが増え、何を確認すればPoCが「成功」なのかが誰にも説明できない状態に陥る。私は、案件の中で最も不確実性が高く、かつ検証結果次第で案件の方向性そのものが変わる問い——「そもそもこのやり方でAIが使い物になるレベルの出力を返せるのか」といった根幹の1問——だけを最初のPoCの対象にすることにしている。ほかの論点は「後で検証するリスト」に退避させ、最初のスコープからは意識的に外す。
検証しながら要件を「同時並行で」埋めていく
PoCを始めた後は、検証と要件の言語化を別工程にしない。検証で動くものを実際に担当者に見せると、口頭のヒアリングでは出てこなかった反応が返ってくることが多い。「思っていたのと違う」「ここまで自動化されると逆に困る」といった反応は、要件が固まっていなかったからこそ、動くものを見せて初めて引き出せるものだ。
具体的には、私はPoCの各検証サイクルの終わりに、担当者と一緒に「今回分かったこと」と「まだ決まっていないこと」を毎回書き出すようにしている。これを1回のPoCの最後にまとめてやろうとすると、初期の気づきを忘れてしまう。サイクルごとに記録を残すことで、要件が少しずつ確定していく過程が可視化され、案件の関係者にも「要件が決まっていないのに何となく進んでいる不安」ではなく「要件が着実に埋まっている実感」を持ってもらいやすくなる。
まとめ
- 要件定義書が完成するのを待つ進め方は、待っている間に案件そのものが立ち消えるリスクを抱える
- 着手判断の基準は「要件がどれだけ固まっているか」ではなく「動かしてみないと分からないことがあるか」
- 最初のPoCのスコープは、案件の方向性を左右する1つの問いだけに絞る
- 検証と要件の言語化は別工程にせず、検証サイクルごとに「分かったこと」「まだ決まっていないこと」を書き出す
次回は、PoCが動き出した後、検証の中で見えてきた不確実性をどう優先順位づけして潰していくかを書く。