進捗管理の設計の基礎 - 室長のひとりごち

進捗管理を「される」ことは嫌ですよね。ええ、放っておいてと言いたいです。でも作業の計画を作っておいて出来ていないというのもちょっと気が引けます。でもちょっと計画どおりに進まない進捗上の障害がありまして…。と切り出すのもちょっとした勇気と踏ん切りとその後に始末をつけないといけないという覚悟が混ざって一歩を踏み出せずについついいうタイミングを逃しがちの月曜日ですが、進捗はいかがでしょうか。

2つの面を持つ進捗管理

進捗管理は、エンジニアの立場から見れば報告するだけだと思っていませんか。違うんですよ。エンジニアの立場であっても2つの意味合いがあるのです。

1つ目は、誰もが知っているしやっているプロジェクトマネージャやマネージャに対して行なっている担当作業の計画に対する実績と見通しの報告です。作業計画に対して実績が前倒しで進んでいるのか、それとも計画より進み方が遅れているのか。その実績からこの後どうなるのか。これが１番目ですね。

2つ目は、チームのメンバの進捗の予実を知って、自分の作業への影響を知ることと困っているチームのメンバに対して自分が経験した解決策を共有したり実際に解決のための手助けが必要かを申し出るなどのチームとしての進捗の目線で捉える、です。

作業計画との関係

進捗管理と切り離すことができないものが作業計画です。作業計画の設計がイマイチだとどう頑張っても進捗管理で知りたいメッシュの進捗は知ることができないからです。つまり、進捗管理の要件は作業計画の制約条件になる、ということです。制約条件になるということは、作業計画の設計をするときには進捗管理からのオーダーを取り込まなければいけない、ということです。

前述した1つ目の報告で報告を受ける側のニーズを把握していないとチームの都合だけの進捗管理となってしまい、報告を受ける側（＝マネジメントなど）のニーズには応えられずに後から進捗管理の設計からやり直すという二度手間になるし、過去の進捗は把握できないからその作業期間の進捗自体が使い物にならないことになりかねないということを招きます。

細かさの粒度（＝程度）

どの程度で作業の計画の予実を知りたいかはチーム＞マネジメントの優先順位があるのは現場で進捗の予実の較差のインパクトを受けるのはチームだからです。

でも、進捗管理を含むプロジェクトマネジメントはマネジメントからのオーダーなのは経営にインパクトを与えるかもしれないとマネジメントサイドが捉えているからです。

でも、いくら必要だと言われても進捗管理の単位が細かすぎれば報告のための作業の管理になってしまうので本末転倒です。

ところでマネジメントサイドは何を知りたいのでしょうか。それを知ればどうすればいいかが見えてきます。

マネジメントサイドは、チームの計画した作業の実績はある意味どうでもいいのです。特に計画通りに進んでいるなら。遅れているのもまあちょっと気になりますけどそれほど優先順位はちょっと下がります。トッププライオリティはじゃあどうなるのか、です。そう、見通しが知りたいのです。

それを伝えられる進捗管理になっていればいいのです。

ではチームではどうするか。

進捗の把握＝作業のロットが大きくなればなるほど予実の較差が大きく開きます。それをどこまで受け入れられるかが把握する範囲を広げる方向でどこで区切るかの判断ポイントです。逆にどこまで小さくするかはどこの粒度で遅延がわかるとリカバリができるか、で判断します。ある作業が今日おわらなければ翌日以降の作業でリカバリができないほどのリソースが足らないなら時間単位で把握する必要があるでしょうし、2−3日以内でリカバリができる余裕があれば日次か半日が把握する最小の単位でいいでしょう。