結論：「LGTM」だけのレビューは、優しさではなく思考停止のサインかもしれない
コードレビューで毎回「LGTM 👍」だけが返ってくる。一見すると「雰囲気いいチームだな」と思いますよね。
でも、ちょっと待ってください。
それって本当に「コードが良かったから」ですか？それとも「指摘するのが面倒」「波風立てたくない」「どうせ直してもらえない」という諦めから来ていませんか？
レビューの質は、チームの学習速度に直結します。 LGTM 連発が常態化しているチームは、コードの品質向上よりも「摩擦を避けること」を優先している可能性があります。今回はそのあたりを、データも交えながら掘り下げてみます。
根拠：レビューの質とチームパフォーマンスの関係
GitHub が公開している研究レポート「The State of the Octoverse」や、開発者調査「GitHub Developer Survey」では、コードレビューの活発さと開発チームの生産性・品質には正の相関があるという傾向が繰り返し報告されています。
また、Google が社内研究として発表した「Project Aristotle」（チームの効果性に関する調査）では、高パフォーマンスチームの共通要素として 「心理的安全性」 が最上位に挙げられています。
ここで面白いのが、「心理的安全性が高い ≠ 指摘しない」 という点です。むしろ逆で、心理的安全性が高いチームほど「率直なフィードバックを安心して言い合える」状態にあります。
一方、IPA（情報処理推進機構）が毎年発行している「ソフトウェア開発データ白書」でも、レビュー工程の手抜きがバグの後工程流出コストを大幅に引き上げるという傾向が示されています。
整理するとこんな感じです：
| レビュー文化 | 短期の雰囲気 | 中長期の影響 |
|---|---|---|
| LGTM 連発 | 摩擦が少なく快適 | バグ流出・スキル停滞のリスク |
| 丁寧なコメント文化 | 最初は緊張感あり | 品質向上・メンバー成長 |
| 高圧的な指摘 | ストレス大 | 離職・委縮・心理的安全性の崩壊 |
問題は「指摘するかどうか」ではなく「どう指摘するか」 なんですよね。
LGTM 連発が生まれる背景
レビュアーが「忙しすぎる」問題
正直、これが一番多い原因じゃないでしょうか。
レビュー依頼が大量に来る、自分の実装タスクも詰まっている、そんな状況でコードをじっくり読む余裕はなかなか持てません。結果として「動いてるなら OK」という判断になりがちです。
「指摘したら嫌われるかも」という萎縮
これも根深い問題です。特に年次が下のメンバーが上の人のコードをレビューするとき、「何か言ったら失礼かな」と感じてしまうケース、よくありますよね。
でも実は、指摘しないほうがチーム全体の損失になる ということを、チームとして共有できているかどうかが鍵です。
PR（プルリクエスト）が大きすぎる
1 つの PR に何百行もの変更が詰め込まれていたら、誰もちゃんと読みません。「小さく・頻繁に」がレビュー文化を健全に保つ基本です。
反論への先回り：「LGTM でもいい場面もある」は正しい
ここで反論も出てきます。「全部のレビューで細かいコメントが必要なわけじゃないでしょ」という意見、これはもっともです。
- 小さなタイポ修正や設定変更なら LGTM で十分
- 信頼関係が構築されたシニア同士なら、省エネなレビューも合理的
- レビューのコストが高すぎると、逆にデプロイ速度が落ちる
これらは全部正しいと思います。「LGTM が悪い」のではなく、「LGTM しか選択肢がない状態が問題」 ということです。
また、「指摘が多いレビュー文化がメンバーを消耗させる」という観点も無視できません。細かすぎる指摘・マイクロマネジメント的なレビューは、逆に開発者体験（DX）を下げてしまいます。
バランスを取るのが難しいんですよね、これが。
補足：あなたのチームのレビュー文化、振り返ってみませんか
最後に、いくつか問いかけを置いておきます。
- 直近 1 ヶ月のレビューコメント、何件ありましたか？
- 「この書き方、なぜこうしたの？」と聞ける雰囲気がありますか？
- 新しいメンバーが「指摘してもいいんだ」と感じられる場になっていますか？
レビューは品質チェックだけじゃなく、チームの学習の場でもあります。 LGTM しか返ってこない状況が続いているなら、「なぜそうなっているのか」を一度チームで話し合ってみるのが最初の一歩じゃないでしょうか。
「レビューしやすい PR を作るには」「コメントの書き方ガイドラインを作る」といった具体的な取り組みから始めるのも、現実的なアクションだと思います。
あなたのチームのレビュー文化、どんな感じですか？
