割り込みレビュー、AI Slop……開発プロセスはAIによって早くなったのか？
「AIで得た速度を、何に配分するのか」。セゾンテクノロジーCTOの高坂亮多氏は、講演の趣旨をそう掲げた。
同社はプロダクト開発とシステムインテグレーション（以下、SI）をおよそ半々の割合で手がける企業だ。高坂氏は長くSIを担当していたが、3年ほど前にプロダクト開発へ軸足を移し、現在はCTOとして技術戦略の立案と新規事業開発を行う。
本講演の前提として挙げられたのは、セゾンテクノロジーが持つ品質へのこだわりだ。同社の企業向けファイル転送ソフトウェア「HULFT」は誕生から30年以上、国内シェアは23年連続でナンバーワン。障害発生率は「HULFT8」製品で0.19％、「HULFT10」製品で0.02％という水準にある。
そんな会社が、新規プロダクトの開発にAIを入れた。「実装のところは、当然AIを入れているのでかなり速くなりました。しかし、開発のライフサイクル全体で見て速くなっているかというと、そうではないという状況でした」。前工程である設計、あるいはコードレビューに滞留が発生し、ボトルネックが移動しただけで終わっていた。
加えて、副次的な問題が2つ生まれていた。ひとつは、レビューの割り込みが発生し、開発プロセス全体の進捗の見通しが悪化したこと。もうひとつは、低品質な変更が量産されるAI Slopである。AIが書いたコードをAIがレビューし、それを人間が最終確認する構造のなかで、「AIが出してきた本質ではない細かいところに、人間が時間を割いてしまっていることが起きていました」と高坂氏は振り返る。実装速度自体は上がっているのに、開発プロセス全体で見れば本当に速くなっているのかが判然としない状態だった。
QAを通過したあとの社内実利用で、製品の正式提供を止めた
では品質はどうだったか。セゾンテクノロジーでは新規プロダクトを世に出す前に、まず社内で実際に試用する期間を設けていた。QAを通して、製品として出せる状態にした後、そこからもう少し社内で使ってみる、という工程だ。
その社内実利用の期間に、ストップが出た。目立ったのは、アプリケーションとしては制御されて正しく動くものの、それがユーザーから見てどう映るのか、初めて見て使えるものなのかという類の問題だ。開発者が想定していない使い方をされたときにどう振る舞うか、ゆらぎのあるアプリケーションのエラーをどうユーザーに露出させるか。「そういった観点が特に不足していました」と高坂氏は指摘する。
速度は実装だけが速くなり、品質が良くなった実感も得られていない。単純に実装へAIを入れるだけでは、得られるメリットは限定的だった。そこで同社は、従来から持つ品質文化をAI時代にどう適応させるか、再デザインすることに決めた。
最初のコンセプトは「速度と品質を同じ場所で両立させようとするのをやめる」ことだ。高坂氏はQAやテストで見つけるべき観点を並べ、実装文脈からの「文脈の遠さ」と「要する時間」という2軸にプロットした。実装ルールへの適合や変更内容の妥当性は近くて速い場所にあり、初見利用での妥当性や実業務・継続利用での妥当性は遠くて遅い場所にある。これを1カ所で全部実現しようとすると、時間も品質もうまくいかない。だから一度分離し、別の場所でつなぎなおす。分離の軸は「時間」「コンテキスト」「主体」の3つだ。
PRレビューに、判断できない観点まで背負わせていた
1つ目の軸は「時間」だ。品質に限らず、さまざまなものをシフトレフトしていこうという考え方がある。高坂氏はそれ自体は正しいと認めながら、「全て何が何でも早ければ早いほどいいという話ではなくて、判断できる最も早い時点がそれぞれあります」と切り出した。
同社では、AIエージェントが書いたコードでも人間が書いたコードでも必ずPRレビューを通すというルールで運用してきた。反省点は、そこに多くを背負わせすぎていたことだ。実装ルールへの適合や変更内容の妥当性は誰もが見るが、全体設計と合っているかという観点はレビュアー任せになっていた。そもそも、それはPR単体では判断しきれない。「一番上のチケットの時点で見ても、実は後続のチケットで全く前提が変わってしまうことも当然発生し得ます」。見たからといって必ず大丈夫とは限らないものに、多くの時間をかけていた。
そこで同社は、ある程度の変更がたまった状態を「変更集合」と呼び、変更集合が揃わなければ見られない観点を明文化した。責務の境界が正しいか、コード的な重複ではなく意味的な重複が起きていないか。こうした観点をPRレビューから少しずつ外していった。
外した観点の受け皿になるのが「変更静止点」だ。スプリントのサイクルとは無関係に、変更がたまったところで静止点を取り、その変更集合の構造が正しいか、美しいかをレビューする。コードからCRUD図、シーケンス図、各種カバレッジといった派生成果物を自動生成して人間が見る。加えて、意味的な重複や責務境界の破壊がないかを人間がコードで確認する。外した観点は静止点でまとめて見る。その結果、「PRレビューは少しずつ楽になりました」と振り返る。
品質を高めるために「コンテキストを渡さない」
2つ目の軸は「コンテキスト」だ。盛んに議論される「コンテキストウィンドウのサイズ」に関する問題ではなく、高坂氏が踏み込んだのは「エージェントが知っていた方がいいことと知らない方がいいこと」の切り分けだった。
わかりやすい例がテストコードだ。同じエージェントにプロダクトコードとテストコードの両方を書かせると、プロダクトコードの都合に引きずられてテストコードのほうを直してしまう。「テストコードを作るエージェントはプロダクトコードのことを知らない方がいい」。実装の誤りを、テストが追認してしまうのを防ぐためだ。
レビューも2種類に分けた。設計に適合しているかを見るレビューは、設計意図と実際のコードを比べたほうがいい。一方、同社では「敵対的実装レビュー」も実施している。これは、通常のレビューとは逆に、コードが何かを壊していないか、非機能的に危ない実装をしていないかを確認するものだ。この際に設計に関するコンテキストを渡してしまうと、設計どおりだから正しいという方向に引っ張られ、実装への敵対性が弱まってしまう。
試行錯誤を経て、セゾンテクノロジーが運用する実際の構成が以下だ。人間が書いたものを設計Docに落とすスキルがあり、最初に動くテストコード実装エージェントが、プロダクトコードを知らないまま設計からテストコードを起こす。次にプロダクトコード実装エージェントが実装し、設計適合レビューを自ら通す。できあがったコードは、それを知らないテストコードでオールグリーンになるかを確認される。最後に、この変更の目的を知らない敵対的レビューエージェントが、非機能や異常系の観点から最終チェックをかける。
「プロダクトコードの実装エージェントと敵対的レビューエージェントの往復は、だいたい2回くらいすると完成度のかなり高いものができる印象」だと高坂氏は言う。「多くはテストコード側の誤りですが、たまにプロダクトコードの実装エージェントが間違えることがあり、それを防ぐことができています」。
AIで得た実装速度を短納期ではなく、機能量と品質保証量に振り向ける
3つ目の軸は「主体」だ。高坂氏が伝えたのは「立場が変われば『正しい』の意味が変わる」ということだ。
品質を練り直す場面でよくあるのはQAの観点を増やす打ち手だが、同社は「観点を増やすというよりも、見る主体を増やしていったほうがいいだろう」と判断した。開発・QAは正しく動くか、意図した通りに動くかを見る。社内実利用は実際の使われ方を集める。そこに加えたのが、開発部門から独立して出荷可否を判定する「製品検査」という主体だ。初見で分かりやすいか、ある画面で違う言葉を使っていないか。作る人とは別の人がそれを見る。
より高い品質を担保するためには、異なる主体で、長い時間をかけて試用することが必要だ。同社は、さまざまな工夫により設計やレビューで縮まった時間でリードタイムを短縮するのではなく、「リードタイムの考え方は変えずに」検査の時間を確保し、社内実利用の期間を長く取った。社内実利用ではエラーログの検知と監視を強化し、失敗をためて、直していく。
もっとも、3つの分離で最も大事なのは分けること自体ではないと高坂氏は強調する。「距離の遠いところでしか本来見つけられないものを、きちんと近いところで検知できるようにするループを作るのが一番大事です」。遠い層で見つかった観点はスキル化して派生する成果物へ反映し、継続利用の問題は新規エラーの自動起票として監視へ戻す。月単位で見つけた失敗を、分単位・秒単位で捕まえられる場所へ降ろす設計だ。
結果は数字に現れた。1人・週あたりのMerged PR数は2.46から2.42で、AI導入前の1.42から上がった水準のまま変わっていない。Issueのリードタイム中央値も12.9で不変だ。「1個の機能を開発するスピードは変わっていないです」。それでも週あたりにクローズしたIssue、それもバグ修正を含まず機能として実装したものに限れば、13.4から39.9へと約3倍に増えた。人間が時間をかけてPRレビューをする状態がなくなり、「並行できる数が増えた」ためだ。品質保証の側も、検査体制による起票が0から24.0へ、仕様未定義やマニュアル漏れの指摘が0から28.0へ増えた。
開発における「当たり前」を言語化し、工程と資産に残す
「AI時代に差がつくのは基本」。高坂氏が常々言っている一文だ。「今回の話も、その基本をいかに工程の中に実装できるかという話だったのではないでしょうか」。理由は2つある。
ひとつは、使う側から見た「当たり前」の水準が上がり続けていること。狩野モデル（製品やサービスの品質を分析するフレームワーク）で言えば最下層にあたる当たり前品質の要求は日々高まり、フロンティアAIの登場でセキュリティ要求は高度化した。昨日の専門性が今日の当たり前になる。
もうひとつは、ツールの高度化で基本動作がブラックボックス化し、リモート・非同期の働き方が暗黙知の伝承機会を削っていることだ。「基本は残していこうと思わないと残りません」と、高坂氏は現在の開発環境の難しさを率直に語る。
だから同社は「当たり前」を明文化し、5つの基本原則として言語化した。進捗ではなく終わるかどうかを見る、数字ではなく成果物を見る、一点突破ではなく網の目で守る、反省ではなく問題を閉じる、単体ではなく境界を見る。「こういうことをきちんと書いて言語化して、それを人間にもエージェントにも伝えています」。
最後に高坂氏が触れたのは、この仕組みを動かした土台だった。新規事業開発では、まず出すことが大事だという考え方もある。正式提供の延期は「すごく迷った決断」であり、その微妙な判断を最後に後押ししたのは、自社が品質を大事にする会社であるというフィロソフィーだった。
「我々は品質を大事にしないと、会社として積み上げてきたものが失われるのではないか」。変更静止点、コンテキスト分離、製品検査、社内実利用、AIスキルという工程は、その最下層に「品質に達していないものは正式提供しない」という思想があって初めて成立した。
速度と品質、そしてAIがもたらす新しさと基本。2つの二面性をつなぐのは人間の意思と工程設計だと高坂氏は言う。「AIがどんどん速度を上げていっても、品質をどれくらい大事にするのか、そもそも品質とは何かというところは、結局人が決めていくところになります」。その決定として同社は、得た速度を機能量と品質保証量に振り向けた。
株式会社セゾンテクノロジーからのお知らせ
セゾンテクノロジーではエンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
