コードレビュー時間

計算式と考え方

1PRのレビュー時間は「変更行数 ÷ レビュー速度」で求めます。300行を時速300行でレビューすれば1時間です。チーム全体の週間工数は「1PRの時間 × 週のPR数 × レビュー人数」で、20件を2人ずつレビューすれば週40時間になります。6人チームなら1人あたり週6.7時間、週40時間稼働の約17%がレビューに費やされる計算です。マージまでのリードタイムは、レビュー着手までの待ち時間にレビュー時間を加えたもので、待ち8時間なら約10時間になります。

レビューの目安

コードレビュー時間の詳しい解説

コードレビューは品質確保の中心的な工程ですが、時間の使い方を設計しないと開発の律速要因になります。最も影響が大きいのがPRの大きさです。研究や実務の知見では、1回のレビューで効果的に見られるのは400行程度までとされ、それを超えると欠陥の発見率が急激に下がります。1,000行のPRは、レビュアーが細部まで確認できずに承認してしまう典型的なパターンで、レビューの形骸化を招きます。対策は、変更を小さく分割してPRを出すことです。機能単位ではなく、レビューしやすい単位で分けるという発想の転換が必要になります。チーム全体で見ると、レビューは稼働時間の1割から2割を占める規模になることがあり、これは無視できる工数ではありません。人数を増やせば1人あたりの負担は下がりますが、レビュアーを何人に設定するかで総工数は比例して増えます。2人体制が一般的とされるのは、1人では見落としのリスクが残り、3人以上では調整の手間が発見できる欠陥の増分を上回りやすいためです。リードタイムも重要な指標です。PRを出してからレビューされるまでの待ち時間が長いと、開発者は次の作業に移り、指摘を受けた時点で文脈を思い出す負荷が生じます。24時間以内のレビューが健全とされ、これを実現するにはレビューを手が空いたらやる作業ではなく、優先度の高い定常業務として位置づける必要があります。朝の時間帯にレビューをまとめて行う運用や、レビュー担当を輪番で決める方法が採られます。レビューの内容についても、人間が見るべき点と自動化できる点を分けることが効率化につながります。書式、命名規則、明らかなバグパターンは静的解析ツールとリンターで検出でき、人間は設計の妥当性、要件との整合、保守性といった判断が必要な部分に集中すべきです。この分業ができていないチームでは、レビューコメントの大半が書式の指摘に費やされ、本質的な議論に至りません。運用を定着させるには、何を見るかの合意も必要です。観点が人によって違うと、同じ変更でも指摘の内容が揺れ、修正の往復が増えます。設計方針やコーディング規約を明文化し、レビューの範囲を共有しておくと議論が短くなります。すべての変更を同じ重さで見る必要もありません。影響範囲の大きい変更は複数人で丁寧に、定型的な修正は1人で短時間にと重みづけを変えることで、全体の工数を抑えられます。ここで挙げた数値は目安であり、実際の所要時間はコードの複雑さやチームの習熟度によって変わります。

業界・現場での使い方

よくある間違い・注意点

• 大きなPRを出す — 400行を超えると欠陥の発見率が急落します。レビューしやすい単位に分割してください。
• レビューを後回しにする — リードタイムが延び、開発の流れが滞ります。優先度の高い定常業務として位置づけてください。
• 書式の指摘に時間を使う — 静的解析ツールで自動化できます。人間は設計と要件の整合に集中すべきです。

関連する規格・法規

• 業界標準
• ISO/IEC規格

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール