【ブログVol.38】CCPMの境界

2016年3月31日
/ / /
Comments Closed
Share

クリティカルチェーン・プロジェクトマネジメント(CCPM:Critical Chain Project Management)は、TOCで最も成功し広く知られたアプリケーションです。CCPMの最も際立った特徴は、不確実性への対処の仕方で、2番目に際立った特徴は、評価尺度が如何に人間の行動に影響を及ぼし、如何にそのパフォーマンスを大きく左右するかの理解です。

_EliSchragenheimBlog_POST38_fig_1

私は不確実性の扱いを最も重視しています。なぜなら、プロジェクトの末尾に目に見えるプロジェクトバッファを追加するということは、我々はプロジェクトが終わる正確な日付を前もって知らないという、大胆な宣言だからです。このバッファは、まるで最初から工程のチェーンに組込まれた正規の期間のように見えて、ドラム・バッファ・ロープ(DBR:Drum Buffer Rope)のバッファより明確なバッファです。このプロジェクトバッファの考え方は、何時でも起き得る「日常的で避け得ない不確実性」への対処に多大な貢献をしたのです。

あなたが私をどう評価するか教えてくれたら、私がどう振る舞うかあなたに教えましょう」というゴールドラット博士の有名な格言は、CCPMより10年前に造られたものです。人間の行動への実績評価尺度の現実の悪影響は、工場の現場でハッキリと見られます。それは人がカギを握るリソースであるプロジェクトでは一層深刻です。マルチタスクのひどい蔓延も、同時実行する他のプロジェクトの存在を無視して、プロジェクトマネージャーを個別に評価すること、それ故彼らは「自分のプロジェクト」のために争わざるを得ないことに由来するのです

CCPMは非常に価値の高いブレークスルーに違いありません。しかし、常に問うべき質問がひとつあります:

その方法論の境界はどこか?

つまり、どうい場合にCCPMを使うのが有益で、どういう場合にある程度の変更が必要になるのか?

要は、その方法論の基本的な前提条件とそれがどんな場合に当てはまらないかの確認です。

論点を簡単に説明するために、癌の治療法を見つけるプログラムを考えてみましょう。そのような研究の初めに納期を決められますか? プロジェクト全体のタスクネットワークを作れますか? どのくらい期間かかるか分かりますか? そもそも納期もないのにプロジェクトバッファが何か役に立ちますか?

特定の状況では正しくないかもしれませんが、私が思うCCPMの基本的な前提条件を以下に列挙しておきます:

  1. 最初から最後までプロジェクトをどう実行すればよいか、まあ大体分かっている
    • 特にどんな要件を満たさなければならないか、プロジェクト開始時点からよく分かっている。
    • 後続の工程の仕事を劇的に変えたり、前工程に戻ったりしないといけないかもしれない、条件付きのポイントがプロジェクトのどこにもない。
  2. 納期前か納期どおりプロジェクトを完了することが何よりも重要である。
  3. 予定通り終わることと、要求された仕様と予算を満たすことの間に、よい相関がある。
  4. 進行とタイミングのコントロールは自分たちが掌握している。
  5. クリティカルチェーンを止めず連続的に実行する計画でいる。そうでないと、プロジェクトの期間を決きめるというクリティカルチェーンの定義が無意味になる。

これら基本的な前提条件のどれかひとつ以上当てはまらないと、どうなるのだろう?

では2つの例を見てみましょう:

プロジェクトのある一定の段階で顧客の確認が必要だが、顧客は確認に好きなだけ時間をかけてよいとしましょう。そうすると、4番と5番の2つの条件が無効になります。つまり、顧客に私たちの工程表を守るよう強制する手段がないので4番目は無効です。そして、顧客がチェック中はプロジェクト全体が中断状態になるので5番目も無効です。であれば、予め顧客のタスクを計画に組み入れて、そのタスクにある一定の時間の50%の時間を与えればいいじゃないかと言う人がいるかもしれません。問題は、顧客がゴーサインを出すのを遅延したら、プロジェクトチームは一体どうやって納期を守れるか? ということです。

こういう場合私が推奨するのは、プロジェクト全体をサブプロジェクトに分けることです。プロジェクトチームは、顧客に確認すべき成果物が渡るまで進捗を管理します。そこで第1プロジェクの完了です。新しい要求が追加されたとしても、顧客がゴーサインを出したら、第2プロジェクトを開始するのです。

もう一つ厄介なプロジェクトは、期日絶対厳守の納期で一切遅延が許されない場合です。そういう場合は、「完了したプロジェクト」は、内容が当初の計画に遥かに及ばないものになるか、急激にコストが増加する可能性が高く、3番目の前提が当てはまらないことを意味します。つまり、本当に重要な変動要素をタイムバッファですべて守ることができないのです。そのようなプロジェクトの計画では、「絶対欲しい」と「あれば嬉しい」要件を明確に区別しなければなりません。私は、絶対厳守の納期を守るプロジェクトバッファに加えて、あれば嬉しい要件を守るバッファを付けるのが、解決の方向性だろうと思います。

全般的な意見: 私はTOCの中ではCCPMが最もホリスティックでない方法論だと見ています。非常に一般的な問題の解決を狙っていますが、それが必ずしも組織の重要な問題とは限りません。私は、全体像を見ずに望ましくない結果(UDE:Undesireable Effect)を解決しようとするのは嫌いです。そうだとすると、あなたはプロジェクトの管理は改善できても、組織はゴール以上には達成できないでしょう。

結びの秘話: 私はある巨大多国籍企業の上級幹部と会いました。私がイスラエルで行われた素晴らしいCCPMのインプリメントの名前を挙げると、その人は「彼らはやらなくていい間違ったプロジェクトを早く終えたのだ!」と言ったのです

TOCは、ただ単にプロジェクトの計画と実行に関わるだけでなく、それらプロジェクトが、正しく選ばれたコンテンツと仕様を持った、実行すべき正しいプロジェクトだと保証することに貢献すべきだとは思いませんか?

しかし、これは組織の戦略に関与することなくできますか?

 


関連記事:

不確実性への対処においてTOCがこれまで成し遂げたこと

「日常的で避けられない不確実性」にまつわる問題

DBR/SDBRの境界


著者: エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。

この記事の原文: The boundaries of CCPM

全ての記事: http://japan-toc-association.org/blog/

Share

Comments are closed.