CCPM(Critical Chain Project Management)とは？
かの有名な書籍「ザ・ゴール」の著者であるゴールドラット博士が提唱したプロジェクトマネジメント手法です。
スクラム等のアジャイルが大きく取り上げられるようになり、少し影が薄くなった感はありますが、使い方によっては効果を発揮する手法だと思います。
PMBOKでも取り上げられているこの手法をプロジェクトで実践した経験から少しお話しさせて頂きます。
1.Freeze ：選択と集中
ここでの「Freeze」とは凍結の意味です。今はやらなくてもよいことを凍結し、やるべきことを選択しそれに集中するという意味を込めています。
CCPMがADMやPDM、PERT等の古典的なスケジューリング理論と大きく違うのはリソースの取り扱いです。そのためまずはプロジェクトメンバーが集中できる環境を作ることが重要な準備となります。
メンバーは他の仕事と掛け持ちするマルチタスク状態を避け、１つのプロジェクトに専任できることがCCPMに取り組むための大前提かも知れません。
３つの仕事をマルチタスクで行う時と、１つの仕事が終わるまで次に仕事に入らない時と、全体としてはどちらが早く終わるのでしょうか？
答えは後者：１つの仕事が終わるまで次の仕事に入らない（シングルタスク）時なのです。しかも３つのタスク共に後者の方が早く終わります。
一般的には時間や分単位で見たら人間は複数のタスクを同時にはできませんのでシングルタスクしかありえないのですが、複数のタスクを１時間毎に区切って入れ替えて仕事をしていたら効率が悪くなるのは当然です。CCPMの研修を受けた時にこれを実習で体感できます。
CCPMではマルチタスクにより次の処理や次のフロー（担当者）に渡せない状態を「悪」＝バットマルチタスクと呼び、これを徹底的に排除しなければなりません。
しかしながら、人的リソースが限られる中で１つのプロジェクトに専念させるのは難しいことです。
同じ組織内のコントロールできる範囲であれば何とかなるかも知れませんが、顧客からの要望や定例イベント等で完全な専任は難しいのが実態です。CCPMが全社的な取り組みになって、会社としてCCPMの配下でプロジェクトの優先順位をつけて「今はやらないこと」＝「順番にやること」を決められる環境が理想です。
とはいえ、難航しているプロジェクト、遅れを挽回しなければならないプロジェクトに部分適用するケースでもその効果は充分にあると思います。
※余談：企画業務等でアイデアが欲しい時にはできるだけ早くお題を脳にインプットしておいた方がアイデアの種は生まれやすいというのはあります。これについて以前投稿しましたアイデアについてのお話を参照ください。
アイディアはどこで生まれる？ – IT業界カウンセリング雑談 (taworks.jp)
2.ODSC：目標のすり合わせ
ODSCとは次の3つの言葉の頭文字から来ています。
Objectives：目的、Deliverables：成果物、Success Criteria：成功基準
この３つを定義しプロジェクトのゴールを決めて関係者と合意することです。
これは１つ注意が必要で、プロジェクトメンバー全員で熱い議論をするとゴールの定義がたくさん出てきます。しかし、これをそのまま全部書き出してゴールにしてはいけません。
本当に実現しなければならないことに絞ることが重要です。そうしないと後述するバックワードでWBS化する時に発散してしまう可能性があります。
あと、このゴールの定義はプロジェクトメンバー全員がわくわくする言葉が欲しいところ。特に目的にはメンバーの人材育成視点を入れることもポイントかもしれません。プロジェクトが迷路に陥った時に必ずここに立ち戻ることができるようにしたいですね。
3.Backward scheduking；ゴールから遡ってタスクを定義する
次は、定義されたゴールから遡ってやるべきことを洗い出すことです。
しかしこれを難しく考える必要はありません。重要なことを急いでやらなければならない時、普通に皆さんがやっていることです。
例えば、客先プレゼン当日の朝、寝坊してしまった時、時間に間に合わせるために何からやればよいかとっさに考えますよね。それと同じです。
ＷＢＳを後ろから作るイメージと言った方が判り易いでしょうか。そのためには以下の様な３つの質問を繰り返します。
①□□の前にやるべきタスクは何ですか？
②○○が出来たら□□が出来るんですね？
③〇〇の他にはないですか？
その時に重要なのは「やるべきタスクしかやらない」ということです。「やった方が良い」タスクはやらない、排除します。
それで完成したプロジェクトネットワーク図は、プロジェクトの目指す姿を達成するために真にやるべきことが表現された「工程表」になっているはずです。
また、この工程表作りに参加された方々の経験値やノウハウが結集されたものになっていることも多いものです。タスクの依存関係の工夫で劇的に納期短縮が可能となったこともありました。
さらに、この工程表がいくつかの実践を通じてブラッシュアップされ、プロジェクトでの学びが蓄積されていけば、組織の財産になっていくでしょう。
なお、実際にやってみて判ると思いますが、ODSC（成功基準）が適切ではないと工程もへんな方向に大きくぶれる可能性があります。なんだか無茶な工程になってしまったら成功基準を見直すことも必要です。
4.ABP：工程のサバ取り
次に設定された各タスクにリソース（通常は人）をアサインし見積工数を入れます。
工数を算出する際にエンジニアはあまり意図せず多めに出します。
これを「サバを読む」と言いますがこれは何も悪いことではありません。自分の工程を確実に実施し後工程に迷惑を掛けないために「誠実で責任感」がある人こそがこの「さば読み」を生むのです。
それを積極的に活用するのがＣＣＰＭの極意です。
通常はサバ読みした工数、HP(Highly Possible) ＝80％できそうな時間（工数）で見積をするのですが、CCPMではABP(Aggressive But Possible) ＝きるかどうか５分５分の時間（工数）で工程を組みます。
HPで工程を組んでいた今までは何が起こっていたか？
人は与えられた時間はあるだけ使って品質を上げたいと思うのが通常の心理で、早く終わったとしてもそのタスクの期限まではブラッシュアップしますよね。それが責任感というものでしょう。
CCPMではこれを各タスクに織り込まれた「バッファ」と考え、各タスクから切り取ってしまいプロジェクト全体で使える「バッファ」に集約しようとするものです。
もう少し正確に定義すると、最も長い工程のパス（＝クリティカルパス）の工数の半分を、プロジェクトの最後尾にまとめ、さらにそれを半分にするといった荒業になります。納期短縮の可能性を最初から織り込むことになります。
それでは普通に見積もった工数(HP)をバッサリ半分(ABP)にして工程表を作ると何が起こるか？
エンジニアは怒ります！
当然ですがCCPMの仕組みを知らなかったらそうなりますね。でもキチンと理解していれば大丈夫です。
まず、本来はできるかどうか判らない（もしくはできるわけがないと思っている）工数を割当られるのですから、普通にやったらダメだろうと考えますね。そうなると、もう少し早くやる方法は無いものか工夫を考える、チームでアイデアを出し合うようになります。もしろんその様な互助精神が生まれ易い「心理的安全性」の確保も必要ですね。
この様に作られた工程表を「計画」とします。
5.Buffer Management：未来に向けたマネジメント
CCPMの工程表の進捗管理は、当然ですが今までと同じ方法でやってはいけません。
そもそも各タスクの工数や期日はできるかどうか判らない計画になっていますので、その期日を守れなかったからと言って「遅延」という言葉は使えないですし、そもそも「遅延」ではありませんし、
クリティカルチェーン上のプロジェクトバッファをどれだけ消費したか？ でプロジェクトの健全性をチェックすることがCCPMでの進捗管理となります。
指標はプロジェクトの進度応じたその時点での標準的なバッファ消化率となります。
その消化率を下回っていたら順調（緑色）であるといういこと。消化率を越えていた（黄色）あたりからマネジメントの介入が必要だと判断します。納期を越えそうな状態（赤色）もしくは、バッファの回復は不可能（黒色）になってから手を打つのが今までのプロジェクトマネジメントにありがちな危機介入のあるあるです。
「何でもっと早く言ってくれなかったのか！」というやつですね。これ、言われた方は本当に悔しいです。報告すればしたで「もっと判り易く報告してくれないと判らない」となり、暇も余裕ない状態で････と言いたくなります。
CCPMではこの様なバックミラー管理ではなく、未来を見据えた進捗管理を目指しています。
そのため、この消化率は過ぎてしまった「過去実績」を表しているのではなく、メンバーから上がってくる「見通し」の情報であることが重要です。この「見通し」を把握するために、現場のマネジメントは既に消化してしまった結果に着目するのではなく、未来に目を向けたマネジメントを常日頃からする必要があります。
現場でのメンバーへの声掛けは下の３つです。
・あと何日位掛かりそうですか？
・問題があるとしたら何ですか？
・何か助けられることはないですか？
この問い掛けにより、メンバー自身もこれからどうする？ という未来を考えながら仕事をすることになりますし、支援が必要なタスクも見つけ易くなります。
そしてさらに重要なのはこのやり取りが互いに学びあえる機会ともなり得ます。スクラムの振り返り（スクラム用語でレトロスペクティブ）の様な場ですね。
なお、CCPMの工程表を作ったり、バッファ消化率を色で知らせてくれる等の便利な管理ツールがあるので、それを使うのが一番楽ではあります。
7.：Buffer Recobver；マネジメントのアクション
バッファ消化率が高い場合（黄色～）マネジメントは何をすればよいのでしょうか？
まずはクリティカルパス上の足踏みしているタスクに着目することです。これは「あと何日か？」が増え続けてい状態であり、このタスクがプロジェクトのボトルネックになっているということです。
例えば「課題対策を進めているがなかなか見通しが立たない」みたいなケースです。この様なボトルネックになっている工程はキーリソース（=その人しかできない）が担当していることが多いのです。
ここでマネジメントがまずトライしたいのは、このボトルネックを徹底活用することです。「活用」するというのがCCPM的な言い回しなのですが、具体的には以下の様なアクションです。
・そこに担当しているキーリソースの仕事をさらに分割
・そのキーリソースしか出来ない仕事を見つけ、それ以外の仕事を他の人に割り振る⇒タスクの分割と多重化
・そのキーリソースしかできない仕事に集中できるようにする
それでもダメならさらにマネジメントとしてエスカレーションをしながら、ケースバイケースではありますが例えば以下の様なことに取り組みます。
①今やらなくても良いことを「やらないでよい」と言う。結構手続き的なことに工数を取っていたりする
②その問題解決をあきらめて、代替手段に変更する
③クリティカルパス上のタスクを後回しにする/あきらめる。スコープ変更になることが多いのでステークホルダーとの交渉要
④人的リソースの追加、問題解決支援者を追加する。クリティカルチェーン以外のタスクからの応援は一番早い。他プロジェクトからの応援は引継ぎや教育ロスもあるので突発的には慎重にやるべき
⑤最後の手段：納期を伸ばす。これはマネジメントとして謝ったり交渉したりすることが必須
⑥そして重要なこと、リーダーやメンバーの足を引っ張ることは絶対やらない、言わない
最後に
ここまで長文を読んで頂きありがとうございました。
今回はCCPMのお話でしたが、科学者としての素養も持つゴールドラット博士のTOC理論からは学ぶべきことが多いです。
皆さんもいくつか出版されている書籍を読んでみてはいかがでしょうか。
以上です。
コメント