はじめに
AIを使った開発では、PRの扱いが難しくなると感じています。
従来の開発では、1日分、2日分、3日分の作業をまとめてPRにすることがよくありました。
もちろん、差分が大きすぎるPRは昔から問題でしたが、それでも人間が手で書く速度には一定の限界がありました。
しかし、AIを使うと、その前提が変わります。
1回の修正でも、大量のコードが出ることがあります。
3日作業した場合、その差分量はかなり大きくなる可能性があります。
では、AI時代にPRは機能するのでしょうか。
私の考えでは、PR制度そのものは必要です。
ただし、従来のように「作業が終わったらまとめてPR」では、かなり厳しくなると思います。
AIは作業量と差分量の関係を壊す
人間だけで開発していた時代は、作業時間と差分量にはある程度の関係がありました。
もちろん個人差はあります。
しかし、1時間の作業、1日の作業、3日の作業で、だいたいの差分量は想像できました。
AIを使うと、この感覚が崩れます。
短時間でも、AIは大量のコードを生成できます。
逆に、長時間かけても設計検討だけで差分が少ないこともあります。
つまり、「何日作業したか」でPRの大きさを判断するのが難しくなります。
AI時代のPRは、時間ではなく、変更内容のまとまりで考えるべきです。
大きいPRはレビューできない
PRが大きくなりすぎると、レビューは難しくなります。
特にAIが生成した差分では、次の判断が必要になります。
- 仕様変更はどこか
- AIが勝手に直した箇所はどこか
- 既存挙動が変わっていないか
- リファクタが混ざっていないか
- 責務の境界が変わっていないか
- テストは十分か
これを大量の差分に対して行うのは大変です。
PRは存在していても、実質的にはレビューできていない、という状態になりかねません。
そして、レビューできないPRは、チーム開発では危険です。
PRを日数で区切らない
AI時代には、PRを「作業日数」で区切るのはあまり適していないと思います。
たとえば、次のような区切り方です。
3日分作業したのでPRを出す
これは、人間中心の開発でも大きくなりがちですが、AI時代にはさらに危険です。
AIを使うと、3日分の作業はかなりの量になります。
複数画面、複数API、状態管理、テスト、リファクタまで含まれることがあります。
そうなると、レビューする側はかなり厳しいです。
代わりに、PRは「何を変えたか」で分けるべきです。
PRは変更の種類で分ける
AI時代のPRは、以下のように分けるとよいと思います。
- ひな形追加
- 型定義追加
- API接続追加
- 画面表示追加
- バリデーション追加
- テスト追加
- リファクタ
- 不具合修正
たとえば、ユーザー一覧画面を追加する場合でも、1つの巨大PRにするのではなく、次のように分けることができます。
PR1: User型とAPIクライアントの追加
PR2: UserListPageのひな形追加
PR3: 検索フォームの追加
PR4: 一覧表示とページングの追加
PR5: テスト追加
すべてを細かく分けすぎる必要はありません。
しかし、少なくとも「仕様変更」と「リファクタ」は分けるべきです。
設計変更と実装変更を分ける
AIは、実装しながら設計変更も提案してくることがあります。
たとえば、既存の状態管理を変えた方がよい、共通コンポーネントを分けた方がよい、APIクライアントを整理した方がよい、という提案です。
これらは有用な場合があります。
しかし、機能追加PRの中に設計変更を混ぜると、レビューが難しくなります。
設計変更が必要なら、先にそれだけをPRにする。
あるいは、Issueや設計メモで合意してから実装する。
この順番が大切です。
AIにPR単位を考えさせる
AIには、実装だけでなく、PR分割の相談もできます。
たとえば、実装前にこう聞きます。
この機能を実装する場合、レビューしやすいPR単位に分割してください。
仕様変更、リファクタ、テスト追加を混ぜない方針でお願いします。
また、実装後にこう聞くこともできます。
現在の差分を確認し、レビューしやすいPR単位に分割するとしたら、どのように分けるべきですか。
仕様変更、リファクタ、テスト追加、不要変更を分類してください。
AIはコードを書くためだけのものではありません。
差分の整理やレビュー観点の抽出にも使えます。
PR制度は不要ではない
AI時代にはPRが難しくなる。
だからPRは不要になる。
そう考えるのは少し危険だと思います。
むしろ、AI時代だからこそPRは重要です。
AIが大きな差分を素早く作れるからこそ、人間が確認できる単位に分解する必要があります。
問題はPR制度そのものではありません。
問題は、AIが生成した巨大な差分を、そのままPRにしてしまうことです。
PRは、AIの出力をチームで受け入れるための関門として、今後も必要だと思います。
まとめ
AI時代のPRは、従来より重くなりやすいです。
理由は、AIが短時間で大量のコードを生成できるからです。
その結果、作業時間と差分量の関係が崩れます。
対策としては、以下が重要です。
- PRを日数で区切らない
- 変更内容のまとまりで分ける
- 仕様変更とリファクタを混ぜない
- 設計変更と実装変更を分ける
- AIにPR分割や差分分類をさせる
PR制度をやめるのではなく、AI時代に合わせてPRの単位を再設計する必要があると思います。
次回は、「AIには細かく指示しない方がいい」という最近の流れが、チーム開発でも通用するのかを考えます。
今後
以降の連載予定になります。
- 第1回：同じAIを使っているのに、なぜコードがバラバラになるのか
- 第2回：AIが書いた「動くコード」が、チーム開発では危ない理由
- 第3回：AIに任せたらコンフリクトだらけになった話
- 第4回：AIに「このファイル以外触らないで」と言うのは正しいのか
- 第5回：AI時代のPRは、なぜ重くなりやすいのか
- 第6回：AIには細かく指示しない方がいい、はチーム開発でも通用するのか
- 第7回：ステアリングファイルだけでは足りない。AIのブレを仕組みで吸収する
- 第8回：AI時代のベテランは、コードを書く人から仕組みを作る人へ