コードレビューにおける「LGTM」の意味
「LGTM」は「Looks Good to Me」の略で、レビュアーが変更リストを承認したことを示します。Googleのような企業では、LGTMはレビュアーが十分な時間をかけて、コードがチームの基準を満たしていると確認したことを意味します。この承認は、十分なコードベースのコンテキストと、一貫性がありレビュー可能な変更構造という二つの要素に支えられます。Googleのエンジニアリングプラクティスはこの用語を定義し、レビュアーに割り当てられたすべての行と周辺のコンテキストを確認するよう求めています。
エージェント支援開発では、AIエージェントがコードを急速に生成する一方、重要なコンテキストが外部のプロンプトやトレースに残ることがあります。レビュアーは、変更行だけを強調する平坦な差分画面を頼りに、変更の目的と仕組みの両方を推測しなければなりません。LGTMの従来の定義は変わりませんが、現代のワークフローはレビュアーの理解力に大きな負荷をかけます。
大きな差分の提示方法が評価を妨げる理由
変更が妥当な上限を超えると、レビュー品質は低下する可能性があります。Ciscoで行われた2,500件のレビューのケーススタディをもとに、SmartBearは1回にレビューするコードを200〜400行以内に抑えることを推奨しています。多数のファイル、平坦なファイル一覧、恣意的な表示順は外在的認知負荷を生み、レビュアーは安全性の評価ではなくコンテキストの組み立てに力を使うことになります。
研究では、ファイルの順序がレビュアーの注目先を左右することが示されています。
- 予測されたレビュー活動に基づいてファイルを並べ替えると、標準的な英数字順と比べてコードコメントが23%増え、注目箇所の特定も改善しました。
- 差分の先頭に表示されたファイルほど、レビュアーから多くのコメントを受けました。
- 同じ研究の対照実験では、欠陥のあるファイルを長い一覧の最後に置くと、検証された二種類の欠陥のうち一つを検出するオッズが64%低下しました。
複数サービスにまたがるスキーマ更新など、大きな変更が必要な場合、レビュー画面は関係性を強調し、論理的な読む順序を提案する必要があります。
LGTMがプロセス崩壊の兆候になるとき
単発の素早い承認は、効率の表れである可能性があります。一方、大規模または多層的なプルリクエストで即時承認が繰り返される場合は、インターフェース誘発型の承認と呼ばれる構造的な問題が浮かび上がります。これは、変更全体のメンタルモデルを構築しないまま、安心材料となる表面的な兆候だけを見て承認することです。
承認の深さが低下している主な兆候は次のとおりです。
- プルリクエストがサービス、データ、認可の境界をまたいでいるのに、システム全体への影響についてレビュアーの議論がない。
- レビュアーが差分を解析しにくいと明言しながら、複雑なコードを承認している。
- 重要なファイルが、デフォルトのレビュー順序で常に最後に置かれている。
- レビュー速度を測定していても、レビューの深さを測る指標がない。
- チームメンバーが後続のスプリントで、過去の承認理由を再構築することに時間を費やしている。
理解のためのインターフェース設計
コードレビューを改善するには、最初の状況把握に必要な労力を減らすインターフェースが必要です。効果的なツールは、編集を論理的なまとまりに整理し、依存関係を考慮した読む順序を示し、挙動を変える修正と定型的な更新を分け、コンテキストをコード変更のすぐそばに配置します。構造化された表示は根拠をたどる明確な道筋を提供し、レビュアーが正しさの検証と確信を持った承認に集中できるようにします。
