「私たちのP2M (Project & Program Management)」とは何か、考えてみませんか

第1回：あなたはPMを誤解していませんか？
（時代の先端を行く、IT業界のみなさん、是非読んでください）

さて、読者の皆さんに早速質問をしてみます。

質問1．	プロジェクトの成果とは何ですか？

あなたはITプロジェクトで考えてください。 この簡単な質問に多くの答えが返ってきます。日本情報システム・ユーザー協会の資料から読み取りますと、最も多いのが「工期が守られた」、「予算が守られた」、「品質が良かった」となっています。ベンダーが評価するのであれば良くわかります。しかしユーザーが発注したITプロジェクトの成果が上記ではおかしいですね。 では質問を続けます。

質問2．	プロジェクトの成果物とは何ですか？

ここではさすがに納期や予算を成果物という人はありません。成果物はシステムです。

質問3．	システムの機能、品質とは何ですか？

ここでまた、解答が細かくなってきます。(問題の核心から離れて、視点が細部に移ります。それは関係者の関心がそこにあるからです)

質問4．	ITシステムの導入は投資ですね。投資効果を測定していますか

ここでの答えはみなさん明快です。ITは見えないものを扱っているので、簡単に成果を評価することはできません。(なるほど、なるほど！)日本ではその程度の評価基準で投資をしても株主からクレームがつかないようですね。 でも、金儲けに厳しい米国の株主はこのような解答では納得しません。何故、米国ではIT投資効果を説明できるのに、日本では「ITは見えないから」多額の投資をしても説明できないのか、不思議に思いませんか。  私が調べたものをここで披露します。 この資料を見て、なにやらできるような気がしたら、これからは評価してください。

質問5．	あなたはどのPMを採用していますか？

この答えは明瞭です。PMBOKです。 PMの世界的なデファクトスタンダードはPMBOKです。これは当然といえば当然な答えと思います。

質問6．	あなたはPMを実施する際に、プロジェクトの構想計画を実施していますか？

ここでの答えは、構想計画とは何をすることですか？という答えが返ってきます。 (たまに、PMBOKの立ち上げ群ですか？共通フレームワークの企画プロセスですか？)があります。 調べてみますと、多くのITプロジェクトは「ソリューション・パッケイジ」を導入しますので、構想計画はしていないようです。

質問7．	2006年になりますと、経済産業省やIPAから「超上流をIT化する勘どころ」という小冊子が発行されました。読まれましたか？

経営者がビジネス要求を出すことは「構想計画」をしなさいという意味だと理解しました。この解答で正しいのでしょうか？。

質問8．	2008年にIT経営ロードマップがIT経営協議会から発行されています。 IT専門家はご存知ですか？

内容を見ますと、 IT化に先立ち、「業務の見える化」をしなさいと示唆しています。理由はITソリューション・パッケイジを導入し、不足分をカストマイズする方法は現状システムの維持であって、業務改革を行うことができない。したがってまず「業務の見える化」をおこない、問題点を探して、業務改革の課題を摘出し、その構想計画書を作成し、次はその考えにしたがって情報化を進めなさいと示唆しています。 さて、読者の皆さん方はこれら一連の質問の中から、PMに関する種々の誤解に気が付いたでしょうか。 では誤解をお話しします。

1． プロジェクトライフサイクルマネジメント

	プロジェクトマネジメント(PM)の基本的共通観(PMに携わる人が知っておくべきこと)に、プロジェクトライフサイクルマネジメントがあります。
�@	構想計画：	このプロジェクトは何をするのかということについて構想計画をすること。構想を考え、何をするかという要求が明確になると、大きくは「使命・目的・目標」が決まります。更に詳細な要求事項が決まります。
�A	設計：	構想計画が決まりますと、多くのベンダーがその要求仕様によって入札ができます。入札に勝利した企業がプロジェクトを開始します。最初が設計です。基本設計、詳細設計を実施し、システムをつくる準備が完了します。
�B	システム開発：	完了した設計に従ってシステムが構築されます。
�C	テスト・引渡し：	システムはテストされ、仕様が満たされていることを確認し、引渡しとなります
�D	システム運用：	システムは運用されて、発注者の要求が満足されます。
この一連の業務の実施がプロジェクトライフサイクルマネジメントです。
�@	構想計画はシステムの発注者が実施するのがしきたりです。なぜならばベンダーが発注者の経営上の要求を知ることは不可能だからです。ましてや、米国で実行されたソリューション・パッケイジが別の会社の経営にそのままで役に立つことはむずかしいとお思います。

2． PMBOKとP2Mの相違点を理解しよう

上図は中央にプロジェクトライフサイクルである
�@ 概念構築・仕様の確定
�A 設計
�B 開発(システム開発)
�C テスト・引渡し
�D 運用
があります。P2Mでは�@のセクションを「スキームモデル」といっています。設計・開発・テストまでを「システムモデル」と呼んでいます。運用を「サービスモデル」といっています。
ここで「スキームモデル」はシステム発注者が実施する業務で、米国では主に経営戦略的視点からMBA資格者の実施領域と考えられています。「システムモデル」は受注者が実施する業務で、通常PMP資格者の領域と考えられています。「サービスモデル」はシステム発注者が実施する領域であることは皆さんご存知のことです。

米国では構想計画を実施しています。MBAがやっているのです。日本ではPMとはPMBOKだと誤解されているため、構想計画が実行されてこなかった事情があります。なぜならばPMBOKの中には構想計画が入っていないからです。

その理由をお話しします。

この図面を見てください。図には3つの丸が描かれています。PMは3つの機能から成り立っています。

�@	システムの成果物をつくるマネジメント(ユニーク性)と書かれた領域です
�A	標準化されたプロジェクトマネジメント知識体系(標準性)と書かれた領域で、通常PMBOKと呼ばれた部分です
�B	一般のマネジメント＋人間系のマネジメント(運用性)と書かれた領域です

1980年代に米国のITプロジェクトは成功率が極端に低かったため、米国内のPM専門家がPMI(米国プロジェクトマネジメント協会)に集合して、「如何なる業界のプロジェクトにも、如何なる国で行われるプロジェクトにも通用するPM標準手法を体系化したのがPMBOK(A GUIDE TO THE Project Management Body of Knowledge )です。

発注者から見たPMは3つの領域全部ですが、最も重要なのはシステムを作る領域でユニーク性の部分です。そこでは構想計画が最も重要な業務になります。しかし、PMBOKがPMのデファクト・スタンダードとなったために、日本では構想計画をしないことが当然のように誤解されてきました。

P2Mは通産省からの委託で作成され、2001年に国際PMシンポジウムでお披露目しました。P2Mは通産省から委託された時点で「発注者のためのPM」がないことに着目し、発注者を含めたPMとして構築しました。

次回はP2Mが構築された経緯、その特徴、どのように役に立つか、初歩的なことの説明をします。

以上