書感：クリティカルチェーン（バッファーは無駄に食いつぶされる＋できる人が限られる＝プロジェクトは遅延する）
書籍『クリティカルチェーン － なぜ、プロジェクトは予定どおりに進まないのか？』を読み返しました。
エリヤフゴールドラット博士の「Theory of Constraints (以後、TOC)：制約条件の理論」に基づいたビジネス小説第４弾です。
今回は、サブタイトルの通り、プロジェクト業務がテーマです。今回の主人公は、これまでの企業人とは異なり、大学の準教授（書籍の表記ママです）で、エグゼクティブMBA（社会人向けMBAコース）でプロジェクト・マネジメント論を担当します。終身在職教授の座を狙う主人公のリックは、現在は一般の企業で言えば契約社員のような不安定な身の上です。
その上、リックが所属する大学では、MBAコースの入学者が減少傾向にあり、リックが知らないところでMBAコースの縮小が検討されるという状態。しかも、それはリックの大学だけにとどまらず、経済界からMBAを取得しても実務では役に立たないとの認識が広まっていることが原因という、根が深い話です。
そんな中、実務で役に立ち、新たな生徒をどんどん獲得できるようなコースを開発できなければ、10年越しの悲願である終身在職教授（≒正社員）の身分を手に入れることができないことが確定したリックは、何としてもプロジェクト・マネジメント論のコースで、実務で役に立つ手法を開発し、それを証明しなくてはなりません。
また、同じく、リックのコースに参加する生徒たちの中には、新製品の開発期間を大幅に短縮する方法を見つけることを副社長から厳命されてきているメンバー達がいます。それを成功させなければ、新製品の開発競争に負けて、企業存続の危機に陥ります。
こうした教師と生徒がタッグになって、プロジェクト業務がなぜうまくいかないのか、どうすれば予定通りどころか大幅に期間を短縮できるのかを試行錯誤しながら研究し、画期的なプロジェクトマネジメント手法を発明していくというストーリーです。（もちろん？、今回も最後はハッピーエンドです）
このシリーズのお約束ですが、今回もまた、１つ問題を解消するとまた次の問題にぶつかる、を繰り返していきます。そのことにより、プロジェクト業務の何が問題なのか、どうすれば、それらの問題を解決できるのかを、ステップ by ステップで解き明かしていきます。
また、生徒の数だけ様々なタイプのプロジェクトがあり、先の挙げた新製品の開発、建設業、プログラムの開発、マーケティング、工場の拡張プロジェクト、などが含まれます。その為、この書籍で説明される手法が、何か特定の業界だけで通じる特殊な手法ではなく、幅広い業界や種類のプロジェクトに適用できることを訴えています。
さて、ここで念のため、プロジェクトの定義を書いておきたいと思います。
本書の中では、「プロジェクトとは、特定の目標、目的を達成するために行われる一連の活動で、開始－中間－終了の段階を明確に定義できるもの」との定義が紹介されています。
言い換えると、定められた期間（始まりと終わり）があって、何らかの目的を達成するための複数の作業が集まった（＝複数人で実施する）お仕事と言ったところでしょうか。
どのような種類のプロジェクトでも、古今東西、計画通りに終えるのが非常に難しいということで、さまざまな業界の方が苦労をされています。
（IT業界なんか、半分くらいは失敗してるんじゃないかってくらい失敗率が高い・・・見かけ上、期間とコストを守れていても、作るものの中身を簡素化して肝心の目標を達成できないなんてことも多いし・・・。そもそも、個々の作業を担当するSEやプログラマーは、プロジェクト本来の目的を意識してない。下手するとPMも。また、これも良くあるのですが、企業側でITシステムの企画立案をしてる人が、プロジェクトで掲げた目標や目的を、ITシステムで達成できると考えていなかったりします。）
ともあれ、紆余曲折や試行錯誤はあれど、本書では、CCPM（クリティカルチェーンプロジェクトマネジメント）という手法を発明し、みごとにプロジェクト期間の短縮に成功しています。
ここでは、キーとなる概念を紹介しておきます。詳しくは、本書を読むか、「クリティカルチェーン」で検索すると様々な書籍が引っかかると思うので、それらの解説本を読んでください。
- プロジェクトバッファー
通常、プロジェクト内の個々のタスクの作業時間を見積もるときは、意図する・しないに関わらず、バッファー（予定外のことが起きたことを想定した余裕時間）が含まれています。
これは、例えば、自宅から目的地まで車で移動するとした場合、おおよそ確実に到着できる時間を想定して出発するのと同じです。多くの人は、道が混んでいるかもしれないことを考慮して、でも、酷い渋滞や通行止めまでは考慮せず、７－８割は確実に到着できる時間を見積もるのではないでしょうか？
これと同様に、プロジェクト業務の場合、担当者が作業時間を見積もると、無意識に70-80%の確率で順守できるような期間で作業時間を見積もると思います(場合によっては、90%くらいで考えるかも)。
それに対し、個々のタスクを理想的な状況がそろっている場合に達成可能な時間（＝先ほどの車での移動で言えば、道がガラガラで信号にも引っかからない場合にかかる時間）で見積もってバッファーが含まれない状態にし、プロジェクト全体に対して設けたバッファーのことを「プロジェクトバッファー」と言います。
大事なポイントなので、もう少し説明しましょう。
先の車の例を拡張して、出発地点(START)と最終目標地点(GOAL)に行くまでの間に３箇所(地点A、地点B、地点C)中堅地点があるとします。そして、それぞれ場所で次の人に交代するとします。各地点間の移動は全て最短の場合は（先の例の通り、道が空いてて信号にも引っかからない場合に）30分で着くものとします。
従来の見積もり方法では、恐らく、START→地点Aの時間は45分、地点A→地点Bで45分、地点B→地点Cで45分、地点C→GOALで45分といった形で、それぞれの目安時間を設けて、GOALには3時間後に到着すると見積もる形になります（もしかしたら、それぞれ60分×4で、4時間かもしれません）。
それに対し、CCPMでは、各ポイント間の移動はあくまで理想の30分で見積もり、プロジェクト全体で30分程度のバッファーを設けます。
なぜこのように見積もるのかと言うと、上記を車ではなく、徒歩またはランニングだと考えてみて欲しいのですが、30分が目標と言われるのと、45分が目標と言われるのでは、どちらが早く次の地点に到着しようとするでしょうか？ 時間に余裕があれば、少し楽をしたくなるのが、人情というものではないでしょうか？ また、これが一回限りのことなら、まじめな人は45分と言われていても、それより早く到着しようとすると思いますが、繰り返し上司に同じことを頼まれる場合は、どうでしょうか？ 一回早く到着できたら、次回はどのように見積もりを回答すれば良いでしょうか？（きっと上司は、前回30分で到着したのに、なんで今回は45分なんだ？と聞き返すことでしょう・・・）
このように、プロジェクト業務の場合、各作業の担当者は与えられた時間よりも早く終わらせるインセンティブがないので、多くの場合、個々のタスクに積んだバッファーは無駄に消化されてしまい、どれだけ余裕をもって見積もってもプロジェクト全体では、バッファーが足りずに遅延してしまうのです。こうした問題に対応するのが、プロジェクトバッファーと言うことになります。
- 合流バッファー
前後関係がある一連の作業、かつ、複数の並行作業がある場合に、一番時間がかかる作業のつながりをクリティカルパスと言います。
通常、プロジェクトバッファーは、クリティカルパスの最後に追加するのですが、クリティカルパスに合流する枝分かれしたパス（一連の作業）が遅れることで、プロジェクト全体が遅れてしまうことがあります。
そうした事態が頻発すると、プロジェクトバッファーがいくらあっても足りなくなってしまうので、プロジェクトの途中で他のパスに合流する全てのパスに対して、合流するところの前に設けるのが、「合流バッファー（枝分かれしたパス用のバッファー）」となります。 - リソースバッファー
一般的なプロジェクトマネジメントの方法論では、クリティカルパスに遅れが発生しない様に注意する様にしますが、TOCでは、これだけでは不十分と言います。
クリティカルパスに加えて、特定のリソース（だいたいが人）でしか実施できないタスクが同時にできないという制約も考慮して計画を組み、都度、調整していかないと、予定通りにプロジェクトが進まないからです。（当初計画時には、個々人の作業の重なりも考慮すると思いますが、予定がずれていく中で、気が付いたら、同じ人が同じタイミングで複数の作業にアサインされる・・・なんてことは往々にしてあります）
しかも、こうした制約になるような優秀な人やリソースは、多くの場合、複数のプロジェクトで活躍したりするので、あるプロジェクトからリリースされるタイミングがずれると、別のプロジェクトも遅れることにつながります。
その為、制約となるリソースが必要なタイミングの調整を行うためのバッファーを、「リソースバッファー」と言います（本書の中では事前予告という形で制約リソースを必要とする作業/プロジェクト間の調整を行っています）。
他にも重要な概念はあるのですが、単一のプロジェクトの管理という観点では、上記３点が大きなポイントになると思います。
実は、以前にCCPMを会社で導入しようとしたことがあるのですが、その時は、残念ながら上手く行きませんでした。
ポイントは、プロジェクト関係者全員がしっかりと理解してトレーニングを積んでいないと、従来型の見積もりになってしまうということと、本書の中にもありますが、契約条件を変えない限り、協力会社さん達の協力を得るのも難しいという現実がありました。
また、CCPMの前提として、ある程度作業計画がきっちりと立てられることが前提となるので、要件がコロコロ変わる流動的なプロジェクトには向かないと思います。（ここにも対応する手法が編み出されているみたいですが・・・）
あと、最大の障壁はもっと心理的なもので、実際にプロジェクト期間の短縮に取り組んでいるときに、いろんな社員や協力会社の人と会話したのですが、プロジェクトを予定より早く終わらせようと考えたことがある人は皆無だったことですね。
期日を守るために早めに作業を終わらせておいて、予期せぬ事態に備えようという気持ちはありましたが、実際に予定より早くプロジェクトを終わらせて納品するということは一切考えていなかったんです（こういうことって、私の周りだけですかね？？？）。
また、上記のようにして、途中で余裕ができたとしても、フェーズの区切りなどのマイルストーンでリセットされるので、プロジェクトの最初から最後まで余裕があるということは、よほど余裕がある見積もりをした場合（かつ、その分の費用を払ってくれる余裕のあるお客様）を除いて、ありませんでした。
ともあれ、多くの人が、プロジェクト期間を短くしようとは考えてすらいなかったことに衝撃を受けました（どうせうまく行かないのだから、と否定的な意見も多かったのです・・・(涙)）。
個人的には、今でもCCPMは非常に魅力的でチャンスがあれば試してみたいのですが、以前と業務環境が変わり、あまり大きなプロジェクトには携わらない＆流動的な仕事が多いので、当面、試す機会はなさそうです。
いまやっている業務だとアジャイルの方が近いのですが、これまたプロダクトバックログ的なものがある仕事でもないので、ちょっとそぐわないのですよね。
それはさておき、この書籍で段階的に明らかにされる、なぜ既存のプロジェクトマネジメント手法ではうまく行かないのか？という点については、どれもこれも思い当たることばかりで、読み進める都度、うなずかざるを得ませんでした。
CCPMを実践できるかどうかはともかくとして、従来型マネジメントの問題点を理解するだけでも価値はあるので、ぜひ、本書およびCCPMの解説書を読んでみて欲しいと思います。
あと、本書を読んでいて面白かったのは、大学教授の世界を垣間見れたことですね。
友人・知人の中に、何人か大学の教授や准教授がいるのですが、日本でも終身在職制度（テニュアと言います）はあって、彼ら/彼女らにとってそれを得られるかどうかは非常に大きな問題です。
また、論文数の話もそうですね。最低限の質がなければ、そもそも論文として認められないのですが、数も出さなければ教授として評価されないので、１つの事象をいくつかに分けて論文を作り上げるという話は友人たちもしていました。
それらの話を聞いた時、本書に書かれていたことと一緒だ！と、変に感心してしまいました。
だから何だという話ですが、このシリーズの魅力の一つは、現実社会の実例とたがわない事実ベースで書かれていることでしょう。
なので、説得力もあるし、ちゃんと実践出来たら効果も発揮できるのだろうと期待もさせられます。
残念ながら、私自身はTOCを正しく実践できているとは言い難いのですが、今後も機会があればトライしてみようと思います（単に私がTOCを十分に理解していないだけな気もしていますし）。
それでは、また。
