目次
はじめに
「プロジェクトリーダーはコーディングレビューまで担当するものなのだろうか」
「テックリードや開発者との役割分担が曖昧で、誰がレビューすべきか判断できない」と感じていませんか。
プロジェクトを進める中で、コードレビューの依頼先が人によって違ったり、PLがすべて確認していたりすると、本来の役割が分からなくなってしまいますよね。
この記事では、プロジェクトリーダーがコーディングレビューにどこまで関わるのかを整理し、PL・テックリード・開発者それぞれの役割や、チームでの適切な分担の考え方を順を追って説明していきます。
プロジェクトリーダーがコーディングレビューをするとは限らない？
プロジェクトリーダーが必ずコーディングレビューを担当するとは限りません。
ここでは、レビュー担当がどのように決まるのかという基本的な考え方と、プロジェクトリーダーがレビューを担当する代表的なケースについて順を追って見ていきます。
結論はチーム体制によって異なる
プロジェクトリーダーが必ずコーディングレビューを担当するわけではなく、レビュー担当者はチーム体制によって異なります。
小規模チームではプロジェクトリーダーがレビューを行うこともありますが、開発体制によってはテックリードやシニアエンジニアが担当するケースも少なくありません。
そのため、誰がレビューを担当するかは、役職ではなくプロジェクトごとの役割分担によって決まります。
プロジェクトリーダーがレビューするケース
プロジェクトリーダーがコーディングレビューを担当するのは、小規模プロジェクトや、専任のテックリード・シニアエンジニアがいないチームでよく見られます。
また、設計方針や実装ルールをチーム全体で統一したい場合にも、プロジェクトリーダーがコードを確認することがあります。
このような体制では、進捗管理とあわせてレビューも担当し、品質を維持する役割を担います。
コーディングレビューは誰が担当することが多い？
まずは、実際の開発現場でコーディングレビューを担当することが多い役割を確認しておきましょう。
ここでは、代表的なレビュー担当者と、それぞれがレビューを担当する理由について順を追って説明していきます。
同じチームの開発者
コーディングレビューは、同じチームの開発者が担当することが多くあります。
日頃から同じシステムを開発しているため、設計方針やコーディング規約を理解しており、実装内容との整合性を確認しやすいからです。
また、担当外の開発者がレビューすることで、実装ミスや見落としにも気付きやすくなります。
テックリード
テックリードがコーディングレビューを担当するケースも多くあります。
設計方針やアーキテクチャを決める立場のため、実装内容が設計どおりか、品質基準を満たしているかを確認します。
特に、重要な機能や共通ライブラリの変更では、最終レビューを担当することもあります。
シニアエンジニア
シニアエンジニアがコーディングレビューを担当することも一般的です。
保守性や可読性、性能まで考慮してコードを確認できるため、品質を維持する重要な役割を担います。
また、経験の浅い開発者へ改善点を伝えることで、チーム全体の技術力向上にもつながります。
プロジェクトリーダー
プロジェクトリーダーがレビューを担当するのは、開発人数が少ないプロジェクトや、レビューを兼務する体制でよく見られます。
実装内容が設計方針や開発計画に沿っているかを確認しながら、品質を保つ役割を担います。
ただし、レビュー担当はチーム体制によって決まるため、プロジェクトリーダーが必ず担当するわけではありません。
プロジェクト規模によるレビュー担当者の違い
コーディングレビューの担当者は、プロジェクトの規模によって変わります。
ここでは、小規模・中規模・大規模プロジェクトそれぞれで、誰がレビューを担当することが多いのかを順を追って説明していきます。
小規模プロジェクト
小規模プロジェクトでは、開発人数が少ないため、同じチームの開発者やプロジェクトリーダーがコーディングレビューを担当することが一般的です。
専任のレビュアーを置かず、開発とレビューを兼務しながら進めるケースが多くあります。
そのため、コードの内容だけでなく、設計方針やコーディング規約との整合性もあわせて確認します。
中規模プロジェクト
中規模プロジェクトでは、テックリードやシニアエンジニアがコーディングレビューを担当することが多くあります。
プロジェクトリーダーは進捗管理や関係者との調整を担当し、レビューは技術的な責任者へ分担する体制がよく採られます。
そのため、実装内容や設計方針との整合性を確認しながら、品質を維持します。
大規模プロジェクト
大規模プロジェクトでは、テックリードやシニアエンジニア、担当チームの開発者など、役割ごとにレビューを分担することが一般的です。
複数チームで開発を進めるため、プロジェクトリーダーがすべてのコードを確認することは現実的ではありません。
そのため、担当領域ごとにレビューを行い、必要に応じて技術責任者が最終確認を担当します。
最終承認者と実際のレビュアーは違うことがある
まずは、コーディングレビューの担当者と最終承認者の役割の違いを整理しておきましょう。
ここでは、それぞれが確認する内容や役割の違いについて順を追って説明していきます。
レビュー担当者が確認する内容
レビュー担当者は、実装内容が設計方針やコーディング規約に沿っているかを確認します。
あわせて、処理に誤りがないか、不要なコードが含まれていないか、命名規則やコードの読みやすさに問題がないかもチェックします。
修正が必要な箇所はコメントで伝え、指摘内容が反映されたことを確認したうえで、レビューを完了します。
最終承認者が確認する内容
最終承認者は、レビュー担当者の確認結果を踏まえ、コードを開発ブランチや本番環境へ反映して問題ないかを最終的に判断します。
レビューで指摘された内容がすべて修正されていることや、承認に必要な条件を満たしていることを確認したうえで、マージやリリースを承認する役割を担います。
まとめ
プロジェクトリーダーが必ずコーディングレビューを担当するわけではなく、実際の担当者はプロジェクトの規模やチーム体制によって異なります。
小規模プロジェクトではプロジェクトリーダーが兼務することもありますが、中規模・大規模プロジェクトでは、テックリードやシニアエンジニアなどが担当するケースも一般的です。
大切なのは、役職だけで担当者を決めるのではなく、プロジェクトごとの役割や責任範囲に合わせてレビュー体制を整えることです。
自社の開発体制に合った役割分担を行うことで、品質を保ちながら、開発をよりスムーズに進めやすくなります。