どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし2-9(原理編9):CCPMが解決する対象問題の関連性と解決方針
CCPMのおはなしシリーズです。
今回も原理編です。前回まで(長々と…)プロジェクトマネジメント知識体系を取り入れたプロジェクトで発生しやすい典型的な問題を紹介しました。
今回は、紹介した問題点の関連性の整理とCCPMでの解決方針について紹介します。

-----------------------------
<参考情報>
本内容は連載的に紹介しております。本記事の前提や全体的な構成についてはこちら(リンク)を参照ください。
現在記載の内容は原理編です。こちらの前提や構成に関してはこちら(リンク)を確認ください。
-----------------------------

前回まで3回に渡って、プロジェクトマネジメント知識体系を取り入れているプロジェクトにおける問題点を提示しましたが、まずは紹介した問題の関連性について紹介します。


■CCPMが解決する対象の問題:キーワードおさらい

前回までの3回にわたり紹介した問題点について、キーワードでおさらいしてみます。

★タスク編
計画によるタスクの見積りと実施の影響
・見積りの不確実性
・遅れは許さない進捗管理
・稼働率100%とバッドマルチタスク
・タスクの個別バッファ(安全余裕)

個々のタスクに個別バッファが含まれた場合の影響
・学生症候群
・マーフィー
・パーキンソンの法則
・早期完了の未報告


★管理編
タスクの遅れ(ギリギリか遅れる傾向)による影響
・タスクの従属性による遅れの影響
・早く始めると(バッド)マルチタスクが増大

問題の優先順位判断方法
・目先の問題解決は全体に影響しないことも
・クリティカルパスの問題を優先

リソースの考慮
・クリティカルパスにリソース制約を考慮


これらのキーワードについては前回までの内容をご確認ください。

プロマネで発生しやすい問題 Д織好編(前編)
プロマネで発生しやすい問題◆Д織好編(後編)
プロマネで発生しやすい問題:管理編


■CCPMが解決する対象の問題:関連性

こちらの内容は、細かい部分の整理になりますので、興味が薄ければ次の「■CCPMによる解決策の方針」をすぐ見て頂いても構いません。
ざっくりと問題の関連性を図にまとめてみております。

★タスク編に関連する問題点の整理
紹介した問題点を整理し、以下の図のようにまとめています。
問題構造その.織好
※クリックで拡大

・遅れは許さない進捗管理やバッドマルチタスク、見積りの不確実性を考慮した結果、個々のタスクには個別バッファ(安全余裕)が確保されてしまいます。
・個別バッファのあるタスクに対しては、パーキンソンの法則(+バッドマルチタスク)により早期完了のみ報告が発生します。結果、タスクはギリギリでの完了になります。
・また、個別バッファのあるタスクは学生症候群(+バッドマルチタスク)により、開始タイミングでは放置され開始が遅れてしまいます。
・開始が遅れたタスクは、マーフィーの法則的な想定外の発生(+バッドマルチタスクの割込み)により、終了付近で問題が発生してタスク完了が遅れてしまうことがあります。

結果として、個々のタスクはギリギリか遅れる…ということになります。


★管理編に関連する問題点の整理
管理編の問題を追加しております。
問題構造その管理
※クリック

・個々のタスクの遅れは従属性により、プロジェクト全体にの遅れとなります。
・目先で発生する問題を優先して対処している状況では、プロジェクト完了に繋がる問題を解決出来ず、結局プロジェクトの遅れを止めることが出来ないことが多いです。
・クリティカルパスはリソース制約を考慮しないと想定の期間よりも遅れることが多々発生します。

結果として、プロジェクト全体が遅れてしまうことに繋がってしまいます。


★間違った対策による問題点の整理
(すぐに思いつく)対策を行うとどうなるでしょうか?
問題構造その4岼磴辰紳从

・遅れる前提で早く作業を開始すると、バッドマルチタスク状況を増幅させてしまいます。
 バッドマルチタスクは、複数の問題の発生源ともなっておりますので、これを増大させてしまうと全体的に悪化してしまいそうです。
・また、遅れに対して厳しいプレッシャーを増やした場合には、個別バッファを確保するための見積もりの化かし合いのような状況になってしまいます。

この結果は、プロジェクトの遅れを回復できないばかりか、ストレスの高い環境を生み出してしまいます。


これらの問題を解決するにはどうしたら良いでしょうか?
なるべく発生源の問題に対して対処をした方が良いことになるでしょう。


■CCPMによる解決方針

さて、CCPMによる解決方針ですが、大きく2つのポイントを紹介して他に繋げてみようと思います。
紹介する解決対象は以下2点です。

・タスクの個別バッファ(安全余裕)
・問題の優先順位判断
※バッドマルチタスクの対策については「■(参考)バッドマルチタスクの対策」に後述します。


1.タスクの個別バッファ(安全余裕)に対する対策
見積りにおいて、タスクに個別バッファを入れてしまうという傾向ですが、以下2つの対策を行います。

A) 計画・見積もりの段階で個別バッファを取り去るべく個々のタスク期間を短縮する
B) 取り去ったバッファは1つの「全体バッファ」にまとめる

以下の図のように予定+バッファという設定を行います。
見積り短縮は結構モメます

この「タスクの短縮度合」と「全体バッファ設定量」に関しても議論は多数あるのですが、今回はタスク短縮は半分、全体バッファは取り去った個別バッファの総量としておきます。

※上記計画を行う理由
この対策は極端な方法に見えるですが、理由は見積もりの不確実性で紹介したβ分布にあります。
β分布から考える

本当にタスクの見積り-結果がこの分布の通りだとすると、50%は早く終わっているはずなのです。
個別バッファ(安全余裕)があれば時間を使い切ってしまう早期完了の未報告が発生するのであれば、その時間は最初からカットします。(つまり、β分布の仮説で50%は短縮できるはず⇒タスクを半分に短縮する、という考え方です。)
本当に時間のかかるタスクは20%以下といったことになりますので、それを上手に発見して対策を打つことでタスクの平均完了期間を短縮できるという見込みが出来ます。

-----
余談になりそうですが、ここで少しだけCCPMで使われる専門用語を入れると、
・80%で終わりそうな確実な見積り:Highly Possible(HP)
・50%で終わる攻めた見積り   :Aggressive but Possible(ABP)

HPとかABPとか呼ばれるものが計画・見積りにおいて出てくる概念になります。CCPMでは全ての計画を「ABP」で見積もることでプロジェクトの期間短縮を試みます。
-----

では、遅れているタスクの問題について優先順位判断する方法を以下に記載します。


2.問題の優先順位判断方法に対する対策

もう一つ、本当に必要な問題を優先として判断する方法になるのですが、
まずは、既に紹介した以下の内容をおさらいします。

・プロジェクトの期間を決めるのはクリティカルパス
・クリティカルパスにはリソース制約の考慮が抜けることがあるので、明確にクリティカルチェーンと名付ける

このリソース制約を考慮したクリティカルパスである「クリティカルチェーン」を遅らせる問題を最優先として問題解決できるようにします。

さて、上記「1.タスクの個別バッファ(安全余裕)に対する対策」に記載したタスク列と全体バッファ設定をクリティカルチェーンを対象にしていればどうなるでしょうか?

プロジェクト全体の遅れが分かるようになります。
クリティカルチェーン上のタスク進捗の遅れを「全体バッファの消費」として扱うと、全体バッファの消費状況が「クリティカルチェーンの遅れ」として明確になります。
クリティカルチェーンとバッファ

この全体バッファの消費状況を確認して、バッファ消費させているタスクを優先にすることで、問題の優先順位が「クリティカルチェーン上で、実施しているタスクを最速で終わらせる」というシンプルな判断ができるようになります。


★補足
実際には、プロジェクトのスケジュールは分岐や合流が多数存在しておりますので複雑にはなります。この複雑なスケジュールを管理しようと思うとこちら(リンク)で紹介したツールを活用とすると楽になります。

ただ、チーム単位でCCPMの考え方を役立てようとするのであれば、「実践編」に紹介するようなクリティカルチェーンを1つ「決めて」管理する方法も可能です。


■(参考)バッドマルチタスクの対策

紹介した問題の関連図では、「バッドマルチタスク」が多くの問題に影響していることが確認できます。ここで、CCPMで実施しているバッドマルチタスク対策についても2つほど紹介します。

・計画時の合流をなるべく遅くする
・同時に扱うプロジェクトの数を減らす

1.計画時の合流をなるべく遅くする
問題点のキーワードとして「早く始めると(バッド)マルチタスクが増大」というものがありました。(以下図は前に紹介したものと同じ)
爆散ふたたび

この問題を解決する場合には、逆にギリギリ間に合うような「遅い開始」をして、合流させればよいという考え方であれば、(バッド)マルチタスクは増えないはずです。

ただ、このやり方をするとクリティカルチェーン以外の部分で余計な遅れを生む可能性が有りますので、合流対象のタスク列にもバッファ(フィーディングバッファと呼ばれる)を入れることで対処します。
なる遅計画
※クリックで拡大。

以上の方法で、計画レベルで(バッド)マルチタスクを減らそうとしております。


2.同時に扱うプロジェクトの数を減らす
こちらは組織的な話になります。
(バッド)マルチタスクがあらゆる問題につながるという背景があるなら、組織が同時に扱うプロジェクト数を減らそう、という考え方です。

1つの企業で年間1000件のプロジェクトを完了させているとしましょう。
月平均200件動いているとして、これを同時100件までにして、それぞれの速度を高めて1つ1つ解決することでバッドマルチタスクを減らします。
シングルへ
※クリックで拡大

上記図で(突っ込みどころがあるかもしれませんが)プロジェクトを減らして期間を短縮する効果は概要的に分かると思います。
これが出来る理由が「バッドマルチタスクによるオーバーヘッドでの非効率を取り除ける」という点、「対策が必要な遅れは検知して優先的に解決する」という点にあります。

実際には、プロジェクト期間が短くなることで一時借入金が減るなどといった財務的な効果もあるのですが、この場では説明を省略します。


以上のようにCCPMが解決する問題があり、CCPMの手法は問題が上手く解決するような手順になるように考えられております。

次回で原理編最後です。
CCPMの手順に対してそれぞれ解決している問題点をマッピングしてみます。
| TOC/TOCfE/CCPM | 14:57 | comments(0) | - |









 123456
78910111213
14151617181920
21222324252627
28293031   
<< October 2018 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ