手堅い見積もりが遅れを生む - セーフティの弊害

「予定より早く作業を終わらせても、最初のステップはそれを報告しないからです。現状の仕組みでは、作業を早く終わらせても何もご褒美はもらえないんです。いやそれどころか、ペナルティーが課されます。」
エリヤフ・ゴールドラット 『クリティカルチェーン

4478420459「なぜ、プロジェクトは予定通りに進まないのか?」。「予定通り進まないのがプロジェクトだ」と言う人もおられるでしょう(^^;)。最近読んだ「クリティカルチェーン - なぜ、プロジェクトは予定通りに進まないのか?」という書籍は、そんな「プロジェクトマネジメント」における常識に挑戦する書籍です。この手の本では、久々に共感するところの多かった影響を受けた書籍なので、紹介したいと思います。

この本、著者はTOC(制約条件の理論)の提唱者で、そのTOCを小説仕立てで解説した「ザ・ゴール ― 企業の究極の目的とは何か」がベストセラーになったエリヤフ・ゴールドラット氏です。「ザ・ゴール」は邦訳もベストセラーになったのでご存知の方も多いと思います。その後、「ザ・ゴール2 思考プロセス」「チェンジ・ザ・ルール」と続編が続いており、本書は「ザ・ゴール4」のような位置付けです。今回は、ザ・ゴールからの主題であるTOCをプロジェクトマネジメントに適用させたものです。

プロジェクトマネジメントといってまず出てくるのはPMBOK。もともとアメリカの非営利団体PMIがまとめたプロジェクト管理に関する知識体系ですが、いまや事実上の世界標準です。最近では研修に取り入れている企業も多いのではないでしょうか。プロジェクトマネジメントを系統的に捉える体系として、有用だと思います。PIMBOKに対し、本書で提案されている手法「クリティカルチェーン」の面白いところは、TOCの適用という点もさることながら、人間心理の特性を重視している点です。

セーフティ - 手堅い見積もり

中でも私が思わずなるほどと思ったのはプロジェクトの工数見積もりにおける「セーフティ(safety)」に関する考察です。ここでいうセーフティとは、あるステップを完了するのに必要な予想工数のマージン・余裕量のようなものとして定義されます。
工数見積もりの際に「これくらいでもできるかもしれないけど、念のためこれくらいにしておくか」という時の、
(念のためこれくらい) - (これくらいでできるかもしれない)
という量です。実際、開発ステップでは外的要因や想定外の障害があるため、ある程度のこのようなマージンを見積もりに入れることが多いです。

過剰なセーフティ

本書では、セーフティは大抵は8割くらいの確率で終わるくらいの量で見積もりをあげるだろうとされます。しかも、この8割の確率で終わるという工数は、5割の確率で終わる工数に比較して、2倍以上になるといいます。にわかには受け入れがたい数字ですが、場合によっては当てはまる気もします。
実際、プログラミングフェーズでは、何の障害もなくすんなり終わってしまった作業も、その見積もり時には、実際にかかった工数の2倍以上で工数を見積もっていたということはあるでしょう。これは特に、工数の小さいステップで顕著です。例えば、うまくいけば2時間程で終わる工数を1日といってしまうこともあるでしょう。このような丸めを入れてしまうのもよくある話です。
そう考えると、ステップを細かく割りすぎると、工数に余分なセーフティを与えてしまう可能性があると考えられます。正確な見積もりをしようとする行為が不確定性を高める。不確定性原理のようなものです。

セーフティの浪費

ここで疑問が出ます。では、なぜプロジェクは遅れるのか?セーフティがあるのならむしろ早く終わるのでは?と。

理由は簡単です。浮いた時間が有効に使われないためです。なぜか?これは、年末の道路工事のようなものです。予算を使い切らないと次年度の予算が削られるかもしれない、だから、予算を使い切るために必要のない公共事業を行うというやつです。開発業務の場合、あまり早く仕上げてしまうと、次回からさらに無理なスケジュールを要求されるかもしれない、だから報告しない。さらに言えば、残業代が少なくなれば収入も減るかもしれない。このような心理的な作用によって、セーフティは無駄に浪費されるというのです。

こう書くと保身のためにさぼっているように思えますが、実際そのようなつもりのない人でも、浮いた時間でコードのリファクタリングをしたり、念入りなテストをしたり、ドキュメントを整備したり。やることはいくらでもあるので、決してさぼっていなくても、浮いたセーフティは消費されることは確かに多いでしょう。

マイルストーンをなくす!

では、どうすればいいのでしょうか。本書では、まず細かいマイルストーンをなくすところからはじめます。そして個々のステップは最小の見積もりでスケジュールを立てる。細かいマイルストーンはなく、大きな単位でのおしりや、複数の作業が合流するところだけにポイントを置く。この時、個々のステップはぎりぎりの見積もりで引かれたものなので遅れる可能性は従来より高い。そこで、このポイントに大き目のバッファを置く。とまぁ、こんな感じです。
個々の「予定」を守ることは単なる局所最適に過ぎません。そこに目を奪われて全体としての「予定」が遅れないようにしようというのが主旨なのです。


とりあえずセーフティについて簡単に触れましたが、この他にも興味深い考察がなされています。興味を持たれた方は是非一読をお勧めします。私は、本書で得た考え方を自分の仕事に取り入れていきたいと思っています。

最初からベストのスケジュールをひけば、遅れることがあるのは仕方有りません。しかし、それを許容する風土がなければこのような管理は難しいでしょう。勿論、そのためにバッファを設けたりするのですが、この「予定より遅れる」ということについて、周りに納得してもらうのは少々頑張らないといけないかもしれませんね (^^;)

447837449X 【関連書籍】
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか? E・ゴールドラット 三本木亮
最速で開発し最短で納めるプロジェクト・マネジメント―TOCの管理手法“クリティカル・チェーン” 村上悟 井川伸治
PMプロジェクト・マネジメントクリティカル・チェーン 中嶋秀隆 津曲公二
プロジェクトマネジメント標準 PMBOK入門 広兼修
ザ・ゴール ― 企業の究極の目的とは何か エリヤフ・ゴールドラット 三本木亮
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか E・ヨードン


このエントリーをはてなブックマークに追加

コメントの投稿

非公開コメント

感動した。
人気エントリ
最近の記事
本のおすすめ

4274065979

4844337858

482228493X

4904807057

4873114799


最近のコメント
Links
プロフィール
  • Author:proger
  • 組み込み関係で仕事してます
ブログ内検索