『クリティカルチェーン』を読んで。－現役PMOがプロジェクトマネジメントについて勉強するー

僕は日中はITコンサルタントとして働いている。

最近アサインされた案件ではPMO、Project Management Officeというプロジェクト管理に関わる役割をもらった。

正直PMOを任せられるのは今回が初めてで、そもそもPMOとか知らなかったということで、ひとまず書籍を読み漁ろうとプロジェクトマネジメントに関する本を幾つか手元に揃えた。

その中で、今日紹介したいのは一番最初に読み終えた「クリティカルチェーン」。

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

「ザ・ゴール」で有名なゴールドラット博士が書いたビジネス小説だ。

さっそく、本の内容と読み終えて感じたことについて話していきたい。

本の構成

先ほども少し触れたが、この本は小説の形式を取っている。

物語は開発競争にさらされる一企業の会議から始まる。

新製品をどんどん世の中に出していくことが求められる中で、プロジェクトの遅れが発生した場合それは会社の存続に致命的なダメージを与えると考えた社長は、社内に特別チームを編成し、彼らにプロジェクトマネジメント手法を確立する使命を与える。

話の舞台はそんな大役を背負った彼らが通う、ビジネススクールのプロジェクトマネジメントの講義に移る。

自身の教授人生をかけたとある助教授が、生徒と共に講義を作っていきながらプロジェクトが遅れてしまう原因を追究していく。

読み物としても非常に面白く、「早く続きが読みたい」と思ってしまう部類の本だ。

理論について

本書では全体を通じて。『どうしてプロジェクトは遅れてしまうのか』という課題に対する解決策を提示してくれている。

その根本にはTOCという理論がある。

TOCとは何かというと、企業活動のパフォーマンスを制限している要素に注目することで、経営課題を改善していくという考え方だ。

というか、この本自体がTOCを提唱するためのものなのかもしれない。

まず、どのプロジェクトにも共通して言えることは、遅延の理由は予測できないトラブルのせいであるということだ。

そのため、プロジェクトを管理する立場の者は必ず万が一のことが起こった場合に備えて予備日を置いている。しかも、実際に必要な時間の2倍もの予備日を置くことが多いらしい。

しかし、これだけ十分な時間を予備として取っているにも拘らず、ほとんどのプロジェクトには遅れが発生する。

なぜそんなことが起こるのか。

それは、焦るギリギリまで物事に着手しない人間の性質と、万一ある作業が早く終わったからといってスケジュール全体を早く終わらせようとしない大人な事情等があるためだという。

そしてプロジェクトを遅らせる最も大きな原因は、局所的なコストに意識がいくとプロジェクト全体を考慮して完遂のための意識が薄れ、反対に全体に目がいくとコストのことを考えられなくなることだという。

つまり、大局と小局が同時に考えられないことが問題だと言っている。

そうならないようにするために、本書では『これが遅れたらプロジェクトが絶対遅れる！』という作業に意識を傾け、こいつが期日まで間に合うように２つの予備日の組み込み方を提案している。

1つはその主要作業の後ろに大きな予備日を設けること。

もう1つはそれ以外の作業が遅れた場合、主要な作業にも影響が出ないようにするため主要な作業とそれ以外の作業のつなぎ目に予備日を置くこと。

この２つを併用することで、プロジェクトが万一遅れた場合でも設置した予備日がきちんと吸収してくれて、最後の締め切りにはちゃんと間に合うという算段だ。

これで大抵のプロジェクトはうまくいくが、中には超スーパーマンが一人で色々な作業を担当し、そのせいでプロジェクトが遅れてしまうということもあり得る。

それを解決するのがクリティカルチェーンというもので、これまでの予備日の考え方はそのままで、スーパーマンが取り組む作業の順番に合わせて予備日を組み込む場所を少し変えるという理論だ。

要約すると、

締め切りに間に合わないプロジェクトは予備日の取り方が悪かったってことだ。

読み終わって

本書では「プロジェクトを予定通り完遂したいなら、適切なスケジュールで予備日を組み込め！」ということが大枠のメッセージだと思っている。

確かに現場を振り返ってみると、「絶対何かイレギュラーが発生する」という考えのもと、チームリーダーが試算した作業日数をもとに全体のスケジュールが組まれているものの、本書のようにそこから更に一歩踏み込んだ工夫はなされていない気がする。

たいがいのプロジェクトが予備日を200%取っているんだけど終わらない、っていう状態はホントかもしれない。

だけど、実際に一番プロジェクトに影響を与える業務の後ろに予備日を作るにしろ、それ以外の業務が遅れた場合に一番大事な業務を守る予備日をつくるにしろ、果たしてそんな予備日をまとめてボンと出した時に相手がどんな反応をするかを考えると、現実問題本書で説かれている理論をプロジェクト管理に組み込むのは非常に難しい気もする。

「いやいやいや、なんでこんなに予備日まとめてとってんだよ？」って絶対言われそう。というかやっぱりスタンダードなやり方じゃないから「ん？」って突っ込まれそう。説得するのが難しそう。

それに加えて非ボトルネックはいくつも存在し、それらに合流バッファを設けるって結構頭というか神経すり減らす作業な気がする。

ちょっと今日の仕事中に簡単な課題管理で取り入れてみようとしたけど、疲れて諦めた。メンドクさ！ってなった。笑

なんにせよ、このセオリーを理解するのにはもう少し時間を有するし、プロジェクト管理に応用できるようになるまではかなり時間がかかりそうだ。