３．実行のプロジェクトマネジメント

「よくわかるプロジェクトマネジメント」でプロジェクトマネジメントの基礎を学習した内容をまとめ。

プロジェクトマネージャー

プロジェクト実行における意思決定は、多数決や合議制では行いません。責任者であるプロジェクトマネージャーが最終決定します。プロジェクトには明確な目標があり、意思決定の方向性が明確。さらに資源（ヒト、モノ、カネ、時間）の制約があり、最善の方策をタイムリーに決めていく必要がある。

プロジェクトマネージャーにはプロジェクトを実行するための組織を作る権限、意思決定に必要な指揮命令権、予算の執行権などと同時にプロジェクトを完遂し、完成させる責任が与えられる。

プロジェクトマネージャーが権限と責任を持つことによって、舵取りが容易になり、プロジェクトを成功に導くことができる。

プロジェクトマネージャーは経験やプロジェクトマネジメントの知識に加え、洞察力、コミュニケーション力や交渉力、リーダーシップなど、多面的な知識や能力が必要となる。経験や勘に頼るだけでなく、トレーニングや継続的学習により身につけることができる。

目的・目標の確認

プロジェクト実行において、最初にすることは発注者の意図の確認。構想・企画書には出てこない事項が多くあることを経験から感じます。

詳細設計に入る前に構想・企画書、経験などから発注者の意図を推測し、明文化し、発注者に確認することが必要。

この作業を怠ると、詳細設計や実行の途中での変更を余儀なくされ、納期の遅延や発注者の意図とは違った結果になる恐れがある。可能な限りイラスト化し、理解を得ることが大事。

しかし、関係者も収益を出すという目的も達成しなければなりません。条件として。

デザインレビュー 設計審査

設計書のチェックのことをデザインレビューという。要求が確実に設計書に反映されているか、要件が叶えられないのはどこか、その代案などを準備することも大切。発注者の希望が優先ですが、機能面、コスト面、安全および環境面などの観点からの検討も必要。最終成果物を得る大切なステップ。おろそかにすると、やり直しによる納期遅れなど、さまざまな問題が発生する可能性がある。

レビューは通常は中間成果物ごとに行うことが好ましい。完成時のみだけでなく、作業の途中でも行い、品質を向上させることが重要。

レビュー実施は事前に資料を関係者へ配り、当時までに内容を検討してもらうようにする。指摘された問題点は解決されるまで徹底的にフォローが必要。

プロジェクトに直接関係のない専門家が参加する第三者レビューは、客観的な評価ができるという効果もあります。

プロジェクトチーム

プロジェクトチームを組織化します。WBSに従い作業を洗い出し、今までの実績と得意分野をベースに各チームを選び、チームリーダーを選任する。

プロジェクトは目標を遂行するために携わる関係者も多く、調整業務がなどが増える。そのためには実施組織や役割分担について、WBSを用いて明確に定義する必要がある。まず、役割分担を定めた責任分担表（RAM)を作る。

プロジェクトは複数の人で行われるため、チームとしての協力がなければスムーズな進捗や完成は難しくなる、チームビルディングが大切。

チームビルディングで注意することは、

1. メンバーがプロジェクトの目標、方針の理解
2. メンバー間での密なコミュニケーション

が大事。

お互いが理解することで、プロジェクトを円滑に遂行できるようになる。プロジェクトは人が進めていくものであることを忘れてはなりません。

プロジェクトチームメンバーだけでなく、プロジェクトに関わる外部組織や関係者（ステークホルダ）も同じことがいえる。組織間のインターフェースを密にするためにミーティング（会議や現場打合せなど）を実施し、情報を組織（チーム）間でタイムリーに交換する。人的なインターフェースを重心する運営が大事。

用語：RAM（Responsibility Assinment Matrix）
責任分担表：各自がそれぞれの作業でどのような責任と権限を持つかを明示する。

スコープの設定

限られた時間と資源（リソース）のなかでプロジェクトの目標を実現するためには、どこまでをプロジェクトの実行範囲（スコープ）にするか、発注者と受注者の間で合意が必要。

プロジェクトメンバーにとって、目標や得るべき成果物が具体化され、何を行うべきかが明確になり、参画意識が高まる。強い参画意識はプロジェクトの成功に欠かせない大事な条件の一つ。プロジェクトマネジメントではプロジェクトの目標達成までに実行、実現すべき事項を、スコープ設定を通じて絞り込み、具体化する。

スコープとは

プロジェクトの目標到達のためには何を作り、何をどの範囲まで行えばいいのかを定義するもので、今後、プロジェクトを遂行するにあたって、骨格のような重要や役割を担う。次の２つに大別される。

プロダクトスコープ

プロジェクトで完成するものを列挙して成果物を示す。

プロジェクトスコープ

プロジェクトの成果物を得るために何をするかという作業範囲を示す。打合せ、開発範囲、インフラ、書類の作成など「役務（作業）」。

スコープ設定により、プロジェクト関係者全員にとって何をどこまでやらなくては目標に到達できないかあが明確になる。

WBSの詳細化とワークパッケージ

作業項目を明確にして管理する必要があり、WBSを詳細化し、作業項目ごとの管理が重要なポイント。WBSはプロジェクトマネジメントの基本概念の一つで、プロジェクト全体の役務、供給範囲を表し、階層構造になってます。

WBSの詳細化は以下のポイントで行う。

1. プロジェクト全体の業務を体系的かつ網羅的に表記
2. 管理の最小単位（WP）まで分解
3. 管理単位ごとに管理責任者を置く
4. コスト、スケジュールの計画と管理の基礎

WBSは成果物単位に分解し、管理するうえでの最小単位まで分解。

子の最小単位をWP（ワークパッケージ）と呼び、責任者を置き、成果物を得るため資源（ヒト、モノ、カネ、時間）を割り当て、管理の基本単位とする。

またWPの成果物を得るために必要な作業をアクティビティ（またはタスク）と呼ぶ。詳細なスケジュールはアクテビティ単位につくる。

このようにして作られたWBSはプロジェクト全体の業務を網羅的に表し、プロジェクト全体の情報共有（進捗管理やコスト管理などの情報）の基礎資料としてプロジェクト全期間を通して活用する。

用語：WP（Work Package：ワークパッケージ）
WBSの最小管理単位であり、資源（ヒト、モノ、カネ、時間）を割り当てる

スケジュールを明確にする

プロジェクトマネジメントにおいて、スケジュールの管理は大きな柱となる。スコープや仕様条件が決まると、次はスケジュール作成。マスタスケジュールに基づき、ＷＢＳのＷＰを単位として「詳細スケジュール」を作成。

スケジュールの種類は「バーチャート（ガントチャート）」と「ネットワーク図」などがある。

バーチャート（ガントチャート）

縦軸に作業、横軸に時間をとり、作業の期間を棒状に表した図表。最も広く使われている。

ネットワーク図

各作業に相互関係を付加したもので、作業Aが終わらないと作業Bが開始できないというような作業間の関係をもとにスケジュールを作成。

ネットワーク図には、ADMとPDMがある。

ADM（Arow Diagramming Method）

個々の作業を矢線（アロー）で表した図。ノードと呼ばれる点、２つの間の矢印そのものがタスクを示す。それぞれのノードには記号や番号をつけて、例えばB-Cと呼ぶ。ADMにはダミーアローと呼ばれ、順序の制約を表現するだけの矢印がある。

PDM（Precedence Diagramming Method）

作業をノード（箱）で示し、矢線で作業の相互関係を示す図。箱がタスクを表す。それぞれに記号や番号がつき、タスクBなどと呼び、矢印はこのタスク間の順序を表す。

ステークホルダーを確認し、対応策を練る

プロジェクトのステークホルダーとは、

プロジェクトから影響を受ける人。一般的に「利害関係者」という。

プロジェクトには多くのステークホルダーが関係するこを考慮せずにはプロジェクトを実行できません。ステークホルダーとプロジェクトには利害が相反することも多々ある。それぞれの利害やニーズを調整し、円滑にプロジェクトを遂行していくのがプロジェクトマネージャの重要な役割。

そのために必要なことは実行しようとするプロジェクトにはどのようなステークホルダーが存在するかを整理し、把握すること。それぞれのステークホルダーがどのようなニーズを持っているか、プロジェクトの実施や完成によりどのような影響を受けるかといった基本情報を理解すること。

この情報に基づいて利害の調整や適切な情報提供などをプロジェクト遂行期間を通じて常に行っていく必要がある。

プロジェクト成功にはステークホルダーがプロジェクトの目的、目標を理解共有することが大事。

ステークホルダーあってのプロジェクト
どんなニーズを持っているか把握することが大切

リスクを検討し、対応策を決める

プロジェクトには不確実性がある、リスクのマネジメントが不可欠。

リスクとは

これから遂行しようとするプロジェクトの目的に対して影響を与え、それによって引き起こされる結果と影響度のこと。

リスク＝ｆ（リスク事象、発生確率、インパクト）

リスクには「原因」と「結果」があって、例えば

原因

限られた人材、住民の許可を得る必要がある

結果

スケジュールの遅れ、品質・コストの影響

となり、その限られた人材の未知の仕事の能力や仕事量の変動がリスクになる。

プロジェクトに対する多くのリスクは管理可能といわれてます。リスクはプロジェクトの進行とともに変化しますので、リスクの検証はプロジェクトの最初だけでなく、プロジェクトの期間を通じて繰り返し行うことが必要。

一方、

危機管理＝事務処理

「大震災が発生したら、どう対応する」は危機管理

リスクマネジメント＝予防措置

「震災発生はどの程度か」「被害を最小にするために何をすべきか」はリスクマネジメント

用語：リスクの種類

• 統制の可能な「内部リスク」（要員の確保など）、不可能な「外的リスク」（天候など）
• 損失のみの「純粋リスク」（災害など）、利益の可能性がある「投機的リスク」（不動産投資など）

ステークホルダーとのコミュニケーション

プロジェクトの失敗の８０％はコミュニケーションに起因していると報告されてる。プロジェクトを進めていく中で余裕がなくなり、他人に配慮した情報の流し方を怠ることが大きな原因。この状況を直すのはなかなか大変で、一種の意識改革が必要。

コミュニケーションの内容は文書化することが大切、顔を合わせてのコミュニケーションは不可欠で「相手の話をよく聞くこと」が肝要。

実行予算を立て管理する

計画変更でコストの変動が起こる。そこでプロジェクトの予算作成時に変更・追加、あるいは不測の事態を想定して予備費（コンティンジェンシー）を設け、ある程度の追加コストが発生した場合でも対応できるようにする。当初、計画の変更を行うときは、変更に対する対応案を作成して、スケジュールなどへの影響、コスト要因などを検討し、変更の決定をする。

通常のプロジェクトでは、実行予算を設定、WBS項目ごとの予算と発生コストの乖離を確認し、業務を進めていく。乖離がある場合は、最終コストを予測し増額をしてもらうなどの折衝を行う。

用語：コンティンジェンシー（予備費）
プロジェクトの変更・追加、あるいは不備に備えて計上した費用。スケジュールにも用いる。

計画をまとめ、発注者への最終承認を得る

計画の最終の仕事として「計画書をまとめ」「発注者からの承認」をとる必要がある。

プロジェクト計画書は、

下記の項目に基づいて作成。

• プロジェクトの目的・目標
• チーム編成（プロジェクト組織）
• 実施項目（WBS）
• 役割分担表（誰が、何を）
• 工程表（ガントチャート）
• コミュニケーション計画（報告、連絡）
• ステークホルダー管理表
• リスク管理表
• 実行予算書
• 評価指標

この計画書をベースに進捗を管理し、課題の対応をしていく中心となる書類。

プロジェクトの実行は計画のようには進んでいきません。進捗の遅れ、問題の発生、予算の超過などさまざまな課題が発生する。そのような場合にプロジェクト計画書を基本にして、判断、対応を進めていく必要がある。そして、この計画書が発注者の請負契約書の一部となる。

チーム統率、プロジェクトのキックオフ

キックオフミーティングとは、

プロジェクトを開始していく際、メンバーと内容を共有するために開かれるミーティングこと。目的はプロジェクトに関わる全員がプロジェクトの目的や内容を理解し、進め方、役割分担を理解すること。

キックオフミーティングで初めて顔を合わせる人も多いため、チームの一体感を生み出す絶好の機会であり、プロジェクトのテーマなどを共有しておくことで、意識や理解度が高まる重要なミーティング。プロジェクトの全体像を可視化し、メンバーがミーティング終了後からゴールに向かって走り出せるようにすることが大事。

資料としては以下を注意。

• プロジェクトの基本概要および設計図
• 工程表（マイルストーンとクリティカル事項）
• プロジェクト体制（誰がリーダーで、誰が何を担当）
• 連絡体制（担当責任者との連絡手段を決める）

ミーティングでは参加者にわかりやすい説明が必要。

良いチーム作りは相手を理解すること。自己紹介を通じ、プロジェクトに関わる人たちの役割を把握してもらう貴重な機会。

キックオフミーティング後でも、プロジェクト進行中に迷いなどが生じた際、読めば原点回帰できるような資料の提供が必要。

進捗管理

計画と実績の差異の確認と対策

進捗報告書は、プロジェクトの現在の状況を記述するだけなく、今後、このプロジェクトがどうなるのかということを記述することが肝要。

1. 現在の状況はどのようなものか
2. 進捗度（出来高）はどうか
3. 今後はどうなるのか（対策と予測）

進捗報告と同時に、翌月（週）の作業計画および重要な変更の記録などを報告。リスクの発生、対応状況、問題点、解決策（解決予定日）などを加えることも。

進捗報告書は読んで理解しやすいということが重要ですので、報告の形式は図、表、グラフを用い、できるだけ視覚化して報告することが大切。

プロジェクトに関わるステークホルダーにとって、進捗報告書は変更などの意識決定のための資料。

問題点の解決

コンフリクトマネジメント

ステークホルダーにコンフリクトが発生した場合、コンフリクトを調整し、問題解決へ働きかけることをコンフリクトマネジメントという。

ステークホルダーの移行を事前に把握せず、合意をとっていない場合に、プロジェクトの途中でステークホルダーの意志によって変更などの新たなニーズが発生することがある。十分な説明をした場合においても、なかなか網羅的に考えることが難しく、プロジェクトが進むにしたがって新たな意見が生まれる場合も多々ある。この新たなニーズがプロジェクトの基本計画と相反する場合、プロジェクトマネージャーはコンフリクトを調整し、互いに納得した形で問題解決にあたらう必要がある。

満足のいく解決策を見つけるには、プロジェクトの現況、ニーズの優先度など考慮して判断する必要がある。ステークホルダー間での調整がうまくいかない場合、プルジェクトマネージャーとしてのコミュニケーションや説得力を十分に発揮することが求められる。プロジェクトマネージャーはコンフリクトが発生したと認識した場合、その対応を避けることなく、自らコンフリクトの真の問題点を見つけ出し、合理的な解決案を提示しながら両社の希望を最大限に生かし、問題の解決に向けて積極的に働きかけるという重要な役割を担ってる。

プロジェクトマネージャーは、相反するニーズ（コンフリクト）解決が重要な責務

• ステークホルダーのニーズの、どれを優先するのあｋ判断
• コミュニケーション力、説得力を発揮

用語：コンフリクト
意見や利害などが対立すること

変更要求

変更のないプロジェクトはない

プロジェクトの計画は、いったん決定したら、それに従って遂行するのが基本できるが、変更の生じないプロジェクトは存在しない。変更へは柔軟に対応することが重要。

変更要求があった場合、コストやスケジュールへの影響を把握して適切な対応をし、ベースラインからの変更となるのか、的確に認識するとともに、関係者と合意をとらなければなりません。変更は新たなリスクをもたらすケースもある。

変更の影響を確実に調整することが大事。関係者の周知徹底、確実な変更と確認は、プロジェクトのスムーズな遂行に欠くことはできません。

変更要求

• スコープ変更
• コスト変更
• スケジュール変更

影響度の確認が必要。

用語：ベースライン
プロジェクトの発注者から承認された成果物が満たすべき要件の基準

リスク対応

不測事態への対応

プロジェクトの進行によってリスクの発生確率は減少し、成功確率は上がっていく。しかし、新しいリスクの発生もあるので注意が必要。

リスクの兆候を監視し、リスクが生じた際の影響を低減させなければならない。プロジェクトに起きるリスクを監視することは重要な活動で、メンバーにリスク発生につながる兆候を把握できるような意識づけを行い、プロジェクトメンバーとの日頃のコミュニケーションのなかから不確実性の芽を摘み取ることも需要。

プロジェクトの終盤で不測の事態が発生した場合、納期、コストに大きな影響を与える。最善の対策をとったとしてもリカバリーの時間的な余裕がない場合が多く、納期の遅れやコストのオーバーを起こしてしまうことがある。プロジェクトの終盤であっても、リスクの監視を怠ってはいけません。

計画策定の際に受け入れると判断したリスクや識別できなかったリスクに対し、計画にない対応策を実施しなければならないことも起きる。このことを「迂回策の実施」という。迂回策の実施には、よりすばやいアクションが求められる。

発生したリスクに対応した結果として、プロジェクトのベースライン（スケジュール、コストなど）の変更があれば、確実に確認して計画を変更し、予定の姿に戻す必要がある。

用語：迂回策（Workaround）
プロジェクト遂行段階において、識別されていない、あるいは不都合なリスク事象を受容し、計画していない対応をとること

最終検査

プロジェクトの種類により、最終検査の内容、引き渡し方法は異なるが、その方法は契約書のなかの検収基準に明記されている。引き渡しにより、プロジェクト成果物の管理責任は発注者引き継がれる。天災などで損害が発生した場合は発注者が損失を被ることになるので、保険などの対応が必要となるケースもある。

完成図書の納品と引き渡し

プロジェクトが終了し、引き渡しの時に最終成果物についての図書を「完成図書」として納めまる。

また受注者は発注者へ納品する完成図書の作成もあるが、一般に自社のノウハウ蓄積のために電子化し、データベースにストックします。これらの完成図書のプロジェクト履歴を「ナレッジマネジメント」として利用。

電子化されたプロジェクト情報は今後のプロジェクトで活用しやすい方に編集し、施工ノウハウとして蓄積、プロジェクト実践の支援ツールとして利用する。

クローズアウト（終結）

プロジェクトの終結は成功で終わる場合だけでありません。資金不足により中断した作業、当初の目的が無意味になり、運用フェーズに移れない作業などにもプロジェクトのクローズアウト（終結）の手続きが必要。

プロジェクトのクローズアウトのための確認事項として

1. 要員の再配置：社内要員は次の業務への配置転換を行う。外部人材は契約を終了。
2. エンジニアリングの完了：納入物を完成図書としてファイリング。
3. 調達契約の完了：プロジェクトの全契約について検収を確認。また設計書などの成果物が納品されていることも確認。
4. 顧客の検収：請負で実施しているプロジェクトは成果物の提出を確認、顧客から検収を受ける。
5. 会計の完了：銀行口座や社内の会計コードなどの使用を終了。受注案件であれば売り上げの手続きを行う。
6. プロジェクト記録：スケジュールや進捗、コスト実績、プロジェクトのコミュニケーションの記録などを完成時の記録として残す。

クローズアウトは、レッスンズラーンド（Lessons & Learned）をまとめることが大切。次に役立つ経験を組織で共有するため。組織としては有効に活用できる仕組みづくりが重要。

用語：レッスンズラーンド（Lessons & Learned）
プロジェクトを実行する組織において、次のプロジェクトをさらにうまく実施するために残す教訓集。