プログラマの思索

CCPM（Critical Chain Project Management：クリティカル・チェーン・プロジェクト・マネジメント）の解説記事があったのでリンクをメモ。

【元ネタ】
CCPM とは：梅田弘之のプロジェクトマネジメント講座：【第６章】大型プロジェクトにはCCPMを取り入れよう

サルでもわかるTOC/CCPM(第五回)｜ザ・プロジェクトマネジャーズ

TOC流の開発型プロジェクト管理術「CCPM」（1）：なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは (1/3) - MONOist（モノイスト）

TOC流の開発型プロジェクト管理術「CCPM」（2）：PDCAサイクルに潜むプロジェクト管理の問題点 (1/3) - MONOist（モノイスト）

TOC流の開発型プロジェクト管理術「CCPM」（3）：TOCのPMが本当に管理すべきポイントはどこか (1/3) - MONOist（モノイスト）

TOC流の開発型プロジェクト管理術「CCPM」（4）：プロジェクト管理の成否はバッファ設計で決まる (1/3) - MONOist（モノイスト）

TOC流の開発型プロジェクト管理術「CCPM」（5）：進ちょく率管理で納期遅れを防げないのなら…… (1/3) - MONOist（モノイスト）

TOC流の開発型プロジェクト管理術「CCPM」（6）：対策の実施されないマネジメントは今すぐ中止！ (1/3) - MONOist（モノイスト）

【1】CCPMは、クリティカルパスに人間の心理学を適用したプロジェクトマネジメントと言える。

人間の心理を支配する法則として、パーキンソンの法則(仕事は常に許される時間まで伸びてくる（学生症候群））、遅延伝播の法則（遅れは伝播するが、早期終了は伝播しない）の二つがあるが、これをプロジェクトマネジメント適用したものだ。
つまり、人は与えられた期間に余裕があっても、ダラダラ作業してその余裕を食い潰してしまう。
そして、早めに自分の仕事が終わっても、他人の仕事が完了しなければ、作業待ちの時間が発生し、納期短縮が伝播しない。

CCPMでは、50％実現の確率で作業見積もりし、バッファ全てをプロジェクトバッファとして最後に一括管理しておく。
そして、各作業の残工数のみ管理し、作業の遅延はプロジェクトバッファで吸収するという考え方。

CCPMの利点は、作業時間の短縮が即座にスケジュールに反映されて納期が短くなることだろう。
残工数の管理という発想も、アジャイル開発の考え方に似ているように思う。

また、プロジェクトバッファで全作業のバッファを集めて一括管理する手法は、PMBOKにおけるコンティンジェンシー予備の発想に似ている。
つまり、プロジェクトのリスクに対する費用確保は、個々のリスクではなく、プロジェクト全体である一定の割合で費用を積み上げておくわけだ。
バッファは自分だけの持ち物ではなく、プロジェクトに関わる全員の共有物なので、作業の遅延が発生した時にバッファを使わざるを得ない時、その理由を他の関係者に明確に説明しなくてはならないプレッシャーがある。
だから、作業の遅延が発生しないように頑張らざるを得ない場面もあるのだろう。

【2】しかし、CCPMの実践は、従来の発想の逆転が必要なのだろうと思う。
まず、ギリギリの工数で見積もった計画と、プロジェクトバッファを積んだ外向けの計画の2種類を作る手間がかかる。
WBSできちんと作業や成果物をMECEで洗い出して、それぞれの見積もり工数を把握する必要があるだろう。

顧客から見れば、プロジェクトバッファを積みすぎた外向けの計画は、そのバッファの正当性を説明できなければ、単なるコストの割り増しにしか見えない。
本来あるべきプロジェクトバッファを削られてしまったら、余裕のない単なるデスマーチプロジェクトになってしまう。

また、メンバーの立場では、５０％実現の確率の見積もり工数で作業をしているために、遅延してしまったら、
「今日までXX日遅れています」という実績報告をせざるを得ず、プレッシャーがかかって本来の力を発揮できなくなる。
だから、経験者に聞くと、「残りXX日で完了できます」という残工数で実績報告するように変える必要があるらしい。
むやみにメンバーを追い詰めても、作業が完了することはないし、成果物の品質も下がるだろう。

【3】僕の考えでは、むしろ作業の完了条件の考え方も重要だろうと思う。
ソフトウェア開発では、一つのプログラムが完了するまでに、仕様書には記載されていない課題が噴出したり、顧客に使ってもらったらもっと使いやすくして欲しいなど、色んなリスクがあるものだ。
すると、3日で終わるプログラムは、障害修正や改善要望の反映などで、倍以上の工数がかかるのはざらにある。

だから、当初の計画通りにまずは動かして使えるレベルまでの工数を見積もっておき、その作業が終わったら、完了として、その後の障害修正や機能改善は別タスクとして管理するようにした方がいいと思う。
つまり、本来のチケットから障害修正や改善要望、課題などの別チケットを切り出して、それらのチケットを解決しながら、ソースや成果物へどんどんパッチを当てて改良していくように進める。

つまり、チケット駆動開発にCCPMの発想を取り入れれば、タスク管理をより柔軟に行えるようになると思う。
色々試してみたい。