クリスマスまで「あと何日」とかお正月まで「あと何日」といった表記が増えてきた今日この頃ですが、もう年の瀬を迎える時期になりましたね。
年末年始にプロジェクトの納期やカットオーバーなど迎える皆さんもお正月も無事に迎えられそうですか?私もTOC/CCPMを実践しているおかげで無事に年越しできそうです(笑)
さて、前回のコラムで紹介した「安全余裕」について覚えていただいていますでしょうか?
少しおさらいしますとHPからABPをマイナスした日数が安全余裕になりますので、その余裕をそれぞれのタスクに設けずに一か所に集めてプロジェクトの安全余裕にするという考え方です。細かい事は第4回のコラムをご覧いただければと思います。
今回はこの集約させた「プロジェクトの安全余裕」をどうやって管理するかという点についてご紹介いたします。
図のように一か所に集約した「プロジェクトの安全余裕」をどうやって使っていくのか?
これが次なるポイントになってきます。
当然、プロジェクトを進めていく上で上記のような単純な横一列のスケジュールになる事は少ないと思います。もっと複雑な工程表になると思います。そんな時に作業の優先度をどのようにして決定するのかがポイントになると思います。
そこで作業が複数同時進行するようなプロジェクトの場合、「この作業が遅れたら納期に影響を及ぼすだろう」という作業をピックアップする必要があります。
例えば私が東京へ行きセミナーをする事をプロジェクトに例えた場合の工程表を以下のような形になります。
縞模様とブルーのバーがあると思います。
縞模様のバーは電車に乗り、新大阪から新幹線で品川へ移動するような工程です。
ブルーのバーは「読書する 寝る」という工程です。
この二つを比較した場合、決定的に違う事があります。縞模様のバーは短くする事が出来ればこのプロジェクトと全体の工程を縮める事が出来ます。
例えば「新幹線で移動する(新大阪→品川)」というタスクが仮に「リニアモーターカーで移動する」という事が出来るようになっていれば時間短縮できますね。
逆にブルーのバーはいくら早く作業を終えてもプロジェクト全体の工程を縮める事が出来ない工程になります。本をたくさん読んだところでセミナー会場に到着する時刻が早くなる事はございません。セミナー会場へ到着する時間は結局、縞模様の移動時間に依存しています。
このようにプロジェクト全体の納期を決めるタスクのつながりを「クリティカルチェーン」と呼びます。逆にプロジェクトの納期に影響のないタスクの事を「非クリティカルチェーン」と定義します。
プロジェクトを進める上に置いてこの「クリティカルチェーン」に指定されたタスクや作業を優先的に無駄なく実施する事が「プロジェクトの安全余裕」を活用するポイントになります。
その他にも「プロジェクトの安全余裕」を活用する為には進捗確認を実行する事も重要ですが、ここにもちょっとしたコツがございます。
例えば、ある現場でプロジェクトを実行している上司の大柴さんと部下の中川君のお話です。
大柴さん「進捗ミーティング始めます。Mr.中川、ワークの進捗はどう?」
中川君「とりあえず順調です。進捗率は80%までいきました 」
大柴さん「何かProblemはありますか?」
中川君「特にないです」
《翌週》
大柴さん「進捗ミーティング始めます。Mr.中川、ワークの進捗はどう?」
中川君「とりあえず順調です。進捗率は90%までいきました 」
大柴さん「予定ではWeek Endにはfinishしそうですが、何かProblemは?」
中川君「特にないですから大丈夫と思います!」
《そのまた翌週》
大柴さん「進捗ミーティング始めます。Mr.中川、ワークの進捗はどう?」
中川君「ちょっと不明点が出て作業効率が上がりませんでした。進捗率は91%です 」
大柴さん「Oh!No!・・・」
結局、進捗率で報告していた中川君は90%までは順調に報告していましたが、それでは少々問題の発見が遅れるようです。ここで大切になってくるのが「進捗率報告」ではなく「あと何日報告」の重要性です。「あと何日報告」を実施する事で、「残日数」という基準が納期に対して間に合うか間に合わないかという点でリーダーもメンバーも共通認識する事が出来るのです。
冒頭でもふれていますが、「今年の消化日数が何日だから2009年消化率は○%です」って答えるより「お正月まであと何日」って答える方が分かりやすいでしょ(笑)
という事で進捗会議では、「あと何日報告」を実施するだけでOKです。その上でクリティカルチェーン上にある作業に対しての遅れを管理すると「プロジェクトの安全余裕」が活用できます。
言葉では分かりにくいので図をご覧ください。
現在日を示す青い▼があると思いますが、その時点で作業着手しているタスクの「あと何日か(残日数)」を入力します。早く作業が終わった場合はスケジュールが前倒しになり、遅れた場合はプロジェクトの後ろに設定している「プロジェクトの安全余裕(プロジェクトバッファ)」が吸収してくれます。その後、進捗を重ね続けて「プロジェクトの安全余裕」の残り具合を観察しましょう。当然、安全余裕が増減するのでその点に注目する事が重要です。
今回は「安全余裕が十分ある時(問題なし)」を「緑」、「安全余裕が減りつつある時(警告)」を「黄色」、「このままだと早期に安全余裕を使い切る可能性が高い時(危険)」を「赤」で表現しています。
作業が遅れて後ろの作業に影響があった場合、このようにリスケジューリングしていき「プロジェクトの安全余裕」が黄色の警告状態になります。このような状態になってもあわてては駄目です。
現在実行中の作業は「BBB」のタスクですが、このタスクに対して何か処置を行うのではなく、オレンジの点線で囲った部分で対応する準備をしておく方がいいでしょう。現在実行中の作業にメスを入れることは現場の混乱を招きかねますからね。
そんでもってもっと作業が遅れたらこんな感じになっちゃいます。
どんどんクリティカルチェーン上の作業がリスケされているのがお分かり頂けると思います。その結果、「プロジェクトの安全余裕」が減少して赤色になってしまいます。こうなったら大体現場はパニック状態になると思うのですが、ここで落ち着いて前回の黄色バッファになった時に考えて置いた対策案を速やかに実行するだけでOKです。この時は実行中の作業であっても現場の混乱を招かぬように気をつけながら対策を実行する必要があります。
「プロジェクトの安全余裕」を配置してそれを有効活用する事で、現在のプロジェクト状況を確認する事ができます。だから各自がそれぞれ「安全余裕」を持たずに「プロジェクトの安全余裕」にする事で、TOC/CCPM的な考え方の管理手法ができ成功への近道となるでしょう。
如何でしたでしょうか?ここまで5回のコラムをしっかりお読みいただけた皆様はTOC/CCPMをご理解いただけていると思います。是非とも少しでも今の職場やプロジェクトで「TOC/CCPMのような考え方もあるんだよ」と紹介していただけるとありがたいです。
最後に今までのコラムトピックに振り返りたいと思います。
1回目は「何を、何に、どうやって変えるのか?」
https://www.it-innovation.co.jp/2009/10/27-123819/
2回目は「ゴールの設定方法 ODSC」
https://www.it-innovation.co.jp/2009/11/08-131742/
3回目は「バックワードスケジューリング 段取り八分」
https://www.it-innovation.co.jp/2009/11/24-134231/
4回目は「安全余裕の持ち方」
https://www.it-innovation.co.jp/2009/12/06-140607/
5回目は「安全余裕の活用方法と進捗確認方法」
まだまだお伝え足らない部分も沢山ありますが、基本的な部分はご紹介できたと思っております。もし、TOC/CCPMについてもっと詳しい話が聞きたいとか、本格的に導入してみたいとお考えの方がいらっしゃればお気軽にお問い合わせいただければ幸いです。
短い間でしたが「サルでもわかるTOC/CCPM」にお付き合いいだたきありがとうございました。
また、お会いできる日がございましたらよろしくお願いいたします。
-以上-