はじめに ― コードレビューが怖くなる瞬間
新しいプロジェクトに配属され、最初のプルリクエストを作成したとき、胸の鼓動が速くなるのを感じたことはありませんか？「自分の書いたコードが指摘される」こと自体が、評価されることへの不安に変わってしまう瞬間です。実際、私が入社して最初に経験したコードレビューでは、指摘が多すぎて「自分はこのチームに向いていないのか？」と劣等感に苛まれました。指摘は成長のチャンスだと頭では理解していても、感情はすぐに「攻撃」や「否定」と捉えてしまうものです。そこでこの記事では、コードレビューを通じて学んだ実践的なテクニックと、レビュー中・レビュー後にメンタルを保つために私が試行錯誤した方法を具体例とともに紹介します。読んでくださる皆さんが「自分だけが苦しんでいるんじゃない」と共感し、次のレビューに前向きに臨める手助けになれば幸いです。
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
スイカゲームとにゃんこ大戦争のようなタワーディフェンス系ゲームを組み合わせたゲームを作成しました！
遊んでみていただけると嬉しいです🙇♂️
ハジメル.dev: https://hajimeru-dev.vercel.app/
「ひとりで続けるのは難しい」「何から学べばいいか分からない」という方向けに、
プログラミングのマンツーマンレッスンサービス「ハジメル.dev」も運営しています。
未経験OK・オンライン完結・月額制/違約金なしなので、気軽に無料相談してみてください🙇♂️
海外テックニュースを追いたいけど、英語や情報量の多さで大変…という方向けに、
Hacker News の話題を日本語でサクッと追える「HackerNews 日本語まとめ & AI要約」
を個人開発しました！
技術トレンド収集に使ってもらえると嬉しいです🔥🙇♂️
→ HackerNews 日本語まとめ & AI要約: https://hn-matome-2ht.pages.dev/
「ニャンパイアサバイバー」というヴァンパイアサバイバーリスペクトのゲームを作成しました！
もしよろしければ遊んで頂けると嬉しいです😭
習い事教室の先生向けに、SNS 投稿・生徒募集・保護者通知の文章を AI で生成する Web サービス「おしらせAI」を個人開発しました。Next.js + Supabase + LLM で構成しており、無料で月 10 回まで試用できます。よければ触ってみてください。
→ おしらせAI: https://oshirase-ai.vercel.app/
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
1. 指摘を「個人」ではなく「コード」に分離する思考法
なぜ指摘が個人的に感じられるのか
レビューコメントはしばしば「この書き方はダメです」や「ここは間違っています」といった形で届きます。文章だけ見ると、まるで自分の能力全体を否定されているように受け取ってしまいます。特に駆け出しの頃は、コードの品質と自分の価値が直結していると無意識に考えてしまうため、指摘が自己否定感に直結しやすいです。
具体的にどう分離すればいいか
私が実践したのは、指摘を受け取った瞬間に「このコメントは『コード』に対する意見であって『私』に対する評価ではない」と紙に書き出すことです。紙に書くことで頭の中で情報を外在化し、感情と事実を切り分けやすくなります。さらに、コメントの中で具体的に指摘された箇所だけを抜き出し、以下のようなテンプレートで整理します。
指摘内容: 変数名が曖昧
対象行: 23
改善案: userInfo → userProfile に変更
このように「指摘内容」「対象行」「改善案」の3要素に分けると、指摘は単なる情報の集合体に見えてきます。感情が抜け落ち、次に何をすべきかがクリアになるのです。
私の場合の変化
この手法を取り入れた最初の週は、レビューコメントの受け取り方が劇的に変わりました。以前はコメント一つで一日中落ち込んでいましたが、テンプレート化したおかげで「やるべきことリスト」にすぐ変換でき、作業効率が上がっただけでなく、自己評価が下がることもなくなりました。結果として、レビューへの不安が減り、コードを書くこと自体が楽しくなったのです。
2. 受け入れやすいフィードバックの受け取り方 ― 「質問形式」に変換する
なぜ質問形式が効果的なのか
指摘はしばしば「こうすべきです」と命令形で書かれます。命令形は受動的な姿勢を強いられ、受け手は防御的になります。一方で「なぜこの実装を選んだのか？」といった質問形式に変換すると、対話的な雰囲気が生まれ、相手の意図を探る姿勢が自然に出ます。
実践ステップ
- コメントを読む → まずは感情的な反応を抑える（深呼吸2回）。
- コメントの要点を自分の言葉で質問に置き換える。
例: 「この関数は副作用があるのでテストが難しいです」 → 「この関数で副作用が出るケースは具体的にどんなものですか？」 - 置き換えた質問をレビュー担当者に返信し、意図や背景を尋ねる。
- 返答を元にコードを改善するか、代替案を提案する。
私の体験エピソード
あるとき、React コンポーネントで「useEffect の依存配列が不足している」と指摘されました。最初は「自分は正しく書いたはずだ」と反論しようとしましたが、質問形式に変換して「依存配列に何が必要か、具体的なケースを教えていただけますか？」と返信。相手は実際にバグが再現したシナリオを示してくれ、結果的にコードをリファクタリングするきっかけになりました。このやり取りは、指摘が攻撃ではなく協働的な改善提案であることを実感させてくれ、メンタル面でも大きな安心感を得られました。
3. 振り返りノートを活用した学習とメンタルケア
振り返りがなぜ必要か
コードレビューは単発のイベントではなく、継続的な学習サイクルの一部です。指摘を受けた瞬間は感情が先行しがちですが、時間を置いて客観的に見返すことで、実際にどのスキルが足りていないかが見えてきます。振り返りノートは、感情の揺れを落ち着かせ、学習項目を可視化するツールとして有効です。
ノートの書き方例
- 日付・PR番号: 2026-06-01 #123
- 指摘されたポイント: 変数名が不適切、テストケースが不足
- 自分の感情: 「自分はまだまだだ」と焦燥感
- 改善策: 変数名は命名規則に沿ってリネーム、テストはユニットテストを追加
- 次回のアクション: 命名規則のドキュメントを読む、テストフレームワークのチュートリアルを完走
このフォーマットで毎回書くことで、感情は「感情」タブに閉じ込め、実際の改善アクションにフォーカスできます。数週間続けると、どの指摘が繰り返し出てくるかがパターン化し、重点的に学習すべき領域が明確になります。
私の変化と効果
最初の1か月はノートを書くのが面倒でしたが、2か月目に入ると「今月は命名ミスが5回、テスト不足が3回」と数値化できるようになり、自己効力感が上がりました。メンタル的には「同じミスを繰り返す自分」に対する不安が減り、代わりに「改善できる自分」を実感できるようになったのです。また、上司に振り返りノートを共有したところ、フィードバックが具体的になり、チーム全体のレビュー品質向上にも貢献できました。
4. 受動的にならないレビュー参加のコツ ― 事前準備と質問リスト
事前準備の重要性
レビュー前にコード全体の構造や変更点を把握しておくと、指摘が来たときに「なぜこの部分が問題なのか」すぐに理解できます。逆に、全体像が掴めていないと指摘が来るたびに「何がどう違うのか」が分からず、混乱とストレスが増幅します。
具体的な準備手順
-
変更点の概要を書き出す
- 変更したファイル数、主なロジックの追加・削除箇所を箇条書きに。
-
自分が不安に思うポイントをリスト化
- 例: 「非同期処理のエラーハンドリングが足りているか」や「パフォーマンスに影響が出ないか」。
-
レビュー担当者に質問リストを添付
- 「この実装で意図した動作は〇〇ですか？」など、事前に疑問点を提示すると、指摘が具体的になりやすい。
実践例と結果
私が新しいマイクロサービスを作ったとき、事前に上記の3ステップを踏んでプルリクエストに添付しました。結果として、レビュー担当者から「エラーハンドリングはどうする？」という質問が減り、代わりに「パフォーマンステストの結果は？」と具体的な指摘に変わりました。自分が不安に思っていたポイントが先に共有されているため、指摘が的外れになることが減り、レビュー時間も30%短縮できました。この経験から、事前準備がメンタルケアだけでなく、プロジェクトの効率化にも直結することを実感しました。
5. メンタルリセットのルーティン ― 小さな習慣が大きな差になる
なぜ「リセット」が必要か
レビューが終わった後、結果が良くても悪くても頭の中に残る情報は多いです。そのまま作業を続けると、集中力が低下し、次のタスクでも同じような不安が持ち越されます。短時間でリセットできるルーティンを持つことで、感情の余韻を切り離し、次の作業にフラットな状態で臨めます。
私が実践している3つのリセット法
-
5分間の深呼吸とストレッチ
- 目を閉じてゆっくり息を吸い、4秒で止め、6秒で吐く。これを5回繰り返すだけで交感神経が落ち着く。
-
「レビュー完了」スイッチを作る
- プルリクエストをマージした瞬間、デスク上の小さな置物を右に回す。物理的なアクションが「完了」感を身体に刻む。
-
15分の非エンジニアタイム
- コーヒーを入れながら好きな音楽を聴く、軽く散歩するなど、コードと全く関係ないことに時間を使う。脳が別の刺激を受けることで、レビューでのストレスがリセットされる。
効果とエピソード
このルーティンを導入した最初の週は、レビュー後に「まだやることが残っている」感覚が強く、作業に戻るのが遅れがちでした。しかし、深呼吸とスイッチを組み合わせた結果、レビューが終わった瞬間に「完了した」という感覚が体感できるようになり、次のタスクにスムーズに移行できました。結果として、1日の作業効率が約10%向上し、精神的な疲労感も大幅に減少しました。小さな習慣ですが、継続することで大きなメンタルの安定につながります。
まとめ
コードレビューは「自分の成長を測る鏡」でもあり、「チーム全体の品質を高めるツール」でもあります。指摘を個人への批判と捉えるのではなく、コードという客観的対象に分離し、質問形式で対話を作ることで防御的な感情を和らげました。さらに、振り返りノートで感情と改善策を切り離し、事前準備と質問リストでレビューを能動的にコントロールすることで、指摘の質と自分のメンタルを同時に高めることができました。最後に、短時間のリセットルーティンを日課にすることで、レビュー後の余韻を速やかに切り離し、次の作業へフラットな状態で臨めます。これらの実践を通じて、私自身が「レビューは怖い」から「レビューは学びの場」へと意識を変えることができました。駆け出しの皆さんも、まずは小さな一歩—指摘を紙に書き出す、質問に変換する、リセットの習慣を作る—から始めてみてください。継続すれば、必ずコードも自分も成長し、メンタルも安定してくるはずです。共に学び続ける仲間として、次のレビューが楽しみになることを願っています。