進行管理の週次レビュー:遅れを「発見する日」を先に決める
遅れは起きた日ではなく、気づいた日に問題になります。私は週次レビューを「進捗を報告する会」ではなく「遅れを発見する日」として設計しています。曜日の決め方と、当日に見る3点を書きます。
進行管理でいちばん効くのは、進捗率を細かく取ることではなく、遅れを発見する日を曜日で固定しておくことだと考えています。遅れそのものは避けられません。避けられるのは、遅れに気づくのが遅れることのほうです。私は週次レビューを「進捗を報告する会」ではなく「遅れを見つけるための時間」として置いています。
遅れは「起きた日」ではなく「気づいた日」に問題になる
1日の遅れは、その日のうちに分かればほぼ何も起きません。同じ1日でも、2週間後に分かると、その間に積み上がった後工程をまとめて動かすことになります。デザインの戻しが1日ずれただけのつもりが、実装の着手日と検証期間と公開日にそのまま伝わっていく。私は一人でディレクションから実装まで往復することが多いので、この「自分の中で持ち越してしまう遅れ」を何度も経験しました。
だから週次レビューの目的は、進捗を数字で確認することではありません。今週ずれた事実を、今週のうちに外に出すことです。目的がそこにあると、会の設計が変わります。全タスクを読み上げる必要はなくなり、ずれた線だけを見ればよくなります。
固定した日を持つ効果は、アジャイル側の枠組みでも似た形で言語化されています。スクラムガイドは、デイリースクラムを「スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させること」を目的とする15分のイベントとし、スプリントの毎営業日、同じ時間・同じ場所で行うと書いています(Scrum Guide)。同じ時間・同じ場所、というところが要点です。開催するかどうかを毎回判断しないで済むことに価値があります。
曜日は「直せる余地が残っている日」に置く
週次レビューを金曜の夕方に置いている現場をよく見ますが、私は基本的に火曜か水曜に置いています。理由は単純で、金曜に遅れが見つかっても、その週で手を打てないからです。翌週に持ち越した時点で、発見と対応のあいだに土日が挟まります。
週の前半に置くと、こうなります。
| 置く曜日 | 発見してから動ける時間 | 起きやすいこと |
|---|---|---|
| 月曜 | 週いっぱい | 週末を挟むので情報が古い、報告が薄い |
| 火・水曜 | 残り3日前後 | その週のうちに順番を組み替えられる |
| 金曜 | 実質ゼロ | 「来週やります」で終わる |
月曜を外しているのは、金曜の終業から時間が空いていて、状況が更新されていないことが多いからです。火曜まで待つと、月曜の実作業が1日分入っているので、話す材料がある。関係者が多い案件では、火曜レビュー→水曜に外部への連絡、という並びにしておくと、相手側の対応時間も確保できます。
当日に見るのは3点だけ
レビューを短く保つために、見る対象を先に絞っています。私は次の3点で回しています。
- 予定と実績の差が出ている作業(全部ではなく、ずれている行だけ)
- 今週着手予定なのに、まだ前提が揃っていない作業
- 来週の判断待ち(誰の、いつまでの決定が要るか)
1については、比較の相手になる「最初の予定」を残しておく必要があります。Microsoft Projectでいうベースラインの考え方で、ドキュメントには、下のバーがベースラインの開始日・終了日、上のバーが現在のスケジュールを示し、計画と現在のスケジュールの差が見えると説明されています。差分そのものを見るには、進捗の追跡でベースラインと実績・予定の開始/終了日を比較する方法が案内されています(Review the progress of your schedule、Set and save a baseline)。
専用ツールを使わない小さめの案件でも、やることは同じです。スプレッドシートに「当初の終了日」列を1本足して、そこは触らない。触らない列があるだけで、ずれは自動的に見えます。逆にいうと、予定を上書きし続けている表からは、遅れは永久に発見できません。
3を入れているのは、遅れの多くが作業ではなく決定の待ち時間から出るからです。「先方の写真選定待ち」のような行は、作業表の中では進捗0%のまま静かに置かれがちで、誰も遅れとして数えません。週次で「これは誰がいつまでに決めるか」を毎回聞くと、待ちが可視化されます。
報告ではなく、順番の組み替えで終える
レビューの出口を「共有できました」で終えると、次の週も同じ行が同じ状態で出てきます。私は最後に、今週の残りの順番をどう変えるかを1つだけ決めるようにしています。追加のリソースがない前提でも、着手順を変える、検証の一部を前倒す、決定を待つ間に別の作業を差し込む、といった打ち手は残っていることが多い。
決めたら、その場でスケジュール表に反映してから閉じます。会の後に反映しようとすると、だいたい翌週に持ち越します。ここは自分に対しても同じで、一人案件でも「レビューの時間内に表を直す」を守っています。
なお、この週次レビューは、成果物そのものを見る場とは分けています。スクラムガイドは、スプリントレビューの目的を「スプリントの成果を検査し、今後の適応を決定すること」とし、1か月スプリントで最大4時間のタイムボックスとしています(Scrum Guide)。中身を見る会と、線のずれを見る会は、必要な人も必要な時間も違います。私は後者を30分に収めることを目安にしています。
明日から試せる一手
カレンダーに、来週から毎週火曜の同じ時間で30分の予定を1本入れてください。名前は「進捗共有」ではなく「遅れの発見」にします。そして今使っているスケジュール表に、上書きしない「当初の終了日」列を1本だけ足してください。この2つがあれば、次の火曜には、ずれている行が自分で目に入ってきます。