どうせ当たらないのになんで見積するの？あるいはアクショントリガーとしての見積
育成型プロジェクトといって、コンサルタントである僕らが何でもやってあげるのではなく、お客さんのメンバーが中心となって慣れない変革に悪戦苦闘しながらすすめるタイプのプロジェクトを作ることが多い。
そういう状況だと色々とモヤモヤがたまる。なので定期的に「モヤモヤ相談会」を開いて、変革プロジェクトにまつわるアレコレを議論したりする。
先日のお題は
作業を見積もれと言われて困る。見積っても当たらないし。
この仕事をやらないわけにはいかないので、どうせ最後は「間に合うか？」じゃなくて「間に合わせる！」という気合しかないでしょ。
というつぶやきに応えて、見積もりの話をした。
★見積は当たらないし、ますます当たらなくなっている
プロジェクトの工数を見積って難しい。100人月クラスのプロジェクトではもちろん、ちょっとした作業が5時間なのか8時間なのかも結構ずれる。
ウチの新入社員研修ではモノづくりの演習で必ず自分で工数を見積もらせるが、当たらない。むしろ「予想どおりに進まないものだ」ということを実感してもらうために、当たらないのを承知でやらせている所もある。
なぜ見積が当たらないかと言うと、プロジェクトというのは本質的に「初めてやるチャレンジ」だからだ。
初めてやることなので、どれくらい時間がかかるかやってみないと分からない。
さらに「始めてからようやく、やるべきタスクの全貌が見えてくる。なので作業が後から後から湧いて出てくる」という状況にもなる。「この施策を検討するには、イレギュラー業務をすべて洗い出さないとヤバイことが分かった・・」みたいな感じ。そうなると、5時間⇒8時間みたいな見積ミスは誤差みたいなもので、工数がいきなり3倍になったりする。
プロジェクト立ち上げ期に、ちょっとした作業を見積る場合（例えば施策を検討するための会議資料を作るとか）では、どこまで品質を上げれば良いのかをメンバーが理解しておらず、やれどもやれどもやり直しを命じられ・・というツライことも起こる。品質基準を持ってない作業を見積のは、そもそも無理ゲーだ。どこまでやればいいのか分かってないんだから。
こんな感じで「プロジェクトでの作業見積」というだけで本質的に難しいのだが、ITの世界ではますます見積が当たりにくくなっている。僕がSEだった20年くらい前は、見積ってもっと当たるものだったのに。。。
例えば今度セミナーをやるJR貨物さんとやったこのプロジェクトも、僕としては比較的手慣れた人事領域のプロジェクトだったんだけど、ある領域に限っては言えば見積と実績のギャップが2,3倍あった（トータルでは流石にそんなにずれてはいない。見積が当たらない言い訳として、色んな事情があったのですよ・・。詳しくはセミナーにて）。
当たりにくくなっている理由の一つは、ITが発展したからだと思う。昔みたいにCOBOLを1万行書くとかだったら、1行あたりの生産性はだいたい収斂していくから、誤差は20%ですむ。ファンクションポイント法みたいな見積方法も工夫されてきた。
でも例えばSaasを活用したプロジェクトだと、「やりたいことにフィットするなら1日で完了。フィットしないなら業務上の対応方法を検討したり別途機能を作ったり・・で2週間」みたいなことは普通に起こる。ブレ幅がすごい。新しい技術をどんどん使うから、ファンクションポイントも意味ないし。
なので、もう「見積の精度でプロジェクトの成否が決まる」というプロジェクトにしちゃダメなんですよ。その時点で負けが確定だから。
★外れるのを承知で見積るのはなぜか？
見積は外れる。だが事前に作業見積をしないとヘルシーにプロジェクトは運営できない。
これは僕らのようなプロがプロジェクトをやる場合はもちろん、自社でちょっとした業務改善やシステム構築をする場合だって同じだ。
なぜかと言えば、プロジェクトマネジメントが以下のような経緯をたどるからだ。
1)外れるのを承知で見積
↓
2)このままの見積だと間に合う
↓
3)そのまま粛々と進める
↓
4)現状把握。その時の情報で再見積。2)へ戻る
プロジェクトが順調に行っている間はずっと2)から4)を往復する
見積った結果、このまま行けば間に合わないというケースもあるだろう。その場合はこういうルートをたどる。↓
1)外れるのを承知で見積
↓
5)やべえ、このままだと間に合わん！
↓
6)計画変更
↓
1)外れるのを承知で見積、に戻る
1回目の見積でいきなりNGとなって2)ではなく5)のルートに突入するケースもある。これまで順調に行っていたのに、4)から突然5)に行ってしまうケースもある。
どちらにせよ、その時点の情報で見積って間に合わないなら、計画を修正して、間に合うように調整する。
調整として一番良いのは期間や予算のバッファ（予備）を持っておき、見積通りいかなかったところに投入することだろう。期間のバッファがあるなら、ある工程が多少遅れても吸収できる。お金のバッファがあるなら、予定より多めに人を雇って人数でカバーできるケースも多い（もちろん、難易度が高いタスクだと急には雇えない）。
何にせよ、「このまま行くとヤバイ」を把握して手を打つのがマネジメントというものだし、そのためには
・当たらないのを承知で、「現時点での見積、予測」を持っておく
・想定外の状況で手を打つためのバッファ、資源を確保しておく
の2つが絶対に必要となる。
「ザ・ゴール」で有名なゴールドラット博士が提唱したCCPMというプロジェクト管理手法はこの極端なバージョンで、
・最初に作るスケジュールでは、担当者による見積工数の半分を使う
（4週間かかる見積なら、強引に2週間でやるスケジュールにする）
・その代わり、プロジェクト全体でバッファを多めに確保して、スケジュールと現実が乖離したらバッファを投入する
という考え方になっている。「クリティカル・チェーン」という本に詳しい。
余談だが、僕自身はオーソドックスなCCPMの手法に則ってはいないが、15年前に「ザ・ゴール」を読んで以来、ボトルネックに注目した似たようなプロジェクト管理方法を編み出して使っている。
さて。
「どうせ当たらないから」という理由で、最初のステップである見積をやらないと何が起こるのか？
それは、ずーっと「結局このまま進めると期限までに終わるの？」という素朴な問いに答えられないままプロジェクトをやっていくということだ。
これは作業をやっているメンバーはきつい（終わりが見えないし、急に休日出勤を命じられたりするから）。そしてプロジェクトを依頼しているプロジェクトオーナーや顧客にとっても、たまったものではない。こういういきあたりばったりな作業はまともな仕事とは言えない。
そしてそうしたずさんな仕事をしているプロジェクトでは、ほとんどのケースでスケジュール通りには終わらない。
ともかく、上記の「見積⇒作業⇒現状把握⇒再見積⇒計画修正」というサイクルを回さないと、完了を担保したプロジェクト運営は不可能だと言うことが分かっていただけただろうか？
当たるか当たらないかが問題なのではない。
★見積して間に合わないことが分かっても、どうせやらないといけないんでしょ？
最初のつぶやきを見ると
この仕事をやらないわけにはいかないので、最後は「間に合うか？」じゃなくて「間に合わせる！」という気合しかないでしょ。
とも書いてある。
あのさぁ・・あなたの気合でなんとかなる仕事なんて、難易度/ボリュームともにたかがしれているんですよ。世の中には何人かが頑張ってもどうにもならないレベルのプロジェクトってたくさんあるんですよ。
「間に合わせるという気持ちが大事」って一見かっこいいけど、もう太平洋戦争みたいな根性論やめましょう。
プロジェクトをやっていて常にあることなのだが、現場のメンバーが「絶対やらないといけない」と思っていることでも、経営レベルで判断し直すと、そうでもないことって結構ある。少なくとも、もともとやろうとしていたことの100%が必達、ということはない。
すべての仕事には優先順位が付けられるし、当初必須と言われていたことにも、
・なるべくならやりたいが、やらないからといって死ぬわけじゃない
・議論の前提（そもそも論）を変えれば、違う結論になる
みたいなことがたくさん紛れ込んでいる。
僕らは、経営にとって納期が最優先の場合、かなり大胆に品質に目をつぶったプロジェクトをやることもある。一般的に「よい品質でプロジェクトをやり遂げたい」というのは健全なプロ意識だと思うが、経営観点からみて必ずしも最適とは限らない。他にも、「時間をカネで買う」もやるし、「それならプロジェクト自体をやめる」という議論もする。全ては経営視点の合理性で意思決定すべきことだ。
そのように大胆にゼロベースで考え直すきっかけを得るためにも、「どうせやらないといけないんでしょ。最後は気合でしょ」というマッチョな姿勢は好きではないし、取るべきでもない。
期限なり予算をオーバーする見通しになった時点で対策を打つ。
対策は上記のように大抵は実行するのが気が重い。誰だって「オーバーしそうなので、期限を遅らせてください。やることを縮小させてください」なんて偉い人に言いに行きたくない。でも、だからこそ、気が重い仕事をせざるを得ない「アクションのトリガー」として、「このまま見積どおりにいったら終わらん」というきっかけが必要なのだ。
ほとんどすべての炎上プロジェクト（デスマーチ）は、
・見積をしない
・見積って期限内に終わらないことが分かったのに、目をそらして具体的なアクションをしない
ことが積み重なって起きている。