//
2026.09.08/4 min read#pm#direction

進行管理の週次レビュー:遅れを「発見する日」を先に決める

遅れは起きた日ではなく、気づいた日に問題になります。私は週次レビューを「進捗を報告する会」ではなく「遅れを発見する日」として設計しています。曜日の決め方と、当日に見る3点を書きます。

進行管理でいちばん効くのは、進捗率を細かく取ることではなく、遅れを発見する日を曜日で固定しておくことだと考えています。遅れそのものは避けられません。避けられるのは、遅れに気づくのが遅れることのほうです。私は週次レビューを「進捗を報告する会」ではなく「遅れを見つけるための時間」として置いています。

遅れは「起きた日」ではなく「気づいた日」に問題になる

1日の遅れは、その日のうちに分かればほぼ何も起きません。同じ1日でも、2週間後に分かると、その間に積み上がった後工程をまとめて動かすことになります。デザインの戻しが1日ずれただけのつもりが、実装の着手日と検証期間と公開日にそのまま伝わっていく。私は一人でディレクションから実装まで往復することが多いので、この「自分の中で持ち越してしまう遅れ」を何度も経験しました。

だから週次レビューの目的は、進捗を数字で確認することではありません。今週ずれた事実を、今週のうちに外に出すことです。目的がそこにあると、会の設計が変わります。全タスクを読み上げる必要はなくなり、ずれた線だけを見ればよくなります。

固定した日を持つ効果は、アジャイル側の枠組みでも似た形で言語化されています。スクラムガイドは、デイリースクラムを「スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させること」を目的とする15分のイベントとし、スプリントの毎営業日、同じ時間・同じ場所で行うと書いています(Scrum Guide)。同じ時間・同じ場所、というところが要点です。開催するかどうかを毎回判断しないで済むことに価値があります。

曜日は「直せる余地が残っている日」に置く

週次レビューを金曜の夕方に置いている現場をよく見ますが、私は基本的に火曜か水曜に置いています。理由は単純で、金曜に遅れが見つかっても、その週で手を打てないからです。翌週に持ち越した時点で、発見と対応のあいだに土日が挟まります。

週の前半に置くと、こうなります。

置く曜日 発見してから動ける時間 起きやすいこと
月曜 週いっぱい 週末を挟むので情報が古い、報告が薄い
火・水曜 残り3日前後 その週のうちに順番を組み替えられる
金曜 実質ゼロ 「来週やります」で終わる

月曜を外しているのは、金曜の終業から時間が空いていて、状況が更新されていないことが多いからです。火曜まで待つと、月曜の実作業が1日分入っているので、話す材料がある。関係者が多い案件では、火曜レビュー→水曜に外部への連絡、という並びにしておくと、相手側の対応時間も確保できます。

当日に見るのは3点だけ

レビューを短く保つために、見る対象を先に絞っています。私は次の3点で回しています。

  1. 予定と実績の差が出ている作業(全部ではなく、ずれている行だけ)
  2. 今週着手予定なのに、まだ前提が揃っていない作業
  3. 来週の判断待ち(誰の、いつまでの決定が要るか)

1については、比較の相手になる「最初の予定」を残しておく必要があります。Microsoft Projectでいうベースラインの考え方で、ドキュメントには、下のバーがベースラインの開始日・終了日、上のバーが現在のスケジュールを示し、計画と現在のスケジュールの差が見えると説明されています。差分そのものを見るには、進捗の追跡でベースラインと実績・予定の開始/終了日を比較する方法が案内されています(Review the progress of your scheduleSet and save a baseline)。

専用ツールを使わない小さめの案件でも、やることは同じです。スプレッドシートに「当初の終了日」列を1本足して、そこは触らない。触らない列があるだけで、ずれは自動的に見えます。逆にいうと、予定を上書きし続けている表からは、遅れは永久に発見できません。

3を入れているのは、遅れの多くが作業ではなく決定の待ち時間から出るからです。「先方の写真選定待ち」のような行は、作業表の中では進捗0%のまま静かに置かれがちで、誰も遅れとして数えません。週次で「これは誰がいつまでに決めるか」を毎回聞くと、待ちが可視化されます。

報告ではなく、順番の組み替えで終える

レビューの出口を「共有できました」で終えると、次の週も同じ行が同じ状態で出てきます。私は最後に、今週の残りの順番をどう変えるかを1つだけ決めるようにしています。追加のリソースがない前提でも、着手順を変える、検証の一部を前倒す、決定を待つ間に別の作業を差し込む、といった打ち手は残っていることが多い。

決めたら、その場でスケジュール表に反映してから閉じます。会の後に反映しようとすると、だいたい翌週に持ち越します。ここは自分に対しても同じで、一人案件でも「レビューの時間内に表を直す」を守っています。

なお、この週次レビューは、成果物そのものを見る場とは分けています。スクラムガイドは、スプリントレビューの目的を「スプリントの成果を検査し、今後の適応を決定すること」とし、1か月スプリントで最大4時間のタイムボックスとしています(Scrum Guide)。中身を見る会と、線のずれを見る会は、必要な人も必要な時間も違います。私は後者を30分に収めることを目安にしています。

明日から試せる一手

カレンダーに、来週から毎週火曜の同じ時間で30分の予定を1本入れてください。名前は「進捗共有」ではなく「遅れの発見」にします。そして今使っているスケジュール表に、上書きしない「当初の終了日」列を1本だけ足してください。この2つがあれば、次の火曜には、ずれている行が自分で目に入ってきます。