第2章 2.3 ← 2.0 プロジェクトの進み方
「進捗90%」が3か月続く理由
実行フェーズでいちばん多い失敗は、遅れることではありません。遅れているのに、数字の上では遅れていないように見えることです。進捗率は毎週きれいに上がり、報告会も問題なく終わり、それでも終わりが近づいてこない。この現象には、はっきりした仕組みがあります。
この記事の要点
- 自己申告の進捗率は嘘ではありません。ただ、残りの中身を誰も見ていないだけです。
- 見るべき数字は「終わったと他人が判定できたものの数」です。0か100しかありません。
- 実行フェーズの仕事の中心は、報告を集めることではなく、止まっているものを外すことです。
- 止まっている理由の多くは作業の難しさではなく、待ちです。回答待ち、承認待ち、環境待ち。
- 週に一度、ボードを一緒に見る10分が、報告資料より多くのことを教えてくれます。
2本の線が離れていくのを見てください
次の図は、同じプロジェクトを2つのやり方で測ったものです。オレンジは各担当者が申告した進捗率の合計、青は「他人が見て終わったと判定できた成果物」の数です。
90%は嘘ではありません
担当者が「9割できています」と言うとき、その人は嘘をついていません。頭の中では実際に9割終わっています。設計は済み、主要な処理は書けていて、あとは細かいところだけ。
問題は、その「細かいところ」の中身を誰も見ていないことです。エラー処理、他システムとのつなぎ込み、想定外のデータへの対応、動かしてみて初めて分かること。これらは作業量として大きいうえに、やってみるまで量が分かりません。だから9割から先が進まないのではなく、最初から9割ではなかったのです。
解決策は、担当者を疑うことではありません。測るものを変えることです。「あなたの感覚で何%ですか」ではなく、「終わったと他人が判定できるものは、いくつありますか」と聞く。これなら0か100しかなく、感覚が入り込む余地がありません。
実行フェーズの仕事は、報告を集めることではありません
実行フェーズに入ると、プロジェクトを持っている人の一日は、驚くほど報告と会議で埋まります。日報を読み、進捗を集計し、週報を書き、定例に出る。忙しく、そして何も動かしていません。
この時期の本当の仕事は、止まっているものを外すことです。そして止まっている理由は、たいてい作業の難しさではありません。待ちです。
- 先方から回答が来ていないので、設計を確定できない。
- 承認が回っていないので、発注できない。
- テスト環境が用意されていないので、確認できない。
- 別の担当者の作業が終わっていないので、着手できない。
これらは、担当者ひとりでは動かせません。動かせるのは、複数の部署に声をかけられる立場の人——つまりあなたです。週の中に、報告を読む時間ではなく、待ちを外しにいく時間を置いてください。これが実行フェーズでいちばん価値のある30分です。
週に10分の「ボードを一緒に見る」
進捗報告の会議ではなく、全員でボードを見ながら「止まっているのはどれですか」だけを聞く時間です。順番に近況を話す会議と違い、10分で終わります。そして進捗報告より多くのことが分かります。人は「遅れています」とは言いにくいものですが、「これは○○さんの回答待ちです」なら言えるからです。
最初の遅れが、いちばん重要な情報です
実行フェーズで起きる最初の小さな遅れは、それ自体は大した問題ではありません。その遅れがどう扱われるかが、そのあと数か月を決めます。
三日の遅れが報告され、責められることなく、日程が調整されたとします。次の遅れも報告されます。逆に、三日の遅れを報告した人が「なんとかならないのか」と言われたとします。次からは報告されません。取り返せる見込みがあるうちは黙り、取り返せないと分かった時点でようやく表に出ます。そのときには一か月になっています。
だから最初の遅れへの反応は、意識して選んでください。聞くべきは「なぜ遅れたのか」ではなく、「何があれば動きますか」です。前者は説明を求める問いで、後者は解決を求める問いです。返ってくるものがまったく違います。
変わったことは、変わったと記録する
実行フェーズでは、計画が必ず変わります。範囲が増えることもあれば、順番が変わることも、担当が代わることもあります。ここで大事なのは、変えないことではなく変えたと分かるようにしておくことです。
とくに日本の現場でよく揉めるのが「仕様変更」の扱いです。相手からの追加要望が、追加なのか、もともと入っていたのか。ここは感情の問題ではなく記録の問題で、立ち上げで書いた「やらないこと」と議事録があれば、たいてい静かに片づきます。逆にどちらもなければ、声の大きさで決まります。
変更を扱う具体的な手順は6.2で扱います。実行フェーズの段階では、変えたときに一行書くという習慣だけあれば十分です。
ABではこう見えます
AB Projectsのボードは、青い線——つまり「終わったと判定できたものの数」——をそのまま表しています。完了列に移ったものだけが数えられるので、感覚の入り込む余地がありません。週に一度この列の増え方を見れば、報告資料を待たずに実態が分かります。
止まっているものは、課題として登録しておくのが実用的です。「○○部の回答待ち」を担当者と期日つきで置いておけば、それが誰の遅れなのかがはっきりします。何も登録しなければ、他部署の回答待ちも、最後にはプロジェクトの遅れとして記録されます。
このページで使った言葉
- 進捗
- 計画に対してどこまで進んだかです。自己申告の進捗率は当てになりにくく、「終わったもの」を数えるほうが正確です。くわしく →
- 課題
- すでに起きていて、対処しないと進まない事柄です。一覧にしたものを課題管理表と呼びます。くわしく →
- 仕様変更
- 決まっていた内容を変えることです。日常会話ではこう呼ばれますが、正式には変更管理の対象になります。くわしく →
- 定例
- 決まって開かれる打ち合わせです。ここで言えなかったことは基本的に表に出ないため、言いやすさが会議の品質そのものです。くわしく →
- エスカレーション
- 自分の権限で決められないことを、決められる人に上げることです。早く上げるほど選べる手が多く残ります。くわしく →
- 検収
- 納めたものを相手が確認し、正式に受け取ることです。ここまで進んで初めて「終わった」と数えられます。くわしく →
あわせて読みたい
6.0 進捗の追い方
実態が見える進捗管理を、もう一段くわしく。
6.2 課題と変更の管理
止まっているものと、変わってしまったものの扱い方。
2.4 終結
「終わったつもりの日」から先に残っているもの。