今年を振り返って第３弾です。
また社内 SNS から再掲します。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
勉強会の overview はこちら。
TOCfE 関西分科会
http://kokucheese.com/event/index/30234/
大和ハウスさんと富士通さんとのシステム開発で、
TOC/CCPM のコンサル、研修を受けながら、導入・実践していった事例を
当事者の方からお話しいただきました。
また「サイコロシミュレーション」という、研修で行う簡単なワークも紹介して下さいました。
以下、私の知識と感想をごちゃまぜにしてのレポートとなります。
CCPM は「よくもわるくも時間はあるだけ使ってしまう」という人の特性に着目しています。
なので、CCPM では、
タスクごとのバッファ（安全余裕）はきれいサッパリ剥ぎとってしまい、
全部まとめてプロジェクトみんなのバッファとして扱います。
なので、プロジェクトのスケジュールは、
ぎりぎりスケジュール ＋ プロジェクトバッファ
となります。こうすることで。
個々のタスクに手間をかけてられなくなる
となる。つまり、
必要以上のことはやんないし、
のんびりのほほーんともやんなくなる（はずだ）
まずはこれでムダとりができます。しかも自然に。
もし思惑どおりに進まなければ、プロジェクトバッファを使う。
わるいことじゃない、どうぞ使って下さい、と。
個々のタスクの遅れを責めたりはしません。
毎日々々「あと何日かかる？」を確認し、正直に伝えてもらいます。
今回の事例では、
ぎりぎりスケジュールの部分を「通常の半分でやるぞ！」というチャレンジングな設定にしたそうで、
バッファを使うのは「ふつうのこと」。
最初から縮められたスケジュールであり、「遅れ」という考えをしないことを
プロジェクトの中で徹底したそうです。
例えば、「しめきり」や「納期」に当たる文字や言葉はプロジェクトの中から全て排除しました。
実はこの「遅れが出てくること」が大事なことなのです！
『遅れ』こそ問題出現のバロメータ
として捉え、
最も遅れているところに着目し、
みんなで助けあってそこを叩く！
これが CCPM です。
今回あえて工期を「通常の半分」としているのも、
工期を短く設定することで「問題を出しやすくするため」とのこと。
問題を早く出して早く対処する。まさにアジャイルそのものですね。
できそうにないくらいのスケジュールにしておかないと、力わざでどうにかしてしまうもの。
だからムリなくらいでないとダメ、
ともおっしゃっていました。
このへんがメソッドらしさ。納得です。
だから、バッファを使ってないのはむしろまずい。
予定通りいっているところは、安全余裕がまだ残っている、ムダがとり除けていないと判断します。
最後に、このプロジェクトのスローガン的なものとしてご紹介下さった、以下を挙げておきます。
CCPM を知っている人にはピンとくる内容と思います。
■ ３つのルール
- リソースの集中
- 局所的な評価の排除
- バッファが与えられた計画と、バッファの管理
■ ４つの行動
- タスクの準備をする
- バッファの優先順位に従う
- 素早く問題解決する
- システムを最新に保つ＝残り時間の報告
最近、勉強会に出ていて思うのは、
本だけだと内容の重みづけやニュアンスが伝わりにくいものですが、
ひとが話しているのを聴くと、
「何度も言う」「盛り上がる」等の様子でもって
「ここがキモなんだ！」「こういう意味だったのか！」というのに
気づく瞬間があるということ。
「気づきがある」とはこういうことなんだ、と思い始めているところです。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
CCPM（クリティカルチェーン・プロジェクトマネジメント）は、
今年いろいろと事例が取り上げられて、ずいぶんメジャーになりました。
CCPM には以前からすごく興味があって、本は読んでましたが、
この勉強会でお話を聞かなかったら、バッファの目的は理解できていなかったと思います。
TOCfE を知り、勉強会の存在を知ったことも、今年の大きな出会いのひとつです。
