バッファは諸刃の刃 プロジェクトマネジメントの基本 その２
前回は『プロジェクトの本質』について書きました。プロジェクトの本質は「不確実性」にあり、プロジェクトマネジメントとは「不確実性を乗りこなすこと」だということでした。
では、どのように不確実性を乗りこなせばいいのかということで、今回は「バッファの考え方」についてです。
バッファは取り扱い方によって、プロジェクトによい影響を与えることもできれば、致命的な悪影響を与えることもあります。そして、バッファの取り扱い方を知ることは、プロジェクトのメカニズムを知るに通じる重要なテーマです。
バッファは諸刃の刃
前回の記事にも書いたように、プロジェクトが抱える不確実性に対処するには、３つのアプローチが考えられる。
１．不確実性そのものを軽減する
２．衝撃を減らす
３．徐々に不確実性を減らす
の３つだ。
この３つのアプローチのうち、もっともお手軽で、もっともよく使われる手が「衝撃を減らす」アプローチだ。誰しもやったことがあるだろう「余裕（バッファ）を見込んでおく」のだ。バッファとは緩衝材のことだ。衝撃を吸収するクッションとして、余裕を見込んでおくのだ。
たとえば、作業を頼まれて「どれぐらいでできる？」と聞かれて、２時間ぐらいかなと思っても、余裕をみて「３、４時間あれば」と答えたことがあるだろう。納期とは「約束」だから、約束が守れるように余裕をみておくことは自然な発想だ。
プロジェクトの見積もりにおいても、この「バッファ」は盛り込まれている。しかし、ここで不思議に思っていただきたいのは、みな余裕をみているはずなのに、「それでも、なぜか遅れてしまう」という事実だ。十分余裕をみているはずだ。それなのになぜ遅れるのか。このメカニズムを見てみたい。
どれぐらいバッファをとれば安心か
エリヤフ・ゴールドラットは『クリティカル・チェーン』のなかで、バッファがプロジェクトに与える影響を見事に解明している。
下のグラフはプロジェクトが完了する確率を表したものだ。０で完了することはないから、ある程度時間が経ったところから、徐々に完了の確率が上がっていく。そして、山を越えるとなだらかに確率は下がっていく。しかし、確率が０になることはない。どんなことが起こるかわからなければ、いつおわるかもわからないのだ。
グラフの内側の面積で考えると、山の中心より少し右ぐらいの位置が、50%の確率を示すことになる。つまり、ここが「何もなければここで完了する」というポイントだ。これは「何かあれば遅れる」というポイントでもある。
作業の見積もりをするときに、「だいたいこれぐらいで終わるだろう」というラインは、すなわち「何もなければここで完了する」というライン、つまり50%のラインだ。しかし、見積もりの申告をするときに「何かあれば遅れる」というこのラインで申告する人は少ないだろう。自分を追い込むのが好きな人もたまにいるが、大多数はそこにバッファをのせたいと思う。では、どれぐらいのバッファを乗せれば安心できるだろうか。
コンサルティング先や、セミナー参加者にいろいろ聞いてみると、９割以上の人が「80％〜90％」のラインが安心だと答える。これはグラフでいうと以下のポイントになる。ということは、グラフで赤い線で引いた部分はバッファということだ。
80％〜90％の確率で約束が守れるようにバッファをとると、見積もりはだいたい1.5倍から2倍近くに膨れ上がることがわかる。これで上手くいくらなら、まだいいかもしれない。しかし、先ほどを言ったように「それでも遅れる」のだ。
期日の余裕は食いつぶされる
バッファの取り方には２つの方法がある。「期日」と「工数（時間）」だ。
期日でバッファをとるときは、期日を向こうに設定する。「2/10」に終わるだろうと考えたとしても、余裕をもった「2末」と答える。
ここで問題となるのが、着手時期だ。期日に余裕があったとしても、果たして早めに着手するだろうかということだ。仮に５日間の余裕があったとして、５日間早めに着手する人がどれだけいるだろうか。１割もいないだろう。「まだ余裕があるから」と、他の仕事をしてしまったり、「調査」と称して、着手を先延ばしにしてしまう人が多いのではないだろうか。これをゴールドラットは「学生症候群」と呼んでいる。
５日間の余裕があったとしても、他の仕事をしていたり、調査に使っていたとしたら、あっという間に余裕を食いつぶしてしまう。いざ着手して「思ったより時間がかかる」「タスクを見落としていた」としても、そのときにはもう余裕は食いつぶしてしまっているのだ。
時間の余裕も食いつぶされる
「工数」で余裕を見積もったとしたらどうだろう。工数でバッファを入れ込むときには「１０時間」でできる（確率50%）と思っても、余裕をもった「20時間」と申告する（確率80〜90％）。
やってみると実際には「15時間」で完了したとしよう。5時間余ったわけだが、早く終わったことを報告するだろうか。おそらくしない。なぜなら次に見積もる機会に、「このまえは早く終わっただろう」と見積もりを減らされてしまうかもしれないからだ。せっかく早く終わらせても、自分で自分の首を絞めることになりかねない。
そこで担当者は、この余った5時間を「ブラッシュアップしてます」といいながら、必ずしも必要のない仕事で使ってしまうのだ。これが「パーキンソンの法則」だ。パーキンソンの法則とは「仕事の料は与えられた時間を消費するまで膨張する」というもので、つまりは「浮いた時間はムダに消費されてしまう」ということなのだ。
バッファ自体がリードタイムを長くする
ここまで見てきたように、期日にしろ、工数にしろ、いくらバッファをとったとしても、それは「必ず消費されてしまう」ということがわかる。これは何を意味するのか。
それは「バッファがプロジェクトのリードタイムを長くする」というおそろしい事実だ。バッファは必ず使われるのだから、バッファをとった分だけ、リードタイムは自動的に長くなってしまう。そして、本当にバッファが必要なときには、すでにバッファは食いつぶされてしまっている。だから、バッファをとっても「それでも遅れる」のだ。
約束を守るためのバッファだったはずが、バッファが原因でプロジェクトが遅れてしまうという皮肉な結果を導いてしまう。バッファが悪いということではない。バッファの扱い方を工夫しなければならないということだ。
期日で管理するのをやめる
期日で管理すれば、「学生症候群」によってバッファは食いつぶされる。これを防ぐには、期日で管理することをやめることだ。
そもそも先のグラフで見たように、期日というのは確率でしかない。２月１日に終わるか、２月２日に終わるのか、誰もわからない。それを「この日に終わる」と宣言することは、シングルポイントの見積もりをしているようなもので、確率を無視した暴挙だ。
ましてや、特定の作業を「その日に」できるかどうかなんて、コントロールのしようがない。割り込みの会議が入ったらどうするのだ。また計画を修正するのか。そんなことをしていたら、計画を修正するだけでプロジェクトは終わってしまう。
プロジェクトは期日で管理することはできない。だから「時間枠」で管理することだ。デッドラインが１０日後であれば、「稼働時間＝一日の稼働時間×日数」で計算して８０時間の「枠」で考えるのだ。
プロジェクトを時間枠でとらえることで、「消化時間」と「残り時間」がわかるようになる。学生症候群で時間を浪費すれば、それだけ「消化時間」は増えていく。
バッファはバッファとして別にして、後ろによせる
工数見積もりにバッファを「含めて」しまえば、その時間は「パーキンソンの法則」によって、自然に消化されてしまう。だったら見積もりに「含めなければ」いい。そこで、バッファはバッファとして別に管理してしまう。
具体的には見積もりの精度の基準を「50%」の確率で約束できるラインにおく。そこに「80〜90％」の確率で約束できる見積もりとの差分を「バッファ」として設定するのだ。メンバーに見積もってもらうときは「なにかあれば遅れる、って工数で見積もって」と言えばいい。
ここでのポイントは、バッファは「本人管理」にすること。そして、バッファは「使ってもいい」という前提を示してあげることだ。ここらへんのバッファの考え方は「バッファをオープンにするマネジャー、隠すマネジャー」に書いたので読んでほしい。
さらに、プロジェクトは複数のタスクを含んでいるから、それぞれのタスクにバッファを見込んでしまえば、リードタイムが長くなってしまう。そこで、個々のタスクからバッファを剥がして、後ろにもっていって、まとめて管理する。
バッファを後ろでまとめて管理することで、バッファの総量を減らすことができる。いままでバッファも食いつぶしていたのは「学生症候群」か「パーキンソンの法則」のどちらかなのだ。見積もり自体が50％確率の精度なのであれば、バッファを使う可能性も50%として、バッファの総量を半分にするのも一つの考え方だが、そこはプロジェクトの不確実性と、担当者の能力をみて判断する。
バッファは悪か？
ここまでバッファが持つ良い側面、悪い側面、そしてどうすれば機能するのかを見てきました。それでもバッファをあてにすること、あてにさせることに抵抗を感じる方はいるでしょう。
バッファをオープンにして、本人に管理させてしまったら、バッファをあてにしてしまうのではないか。確かにそうかもしれません。しかし、仮にバッファを全部使い切ったとしてお、それはあらかじめ設定されたバッファであって、プロジェクトが遅れるということではないのです。
バッファをオープンにせず、まとめて管理もしなければ、必ずどこかにバッファが潜り込むます。そしてバッファはいつのまにか消化されて、何かトラブルが起こったときには、そのバッファは残っていないのです。
プロジェクトマネジメントの極意は「いかに現実を把握するか」ということに尽きます。バッファをクローズしてしまうのは、プロジェクトを霧に包むようなもので、現実を見えなくさせてしまいます。バッファを正しく運用することで、プロジェクトの現実をつかみ、不確実性を乗りこなしていただきたいと思います。
＜おすすめ文献＞
『クリティカル・チェーン』・・・『ザ・ゴール』の著者、エリヤフ・ゴールドラット博士がプロジェクトのメカニズムを解明した本。バッファがプロジェクトに与える影響について詳しく知りたい方はこの本がおすすめです。
『ソフトウェア見積もり』・・・ソフトウェア見積もりの現実と、サイエンスではなく、アートとしての見積もり技術について詳しく書かれています。『コードコンプリート』の著者、スティーブ・マコネルによる著作。
週１回、メールマガジンを発行しています
ビジネススキル、プロジェクト管理、チームマネジメントなど、
仕事の役に立つ情報を知りたい方はこちらからご登録ください。