PLのレビューと進捗確認: 遅れを責めずにリスクを早く見つける

PLとして進捗を確認するときに大切なのは、遅れた人を責めることではありません。

本当に見るべきなのは、チームの中にあるリスクです。

実装が遅れているのか、仕様が決まっていないのか、レビューが詰まっているのか、影響範囲が広がっているのか。原因によって必要な対応は変わります。

この記事では、PLがレビューと進捗確認で意識したいことを整理します。

進捗確認は「完了率」だけでは分からない

「何パーセント終わっていますか？」という確認は、あまり役に立たないことがあります。

開発の作業は、最後の20%に難しい問題が残りやすいからです。

たとえば、画面はほぼできていても、次のような問題が残っていることがあります。

• APIのエラー仕様が決まっていない
• 権限ごとの表示条件が未確認
• 既存データで例外が出る
• レビューで設計の修正が必要になった
• テストデータが用意できていない

そのためPLは、完了率よりも「何が残っているのか」を確認する必要があります。

聞き方を変える

進捗確認では、聞き方がとても大切です。

進んでいますか？

と聞くと、相手は「はい、進んでいます」と答えやすくなります。

一方で、次のように聞くと具体的な状況が見えます。

今日の時点で、判断待ちになっていることはありますか？

レビュー前に不安な点はありますか？

想定より時間がかかっている箇所はどこですか？

PLは、報告を待つだけではなく、詰まりが表に出やすい聞き方をすることが大切です。

レビューは品質確認だけではない

レビューというと、コードの間違いを見つける作業だと思われがちです。

もちろん品質確認は重要です。

ただし、PL視点のレビューでは、コードの正しさだけでなく、プロジェクト全体への影響も見ます。

• 仕様どおりか
• 既存機能に影響しないか
• 変更範囲が広がりすぎていないか
• テストしやすい形になっているか
• 今後の保守で困らないか
• リリース前に確認すべきことが残っていないか

レビューは、品質を上げるためだけでなく、リスクを早く見つけるための場です。

レビュー前に観点をそろえる

レビューで手戻りが大きくなる原因の一つは、レビュー観点がそろっていないことです。

実装者はUIの動作を見ていて、レビュアーはAPI設計を見ている。仕様担当者は業務ルールを見ている。この状態だと、後から抜け漏れが発覚しやすくなります。

レビュー前に、最低限次の観点をそろえておくとよいです。

今回レビューしてほしいこと:
- 仕様どおりの動作になっているか
- エラー時の表示が適切か
- 既存の登録処理に影響がないか

今回レビュー対象外のこと:
- 画面デザインの大幅な変更
- 認証方式そのものの見直し

対象と対象外を明確にすると、レビューの精度が上がります。

遅れを見つけたら、原因を分ける

遅れが見えたとき、すぐに「急いでください」と言っても解決しないことが多いです。

まずは原因を分けます。

• 作業量の見積もりが甘かった
• 仕様確認が止まっている
• 技術的な調査が必要になった
• レビュー待ちで進めない
• 他タスクとの優先順位が曖昧
• そもそも完了条件が広がっている

原因が違えば、対応も違います。

仕様確認が止まっているなら、確認先を決める。レビュー待ちなら、レビュアーを調整する。作業量が増えたなら、スコープを見直す。

PLは、遅れを責めるより先に、遅れの構造を見に行く必要があります。

状況共有は短く、判断できる形にする

PLは関係者へ状況を伝える場面も多くなります。

そのとき、細かい作業内容をすべて説明する必要はありません。

重要なのは、相手が判断できる形にすることです。

現在の状況:
登録画面の実装は完了。APIエラー時の表示確認が残っています。

リスク:
既存APIのエラー形式が画面仕様と合っていない可能性があります。

対応案:
1. 画面側で既存形式に合わせる
2. API側のエラー形式を調整する

確認したいこと:
今回は画面側で吸収してよいか判断をお願いします。

このように、状況、リスク、対応案、判断してほしいことを分けると、関係者も動きやすくなります。

まとめ

PLのレビューと進捗確認で大切なのは、遅れを見つけて責めることではありません。

チームの中にあるリスクを早く見つけ、対応できる形にすることです。

進捗確認では、完了率ではなく残っている不確実性を見る。レビューでは、コードの正しさだけでなく、仕様・影響範囲・テスト・リリースリスクを見る。

PLは、問題を大きくする前に表に出す役割です。

そのためには、問い方、レビュー観点、状況共有の形を整えることが重要です。