進捗管理の落とし穴

EVMは進捗管理の手法としてPMBOKにも出ている有名なものである。
”コストベースの進捗管理”といった程度のことしか分かっていなかったので
進捗管理の基本を知ろう | 日経 xTECH（クロステック）
で勉強してみた。なるほど。ふむふむ。

で、Part3に出ている例題の質問をちょっと変えてみる。

1日1本という見積で、1人で5本のプログラムを5日間で開発する。
3日目終了時点で2本完成した。この時点で何日遅れか？

職場の同僚4人にそれぞれ聞いてみたところ、4人とも「1日遅れ」という回答だった。
根拠としては、「2日で2本完成するところを3日かかったのだから1日遅れ」ということ。
確かに普通はこう答えるよねえ。
答えた側としては”3日目が終了した時点”では1日遅れという認識でいるのだろう。
しかし、質問した側（管理者だろう）はトータルで見た場合の遅延報告を期待している。
よって、管理者は「1日遅れか。ということは5+1で6日だから、あと3日だな」と判断する。
ここが落とし穴。
EVMでETC(残作業コスト予測)を計算すると4.5人日となる。例題では1人で開発しているわけだから日数にすれば単純に4.5日。
管理者が判断した「あと3日」と1.5日もずれている。
そのため、管理者が5日目完了時点で「明日で終わるよな？」と聞くと「いや、明々後日です」と回答がくる。
で、管理者は「んだとぉ〜！てめえ、一昨日の時点で1日遅れって言ったじゃねえか！明後日にリリースするって約束しちゃってんだよ、こっちは！」となる。
で、あわれな担当者は徹夜で何とか仕上げたものの、徹夜だから当然出来はボロボロで客からクレームがくると。

では、質問の仕方を変えてみたらどうだろう？
「何日遅れ？」ではなく「あと、何日かかる？」と。
それでも「あと、3日です」と答える人はいるだろう。
これはこれで、その担当者は問題だが、私としてはこう提案したい。
担当者が進捗報告するのではなく、管理者が進捗状況を計算すること。
その代わり、担当者は実績の報告をする。管理者は実績報告をもとに進捗状況を計算する。
進捗状況は即、関係者全員に広報する。
管理者は進捗が悪い担当者がいたらヒアリングしたり様子を見てみる。
もしかしたら割り込み作業が多いのかも知れないし、具合が悪いのかも知れない。
彼女とケンカしたのかも知れない。
そして管理者は問題点を取り除く対応をする。彼女とのケンカの対応は無理だけどね。
そもそも担当者に進捗報告の作業までさせるのがおかしい。
担当者には実作業に集中してもらうべき。報告してもらうだけだったら管理者はいらない。
管理者が自ら動いて状況を把握するべきだ。そして、問題点の対応をするべきだ。

担当者は実績報告の際、注意が必要。
「80%完了です」という報告から100%完了までがえらく長いというのはよくある話。
なので実績報告は0か100、ようするに「終わったか終わってないか」だけ報告するようにする。
こうしないと結局、まやかしの進捗となる。
「仕掛かったら30%」という計測方法もあるが個人的にはこれもまやかしだと思っている。
「でも、この作業、10日って見積もってんだけど。そうしたら10日間、ずっと進捗0じゃん」という反論もあるだろう。
作業を分割しなさい。
初期見積時にはそういったどんぶり見積もやむをえないが、実作業の段階で10日なんて見積は見積もってないのと等しい。
分割することで作業の整理もできるし、実は同じような作業があるのを発見して、共通化を図ることにより時間短縮につながるかも知れない。
できれば1日単位にまで分割するのが望ましい。そうすれば実績報告も簡単。
進捗状況もリアルなものになる。
とはいえ、いきなり1日単位に分割するのは難しいから最初は1週間、次に3日・・・と慣れていくにつれて粒度を小さくすればいい。

「偉そうに書いているけどやったことあんの？」と聞かれそうだが、実はやったことはある。
小さいプロジェクトだったので私は作業担当者兼管理者だった。
この時はEVMなんて知らなくて自分で適当に考えた計算式に基づいて進捗管理していた。
実績と予定（見積）はちゃんと区別するようにした。
作業もできる限り、1日単位に区切るようにしていた。
厳し目に実績報告していたせいもあって、常時遅れている状態になってしまい、緊張感をもって作業ができた。
もちろん問題なくQCDはクリアした。
ただ、この時は2ヶ月間ぐらいだったから緊張感がもったが長期間だときつかったかも。