AIがコードを書くのが当たり前になって、人間がコードの正しさを見て承認する作業(この記事でいうコードレビュー)を、これまでどおり続けるのは追いつかないと感じています。人間のコードレビューがつねに必要かどうかは賛否が分かれますが、少なくとも今のやり方のままではボトルネックになると思っています。
同じ問題意識の2つの記事を読んで、やめたあとに人間が品質の何を見ておきたいかを考えました。
読んだ2つの記事
きっかけは、次の2記事です。切り口は違いますが、どちらも「人間のコードレビューをやめる」ことを真面目に考えています。
コードレビューをなくすことを考える
1本目は、従来のレビューの目的を4つに分けて考えています。
- 要件を満たしているか
- 設計が正しいか
- セキュリティに問題がないか
- チーム内で知識が共有されるか
このうち前半の3つは、レビューする人の経験や知識で質がばらつきます。一般的な技術スタックなら、いまのAIも一定水準でレビューできるので、1本目はAIに寄せられるとしています。人間に残るのは、知識共有と、新しく加わる「AIへの指示が正しいか」の確認です。AIがどれだけ優れていても、指示が間違っていれば、間違った成果物が出てくるだけだからです。
そこで、AIへの指示が正しいかを実装前に確かめるために、「コンセプト」という文書を書いてチームで承認する流れが提案されています。コンセプトには、1行サマリー、解決したい課題、達成の定義、絶対に触らない範囲、事前調査の内容を入れます。実装後はAIレビューを通し、コンセプトと実装のギャップを見て、そのままリリースします。ただ、コンセプトを書いて承認を得る手間が小さな変更にも見合うかは、やってみないとわかりません。筆者も軽微な修正は省略可としています。
ハーネスエンジニアリングで人間のコードレビューをやめる
2本目は、品質チェックの部分を実際にAIへ任せている話です。ハーネスエンジニアリングとは、モデルそのものではなく、モデルを動かす外側の仕組みを設計することを指します。
タイトルでは「やめる」と言い切っていますが、立場は「何を作るか、何をやらないかは人間が決め、方向が決まったあとの品質チェックはAIに任せる」です。人間をゼロにする話ではありません。
AIが数分で書いたコードを、人間が数時間から数日かけて見る。この非対称がボトルネックだ、という指摘です。
AIレビューを1回通すだけでは、過剰な指摘や、その場しのぎの修正、直しては戻す往復が起きます。そこで、レビュー、トリアージ(指摘を重大度で分けて、低いものを捨てる)、修正、バリデーション(根本原因に対処できているか、その場しのぎでないかの検査)をループにして、低い重大度の指摘は捨てたうえで、残った指摘がゼロになるまで回しています。このループの手順はYAMLに書かれ、Gitで管理されています。
2本目は、こう書いています。
モデルの性能ではなく、モデルの外側の設計が結果を決める。
この「外側の設計」にあたるのが、上のループです。
なぜ従来のレビューをやめたいのか
見る範囲と集中力に限界がある
人間のレビュアーは、コードベースの一部しか把握できません。疲れや遠慮で見落とすこともあります。差分の量がAIで増えれば、この限界はさらに目立ちます。
承認が形だけになる
1本目の記事は、複数人でチェックすると、誰かが見ているだろうと各自が安心して通してしまう点を挙げています。誰が何に責任を持つのかが決まっていないと、承認の数が増えても品質の担保になりません。
「なぜそう実装したか」を聞く場になりやすい
レビューで「なぜこう実装したのですか」と議論になることがあります。これは実装前にAIと壁打ち(AIに方針を話して詰めること)して、なぜその実装にするかを実装者自身が説明できる状態にしておけば、レビューで聞く必要はなくなります。理由を先に持っておけば実装の質も上がり、その記録がそのままメンバーへの共有にもなると思っています。
人間が見ておきたいのは、仕様と要求
とはいえ、人間が見る作業まで要らなくなるとは思っていません。コードの正しさはAIに任せ、人間は、満たすべき要求や仕様そのものが妥当かどうかを見ます。
- 仕様や要求が、例外も含めて妥当か
- その根拠は、ドメインの決まりか、業務上の都合か
たとえば、法律の都合で計算式のロジックを合わせる必要があるのは、ドメインの決まりです。実装側の都合では変えられません。業務上の都合なら、事情が変われば見直せます。この区別がないと、その例外を変えてよいかが判断できず、議論が好みの話に流れます。好みは、品質とは別の話です。
承認が形だけになるのは、誰が何に責任を持つかが決まっていないからでした。何を作ろうとしたかを一番知っているのは実装者なので、要件が漏れなく入っているかの責任は、後からコードを見る人より、実装した本人(AIに実装を任せる開発者)が持つべきだと思っています。
実装者が要件の責任を持つなら、確かめる時点は実装後ではなく、AIに指示を出す前になります。1本目のコンセプトにあたる実装前の文書は、この記事ではADR(Architecture Decision Record、設計判断の記録)で代えます。
例外と「なぜそう実装したか」を、どこで確定するか
実装にある例外的な対応も、もとをたどれば要求から来ています。「この場合だけ挙動が違う」には、たいてい理由があります。
その理由が実装者の頭の中やレビューのコメントにだけあると、次にAIが触るときに失われます。次にAIが触るとき読めるのは、リポジトリやドキュメントに残ったものだけです。だから、例外も含めて仕様として整備しておく必要があると考えています。置き場所はADRが合います。ADRに書いておけば、あとから来た人やAIも同じ理由を読めます。
「なぜそう実装したか」の壁打ちも、ADRの上で確定させます。ADRは実装者が責任を持って確定します。確定できなければ、周りに相談します。決まった仕様をAIに渡して、その仕様で実装させます。
実装後は、2本目のようにAIにコードを確認させるハーネスと、E2Eテスト(画面やAPIを通して一連の動作を確かめるテスト)で、実装漏れがないかを確認します。ある程度はカバーできると考えています。「なぜ」は実装前に決めてあるので、実装後に議論する必要がありません。
学びや知識はどこに残すか
1本目が人間の役割として残した知識共有は、放っておくと肥大します。学びや知識を、毎回人間がまとめ直すのは現実的ではありません。
共通の学びは、AIがSKILL(AIに渡す手順書)やドキュメントに書き足し、人間はその差分を承認するだけにします。これらは人間にも読めるので、知識共有の役割も、ある程度はここで担えると考えています。
要求や仕様の確認は、AIに寄っていくのか
要求や仕様の確認も、いずれはAIに置き換わるかもしれません。ただ、いまは、AIに正解を出させるより、実装前の要求やADRの案をAIに指摘させ、抜けや曖昧さを出させて、実装者が確認する形が噛み合っていると感じています。
人間とAIの分担
ここまでを踏まえて、これから進めたいのは、人間が仕様と要求の妥当性に集中できるよう、それ以外の確認をAIとテストが回る仕組みに寄せることです。
| やること | 担当 |
|---|---|
| 何を作るか、何をやらないかを決める | 人間 |
| 例外も含めた仕様を、AIと壁打ちしてADRに確定する | 実装者（確定できなければ相談） |
| 要求とADRの抜け・曖昧さを洗い出す | AI（指摘を実装者が確認） |
| コードの正しさ、設計、セキュリティを見る | AI |
| 実装漏れがないかを、ハーネスやE2Eで確かめる | AIとテスト |
| 学びや見落としやすい観点を、SKILLやドキュメントに落とす | AI（人間は差分を承認する） |
学びを落とす行は、2本目のように、問題が起きるたびにチェックやSKILLを足して履歴を差分として残すことにあたります。そうすると、品質の基準が人の頭の中ではなくリポジトリの中にたまっていきます。
承認のためにレビューを待つ時間は減らして、その分を「何を作るか」を考える時間に使えると便利です。
最初に試すなら
まだ試行錯誤の途中ですが、まずは実装前に「何を満たしたいか」と、その理由をADRに書き出すところから始めてみると、手軽に試せます。