レビューをしても、指摘が次のバージョンで直っていない。同じ指摘が2度・3度と繰り返される。こういった状況はプロジェクトの品質管理として問題ですが、「反映されていない」ことを確認する仕組みが整っていないと、PMも把握できません。
レビュー後に指摘が反映されているかどうかを確認するのは、担当者を監視することではありません。「反映済みであることを確認する」という品質保証のステップです。この記事では、レビュー指摘の管理フローを整理します。
レビュー指摘が反映されない理由
指摘が反映されない原因はいくつかのパターンがあります。
担当者が指摘内容を正確に理解していない — 「このロジックを修正してください」という指摘が、どこをどう修正すればいいか分からないまま放置されているケースです。
優先度が下がって後回しにされている — 指摘はあったが、他の作業が優先されて手をつけられていないケースです。締め切り直前に気づきます。
対応方針が決まっていない — 指摘に対して「修正するか・対応しないか・後回しにするか」の判断がなく、宙に浮いたままになっているケースです。
どのパターンも「指摘をアクションに変換するステップ」がないことで起きます。
指摘をアクション化する
レビューで指摘が出たとき、その場でアクションに変換します。
アクション化に必要な情報は次の3つです。
- 何をするか（具体的な修正内容）
- 誰がするか（担当者名）
- いつまでにするか（期限）
「ここを直してください」という指摘を、「〇〇ページの〇〇の処理を□□に修正する（担当：〇〇、期限：〇月〇日）」という形に変換します。
この変換作業をレビューその場でやるのが理想ですが、難しければレビュー後に議事録やチケットで整理します。大切なのは「指摘がタスクとして誰かのToDoに入ること」です。
対応方針を確認する
すべての指摘が「修正する」になるとは限りません。指摘に対しては4つの対応方針があります。
- 修正する — 指摘通りに対応する
- 別の方法で対応する — 指摘の意図は受け入れるが、異なる実装方針で解決する
- 対応しない（理由あり） — 仕様上の理由や工数上の判断で対応しない
- 後回しにする（条件付き） — 今回のリリースでは対応せず、次フェーズに持ち越す
「対応しない」という選択肢を持っておくことで、工数の現実的なコントロールができます。すべての指摘を修正しようとすると工数が読めなくなります。「今回対応するもの」「後回し」「対応不要」に仕分けることで、品質管理が回し続けられる状態になります。
ただし「対応しない」場合は理由を記録します。後で「なぜ対応しなかったのか」を確認できるようにしておきます。
反映確認の基準を決める
「修正した」という連絡をもらったとき、PMはどうやって確認しますか。
口頭の「直しました」で完了にするのか、チケットのステータス変更で確認するのか、実際に成果物を見るのかによって、確認の確度が変わります。
最低限決めておくべきなのは次の2点です。
- 「修正完了」の報告方法（チケット更新・Slack通知・メールなど）
- PMが確認するタイミングと方法
全件をPMが目視確認するのは現実的ではないので、「重要度の高い指摘はPMが確認、それ以外はリーダーが確認してから報告」という役割分担でも構いません。
再レビューのタイミング
修正が完了した後、再レビューが必要かどうかを判断します。
軽微な修正（誤字・表現変更・数値の修正など）は再レビュー不要のケースが多いです。設計・ロジックの変更を伴う修正は、再レビューが必要です。
再レビューのタイミングを事前に決めておかないと、「修正したはずが反映されていなかった」という事態が本番前に発覚します。特に品質に影響する指摘は、「修正後にレビュアーが確認する」というステップをタスクに明示します。
同じ指摘を減らす
同じ指摘が繰り返される場合、それは個人の問題ではなくチームの問題です。
同じ指摘が3件以上あれば、チェックリスト化する価値があります。「このタイプのミスが起きやすい」という認識をチームで共有し、成果物を作る段階でセルフチェックできるようにします。
「なぜ同じ指摘が繰り返されるか」の原因を確認し、それが「知識不足」なら教育機会を作る、「確認を省いている」なら確認ステップをルール化する、という対応につながります。
まとめ
レビュー指摘の管理は「指摘する」で終わりではなく、「アクション化→対応方針確認→反映確認→再レビュー」の流れを持つことで機能します。
この流れを持っていると、同じ指摘の繰り返しが減り、品質の安定につながります。個人の注意力に頼るのではなく、仕組みとして運用します。
品質管理・炎上予防の実務力を高めたい方は、品質管理・炎上予防系の講座や受託開発PM向けの課題別パックをご覧ください。