この記事は 株式会社カオナビ Advent Calendar 2025 24日目（シリーズ1）の記事です。
🚩 はじめに
カオナビには、「レビューマスター」というコードレビューを担当する役割があります。
新卒2年目のフロントエンドエンジニアである私も、今年9月からこの役割を担うことになりました。
レビュワーという新しい役割に挑戦する中で、「何をコメントすべきか」「自分の指摘は正しいのか」という迷いに何度も直面しました。
特に、自分の担当機能以外のレビューも行うため、ドメイン知識や背景が掴みにくく、「本当にこの理解で合っているのか？」と不安になることも多くありました。
本記事では、そうした心理的なハードルをどう下げたか、チームの仕組みやツールを活用しながら得た気づきを整理します。
1. レビュワーになって直面した壁 🧱
レビュワーとして取り組み始めた当初、いくつかの壁がありました。
-
何をコメントすべきか分からない
「これは指摘すべき？それとも好みの問題？」と判断に迷う -
自分の指摘が正しいか自信が持てない
「もっと良い書き方があるかもしれない」と思っても、確証が持てない -
背景理解に時間がかかりすぎる
自分の担当外の機能では、MR（マージリクエスト）から全てを読み取ろうとすると時間がかかりすぎる
「完璧なレビューをしなければ」という思い込みが、かえって行動を鈍らせていました。
2. ハードルを下げた3つのこと🔍
① Askコメントで「コメントのハードル」を下げる
「指摘」ではなく 「質問（Ask）」 から入るようにしたことで、迷わずコメントできるようになりました。
🟡 Before：指摘スタンス
- 「こう書くべき」という正解を提示しなくては、というプレッシャー
- 100%の自信がないとコメントしにくい
- 指摘が間違っていたら……という不安がブレーキになる
🟢 After：確認スタンス
- 「ここは〇〇という理解で合っていますか？」という確認から入る
- 自信がないからこそ、素直に質問として投げられる
- 「もし間違っていたら教えてください」という構えでいられる
このように「確認」の形で聞くことで、自分の推測が合っているか迷って手が止まる時間がなくなりました。
なぜ「質問（Ask）」が合理的か💡
-
「正解」を持っていなくていい:
正解を知らなくても、「気になった点」をそのまま投げられるようになる。 -
背景を最速で把握できる:
担当外のコードをMRだけで完璧に読み解くのは限界があるため、本人に意図を聞くのが最も早く確実。 -
不要なすれ違いを防げる:
いきなり指摘して「制約があってできない」と返される二度手間がなくなり、スムーズに話が進む。
② ペアレビュー・モブレビューを通じた「慣れ」と「視点の獲得」
私の所属するチームでは以前からモブレビューの取り組みがあり、先輩を中心に数人でコードを見る習慣がありました。
さらに最近、組織全体の活動として「他チームのレビューマスターと1対1でレビューを行う」というペアレビューの機会がありました。
これはシニア枠と育成枠がペアになり、実際に現場のMRを一緒に見ながら進める取り組みです。
この「誰かと一緒に見る」という経験が、ハードルを下げる上で非常に大きかったです。
-
「コメントすること自体」に慣れる
シニアエンジニアと一緒に見てもらえる安心感の中で実践を重ねることで、コメントをすることへの抵抗感が徐々に薄れていきました。結局、この「慣れ」の部分が一番大きかったと感じています。 -
人によって異なる「観点」を知る
ペアレビューを通じて、人によって「差分の追い方」も「重視するポイント（アクセシビリティ、パフォーマンス、コードの配置など）」も全く違うことを知りました。
「全ての観点を最初から完璧にカバーしなきゃ」と気負うのではなく、 「まずは自分が得意な観点や、気づいたポイントから確実に貢献していく」 というスタンスを持てたことで、以前よりも主体的にレビューに臨めるようになりました。
③ AIを活用する
ペアレビュー中、シニアエンジニアも積極的に GitHub CopilotやClaude CodeなどのAIを活用しているのを目の当たりにし、自分もレビューにAIを取り入れるようになりました。
- 人間（自分）の役割: コードを読んで「何か怪しい」という直感的な違和感を見つける
- AIの役割: その違和感に対する技術的な裏付けや、具体的な修正案を生成してもらう
「この書き方、本当に問題があるのかな？」と迷った時、AIに裏付けをもらうことで、自信を持ってコメントできるようになりました。
3. レビュワー経験が自分のコードを変えた 🚀
レビュー側を経験したことで、自分のコーディング習慣にも良い変化がありました。
-
MRの「分割」を強く意識するように
膨大な差分はレビュワーの負担になり、質も下がることを痛感しました。今は「なるべく100〜150行以下」に収めるよう意識しています。 -
セルフレビューの精度が向上
「ここは意図が伝わりにくいかも」と客観的に見れるようになり、コードコメントやMR説明文を出す前に充実させるようになりました。 -
技術のキャッチアップにも繋がる
ペアレビューなどで自分がまだ触ったことのない技術のMRを扱う際、「これはこういう使い道がある」と解説してもらえることがあり、学びの場にもなりました。
4. 一人で抱え込まず、相談先を持つ 🛡️
自力で完結させる努力は前提ですが、どうしても判断に迷う時の「相談先」があることで、心理的な余裕が生まれています。
-
どうしても困ったら他のレビューマスターを頼る
自分の提案が的外れでないか不安な時や、複雑なロジックで判断が下せない時は、他のレビューマスターに相談するようにしています。
「いざとなったら相談できる環境がある」という実感が、一人で抱え込まずに一歩踏み出すための支えになっています。
まとめ 🏁
自分一人で抱え込まず、「質問（Ask）」「仕組み（ペアレビュー）」「ツール（AI）」を状況に応じて使い分けることで、過度に気負うことなくレビューに関われるようになりました。
「最初から完璧な正解を出さなければ」と構えるのではなく、分からないことは素直に聞き、便利なものはフル活用する。この進め方に変えたことで、レビューの心理的ハードルがぐっと下がりました。
こうしてレビューの回数を増やしていくことが、結果的に自分自身のスキルアップや、より良いコードを書くためのヒントにも繋がっていると感じます。
同じようにレビューに不安を感じている方の参考になれば幸いです！☘️