3日で終わる予定だった作業に、実際は5日かかったとします。管理表の「3日」を「5日」に直すと、実績には合います。ただ、最初の見積もりが消えると、どれだけずれたのか、なぜずれたのかを後から確認しにくくなります。今回は、予定と実績の両方を残す書き方を考えます。
この記事のポイント
当初計画、実績、現在の予測は別々に記録します。今の見通しを更新しながら、最初の見積もりや変更理由も残しておくと、次回の計画を考えるときに使えます。
当初計画・実績・予測を別の欄に書く
比較するときは、数字の単位をそろえてください。人日で表す工数と、開始から完了までの期間は違います。正式に計画を立て直す場合も、前の計画と変更理由を残しておけば、後から経緯を確認できます。
| 項目 | 記録するもの |
|---|---|
| Plan | 当初合意した予定値 |
| Actual | 実際にかかった工数や期間 |
| Forecast | 現時点で予測する着地 |
| Variance | 計画と実績、または計画と予測の差 |
| Reason | 差が生じた理由と、確認できた事実 |
当初計画を残しながら、現在の予測を更新する
進行中の作業が遅れそうなら、わかった時点で予測を更新して共有します。最初の数字だけでは、今どのくらい遅れそうか、調整が必要かを判断できません。
当初計画も残しておくと、今の見通しと、予定から何が変わったかを両方確認できます。計画の変更は必要に応じて行い、その理由が後からわかるようにしておきます。
予定との差が出た理由を調べる
QAに予定より時間がかかったとしても、理由はいろいろ考えられます。仕様の確認に時間がかかったのか、環境を待っていたのか、観点が増えたのか、不具合の再確認が必要だったのかを調べます。
かかった日数だけで品質や個人の能力を判断するのは難しいものです。何に時間を使ったかを記録しておくと、次の見積もりに余裕を持たせる、環境を早めに準備するといった対応を考えられます。
状況が変わったら計画も見直す
Scrum Guideでも、Sprint Backlogは新しくわかったことに応じて更新する計画として説明されています。この記事で紹介した項目分けは、Scrumで必須とされる形式ではありません。見通しと変更の履歴を共有するための一例です。
予定との差が残っていると、表がそろっていないように見えるかもしれません。でも、その差と理由が、次の計画を考えるときの資料になります。数字を見ながら「次は何を変えられるか」を話せるとよいと思います。