こんにちは、フロントエンド推進課の水野です。
普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。
自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。
最近、自分の中でコードレビューのやり方が変わったなと感じています。
GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。
成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。
その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。
個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃しているからというのもあります。
添削作業の消失
コードレビューにおいて、おそらく以下のようなコメントを見かけたことがあるでしょう。(私は今でも見ます)
- 「このif文はearly returnした方がよくないですか？」
- 「命名がcamelCaseではなくsnake_caseになっています！」
- 「変数名が抽象的すぎるのでもうちょっと分かりやすくしてください」
- 「外から参照する型定義は
*.interface.tsに定義しましょう！」
などなど。
既に答えを知っているメンバーが答案用紙に赤ペンを入れて、実装者がそれに従って修正するという表現が近いかと思います。これはこれで大事で、勿論コードの品質は保たれるのですが、なんだか一方通行だなあと思うことはありました。
今は開発周辺ツールがそこら辺をカバーしてくれます。AIサービス含め、Linter, Formatterがあれば人間の出番はほとんどありません。そうなると、「コードレビューの存在意義って何？」という哲学的な問いに直面することになります。哲学的というか、自分自身の存在に対する危機感でもあるというか...。
答えを出すことによる機会損失
「こう書いてください」ではなく「こういうケースの考慮が必要になりませんか？」と聞いてみることが増えました。直接答えをポンと提示するのではなく、一緒に考える時間を作るように意識しています。とは言っても「なんでこうしたんですか？」「この実装のどこに問題があるでしょうか？」みたいなネチネチした詰め方はしませんが。
APIリクエスト処理を書く時に「リクエスト前後でこういう処理が必要になりませんか？」と聞いてみたり、UIコンポーネントを作る時も「このコンポーネントってどの画面でどういうパタンで使われますか？」と実装前に一度考える時間を作ったり。
そうすると、次に同じような問題が出てきた時や別の人のレビューを行う際に自分で判断したり、別の改善案を考えたりできるようになっていきます。
「なんで？」を大事にしている
機械がコーディングをアシストする場面が増え、構文的には正しく効率的なコードが出てきやすくなりました。しかし、「なんでその設計にしたの？」のような部分の責任は依然として人間にあります。
設計の話
- 「このコンポーネントの共通化の粒度、後で機能追加する時に耐えられますか？」
- 「この関数だけ責任範囲が広すぎませんか？」
- 「これ、3ヶ月後に見てもウッてなりませんか？」
- 「テスト書きにくくないですか？」
運用の話
- 「この実装は別のプロダクトでも何箇所か見かけたのでライブラリのAPIに閉じてしまって良さそうですね」
- 「デザインシステムや他プロダクトとの整合性は取られていますか？」
- 「前にも似たようなもの作っていませんでしたっけ？」
機能的には問題無くても時系列的な整合性が無かったり客観性に乏しかったりすると、負債になりやすいと考えます。そういうものをまあまあ見落としがちで、後からテコ入れしたり実装背景が後付けされることもありました。
なので、単純に「動くか動かないか」ではなく「長く使っていけるか」「変更に強いか」「チームにとってプラスか」のような視点で話すことが増えました。
AIが生成するコードは特に「なんでこうしたの？」が抜けていることが多いので、「前提条件って何でしたっけ？」「こんなケースは考えました？」を掘り下げてコンテキストを補足する作業が大切だと思っています。
開発チームの変化
知見の民主化
以前は「コードが書ける人」「コードレビューができる人」でなんとなく別れるようなことが多かったのですが、今は流動的になってきたと感じます。コーディングの敷居が下がった結果、より多くの人が実装に参加できるようになり、逆にレビューにおいては各々の専門性・経験値が活かされるようになってきました。
自身の周りの話ですが、業務ドメインに詳しいエンジニアがロジックを実装してアーキテクチャに強いエンジニアが別の観点からレビューしたり、フロントエンドエンジニアが実装したUIコンポーネントをマークアップ・Webアクセシビリティに精通したメンバーがチェックしたりといった協業は自然と生まれてきています。
非同期で作る
これまでは「作る→レビュー→直す→またレビュー...」を繰り返していましたが、現在は事前に相談する(相談できるようにする)ことが増えてきました。「なんでこの方法？」「他の選択肢は？」「今後の運用は？」のような話を作る前にしておくことで、実装時のレビューはその確認作業に近くなり、大きな手戻りも発生しにくくなりました。
一人がコンポーネントを実装しながら、別の人がリアルタイムで画面の開発を進める、みたいな動き方も出来るようになってきました。多少複雑なインタラクションや状態管理も非同期で考えながら進められるので、完全に作り終わってからの考慮漏れは格段に減ったと感じています。
今後
生成AI含め、技術の進化は止まりません。近いうちに「なぜこの実装を選んだのか」の前後も含めて実装プロセスが圧縮されるかもしれません。そうなったとき、人間の役割はさらに抽象的、例えば「そもそもこの機能は必要か」「体験として最適なのか」「プロダクトとの親和性は」「人間もAIも守っていない実装ルールは捨てるべきでは」といった、より戦略的な判断軸に移り変わるだろうと予想しています。
だからといって人間の価値が下がるわけではなく、末端実装の細部まで気を払う必要が無くなることで、より本質的な価値創造を追求できるようになったと考えています。
おわり
人間以外にコードを書かせる技術が一般化した今のコードレビューは、表面上の正確性から人間的な洞察へとシフトしています。
単純なコードの良し悪しではなく、実装の本質的な価値と持続可能性を見極めるために、AIが生成したコード含め全てのアウトプットを『人が作り上げるシステム』という文脈で評価し、プロダクトの価値提供への貢献は勿論、開発チームの成長にも結びつける。
...みたいな思想が当てはまるのだろうと思います。
正直な所、自分がレビューにかける時間は長くなったと感じています。純粋に実装単位のボリュームと実装速度が上がって物理的な負担が上がったのもそうですし、技術的な側面だけではなくもっと広い視点でレビューすることが増えました。
毎回疲弊しないためには、事前の相談を大事にしたり背景をドキュメントにしたりなどの工夫をする必要があります。
その一方で、開発チーム内の知識共有やコミュニケーションが活性化したり、「本来こうあるべき」のような話をやりやすくなったという効果は確実に得られています。
何より、単純作業から解放されて抽象度の高い課題解決に割ける時間が多くなったのは嬉しいことです。まだまだ頑張れることがたくさんありそうで、それはそれで楽しみでもあります。
