プロジェクトマネジメントフレームワーク4

プロジェクト・フェーズ

フェーズには属性がつきます。魔法でいうと火の属性で、名前はメラゾーマで攻撃力はXX、という具合に、プロジェクトフェーズにも、名前、所要期間、その時に必要なもの、開始・終了基準などが属性として付与される。フェーズはプロジェクトマネージャーが勝手に決められるものではない。プロジェクトはお金がかかるものなので、資金を出した人に状況を伝える必要があるので、伝えられる側が理解しやすいフェーズの切り方というのは案外重要になる。そのほか、この業界では多くはこのフェーズの組み合わせを採用しているのでそれを利用するというやり方をすると、参加してくるメンバーにとっては都合がよい。

フェーズ・ゲート

時間をフェーズというもので区切るからには、どこで明確に区切られるか、その境目がフェーズといものの形を表現することになる。プロジェクトの場合特に重要になるのが、何をもってそのフェーズを完了とするかだ。この完了の基準のことをフェーズ・ゲートという。このときに参照される成果物はとても重要になる。次のようなものだがそれぞれ深みのあるものなので後述するとしてここでは細かくは記載しない。

・プロジェクトビジネスケース
・プロジェクト憲章
・プロジェクトマネジメント計画書
・ベネフィット・マネジメント計画書

基本的には、このプロジェクトを行う意味について、予想される結果と成果、いまのところの状況というのを見て判断する。そして判断の結果として次のアクションのどれかを選択する。

・次のフェーズに進む
・少し修正してから進む
・もうやめてしまう
・まだこのフェーズを終わらせない（のこっている作業を行う）
・もう一度同じフェーズを最初から行う

プロジェクトマネジメント・プロセス

プロジェクト・ライフサイクルの中身は、決められたやりかた（プロセス）だ。プロセスが組み合わさって一つの流れを作り出す。プロセスはまさに人間を作り出す細胞のようなもので、プロジェクト＝プロセスといっても過言ではない。プロジェクトの中にはいろいろな形のプロセスが詰まっている。

プロセスはいくつかのインプットといくつかのアウトプットが必ず存在する。何も入れない、何も出さないプロセスというものはなく、入ってくるものと生み出されるものがある。それがプロセスだ。プロセスが作り出すものはふつう以下のどちらかになる。

　プロジェクトのアウトプット　
　　　　　　↓
・別のプロジェクトへのインプット
・プロジェクト全体の成果物、もしくはフェーズでの成果物

プロセスも大体に通ったグループに分けられる。

・プロジェクトの進行に応じて半自動的に立ち上がってくるもの
　　例：プロジェクト憲章の作成や、フェーズ終結プロセス
・プロジェクト中に発生した何かに応じて動き出すもの
        例：プロジェクトメンバーの参加に応じた参加処理　など
・プロジェクト全体を通して継続的に行われるもの
　　例：リスク管理や変更管理、問題管理など

プロセスは多いのでいくつかのグループに分けて考える。知識エリアと呼ばれる次の10個だ。すべてにプロジェクト　と　マネジメント（管理）という文言がつくが省略している（統合　なら　プロジェクト統合マネジメント　という具合）

＜大枠として＞
統合：プロジェクトという無形のものの形を保つためにある。哲学。頭脳
＜土台として＞
スコープ：やるべき範囲というラインをひく。時空の空間部分。
スケジュール：範囲の次は時間だ。時空でいれば、時間がここ。
コスト：お金は必要。ガソリン。これがないと動かない
＜動くために＞
品質：どのくらいのきれいさで動かすか
資源：だれがやるか。人間はここ。お金だけあってもだめ。
調達：どうやって手に入れるのか
＜人間がいることを忘れない＞
コミュニケーション：どう有機的に、高めあって作業するか
ステークホルダー：すごく声が大きい人達に納得してもらう
＜こわいことを鎮めよう＞
リスク：どんな怖いことがありそうで、どう備えるか

PMBOKではプロセスを5つのプロセス郡としてグループ化している。以下の５つだ。上記の知識エリアとの紐づけも追記する。

１．立ち上げプロセス群

立ち上げ時は２つのことをする。統合管理と、そして一番利害が関係するステークホルダー管理が重要。

２．計画プロセス群

計画は重要なので、すべての知識エリアが含まれる。すべてだ。

３．実行プロセス群

実行では土台にあたる、スコープ、スケジュール、コストはいったんわきに置かれる。統合は常にどこのプロセス群にも含まれている。

４．監視・コントロール・プロセス群

ここも、計画がそのまま進んでいるかをみるところなのですべての知識エリアが含まれる。

５．終結プロセス群

終結では統合管理だけが関係する知識エリアとなる。別の見方をすれば、

■立ち上げ、終結プロセス群
統合管理（初回のみステークホルダーも仲間に入れよう）をしよう。
ある意味特殊なところで、統合管理しかしていないところともいえる。
■計画、監視・コントロール・プロセス群
ぜーんぶやります。
■実行プロセス群
スケジュール、スコープ、コスト以外の雑多なところは面倒みましょう。
品質、資源、コミュニケーション、リスク、調達など。

ということも言える。

プロジェクトマネジメントのデータと情報

プロジェクトはプロセスの連なりであり、プロセス自体はインプットを得てアウトプットを行う。その流れの中でいろいろなデータが、プロジェクトマネージャーを中心に管理者の元へと集まってくる。集まってこなければそのデータは判断に利用されないのでないも同然だ。なので集めてくるようになっていなくてはならない。そのデータは生のデータからだんだんと加工されていく。その段階を３つに分けると以下になる。

・作業パフォーマンス・データ
　　作業にかかった時間やコスト、実施した日、変更や欠陥の数
・作業パフォーマンス情報
　　データを集計してまとめたり、残りの時間を予測したりする
・作業パフォーマンス報告書
　　情報をとりまとめてメッセージとし誰かにアクションを起こしてもらう

テーラリング

プロジェクトは、実施するたびにいろいろなことが違う。関わる人も周りの状況も全く同じということはあり得ないので、プロセスを現状にあわせて工夫や変更をする。こういう作業をテーラリングという。テーラーメイドという言葉にあるように、そこにある状況にプロセスをあつらえる。プロセスがあるからといって、それを前任者がやっていたからといってそのままやるのでは無策と同じだ。闇雲に変えるのもよくない。そうなっている理由がないかもよく考えるべきだ。そういう熟考をかさねて、プロセスを少しずつ変えたり、場合によっては抜本的に見直したりする。それがテーラリングだ。