コードレビューにおけるフィードバックの受け方と伝え方
コードレビューとは
コードレビューは、ソフトウェア開発プロセスにおいて仲間の開発者が書いたコードをチェックし、品質向上や知識共有を目的としてフィードバックを行う作業です。具体的には下記の利点があります。
- 品質改善:バグの早期発見や可読性・保守性の向上
- ナレッジ共有:設計や技術的知見の共有を通じたチームのスキル底上げ
- 標準化:コーディング規約やベストプラクティスの遵守促進
- リスク低減:セキュリティやパフォーマンス上の問題を未然に防ぐ
コードレビューはPull Requestを通じて実施されるのが一般的で、開発者とレビュアーの双方向コミュニケーションを通じてより良いコードを共に作り上げます。
1. フィードバックの受け方
- 心構えを整える
- 成長マインドセットを持つ
- 「指摘=否定」ではなく「自分のスキルアップの機会」と捉える
- レビュー内容を「学びのネタ」としてメモを残す
- 防衛反応をコントロール
- 感情的になる前に深呼吸し、一度冷静になる
- 思わず反論したくなったら「なるほど、詳しく教えてください」と言い換える
- 成長マインドセットを持つ
- レビュー準備
- 事前確認
- 自分でチェックした箇所(命名、例外処理、テストカバレッジなど)を一覧化
- レビュアーに「ここは自分なりに重点的に見てほしい」と共有
- 背景・意図の説明
- プルリクの説明文に「なぜこう設計したか」を明記
- レビュー時に聞かれたときスムーズに回答できるよう準備
- 事前確認
- 受け取り方のフレームワーク
- SBIモデル
- Situation(状況):「〇〇の機能を実装したPRで」
- Behavior(行動):「変数名が抽象的で、何を指すか分かりにくかった」
- Impact(影響):「可読性が下がり、チームでの共有・保守が難しくなる可能性があります」
- このモデルでコメントを咀嚼し、自分への影響を整理
- SBIモデル
- 質問の仕方
- 具体的に聞く
- NG:「直してください」
- OK:「こちらの変数名を
userScore
にすると意図が伝わりやすいと思うのですが、いかがでしょうか?」
- オープンクエスチョンを活用
- 「このアルゴリズムの何が可読性を下げていると感じましたか?」
- 「別アプローチで改善するとしたら、どのような方法が考えられますか?」
- 具体的に聞く
- 改善アクション
- 指摘を受けたら 24時間以内 に修正案をプッシュ
- 修正後は「対応しました。〇〇も併せて修正しています」とコメント
- 再レビューでの 感謝の一言を忘れずに
2. フィードバックの伝え方
- ポジティブなフレーミング(サンドイッチ法)
- ◎「この関数、命名が明快でいいですね」
- △「ただ、例外処理が抜けているので、
try/catch
を追加するとさらに堅牢になります」 - ◎「全体的にテストカバレッジも高く、信頼性があると思います」
- 具体性を担保する
- 箇所の特定:「
PlayerController.cs
の 42 行目~48 行目のロジック」 - 理由の明示:「ここで
null
チェックを入れないと、シーン切り替え時に例外が発生します」
- 箇所の特定:「
- 建設的な表現
- NG:「ここダメです」
- OK:「こちらの動作は想定外のケースで例外が投げられる可能性があります。こうすると防げるかと思います」
- 提案ベースで提示
- 代替案の提示
// Before var tmp = CalculateScore(user); // After var userFinalScore = CalculateUserFinalScore(user);
- 「このユーティリティメソッドを共通化して使い回すとメンテしやすくなります」
- 代替案の提示
- 双方向コミュニケーション
- 質問を投げかける
- 「こちらの設計、どういう想定で書かれましたか?」
- フォローアップ
- 修正後に「この修正で意図はクリアになりましたか?」と確認
- 質問を投げかける
演習例
- ロールプレイ演習
- レビュアー役と開発者役に分け、実際のPRを用いてフィードバック演習
- フィードバックシート活用
- 「状況」「行動」「影響」「提案」「質問」の欄を設けたシートで練習
- 振り返りセッション
- 良かった点・改善点をグループで共有し、ベストプラクティスをまとめる
ディスカッション
コメント一覧
まだ、コメントがありません