どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし2-10(原理編10):CCPMの手順と問題解決の関連性
CCPMのおはなしシリーズです。
これでようやく原理編の最後です。前回までに紹介した問題のキーワードをCCPMの手順に割り当ててみましょう。

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

すでにCCPMにおける手順の全体像については「CCPMのおはなし1-2(紹介編2):CCPMの超概要と期待される効果」で紹介しております。
こちらで紹介したCCPMの概要的な手順に少し情報を追加しつつ、原理編で紹介した問題点をどのように解決しているか?をマッピングしながら紹介してみます。


■CCPMの手順全体像と紹介する範囲(前提)

CCOMの手順をざっくりと分割しておきます。(本記事の構成にもなっています。)

1.計画の作り方
2.進捗状況の数値管理(バッファ管理グラフ)の作り方
3.バッファ管理グラフを用いた進捗の判断方法

紹介する手順は、(後で検索して調べやすいように)CCPMの紹介で扱われる専門用語で表現するようにしております。専門用語的な部分は”キーワード”のように””で囲むようにしておきます。
この際、原理編で既に紹介したキーワードについては説明を入れませんので、前回までの記事にて確認ください。

★前提
紹介する範囲ですが、1つのプロジェクト(もしくはその1部分)でCCPMをやる想定の紹介範囲にとどまっております。
組織的・複数のプロジェクトへのCCPMの適用については「CCPMのおはなし2-1(原理編1):原理編の構成と前提」に記載の通り優先しておりませんのでご了承ください。


■1.計画の作り方

個々のタスクが繋がった一連のタスクセットを「計画」と考えます。
ここの説明では、タスクの合流や並列作業は省略します。

CCPMでは、主に以下の点を考慮した計画を行います。

A) タスクに”リソース制約”を考慮
B) タスクに含まれる「”個別バッファ”(安全余裕)」を取り除く
C) ”クリティカルチェーン”に”全体バッファ”を設定する

★A) タスクに”リソース制約”を考慮
タスクを出し、それをつなげた計画を作る場合においてリソースによって影響をうけますので、計画段階でリソースを考慮します。

具体的には以下のような感じです。(例は「カレー作り」です^^)
クリティカルカレー

このようにリソースを考慮した計画を作ります。
上記における「最も長いタスク列」が”クリティカルチェーン”になります。

では、上記例で、今時では無いでしょうが以下の2つの条件が加わるとどうなるでしょう?
・炊飯器で無くコンロでご飯を炊く
・コンロは1つしか存在しない
クリティカルコンロ

さらに一人で作業するのであれば…という”リソース制約”でも”クリティカルチェーン”が変化するはずです。
このように、「”リソース制約”」を考慮した計画を作ります。

<解決できる問題点>
ここでは、「リソース制約を考慮していなかったため予定より遅れる」という問題を解決出来ます。


★B) 「”個別バッファ”(安全余裕)」を取り除く
上記の計画における見積りでは”個別バッファ”(安全余裕)が含まれているとしましょう。
※個々のタスク見積りの時点で取り除く作業が完了済の時も有ります。

この”個別バッファ”を取り除くことが出来るように、思い切って期間を半分に短縮します。カレー作りの計画を短縮できるのかよ!?煮る時間は!?というツッコミは無しでお願いします-_-)b
短縮したクリティカルチェーン
※クリックで拡大

この「半分」の理由としては、”見積りの不確実性”におけるβ分布の統計を考慮してタスクの50%は短い期間で終わると想定し、”Aggressive but Possible(ABP)”という攻めた見積もりにするためです。

<解決できる問題点>
ここでは、”個別バッファ”を取り除くことによって、”学生症候群”を防止します。また、”パーキンソンの法則”からの”早期完了の未報告”によるタスクの遅れの傾向(ギリギリか遅れる傾向)を大きく改善することを狙っています。


★C) ”クリティカルチェーン”に”全体バッファ”を設定する
これで攻めた見積りの”クリティカルチェーン”が作られますが、このチェーンに対して”全体バッファ”を設定します。
この”全体バッファ”は取り除いた個別バッファの部分の時間を活用して割り当てます。
全体バッファは世界を救う

”全体バッファ”は、タスク短縮分をそのまま設定する場合も有れば、その半分しか設定しないような場合も有ります。CCPMで推奨している方法は、”全体バッファ”はタスク短縮分の1/2に設定するというものです。
※つまり、上記例では「20分」に設定します。

日々発生するタスクの遅れは”全体バッファ”を消費しながら吸収して進捗管理を行うという方針です。

<解決できる問題点(+副作用の防止)>
既に”ABP”の攻めた見積もりにしているため、当然個々のタスク完了には遅れが発生します。”全体バッファ”はこの遅れを吸収するために設定します。


■2.進捗状況の数値管理(バッファ管理グラフ)の作り方

計画では”ABP”の攻めた見積りであるため、間に合うこともあるかもしれませんが”マーフィー(想定外)”が発生することも多く、当然遅れる場合も発生します。
マーフィー退治
※クリックで拡大。

CCPMでは「個々のタスクは”ABP”であるため当然遅れが発生する」ものとして遅れ発生の場合には「”全体バッファ”の消費」で対処します。

上記の図では、タスク,詫縦蠶未蟆燭箸完了しておりますが、タスク△巴戮譴発生してしまっています。(タスクはまだ行っていない状況とします)この場合、タスク△巴戮譴進だけ”全体バッファ”を消費するという形式で吸収します。

ここで、横軸:進捗率、縦軸:バッファ消費率というグラフに割り当てます。
結果として、数値管理のグラフ(”バッファ管理グラフ(フィーバーチャート)”が完成します。
バッファ管理グラフへ
※クリックで拡大。

この”バッファ管理グラフ”を用いて進捗の判断を行います。

<解決できる問題点>
作業においては”マーフィー(想定外)”のような事象による遅れは多々発生します。
個々のタスクの遅れは”タスクの従属性”によりプロジェクト全体の遅れに繋がってしまいます。この際、”遅れは許さない進捗管理”のような遅れを責めたてる管理では無く、遅れ状況をバッファの消費という形式にして、プロジェクト全体の問題の優先順位判断に上手に活用しようという狙いがあります。


■3.”バッファ管理グラフ”を用いた進捗の判断方法

さて、2つのプロジェクトにおける”バッファ管理グラフ”の状況と、実際の進捗状況を図にしたものを以下に示します。
どっちがヤバい?
※クリックで拡大。

上記どちらのプロジェクトの問題を解決すべきでしょうか?
・進捗はまだ25%程度
・”全体バッファ”が大量に(80%)消費されている⇒遅れている!

上記の条件である「左側」が明らかに遅れている状況が分かります。そのため、マネージャは左側のプロジェクトの問題を優先的に支援して解決します。
このように、進捗管理から問題解決対象プロジェクトの優先順位づけに役立てることが出来ます。

<解決できる問題点>
”全体バッファ”の消費状況というシンプルな判断で問題の優先順位判断が出来るようになります。そのため、目先や気になる問題を優先して全体的な進捗に影響の小さい(相対的に役に立たない)活動が減るようになります。


★(参考)バッファ管理グラフの比較
バッファ管理グラフは簡単に言うと「グラフの上の方に行くほどヤバい」と判断出来るですが、開始タイミングや期間が異なる複数のバッファ管理グラフの比較方法についても軽く紹介しておきます。

下記図には黄色ラインと赤色のラインを引いていますが、これがプロジェクトとしての「ヤバい」「マジヤバい」範囲となります。※表現は適当^^
ヤバい、マジヤバい
※クリックで拡大

少なくとも黄色ラインに達していないようなプロジェクトは「相対的に余裕がある」とみることも出来ますので、「マネージメントの介在(問題解決の手助け)はしない」、「他のチームが困っている場合に手伝って貰う」という判断が出来るようになります。

なお、ラインはCCPMの推奨では以下のように聞いたことががあります。
・黄色ライン:15%〜70%
・赤色ライン:30%〜85%
ラインの範囲

ただ、調べてみるとこのラインの引き方は様々存在しているようです。また、組織的に標準化するような状況でもない限り、それ程気にする必要はないと思います。
数値化が進むと黄色と赤のライン内に上手く入るようにリソース・活動のコントロールが出来るようになるらしいですが、この記事ではそこまでの活動については触れません…
こんな感じ?


■(参考)問題の解決方法(組織的な構成)

問題の解決は、以下のように対処が出来るほど効果が増します。
・個人で解決できない/時間のかかる問題はチーム全体で解決
・チームで解決できない/時間のかかる問題は組織全体で解決

この対応には組織的な理解や活動が必要となります。
※関連する範囲のプロジェクトが全てCCPMのバッファ管理を行っているなどが無いと、客観的な判断に繋がらないため。

過去に、組織的な構造、コミュニケーションの仕組みとして問題を解決出来る仕組みを構築したという内容を聞いたことがあります。(こちらのリンク

以下のような組織構造ですね。
問題を組織で解決
※クリックで拡大。


■まとめ:手順概要をCCPMの用語で説明

まとめ的にCCPMの用語を用いて手順を説明してみます。
今までの原理編を読んでいないと「何これ?」となるかもしれませんね…

・計画の時点で”リソース制約”を考慮して”クリティカルチェーン”を決定します。
・”クリティカルチェーン”に対して”全体バッファ”で遅れを吸収しながら進捗確認が出来るようにします。
・プロジェクト進捗とバッファ消費量をグラフ化した”バッファ管理グラフ(フィーバーチャート)”を用いて進捗管理を行います。
・”バッファ管理グラフ”で遅れを検知した時点で、優先的に解決する問題が発生したという判断をして対策を実施します。


■(参考)CCPMは実際はもっと広い範囲で対策をしております

この記事の最初の「前提」でも記載しておりますが、紹介したCCPM手順は一部の狭い部分のみを紹介しております。少しだけより全体的な部分について触れておきます。
個人的な解釈では、CCPMは3つの階層で整理が出来ます。
3階層のCCPM
※クリックで拡大

★組織的なCCPM
実際には、組織的に同時に実施するプロジェクトを(最速で処理できる量まで)数を減らして、バッドマルチタスクを減らすような対処を行います。また、組織的なリソース(組織のスキルセット)を考慮した対策を実施するなどを行います。
他にも、チームで解決が困難な問題を組織で解決できるような組織構造を作るといったことも対象になります。
※本記事に「★(参考)問題の解決方法(組織的な構成)」という部分で記述している内容が対象なります。


★プロジェクトのCCPM
この部分が記事での紹介の中心となります。なので、ここでの説明は省略。
個々のプロジェクトに対してクリティカルチェーンの計画を行い、バッファ管理グラフを用いて問題の優先順位判断のもとで活動を行います。


★現場でのCCPM運用
定期的な進捗確認と現場における対策の実施となります。現場での運用方法もポイントがいくつかある状況です。
朝会での進捗確認、割込みが入らないタスク監視・制御の仕組み等が対象です。
この辺に関しても具体的な紹介は行いませんが、現場の活動はソフトウェア開発のアジャイル手法の1つである「スクラム」に近い進め方を推奨します。
※スクラムの参考(リンク)



以上でCCPMの手順と解決する問題の関連性についての紹介(及びいくつかの参考の紹介)を終了します。

・・・
これで10回に渡りました原理編が終わりとなります。
最低限、原理編で紹介したキーワードを用いた会話が出来るようになりますと、書籍を読んだり、何らかのイベントに参加した場合に理解が速くなるはずです。

次は実際にCCPMを行う手順を紹介する「実践編」となります。
| TOC/TOCfE/CCPM | 17:00 | comments(0) | - |









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