「テストが通った」はもう信用できない──人間には重すぎた「受け入れテスト駆動開発（ATDD）」をAIに任せたら

【B-4】なぜ「テストが通った」はAI時代に信用できなくなったのか 〜受け入れテスト駆動開発(ATDD)にたどり着くまで〜

テストは全部通るのにバグが出る、原因は要件定義にあった

　ダブルループを組み込んだ仕組みを動かし始めると、「極端に変なテスト」は減っていったという。しかし別の問題が現れた。テストはすべて通っているのに、実際に動かすと変なバグが出る。大園氏はその原因を次のように説明する。

　「アクセプタンスクライテリアをきちんと作れるかどうかの判断を、AIがうまくできていませんでした。つまり、要件定義やユーザーの機能分析ができていなかった。皆さんが実装前に大事にしていることをスポイルした結果、ちゃんとしたテストも書けていなかった。ただそれだけの話です」

　この反省から大園氏が重視するようになったのが、PRD（Product Requirements Document）とDesign Docの2文書だ。PRDでは「この機能はなぜ必要か」「ユーザーのどんな要求に応えるのか」を言語化し、Design Docでは「何をどう作るか」「アーキテクチャはどうするか」を固める。実装前にこの2つを必ずAIと一緒に作る。

　ただし、設計フェーズのスキル化は簡単ではなかった。テスト駆動の部分は大園氏の専門で、ATDDがAIにフィットすることも肌感としてわかっていたが、PRDやユーザーストーリーは専門外だった。

　「AIが一般論や外の事例を単に流し込むだけの設計の仕方をスキルにしていたのですが、それはなかなかうまくいきませんでした。私のやり方にちゃんとフィットしたやり方を模索する必要がありました」

　そこで、現職のチームメンバーにいたスペシャリストにスキルを作ってもらい、一緒にこの開発手法を確立していった。

　現在の開発スタイルは、この経験を3つのスキルに体系化したものだ。最初の「Discover」ではAIとの壁打ちを通じてPRDを作成し、次の「Plan」でユーザーストーリーやアクセプタンスクライテリア、Design Docなどの実装前設計を固め、最後に「ATDD」スキルでダブルループを回して実装を進める。大園氏はこれらのスキルをプラグインにまとめ、約2カ月間、1人で複数のプロジェクトに適用して463件のIssueと454件のPRを作成した。当初はAIが書いたテストや実装を一行一行確認していたが、今は設計段階のレビューに注力し、実装はほぼAIに任せているという。

Discover→Plan→ATDDの3つのスキルで回す現在の開発スタイル

ATDDにこだわる必要はない、大事なのは実装とテストの分離と設計の質

　大園氏は「テストが通った」がAI時代に信用できなくなった理由を2つに整理した。1つ目はAIが持つリワードハッキングの傾向だ。2つ目は人間が要件をAIに正しく伝えられていないケースで、この場合はテストがきちんと書かれて通っていても、テスト自体が意味のないものになっている可能性がある。

「テストが通った」がAI時代に信用できなくなった2つの理由

　講演の最後に大園氏は、ATDDについて普段よく聞かれるという3つの質問を自ら取り上げ、それぞれに答えた。「UIが決まっていない段階でE2Eテストは書けないのでは」という質問には「書けます。書けないのだとしたら、おそらく受け入れテストを書くための要件が決まっていません」と回答。「どのような開発体制に向くのか」については、基本的にはどの体制にもなじむとしつつ、使い捨てのLPや1～2時間で作るプロトタイプのようにメンテナンスしないものには、このフローは重すぎると線を引いた。「うちの環境は特殊なので無理だと思う」という声には「極論を言うと、適用できない現場はおそらくないと思います。もちろん向き不向きはあります」と応じた。

　大園氏は、今日の話はあくまで「今の」AIを前提にしたものだと念を押す。1〜2年後には情勢が変わり、テストを書かなくてもよい時代が来る可能性もあるからだ。そのうえで、手法そのものにこだわる必要はないと語った。

　「ATDDという手法にこだわる必要はまったくありません。私が『いい感じ』にできるものが、たまたまこれだったというだけです。大事なのはAIの癖、実装とテストを分離させた方がいいのではないか、テストの設計自体の質が大事なのではないか、といった根本のところです。皆さんがやりたい、やらせたい方法でAIとうまく付き合う。そのときにテストを有効に活用してもらえればと思います」