「90%完了」という報告が3週間続いたことがあります。
毎週の定例で進捗を聞くと、返ってくる答えは毎回90%でした。嘘をついているわけではありません。本人の感覚としては、確かに残りはわずかだったのだと思います。ただ、その「わずか」が終わらない。
このとき私が困ったのは、遅れていること自体ではなく、遅れの量が分からないことでした。あと1日なのか2週間なのかが分からないと、顧客に何も言えません。
この記事では、計画が動き出した後の話を書きます。進捗をどう測るか、ズレをどう見つけるか、そしてツールで解決できる部分とできない部分について。計画段階で何を決めておくべきかは成功するプロジェクトマネジメントの基本原則の方にまとめました。
目次
1. 進捗率の自己申告はほぼ当てにならない
冒頭の90%が何だったのかを説明します。
その人が担当していたのは、外部システムとの連携部分でした。主要な処理は確かに書き終わっていて、残っていたのは異常系の処理と、相手側の仕様が想定と違っていた箇所の調整でした。
つまり、書いた量としては90%だが、残っている作業の難易度が高いという状態です。しかも残りの作業は、やってみないと量が分からない種類のものでした。
進捗率を人に聞くと、たいていは書いた量の割合が返ってきます。これは自然なことで、自分が今どのくらい進んだかを答えるとき、人は済んだ作業を数えます。残りの難しさを織り込んだ数字を出すのは、実はかなり高度な作業です。
だから私は、進捗率を聞くのをやめました。代わりに聞くようにしたのは「終わっているものはどれか」です。パーセントではなく、個数で答えられる形にします。
2. 作業を小さく割ると進捗が測れるようになる
個数で答えられるようにするには、作業が割れている必要があります。
一つの作業が2週間分の大きさだと、その途中経過は結局パーセントでしか表現できません。逆に1日から3日程度に割れていれば、終わったか終わっていないかの二値で答えられます。二値なら解釈のズレが起きません。
私の目安は、1つの作業が3日を超えたら割るです。3日以内なら、遅れが分かるまでの遅延も最大3日に収まります。
割るときに一緒にやるのが、完了の条件を書くことです。「連携処理を実装する」ではなく「正常系の連携処理が動き、テストが通り、レビューを通過している」と書きます。ここを揃えておかないと、個数を数えても意味が変わってしまいます。完了の定義については成功するプロジェクトマネジメントの基本原則にも書きました。
正直なところ、作業を細かく割るのは面倒です。特に着手前の段階では、何をやるべきかがまだ見えていない部分があるので、割りようがないこともあります。その場合は、まず調査だけを一つの作業として置いて、調査が終わった時点で残りを割り直すようにしています。
3. ズレを見つけるのは進捗ではなく残作業
進捗を測れるようになっても、それだけでは遅れに気づけません。
たとえば全体の60%が終わっていて、日程も60%が経過しているとします。これは一見順調ですが、判断としては不十分です。残りの40%が、残りの日程で終わる保証がどこにもありません。
見るべきなのは、残りの作業を終えるのにあと何日必要かという見込みの方です。これを毎週作り直します。
- 残作業の見込みが残日数より少ない → 順調
- 残作業の見込みが残日数を超えている → その差が現時点での遅れ
冒頭の90%の件も、この形で聞いていれば早く分かりました。「残りは異常系の処理で、相手側の仕様確認が要るので、あと何日かかるか読めません」という答えが出ていたはずです。読めないという情報自体が、極めて重要な報告でした。
そして、この再見積もりを毎週やると、数字が動きます。先週「あと3日」だったものが今週も「あと3日」なら、その1週間は進んでいないということです。進捗率で見ていると、この停滞は見えません。
同じ考え方は予算にも使えます。消化した額ではなく、残作業に必要な額を見る。詳しくはコストを見える化：プロジェクト予算を簡単・効率的に管理する方法に書きました。
4. ツールが解決することと、しないこと
JiraやAsana、Backlogといったプロジェクト管理ツールは、この種の管理をかなり楽にしてくれます。作業を登録して状態を更新していけば、残件数の推移が自動で見られるようになります。
ただ、ツールを入れても解決しない部分がはっきりあります。私が実際に経験した範囲では、次の三つです。
作業の割り方は自動化されない。 ツールは登録されたものを集計するだけなので、2週間分の作業が1件として登録されていれば、やはり進捗は見えません。割るのは人の仕事です。
更新されない状態は検出されない。 忙しくなると、まずチケットの更新が止まります。実態は進んでいるのに画面上は止まったまま、あるいはその逆。私は「更新が3日止まっているものを定例で確認する」という運用で対処していますが、これも人がやっています。
言いにくいことは登録されない。 「たぶん間に合わない」という情報は、チケットのステータスとしては表現しにくいものです。ここは結局、口頭で出てくるかどうかにかかります。リスクが上がってこない問題についてはリスク管理の重要性：ITプロジェクトでのベストプラクティスに詳しく書きました。
SlackやTeamsのようなコミュニケーションツールについても同じことが言えます。情報が流れる経路を作ることはできますが、流すかどうかは人が決めます。ツールの選定に時間をかけるより、何を報告してほしいのかを言葉にする方が効きました。この情報の流れの設計についてはチームワークを高める：ITプロジェクト管理におけるコミュニケーション戦略にまとめています。
5. 終わった後に何を残すか
プロジェクトが終わったら、成果物の確認と振り返りを行います。ここを省くと、次の案件が毎回ゼロから始まります。
私が残すようにしているのは、次の二つです。
見積もりと実績の差。 どの作業がどれだけずれたかを記録しておきます。これがあると、次に似た作業を見積もるときの補正が効きます。感覚で「だいたい1.5倍かかる」と言うより、記録がある方が説得力もあります。
どこで気づくのが遅れたか。 問題そのものより、それに気づくまでにかかった時間を見ます。冒頭の90%の件なら、「進捗率で聞いていたので3週間気づかなかった」が記録すべき内容です。同じ問題は次も起きますが、気づくのが早ければ被害は小さくなります。
逆に、細かい経緯の記録はあまり残していません。次に読まれないからです。振り返りの資料が丁寧すぎると、作るのに時間がかかったうえに誰も読まない、という結果になりがちでした。
6. まとめ
実行段階の進捗管理について、私がやっていることを整理します。
- 進捗率を聞かない。 自己申告のパーセントは、書いた量の割合になりやすい。
- 作業を3日以内に割る。 二値で答えられる大きさにすると、解釈のズレが消える。
- 消化ではなく残作業を毎週見積もり直す。 遅れの量は、残りの見込みと残日数の差でしか分からない。
- ツールは集計を助けるが、割ることと言いにくいことは人の仕事。
- 振り返りでは、問題そのものより気づくのが遅れた理由を残す。
冒頭の3週間続いた90%は、報告の仕方を変えていれば1週目で分かったはずのものでした。進捗が見えない案件は、たいてい進捗の測り方の問題だと思っています。
計画段階で何を決めておくべきかは成功するプロジェクトマネジメントの基本原則に、プロジェクトマネジメント全体の枠組みはITプロジェクトマネジメントの基礎とその重要性に書いています。