［実行時の現状］実行 01 実行すれば見えてくる現実［チームとは］実行 02 チームとは何かを改めて考えてみる実行 03 目指すのはシナジーチーム［キックオフ］実行 04 プロジェクトチーム育成は「キックオフ」から始まる実行 05 キックオフミーティングのアジェンダ（議題）実行 06 ヴァーチャルプロジェクトチームのキックオフ実行 07 キックオフミーティングで避けるべきこと［チームの形成］実行 08 ワーキングアグリーメント（ Working Agreement）の重要性実行 09 チームの形成段階を知ろう実行 10 プロジェクトチームメンバーの「衝突」は当たり前？［メンバーへの説明］実行 11 作業内容や関連する情報をメンバーに説明しよう実行 12 しっかりと情報を伝えるための基本 ①─発信情報の確認─実行 13 しっかりと情報を伝えるための基本 ②─良好な関係と環境─［コントロール］実行 14 プロジェクトのコントロール［進捗確認］
実行 15 進捗確認とは？─過去と未来を見るのが進捗確認─実行 16 進捗確認のための情報収集［情報収集］実行 17 情報収集は「定量情報」と「定性情報」を収集する実行 18 情報分析と未来予測［計画と実績のギャップ対策］実行 19 是正措置と予防処置［変更要求］実行 20 変更要求とは？実行 21 変更要求の決裁実行 22 変更要求は最初が肝心実行 23 変更要求時にもバランスの観点が必要実行 24 変更履歴をしっかりと保管・保存しよう［進捗確認の優先度］実行 25 クリティカルパス上の進捗確認は徹底的に［レポーティング］実行 26 レポーティングの基本実行 27 進捗報告で最低限押さえておくべきこと ①─内容─実行 28 進捗報告で最低限押さえておくべきこと ②─構成─実行 29 進捗報告で最低限押さえておくべきこと ③─頻度─実行 30 緊急時のレポーティング［ステークホルダー管理］実行 31 ステークホルダー管理のポイント実行 32 中立かつ冷静な立場でステークホルダー管理をする［マイルストーンでの判断］実行 33 マイルストーンで実施すべき３つの判断［プロジェクト終結］実行 34 プロジェクトの終結実行 35 プロジェクト終結報告書実行 36 プロジェクト終結ミーティング［まとめ］実行 37 【実行】のまとめ
［実行時の現状］実行 01実行すれば見えてくる現実 プロジェクトマネジメント計画書が完成し、いよいよプロジェクトの実行となります。残念ながら、プロジェクトの実行中は計画通りに事が進むことはほとんどありません。 コストオーバー、スケジュール遅延、スコープの突然の追加や変更、プロジェクトチームメンバー間の衝突（コンフリクト）、リスクの発生、マイルストーンでの成果物の品質問題の発生及びそれによる作業のやり直し、コミュニケーションエラーによる意思疎通問題など、様々な課題や問題が発生し、計画通りのプロジェクト進行を阻害します。 プロジェクトの実行中にプロジェクトマネージャはその役割名通り、プロジェクトを「やりくり」し、計画通りにプロジェクトを進行させる努力をしたり、または合理的な理由のもとで計画の微修正や変更をしていきます。 この「やりくり」の際、プロジェクトマネージャには、リーダーシップ、推進力、交渉力、コミュニケーション力、プレゼンテーション力、合理的思考、論理的思考、戦略的思考、分析力など、様々な「人間力」が必要になってきます。 第 １章【基本】で、プロジェクトマネージャにはプロジェクトマネジメントの知識や技術以外にも経験や人間性が必要だとお伝えしましたが、プロジェクトの実行中はまさにこれらが生きる部分です。 プロジェクトの実行に必要な知識や技術、経験や人間性は多岐にわたります。本書では「実践」をテーマにしているため、引き続きプロジェクトの実行で最低限知っておくべき内容を紹介していきます。［チームとは］実行 02チームとは何かを改めて考えてみる プロジェクトは、プロジェクトチームメンバーと力を合わせて進めていきます。「チーム」という言葉をよく使いますが、「チーム」とは一体何でしょうか？ 人が集まっただけでチームなのでしょうか？ 人が複数いる状態を表す言葉は他にも「群衆」「集団（グループ）」などがあります。これらと「チーム」は何が違うのでしょうか？ 皆さんは「サッカーグループ」や「野球グループ」とは呼ばず、「サッカーチーム」や「野球チーム」というと思います。なぜ「チーム」と呼ぶのでしょうか？ 良い機会ですので数分間「チームって何だろう？」と考え、自分なりの答えを出してみてください。 チームの特徴は様々ありますが、目的や目標が共有され、その目的や目標の達成を目指している人間の集まりであることがまず挙げられます。次に、その目的や目標を達成するために、各チームメンバー自らの役割が明確で、お互いの強みを生かし参画し貢献しようとしています。また、チームメンバーがお互いに信頼し、相互補完し合っている状態です。 先ほどの群衆や集団（グループ）は、目的・目標の有無にかかわらず、複数の人間が集まっている状態です。プロジェクトではプロジェクト「チーム」メンバーと活動していきます。 そのために、プロジェクトマネージャは「チーム」を作り育成していかなければなりません。これを一般的に「チームビルディング」といいます。 もっと簡単にいえば、プロジェクトの目的・目標を共有する前の「集団」の状態から、目的・目標の共有されている状態、各自が強みを活かし、相互補完し合い、相互に信頼している環境などを生み出していくことが求められます。
［チームとは］実行 03目指すのはシナジーチーム プロジェクトチームのチームビルディングの目指すべきところはどこでしょうか？ それは生産的なチームであり一般的に「シナジーチーム」と呼ばれることがあります。 シナジーチームは目的・目標を目指す挑戦力、そのために必要な提案力や実行力、各チームメンバーのチームへの貢献度、協力度、各チームメンバーへの相互信頼が極めて高い状態です。 さらに簡単にいえば、「次に自分はチームのために何をすべきか」を自身で考え動く状態です。各プロジェクトチームメンバー自身のスキルが高いだけではなく、お互いが相互補完関係になり、チームとして高い生産性を生み出している状態です。 プロジェクトマネージャは、理想的なシナジーチームを構築するために、常にプロジェクト実行中に「何ができるか」を考えていく必要があります。 プロジェクトチームの状態は常に変化します。プロジェクトチームを結成した直後はチームメンバー同士がお互いのことを理解していない状態です。この状態をどう相互理解の状態に持っていくのかを考える必要があります。 さらに、相互理解が深まると、お互いの思考の違い、文化・風習の違いなどで衝突（コンフリクト）が起きるかもしれません。そのコンフリクトをどう調整し、プロジェクトチームとしての文化・風習を構築し、お互いの信頼関係に結びつけるかを考える必要があります。 チームメンバー各自の協力度、貢献度を高めるにはどうしたらいいのか、そして、それらが高まった時にどう維持するのがよいのかなど、状況により変化するプロジェクトチームの状態を把握し、チーム力を高める活動を常にしていかなければなりません。［キックオフ］実行 04プロジェクトチーム育成は「キックオフ」から始まる 「キックオフ」とはサッカーなどでの試合開始ですが、プロジェクトの実行開始を意味したビジネスミーティングとして「キックオフミーティング」と呼ばれる会議体があります。 キックオフミーティングは、一般的にプロジェクトの目的・目標、スケジュールやコスト、プロジェクト体制やチームメンバーの紹介、プロジェクトマネジメント手法やレポーティング手法、コミュニケーション手法などのプロジェクトの概要の共有やメンバーの不安を軽減させる質疑応答などで構成された極めて重要な会議になります。 したがって、基本的にプロジェクトの関係者が全員集まりキックオフミーティングを実施することが望ましいのです。 キックオフミーティングの本質的な目的は、大きく分けて３つあるといっていいでしょう。 それらは、プロジェクトに関する基本的情報、重要な情報を共有し理解すること、プロジェクトの目的・目標を達成する意識を高めること、そして、プロジェクトに関係する人たちの相互理解とコミュニケーションのきっかけを生み出すことです。 プロジェクトチームにとっては「チーム」であるための目的・目標の共有、そしてその達成のためのチームメンバー間の相互理解となる第一歩がキックオフミーティングなのです。 キックオフミーティングをリードするのは、一般的にプロジェクトマネージャです。キックオフミーティングの重要性をプロジェクト関係者に説き、全員が参加できるよう調整し、キックオフミーティングの目的を達成すべくミーティングをリードします。
［キックオフ］実行 05キックオフミーティングのアジェンダ（議題） キックオフミーティングの進行内容やアジェンダ（議題）は企業や組織、プロジェクトによっても様々です。しかし、プロジェクトの成功のためにこれだけは必ずやっておくべき内容を以下に紹介します。 ■ １．プロジェクトマネージャの自己紹介 キックオフミーティングをプロジェクトマネージャが進行するにあたり、自己紹介を行いましょう。「この人の話を聞いてみたい」と思わせるような自分自身のキャラクターを生かした魅力的な自己紹介ができることが望ましいです。 自己紹介から関係者を引きつけることができれば、キックオフミーティングの内容を聞いてもらえすますし、内容の理解も深まります。 さらに、プロジェクトチームメンバーに「今後この人と仕事をしたい」と思ってもらえれば、リーダーシップの第一歩にもなります。 ■ ２．プロジェクト概要説明 プロジェクト憲章やプロジェクトマネジメント計画書の内容をコンパクトにまとめたプロジェクトの概要を共有しましょう。目的や目標、スケジュールやコスト、体制やメンバー、プロジェクトマネジメント手法など基本的な内容や重要な情報を共有します。 特に、このプロジェクトがなぜ必要なのか、その意義は何かなど、プロジェクトの重要性について説くことが大切です。プロジェクトチームメンバーに対しては、基本的情報や重要情報を理解するだけではなく、チームメンバーが「このプロジェクトをやりたい」とモチベーションが高まるような概要説明が望ましいです。 プロジェクト憲章やプロジェクトマネジメント計画書を印刷し、それらを読み合わせるようなキックオフもありますが、関係者のプロジェクトへのモチベーションを高める目的で、プロジェクト概要をプレゼンテーション資料にまとめてプロジェクトマネージャがプレゼンしたり、一部を動画にしてプレゼンしたりするなどの方法もあります。 ■ ３．プロジェクトチームや関係者の自己紹介 キックオフミーティングでは主要ステークホルダーやプロジェクトチームメンバーなどプロジェクトの関係者が一堂に会します。今後の関係者のコミュニケーションの活性化や良好な関係構築の第一歩として、それぞれの人がどのような人なのかを各自が表現できる時間を持ちましょう。 また、プロジェクトチームメンバーの自己紹介時には、プロジェクトマネージャが各プロジェクトチームメンバーの「役割」「プロジェクトに呼ばれた理由」「個別の期待」「プロジェクト活動と個人の成長との関連付け」などを説明し、プロジェクトチームメンバーのモチベーションを高めましょう。 例えば、チームメンバーの Ａさんは通信販売の注文管理システムの担当だったとします。 Ａさんの自己紹介が終わったら「皆さん、 Ａさんは以前の〇〇というプロジェクトで注文管理システムを構築し素晴らしい実績をあげました。その経験と技術に大いに期待しています。今回は以前の注文管理システムに〇〇という新しい技術を入れることが求められています。今回のプロジェクトを通じて Aさんの知識や技術はさらにアップすることでしょう。 Ａさん、一緒に頑張りましょう」というようなことをしっかりと伝えましょう。 ■ ４．質疑応答 質疑応答の時間を設けましょう。理由は複数ありますが、まず重要なことは、プロジェクト概要がしっかりと伝わったかを確認するためです。グローバルプロジェクトなどでは、この質疑応答で各自が不明な点を積極的に確認する場になります。 しかし、プロジェクトによっては「プロジェクトの概要で不明な点はありますか？」と聞いてもシーンとし、誰も発言しないことがあります。 そういった場合はプロジェクトマネージャが相手の理解度を確認するために関係者、特にプロジェクトチームメンバーを指名して確認することもあります。 例えば「プロジェクトのビジネスニーズは〇〇ですが、このビジネスニーズについて感じたことはありますか？」や「〇〇さんの担当する成果物の WEBサイトの要求事項は〇〇や〇〇ですが、〇〇さんの経験上、これに近しい WEBサイトの事例などがあれば教えてください」など相手が話すきっかけを与え、その回答から理解度を確認していくなどです。これもファシリテーションのひとつです。 すでに述べたように、キックオフの目的は情報共有やその理解、プロジェクトへの意識を高めることや関係者との相互理解やコミュニケーションのきっかけを生み出すことでした。これらを実現するために情報共有が必要なものがあればアジェンダに組み込みましょう。 また、意識を高め、チームメンバーや関係者間の相互理解やコミュニケーションを活性化させる目的で、「ワークショップ」をアジェンダに組み込む場合があります。 「ワークショップ」とは、何かひとつのお題や目標を明示し、それを皆で協働しながら進める場です。ひとつのことに対して協働することで、お互いコミュニケーションが生まれ、またお互いをより理解することが可能になります。［キックオフ］実行 06ヴァーチャルプロジェクトチームのキックオフ 最近よく聞かれることが、プロジェクトチームメンバーが各拠点などの遠隔地などにいる場合、キックオフミーティングはどうすべきかということです。 ICT技術が発達し、あらゆるコミュニケーションツールを活用し、遠隔地間でプロジェクトを進めていくヴァーチャルプロジェクトチームも増えてきました。 しかし、結論からいうと、キックオフミーティングは対面で実施したほうがよいことには変わりありません。対面だからこそ、相手の表情や反応から理解度を把握できたり、お互いの人間性の理解が進んだりします。 また、同じ時間を一緒に共有することでプロジェクトに対する意識も高まります（テレビ会議や電話会議で他のお仕事の「内職」をすることもなく……）。特にプロジェクトチームメンバーについては、キックオフミーティングで情報共有が適切になされ、プロジェクトの意識が高まり、相互理解が進めば、チームの生産性が高まることが期待できます。 キックオフミーティングのような最初の重要なミーティングだからこそ、最初は対面が望ましいのです。しかし、グローバルプロジェクトなどで国境を超える場合やコスト的に対面が難しい場合、極力テレビ会議などでお互いの顔が見える状況でキックオフを行いましょう。 さらに、少なくとも各国の拠点で相互理解を高める目的で、各国の拠点にそれぞれが集まり、テレビ会議で結ぶことが重要です。 逆にいえば、個々人が個別のパソコンなどでテレビ会議にアクセスする場合、関係者間の相互理解が進まない恐れがあります。
プロジェクトマネージャは、すでに述べたキックオフの目的をしっかりと理解し、ヴァーチャルプロジェクトであっても最良の手法を考えキックオフミーティングを計画、実施していきましょう。［キックオフ］実行 07キックオフミーティングで避けるべきこと ここまでキックオフミーティングの重要性や実施すべきことを紹介してきました。今度は逆にキックオフミーティングで避けるべきことをお伝えしようと思います。 すでに紹介したキックオフミーティングの目的の中に、参加者の「プロジェクトの目的・目標を達成する意識を高める」がありました。キックオフミーティングでは意識を低下させる言動や行動などは避けるべきです。 プロジェクトチームメンバーはこれから目的・目標達成のために尽力していきます。プロジェクトの実行前にメンバーは不安なものです。だからこそ意識を高め、モチベーションを高める必要があります。 キックオフミーティングでやりがちなこととして「プロジェクトメンバーに対する個別のアクティビティの詳細まで厳格に説明してしまう」ということがあります。 例えば、「 Aさんは Xというアクティビティを〇月〇日までに完成させてください。次に…。今回のプロジェクトではスケジュール遅延が一切許されないため、毎日報告をしていただきます」とキックオフミーティングでいわれたらどうでしょうか。多くの関係者の前でいわれることでプレッシャーを感じてしまうかもしれません。 さらに、初回から細かいことを要求され嫌な思いをする、または不安が増幅するかもしれません。また、周りの関係者も細かい話は私には関係ないので個別でやってくださいと感じ、しらけるかもしれません。 個別に対する詳細な話は、個別または関連するチームメンバーとともに別途時間を設けて実施しましょう。 プロジェクトマネージャはキックオフミーティングをリードしていく上で、意識が下がる、モチベーションが下がることを避け、キックオフミーティングの目的を最大限達成できるよう努力しましょう。［チームの形成］実行 08ワーキングアグリーメント（ Working Agreement）の重要性 プロジェクトチームの育成やチームビルディングを醸成するひとつの方法として「ワーキングアグリーメント」があります。ワーキングアグリーメントとは簡単にいえば「働き方の合意」であり、またはこれらをまとめた文書になります。 キックオフミーティングの後にプロジェクトマネージャとプロジェクトチームメンバーが集まり作成したり、キックオフのワークショップなどで作成したりします。 合意される内容は、「課題が発生した時点で全チームメンバーに共有する」というようなルールのようなものであったり、「ポジティブな発言をする」「嘘はつかない」などの行動基準だったり様々です。 ここで重要なことは、目的・目標達成のために「チーム」としてどうあるべきか、どうするべきかを「チーム」として考え、「チーム」として合意し約束すること、またその合意までの過程を共有することです。これにより、チームの一体感が醸成されていきます。 プロジェクトのルールがプロジェクトマネージャにより詳細にわたって決められ、指示・命令・管理されたら、プロジェクトチームメンバーはどう思うでしょうか。そのルールなどの合理的な理由がしっかりと理解されない限り、プロジェクトチームメンバーの意識の低下やモチベーション低下につながる可能性があります。さらに、プロジェクトチームメンバーがルールに同意・合意しなければルールは守られない可能性もあります。 確かに、プロジェクトでは守らなければならないプロセスや手法が多くあります。しかし、その中でもチームメンバーの裁量で決められるものがあれば、チームビルディングのひとつ
ひとつの手法としてワーキングアグリーメントを活用することが望ましいのです。なお、ワーキングアグリーメントは定期的にアップデートすることが望まれます。［チームの形成］実行 09チームの形成段階を知ろう 皆さんは Bruce Wayne Tuckman氏が提唱した Tuckman’ s stages of group development（ 1965, Bruce Wayne Tuckman）をご存じでしょうか。日本では一般的に「タックマンモデル」や「チームの形成段階」のモデルとして知られています。 話を単純化すると、このモデルでは、先ほど紹介したシナジーチームになるために、チームは Forming（成立期）、 Storming（動乱期）、 Norming（安定期）、 Performing（遂行期）という段階を経ることを我々に伝えています。 チームが形成されると、まずは「成立期」になります。簡単にいえば、チームメンバーが顔合わせの段階であり、個々がまだ独立していて自らの習慣や行動から抜け出せていない状況です。お互いがどこかよそよそしく、相手がどういう人なのかを探っている状況です。 そのチームメンバーが目的・目標達成のために一緒に行動します。「動乱期」は、メンバー各自が独自の仕事のやり方、習慣、行動から抜け出せておらず、他のメンバーに対して自分の「やり方」を主張し衝突が起きやすい時期です。 衝突を経て、メンバーの相互理解がさらに進むことにより、メンバー自らの習慣や行動が変化しはじめ、チームとして一緒に活動しはじめます。これが「安定期」です。さらに相互理解が進み、メンバーが相互補完関係となり、相互依存状態となると、チームは生産的な状態になり「遂行期」を迎えます。 このチームの形成段階について、プロジェクトを経験した皆さんは「当てはまる」と思うことが多々あるかもしれません。仕事以外でも、学校生活やクラブ活動を思い出してみてください。チームはこうやって成長するというひとつのモデルとして覚えておくことをお勧めします。［チームの形成］実行 10プロジェクトチームメンバーの「衝突」は当たり前？ プロジェクトマネージャがプロジェクトチームの育成をリードする上で、既述のタックマンモデル、チームの形成段階を知っていると知らないでは大きな違いがあります。 なぜなら、現在のプロジェクトチームの段階がどのレベルにあるのか、それに対してどうチームの育成のためにアプローチすればいいのかのアイデアが得られるからです。 例えば、形成段階ではお互いを知るためにはどうすればいいのか、動乱期にはお互いを理解させるためにはどうすればいいのか、安定期にはさらなる相互理解を深め相互依存状態、相互補完関係にするにはどうすればいいのか、などの打ち手が考えられます。 これらの打ち手を講じプロジェクトチームはシナジーチームに成長していきます。 数多くのプロジェクトの実行支援や教育研修を行っていると、プロジェクトチームメンバー間やチームメンバーとプロジェクトマネージャとの衝突に悩まされていることが多いと感じます。また動乱期の状態に心を痛めているプロジェクトマネージャもいます。タックマンモデル、チームの形成段階を知っていることで、これらの衝突に対し客観的な視点で物事を考えられます。 例えば、今は動乱期だから自分はチームメンバーの相互理解を進めるためにどうすればいいのかを考えよう、などとなります。また、ポジティブに考えれば、動乱期がなければ次の安定期や遂行期には到達できないので、動乱期は成長している証だ、と考えることもできます。 衝突は当たり前と、客観的に捉え、冷静に対処することが、プロジェクトマネージャが心身ともに冷静になるひとつ
であることをお伝えしておきます。［メンバーへの説明］実行 11作業内容や関連する情報をメンバーに説明しよう キックオフミーティングが終了したら、プロジェクトマネージャはプロジェクトチームメンバーに対して、個別に担当する作業の詳細や関連する情報を説明しましょう。 現在まで作成したプロジェクト憲章やプロジェクトマネジメント計画書類を用いて、各メンバーが担当する成果物や要素成果物（ワークパッケージ）、アクティビティの詳細情報、それぞれの要求事項、コストやスケジュール、関連するリスク、自分が担当するアクティビティの前後にある他担当のアクティビティ情報などを説明します。 また、プロジェクトマネージャがどのようにプロジェクトマネジメントをするのか、例えばどのようにどの頻度で進捗確認をするのか、会議体や情報共有、報告をどうするのかなどを説明します。 メンバーに対して個別の作業内容や関連する情報を伝えるのは大変な作業です。しかし、作業内容や成果物、要素成果物のイメージがメンバーとしっかり共有できるまで伝えることがプロジェクトの成功に結びつきます。 本書の第 ２章【目標設定】で「ロホホラゲーム」（「目標設定 07 ゴールから考える重要性 ④」）をやったのを覚えていると思います。イメージがしっかりと共有されていないと、意図しない作業結果や成果物、要素成果物のアウトプットが出てきてしまいます。 作業内容や関連する情報を伝えても、後日、メンバーの中で不明点、不安点が出てくるかもしれません。その時のために、プロジェクトマネージャは不明点や不安点があればいつでも連絡してほしい旨をしっかりと伝え、不明点や不安点があるままでメンバーが作業を進めないようにしましょう。また、メンバーに対して「いつでも相談して大丈夫」という安心感を与えましょう。［メンバーへの説明］実行 12しっかりと情報を伝えるための基本 ①─発信情報の確認─ 作業内容のメンバーへの伝達に限らず、プロジェクトマネージャは自らが発信した情報を、相手がしっかりと理解したかを確認する必要があります。 コミュニケーションの基本として「情報の発信者は発信した情報の責任者」という概念があります。つまり、発信した情報が相手にしっかりと伝わったかの責任は情報発信者にあるのです。 したがって、情報発信者は、情報伝達相手の返答、表情、行動などを確認し、しっかりと情報が伝わったかを確認する必要があります。特にグローバルプロジェクトなどでは異文化コミュニケーションが基本となるため、コミュニケーションの難易度が高くなります。 しっかりと情報が伝達できたかを確認するため、相手に対して情報のフィードバックをもらい確認することもあります。例えば、相手に対して伝えた内容の要約をフィードバックとしていってもらったり、またはしっかりと理解したかを確認する質問を情報伝達相手にして適切な回答がフィードバックとして得られるか、を確認したりします。 例えば「今日のミーティングはこれで終わりましょう。最後に、確認のために今日伝えたことの概要をまとめて私に伝えていただけますか？」や「アクティビティ 10301のスケジュールの期日は〇月〇日で期間は 14日間ですが、どのような順序で作業を進めますか？」などです。 面倒なように思えますが発信した情報がしっかりと伝達できたかの確認をしないことで、その後のプロジェクトに大きな影響を与える場合があります。
後々になって「〇〇はそういう意味だったんですか？」「そんなこと聞いていませんよ……」などになると、プロジェクトの遅延や要求事項と異なる結果が出てきたりしてしまい、作業のやり直しや工数増などが発生します。それが積み重なることでプロジェクトの成功に影響を与えるのです。［メンバーへの説明］実行 13しっかりと情報を伝えるための基本 ②─良好な関係と環境─ 発信する情報がしっかりと伝達相手に伝わったかを確認する以外にも、適切に情報を伝達するために、伝達相手との良好な関係性を築いておくことが重要です。 例えば、皆さんも経験があるかもしれませんが「この人ちょっと苦手だな……」と感じている人と話していると、コミュニケーションに集中できず、情報が入ってこない場合があるでしょう。または「この人は信頼できないから」と思う人の言葉を純粋に聞くでしょうか。 このように人と人との「関係性」は情報伝達に影響します。話を単純化させると関係性が悪い場合、発信する情報が歪曲して相手に伝わる可能性もあります。 例えばいつも叱ってくる上司から「期日は〇月〇日です」と情報が発信されたとします。上司は単純に「期日は〇月〇日」という情報の事実を伝えたいだけだったとします。しかし、過去からの悪い関係性から情報の伝達相手は「私が期日に作業が終了しないと思っているからいっているんだ……」と感情的に情報が歪曲して伝わってしまう可能性があるのです。 良好な関係で情報を伝えるためには「環境」も重要です。例えば、打合せの際、情報の発信者がしかめ面で横柄な態度だったら、または暗い感じの環境だったら相手の情報を聞こうとするでしょうか。ポジティブで明るく何でもいい合える環境でしっかりと情報を伝えましょう。 環境でさらにお伝えすると、例えばガヤガヤと騒音がある場所では情報伝達がしにくいものです。静かな会議室で打合せするなど、物理的環境も考慮し適切な情報伝達ができるようにしましょう。［コントロール］実行 14プロジェクトのコントロール プロジェクトが実行された後、プロジェクトマネージャが実施する重要な活動として、プロジェクトの「コントロール」があります。 ISO 21500: 2012では、コントロールのプロセスについて「プロジェクト計画に照らしてプロジェクトのパフォーマンスを監視し、測定し、コントロールするために用いる。その結果、プロジェクトの目的を達成するために必要なときは、予防及び是正措置をとり、変更要求を行うことがある。」（ ISO 21500: 2012）と記載があります。 プロジェクトマネージャはプロジェクトが計画通りに進んでいるかについて、そのパフォーマンスを監視（モニタリング）し、測定する必要があります。 測定した際に、計画と実績の差が発見されます。この差に対して、計画通りに進むよう是正措置を講じたり、計画通り進むように予防する措置を講じたりしていきます。計画通りに進むよう努力しても目的や目標達成に影響があると判断される場合は計画などの変更を検討したりします。 非常に簡単な例を挙げると、例えば複数人数で山の頂上を目指し登山をしている時、計画通り登山が進行しているのか、それぞれの測定地点での到達時刻、疲労度、食糧や備品の消費率などを測定し把握します。そして、その計画と実績の差を分析し、計画通り山頂に行けるのかを考えます。 このままでは計画通り行けないと予測される場合、計画通りに行く是正措置がとれるのか、計画を変更するのか、未来にさらなる計画変更や是正措置を講じることなく計画通りに進めるための予防処置はあるのか、を検討し対応するようなイメージです。 本書では引き続き実践的な最低限必要な知識と技術について紹介していきます。プロジェクトのコントロールは「進捗確認」から始まります。次の項目から見ていきましょう。
［進捗確認］実行 15進捗確認とは？─過去と未来を見るのが進捗確認─ プロジェクトの現場で「進捗」という言葉を聞いたことがあるでしょう。進捗とは「物事の進みはかどること」という意味です。 プロジェクトではあらゆる成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）が計画されていますから、これらが計画通り進んでいるかを確認することが「進捗確認」です。 進捗確認というと、ガントチャートなどのスケジュール確認を思い浮かべるかもしれませんが、それだけではありません。スコープ、資源、スケジュール、コスト、リスク、品質などあらゆる計画に対して、進捗を確認します。 進捗確認で重要なことは ３点あります。 ①過去の実績を測定すること、 ②計画と実績の差を分析すること、 ③未来にどうなるかを予測すること、です。 進捗確認というと ①のみを思い浮かべますが、進捗確認で重要な視点は、 ③をするために ①と ②をするという視点です。 プロジェクトには目的・目標や定められた計画があります。プロジェクトでは、あらゆる計画の達成度合いが未来の目的・目標達成にどう影響するのかを把握し、目的・目標に影響する場合はそれを対処しながらプロジェクトを進めていく必要があります。 簡単なイメージをお伝えしましょう。例えば、皆さんが自動車で高速道路を走っていたとします。そこで大渋滞にはまってしまいました。今回は ２時間かけて走り 12時に目的地に到着する計画だったとします。 現在までの運転時間や走行距離を測定することが ①、現在の時刻や走行距離などをもとに計画と実績の差を分析することが ②、渋滞情報やナビの情報を収集し目的地到着時刻や最終的な運転時間を予測することが ③、というようなイメージです。［進捗確認］実行 16進捗確認のための情報収集 進捗確認の最初は「情報収集」です。プロジェクトマネージャは定期的にプロジェクトチームメンバーから、計画に対するあらゆる実績データや現状の課題、今後の見通しなどの情報を収集します。 この「定期的」というのはどれぐらいの頻度かを聞かれることがありますが、この後に述べるプロジェクトの「レポーティング」の頻度や、あらかじめスコープ記述書やコミュニケーションに関する計画書などで設定されている頻度に合わせて情報収集する必要があります。 情報収集の方法は、プロジェクトや企業、組織によって異なります。会議や電話での対話、メールによる報告、プロジェクトマネジメントツール（システムなど）に直接実績データを入力して報告するなど様々です。 確認内容はスコープ、資源、スケジュール、コスト、リスク、品質など多岐にわたりますが、具体的には、本書で紹介したガントチャートの進捗率はどうなのか、コスト管理表で明確にした計画に対して実績はどうなっているのか、リスク計画書に明示されているリスク対応策の実行はできているのかどうか、などです。 その他にも、スコープ記述書の要求事項通りになっているかどうか、プロジェクト憲章などに記載されている人的資源はしっかりと配置されているかどうか、稼働時間はどうかなどを把握します。 プロジェクトが大きくなり複雑になるにつれて膨大な情報がプロジェクトマネージャに集まります。情報が膨大になるにつれて情報収集を PMO（ Project Management Office、第 １章「基本 12 プロジェクトを支える様々な役割」参照）やプロジェクト事務（ Project Office）の担当がサポートする場合がありますが、こういった場合でもプロジェクトマネージャ
マネージャは情報を確認する必要があります。 また、データだけでは状況が完全に把握できない場合やデータから異常や異変を把握する場合もあります。その場合は直接対話をして確認することが望ましいです。［情報収集］実行 17情報収集は「定量情報」と「定性情報」を収集する 進捗確認のための実績情報は定量的な情報であることが望ましいです。プロジェクト計画の多くは見えないものを数値で可視化させますので、その特性を生かして実績情報も定量的に収集し、計画と実績を定量的に分析できる準備をしておきましょう。 例えばプロジェクトチームメンバーに「 30203の『申込』の進捗を教えてください」と確認した際に、「 30203は『いい感じ』に進んでいます」と報告を受けるのではなく、「 30203は現在 50%です」と事前に取り決めた進捗率に関するルールで定量的に報告されれば、実績確認の精度が違います。 これは笑い話ではなく、実際のプロジェクト現場でも発生する事象です。「ぼちぼちです」「うまい感じで進んでいます」「ヤバイです」「まずまずです」「比較的よいです」など、個人の感性が基準となる実績情報はこの後の分析や未来の予測に悪い影響を及ぼします。 プロジェクトでの実績情報の収集イメージは、例えば、プロジェクトチームメンバーが 100段ある階段を上っていて、「今、どこまで上りましたか？」という質問に対し「真ん中ぐらいですかね？」という回答ではなく、「 100段あるうちの 52段目で残りは 48段です」といった定量的情報の収集が基本です。 ただし、現実のプロジェクトでは定性的な情報も必要になります。 多くの場合、定量的な情報が「なぜそうなったのか」という情報は定性的な情報です。例えば、確認日までに進捗率が 75％の計画に対し、 50％の実績であった場合に、その理由がメンバーの体調不良、お客様からの問い合わせ対応、機器の故障などの事象などです。これらの情報も今後の分析や予測を立てるために重要な情報です。 したがって、情報収集は定量的な情報収集を基本に、付帯する定性的な情報収集も行っていく必要があります。［情報収集］実行 18情報分析と未来予測 進捗確認のための実績情報が収集できたら、情報の分析と未来の予測を立てていきましょう。情報の分析と未来予測と聞くと、重い話に聞こえるかもしれませんが、本書は「実践」をテーマにしていますので、シンプルに最低限習得すべき知識と技術を伝えます。 情報の分析の始まりは、あらゆる計画の基準と実績データの「差」を把握することです。これを「ギャップ分析」などということもあります。この差についても基本的には定量的な分析であることが望まれます。 例えば、簡単な例として、「アクティビティ Aは計画より 2日遅延している」「〇〇のコストは計画より 30万円多く支出している」などです。 次に、このままプロジェクトを実行した場合に未来はどうなるかを予測します。 例えば簡単な例として、「アクティビティ Ａは進捗率 50％の段階で ２日遅延しているため、アクティビティの完了日は ４日遅延する可能性がある」「〇〇のコストは計画より 30万円多く支出しているが、主な増加コストは人件費からくるものであり、現在の稼働時間が同水準のままプロジェクトが進むことにより、プロジェクト終了までに 300万円の増加コストが予測される」などです。 なお、計画よりも「前倒し」や「少ない」ということも危険な信号として認知しておく必要もあります。例えば、計画よりもコスト支出が少ない実績が得られた場合、もしかしたら資源の調達や、スケジュール遅延が発生しているからコストが支出されていない可能性があります。 また、スケジュールが前倒しの場合、メンバーが頑張りすぎ
すぎていてコストが上がる、新しいリスクがあるなどの可能性もあります。 計画との差の上下をしっかり見て分析、予測しましょう。［計画と実績のギャップ対策］実行 19是正措置と予防処置 計画と実績の差を把握し、分析し、未来の予測ができたら、次は、それに対してどう対処するかを考えます。計画と実績の差をそのままにしておくことは、プロジェクトの目的・目標の達成に影響を与える可能性を高めます。 是正措置とは「作業パフォーマンスを計画に合致させるための、作業パフォーマンスを修正する指示及びアクティビティ」（ ISO 21500: 2012）です。 簡単にいえば、是正措置は計画と実績の差があった場合に、計画通りに進めさせるための施策立案、指示、活動です。 この是正措置の中でもプロジェクト憲章やプロジェクトマネジメント計画書の計画を変更しなければならない施策があります。その場合は、次項目で紹介する「変更要求」に関連してきます。 予防処置とは「計画とパフォーマンスの潜在的な逸脱を回避あるいは低減する目的で作業を修正するための指揮及びアクティビティ」（ ISO 21500: 2012）です。 例えば、特定のアクティビティの計画と実績の差を生み出す要因が、他のアクティビティでも計画と実績の差を生み出す可能性がある場合、予防処置を講じ、今後の計画と実績の差の発生を予防します。 予防処置の中でもプロジェクト憲章やプロジェクトマネジメント計画書の計画を変更しなければならない施策があります。その場合は、次項目で紹介する「変更要求」に関連してきます。［変更要求］実行 20変更要求とは？ スコープ、資源、スケジュール、コスト、リスク、品質などの進捗確認を経て、是正措置や予防処置が必要、かつプロジェクト憲章やプロジェクトマネジメント計画書の計画を変更しなければならない施策の場合、「変更要求（ Change Request）」をまとめていきます。 また、計画と現実の差の分析によっては、目的や目標、計画の微修正や修正自体が必要な場合もあります。この場合も「変更要求」をまとめていきます。 これら様々な変更要求は「変更登録簿」に記録していきます。 なお、変更登録簿の内容は、この後に説明する変更内容の決裁者との会議などで議論されます。したがって変更要求は単なる「要求」だけではいけません。 各変更の変更は何なのか、なぜ変更が必要なのか、変更範囲はどこまでか、各変更をする理由や変更しなかった場合の影響とは何か、各変更を実施した場合の便益（ベネフィット）は何か、資源・タイム・コスト・リスクなどの影響はどうなのか、などの情報を最低限入れましょう。 また、課題に対する変更要求が複数パターンある場合は、それらを全て明示し、決裁者に決裁を求められるようにしておく必要があります。 もしも皆さんが決裁者の立場になったらと考えてみてください。例えば、「 Aという課題が発生し、それにより Ｂという是正措置を実施したいです」と承認を求められたとします。 その時に、なぜその課題が起きたの？ なぜ Ｂでなければいけないの？ Ｂを実施するとコストが上がる？ スケジュールが伸びる？ 追加人員や機材などの資源は必要？ リスクはないの？ などの様々な疑問が出てくると思います。これらを説明できる合理的な理由を用意しておく必要があります。 決裁者の立場に立って変更要求を変更登録簿に記載していくことをお勧めします。
［変更要求］実行 21変更要求の決裁 変更要求の決裁は、あらかじめプロジェクト憲章で定められた変更コントロールのプロセスやルール、またはスコープ記述書のプロジェクトスコープで定められたプロセスやルールにより、適切に決裁されます。 一般的にはレビューコミッティー、ステアリングコミッティー、変更会議など、プロジェクト憲章やスコープ記述書であらかじめ定められた複数の決裁者が集う会議体で議論され、変更要求が可決されたり否決されたりします。 小規模なプロジェクトで決裁者がプロジェクトスポンサーだけという場合もありますが、通常は複数人数で行うことが一般的です。 皆さんは取締役会議や執行役会議などのプロセスをご存じでしょうか。「第 １号議案〇〇について」など議案の内容を説明し、質疑応答の上、取締役や執行役が決裁していきます。プロジェクトが大きくなり複雑化していくと、まさにこのような会議の場となります。 プロジェクトマネージャが変更登録簿の内容を決裁者に説明し、決裁者がその内容を評価し変更の可否を決定します。 この機会に再度、本書のプロジェクト憲章の変更コントロールについて確認しましょう。 変更要求が否決された場合、プロジェクトマネージャはその理由をしっかりと確認しましょう。場合によっては課題に対する再提案を求められる場合もありますし、当該会議で決裁者から新しい方針や対応策が指示されることもあります。再提案や指示内容に対して準備し、次の変更に関する会議に備えましょう。 可決された場合はプロジェクト憲章やプロジェクトマネジメント計画書類などの文書を迅速に改定するとともに、関係するステークホルダーにその変更内容情報を伝達し活動を開始しましょう。［変更要求］実行 22変更要求は最初が肝心 プロジェクト実行を開始すると、最初のうちは変更要求が多くなります。プロジェクトを実行すると、計画時にはわからなかったあらゆる「現実」に直面するからです。 プロジェクトマネージャや決裁者は「また、変更要求？」と嫌になってしまう場合がありますが、プロジェクト実行後の最初の変更要求をしっかりと対応していけば、その後の変更要求は徐々に少なくなる傾向にありますし、また何よりもプロジェクトの目的・目標達成に近づきます。 なぜなら、現実に対してひとつひとつ対応することにより、計画がより現実に合わせた形になっていくからです。 計画の章でお伝えしたように、計画時にも同じようなことがありました。計画を進めていくと、計画が段階的に詳細化され、前工程の計画ではわからなかった部分が見えてきました。それにより、計画の最初は前工程の計画を修正することが多いのです。 実行に移ると、実際の現実を目の当たりにして、同様のことが起こります。計画のように、ひとつずつ丁寧に変更に対応しコントロールすることにより、段階的に計画が現実に合わさり、変更要求が少なくなる傾向になります。 プロジェクトが進行すればするほど、変更は困難になります。極端な例を出すと、プロジェクト終了直前に、「成果物のスコープを変えよう」などとなったらどうでしょうか？ 今までの活動は無駄になります。これによりスケジュールの大幅な変更やコストの大幅な増加など影響が大きいです。 これがプロジェクト実行の冒頭だったらこれほど大きな影響にはなりません。実行時の最初は変更が多く大変かもしれませんが、ここでしっかりと対応していくことが大切です。［変更要求］実行 23変更要求時にもバランスの観点が必要 第 ３章【計画】で、プロジェクトマネージャは「スコープ」「時間」「資源」「コスト」などの角がある“お盆”の上にボールを乗せて歩いているようなものと説明しました（「計画 76 計画のヒント ①」参照）。つまり、「スコープ」「時間」「資源」「コスト」のバランスを意識し、ボールが落ちないように調整します。 プロジェクト実行中もこのバランス観点を持って変更要求の対策を考える必要があります。 例えば、計画にはない作業を「スコープ」に加えてほしいと実行中に要求があった場合、お盆の「スコープ」の角が上がります。他の「時間」「資源」「コスト」の角を一緒に考えなければ、これらの角は上がらず、お盆は傾き、お盆の上のボールは下に落ちてしまいます。 これはプロジェクトのトラブルを表しています。通常であれば、スケジュールを伸ばす、資源を増やす、コストを増やすなどで「時間」「資源」「コスト」の角も上げてバランスをとらなければなりません。 これらの要求が通れば話は簡単なのですが、通常のプロジェクトではそうはいきません。「時間」「資源」「コスト」はそのままで「スコープ」を増やす要求もしばしばです。この時にプロジェクトマネージャは計画時と同じく「調整」や「交渉」が必要になってきます。 例えば、追加要求の優先順位はどうか、スコープを追加する代わりに他のスコープは削除できるか、コスト追加は満額ではなくともどれぐらいまで可能か、前工程が走りながらでも先に当該作業を開始することは可能か、これによりリスクは増大するがそれは許容できるか、など計画時に行ったような調整交渉が必要です。
この調整を行わない場合、後になって納期遅れ、コスト増加、人的資源の疲弊などトラブルが発生してしまう場合があります。変更時の交渉・調整は大変ですが、後にトラブルを起こさないようにしっかりと行いましょう。［変更要求］実行 24変更履歴をしっかりと保管・保存しよう 今まで述べたように、プロジェクト実行中もプロジェクト憲章やプロジェクトマネジメント計画書の変更があります。 これらの文書については、第 ３章【計画】でお伝えしたように、必ずバージョン情報を明確にし、過去のものも保管するとともに、いつ、誰の決裁で、どのような理由で変更されたかの情報を管理しておきましょう。 例えば、変更要求の決裁をレビューミーティング、ステアリングコミッティー、変更会議などで行う場合は議事録をとるなど、記録を残すことが基本です。 計画時と同じように、文書の変更記録や過去の文書類が適切に保管・保存されていない場合、時間の経過とともに、誰の決裁でなぜ変更されたのかが、よくわからなくなってしまいます。 最悪の場合は「何でこんな変更をしたんだ」ということになり、作業のやり直しが発生してしまう可能性だけではなく、顧客に対するプロジェクトの場合、契約関連の係争の可能性すらあります。 また、変更に際しての関連する文書の追加・変更、新しい文書の追加など、関連する文書の保管・保存管理も重要です。 例えば、お客様企業情報・組織が変わった、契約書が更新された、設計図・デザイン図が変わった、会社や組織の情報セキュリティルールが変わった、労働保険・社会保険などが変わった、関連する法案に変更があった、など様々な関連文書が変更になります。 これらも適切に保管・保存し、プロジェクトの目的・目標達成の障害にならないように適切に情報を管理しましょう。［進捗確認の優先度］実行 25クリティカルパス上の進捗確認は徹底的に プロジェクトが大きくなり複雑化すると進捗確認のための情報収集自体が困難になる場合があります。そして、ついつい進捗確認の頻度を落としがちです。 その場合は、アクティビティ、要素成果物（ワークパッケージ）、成果物の進捗確認の優先順位を決めて、優先順位が高いものについて徹底的に進捗確認しましょう。特に、クリティカルパス上のアクティビティ、要素成果物（ワークパッケージ）、成果物の進捗確認は徹底的に頻度高く行いましょう。 すでにお伝えしたように、クリティカルパス上のアクティビティ、要素成果物（ワークパッケージ）、成果物はプロジェクト全体のスケジュールに影響を及ぼします。これらが遅延するとプロジェクト全体が遅延します。その他のパス上のアクティビティ、要素成果物（ワークパッケージ）、成果物はある意味、時間余裕があるということです。 この例はあくまでもスケジュールマネジメントの観点ですが、その他にも、例えばコストマネジメントの観点で優先順位をつける方法もあります。コスト管理表を作成した際に一番コストがかかるアクティビティ、要素成果物（ワークパッケージ）、成果物を優先的にコストの面で進捗管理する方法もあります。 また、資源マネジメントの観点で最も人的資源が投入され稼働時間が多いところを優先的に進捗管理する方法もあります。他にも、スコープマネジメントの観点で、最も要求事項の難易度が高いところを優先的に進捗管理する方法もあります。 このように、スコープ、時間（スケジュール）、資源、コストなどの進捗確認に優先度を定めて進捗確認を進めるなどの対応も考えましょう。
［レポーティング］実行 26レポーティングの基本 プロジェクトでは、進捗情報を定期的に共有するための定期的なレポーティングや緊急時などに情報共有するための不定期なレポーティングなどがあります。これらのレポーティングの内容や伝達手法、ルールなどは企業や組織、プロジェクトによって様々です。 なぜなら、これらのレポーティングは、ステークホルダーの要求事項によりその内容や伝達手法、情報の配布頻度などが異なり、また企業や組織、プロジェクトによってステークホルダーが異なるためです。 情報伝達先のステークホルダーが望まないレポートは残念ながら誰も読みません。したがって、レポーティングの基本は「相手が何の情報を、どういった頻度で、どのような情報配布媒体で求めているのか」を定義し、それに準じたレポート内容であることです。 では、その定義はどこでするべきなのでしょうか？ 勘が鋭い人はもうおわかりなのではないでしょうか。そうです、スコープ記述書のプロジェクトスコープの部分や、コミュニケーションに関する計画書で明確に定義しておくことが大切です。 また、相手に「読まれる」レポーティングをするために、相手の立場になって情報を配布する必要があります。既述の通り、コミュニケーションの基本は「情報の発信者は発信した情報の責任者」とお伝えしました（「実行 12 しっかりと情報を伝えるための基本 ①」参照）。レポートがしっかりと読まれるかは情報発信者の責任です。 例えば長いメールを全て読まなければ状況がわからないレポート、数十ページにもわたる紙資料を全て読まなければ状況がわからないレポートなどは、相手が読まない可能性があります。 ステークホルダーが読まなければ、適切な決裁が得られなかったり、「こんなの聞いていないよ！」と作業のやり直しが発生してしまうなどプロジェクトに影響が出てきてしまいます。［レポーティング］実行 27進捗報告で最低限押さえておくべきこと ①─内容─ 重要な定期レポーティングのひとつとして「進捗報告書（ Project Status Report）」があります。進捗報告書はその名の通り進捗を報告するわけですが、ここで「進捗確認」とは何かを今一度思い出しましょう。 進捗確認は、 ①過去の実績を測定すること、 ②計画と実績の差を分析すること、 ③未来にどうなるかを予測すること、が重要な要素でした。進捗報告書の中でよく見受けられるのは ①のみの場合です。 しかし多くのステークホルダーは、 ①の実績に対して、 ③の未来はどうなるかを知りたいのです。実績のみを報告して「で、何なの？（ So What？）」とならないように、しっかりと分析した未来の予測も進捗報告書で明示しましょう。 また、既述の通り、進捗報告書の内容はステークホルダーの要求事項によって内容が異なり、また企業や組織によっては進捗報告書のフォーマットが完備されている場合があります。しかし、プロジェクト現場で一般的に最低限記述しておくべきポイントがあるので、以下にその内容をお伝えします。 ■ １．進捗情報概要 プロジェクトの状況がどうなっているのかを簡潔に、かつ定量的に表し「概要」として報告します。 皆さんは車の運転席にあるメーター類を見たことがあると思います。あらゆる計器で速度やエンジンの回転数、燃料の量、走行距離、温度など一目すれば状況がわかるようになっています。プロジェクトでも「概要」部分でプロジェクトがどうなっているのかを確認できるようにすることが多いです。特に、既述のスコープ、時間（スケジュール）、資源、コストなどが一目でわかるような概要が最低限必要です。 例えば、あらかじめスコープ記述書にて、「プロジェクトの進捗率」は、全アクティビティの進捗率の平均値とするというようなシンプルなルールを定めていたとして、レポートに「プロジェクトの進捗率」という項目を作り「先週 計画 64％／実績 63％ → 今週 計画 67％／実績 67％ →来週 計画 70％／予測 70％」と報告するなどです。 このように定量的に簡潔にまとめることにより、先週より ４％進行した、先週は計画に対して １％遅延していたが今週はそれをリカバリーし来週も計画通りに進むということが一目でわかります。 その他にも「コスト消化率」を計画・実績・予測で表す、資源の部分でプロジェクトメンバーの「稼働時間数」を計画・実績・予測で表す、スケジュールを「マイルストーン」の到達日を計画・実績・予測で表すなど、様々な現在状況、未来状況を簡潔に定量的に表しましょう。 ■ ２．活動完了情報、活動中情報、今後の活動 前回の進捗報告から今回の進捗報告までに新たに完了したアクティビティや要素成果物（ワークパッケージ）または成果物の情報、現在活動中のアクティビティや要素成果物（ワークパッケージ）または成果物の情報を報告します。また、直近で活動を開始するアクティビティや要素成果物（ワークパッケージ）または成果物の情報を明示します。 重要なことは、何が終わり次に何をすべきかを明確にすることです。アクティビティの担当者によっては、他の担当者が活動している前工程のアクティビティの情報が重要になります。 なお、グローバルプロジェクトの現場では、終了したアクティビティ類を「 DONE」、実行中のアクティビティ類を「 WIP（ Work in Progress）」、直近で実施するアクティビティ類を「 To Do」などとステータス分けして報告する場合があります。 さらに、 DONEのアクティビティに対して計画の終了日と実際の終了日を明記し、予定通り（ On Time）に終了したのか、遅延（ Delay）して終了したのかを簡潔に明示することも
あります。 WIPのアクティビティについても、計画の終了日と予測終了日を明記し、予定通りに終了しそうか遅延しそうかを明記することがあります。 また To Doのアクティビティについては、開始日（ Start Date）と完了日（ Due Date）を明示することがあります。 ■ ３．課題／リスク 現状の課題やリスクについて記載します。また、各課題やリスクに対してどう対応するのか、またはどう対応しているのか、その方針や戦略、活動内容などを報告します。 ■ ４．決裁依頼内容 変更要求や、その他の決裁者の決裁が必要な事項の概要を報告します。そして、その決裁内容を誰がいつにどのように決裁判断を仰ぐかの情報を報告します。 ■ ５．詳細情報 今まで １ ～ ４の最低限必要な報告内容を記載しましたが、これらの詳細情報や関連する情報を添付する場合があります。また、ガントチャートやコスト管理表、リスク管理表など、進捗管理用のツールなどの情報を添付する場合があります。 ■ ６．その他 既述の通り、進捗報告書の内容は、ステークホルダーの要求事項に応じたスコープ記述書のプロジェクトスコープの内容や、コミュニケーションに関する計画書で決定された内容に準じます。要求事項に応じて項目を追加しましょう。［レポーティング］実行 28進捗報告で最低限押さえておくべきこと ②─構成─ 進捗報告書は情報の配布先の人々が見てくれなければ意味がありません。しかし、ステークホルダーの特定や分析で説明した通り、ステークホルダーの関心事項はそれぞれ異なります。 例えば、プロジェクトスポンサーやプロジェクトチームメンバーなど、直接プロジェクトの詳細まで関与しているステークホルダーは進捗情報の詳細まで知りたいでしょうし、忙しい経営者層はプロジェクトがうまくいっているのかどうなのかという概要を知りたい可能性があります。財務・経理担当はコストのみに興味があるかもしれません。 これらの理由で、企業や組織ではプロジェクトに合った進捗報告の構成を考えます。例えば、大量の進捗情報の「サマリー」を報告書の 1ページ目やメール送信時の文面で報告し、詳細が気になる人のためにその後に詳細情報の文書を添付する、またはメールで報告する場合、メールの件名で進捗の状況を表すなどです。 このように段階的に情報を整理した構成にすることで、概要のみ知りたい人と詳細まで知りたい人をカバーしています。また、進捗を直観的に把握できるよう、進捗報告書の概要部分でスコープ、時間（スケジュール）、資源、コストなどの情報を「信号機」で表すこともあります。青信号は問題なし、黄色信号は注意、赤信号は課題ありという設定です。 信号機で表すなら、あらかじめスコープ記述書などで信号の色の定義が必要です。プロジェクトの課題をいち早く知りたいステークホルダーは黄色信号や赤信号の部分を詳細まで読むことでしょう。 様々なグラフを使って進捗概要を表現する場合もあります。例えばコスト消化率など、計画と実績 ＋予測の折れ線グラフなどで表現すれば、現状の計画に対するコスト支出実績はどうか、予測はどうなるかが一目でわかります。このように相手に読まれるよう相手の立場に立った構成を考えましょう。［レポーティング］実行 29進捗報告で最低限押さえておくべきこと ③─頻度─ 進捗報告はどれぐらいの頻度で報告するのがよいのかという質問がよくあります。頻度についても、ステークホルダーの要求事項に合わせる必要があります。 少なくともプロジェクトで設定したマイルストーンや変更要求を決裁する会議の前までには報告が必要であると考えます。なぜなら、進捗がわからなければマイルストーンのミーティングが予定通り行われるのかなどがわからなかったり、変更要求を決裁するための基本的な情報が事前にわからなかったりするためです。 また、実際のプロジェクトではステークホルダーの関心度のレベルにより、報告頻度の要求はバラバラな場合もあります。 そこで、プロジェクトマネージャが検討すべきは、どの情報をいつにどの進捗報告書で誰に報告するかということです。例えば、週次報告、月次報告、マイルストーン前の報告など、報告内容と報告頻度、報告先を分けて報告する手法などがあります。 週次報告はプロジェクトの詳細まで関与しているステークホルダーに、月次報告は全ステークホルダーになどの区分けが可能です。これらの報告書種別や頻度、報告書の配布先などはスコープ記述書やコミュニケーションに関する計画書類に明文化しておきましょう。 筆者がプロジェクトマネジメントを指導・支援する場合、プロジェクトの詳細まで関与するステークホルダーに対しては、週次で報告書を展開することをお勧めしています。 また、そのために週次で進捗確認をするのがいいでしょう。プロジェクトでの課題や問題を早めに把握し解決すること
ことがプロジェクトの成功に結びつきます。［レポーティング］実行 30緊急時のレポーティング 不定期のレポーティングの中で緊急時の報告があります。内容は事故やその他の緊急を要する不測の事態、お客様との係争、競合他社の動向など様々です。このような緊急時の報告でも、報告される「相手の立場」に立って報告する必要があります。 例えば、緊急事態が発生し、その状況だけを迅速に報告したとします。報告した相手はすぐに状況を把握できますが、「それで、どう対応するの？」「私は何をすればいいの？」など、報告相手が疑問に持ち、説明を求めてくる可能性があります。 逆に、緊急事態への対応方針を詳細まで時間をかけてしっかりと考えて、報告相手に依頼すべきことも策定してから報告したとします。報告した相手は状況、今後の対応、自分への要求事項を把握することはできますが、「緊急なのに何でこんなに発生から時間が経過しているの？」など相手が疑問に持ち、説明を求めてくる可能性があります。緊急時の報告は迅速にするべきです。 緊急報告の場合は、「事象の事実」「今後の事象に対する活動の概要（アクションプラン）」を迅速にまとめ「第一報」などとして報告することをお勧めしています。 「第一報」の内容によってはアクションプランに対するアドバイスが報告先から入るかもしれません。また第一報後に新たな情報やアクションプランの結果が出てきます。これらをまとめて「第二報」「第三報」……など段階的に報告しましょう。［ステークホルダー管理］実行 31ステークホルダー管理のポイント プロジェクト実行中にプロジェクトマネージャが対応すべき重要な活動として「ステークホルダー管理」が挙げられます。 第 ２章【目標設定】で説明したステークホルダー登録簿を今一度思い出してください。ステークホルダーの情報とともに、関心事項、影響度、興味・関心度、賛否、対応内容などの情報を整理したと思います。 プロジェクトマネージャは、プロジェクト実行中もこれらを定期的に確認し、ステークホルダー分析で得られた対応方針をもとにステークホルダーとコミュニケーションをとっていきます。 プロジェクトに反対の人は中立に、中立の人は賛成に、賛成の人は賛成のまま維持するよう常に努力します。さらには、要求事項の収集で調整した期待や要求事項を実現させるために努力します。 しかし、残念ながら、ステークホルダーの関心事項、影響度、興味・関心度、賛否、要求事項はプロジェクトの状況や外部環境の変化で常に変化します。 例えば会社や組織の業績が悪くなれば、社内関係者または顧客からすでに設定されている予算のカットの要求が発生するかもしれません。競合他社が同様の製品を開発していることがわかり成果物のスコープの変更を要求されるかもしれません。興味・関心度が低かったステークホルダーが、何かの都合で急激に興味・関心度が高くなるかもしれません。 このように、プロジェクトマネージャは、ステークホルダーの状況に常に注意を払い、ステークホルダーの懸案事項の特定、定期的なステークホルダー分析や対応方針の調整、要求事項の調整、ステークホルダーの課題解決をする必要があります。 ステークホルダー登録簿は定期的に最新の状態にし、ステークホルダー管理を常に行いましょう。
［ステークホルダー管理］実行 32中立かつ冷静な立場でステークホルダー管理をする プロジェクトマネージャも人間ですから、ついつい偏った視点でステークホルダー管理をしてしまうことがあるかもしれません。しかし、あらゆるステークホルダーの変化や要求事項の変化に中立かつ冷静な立場で合理的思考で対応する必要があります。 今一度プロジェクトマネージャの責任を思い出してみてください。 プロジェクトマネージャの責任は、単純化すれば納期までに目的や目標を達成させるために要求事項を満たす成果物を納品することです。根底には目的・目標を達成させるためにプロジェクトマネージャは活動しています。 例えば、プロジェクト実行中にお客様の企業から成果物のスコープ追加の要求があり、お客様は変更をしなければ競合他社に勝てないことがわかっていたとします。自社また自組織のプロジェクトチームメンバーは現在までのスコープを完遂させるために頑張っていて、変更を伝えることでプロジェクトチームメンバーの士気が下がる、コストが増加する、スケジュールが遅延する可能性があります。しかし、自社または自組織の営業部隊は自らの売上を確保するためにお客様の要求を叶えて欲しい、など関心事項がそれぞれ異なっていたとします。 この時、プロジェクトマネージャがお客様、プロジェクトチームメンバー、営業部隊のいずれかに偏った視点を持っていた場合、ステークホルダー管理も偏ってしまいます。偏った視点によって目的・目標の達成に支障をきたすかもしれません。 各ステークホルダーの関心事項や要求事項を中立に冷静な立場で把握し、それぞれの要求事項を優先した場合の便益や損失を把握しましょう。 また、分析結果をもとにステークホルダー間の調整をすることも重要です。自分で判断できない場合は分析結果を決裁者などに相談する、変更要求を出すなど判断を仰ぎましょう。［マイルストーンでの判断］実行 33マイルストーンで実施すべき３つの判断 プロジェクト実行中に実施する重要な活動として、第 ２章【目標設定】で設定したマイルストーンの確認ミーティングを実施します。 マイルストーンミーティングでは、あらかじめ設定された関係者が、あらかじめ設定した基準をもとにフェーズの完了や、成果物や要素成果物などが要求事項にもとづいて作り上げられているかなどを確認します。 プロジェクトマネージャはマイルストーンミーティングを招集し、事前に設定されたルールや基準に則りミーティングを運営することが求められます。 マイルストーンミーティングでの評価結果及びその判断は単純化すると以下の３つです。 ①「承認（ GO）」：あらかじめ設定した基準をクリアし、次のフェーズに進む、または成果物や要素成果物の納品完了を承認する。 ②「やり直し（ REPEAT）」：あらかじめ設定した基準が一部クリアしておらず、もう一度フェーズの一部をやりなおす、または成果物や要素成果物の一部やりなおしを指示する。 ③「中止・停止（ STOP）」：あらかじめ設定した基準をクリアしておらず、今後のプロジェクト継続が困難と判断し、中止または停止の判断をする。 実際のプロジェクトでは、 ①と ②の中間のような条件付きの承認などもあります。例えば、作業や活動条件を指示し実行する前提で次のフェーズに進む許可などです。 プロジェクトマネージャは、マイルストーンミーティングでの結果をしっかりと議事録などに残し、結果に応じて迅速にプロジェクトチームメンバーとともに次の行動をとることが求められます。 また、やり直しとなった場合はあらゆるプロジェクト計画の調整や変更が必要な場合もあります。中止・停止についてはしかるべき決裁者と今後の対応について協議しましょう。
［プロジェクト終結］実行 34プロジェクトの終結 成果物が全て納品されプロジェクトの目標を達成しプロジェクトを完了する場合、または努力しながらも残念ながらプロジェクトが中止となった場合、いずれの場合でも「プロジェクト終結」に関する活動が最低限必要です。 プロジェクトマネージャの最低限必要な活動としては、 ①プロジェクトが全て終了したかを確認すること、 ②プロジェクト関連の文書の保管及びプロジェクトの終結報告書（ Project Closure Report）をまとめることです。 ①については、例えば、プロジェクト成果物が全て納品完了していたとしても、または残念ながらプロジェクトの中止指示があったとしても、プロジェクトメンバーは解放されていない状態です。プロジェクトメンバーをそれぞれの部署に戻したり、新しいプロジェクトに異動してもらいます。 また、プロジェクトで利用した機材や資材、オフィス環境なども返却・売却・譲渡・処分などの対応が必要です。コストについても支払を全て済ませる必要があります。顧客やサプライヤなどとの契約完了にも活動が必要です。このように、プロジェクトでは「後片付け」も重要な活動のひとつとなります。 ②については、プロジェクト関連文書はプロジェクトの成功・失敗にかかわらず、企業や組織にとっては重要な財産的情報になります。 プロジェクトの終結時に、プロジェクトの結果や結果の要因、プロジェクトから得られた教訓などを「プロジェクトの総括」として報告書にまとめ、今後の企業や組織のプロジェクトのために活用できる情報、またはプロジェクトで生み出したものを定常・継続業務に引き継ぐための情報とする必要があります。 なお、プロジェクトが大きくなり複雑化し、フェーズごとにプロジェクトを明確に区切って進めていく場合、この終結の対応をプロジェクトのフェーズごとに行うこともあります。［プロジェクト終結］実行 35プロジェクト終結報告書 「プロジェクト終結報告書」は企業や組織によってフォーマットが決まっていたり、記載する内容の明確な指示があったりする場合があります。一度、自組織のフォーマットやルールを確認してみましょう。 ここではプロジェクト終結報告書にて最低限記載すべき内容を以下にお伝えします。 プロジェクト憲章はプロジェクトの開始を明示する重要な文書でした。一方、プロジェクト終結報告書は、プロジェクトの終結を明示する重要な文書となります。 プロジェクト終結報告書を作成する上で、プロジェクトマネージャが持つべき重要な観点が３つあります。 それは、 ①今後の自組織のプロジェクトまたはプロジェクトマネジメントの高度化のための財産的情報になる、またはプロジェクトでの成果を引き継ぐ定常・継続業務での基礎的な情報になるという認識を持って作成すること、 ②公平・公正な立場で事実・原因・結果を記載すること、 ③自らだけの観点ではなく、ステークホルダーからも情報を収集してプロジェクト全体としての終結報告書とすること、などです。 ■ １．基本情報 プロジェクト憲章のように、プロジェクト名、プロジェクト終結報告書のバージョン番号、作成者、この文書の目的を明記します。なお、プロジェクト終結報告書もプロジェクト憲章や他の計画書のように、何度か変更を指示されることがあります。バージョン情報はしっかりと明記しておきましょう。 ■ ２．プロジェクトの概要 プロジェクト終結報告書またはその中に含まれている「プロジェクトの教訓（ Lesson & Learn）」の情報は、今後の新しいプロジェクトの計画時に活用される場合があります。 例えば、類似したプロジェクトを自組織で行う場合、過去のプロジェクトの情報が参考になります。計画の際に過去の情報を参考にするために、プロジェクトマネージャがプロジェクト終結報告書を見た場合、自分が今後計画するプロジェクトの類似プロジェクトなのかが認識できるように、改めてプロジェクトの概要をまとめて記載しておきましょう。 ■ ３．プロジェクトパフォーマンス実績 ここでは最低限あらゆるプロジェクトの計画に対する実績を項目分けして記載することが重要です。 まず、「目的・目標の達成」ができたのかどうかを簡潔にまとめます。 次に、成果物の「納品完了概要」を明示します。 WBSに明示されている成果物の納品が完了している事実、そしてその成果物の当初の計画納品日と実際の納品日の実績の情報を明示します。もしも納品の計画と実績が異なる場合、その理由を簡潔に記載しましょう。 続けて、最低限、スコープ、スケジュール、コスト、リスクの計画と実績を簡潔に記載します。例えばスコープであれば、計画当初のどのスコープが実現できて何が実現できなかったのか、実現できなかったその理由はなどです。 スケジュールやコストであれば、計画に対して実績はどうだったのか、計画と実績の差が出たのはなぜなのかなどの事実を簡潔にまとめます。リスクに対してはリスク計画に対する実績はどうだったのか、その他特定していなかったリスクの有無、その対応などの事実を簡潔にまとめます。 ■ ４．プロジェクト評価と教訓 プロジェクトパフォーマンスに対する評価をまとめます。成果物、スコープ、スケジュール、コスト、リスクなど、それぞれのカテゴリを設定し評価することが望ましいです。
プロジェクト終結ミーティングはプロジェクトマネージャがリードして実施しましょう。［まとめ］実行 37【実行】のまとめ 第 ４章【実行】では、主にチームビルディング、コミュニケーション、進捗管理、プロジェクトや変更に関するコントロール、レポーティングなどの情報配布について重点的にお伝えしてきました。 実際のプロジェクトでは、計画をしっかりやったと思っていても、計画通りプロジェクトが進むことは滅多にありません。 そこで、プロジェクトマネージャは現状を「やりくり」し計画通りに進むように努力することと、努力したとしても計画や目標を変更せざるを得ない場合、現状の分析や合理的思考にもとづいて適切に変更をコントロールしていく必要があります。 さらに、多くのプロジェクトでは、目的・目標達成のためにステークホルダーとコミュニケーションをとりながら、プロジェクトチームメンバーとともに一丸となって活動していく必要があります。 全てはプロジェクトの目的・目標達成のためにプロジェクトを進めるように、そして止めないようにする努力です。 「自転車」に乗った経験のある人は多いと思います。自転車は「こぎ始め」が一番力を使います。しかし自転車が進みはじめると、一定の力で一定の速度で進みます。プロジェクトもこれに似ています。すでに説明したように、計画時にプロジェクトマネージャの労力は大きくなります。 さらに実行開始時にはプロジェクトチームのチームビルディングや、様々な変更があり引き続き労力が必要です。自転車の「こぎ始め」です。 しかし、そこでしっかりと力を入れると、その後プロジェクトが推進しはじめます。プロジェクトが安定的に推進しはじめても、常に一定の力をかけプロジェクトを止めないように努力していかなければなりません。 一度プロジェクトが停止すると、計画や実行のやり直しです。やり直しは再度大きな労力、つまり自転車の「こぎ始め」が発生するのです。
コメント