「クリティカルチェーン」から学んだプロジェクト管理

一生勉強

プロジェクト・マネージメントについては、アメリカのPMIが発行したPMBOKというプロジェクトマネージメントに関する知識体系が有名ですが、PMBOKで解決できない様々な問題をクリアにし、解決するための新たな手法(CCPM)を提案したのがゴールドラット著の「クリティカルチェーン」です。

 

作品紹介


Amazonで見る

題 名 : クリティカルチェーン

著 者 : エリヤフ・ゴールドラット

訳 者 : 三木本亮

出版社 : ダイヤモンド社

 

クリティカルチェーンのストーリー解説

 

ゴールドラット博士のTOC(Theory Of Constraints:制約の理論)は、ごく簡単にいうと「企業、組織のスループットは、ボトルネックの能力で制約される」というものですが、「クリティカルチェーン」という本は、この理論をプロジェクト・マネージメントに当てはめると新たな画期的なツールになるということをわかりやすく解説した本です。

この本によって、クリティカルチェーン・プロジェクト・マネージメント(CCPM:Critical Chain Project Management)というプロジェクト管理手法が世の中に提起されることになり、この手法によって多くの企業で成果が出されています。

「ザ・ゴール」や「ザ・ゴール2」と同様に小説仕立てになっていて、物語の中で実際の例をふんだんに入れながら、わかりやすく説明されています。

物語では、様々な人間模様やビジネススクールと企業との関係などの話もありますが、ここではCCPMという手法がどうやって生み出されたかにフォーカスして、CCPMが生まれた背景をこの本の流れに沿って解説していきます。

物語は、モデム製造販売を行うある企業が、開発日程の遅れによって将来、会社が行き詰まっていくという危機感から、若手マネージャー3人をビジネススクールのエグゼクティブMBAコースに送り込むところから始まります。

ビジネススクールで、雇われ講師をしている主人公と、前述のモデム会社やその他の企業から送り込まれた生徒たちとが、オープンディスカッション・スタイルの講義を進める中で、日程遅れを発生させないマネージメント手法を発見していきます。

予定通りにいかない原因

最初の議論は、現実の世界でなぜプロジェクトが予定通りに行かないかという議論です。

現実の世界でプロジェクトの実態は、

  1. 予算がオーバーする
  2. 予定通りに終わらない
  3. 計画を縮小する

ということが頻発しています。

では、予定通りにいかない原因を、公式な理由、及び非公式な理由としてプロジェクトリーダーの視点と現場の視点で調べてみると、

公式な理由(例)
  • 悪天候
  • 予期しない納入業者の遅れ
  • 政府との交渉が長引いた

⇒コントロールできない(他人のせいにする傾向)

非公式な理由(リーダー視点)
  • もともと非現実的なスケジュール
  • あまり信用できない業者でもコスト優先で採用
  • 参加メンバーの参加開始がズルズル遅れた
非公式な理由(現場視点)
  • 業者の進捗レポートが不正確だった
  • 下請け業者の管理が甘かった
  • 緊急の問題で頻繁に仕事が変更になった
  • 作業調整のための無駄な会議が多い

 

プロジェクトの不確実性

プロジェクトが予定通りにいかない理由を公式、非公式でみると、それぞれの立場で若干言うことが違っていますが、共通することは”不確実性”です。

プロジェクトに”不確実性”が存在することは誰でも理解できるのですが、不確実性に対して安全(セーフティ)を見ようとしても、安全を見ることを邪魔するのは実はトップマネージメントなのです。

トップマネージメントは、セーフティーとしてキープしているマージンを削除して、最短でやるように指示します。

ただしこれは、プロジェクトのスケジュール全体にセーフティを持たせようとした場合の話で、個々のステップでのスケジュールに関するセーフティについては別のストーリーがあります。

 

ここで不確実性について、少し詳細に検討していきます。

射撃の名人が標的を狙ったときに、標的に当たる確率は高いものの100%ではないとします。

何度も射撃をしたとして、標的からのズレをプロットすると下図のような正規分布になります。

 

 

一方、ある地点から目的地まで自動車で移動することを考えます。

目的地までの時間は、その時間での交通量、信号や踏切などの待ち時間、予期しなかった事故や道路工事などの影響で不確実となります。

しかし、交通量の少ない時間帯で他の要因がなければ、最短の時間はある程度読むことが出来ます。

このときの不確実の様子は、下図のようなベータ分布と呼ばれるものになり、短い方のバラつきは小さく、長い方のバラつきは長い尾っぽ(Long Tail)のような形になります。

 

 

プロジェクトの不確実性もこのベータ分布となります。

 

次に、エンジニアがプロジェクト中の自分が担当するステップの日程を見積もるときに、上記のことを考えると、どんな見積をするかを考えます。

エンジニアは不確実性の問題を身をもって知っているので、自分の作業が遅れてしまうことを当然ながら嫌がります。

ある仕事にかかる時間を聞かれれば、当然、時間通りに終わる確率を上げるためにセーフティーをたくさん取ろうとしますが、ベータ分布の図で考えると、中央値では予定通りに終わる確率は50%になるので、最低でも80%くらいの確率を求めようとすると、中央値よりもずっと右の方の時間を見積もろうとします。

この本では、80%の確率で作業を終えるためには、セーフティーを持たない時間の200%くらいのマージンを取ろうとするはずだと言っています。

さらに、作業者を取りまとめるリーダーは、2つの作業のセーフティーの見積がそれぞれ5だったとすると、5+5=13のように、新たに3のセーフティーを付け足そうとするのですが、これらは自分たちのせいで日程が遅れることを阻止するためでもあると同時に、上位マネージメントからセーフティーを削られることを知っているので、予め足しておくという心理も働きます。

このように、プロジェクトの日程は、個々のステップの見積りに十分なセーフティーが含まれた上で作成されていきます。

つまり、プロジェクトスケジュールには、たっぷりと余裕があるはずなのです。

 

遅延は伝達、早まりは伝達しないメカニズム

個々のステップには十分すぎるセーフティーが乗っているはずなのに、なぜプロジェクト全体で遅れが生じるのかを追及していきます。

学生症候群

簡単に言うと夏休みの宿題をギリギリまでやり始めないということです。

一旦、安全な日程を確保した後は、自分のペースでセーフティーを他の仕事に割り当てて、期日までに終わればいいという感覚で期日通りに終わらせます。

ここで、セーフティーの浪費が起こっているわけです。

作業の掛け持ち

ある作業者が複数のステップを担当している場合、作業者がステップを一つ一つ順番にこなしていけば、それぞれのリードタイムは計画通りに終わるはずが、周囲からのプレッシャーで、すべてのステップを早く終わらせるように催促されると、作業者は担当するすべての作業を一つを少しやって、別の作業に移ってまた少しやって、それぞれを少しずつ進めるようなことが起きます。

そうなると、ある一つの作業が終わるまでのリードタイムは計画よりも長くなってしまいます。

ステップの従属関係

2つのステップが、一つが終わってから次のステップを開始するという従属関係にあるとします。

最初のステップが計画よりも遅くなると、その遅れが次のステップに伝達されて、全体スケジュールが遅れることになります。

ところが、最初のステップが早く終わっても、次の作業者は早く終わった分、早く始めるわけではありません。

この理由の1つは、前の作業者が早く終わったことを報告しないためであり、もう一つの理由は、仮に早く終わったことが報告されても、次の作業者の準備が出来ていないために作業を始められないために、早く終わったことは伝達されないことになります。

 

TOCの思考プロセスをプロジェクトに応用する

作品中、主人公は同僚の先生からTOCの考え方を教わり、深く感銘を受けます。

本の中で、改めてTOC(制約の理論)をどうやって組織改革に応用していくかが解説されています。

そして、このTOCの考え方をプロジェクトマネージメントに応用できないかということを考えていくわけです。

結果、すべてのステップにセーフティを持つのは部分最適でしかないことに気づきます。

また、プロジェクトを予定通りに終わらせるには、各ステップがそれぞれ定められた期日までに作業を終えるしかないという思い込みをしていることにも気づきます。だから、各ステップに十分すぎるセーフティをつけてしまうのだということです。

守るべきはクリティカルパスであって、プロジェクトマネージメントにおけるボトルネックはクリティカルパスであると気づくのです。

クリティカルチェーンの一つ目の考え方は、

  • クリティカルパスの各ステップのセーフティーを一つにまとめてプロジェクトバッファとする
  • プロジェクトバッファをリーダーがまとめて管理する
  • プロジェクトバッファは、各ステップのセーフティ合計の半分にする
  • クリティカルパスに合流するパスにも合流バッファを設ける

 

TOCの考え方から、プロジェクトの進捗管理は、クリティカルパスでしか評価しないという方法で日程短縮が図れると結論づけます。

主人公の下で学ぶモデム製造会社では、この方法を取り入れて実際に進行しているプロジェクトの日程短縮が現実のものとなっていきます。

 

リソースバッファ

各ステップからセーフティを取り上げて一括管理する考え方では、ステップの従属関係の課題を解決する必要があり、リソースバッファという考え方を導入します。

バッファというよりは、情報伝達的なことになりますが、クリティカルパスで作業を控えている作業者に、一週間前、3日前、前日にリマインドをすることで、スムーズな作業移行をしていきます。

プロジェクトリーダーに状況を報告する中で、前の作業が早く終われば、次の作業者の早めの準備を促し、遅れそうならそれ相応の対応をできるようにします。

大事なことは、クリティカルパス上での作業は、他のどの作業よりも優先して集中しなければならないことがチームメンバーに周知徹底されていることだと言えます。

 

プロジェクトが遅れたときの損出額を認識する

プロジェクトが遅れる原因の一つに、コスト優先で選んだ外注さんの遅れというのがありました。

ここで重要なことは、チームメンバーがプロジェクトが遅れたことによる会社の損出額を認識することだということになります。

遅れによる損出を認識し、外注に損出額よりも小さいインセンティブを支払うことで遅れを抑えるように外注との交渉を行うことが出来ることを作品中で示しています。

 

更なる探求

TOCの考え方をプロジェクトマネージメントに導入し、クリティカルパスに神経を集中することで、大幅な日程短縮が実現できることがわかってきたが、あるときMBAコースの生徒から、非クリティカルパスで問題が起きているという報告があります。

何が起こっているか講義の中で検証していき、リソースバッファがうまく働いていない、つまりリソースがコンフリクトを起こしていることを発見します。

この原因は多くのパスで共通して活用する部署のリソースであることがわかり、このリソースによるステップをXとすると、Xの作業が複数のパス間で同時に起こらないような工夫が必要であることがわかります。

Xの作業が重ならないようにスケジュールすることで出来るパスを、クリティカルチェーンと呼ぶことにしたというわけです。

 

さらに、このリソースの重複がプロジェクト内だけではなく、複数のプロジェクト間で競合することも起きえます。

この時、複数の部門でリソースの重なりが最も多い部署を、ボトルネックとして定義します。

そしてボトルネックである組織のリソースに関するスケジュールを先に立てて、それ以外についてはボトルネックのスケジュールに合わせて作成することで、複雑なリソースの重複も解決できるというわけです。

さらに、このボトルネックを守るために、ボトルネックバッファを用意して、ボトルネックの作業を前倒しで開始できるようにします。

このことによってボトルネックでの不確実性からスケジュールが守られるというわけです。

この作品で紹介されているクリティカルチェーンによるプロジェクトマネージメント手法(CCPM:Critical Cain Project Management)がどのように生まれたかについての解説は以上になります。

 

その他の書籍紹介記事

「ザ・ゴール2」から学んだ思考プロセス

オープンイノベーションの本質を学べる「ワイドレンズ」

 

クリティカルチェーンからの学び

この本は、TOC(制約の理論)がプロジェクトマネージメントに適用出来ることを示し、かつそれによって予定通りにプロジェクトを進めるための新たなプロジェクトマネージメント手法があることを教えてくれました。

 

プロジェクトマネージメントは、PMIという非営利団体によってPMBOKという形で体系化されており、世界標準になっています。

5つのプロセス(立ち上げ、計画、実行、監視・管理、終結)と10の知識(品質管理、原価管理、スケジュール管理、スコープ管理、要員管理、コミュニケーション管理、リスク管理、調達管理、ステークホルダー管理、統合管理)というなんだかちょっと難しい学問のような体系として定義されています。

この知識を習得することは、プロジェクトマネージメントを遂行する上で大いに役立つことは間違いありませんが、知識があればちゃんと出来るというものでもありません。

プロジェクトは日々動いているし、人間がやっているものです。

優れたプロジェクトマネージャーは、知識だけでなく、考える力やセンス、そして判断力も必要です。

TOCは、もともと泥臭い人間の行動や考え方を取り入れた考え方です。

クリティカルチェーンは、PMBOKで提供されるプロジェクトマネージメントのノウハウとは全く違う視点で、特に人間の特質を十分に考慮した新しい考え方になります。

どちらも重要ですが、企業ごとのプロジェクトの特質なども考慮して、本質的な課題を見据えてプロジェクト管理を行っていくことを学ぶことができたし、そのようにやっていきたいと思います。

 

 

まとめ

 

私自身、国内の大手メーカー、海外半導体メーカー、EMS企業などで製品開発のプロジェクトマネージメントを数えきれないくらい経験してきました。

PMBOKもこんなのがあるかというレベルでかじってはいたものの、プロジェクトマネージメントのスキルは経験とセンスだとずっと考えていました。

今でも対象がどんなものであっても、プロジェクトマネージメントを平均点以上の結果で終わらせる自信はあります。

ただし、「クリティカルチェーン」で生み出されたCCPMという手法は、人間の習性を捉えて、そこにうまく手を入れようとするものなので、このロジックを成り立たせるには、プロジェクトリーダーが手法を理解するだけでは成り立ちません。

組織全体、メンバーの一人ひとりが、このマネージメント手法の本質を理解する必要があると思います。

 

CCPM実践の支援

この本を読んで理解すれば、この手法が優れていることは理解できると思います。

しかしながら、実践するには、トップマネージメントの理解、中間マネジャー、現場作業員の全員がこの手法のしくみ、重要ポイントを理解した上でないと成果が出せないと思います。

つまり組織全体での教育と、リーダーへの実践方法の伝授です。

組織としてCCPMにチャレンジしたいと思われたら、下記の問い合わせからご相談ください。

 

 

 

コメント

タイトルとURLをコピーしました