【決定版】コードが書けないPjMでもチームを救える！「質の高いコードレビュー」で実践する戦略的3つの視点
こんばんは！IT業界で働くアライグマです！
「コードレビュー、皆さんのチームでは形骸化していませんか？」
プルリクエスト（マージリクエスト）が作られても、流れるようにLGTM（Looks Good To Me）のスタンプが押されていくだけ。あるいは、実装の細かすぎる部分にだけ指摘が集中し、本来議論すべき本質が見過ごされてしまう…。多くの開発現場で、コードレビューは「やるべきこと」と分かっていながら、その価値を最大限に引き出せていないのが現実ではないでしょうか。
特に、自身ではコードを書かない、あるいは書く機会が減ったPjM（プロジェクトマネージャー）やテックリードの中には、「自分がレビューしても、的確な指摘ができないのでは…」と、レビューに対して少し及び腰になってしまう方もいるかもしれません。
しかし、それは大きな誤解です。PjMだからこそ、エンジニアとは違う視点から、プロジェクトの品質を劇的に向上させる、極めて価値の高いレビューができるのです。今日は、単なる「間違い探し」ではない、チームとプロダクトを育てるための「戦略的コードレビュー」について、私が実践する3つの視点をご紹介します。
なぜ、今「レビューの質」が重要なのか？
本題に入る前に、なぜ私たちが「レビューの質」にこだわるべきなのか、その理由を共有させてください。質の高いコードレビューは、単にバグを見つけるだけでなく、以下のような、計り知れないほどの副次的な効果をチームにもたらします。
- 属人性の排除と知識の共有: 一人のエンジニアが書いたコードを、チームの複数の目でチェックすることで、「その人にしか分からない」というブラックボックス化を防ぎます。レビューは、チーム全体の知識レベルを底上げする、最高の勉強会の場なのです。
- 品質基準の浸透: レビューを通じて、「私たちのチームでは、ここまでの品質を求める」という暗黙の基準が、自然とチーム全体に浸透していきます。これにより、コードの品質が安定し、長期的な保守性が向上します。
- コミュニケーションの活性化: コードという「事実」をベースにした対話は、チーム内の健全な技術的コミュニケーションを促進します。お互いの実装から学び、リスペクトし合う文化が生まれます。
この前提を理解するだけで、レビューに臨むあなたの意識は大きく変わるはずです。
視点1：「仕様」は、正しく実装されているか？（PjMの最重要責務）
PjMのコードレビューにおける、最も重要で、かつあなたにしかできない役割。それは、「そのコードが、私たちが合意した『仕様』を、本当に満たしているか？」という観点でのレビューです。
エンジニアは、しばしば「どう作るか（How）」に集中するあまり、その機能の「なぜ（Why）」や「何（What）」を見失うことがあります。あなたの仕事は、そのズレを誰よりも早く発見し、修正することです。
具体的なチェックポイント
レビューに臨む際は、必ず手元に最新の仕様書や、関連するユーザーストーリーのチケットを開いておきましょう。そして、以下の点を確認します。
- 要求事項の充足: 仕様書に書かれた「〇〇ができること」という要求事項は、全て満たされていますか？逆に、仕様書にない機能が、こっそり追加されていませんか？
- 異常系の考慮: 仕様書で定義したエラーハンドリング（例：「不正な値が入力されたら、400エラーとメッセージを返す」）は、正しく実装されていますか？「このパターンだと、仕様書にある例外ケース〇〇の考慮が漏れていませんか？」といった指摘は、極めて価値が高いです。
- データ形式の整合性: APIのレスポンスや、データベースに保存されるデータの形式は、仕様書で定義した通りですか？キーの名前、データ型、桁数などをチェックします。
このレビューは、コードの書き方の巧拙を問うものではありません。あくまで、「約束事を、守れているか？」を確認する作業です。
視点2：「命名」は、第三者に伝わるか？（未来のコード品質への投資）
次に重要なのが、「命名（ネーミング）」のレビューです。これは、コードが書けないPjMでも、いや、コードを毎日書かないPjMだからこそ、客観的に指摘できる重要なポイントです。
良い命名は、半年後の自分、そしてチームに新しく加わったメンバーを救います。変数名や関数名を見ただけで、その役割が瞬時に理解できるコードは、それだけでドキュメントとしての価値を持ち、バグの温床となる誤解を防ぎます。
具体的なチェックポイント
- 曖昧な名前を避ける:
$data$list$flag$tmpといった、意味の広い単語が使われていないか。- 悪い例:
$data = getUsers(); - 良い指摘: 「この
$dataは、具体的に何を含んでいますか？ 例えば$active_usersのように、より具体的な名前にできませんか？」
- 悪い例:
- ビジネス用語と一致しているか: 仕様書や普段の会話で使っているビジネス用語（例：「請求書」「顧客ランク」）と、コード内の変数名が一致しているか。この一致が、エンジニアとビジネスサイドの会話をスムーズにします。
- 悪い例:
$info = getCustomerRank(); - 良い指摘: 「
$infoではなく、仕様書に合わせて$customer_rankという名前にしませんか？」
- 悪い例:
- 長すぎる、あるいは略しすぎている名前: 極端に長い名前は可読性を下げ、不適切な略語は誤解を生みます。チーム内で、命名規則のガイドラインを作るのも良いでしょう。
良い命名規則は、未来のバグを減らし、新しいメンバーの学習コストを下げる、最も費用対効果の高い「品質への投資」なのです。
視点3：「コメント」は、「なぜ」このコードが必要かを語っているか？
コードレビューで最後に見るべきは、「コメント」です。ただし、見るべきはコメントの量ではありません。その「質」です。
最悪なコメントは、「コードを見ればわかること」を、そのまま日本語で書いているコメントです。
- 悪いコメントの例:
// ユーザーIDを取得 - コード:
$user_id = $request->user()->id;
このようなコメントは、コードの変更に追従できずに嘘の情報になったり、コードの可読性をむしろ下げたりする「ノイズ」にしかなりません。
では、良いコメントとは何か？それは、「何をしているか（How）」ではなく、「なぜ、このような実装にしたのか（Why）」を語っているコメントです。
- 良いコメントの例:
// パフォーマンス上の理由から、通常はキャッシュを利用すべき箇所。しかし、〇〇という特殊な要件（ユーザーのリアルタイムな反映が必須）に対応するため、あえてここではキャッシュを使わずに直接DBを呼び出しています。
このような「実装の背景」や「設計上の意図」を説明するコメントは、コードだけでは絶対に伝わりません。この「Why」のコメントが、半年後の自分自身や、後任のエンジニアが仕様を誤解し、バグを生み出すのを防ぐ、最高の道標となるのです。
まとめ：PjMのレビューは「未来」を見ている
もうお分かりいただけたかと思います。
PjMが行うべきコードレビューは、コードの細かなアルゴリズムや、トリッキーなテクニックを評価することではありません。
- 仕様とコードの「現在」が、正しく一致しているか。
- 命名やコメントによって、「未来」のエンジニアが迷わないか。
- 実装の背景にある「過去」の意思決定が、正しく記録されているか。
このように、時間軸を行き来しながら、プロジェクト全体の健全性を保つこと。これこそが、PjMにしかできない、本当に価値のあるコードレビューです。
たとえあなたが1行もコードを書けないPjMだったとしても、この3つの視点を持つだけで、あなたはチームにとってかけがえのない、最高の「品質保証担当者」になることができるのです。