プルリク倍増と品質担保を両立するAI開発──TOKIUM流「ハーネスエンジニアリング」はどう実現されたか

コードレビューの委任、コーディングルールの更新──TOKIUM流「ハーネスエンジニアリング」とは

　坂上氏のチームはAIを組み込んだ開発を始めてから約1ヶ月で、3人のメンバーが1日10件以上のプルリクエストを継続的に出せる状態に達した。人間が手で書いていたころは多くても1日3～5件だったが、あるときは1営業日あたり10件以上、1件あたり500～1000行規模のプルリクエストを出せるようになった。

　しかし、成果物の急増は新たなボトルネックを生んだ。チーム全員がレビュー作業に疲弊したのだ。「認知負荷と体力的な面で、この体制を続けていくのは難しいと感じました」と坂上氏は振り返る。

　そこで取り組んだのがコードレビューのAIへの委任だ。「人間が今までの形と同じように細かくコードを読んでコメントしていく進め方は、AIのアウトプットを必要以上に絞ってしまうと感じました」と坂上氏は明かす。

　実際にAIにレビューさせると人間が見落としていた指摘が上がるケースも多く、「AIにレビューさせた結果を信じて、mainブランチにマージしていくスタイルを作っていこうとしています」と坂上氏は話す。

　AIによるレビューを運用し始めると、次の課題が浮かんだ。それは、同じ指摘が何度も繰り返されることである。このままでは、AIが毎回同じコメントを出し続ける非効率が生じる。そこで設計したのがコーディングルールの自動昇格だ。週2回、プルリクエストのコメントを全件洗い出し、共通する指摘があれば「このルールをコーディングルールに昇格すべきです」と自動でレコメンドするプルリクエストが開発者に届く。ルールがアップデートされることで、AIがコードを生成する時点から問題が解消された状態となる。

　AIレビューへの移行が進む一方、品質をどう担保するかは現在進行形の課題である。現在検討しているのは、絞り込んだテストケースを人間がレビューするアプローチだ。タスクやシーンの切り方を工夫してテストケースの差分を見えやすくし、そこだけを人間が確認する。「チームで合意まで取れていて、仕組みはこれから作り始めるところです」と坂上氏は話す。

　スクラムの運営にもAIを組み込んでいる。Slackチャンネルにはメンバーが開発したAIボットが常駐し、朝会の議事録を自動でまとめてToDoを抽出し、完了するまで繰り返しリマインドする。スプリントの振り返りではMiro上のホワイトボードからKPT（Keep・Problem・Try）の内容を読み取り、JiraのチケットへAIが変換する。開発以外のタスク運用コストも、AIが吸収していく。

メンバーで開発した議事録をまとめるAIボット（※アプリ作成者が広島出身のため広島弁）

　エンジニアリングの成果を測る定量指標として採用しているのは、ソフトウェア開発の生産性を測るフレームワークであるFour Keysだ。なかでも変更リードタイムの改善を重視している。一方で、今後はAIが自動マージする比率や、1回のプロンプトでAIが実行し続ける時間の長さなど、Four Keys以外の新たな指標も活用していく考えだ。

　チームごとのアプローチは一律ではない。別のチームでは、チーム人数を半分に絞りながら成果量を維持する取り組みを進めた。コードを細かく読む代わりに、インプットとアウトプットが仕様通りかを自動でレビューする仕組みに集中した結果だ。プロダクトの性質によって整備の勘所は異なり、各チームが自律的にボトルネックを見つけ解消していく姿勢がTOKIUMのハーネスエンジニアリングを支えている。