有能なプロジェクトマネージャを育てるには（2）：何かがおかしいIT化の進め方（29）（1/3 ページ）

前回に引き続き、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。今回は特にPMBOKの使用法などについて考える。

[公江義隆，＠IT]

　団塊世代が組織から去りつつあるいま、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。2回目となる今回は、前回に引き続きシステム開発のプロジェクトマネジメント能力育成について考える。

システム開発プロジェクトマネジメントでPMBOKを参考にすると

PMBOKは教科書ではなく参考書

　プロジェクトマネジメントに関する知識というと、「PMBOKを教科書にして勉強しよう」という方がときどきおられる。PMBOKは、いろいろな分野で行われる“プロジェクト”という仕事のやり方を分析能力にたけた人が整理し、プロジェクトマネジメントの一般的・共通的な枠組みとして整理したものだ。

　少し極端ないい方をすると、「共通性という観点から整理してみると、いろいろな分野のプロジェクトという仕事の中には、こんな共通の問題がありますよ」という分析結果のまとめ（一種の理論）なのである。

　理論であるから抽象化されている。従って、情報システムでは大問題であっても、ほかの分野のプロジェクトとの間で共通でなかったことや、特定のケースでは重要であっても一般的ではないことは当然取り上げられない。また、これを隅々まで覚えることで資格試験には合格できても、実際のマネジメントがうまくできるというわけではないのだ。

　PMBOK関係の資料や書籍を眺めて、「分かったような、分からないような……」という人がよくおられる。企業の中では、仕事の役に立たないレベルの理解は知らないのと変わらない。どうせ勉強するなら、役に立つレベルまで徹底的にやることだ。仕事に生かすことができるレベルでの理解とコンピテンシー（注1）が大切なのである。そのためには、ほかの分野のいろいろな問題において「理論を応用して問題解決をする・創作する」ときと同様に、一般論・総論を具体論に構成し直す工学的アプローチが必要になる。

　“ハウツーものを読んで覚える”という目先の効率重視の価値観や、マニュアルに頼る文化からの脱却が、真の実力を付けるための出発点になるのだ。

---

（注1）

高いレベルの成果を生み出すために、行動として安定的に発揮される能力・行動特性。

---

システム開発プロジェクトへのPMBOK適用のポイント

ポイント1

　情報システム開発では多くの場合、プロセス全体をフェイズに分けて作業が進められる。PMBOKを基にしてマネジメントを考える場合には、1つのフェイズをPMBOKでいうところの「1つのプロジェクト」と考えると分かりやすいと思う（注2）。

　すなわち、フェイズごとに、PDCAに相当する5つのプロセス（立ち上げ、計画、実行、コントロール、終結）と、9つの分野のプロセスマネジメント（統合、スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達）があると考えるわけである。

---

（注2）

PMBOKは、1つのPDCAサイクルの内容を整理したものである。また、WBS（Work Breakdown Structures：そのプロジェクト／フェイズで行う作業要素への分解）は、そのプロジェクト／フェイズの計画プロセスの作業に位置付けている。フェイズ分割の実態に、これとの食い違いがないかを確認しておく必要がある。

---

ポイント2

　情報システム開発は、すべてのフェイズが一気通貫に実行されるのが一般的なので、上記ポイント1の結果、隠れてしまう“全フェイズ一貫のマネジメント機能”を、別に付加して考えておく必要がある（PMBOKの統合マネジメントは、フェイズ内の各プロセスマネジメントを統合する位置付けのもの）。

　この中で、プロジェクト全体を対象とする“立ち上げ”や“計画”と、実行段階での各フェイズの統合、システムガバナンスにかかわる問題（投資効果の管理やセキュリティ管理体制、システムインフラ標準化の管理……、など）を、この“全フェイズの一貫マネジメント機能”の中で具体的にしておくことが必要だ。

　また、システム開発では、計画・設計からプログラム作成のフェイズまでのブレークダウンのフェイズ群と、この後のプログラムやシステムのテスト、業務運用テスト、運用・保守という積み上げのフェイズ群が写像の関係になっている。

　この構造に基づいて各フェイズの作業で用いる条件は、「どの先行フェイズのどのドキュメントに記載されているか？」を明確にしておくことが大切である（例えば、プログラムテストやシステムテスト、総合運用テストや本番移行の条件は、それぞれの設計フェイズで決められるべきである）。

ポイント3

　情報システム開発のプロジェクトには、「効果発現の管理」という大変重要な問題がある。この問題の主な管理対象は、システム開発途上のユーザー側での準備作業（組織や業務手順などの改編、人事異動、関係者の教育訓練など）だ。

　この内容についての計画、検討・準備の実行が、効果の発現に向けて順調に進むように、それらの内容や進ちょくをキチッと管理しなければならない。くどくなるが、これは1つのマネジメントの下で、システム開発途上にコンピュータシステムの開発と並行して行われるべき作業なのだ。

　PMBOKにはコストの管理はあっても、この効果発現のマネジメントプロセスについての明示的な記述がない（効果＝プロジェクト目的という考え方がほかの分野での一般的な理解）。コスト発生を伴うコンピュータシステム開発作業にコスト管理が必要なように、効果をアウトプットとするユーザー側の業務システム開発という準備作業については、その内容に基づく発現効果のための管理が必要なのだ。

　例えば、プロジェクトの進行途上で、計画どおりの効果の発現が期待できそうにないということが分かれば、その対象部分のシステム機能の変更や、システムコスト（投資額）の削減策を検討しなければならない。IT関係者には抵抗があるかもしれないが、これができなければ「状況変化に対応しない」と批判の多い公共工事と同じになってしまう。

　システム化プロジェクトのマネジメントの範囲（スコープ）は「コンピュータシステム」と「業務・人のシステム」の両方である。

ポイント4

　先に述べた「分かったような、分からないような」というのは、抽象的には知ったが、具体的なものと結び付けができるほどには理解できていない状態なのだと思う。この抽象的と具体的、理論と実際のギャップを埋めるためには、以下に述べるような作業が有効である。

　PMBOKでは、5つのプロセス、9つの知識エリアの組み合わせからなる（5×9）のマトリクス上に44のマネジメントプロセスが定義されているが、この44のマネジメントプロセスそれぞれについて、「その具体的な対象・具体的な内容・具体的な成果物が何になるのか」、また「それらについての説明は、具体的にはどのようなものになるか」を、フェイズごとに情報システム分野の問題や言葉、自分たちの現場作業や成果物に書き換えてみることである。

　これによって、初めてPMBOKと情報システム開発プロジェクトマネジメントの関連が具体的に把握できたことになるのだ。