Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

CCPM のこと

社内勉強会をする。
CCPM を紹介しようと思うので、以下、ラフな下書き((C)あきぴーさん)。


なぜプロジェクトは遅れるのか
CCPM でゆとりのマネジメント(仮)

■参考資料
『最短で達成する 全体最適のプロジェクトマネジメント』岸良 裕司

今回も許可なく引用しております m(__)m


やったことのないことに対して人は正確に未来を予知し、
リスクをコントロールできるのだろうか?

私は超能力者ではないので、大変むずかしいと思っている。

※ここは割愛する?、で、次を引用する?


不確実性の高い作業を詳細に分解しても、不確実性をすべて抑え込めません。
むしろ細かくすればするほど「創作」や「作文」が多くなり、精度は悪化します。
要するに作業をどれだけ分解しても、開発工程の時間見積もりは正確にはできないということなのです。

あくまで立案されるのは「絵に描いた計画」であって、そのとおり進むという保証は何らありません。

実はこれまで皆さんが正しいと考えてきた開発計画の立案方法には、根本的な矛盾があるのです。

TOC流の開発型プロジェクト管理術「CCPM
なぜプロジェクトの進行計画はいつも壊れるの?
クリティカルチェーン・プロジェクトマネジメント」とは
http://monoist.atmarkit.co.jp/mn/articles/0812/17/news141.html


プロジェクトとは、不確実性が高く、納期があり、人が行なうもの

■5つの人の行動特性

  • サバよみ
  • 予算と時間をあるだけ使う
  • 一夜漬け
  • 過剰管理
  • 早く終わっても報告しない

(それぞれ図で説明)

マルチタスクのことは割愛する、バッファマネジメントに注力

クリティカルチェーン

(図で説明)

■サバ取り

(図で説明)

v できるかできないか五分五分の「チャレンジ期間」
v 安全余裕である「サバ」

に分けていく

■プロジェクトバッファ

(図で説明)

(再度、β分布の図)

できる確率が50%の納期で設定する
→50%の確率で遅れが発生する

(余裕を半分の図で説明)

※まずはここで「納期が短くなるじゃん」と見せておく

■みんなで議論

はじめに納期ありきがプロジェクトの現実...

1. 段取り工程表をつくる
2. クリティカルチェーン上の期間を確認する
3. バッファを入れて納期を確認する
4. クリティカルチェーン上の長いタスクを確認する
5. みんなで短縮する方法について知恵を絞る
6. 納期が間に合うようになるまで 2~5 を繰り返す

→ゆとりはつくるもの

■叡智を集めて

ベテランや他のメンバーの考え方や過去の経験からくる暗黙知が引き出される
全員がその考え方を学ぶだけでなく、参加メンバーから新しい知恵も出される

→組織の知恵である暗黙知形式知

■ゆとりのマネジメント
「進捗率」の定義は人それぞれ

(図で説明)

進捗率で管理される限り、人は「進捗率を稼ぐにはどうすればいいか」という基準で行動する

■「あと何日」で管理する

大切なのは納期を守ること
残りの日数で数え、率で判断しない

(図で説明)

■「あと何日」は人を育てる

  • 見積もりを毎日訓練する
  • 完了までの日数を毎日意識させる
  • 完了までの段取りを考える訓練になる
  • 作業の質が日々改善される

■バッファマネジメント

(図で説明)←2日めのとこに「いまココ」を入れておく

■バッファマネジメント
何か問題があれば必ず遅れという形で「見える化」する

(青、黄、赤の図で説明)

プロジェクトマネジメントにおいて重要なのは
「いつマネジメントが介入するか」よりも「いつマネジメントが介入しないか」のほうである

過剰管理は、煩雑な報告作業などで現場の集中をそぎ、かえって事態を悪化させてしまう
※赤文字で強調~!


CCPM ツールの画面)

いかにリスクを予測して、入念に準備しても予想外のことは必ず起きる。
どうしても「ゆとりは」必要なのだ。
「ゆとり」がなければ、助けたくても助けられない。

サバなしのギリギリの納期を約束した見返りに、プロジェクトマネージャーがバッファで現場を守る
※↑これは削るか

■遅れの改善

納期を守るためにこれから何をすべきかみんなで議論する

パレートの法則

(図で説明)

TOC

Theory Of Constraint:制約理論

一番弱いところが全体の制約。全体をよくしたいなら、この制約に取り組めばよい。

  • 一か所に取り組むほうが楽
  • 効果も手っ取り早く期待できる
  • 費やされた努力は全体最適に向かう

CCPM

Critical Chain Project Management

5つの処方箋

  • Check 選択と集中
  • ODSC 目標すり合わせ
  • Backward Plan 段取り八分
  • Aggresive But Possible サバ取り
  • Buffer Management ゆとり

CCPM

プロジェクトマネジメントにおける根本的な誤りは、安全余裕を個々のタスクに入れて見積もるという慣行である

安全余裕は個々のタスクに入れるのではなく、プロジェクト全体を守るために入れるべき


Question:
プロジェクトにはバッファが必要だということを理解してもらう為に、どのようなことを行われましたか?

Answer:
貴方は、タスクの安全余裕(=バッファ)を取り、「挑戦」する人をどのように支援しますか。
「大丈夫だ!困った時には助ける」ですか。本当の意味で信頼関係ができているならこれで十分かもしれません。
しかし、「本当の」は非常に希なことです。
ですから具体的な「助け」を明確にすることが重要ですね。それが「バッファ」です。これが確保されているから「挑戦」できるんです。

また、時間を短縮することが最も大切だと考えている人に、「バッファ」という余裕が必須であることを理解してもらうことは難しいことです。
バッファは短縮とは全く逆の対応ですから。(...)「バッファ」の効果は百年もの間に証明された考えです。

「早い流れが欲しいならバッファが必要です」、まさに、パラダイムシフトです。
(...)
このパラダイムシフトは本当の話ですから実際にCCPMを使うと理解できます。また本当のトヨタ式を勉強すれば理解できます。

マツダ/パワートレイン開発本部でCCPM導入を推進した 元マツダ/田中義道氏 特別インタビュー
http://www.toc-ccpm.net/tanakaqa/index.html

※これは蛇足感ありありだなぁ(とても好きなページなのだけど)

※渋滞理論も似てるかな?、WIPの制限とか?、そんな話も蛇足なだけか
※「とりあえず先に進めとこ」じゃなくて、「遅れてるところを手伝おうぜ」なんだ、ということか


さて。twitter を見ていると、倉貫さんの "納ない本" の紹介とともに、以下のページがあらためて話題になっていた。

ソニックガーデンでは「月額定額の納品しない受託開発」を実践しています。
毎月定額なので、開発者は赤字に陥るリスクにおびえながら(たっぷりとバッファを積んだ)見積りをする必要はありません。

アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try

納期を守って頑張ろうよ的なまとめをしてたところにこれを読んで、ちょと凹んだけど。

まぁ、今回はアジャイル開発の説明ではないのだし、我々の現実は「納期ありき」の世界なので。

実は、私が社内勉強会をしたいと思ったのは、この本と CCPM のことを伝えたいと思ったところがスタートだった。
だから、今回でようやく自分の中で「始まった」感じがする。