東京目黒の雅叙園で開催された「Microsoft Office Project Conference 2007」についてのご報告、および、感じたこと

ここで、我がTOCコミュニティを代表して、(株)ロゴの酒井昌昭副社長が、「PM（プロジェクト管理）はTOCで進化する」というテーマで講演されました。まさに、我が意を得たり、でした。

昨日（2007年2月27日）、マイクロソフト主催、PMI東京支部、MPUF共催の、日本で初めという東京目黒の雅叙園で開催された「Microsoft Office Project Conference 2007」に参加しました。主催者側のお話では、当初の目標よりも大きい、900名に及ぶ「プロジェクト管理」のお仕事に携わる専門家、実務者の方々の参加があったとのことで、大変、盛会でした。

そこで、PMI東京支部長の瀬尾恵氏が基調講演をされましたが、同氏のお話では、最近では、日本国のGDPの25%が、「プロジェクト型」の経済活動で創出されているとのことです。初めて、このような統計数字を聞きましたが、この数字は、大変、興味深いものです。

同氏が講演にお使いになった資料によりますと、経済活動のこのような動きを反映してか、PMPの資格取得者数も、2001年12月の2,000名足らずから2006年12月の約18,000名に、毎年、40%から80%の勢いで急増しているとのことです。そして、これらのPMPの75%がIT関連の業務に就かれているとのことです。また、PMI東京支部の会員数も、2002年5月の500名足らずから、2007年1月には2,600名に急増してきているとお話されていました。また、PMP資格取得者は、首都圏6,380名、関西549名、名古屋圏251名で、首都圏に85%が集中しているとお話されていました。そして、先進的な大きな会社では、300名とか500名とかいうオーダーのPMP資格保有者を保持するようになってきているとのことでした。
また、PMI東京支部ステークホールダー委員会報告書によると、スポンサー企業の関心のあるテーマの上位五つは、「PMP育成」、「PMO (Project Management Office) の設置｝、「PMBOK」、「CMMI (SEI [Software Engineering Institute]　のCapability Maturity Model Integration」、および、「PM Competency」とのことです。（注：CMMIについては、http://www.sei.cmu.edu/cmmi/translations/japanese/models/を参照。簡単に述べると、SEIは、下記のように、IT組織の成熟度を5つのレベルに区分けし、適切に行えるべきIT関連のプロセス領域を、それぞれのレベルに対応させています。5つのレベルは、Initial、Repeatable、Defined、Managed、Optimizingです。「Initialレベル：Level 1」では、ものごとは、場当たり的（Ad hoc）なプロセスで行われています。このモデルでは、18のプロセス領域が定義されており、成熟度が一番高いレベル5では、これらの18のプロセス領域のすべてが適切に行えなければなりません。）。

PMOの設置状況は、「PMO部門設置済み：48%」、「必要であるが時期は未定：23%」、「必要性は当面なし：15%」、「一年以内に予定：4%」とのことでした。

しかし、現実は厳しく、PMOが行っている、現在、一番、緊急度の高い仕事は「プロジェクト状況の把握、および、火消し」とのことです。

そこで、PMPの資格試験の出題範囲は、どのようなものであるかを調べてみました。http://www.pmi-tokyo.org/02/000200.htmlによると、以下のようなものです。

1.　"A Guide to Project Management Body of Knowledge 3rd Edition"（PMBOK第3版）が試験の資料として使われます。

2.　PMBOKガイドの内容に加えて、多様なプロジェクトマネジメント業務を対象とした問題が出題されます。

ところで、谷島宣之氏（日経ビズテック日経ビジネス日経コンピュータ編集委員）のインタビューに答えて、瀬尾惠会長は、「PMBOKの知識はプロジェクトを成功させるための必要条件ではあるが十分条件ではない」という答をなさっておられます。つまり、『成功するプロジェクトマネジャーはコミュニケーションに80％の時間を費やさないといけない。しかし、PMBOKを学んでこの知識を仕入れた人が直ちに「コミュニケーションができるか？」と問われると、必ずしも、イエスとはならない。プロジェクトにおけるコミニュニケーション・マネジメントの重要性を認識することはプロジェクト成功の必須条件ではあるが、認識しているだけではだめで、実行をともなう必要がある。つまりPMBOKの知識だけでは十分ではない』ということ、また、『「プロジェクトを継続的に成功裡に実施していくためには、PMBOKに代表されるPMの知識に加えて、プロジェクトマネジャー個人のコンピテンシーやプロジェクトを支える組織（会社）の仕組みつくりが必要」という。このためPMIはPMBOKに加え、「プロジェクトマネジャー能力開発フレームワーク」、「組織的プロジェクマネジメント成熟度モデル (CMMI)」といった新分野の標準を発表している」』とのことです。（出所：http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20050521/161280/）

雅叙園のMicrosoft Office Project Conference 2007では、我がTOCコミュニティを代表して、(株)ロゴの酒井昌昭副社長が、「PM（プロジェクト管理）はTOCで進化する」というテーマで講演されました。同氏は、Microsoft Office Project のユーザの勉強会MPUF（Microsoft Project User Forum）のTOC-PM研究会主幹事です。この研究会には、200名を越えるメンバーがおり、プロジェクト管理とCCPM日本語版PMBOKガイド第3版、グロッサリー（361ページ）に記載の「クリティカルチェーン法」の定義を引用されてお話されました。同氏は、PMBOKでのクリティカルチェーンの定義、すなわち、「クリティカルチェーン法：制約のある資源を考慮してプロジェクトスケジュールを修正するスケジュールネットワーク分析技法。クリティカルチェーン法は、スケジュールのネットワーク分析に決定論的アプローチと確率論的アプローチを組み合わせた方法である」ということが書かれていることを紹介し、TOC、クリティカルチェーンにより、「PMはTOCで進化する」ということを説明されていました。小生も、まったく、同感で、会場で、内心、拍手を送っていました。

PMBOKの、上のCCPMの定義は難解で、判りづらいと酒井さんも述べておられました。多分、このままでは、誰もわからないと思います｡ 特に、「クリティカルチェーン法は、スケジュールのネットワーク分析に決定論的アプローチと確率論的アプローチを組み合わせた方法である」というところです。そこで、Larry Leachに質問してみました。ラリーの返事は、以下の通りでした。

「最初に言っておくけど、私は、この定義に同意していないよ。（クリティカルチェーンはともかく）少なくとも、CCPMについては!!　私は、もっと、ホリスティック名な定義を行なうように勧めたのだけど、彼らは、聞き入れない。決定論的と確率論的は正反対のも。この定義では、タスク期間の推定値を一つの数字で行なえると仮定して、これらの推定値を「一番長いチェーン」に沿って合計すると、全体的なプロジェクト期間が得られるとしている。これは、変動性を無視している」と書いてきました。続いて、「この定義は、読む人を混乱させる。私が、特に気にしているのは、CCPMが、ネットワーク分析ではなく、プロジェクトの実行の際の人々の行動についてのものなのに、そうは定義されていないことだ。勿論、適切なネットワークがインプットとして必要名ことは当然だけど」。さらに、「クリティカルチェーンは、変動性の存在を明確に認識して開発されている。そして、この変動性にバッファで対応する。しかし、クリティカルチェーンでも、タスク期間、バッチサイズに単一の推定値を使っている。他方、モンテカルロ法やPERTでは、三つのタスク期間推定値（もしくは、分布）を使っている。こうして、クリティカルチェーンのスケジュールは、「みたところ」決定論的な方法と同じように見えるので、『クリティカルチェーン法は、スケジュールのネットワーク分析に決定論的アプローチと確率論的アプローチを組み合わせた方法である』という定義がされたのだと思う」と書いてきました。

弊社（MSI）は、このコンファレンスでブースを出し、ラリー・リーチが開発したCCPMのソリューション、「CCPM+」を出展しました。大変、好評で、マイクロソフトの方が、「予想以上に、MSI様のブースが盛況だったのには、正直びっくり致しました。やっと、CCPMも浸透してきたように思います。最後のMPUFのCCPMのセッション（注：酒井氏のセッション）も満席のようでした（原文のまま）」というメールを頂戴しました。
反面、このコンファレンスでびっくりしたことは、アンケートによると、PMの専門家、実務者の中で、クリティカルチェーンを知っている人が少ない、ということです。弊社のブースに来られた方々は、二つに分かれていたようです。つまり、方や、CCPM（および、CCPM+）を熟知されておられる方々、そして、クリティカルチェーンという本すら読んだことのない、「頭の良い方々」でした。しかし、我々の説明で、流石と思われるほど、呑み込みが早く、多くの方がポイントを即座に把握されました。

この会場で、CCPMの宣伝を、と思い、ラリー・リーチの下記資料も配布しました（ご参考）。

ラリー・リーチの文献を読むと、彼は、一般に、CCPM で得られる利点として下記のことを挙げています。これらは、プロジェクト管理の伝統的な考え方、方法論では、実現できないことです。

• プロジェクトが、常に、スケジュール内に完成する
• プロジェクトで実現しようとしたことが、すべて、実現できる
• プロジェクトの費用が、予算内に納まる
• 市場での優位性が得られ、事業が成長できる

• 前に行った類似プロジェクトに較べ、プロジェクト期間が、すくなくとも半減する
• 個々のプロジェクト計画は、少なくとも、25％は短縮する
• 並行的に行われる複数プロジェクトのプロジェクト期間が、大幅に短縮する
• プロジェクトでの変更が少なくなる
• 業務改善プロジェクトで実現しようとする改善の時期が早まる
• 投資のペイバック期間が短縮する

• マルチタスキングから生まれる混乱が少なくなる
• インプリメンテーション時点で、一つのタスクに集中できるようになる
• 変更が少なくなる
• やり直しが少なくなる
• 複数のプロジェクトを担当するマネジャーのストレスが小さくなる
• 「期日遵守」を前提としたタスク管理によるプレッシャーが除去される
• タスクを実際に行う人たちは、バッファレポートを参照することで、自分の担当のタスクの優先順位を決められる
• 高い優先順位を持つタスクが、突然、飛び込んでくることが少なくなる

• ステータスが、素早く、容易に判る
• リアルタイムでプロジェクトステータスが判るので、レポートを待つ必要がない
• ステータスがリアルタイムで判るので、バッファ、チェーン、タスク別に、どこに注意を向けるべきかが即座に判る
• バッファレポートにより、適切な意思決定が行える
• プロジェクト開始のパイプライニングについての意思決定が行える

• プロジェクトマネジャーは、何処に注意を向けたらよいかが容易に行える（早すぎるタスク着手が減る）
• プロジェクト計画作成が単純化されるので、ペーパーワークが少なくなる
• プロジェクトステータスの報告が単純化する
• ステータスの把握により、その時点で、計画を作成すればよいのか、それとも、アクションを起こさなければならないのかが意思決定できる
• ステータスの把握により、どのタスクに、優先的に資源を割り当てたらよいのかが判る

• 資源についての争いが減る
• 同一の資源量で、より多くのプロジェクトが、より早く完了する
• 足りなくなってしまった資源の追加が減る
• 資源に起因する遅延が減少する
• プロジェクトのキャッシュフローが改善する
• ROI が改善する

2007年2月28日
(小林英三記)