プロジェクト・マネジメント　（印刷用PDF）

2004/07/05

    組織の業務は「定常業務」と「プロジェクト」に分けることができます。「プロジェクト」は組織における通常の業務では対応できない様々な要求に対応する活動です。たとえば「企業再生」へ向けた活動も期限を定めて目標とする一定の成果を上げるように計画した場合はプロジェクトです。その場合の成果物は「目標とした財務内容を達成し、絞り込んだ収益性の高い事業から計画されたキャッシュフローを生み出す、モチベーションの高いスタッフで構成された組織（企業）」ということになりましょう。

    この「プロジェクト」の管理については「進捗」、「コスト」、「品質」が代表的な管理項目として従来から扱われておりましたが、これだけの管理で予期したとおりの成果が得られるわけではありません。

    今回はプロジェクト･マネジメント知識体系として世界的なデファクトスタンダードとなっているPMBOK（Project Management Body of Knowledge：ピンボック）を取り上げ、その概要をご紹介しますが、「プロジェクト･マネジメント」というテーマはメールマガジン1回分で語り尽くせるようなボリュームでは到底ありえません。今回はそのベースとなるごく基本的な考え方をご紹介することにとどめます。


  • 「プロジェクト」および「プロジェクト･マネジメント」とは

    • 「プロジェクト」とは「独自の製品やサービスを創造するために実施される有期的な業務」を言います。「有機的」ではなく「有期的」であることに留意ください。つまり期限を定めて行う活動ということです。また、「独自」とは以前に実施されたことがないという意味合いでご理解ください。反復的な要素があっても生み出される成果物が新規なものであれば独自性が存在するといえます。

    「プロジェクト･マネジメント」とは「プロジェクトの要求事項を満足させるために、知識、スキル、ツールおよび技法をプロジェクト活動に適用すること」です。組織の「定常業務」は「プロジェクト」とは異なりますが、定常業務を改善する活動は定常業務の中で常に求められており、この改善活動にプロジェクト･マネジメントの技法を応用することは可能です。


  • プロジェクト･マネジメント知識エリア

    • 冒頭でご説明したとおり、プロジェクトは「進捗（タイム）」、「コスト」、「品質」だけを管理していればうまくいくということではありません。PMBOKではこの3つを含む全部で9つの管理要素（知識エリア）を定めております。

    （１）統合マネジメント

    これはプロジェクトの様々な要素を調和の取れた形に統合するための管理活動です。これには次のプロセスが含まれます。後ろの括弧内はそのプロセスにおける主な成果物です。

    　・　プロジェクト計画の策定（成果物：プロジェクト計画書等）
    　・　プロジェクト計画の実行（成果物：作業結果、変更要求等）
    　・　統合変更管理（成果物：プロジェクト計画書更新版等）

    （２）スコープ･マネジメント

    これはプロジェクトを成功のうちに完了するために、プロジェクトに必要とされる全ての作業を含み、かつ必要とされる作業のみを含んでいることを確実にするための管理活動です。スコープという言葉には製品やサービスの特徴や機能を表す「成果物スコープ」とこの成果物を生み出すための作業を表す「プロジェクトスコープ」が含まれます。これには次のプロセスが含まれます。

    　・　立ち上げ（成果物：プロジェクト･マネジャの任命、制約･前提条件等）
    　・　スコープ計画（成果物：スコープ記述書等）
    　・　スコープ定義（成果物：ワーク･ブレークダウン･ストラクチャー等）
    　・　スコープ検証（成果物：公式な受け入れ）
    　・　スコープ変更管理（成果物：スコープ変更等）

    WBS（Work Breakdown Structure）について補足説明しておきます。WBSとはプロジェクトを完了するために必要なすべての成果物を洗い出し、階層構造により表現したものです。これに表現されたすべて作業の終了はプロジェクトの終了を意味します。WBSに出てこない作業はプロジェクトの作業には含まれないことも意味します。WBSの最下位レベルの要素成果物はワーク･パッケージと呼ばれます。ワーク･パッケージはさらに複数のアクティビティに分解され、それぞれのアクティビティに対して所用期間や費用が検討されます。

    WBSはプロジェクト･マネジメントのベースとなるものであり、これなしにプロジェクト･マネジメントは語れないほど重要なものです。

    （３）タイム･マネジメント

    これはプロジェクトを所定の時期に完成させるための管理活動です。これには次のプロセスが含まれます。

    　・　アクティビティ定義（成果物：アクティビティ･リスト等）
    　・　アクティビティ順序設定（成果物：プロジェクト･ネットワーク図等）
    　・　アクティビティ所要期間見積り（成果物：所用期間見積等）
    　・　スケジュール作成（成果物：プロジェクト･スケジュール等）
    　・　スケジュール･コントロール（成果物：スケジュール更新版等）

    （４）コスト･マネジメント

    これはプロジェクトを承認された予算内で完了させるための管理活動です。これには次のプロセスが含まれます。

    　・　資源計画（成果物：資源に対する要求事項）
    　・　コスト見積（成果物：コスト見積り等）
    　・　コストの予算化（成果物：コスト･ベースライン）
    　・　コスト･コントロール（成果物：コスト見積り改訂版等）

    （５） 品質マネジメント

    これはプロジェクトが意図するニーズを満足させることを確実にするための管理活動です。品質についてはプロジェクトの成果物により様々な考え方があります。最近は「顧客の満足」がすなわち「品質」であるというくらい広く解釈されるようになってきております。これには次のプロセスが含まれます。

    　・　品質計画（成果物：品質マネジメント計画書等）
    　・　品質保証（成果物：品質改善）
    　・　品質管理（成果物：受け入れの決定等）

    （６） 人的資源マネジメント

    これはプロジェクトに関与する人々を最も効果的に活用するための管理活動です。これには次のプロセスが含まれます。

    　・　組織計画（成果物：役割と責任の割り当て、組織図等）
    　・　要員調達（成果物：プロジェクト･チーム名簿等）
    　・　チーム育成（成果物：業務遂行能力等）

    （７）コミュニケーション･マネジメント

    これはプロジェクト情報の生成、収集、配布、補完、廃棄をタイムリーかつ確実に行うための管理活動です。これには次のプロセスが含まれます。

    　・　コミュニケーション計画（成果物：コミュニケーション･マネジメント計画書）
    　・　情報配布（成果物：プロジェクト記録等）
    　・　実績報告（成果物：実績報告書等）
    　・　完了手続き（成果物：プロジェクトの公式記録等）

    コミュニケーション･マネジメントで注意しなければならないのはオフィシャルなコミュニケーションだけでは不十分なケースが多々存在するということです。特に大人数の定例会議などで意思決定を求めても成果が出ないことは少なくありません。非公式な意思疎通の方が本音が聞けたり、実質的な意思決定に至ることがあることをプロジェクト･マネジャは忘れてはなりません。

    （８）リスク･マネジメント

    これはプロジェクトのリスクを識別･分析し、リスクに対応するための管理活動です。これには次のプロセスが含まれます。

    　・　リスク･マネジメント計画（成果物：リスク･マネジメント計画書等）
    　・　リスク識別（成果物：リスク等）
    　・　定性的リスク分析（成果物：プロジェクトの総合リスク･ランキング等）
    　・　定量的リスク分析（成果物：リスク優先順位リスト等）
    　・　リスク対応計画（成果物：リスク対応計画書等）
    　・　リスクの監視･コントロール（成果物：迂回策の計画等）

    プロジェクト･マネジメントにおいてリスク･マネジメントはおろそかにされることが大変多いと私は感じます。企業経営でも同じなのですが、最悪の事態を想定しているか否かが明暗を分けることが少なくありません。最初は簡易なものでかまいませんので、リスクを洗い出して、それに対して事前に対応策を考えて文書化しておくだけでも効果があります。

    （９）調達マネジメント

    これはプロジェクト母体組織の外部から物品やサービスを取得するための管理活動です。これには次のプロセスが含まれます。

    　・　調達計画（成果物：調達マネジメント計画書等）
    　・　引合計画（成果物：調達文書等）
    　・　引合（成果物：プロポーザル）
    　・　発注先選定（成果物：契約）
    　・　契約管理（成果物：コレスポンデンス等）
    　・　契約完了（成果物：公式な受け入れと終結等）


  • プロジェクト･ライフサイクル

    • プロジェクトは大きく4つのフェーズに分かれます。

    　・　立ち上げ
    　・　計画
    　・　実行
    　・　終結

    これらのフェーズはこの順番で実施されて行きますが、期間的に明確に区別できるとは限りません。多くは4つのフェーズがオーバーラップしてきます。また、フェーズとは呼べませんが計画－実行－終結の3つのフェーズにわたりプロジェクトをコントロールする作業が出てきます。


  • ライフサイクルと知識エリアの各プロセスとの関係

    • プロジェクトのライフサイクル（4つのフェーズ）とコントロールに対して、上述した各知識エリアの合計39個のプロセス割付を次のテーブルにまとめてみました。



    上記のテーブルから一目瞭然ですが、「計画」フェーズに多くのプロセスが含まれていることがわかります。私の今までのプロジェクト参加経験からも言えることなのですが、プロジェクトの成否は「計画」にかかっているといっても過言ではありません。「計画」には十分な時間を割くことがプロジェクト成功の秘訣のひとつです。


以　上


Copyright©2004 That's it コンサルティング 斎藤 淳 All Rights Reserved.