進捗会議に継続的に出ているのに進捗がよく分からないときに、起きていること

進捗管理の基本的なところは、色々な書物やウェブサイトでも情報がありますし、各ITパートナも様々なノウハウを持っています。そのため、進捗管理の基本を外しているプロジェクトは、滅多にないと思います。

しかし、実際の現場では、進捗会議に毎週出席して、進捗報告を聞いているが、「良いのか悪いのか」よく分からない。といった印象を持つことが結構たくさんあるのではないでしょうか。特に、プロジェクト慣れしていないユーザ企業のプロジェクトマネージャやステアリングコミッティの人たちのなかには、モヤモヤした気持ちを抱えている人も少なくないと考えます。

今回は、なぜ、そうしたことが起きるのか。どうすれば、解消できるのか、について、お話していきます。

---

そもそも、どうやって進捗が良いかどうか把握するのか

まずは、進捗管理の基本的なところからお話を始めます。

テストフェーズに入ったものの、設計開発の残件があり、設計、開発、テストのタスクが同時並行で実施されているちょっと面倒な状況を思い浮かべてください。以下は、ある時点のタスクの進捗実績です。

全体母数に対して、その日時点の実績数が報告されています。一応、どこまで進んでいるか自体は把握できます。しかし、これが良い状態なのかどうかは分かりません。

そこで、通常は、予定を併記して、予定に対して実績がどうかを報告する形式にします。それにより、予定通りか、遅れているかが分かるようになります。

上記の例は、すべてのタスクが遅れています。ただ、この遅れが深刻な遅れなのか、まだリカバリ可能な遅れなのかは、これだけでは分かりません。

そのため、予定と実績の対比に加えて、遅延に対する見解を文章で説明するようにしている場合が多いと思います。

このケースでは、設計と開発は、遅れが出ているものの、全体への影響が出ないように調整済みで、深刻ではないことが分かります。また、他の遅れについても、まだ完了はしていませんが、なんらかの対応が打たれていることが見て取れます。

さらに、そこに、青（緑）・黄・赤の信号機を追加して、状況をひと目で分かるような工夫もしたりします。ここでは、設計と開発は、青：問題無い。他の遅れは、黄：遅れはあるが、まだ深刻ではない状態だと分かります。

ここまでは、たいてい、どのプロジェクトでもやっている進捗管理だと思います。

さて、ここからが、本題です。上記にあるように、きちんと進捗報告をしていても、状況がよく分からなくことがあります。

---

進捗が良いのかどうか、分からなくなるとき

大きなプロジェクトにおいては、全部が予定通りということは稀です。もともと想定していたリスクが現実の問題になってしまうこともありますし、想定外の事態が起こることもあります。

そして、多くの場合、問題の解決には時間が掛かり、以下のように、長期間に渡って、ずっと何らかの問題がある状態が続くことがあります。

この状態は、ITパートナ側にとっても、良くありません。この状態が続くと、スキルと経験のある人たちであっても、感覚がマヒしてきます。実は、徐々に深刻な状況になってきていても、見逃してしまうことが増えてきます。

では、どうするか。解像度を上げます。

---

解像度を上げる

今回は、テストフェーズでの進捗報告ですので、テスト進捗について、解像度を上げてみます。解像度の上げ方には、色々ありますが、ここでは、チームごとの進捗にブレイクダウンしてみます。

チームでブレイクダウン

さて、チームごとに分けてみると、販売チーム以外は、概ね予定通りに進捗しているものの、販売チームが大きく遅れていることが分かります。

ここで解像度をさらに上げてみます。

作業手順でブレイクダウン

今回は、さらに解像度を上げるにあたって、テストの目的である「不具合を洗い出す」という点に着目してみます。

テストが完全に完了していなくても、不具合を洗い出し切れていれば、対象すべき不具合の数が明確になり、進捗管理としては大きな前進になります。

そこで、テストは完全には完了していないが、不具合を洗い出せている状態として、「不具合あり完了」というステータスを設けることにします。

このステータスを使って、進捗管理をブレイクダウンしてみると、どうなるでしょうか。

不具合なし完了は、予定の半分以下の進捗で全然ダメですが、不具合あり完了で見た場合は、予定通りは行きませんが、予定に近い実績となっています。

そうやって、解像度を上げていった結果、現在のテストの状況は、以下のような状況だと分かります。

• 販売チーム以外は、ほぼ予定通りに進捗している
• 販売チームは遅れているものの、シナリオの完全完了には至っていないが、対処すべき不具合は識別できている
• 今後は、洗い出した不具合の数・対応状況を見て、いつまでにシナリオの完全完了に持っていけるかを確認する必要がある

このように、ブレイクダウンしていくことで、解像度を上げることができます。

しかし、なんでもかんでも、ブレイクダウンしていくと、情報が多すぎて、かえって分からなくなります。そのため、必要な範囲でブレイクダウンしていくことが重要です。

---

どのように解像度を上げるか

結論から言うと、試行錯誤しながら、状況に応じて一生懸命考える。ということになります。

なぜならば、プロジェクトによって、難しいポイントも違いますし、体制の組み方も違います。大事なことは「定番の進捗管理では、モヤモヤが残ってしまう。どうにか解像度を上げたい」と思うことです。

解像度の上げ方には、色々ありますので、幾つか、以下に例を挙げておきます。

• 通常業務のシナリオと、派生業務のシナリオ
• 海外関連のシナリオと、それ以外
• 月次処理系のシナリオと、それ以外
• 課題〇〇に関連するシナリオと、それ以外
• 仕様変更△△の影響を受けるシナリオと、それ以外
• 開発遅延□□の影響を受けるシナリオと、それ以外
• インタフェースありのシナリオと、それ以外

ポイントは、比較的順調なところと、問題のあるところを切り分けることです。そのために、現場での聞き取りも必要ですし、様々なの試行錯誤も必要です。

なお、どう切り分けても、全体的に問題があるようなら、全面的な立て直しが必要になります。

---

定番の進捗管理は、非常に重要です。しかし、進捗遅れの範囲が大きくなったり、進捗遅れが継続するような場合には、定番のやり方だけでは、状況がよく分からなくなることがあります。そのため、状況に応じた解像度の上げ方が重要である、というお話をさせて頂きました。

なお、解像度を上げるためには、試行錯誤が必要ですが、試行錯誤を効率的に行うためのノウハウもあります。こちらは、また別の機会にお話しできればと考えています。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---