PRレビューに、判断できない観点まで背負わせていた
1つ目の軸は「時間」だ。品質に限らず、さまざまなものをシフトレフトしていこうという考え方がある。高坂氏はそれ自体は正しいと認めながら、「全て何が何でも早ければ早いほどいいという話ではなくて、判断できる最も早い時点がそれぞれあります」と切り出した。
同社では、AIエージェントが書いたコードでも人間が書いたコードでも必ずPRレビューを通すというルールで運用してきた。反省点は、そこに多くを背負わせすぎていたことだ。実装ルールへの適合や変更内容の妥当性は誰もが見るが、全体設計と合っているかという観点はレビュアー任せになっていた。そもそも、それはPR単体では判断しきれない。「一番上のチケットの時点で見ても、実は後続のチケットで全く前提が変わってしまうことも当然発生し得ます」。見たからといって必ず大丈夫とは限らないものに、多くの時間をかけていた。
そこで同社は、ある程度の変更がたまった状態を「変更集合」と呼び、変更集合が揃わなければ見られない観点を明文化した。責務の境界が正しいか、コード的な重複ではなく意味的な重複が起きていないか。こうした観点をPRレビューから少しずつ外していった。
外した観点の受け皿になるのが「変更静止点」だ。スプリントのサイクルとは無関係に、変更がたまったところで静止点を取り、その変更集合の構造が正しいか、美しいかをレビューする。コードからCRUD図、シーケンス図、各種カバレッジといった派生成果物を自動生成して人間が見る。加えて、意味的な重複や責務境界の破壊がないかを人間がコードで確認する。外した観点は静止点でまとめて見る。その結果、「PRレビューは少しずつ楽になりました」と振り返る。
品質を高めるために「コンテキストを渡さない」
2つ目の軸は「コンテキスト」だ。盛んに議論される「コンテキストウィンドウのサイズ」に関する問題ではなく、高坂氏が踏み込んだのは「エージェントが知っていた方がいいことと知らない方がいいこと」の切り分けだった。
わかりやすい例がテストコードだ。同じエージェントにプロダクトコードとテストコードの両方を書かせると、プロダクトコードの都合に引きずられてテストコードのほうを直してしまう。「テストコードを作るエージェントはプロダクトコードのことを知らない方がいい」。実装の誤りを、テストが追認してしまうのを防ぐためだ。
レビューも2種類に分けた。設計に適合しているかを見るレビューは、設計意図と実際のコードを比べたほうがいい。一方、同社では「敵対的実装レビュー」も実施している。これは、通常のレビューとは逆に、コードが何かを壊していないか、非機能的に危ない実装をしていないかを確認するものだ。この際に設計に関するコンテキストを渡してしまうと、設計どおりだから正しいという方向に引っ張られ、実装への敵対性が弱まってしまう。
試行錯誤を経て、セゾンテクノロジーが運用する実際の構成が以下だ。人間が書いたものを設計Docに落とすスキルがあり、最初に動くテストコード実装エージェントが、プロダクトコードを知らないまま設計からテストコードを起こす。次にプロダクトコード実装エージェントが実装し、設計適合レビューを自ら通す。できあがったコードは、それを知らないテストコードでオールグリーンになるかを確認される。最後に、この変更の目的を知らない敵対的レビューエージェントが、非機能や異常系の観点から最終チェックをかける。
「プロダクトコードの実装エージェントと敵対的レビューエージェントの往復は、だいたい2回くらいすると完成度のかなり高いものができる印象」だと高坂氏は言う。「多くはテストコード側の誤りですが、たまにプロダクトコードの実装エージェントが間違えることがあり、それを防ぐことができています」。
