進捗管理はつらいよ
今回のテーマは「進捗管理」です。
全体的にゆるい話になりますので、先に堅い話を申し上げますと、進捗管理は、PMBOKでは「タイムマネジメント」の知識エリアに属し、「監視・コントロール」のプロセス群に定義されています。ところで、みなさまは「進捗」と聞いて何を思い浮かべますか。
（いつも）遅れている。
（順調と言うが）疑わしい。
（わかりにくいけど）深掘りしないで。
ネガティブなイメージしか思い浮かびませんね。
「進捗＝ネガティブ」になるのは、進捗管理の目的が「期日を守る」ことにあるからだと思います。これは、品質管理やコスト管理とは異なる大きなポイントです。品質管理はバグが存在することを前提としています。コスト超過したところで顧客に迷惑はかかりません（納税額が減るので原因は追及されますが）。しかし、期日を守れなかったらどうなるでしょうか。サービスインが遅れたら顧客に損失を負わせることになりますが、最近ではそのような事態に陥らないようにバッファを置いています。バッファが置かれているから期日は守らなくてもよいのか。そうならないのは、期日を守られなかったら「信用を失う」からです。妥協が許されていないのです。だから、冷静な判断が失われ、デスマーチに嵌るのではないでしょうか。
「期日を守る」ための進捗管理ですから、進捗会議の雰囲気は得てして厳しいものになりがちです。例えば、
リーダー：例のタスクの進捗は？
メンバー：進捗率は60%ぐらいです。
リーダー：期日は明日だが、大丈夫なのか？
メンバー：実は間に合いそうにありません。
リーダー：・・・
というような感じです。最近ではパワハラが問題視されているので個人が一方的に責められることはないでしょうが、昔は上司にねちねちと絞られたものです。そうでなくても、進捗遅れの原因分析を「なぜなぜ5回」で行えば、個人の問題に踏み込むことになります。メンバーは技術者としての資質を問われて気が滅入ってしまいます。リーダーも経営層や顧客の信頼を失いたくないので必死です。この状況下でポジティブになれる方は、そう多くはないでしょう。
進捗をどのようにとらえるか
みなさまでは「進捗」をどのように表していますか？よく使われるのは「進捗率」です。OBPMをお使いの場合、各メンバーは【ガントチャート】でアサインされたタスクの進捗率を入力します。進捗率の定義は、
進捗率＝報告時の出来高÷計画日数
となります。至極明快ですね。ところが、この「報告時の出来高」が曖昧なために、現場を混乱に陥れることになります。「90%症候群」はよくある話ですね。報告時の出来高を高い精度でとらえるためには、タスクの着手前に段取りを整理し、各段階の工数を見積もっておく必要があります。例えば、5日予定のレポート出力プログラムを製造する場合、
① 出力指示画面の作成：1日
② 出力データ取得サービスの作成：1日
③ レポートレイアウトの作成：1日
④ 出力データ抽出処理の作成：2日
と整理し、進捗報告時点で②が終了しているなら、進捗率は2日÷5日＝40%という具合です。メンバーはこの整理ができていない場合、リーダーから進捗率の根拠を問われると慌てるしかありません。リーダーは、根拠のない進捗率を報告されること避けるため、工程毎の進捗基準を設けることになります。OBPMでは【進捗率設定】で進捗基準を設定できます。
また、「進捗遅れ」はどのようにとらえていますでしょうか。よく使われるのは「遅れ日数」でしょう。遅れ日数は観点が二つあります。一つは「報告時点の遅れ日数」です。これは、
遅れ日数＝報告時の開始予定日からの経過日数－報告時の出来高
と定義できます。例えば、10日予定のタスクを担当していて、開始予定日から5日後の時点で進捗率が40%ならば、報告時の出来高は4日分になるので1日遅れという具合です。OBPMでは【ガントチャート】の「遅れ日数」欄で確認できます。しかし、これも「報告時の出来高」が曖昧で、根拠のない進捗率が報告されると、リーダーは適切に判断できません。
もう一つは「期日からの遅れ日数」です。これは、
遅れ日数＝終了予測日－終了予定日
例）6/27(火)に終了予定のタスクの終了予測日が6/30(金)の場合、遅れ日数は3日。
となります。終了予測日はどのように見立てたらよいでしょうか。現場でメンバーに進捗を確認する場合、「残日数」（あと何日で完成？）をヒアリングすることがあります。根拠のない進捗率よりも精度が高いことがあります。この残日数を使って、
遅れ日数＝報告日＋残日数－終了予定日
例）6/27(火)に終了予定のタスクについて、6/23(金)の時点で「完成までにあと5日必要」
な場合、終了予測日は6/23(金)＋5日＝6/30(金)、遅れ日数は3日。
として、リーダーは期日を守れるのかどうかをメンバーに確認します。いずれにしても、遅れ日数がプラスだった場合、メンバーはリーダーの原因追及を免れることはできません。
計画は間違ってないのか
進捗遅れが発生したら、メンバーはリーダーの懸念を払拭しなければなりませんが、往々にしてその試みは成功することはありません。リーダーの寛大な措置（期日の延期、アサイン調整）を待つしかありません。しかし、計画に間違いはないのでしょうか。振り返ってみると、
進捗率＝報告時の出来高÷計画日数
ですが、この「計画日数」は、何を根拠に見積もられたのでしょうか。ソフトウェア開発における工数見積には様々な手法があります。例えば、
機能種別見積
FP法
PERT（Program Evaluation and Review Technique）
KKD（勘、経験、度胸）
などがあります。見積手法は次回で取り上げたいと思います。しかし、どんな手法で見積もったとしても、そのプロジェクトの特性に合致しているとは限りません。進捗遅れの原因として、計画の甘さもあるわけです。メンバーだけに原因があるわけでないのです。
みんなで差異を味わおう
プロジェクト管理の目的は、確度の高くない未来にゴールを見据え、ヒト・モノ・カネを適切に管理しながら、期日に完成をむかえ、想定した利益を生み出すことです。そのような特性をもつプロジェクトにおいて、「進捗する＝成長する」ということができるでしょう。プロジェクト管理に携わる立場上、「計画どおりに行かなくて当たり前」などと厚かましいことは言えませんが、「予実差異＝伸びしろ」ととらえ、メンバー全員で共有していく姿勢が必要なのではないでしょうか。
プロジェクト管理全般について詳しくまとめた資料もご用意していますので、ぜひご活用ください。
