前回、「プロジェクト」、「管理」、「PM」といった言葉の定義をご説明しました。(前回の記事はこちら)

では、今回からPMBOKの主要な構成要素である”10の知識エリア”について解説を進めていきます。なお、”5つのプロセス群”は知識エリアの後に解説する予定です。

・”10の知識エリア”の説明

今回の本題に入る前に、簡単に”10の知識エリア”について触れます。
PMBOKは、プロジェクトを成功させるための知識体系と説明しました。”10の知識エリア”は、プロジェクトを成功させるためにPMが特に意識して管理すべき10個の要素です。全エリアの名称は以下の通りです。

・プロジェクト統合マネジメント

PMBOKでは、「プロジェクトマネジメント・プロセス群内の各種プロセスとプロジェクトマネジメント活動の特定、定義、統合、統一、調整などを行うために必要なプロセスおよび活動からなる」と定義されている知識エリアです。

特に意識しておくべきポイントは以下の２つです。

ゴールとそこに至る道のりの整合性確保(目標と進め方の統合)

このプロジェクトのゴールは何か、フェーズの設定や期間の割り振りをどうするか、ゴールに到達したと判断する条件は何か、これらが矛盾なく筋の通った状態になっていることが望ましいです。

例えば、アジャイル開発の経験を蓄積することがプロジェクトの目標になっているのに、工程管理がウォーターフォールの様式になっていたりすると、目標と進め方が統合されていないことになってしまいます。

管理方法や書式の統合

例えば、各工程を完了と判断する基準や作業進捗の管理書式がチームごとにバラバラだと、PMが正確に現状を把握できず、後の工程で品質の問題が顕在化する可能性があります。

さらに言えば、工程完了判定タイミングがプロジェクト全体のスケジュールに対して妥当か、といったことも意識する必要があります。

プロジェクトの目標から細かな書式まで矛盾がないように作りこみ、様々なプロセスが停滞することなく円滑に動くよう細部を気遣う必要があります。（神は細部に宿る、と言いますね！）

ここで作りこまれたものが、プロジェクトの「計画」です。

・「計画」はプロジェクト管理のキモ

プロジェクトには一般的に複数の人が関わります。実際にプロセスを動かすのはPMだけではなく、関係する人全員です。計画がしっかりしていないプロジェクトはメンバーの意思疎通が上手くいかず、成果物が想定していた品質に届かなかったり、納期を守れないことが終了間際に発覚したり、など終盤で大きな問題を発生させることがあります。

プロジェクトの中で変更が発生する場合、そのタイミングがプロジェクトの終盤に近ければ近いほど、修正コストが大きくなります。要件定義書を作成している段階とシステムテスト終盤の段階では、どちらが修正するものが多くなるか、一目瞭然ですね。

・｢計画」は立てて終わりじゃない

これはプロセス群での説明にも関わりますが、「計画」は立てて終わりではありません。プロジェクトは不確実性(＝リスク)を内包した状態で始まります。そもそも立てた「計画」が上手くいくかどうか、も不確実性の1つです。

もし、最初に立てた計画が完璧で、きっちり予定通り進み、問題なく成果物が完成するということが可能であればそもそもPMは必要ありません。

何か問題が発生して、何か手を打たなければならない時、現在の状況を把握してしかるべき判断を下すのがPMの役割です。このタイミングで判断の拠り所とすべきなのがプロジェクトの計画です。
今一度、プロジェクトの目標や当初の管理計画設定時に立ち返り、どうやって軌道修正すれば元のラインに戻れるか考えます。

・今回のまとめ

計画を立てるのことによる効果は以下のものがあります。

＞プロジェクト関係者が迷いなく行動するため

＞プロジェクトの各プロセスを円滑に動かすため

＞問題発生時の判断軸とするため

そして、常に想定通りに計画が進んでいるかを常に意識することで、プロジェクトをより良い方向に導くことができます。

・次回のテーマ

今回、計画の重要性を説明しました。
では、計画を立てるにあたって最初に意識すべきことは何でしょうか。次回は、プロジェクトで最初に優先順位を設定すべき3要素（QCD）について説明します。