どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし4-4(応用編4):CCPMアラカルト(EVMとの比較、タスクサイズや見積りの正確さの議論)
CCPMのおはなしシリーズです。
応用編紹介中です。今回は比較的マニアックな感じもする話題をアラカルト的に3点議論してみます。
※応用編はCCPMの用語や知識をある程度知っている前提での紹介になりますのでご了承ください。

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


CCPMを実施するうえで(マニアックな人が)気になる(かもしれない)話題を3点紹介してみます。

・EVM(Earned Value Management)との比較
・タスクのサイズはどのくらいにするか?
・見積りは正確である必要はあるか?


■EVM(Earned Value Management)との比較

プロジェクトマネージメントの知識体系に詳しい方は、CCPMのバッファ管理グラフと比較的近い形で進捗を数値管理しているEVM(Earned Value Management)との比較が気になるかもしれません。
※本記事では「EVMって何?」という意見については説明しませんので、知らない方は別途調べてみて下さい。

確かに、EVMのPVとEVの関係と似ている感じかもしれません。情報源がタスクとのその見積もり、実際の状況ということで同じものを使用しておりますので、そう思うのも確かでしょう。
本記事ではEVMのPV/EVの関係とCCPMのバッファ管理グラフの比較を考えてみます。

★EVMとCCPMの違い
先にざっくりと言ってしまいますが、CCPMのバッファ管理グラフはクリティカルチェーン部分のみを着目しますが、EVM(PV/EVの関係)では全体のタスクの進捗で管理をする点が異なります。

※CCPMのバッファ管理グラフ
CCPM的な見え方
※クリックで拡大。

※EVM(PV/EVの関係)
EVM的な見え方
※クリックで拡大。

そのため、全体としての進捗が厳しい状況はEVM(PV/EVの関係)では分かりますが、CCPMのバッファ管理グラフのように残り日数や問題の優先順位を判断できる状況とはなりません。
クリティカルパス/クリティカルチェーンが遅れていても、EVM(PV/EVの関係)では他の作業で進捗をカバーできる/コッソリと問題を隠しつつ進捗しちゃうんですね…
EVM的なコッソリな見え方
※クリックで拡大。

ただ、複数の作業が並列している場合などに「全体としてどうか?」という点についてはEVM(PV/EVの関係)の方が一目で分かります。


★シミュレーションで見え方の違い
まあ、クリティカルチェーンのみをEVM(PV/EVの関係)で示した場合には、ほぼCCPMと同じ情報がEVM(PV/EVの関係)で示されるはずです。
こちらの情報を使って管理する…ということも出来ますね。
簡単に違いをシミュレーションしてみましょう。

※クリティカルチェーンのみのEVM(PV/EVの関係)での進捗 VS CCPMのバッファ管理グラフでの進捗
同一のモノの見え方
※クリックで拡大。

こちらに関しては、読み方を知っていれば双方とも同等の効果が出すことが出来そうです。
ただ、CCPMのバッファ管理グラフの方がシンプルに遅れの発生状況を判断できるかもしれませんね。


■タスクのサイズはどのくらいにするか?

さて、CCPMに限りませんが「個々のタスクをどのくらいのサイズにするか?」ということは議論になることが多いです。
今回は「CCPMを行うに当たって」のタスクサイズに対して、筆者の今までの経験からコメントをしておきます。

以前の記事では以下のような記載を行っています。
(実践編)計画を作成する Д織好出し+依存関係整理
「■(参考)タスクの粒度について」に記載しております。

大まかに考えると、定例的にモニタする周期とタスクサイズを考えると良いと考えております。

★定例のモニタ周期とタスクのサイズ(毎日確認の場合)
 進捗モニタ周期:毎日(朝会想定)
 規模…人数:4〜5人以内、CCPM管理の期間:2か月程度
 
 1つのタスク粒度:半日〜3日(最大5日)の規模にする

また、毎週確認する前提であれば、以下のようなサイズが良いのではないでしょうか。
WBSの8/80ルールに従ったような形式になります。

★定例のモニタ周期とタスクのサイズ(毎週確認の場合)
 進捗モニタ周期:毎週(週の定例を想定)
 規模…人数:4〜6人以上、CCPM管理の期間:半年〜1年程度?
 
 1つのタスク粒度:1日〜2週間程度の規模にする。

この理由を少しだけ考えてみましょう。
定例で変化が確認できないほど小さい進捗の場合には、問題を確認しづらいです。
例えば、1ヶ月のタスクを毎日確認しても、毎日の進捗は5%程度です。これでは問題が発生しているかどうかも分かりません。
毎日確認するときには?
※クリックで拡大。

上の図のケースでは、90%以降の進捗で停滞する…といったよくプロジェクトでみられる傾向も発生しそうです。
この傾向は「タスクを分解できていない」ことにも起因しますが…

逆に、定例の間にものすごい数が進められても(個々の確認が出来る点は良いですが)1回の進捗会議も長くなりますし、難しいのではないでしょうか。
極端ですが、毎週の定例で1時間くらいのタスクまで確認していると、1人のタスク確認は20個、40個に及んでしまいます。
また、1つが大きく遅れた場合には、1週間の周期では影響が大きな遅れになっている可能性も有ります。
この際、プロジェクト期間が半年であれば1週間の遅れは5%程度の影響ですが、プロジェクト期間が1か月であれば1週間分の遅れの影響は20%〜25%にも及んでしまいます。
毎週確認するときには?
※クリックで拡大。

適切なタスクの量としては、(定例進捗会議などの)モニタ周期の半分〜3倍程度までの範囲、また、全体のプロジェクト期間の2〜5%程度の周期でモニタ出来ると、遅れた場合の影響も小さく出来るのではないでしょうか。
定例のモニタ周期で一人のタスクが毎回1つ〜3つ程度終了、もしくは1つのタスク進捗が30〜50%程度進むといった状況であれば、確認もやりやすく、遅れが発生した場合の影響もそれほど大きくならない、ということが言えます。

モニタ周期で進捗が明確であり、定例1回分の期間遅れが全体プロジェクト期間でカバーできる程度の大きさが良いのではないでしょうか。

なお、個人のタスクに関しては、各個人が毎日確認すると良いと思いますので、「毎日のモニタ周期」のタスクサイズが推奨ですね。


■見積りは正確である必要はあるか?

以下の記事で説明したように、CCPMは攻めた見積りを行い、全体バッファでカバーします。

(原理編)CCPMが解決する対象問題の関連性と解決方針
「■CCPMによる解決方針」に記載しております。

この方法で進めた場合、見積りが大きくずれることが多数発生するよりも、見積りを正確にした方が良いのではないか?とも考えられます。
つまり、バッファ消費はする前提としても、平均的に同じ割合で遅れるくらいに見積りが出来た方が良いという意見ですね。

実際に、見積りを正確にするとどうなるでしょうか?

過去に「折り紙」でCCPMを行った結果のグラフを2つ紹介します。
1つは、5種類の折り紙の見積りを全て2分にしたもの。もう1つは折り紙の見積りそれぞれに差をつけて、見積りをより正確に表現したものです。
なお、折り紙は5種類分ですが合計時間は「10分」で統一しています。
見積りの正確さとグラフの見た目
※クリックで拡大。

CCPMのバッファ管理グラフの違いはどうでしょうか?
多少最大のバッファ消費状況に差があるようにも見えますが、それ程大きく変わらないようです。
毎日の進捗管理に使用する目的であれば、差は全くないとも言えそうです。

どのみち、見積りの不確実性を吸収するための全体バッファの仕組みですので、見積りがずれていたとしてもある程度は吸収できるようです。
このことを考えると、見積りは参照値と考えて「気楽に見積りしてね」ということが言えるかもしれませんね。


今回は結構マニアックな話題について3点アラカルト紹介してみました。
次回は、CCPMを行っている現場における問題を解決して改善していくための典型的なパターンについて紹介します。
| TOC/TOCfE/CCPM | 21:01 | comments(0) | - |









    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ