PRが重くなるのは、実装が速くなったから
AIを使った開発では、PRの扱いが難しくなると感じています。
従来の開発では、1日分、2日分、3日分の作業をまとめてPRにすることがよくありました。
もちろん、差分が大きすぎるPRは昔から問題でしたが、それでも人間が手で書く速度には一定の限界がありました。
しかし、AIを使うと、その前提が変わります。
1回の修正でも、大量のコードが出ることがあります。
3日作業した場合、その差分量はかなり大きくなる可能性があります。
ここで気になるのが、AI時代にPRが機能するのかという点です。
私の考えでは、PR制度そのものはまだ残ると思っています。
ただし、従来のように「作業が終わったらまとめてPR」では、かなり厳しくなると思います。
この記事で言いたいこと
- AI時代は、作業時間と差分量の感覚がズレる
- PRは日数ではなく、変更の種類で分けた方が読みやすい
- AIには実装だけでなく、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の出力をチームで受け入れるための関門として、今後も残ると思います。
PRは判断できる単位で切る
AI時代のPRは、従来より重くなりやすいです。
理由は、AIが短時間で大量のコードを生成できるからです。
その結果、作業時間と差分量の関係が崩れます。
自分が意識したいのは、以下のようなことです。
- PRを日数で区切らない
- 変更内容のまとまりで分ける
- 仕様変更とリファクタを混ぜない
- 設計変更と実装変更を分ける
- AIにPR分割や差分分類をさせる
PR制度をやめるのではなく、AI時代に合わせてPRの単位を再設計していくのだと思います。
次回は、「AIには細かく指示しない方がいい」という最近の流れが、チーム開発でも通用するのかを考えます。
シリーズ構成
【AIエージェント時代のチーム開発】