第2章 プロジェクト・マネジメント・フレームワーク

2.1 プロジェクトの定義

プロジェクトとは、下記を意味している。

(1)独自の製品やサービスを創造するために実施される期間が区切られた業務

(2)始まりと終わりがある

(3)目標、目的、ゴール…つまり成果物がある

(4)人によって実施される

(5)限られた資源によって制約される

(6)計画→実行→コントロール→計画… と繰り返される（PDCA）

2.2 プログラムの定義

プログラムとは、下記を意味している。

(1)関連性のあるプロジェクトのグループ

(2)調和の取れた方法でマネジメントされるプロジェクト群

(3)反復的/周期的業務も含まれる

2.3 ステークホルダー

ステークホルダーとは、下記を意味している。

(1)プロジェクト・マネージャー、スポンサー、チームだけではない

(2)プロジェクトにより、自分の利益にプラス、あるいはマイナスの影響を受ける個人/組織

(3)プロジェクトに積極的に関与している個人/組織

(4)プロジェクト・マネージャー(プロジェクトをマネジメントする責任を有する個人)

(5)顧客（プロジェクトの成果物を使用する個人/組織）

(6)スポンサー(プロジェクトの資源を資金面から支える個人/組織)

(7)チーム/メンバー(プロジェクトのタスクを実行する人々)

2.4 社会/経済/環境の持続性

プロジェクトの持続性とは、下記を意味している。

(1)プロジェクトは、社会、経済、環境に対し責任、説明義務(アカウンタビリティ)がある。

(2)プロジェクトが終結し、年月が経った後も、説明義務は持続する。

つまり、「プロジェクト終結後も将来を考えておく必要がある」、と言う事である。

2.5 「3つ」の制約条件

プロジェクトには、基本的に「3つの制約」があると言っているが、この「3つの制約」に付随して、「2つの項目」が存在する。これらは相互に影響しあい、時にはトレートﾞ・オフの対象となる。

2.5.1 基本的な制約

(1)コスト

(2)時間(タイム)

(3)スコープ

2.5.2 付随する制約

(1)品質

(2)顧客満足(カスタマー・サティスフアクション)

2.5.3 品質について

よく「品質第一」と言われるが、「品質とは何か」と言うことを考える必要がある。PMBOK日本語版には、下記のように定義されている。

『 品質とは、ある物の、明示された、または暗黙のニーズを満たす能力に関する特性の全体 』

しかし、品質とは『 予定したものとできたものの差 』と考えるのが普通である。例えば、

(1)ソフトウェアなら、要求仕様書と出来上がったソフトウェアとの差異

(2)建築物なら、青写真と建造物自体の差異

(3)サービスなら、提供サービスの説明と実際に行われたサービスの差異

品質の良し悪しを決定するのは、「予定した/計画した/要求された」成果物と、「現実に行われた/できあがった/提供された」成果(納品)物の差異のことである。良く「品質はお客様に評価して頂く」と言うが、それは間違いである。

品質とは、お客様が、「事前に合意した/定義した/要求した」結果で決まるのであって、ここでいう「結果」とは、設計書であれ、仕様書であれ、文書で定義された物のことである。

だから、品質管理だけ力を入れることは不可能であり、品質管理を正確に行うためには、少なくとも最初に、「何を作るのか/したいのか」と言う事が、要求事項が明確化されてなければならない。

PMBOKで言うと「スコープ」の事である。そして、どれぐらいお金がかかるのか(コスト)、納期はいつになるのか(時間)、を事前に決めておく必要がある。

「何を作るのか/したいのか」と言う事が明確化されていなければ、品質は、最初から無いも同然である。

良く「コスト、時間、品質」と言われるが、この三拍子は間違いであり、本来の三拍子とは、「コスト、時間、スコープ」のことである。(但し、時と場合により異なる)

そして、コストは見積もり通り、時間(期限/納期)も予定通り、スコープ(要求仕様/事前説明)どおりの製品が提供されて、初めて「高品質」と評価されるのである。

PMBOKにおける「品質」についての説明をしたが、実際には、PMP試験における「品質」と現実社会における「品質」とは、かなり違うので注意する必要がある。

また、品質関連の質問で、下記の選択肢がでてきたら正解と考えて間違いない。

(1)要求事項への適合

(2)使用適合性

2.6 プロジェクト・ライフサイクル

「プロジェクト・マネジメント・ライフサイクル」とは違うことに注意する必要がある。「プロジェクト・ライフサイクル」とは、『 プロジェクトにおいて行う仕事 』のことである。

例えば、ソフトウェア開発の場合は、下記のライフサイクルとなる。

(1)要求仕様の分析

(2)基本・詳細設計

(3)コーディング

(4)テスト

(5)インテグレーション

(6)移行、運用

これら(1)～(6)をフェーズと呼び、各フェーズの中に、(常にそうなるとは限らないが)次項以下の「プロセス」が繰り返されていると考える。

2.7 プロジェクト・マネジメント・ライフサイクル

「プロジェクト・マネジメント・ライフサイクル」とは、以下のプロセス群により構成される。

(1)立ち上げプロセス群

(2)計画プロセス群

(3)実行プロセス群

(4)コントロールプロセス群

(5)終結プロセス群

そして、情報に関しては、次のように流れることになる。

①立ち上げ→計画→実行→コントロール→終結

②コントロール→実行

③コントロール→計画

それぞれのプロセス群は、必ずしも段階を追って順々に実行される必要はなく、オーバーラップする部分もある。また、1つのフェーズの中に、「プロジェクト・マネジメント・ライフサイクル」が含まれている。

(1)立ち上げプロセス群 ： プロジェクトを認可する

(2)計画プロセス群 ： 目標を定義して、詳細化する。その目標を達成するためにやるべきことを選択する

(3)実行プロセス群 ： 計画を実行するために人・資源の調整を行う

(4)コントロールプロセス群 ： 計画からの差異を検出するため、進捗を定期的にチェックする。必要な場合は是正処置を行う

(5)終結プロセス群 ： プロジェクトを承認し、プロジェクトを終わりへ導く

2.8 プロセス同士の関係性

プロセス同士の関係性は、「付録4.プロセス関連図」を暗記すること。矢印は情報の流れを示す。「○○の次に何をするのか?」の設問の大半は、ここから出題されるから。

2.9 プロセス分類表示

39個のプロジェクト・マネジメント・プロセスを、知識エリアへ割り付けた「付録3.9個の知識エリア」を暗記する必要がある。

これら39個のプロセスは、「付録4.プロセス関連図」のように、5個のプロセス群に配置され、関係付けられている。

そして、各プロセスは、プロセスに必要なインプット(入力)とプロセスの処理結果として出力されるアウトプット、およびインプットからアウトプットを生み出すために利用されるツールと技法から構成されている。

また、プロジェクト計画の段階的な詳細化は、ローリング・ウェーブ計画法と呼ばれ、計画作成が反復的で継続的なプロセスであることを示している。

2.10 プロセス毎の作業

2.10.1 立ち上げプロセス

(1)プロジェクトを選択する

(2)過去の情報を集める

(3)プロジェクト成果物を決める/見積もる

(4)プロジェクトの前提条件/仮定条件を決める

(5)どんな業務要件があるか調査し、定義づける

(6)どんなプロダクト(製品)になるか、調査する

(7)プロジェクト・マネージャーの責任を定義する

(8)どれくらいのリソースを使うか見積もる

(9)プロジェクト憲章を仕上げる

2.10.2 計画プロセス

(1)スコープ記述書を書く

(2)プロジェクト・チーム/チームメンバーを決める

(3)WBSを書く

(4)WBS辞書(WBS内のタスク毎にスケジュール、予算、メンバーを記載したシート)を書く

(5)ネットワーク・ダイヤグラムを書く

(6)時間とコストを見積もる

(7)クリティカル・パスを見極める

(8)リスク・マネジメント計画書を書く

(9)スケジュール表を作成する

(10)予算を策定する

(11)コミュニケーションが必要なステークホルダーを洗い出す

(12)品質評価基準を決める

(13)リスク識別、定性的リスク分析、定量的リスク分析、リスク対応計画を、書く

(14)スコープ、スケジュール、コスト、品質、人的資源、コミュニケーション、調達マネジメント計画書を書く

(15)プロジェクト管理システムを決める

(16)プロジェクト計画書を承認してもらう

(17)キックオフ・ミーティングを開催する

2.10.3 実行プロセス

(1)プロジェクト計画書に沿って実行する

(2)プロジェクト進捗を測る

(3)ワークパッケージを遂行する

(4)プロジェクト情報をステークホルダーに伝える

(5)品質保証(品質評価基準がちゃんと役に立っているか検査すること)を行う

(6)メンバーの育成を行う

(7)進捗報告ミーティングを開催する

(8)「変化」を識別する。つまり、プロジェクト計画と現実との「差」がないか見極める。

(9)作業認可システムを使う。意味としては「そのタスクがWBS辞書に定義されたとおりの正しいタイミング、正しい順番で行われたかを認可する手続き」である。

(10)プロジェクト計画からみて、「例外」が発生していないかチェックする

2.10.4 コントロールプロセス

(1)変更管理を実行する

(2)プロジェクトが予想したどおりに進捗しているか報告する

(3)スコープ変更を管理するる

(4)品質管理を行う

(5)リスク管理を行う

(6)スケジュール管理を行う

(7)コスト管理を行う

(8)スコープを再確認する

(9)計画を遵守しているか確認する

(10)プロジェクト計画をアップデートする

(11)是正措置を取る

2.10.5 終結プロセス

(1)調達監査を行う

(2)プロダクトを検証する

(3)財務決済を行う

(4)教訓を取りまとめる

(5)もろもろのプロジェクト情報をアップデートする(記録するため)

(6)結局、プロジェクトが予想通りに進捗したのか? 予想と差異があるのなら、どれぐらい差異があるのかを報告する

(7)オフィシャルな承認をもらう

(8)プロジェクト情報のアーカイブを作る

(9)使用したリソースを解放する

2.10.6 組織形態

組織形態として押さえるべきポイントは、以下の3ポイントである。

(1)プロジェクト・マネージャーと機能マネージャーのどちらに権威があるか?

(2)その組織形態のメリットは?

(3)その組織形態のデメリットは?

2.10.7 プロジェクト型組織

プロジェクト指向の組織形態のことである。CEO配下に、プロジェクト・マネージャーがプロジェクト単位にいて、その配下にメンバーが割り振られる。メンバーはプロジェクト・マネージャーにだけ報告すればよい。

(1)メリット

①プロジェクト指向の組織のため、案件に対し最も効率のよい組織といえる

②機能型よりもコミュニケーションがやりやすい

(2)デメリット

①プロジェクトが終結したら「ホーム」がなくなる

②(財務や人事などの)プロフェッショナルが育ちにくい

③プロジェクト毎に同じような仕事が重なることになり非効率的(プロジェクトのそれぞれに経理担当がいると考えてみて)

④人的リソースの使い方が非効率的

2.10.8 機能型組織

最も一般的な組織形態のことである。CEO配下に、「開発部門」、「営業部門」、「経理部門」と機能単位に統括者がいる形である。

試験ではほとんど出てこないが、「マトリクス型組織はどこが優れているか」といった設問の行間には、「マトリクス型組織は、機能型組織と比べてどこが優れているか」という事が隠れていることが多いので、注意が必要である。

(1)メリット

① 単一業務しか行っていないので、(経理や営業などの)スペシャリストが育ちやすい。メンバーはただ一人の上司に報告すればよい

②似たようなリソースが集中しているため、その分野のプロ単位に組織化されている

③キャリアパスが明確になっている

(2)デメリット

①プロジェクトの遂行よりも、目先の業務をこなすことに注力しがちになる

②プロジェクト・マネジメントのキャリアパスは育たない

③プロジェクト・マネージャーは、何の権威もない

2.10.9 マトリクス型組織

プロジェクト型と組織型の、それぞれの良い箇所と悪い箇所を併せ持っている。ポイントとして、メンバーは、上司が二人いる(プロジェクト・マネージャーと機能マネージャー)ので、両方に報告しなければならない。

強いマトリクス型組織では、プロジェクト・マネージャーが、より強い権威を持つことになる。一方、弱いマトリクス型組織では、機能マネージャーが、より強い権威を持つことになる。バランス・マトリクス型組織では、権威は二人のマネージャーで共有されることになる。

タイト・マトリクス(tight matrix)は、組織形態とは、何の関係もないものである。これは、メンバーがオフィスの同じ部屋に「縛り付けられているか」という意味。(ダミーの選択肢として、まれに出題される。)

仕事を進めたり、モニタリングしたり、コントロールしたりするために複雑化するが、そこそこ効率的で、そこそこ安全で、そこそこプロジェクト向けな組織形態といえる。現実には、これが一番多いのではないかと思われる。

PMBOKでは「プロジェクト・マネージャー」VS「機能マネージャー」で、権威やリソースの綱引きが行われると書いてあるが、余り現実味が無い内容になっている。(実際には、その確執がメンバーに押し付けられる形になっている。)

(1)メリット

①プロジェクトの目標が見えやすい

②プロジェクト・マネージャーが、リソース管理する能力を育むことができる。つまり、プロジェクト型だと無駄使いするかもしれないし、機能型の場合、リソース管理さえ行わせてもらえないことになる。

③機能組織からのサポートが受けやすい

④限られたリソースを最大限に活用することができる

⑤より調和の取れた組織形態

⑥機能型よりも、水平・垂直の両方向にコミュニケーションが取れる。水平は、プロジェクト・メンバー同士。垂直は、プロジェクト・マネージャー同士

⑦プロジェクトが終結しても、メンバーには「ホーム」がある

(2)デメリット

①プロジェクト・マネージャーと機能マネージャーの調整役を必要とするため、コスト的に見て非効率的

②メンバーにとって二人以上の上司がいる

③モニタリングやコントロールが複雑

④リソースの割り当てが難しい。時には奪い合いになることもある。ここでいうリソースは「人的リソース」を意味すると思われる

⑤仕事を進める上での方針や手続きが、プロジェクト部門と機能部門の両方にまたがる

⑥優先順位が機能マネージャーとプロジェクト・マネージャーで異なることがある。現実には、良く対立することがある。最初は機能マネージャーに知識がないと思われがちであるが、両方の仕事を経験すると、どちらも正しいことが理解できる。機能マネージャーは、機能マネージャーの、プロジェクト・マネージャーは、プロジェクト・マネージャーの「やるべきこと」があり、どちらも必要なことなのである。PMBOKでは明確には書いてないが、「プロジェクト・マネージャーが最高です」と言うような選択肢があれば迷わずに、これを選んだ方が良いと思われる。

2.10.10 プロジェクト推進担当

スタッフの手助けをしたり、異なる機能部門の間に立って、コミュニケーションの調整をしたりする人である。立場はマネージャーより下になり、部門間におけるメンバーの緩衝材のような立場になる。原語は、『 Project Expeditor 』

※ expeditor : 推進 / 原料供給係 / (生産・製造工程での)督促係、促進係

2.10.11 プロジェクト・コーディネーター

部門間の調整役である意味では、上記と同様である。異なるのは、立場がマネージャーより格上であるところである。プロジェクト・コーディネーターからの指示は、マネージャーを通して通達される。(実際には、現場を良く知らない人間が多い。)

※coordinator : 同格対等にする人 / 整合調整する人

2.10.12 プロジェクト・オフィス

プロジェクトが遂行されるオフィスのことである。実際には、細かく指導する人間がいたり、放任主義の人がいたりと、様々な形態がある。

(1)プロジェクトを遂行する上での方針や方法、テンプレートだけを提供する。(テンプレートとは、その組織で使う報告書や指示書の様式のこと)

(2)仕事を進める上でのお手本を示してくれる。

(3)プロジェクト・マネジメントを、どのように進めるのかを教えてくれるプロジェクト・マネジメント・ソフトウェア(MicrosoftのProject2000/2003が有名)の使い方や、他のプロジェクト・マネジメント・ツールを適用する方法を指導してくれる。

(4)複数の異なるプロジェクトを与え、それらのプロジェクトの結果への責任を持たせる。

プロジェクト・オフィスのキーとなる考えは以下の3つである。

(1)プロジェクト・オフィスの役割が明確に定義されていること

(2)シニア・マネジメント(プロジェクト・マネージャーの上司)の承認が得られていること

(3)プロジェクト・マネジメントの手法を実際に使わない限リ、どんなにトレーニングをしてもらってもプロジェクト・マネージャー能力は上達しない