第11回 クリティカルチェーン・プロジェクトマネジメント その1(2007.11.30)
前回までは、PMBOK(R)のリソース・マネジメントをMicrosoft Office Project(以後MS Projectと呼ぶ)を使用してどのようにマネジメントできるのかということについてお話ししましたが、今回からは、クリティカルチェーン・プロジェクトマネジメント(CCPM)についてお話ししたいと思います。
クリティカルチェーンとは、制約理論の中の一つです。
制約理論とは、経営管理手法の一つで、特に制約に注目することで、経営革新を可能にするものです。
クリティカルチェーンとは、要員の競合があり、要員人は一度に一つの作業しかできないという条件を考慮した作業連鎖で最も長いものがプロジェクトの制約条件になります。この制約をクリティカルチェーンと言います。
今回は、第一弾として、以下のような内容についてお話ししたいと思います。
・ プロジェクトの不確実性
・ 作業時間見積もり
・ 作業が遅れる理由
尚、弊社と協業しております、MSI株式会社監訳本 『リーンプロジェクトマネジメト』が10月に発売されました。
本書は、リーン、クリティカルチェーン、PMBOK Guide(R)を統合した、プロジェクトマネジメントのバイブル − CCPM(クリティカルチェーンによるプロジェクトマネジメント)の名づけ親が著した実務者のための『プロジェクトマネジメントのバイブル』です。こちらも併せて是非お読み下さい!
■プロジェクトの不確実性
プロジェクトは不確実なことばかりです。
例えば、
・ 仕事の要求事項は仕事が実際に行われるまでは完全にはわからない。
・ プロジェクト・メンバーの能力と士気は大きく差がある。
・ 顧客による仕様変更や仕様追加がある。
・ 一つ一つの作業が実際にはどれだけ時間がかかるのかはやってみないとわからない。だから、プロジェクトの完了にどれだけの期間が必要なのかがわからない。
・ どこに、どれだけのゆとりが必要なのか分からない。
ところで、不確実性とは、どういうことでしょうか?
不確実性とは、不明確で、あいまいで、起こるかどうかも定かではない、解決が難しい、そして、定まったものではない、という意味になります。
不確実性と変動性とは違います。
変動性とは、同一のプロセスを反復して適用した時に得られる異なった結果のことをいいます。
例えば、毎日同じ通勤経路を使用していても、家から会社までの通勤時間は日によって違います。しかしながら、毎日の経験上、その違いはある程度予測できます。
よって、このような統計的な変動は、余裕(バッファ)を設けることで対処することができます。例えば、今日は雨が降っているのでバスが遅れる可能性が高いので、15分早めに家を出ようとか。
一方、不確実性とは、特別な原因による変動で、その度合いが予見の範囲を超えた時のことをいいます。
例えば、朝、子供が高熱を出したので病院へ連れていかなければならなくなったため、午前中半休を取らなければならなくなってしまったということです。
このような不確実なことへの対処としては、リスク・マネジメントで対応する方法があります。PMBOK(R)では、リスクを識別し、リスクの優先順位を決定し、優先順位に従った対応策を策定し、監視・コントロールを行うというプロセスでリスクをマネジメントしていきます。
プロジェクトは、独自のプロダクト、サービス、所産を創出する活動なので、不確実事項が多々あります。
では、そんな不確実性の高いプロジェクトの作業時間はどのように見積もればいいのでしょうか?
■作業時間見積もり
皆さんはプロジェクトの作業の時間はどのように見積もっているでしょうか?
一番多いのは、過去の類似した経験を基に、今回のプロジェクトの様々な条件を考慮しながら作業時間を見積もると思います。
しかしながら、不確実性の高い作業の時間見積もりを行う場合、以下のような傾向がありませんか?
・ 悲観的に見積もりがち
・ 80%〜90%の確率で納期通りに完了するように充分な余裕を持って見積もりがち
よって、不確実性の高い作業の時間見積もりは、50%の確率で納期通りに完了するような強気の見積もりはしないので、結果として、作業時間が2倍の見積もりになってしまします。
では、なぜ、余裕を持って見積もるのでしょうか?
その理由は例えば、以下のような理由が挙げられます。
・ 仕様変更などによって手戻りが発生するかもしれない。
・ プロジェクトの開始が遅れるかもしれない。
・ プロジェクトの作業が遅れるかもしれない。
・ 計画が実現的でないかもしれない。
・ 期待したスキルに技術者を調達することができないかもしれない。
どれも、プロジェクトの不確実性に起因しています。
つまり、不確実性の多いプロジェクトでは、その不確実性に対応するために、作業時間は充分な余裕を持った見積もりになってしまうのです。
でも、余裕を持った作業時間の見積もりをしているにも関わらず、プロジェクトは遅れてしまいます。なぜでしょうか?
■作業が遅れる理由
プロジェクトの作業が遅れてしまう理由は、作業時間見積もりの際に設けた余裕時間を無駄にしているからです。
そのメカニズムとして、以下の5つが挙げられます。
・ 学生症候群
・ パーキンソンの法則
・ マルチタスク
・ 要員の従属関係にあるタスク
●学生症候群
試験勉強のために充分な期間があっても、それを有意義に使って試験勉強する学生より、試験間近になってあたふたと試験勉強を始める学生のほうが多いですよね?私も後者の学生でした。
それと同じように、余裕期間があると、余裕があるからと、ぎりぎりまで他の作業を行い、結局開始が遅くなってしまい、作業が遅れてしまう場合があるということです。
そして、急いでいる時に限って問題が発生するように、計画の80%進行時点で問題が発生してしまうことが多いのです。そのことによって更に作業は遅れてしまいます
●パーキンソンの法則
仕事は予定工数を全て使い切るように拡大するという法則があります。
早く終わりそうになると、手直しを行ったりして、納期まで仕事を抱えています。
なぜなら、従来のプロジェクト管理では、遅れないように圧力をかけるけれど、早く終わるようには圧力をかけられないからです。
また、納期より早く終わっても、ほめられることはありません。
●マルチタスク
ほとんどの場合、一つのプロジェクトや作業にだけ没頭していればよいということはなく、皆、同時期に行わなければならない作業をいくつも抱えています。
例えば、メールのチェックや返信ですが、これを何か作業をしている間に、度々する人より、1日で時間を決めて集中して行う人のほうが、効率的に作業をこなすことができます。
これは、あれもこれもと並行して作業を行うより、一つ一つの作業は集中して作業して片付けたほうが効率的だということです。というのは、他の作業を行うためには頭を切り替えなければいけないからです。あれもこれもと並行して作業を行うと、その切り替え時間分、時間を無駄にしているということになるのです。
●要員の従属関係にあるタスク
作業は人が行うものなので、作業を行う「人」に大きく依存しています。
例えば、BとEは同じ人で行われるとします。
もし、Bが遅れると、Dだけでなく、Eも遅れてしまいます。
逆に、Bが早く作業を完了しても、Cが完了するまでEを開始することができません。
一つのプロジェクト内でもこのようなことがあるように、同時進行している複数のプロジェクト間でも同様のことが多々起こっているのです。
よって、プロジェクトの作業というのは、単なる作業の依存関係だけでなく、その作業を行う「人」にも大きく依存しているのです。
クリティカル・パスでは、この点が無視され、単なる作業の依存関係だけでプロジェクト・スケジュールを作成しているので、「人」に関する不確実性に対応するための充分な余裕期間が必要だったのです。
上記のようなメカニズムより、充分な余裕を持って作業時間を見積もったとしても、その余裕時間が適切に使用されていないため、プロジェクトは遅れてしまうのです。
では、これは、どのようにしたら解決するのでしょうか?
解決方法としては、余裕時間を一つ一つの作業(担当者)に持たせるのではなく、プロジェクトで共有し、それをプロジェクト・マネジャーが管理するということです。
次回は、それを実現する、クリティカルチェーン技法についてお話しします。
◆プロジェクト計画書作成のセミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆プロジェクト計画書の作り方・書き方・活かし方 (7PDU's)
日時・場所:【Zoom】2025年 01月 15日(水)9:30-17:30(9:20入室可)
【Zoomハーフ】2024年 11月 13日(水)13:00-17:00+3時間
【Zoomナイト】2024年 12月11日(水)13日(金) 19:00-21:00+3時間
※Zoomによるオンライン開催です
※ナイトセミナーは、2日間です
※ハーフセミナー、ナイトセミナーは、事前学習が3時間あります。
※少人数、双方向にて、演習、ディスカッションを行います
講師:鈴木道代(プロジェクトマネジメントオフィス、PMP、PMS)
詳細・お申込 https://pmstyle.biz/smn/plan20.htm
主催 プロジェクトマネジメントオフィス、PMAJ共催
※Youtube関連動画 プロジェクトマネジメント基礎(1) プロジェクトマネジメント基礎(2)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
1.プロジェクト計画書作成プロセス
2.プロジェクト計画をデザインする
3.プロジェクト計画の骨組みを決める
4.プロジェクト活動計画書の書き方
5.予算計画書の書き方
6.リスク計画書の書き方
7.ステークホルダー計画書の書き方
8.コミュニケーション計画書の書き方
9.プロジェクト計画全体の整合と各計画書の調整
10.プロジェクト計画書の使い方と段階的詳細化
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
著者紹介
岡野 智加 アイ・ツー・マネジメント 代表取締役
大手ISベンダーなどにてOracleをはじめとするソフト・トレーニングの講師経験を経て、現在、Microsoft Office Projectセミナーに特化した教育事業経営を行っている。
1998年に日本初の、プロジェクトマネジメントの世界標準であるPMBOKTM(Project Management Body of Knowledge)に準拠したMicrosoft
Office Projectセミナープログラムを独自開発。これまでの単なる操作方法を習得するセミナーではなく、プロジェクトマネジメントプロセスに従ったMicrosoft
Office Projectの実践的活用ノウハウが習得できるセミナーを開発。
開発当初からこの今までに無い実践的な内容のセミナーは、当時、プロジェクトマネジメントをいち早く導入しようとしていた日本の最大手企業から高い評価を得る。
マイクロソフト社からも評価され、、2002年には日本初の米国マイクロソフト社公認Microsoft Office Project Official Partnerに認定される。
2002年に出版した書籍は、これまでの単なる操作方法を解説する書籍ではなく、プロジェクトマネジメントのプロセスに従ったMicrosoft Office Projectの活用方法が解説されているということで、大ベストセラーとなり、売れ続けており、その後の書籍及び日本中のセミナー企業へ多大なる影響を与える等、Microsoft Office Project講師として日本におけるリーディングパーソンである。
メルマガ紹介
本連載は終了していますが、PM養成マガジン購読にて、最新の関連記事を読むことができます。