AIが全部作れる時代だからこそ、人間は順番を守った方がいい

AIが速く成果物を生成する時代だからこそ、人間のレビュープロセスが破壊されている。ある開発チームでの実例では、要件定義をAIに書かせたはずなのに、同時に設計、データモデル、シーケンス、異常系まで一気に出力されてしまう。それを見たレビュアーは、本来確認したかった「要件が正しいか」を判断する前に、詳細な設計の矛盾に目が行き、結果として「そもそもこの要件でいいのか」という大事な論点が薄れてしまう。生成コストが下がった分、レビュー側の負荷だけが爆増している逆説だ。

AIが「完成度の高い成果物」を出力するのは、使い手にとって一見便利に見える。だが、それは工程管理の罠でもある。要件定義なら、レビュー対象は「要件」であるべき。その要件が現実に成立するかを検証するために、後段の設計を薄く考えてみるのはアリだが、そこで見つかった問題は、設計を完成させるのではなく、現在の工程（要件）へ戻すべき。AIにはシーケンスやデータモデルを完璧に作らせるのではなく、薄い下書きを作らせ、「この場合どうする？」という質問を出させる程度でいい。つまり、AIを「議論のきっかけ作り」に使う。

AIの鬼の視点では、ここが要所だ。AIの速さを信頼しすぎて、工程の境界を曖昧にすると、結局のところ人間側のレビュー品質が劣化する。AIが出した指摘をチェックリストにするのは危険で、AIは与えられた情報と一般的な知識からしか考えられない。実際の開発には、「このシステムでは論理削除」「この操作では監査ログ必須」といった、チームやドメイン固有の暗黙知がある。AIにはそれを教わっていないから、見つけてくれない。だから人間のレビュアーには、AIが指摘しなかったことの中から「これ、どうするの？」を探す役割が残る。

実務的には、「今のレビュー対象は何か」を明確にすることが、AI時代の最重要ルールになった。レビューに出す側は「要件までで合意したい」なら、その旨を明示し、後段の設計は「参考資料」として扱う。AIにも、後工程まで完璧に作り込むのではなく、薄く考えさせることを指示する。レビュアー側は、その外側にあるチーム独自のルールや暗黙知を探す。こうして何度も同じ暗黙知が出てくるなら、そのときこそ初めて「チームのルールとして明文化しよう」と考える。AIのために巨大なプロンプトを作るのではなく、人間のレビューを通じて必要なものだけ少しずつ形にしていく。それくらいが、AI時代のプロセスマネジメントのしっくり来る姿勢だ。