第 ３章【計画】段階的に計画を立てる［計画の重要性］

計画 01 段取り八分とは？［ファシリテーション］計画 02 ファシリテーションの重要性─計画の前に─［要求事項］計画 03 ステークホルダーの要求事項を収集しよう計画 04 要求事項の収集で重要な「優先順位付け」「明確化」計画 05 要求事項の意思決定ルールを明確にしておこう［スコープ］計画 06 スコープ定義／スコープ記述書とは？計画 07 スコープ記述書で最低限明確にする内容計画 08 スコープ記述書の重要ポイント［詳細計画のイメージ］計画 09 詳細計画に向けての全体像 ［WBS］計画 10 目標達成の要素を導く─WBSとは─計画 11 WBS作成で重要なこと計画 12 WBSの作り方計画 13 プロジェクト成功率を高めるための WBS作成のコツ ①計画 14 プロジェクト成功率を高めるための WBS作成のコツ ②計画 15 WBS辞書を作ろう計画 16 WBSと WBS辞書作成の後にすべきこと計画 17 スケジュールを策定しよう計画 18 ガントチャートと WBSのつながりとは？［アクティビティ］計画 19 アクティビティの順序付けとは？計画 20 アクティビティの順序付けをやってみよう計画 21 アクティビティの順序付けでの注意点計画 22 アクティビティ期間の見積もりをしよう［スケジュール調整］計画 23 プロジェクトにおける資源を考えよう計画 24 クリティカルパスとは？計画 25 どうしてもプロジェクト完了期日に収まらなかったら？［ガントチャート］計画 26 ガントチャートの中の情報とは？計画 27 アクティビティリスト情報（ WBSの情報）を入力しよう計画 28 責任分担の情報を入力しよう計画 29 責任分担表の注意点計画 30 開始日と終了日を入力しよう計画 31 開始日と終了日設定時の注意点計画 32 進捗情報を明示する項目を作っておこう計画 33 スケジュールを可視化しよう計画 34 ガントチャートにマイルストーン情報を入力しよう計画 35 クリティカルパスや依存関係ネットワークを明確にすると便利計画 36 「実績」や「現在」を表現する部分を設けると便利計画 37 ガントチャートを作ってみよう［時間余裕（バッファ）］計画 38 時間余裕（バッファ）の考え方計画 39 時間余裕（バッファ）を組み込む場合はどうするか？［コストの見積もり］計画 40 コスト計画を策定しよう─資源が動けばコストがかかる─計画 41 コストの見積もりの前に決めておくべきこと計画 42 コストの見積もりの手法は３つある計画 43 コストの見積もりを体験してみよう計画 44 リスク対策にもお金がかかることに注意［コスト管理］計画 45 スコープ vs時間 vs資源 vsコストの視点計画 46 コストオーバー時に最低限やるべき３つの対応計画 47 コスト管理表とは？計画 48 コスト管理表を作ってみよう計画 49 コスト余裕（バッファ）の考え方［リスク］計画 50 リスク対応計画に入る前にゲームをしよう計画 51 リスクの概念をしっかり持とう計画 52 リスクを特定しよう計画 53 リスク登録簿を作成しよう計画 54 QCDの観点をリスク登録簿に入れよう［リスク分析］計画 55 定性リスク分析とは？計画 56 定性リスク分析をやってみよう計画 57 定性リスク分析で発生しやすい事象計画 58 定量リスク分析とは？計画 59 定量リスク分析をやってみよう［リスク対応］計画 60 リスク対応の優先度を決めよう計画 61 リスク対応の優先度と対応基準を決めてみよう計画 62 リスク対応計画を立てる前に─脅威のリスク対応策の基本─計画 63 リスク対応計画を立てる前に─好機のリスク対応策の基本─計画 64 その他のリスク対応策計画 65 リスクの軽減策、強化策の注意点計画 66 リスク対応策にはコストがかかる計画 67 リスク対応策を考えてみよう計画 68 二次的なリスクという考え方［リスク管理］計画 69 リスク管理表とは？計画 70 リスク管理表の作成が終わったら計画 71 リスク管理表における落とし穴計画 72 未知のリスクと既知のリスク［計画書］計画 73 〈参考〉その他の計画［計画書の承認］計画 74 プロジェクトマネジメント計画書の承認を得よう［チームの結成］計画 75 プロジェクトチームの結成のタイミング［計画のヒント］計画 76 計画のヒント ①─バランス─計画 77 計画のヒント ②─３つの「しない」─計画 78 計画のヒント ③─文書・資料管理─［まとめ］計画 79 【計画】のまとめ

［計画の重要性］計画 01段取り八分とは？

皆さんは「段取り八分」という言葉をご存じでしょうか。昔から、段取りをしっかりとしておけば、その仕事の大半を占める ８割は完了しているのも同然という意味で、この言葉が使われてきました。プロジェクトマネジメントでいえば「計画」という下準備にあたります。 確かに、プロジェクトの計画ではプロジェクトマネージャの稼働が集中してとても忙しくなります。しかし忙しいからといってプロジェクト計画が大雑把になると、どうなるか皆さんもおわかりですよね？ プロジェクトのスケジュールが遅延する、コストがオーバーする、作業工程に抜けもれがある、プロジェクトチームメンバーのコミュニケーションが混乱するなど、プロジェクト実行中に様々な障害をもたらします。 プロジェクト実行中に様々な障害が出るとどうなるでしょうか。そうです、プロジェクト実行中もプロジェクトマネージャはバタバタとしなければならなくなります。 プロジェクト計画での知識や技術の多くには、見えないものを「可視化」する知識や技術が含まれています。「可視化」することで、未来の活動に対して頭の中でシミュレーションができるとともに、ステークホルダーとの意思疎通をしながら計画を進めやすくなります。 プロジェクト計画でプロジェクトマネージャは多くの労力を使いますが、今一度「目標設定」でお伝えしたことを思い出してください。「あなたの欲しいものは？ あなたの会社が欲しいものは？」のゲームで体感したように目的・目標設定が大雑把であれば、その後の計画も大雑把になってきます。明確な目的・目標設定こそ計画を高度化させる基本となり

となります。［ファシリテーション］計画 02ファシリテーションの重要性─計画の前に─ 「ファシリテーション」という言葉を聞いたことがありますか？ 単純化させると、ファシリテーションは、会議などで参加者の議論や参加を促し議論を活性化させたり、議論の内容を整理したり、議論の場における合意形成を支援したりする活動や行動、能力を指します。また、会議などのアレンジや議論の進行ルールの策定もファシリテーションに含まれるといわれています。 プロジェクトの計画の様々な場面において、プロジェクトマネージャにはファシリテーションが求められます。プロジェクトが大きくなり複雑化するにつれて、目標達成に必要な活動の専門知識は高度化、詳細化し、プロジェクトマネージャとなる皆さんが知っている特定分野の専門知識だけでは対処ができなくなってきます。 しかし、その中でも様々なステークホルダーの要求事項を聞き、各種計画を行っていかなければなりません。目標達成に必要な各分野の専門家や有識者の意見を聞き出し、議論をリードし、合意形成をしていくことが極めて重要な能力となってきます。 知らない専門知識を自ら学ぶことは大変重要なことですが、残念ながらプロジェクト活動には期限があります。信用できる専門家や有識者を巻き込み議論をファシリテートする能力を身につけましょう。 その際、専門知識がないからといって自信をなくさないでください。【基本】の章でもお伝えしましたが、プロジェクトマネージャの皆さんは、どの業種業態でも共通の「プロジェクトマネジメントのプロセス」を実行する担当です。 逆にプロジェクトマネジメントのプロセスに責任を持つ者として、プロジェクト成功のために、わからない単語や内容は積極的に質問し、有識者や専門家の判断に対しては「なぜ」その判断をしたのか、合理的な思考で判断しているのかをチェックしていきましょう。［要求事項］計画 03ステークホルダーの要求事項を収集しよう プロジェクト憲章やステークホルダー登録簿が明確になったからといって、プロジェクトマネージャが独断で、プロジェクトによって生み出される製品やサービスなどの成果物やプロジェクトの進め方を計画してはいけません。 各ステークホルダーには製品やサービスの仕様や作業内容、プロジェクトの進め方に対して「要求事項」があります。これらの要求事項を満足させる製品やサービスを生み出せない、またはプロジェクト活動が実行できない場合、ステークホルダーは「こんなはずではなかった」「なぜこうなるんだ」とプロジェクトの停止や作業のやり直しの要因になりかねません。最終的にはプロジェクトの成功に影響を与えてしまいます。 要求事項は 2つに大きく分かれます。プロジェクトによって生み出される製品やサービスに対する要求事項と、プロジェクトの進め方に対する要求事項です。 製品やサービスの詳細に関心の高いステークホルダーは、製品やサービスに対する要求事項が多くあります。例えば、製品の機能・性能的要求、セキュリティ要求、デザイン要求、使用する技術や方式など様々なものがあります。 一方で製品やサービスの詳細ではなく、そもそもこのプロジェクト自体やプロジェクトマネジメントの進め方に関心の高いステークホルダーの要求事項もあります。 例えば、プロジェクト憲章で明確にしたビジネスニーズやビジネスケース達成の要求事項、納期や予算に関する要求事項、プロジェクトマネジメント手法に関する要求事項など様々です。 これらの要求事項を聞き出す作業から計画は始まります。各ステークホルダーの要求事項を聞き出し、それらを文書として

としてまとめておきましょう。［要求事項］計画 04要求事項の収集で重要な「優先順位付け」「明確化」 ステークホルダーの要求事項収集で最低限行うべき重要なポイントをお伝えします。要求事項を収集すると、各ステークホルダーは自身の要求事項を満足させるために数多くの要求事項を伝えてくることがあります。 しかし、プロジェクトマネージャにはプロジェクトで利用できる様々なリソース、コスト、時間が決まっています（これらも要求事項です）。各ステークホルダーの全ての要求事項を叶えることは現実的に難しいのです。 したがって、ステークホルダーの要求事項を調整しながら収集していきます。 優先順位付けは、ステークホルダーの各要求事項が Must（必須）、 Should（すべきこと）、 Could（可能であれば）、 Won’ t（不要）なのかを確認し調整しながら収集していきます。また、これらを文書に記録しておきましょう。 次に、重要なポイントとして「明確化」が挙げられます。要求事項は極力 6 W 2 Hを明確にし、さらに数値で明確にしておきましょう。これは相互の認識の齟齬を防止するために役立ちます。 以下に単純化した「優先順位付け」「明確化」の例を記載します。 ×販売価格は類似商品の希望小売価格と同一にする。 ○ Must：販売価格は類似商品 Ｘまたは Ｙの希望小売価格 100円にしなければならない。 ×商品の最終デザインチェック ○ Should： Ａ商品の最終デザインチェックはレビューコミッティーメンバーと 2016年 10月 31日に行い、 Ｘ、 Ｙ、 Ｚの ３点についてチェックしレビューコミッティーと合意の上で次の工程に進むべきである。［要求事項］計画 05要求事項の意思決定ルールを明確にしておこう 要求事項の「優先順位付け」などを経て、プロジェクトマネージャが各ステークホルダーの要求事項を調整したとしても、それでもまだ利害関係が衝突する場合があります。その時のために、要求事項の意思決定ルールを明確にしておくことをお勧めします。 要求事項の利害関係の衝突があった場合、誰が（個人やグループ、組織）要求事項の優先を決裁し、その決裁で用いる手法は何を利用し、どの段階でその意思決定をするのか、またその場には誰が参加するのかを明確にすることです。 決裁する個人やグループ、組織はレビューコミッティーメンバー、ステアリングコミッティーメンバー、プロジェクトスポンサーなど具体的な個人やグループ、組織を明確にしましょう。 決裁手法としては、多数決や全会一致、過半数や独断など決裁ルールを明確にすることが必要です。そしてその決裁の場にはマーケティング担当、開発担当、顧客が参加など、具体的にステークホルダーの参加者を決めておきましょう。事前にプロジェクト憲章に、この意思決定ルールを記載し承認を受けるのもひとつの方法です。 なお、このような要求事項の優先順位を決裁する場では、どうしてもステークホルダー個別の要求事項や利害関係に話がフォーカスしがちです。しかし、その場合には今一度プロジェクトの目的や目標である「プロジェクト憲章」に立ち返ることを忘れないでください。

［スコープ］計画 06スコープ定義／スコープ記述書とは？ 「スコープ（ Scope）」を直訳すると「範囲」という意味になります。プロジェクトのスコープは単純化すると「プロジェクトの範囲」となります。ここから、プロジェクトを計画するにあたり、プロジェクトのスコープを定義してから計画を進めていきましょう。定義したスコープはスコープ記述書に明文化していきます。 「プロジェクトの範囲」といっても「プロジェクトの範囲はここからここまで」という簡単なものではありません。成果物や要素成果物の仕様、作業内容・方法、納品時のチェック項目（完了条件）やプロジェクトマネジメントに対する方法論、納品する書類、作業内容・方法、レビューのチェック項目、会議やレポートなど、さらには、プロジェクトの前提条件、制約条件など、企業や組織、業種業態により多岐にわたります。 企業や組織、業種業態によっては詳細に定義し、プロジェクト記述書が相当数のページになる場合もあります。 では、このスコープ定義をし、スコープ記述書を作成するために必要な情報ソースは何になるのでしょうか。すでに勘が鋭い人はおわかりかと思います。それは、調整され現段階で確定されている、プロジェクト憲章、要求事項をまとめた文書など、スコープ記述書を作成する前に確定した文書類です。 プロジェクト憲章では、目的・目標、制約条件、前提条件などが明文化されています。要求文書では仕様、手法、作業内容、進め方などあらゆる要求事項が明文化されています。これらの情報をもとにスコープを定義し、スコープ記述書を作成していきます。［スコープ］計画 07スコープ記述書で最低限明確にする内容 業種業態、企業や組織によりスコープ記述書の詳細化レベルが異なります。詳細化のレベルによりスコープ記述書のページ数も異なってきます。ここでは、スコープ記述書で一般的に最低限明確にすべき項目を説明します。 皆さんの企業や組織ではスコープ記述書のテンプレートが完備されているかもしれません。完備されていない場合でもワードやエクセルを使って作っていきましょう。 ■ １．基本情報 プロジェクト名、スコープ記述書のバージョン番号、作成者、この文書の目的を明記します。この文書もプロジェクト憲章と同じく、今後改定される可能性があります。バージョン番号を明確にしておきましょう。 ■ ２．成果物スコープ 成果物に特化したスコープを明確にします。さらにわかりやすく説明すると、プロジェクトによって生み出される製品やサービス自体の範囲を明確にします。そして、当該製品やサービスを生み出すためのプロジェクトマネジメントで生み出される書類やレポート自体の範囲を明確にします。 例えば、プロジェクト憲章や要求事項の文書で明らかになっている成果物に関する機能や仕様、設計、制作に用いる技術や方法論などです。「プロジェクトで生み出すものは何か」の「 What」を明確にします。 ■ ３．プロジェクトスコープ プロジェクトの作業や活動に特化したスコープを明確にします。さらにわかりやすく説明すると、成果物を生み出すための作業や活動と、プロジェクトマネジメントの作業や活動の範囲を明確にします。 例えば、成果物を生み出す作業・活動内容、工程やその計画、作業・活動時の手法や方法論、会議、報告、またプロジェクトマネジメントの作業・活動内容としては、プロジェクトマネジメントの手法や内容、方法論、計画（計画書類）、会議、報告、進捗管理、各種計画や文書の変更に関する管理、プロジェクト終了方法などです。「成果物をどのように生み出すか」の「 How」の作業や活動を明確にします。 ■ ４．受入れ基準／完了基準 成果物を納品した際のチェック基準、手法、プロセスなどを記載します。成果物を納品する場面を想像してみてください。どのようなチェック項目で誰がどのようにチェックし、最終的に誰が決裁し納品が完了するかを想像しながら具体的に記載しましょう。また、チェック項目は、成果物スコープの条件が満たされている必要があります。 ■ ５．要素成果物 各成果物を構成している要素を記載します。例えば自動車が成果物だった場合、その自動車を構成している要素、エンジン、シャーシ、ボディ、電子部品類……などを記載し、その概要や詳細を記載します。この項目は後述する WBSで詳しく行います。 ■ ６．前提条件 成果物スコープやプロジェクトスコープに関する前提条件を記載します。プロジェクト憲章の前提条件はプロジェクト全体の前提条件でしたが、ここではそこからさらに各スコープに特化した前提条件を記載します。また、もしもその前提条件が発生しなかった場合、どのような事態が発生するかを記載します。 ■ ７．制約条件 成果物スコープやプロジェクトスコープに関する制約条件を記載します。プロジェクト憲章の制約条件はプロジェクト全体の制約条件でしたが、ここではそこからさらに各スコープに特化した制約条件を記載します。コストやスケジュール、経営指示や、契約内容、さらには利用する技術や方法論など多岐にわたります。 ■ ８．除外事項（ Out of Scope） プロジェクトでは Out of Scope（アウト・オブ・スコープ）という言葉をよく使います。これはプロジェクトの「範囲の外」という意味です。スコープ記述書ではスコープとして「やること」の他に「やらないこと」も明文化しておきましょう。 例えば、マーケティングで WEBを活用したマーケティングを実施することが決まっていたとしても、除外事項としてスマホ対応の WEBまたはアプリによるマーケティングはしない、と「やらないこと」を明確にできます。要求事項収集時の Won’ t（不要）とも関連してきます。 ■ ９．承認 プロジェクトが進むにつれ、スコープ定義やスコープ記述書で明確にした決定事項を忘れてしまったり、スコープ記述書を決裁者やステークホルダーが読んでおらず、後になって、これは誰が決めたんだ、知らない、聞いていない、などの問題が発生する場合もあります。 スコープ記述書に対してあらかじめ定めた決裁者からの承認、または関連するステークホルダーからの合意を得て、それを明確にする項目を設けておくことをお勧めします。 ■ 10．改定履歴 今後の計画時に新たな事実が明らかになったり、実行時に新たな事象が発生したりするなど、やむを得ない事情から決裁者の承認を経てスコープ記述書を改定するかもしれません。 改定履歴の項目を設け、バージョン情報、改定日、作成

者、変更内容などを明確にし、最新のスコープ記述書はどれなのかを識別できるようにしておきましょう。［スコープ］計画 08スコープ記述書の重要ポイント 皆さんも経験があるかもしれませんが、プロジェクトを開始すると次のようなことが発生します。「その内容、聞いてないよ」「状況が変わったので ○ ○の機能を追加してほしい」「 × ×はやるって思っていたよ」などの状況です。 これらにより、プロジェクト進捗の停滞や、作業のやり直しが発生したり、同コストで作業・活動工数ボリュームのみが増大したりする弊害が発生します。最終的には目的・目標の達成が期日までにできなくなってしまう可能性すらあります。 要求事項の収集から、要求事項の優先順位付けをし、その要求事項を 6 W 2 Hで明確にし、さらにそれをスコープ記述書で明確にし、合意形成をすることで、これらの弊害の発生を軽減させることが期待できます。 もちろん、プロジェクトは未来に対する活動であり、常に不確実性があるので、 100％防止できるというわけではありません。しかし、文書に明確化し合意形成しておくことで、今まで双方が気づかなかった事象が発覚した場合には、「ここはスコープ定義していなかったな」と双方で納得し、建設的かつ合理的なコミュニケーションを通じて、新たな事象について取り組むことが可能となります。 なお、スコープ記述書の作成時には、要求事項を再度調整し要求事項の文書を修正したり、プロジェクト憲章を決裁者の承認を経て改定しなければならなかったりする場合があり、それを何度か繰り返す場合があります。しかし、これらの修正・調整を経て、あらゆる文書がより現実的なものになっていくのです。

［詳細計画のイメージ］計画 09詳細計画に向けての全体像 プロジェクト憲章でプロジェクトの目的や目標が明らかになりました。そして、それを達成させるためのプロジェクトの範囲についてもスコープ記述書で明らかになりました。 次の課題は、「そのプロジェクトの目的や目標を、スコープの範囲内でどう達成させるか」です。そのためにより詳細な計画を作っていきましょう。以降は引き続き、実践的かつ最低限必要な知識と技術を伝えていきます。 目的や目標、プロジェクトの範囲が決まったとしても、それを詳細な計画なしに実行するのは難しいです。まだまだ「段取り」はできていない状況です。 段取りのためには、目的や目標達成に必要な「要素」に分解し、それを「いつ、誰が、どこで、何を、どのように、いくらでやるのか」、「その活動でのリスクは何か」などを明確化しなければなりません。 次の図は、目的・目標そしてプロジェクトの範囲が明確になってから、それをどのように詳細計画するかのイメージです。まずは、目的・目標そしてプロジェクトの範囲を「行動しやすいサイズ」に細分化することから始まります。 例えば、「パソコンを作るプロジェクト」があったとして、その目的や目標、プロジェクトの範囲が決まっていたとしても、それを「いつ、誰が、どこで、何を、どのように、いくらでやるのか」、「その活動でのリスクは何か」などはまだ具体的ではありません。次の項目から最低限必要な計画知識を学んでいきましょう。 ［WBS］計画 10目標達成の要素を導く─WBSとは─ 皆さんは大きなステーキを食べる時にどのように食べますか？ 多くの人はナイフとフォークで細かく切って、ひとつひとつ食べると思います。なぜなら大きなステーキは一度に食べられないからです。 実はプロジェクトも同じです。プロジェクト憲章で設定した目標やスコープ記述書で定義したプロジェクト範囲を一度で達成することは困難です。目標や作業範囲を「要素」に細分化し、ひとつひとつ達成することで、大きな目標を達成していきます。 この目標を要素に細分化し「何をすべきか」を導く技術を WBS（ Work Breakdown Structure：作業分解図）といいます。次の図は単純化した WBSの例です。「車」という最終目標に対し、その最終目標を構成している要素に分解しています。

最終目標を細分化したものを「成果物」といいます。 WBSではさらに成果物を構成している要素に分解します。これを一般的に「要素成果物」といいます。最後に、要素成果物をどう作り出すかを明らかにする「活動」を記載します。 このように要素に分解していくことを一般的に「要素分解」といいます。 WBSでは、最終目標をレベル １、成果物をレベル ２、要素成果物をレベル ３、活動をレベル ４などと表現することもあります。また一般的にレベル ３の要素成果物を「ワークパッケージ」、レベル ４の活動を「アクティビティ」と呼ぶことがあります。 どのくらいのサイズに要素分解すればよいのかという質問が常にあります。例えばステーキを細かく切って食べたい人もいれば、大きく切って食べたい人もいます。細分化が細かすぎるとこの後の進捗管理に工数がかかりますし、細分化が大雑把すぎると進捗情報が見えにくくなります。何度かプロジェクト経験を経て自分に合ったサイズを見つけていきましょう。 ［WBS］計画 11 WBS作成で重要なこと 既述の通り、 WBSでは目標達成のために具体的に「何をすべきか」を導いていきます。 WBSの要素分解の仕方でプロジェクトの作業内容が大きく変わってきます。 例えばパソコンを作るプロジェクトの場合、成果物に「キーボード」があったとしましょう。このキーボードを自社で作り組み立てるのと、外注先企業から納入して組み立てるのでは、その後の要素成果物の内容や活動が大きく変わってきます。つまり WBS作成の段階から目標達成するまでの計画や未来の活動のシナリオが大きく変わってくるのです。 WBSは自社の経営リソース、プロジェクトの期間、コストなどを考え、社内・社外の有識者とともに作成することが望ましいです。大きなプロジェクトになればなるほど、プロジェクトマネージャの過去の知識や経験では対応できない成果物や要素成果物が目標達成のために必要になります。 その時に重要なのは成果物や要素成果物の専門的知識や経験を持った自社または関係会社の有識者です。このような場合、プロジェクトマネージャに求められるのは、有識者との議論を活性化させ、有識者から専門的情報を聞き出し、 WBSにまとめていくファシリテーション能力です。 次に、スコープ記述書にもあったように、プロジェクトには成果物のスコープの他にプロジェクトマネジメントのスコープもあります。 要素分解をするのは成果物に限ったことではなく、プロジェクトマネジメントの範囲も要素分解し WBSにその要素成果物をしっかりと記載しましょう。 わかりやすいところでは、プロジェクトマネジメントでどのような計画書類が完備されるのか、どのような会議や報告書があるのか、そしてそれに必要な活動とは何かなどの要素分解です。 ［WBS］計画 12 WBSの作り方 会議の中で有識者と WBSを作成する一番単純な手法をお伝えします。 プロジェクトマネージャが付箋とペンを持ち、有識者から最終目標を構成する要素を、ファシリテーションを通じて聞き出していきます。プロジェクトマネージャは構成要素を付箋に書き、壁やホワイトボードなどに貼っていきます。 要素を出し終わったら各要素を最終目標（レベル １）、成果物（レベル ２）、要素成果物（レベル ３）に整理し WBSの形にしていきます。その後、各要素成果物を生み出すための活動（レベル ４）を有識者とともに考え、貼っていきます。 最後に、これらの付箋の階層構造をプロジェクトマネジメントツールなどにデータ化したり、ドキュメント化したりしていきます。 この会議は何度か繰り返すこともあります。計画段階でベストな WBSを作っていきましょう。 皆さんの身近にあるものでまずは WBSの要素分解をやってみましょう。 例えば、パソコンや椅子、机、鞄、スマートフォンなど身近にあるものをひとつ選び、どのような要素で構成されているかを観察し、 WBSを作ってみましょう。 WBSのフォーマットは「計画 10」の図を参考にしてください。 パソコンを作る最終目標があった場合に、パソコンはどんな要素でできているでしょうか？ モニター、キーボード、ハードディスク、 OS、アプリケーション、 CPU、メモリ……など様々な要素で構成されていることがわかると思います。それを階層構造にして WBSを作ってみましょう。

［WBS］計画 13プロジェクト成功率を高めるための WBS作成のコツ ① WBSで目標達成のための要素を分解していったわけですが、逆にいうと、これらの要素分解した成果物や要素成果物、活動が全て終わればプロジェクトは完了ということになります。 プロジェクトの実行に移ると、プロジェクトマネージャは、それぞれの要素成果物や活動の進捗確認や完了チェックを行っていきます。 この進捗確認や完了チェックの際、「目に見える、または触れられるもの」と「目に見えない、または触れられないもの」とどちらが進捗確認や完了チェックがしやすいですか？ 「目に見える、または触れられるもの」ですね。 筆者の様々なグローバルプロジェクトの経験では、 WBS作成時によく「 Tangible（タンジブル）：触れて感知できる、有形の」という言葉が使われていました。 例えば、要素成果物であるワークパッケージに「営業」というものがあったとします。この「営業」をどう具体的に進捗確認したり完了チェックしたりするでしょうか？ 担当から「営業実施しました。終わりました」といわれるだけで本当に要求事項に沿って進捗しているか、完了したかをチェックできるでしょうか？ こういった場合、ワークパッケージを「 Tangible」にしましょう。例えば、営業活動前の営業活動計画書、営業活動中の営業先リストや活動報告書、営業活動後の契約書など活動で生み出されるアウトプットなど「 Tangible」なものに要素分解しておけば、プロジェクト実行中のチェックもより具体的にかつ明確にできるようになります。 この他に例えば、「採用」というワークパッケージではなく本当に採用が完了したかを判断できる「雇用契約書」というワークパッケージにする、または「契約」というワークパッケージではなく、本当に契約が完了したかを判断できる「契約書」というワークパッケージにする、なども「 Tangible」の例です。 ［WBS］計画 14プロジェクト成功率を高めるための WBS作成のコツ ② WBSで要素分解をしていくと、数多くの成果物、要素成果物、活動が導きだされます。プロジェクト実行中、これらの進捗確認や完了確認をプロジェクトマネージャがしっかりと行っていく必要があります。 この確認にはプロジェクトチームメンバーとのコミュニケーションが重要になります。そのコミュニケーションを円滑化させるために、各成果物、要素成果物、活動に任意のナンバリングまたはコードをつけましょう。 例えば、「新店舗開店プロジェクト」があったとします。成果物としては、「店舗」「商品」「スタッフ」「マニュアル」「プロジェクトマネジメント」などがあったとします。ナンバリングとは「 10000店舗」「 20000商品」「 30000スタッフ」……などと任意の番号をつけることです。 さらに「 30000スタッフ」の要素成果物として「 30100採用媒体契約書」「 30200採用面接会場申込完了書」……など成果物をさらに細分化した関連する番号でナンバリングするなどします。 「 30200採用面接会場申込完了書」の活動として「 30201会場候補を WEBで探す」「 30202決裁承認を受ける」「 30203申込」……などとさらに細分化し関連する番号でナンバリングしたりします。 プロジェクトでは似たような名称の要素成果物や活動が出てくる場合があります。プロジェクトチームメンバーとの進捗確認で「『申込』ってどの申込ですか？ 商品系ですか採用系ですか？」という非効率なコミュニケーションが発生しかねません。 ナンバリングすることで「 30203の『申込』の進捗を教えてください」、「 30203は現在 50%です」というような効率的なコミュニケーションが実現します。

［WBS］計画 15 WBS辞書を作ろう プロジェクトが大きくなり複雑化すればするほど、 WBSのワークパッケージは多くなります。大きなプロジェクトでは、要素成果物や活動の数が数百を超えることもあります。 この場合、プロジェクト進行中に「この要素成果物って何だったっけ？」と忘れないよう、しっかりと各成果物、要素成果物、活動の内容を明文化しておきましょう。 各成果物、要素成果物、活動の内容を明文化しておく書類を「 WBS辞書」と呼びます。 WBSのフォーマットはエクセルなどで成果物や要素成果物、活動のリストを作成し、そのリストに内容を明文化する方法と、ワードなどで各成果物や要素成果物、活動の内容を明確化する方法などがあります。まさに WBSの各要素の詳細を記した辞書です。 WBS辞書で成果物、要素成果物の内容を明確化する時に重要となる資料がスコープ記述書の成果物スコープです。 既述の通り、スコープ記述書の成果物スコープには様々な機能や仕様、設計、制作に用いる技術や方法論などが記載されています。これらの要求事項や条件と WBSの内容を照らし合わせ、各成果物、要素成果物に必要な機能や仕様、設計、制作に用いる技術や方法論などを WBS辞書に記載しておきましょう。 WBS辞書で活動の内容を明確化する際に重要となるのが、スコープ記述書のプロジェクトスコープの情報です。プロジェクトスコープの情報には作業・活動内容、工程やその計画、作業・活動時の手法や方法論、会議、報告などが記載されています。これらの要求事項や条件と WBSの活動を照らし合わせ WBS辞書に活動の内容を明文化していきましょう。 ［WBS］計画 16 WBSと WBS辞書作成の後にすべきこと WBSと WBS辞書の作成が終わったら、今一度プロジェクト憲章やスコープ記述書を見てみましょう。すると、多くの場合「あれ？ プロジェクト憲章の内容と微妙に違うぞ」「スコープ記述書にこの内容も加えておくべきなのでは？」などと感じることがあるでしょう。 例えば、 WBSを作成することで、「新たな成果物が必要だった」「こんな制約条件があると気がついた」「この範囲もプロジェクトに加えないと目標達成できないことがわかった」など新たな発見があるはずです。 プロジェクトの計画では、計画が進むにつれ、計画内容が「詳細化」されていきます。詳細化されればされるほど、最初に気がつかなかったことに気がついていきます。 WBS作成など、詳細計画をした後には、必ず前工程の文書をチェックし、「整合性が取れているか」を確認しましょう。そして、前工程の文書を改定しなければならない場合、あらかじめ設定した決裁者の承認を経て文書改定をしていきましょう。 この「整合性」をとるための改定はプロジェクト計画時に何度も発生します。グローバルプロジェクトなどではプロジェクト計画時に「 back and forth（行ったり来たり）」という言葉をよく使います。前工程の文書と作成した文書を行ったり来たりして整合性をとっていきます。 この作業は面倒だと思うかもしれませんが、整合性がとれていない計画書は計画書の意味がありません。計画の詳細化をしはじめた時は前工程の文書改定が多いかもしれませんが、そこでしっかりと前工程の文書との整合性をとっておくことで、詳細化がさらに進んだ時の改定は徐々に少なくなっていきます。

［WBS］計画 17スケジュールを策定しよう WBSでは、目標達成のためにどのような成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）が必要かを具体的に導いていきました。つまり「何をすべきか」を明確にしたわけです。 次に、この「何をすべきか」に「時間」という要素を加えていきます。つまり「いつすべきか」を明確にするのです。これがスケジュールの策定です。 スケジュールの策定の最終アウトプットとしては「ガントチャート」などがあります。話を単純化させると「ガントチャート」とは工程表です。皆さんもお仕事やプライベートで工程表を一度は見たことがあると思います。 「何をやるか」のアクティビティ内容が書かれていて、それぞれの内容の開始日・終了日の記載があり、その開始日と終了日の期間を帯状のグラフで可視化させたものが工程表です。 プロジェクト現場では、 WBSを作らず、いきなりガントチャートを作りはじめることがありますが、最低限 WBSを作ってからガントチャートを作成しましょう。なぜなら、 WBSを作成しなければ、成果物、要素成果物（ワークパッケージ）、活動内容（アクティビティ）の抜け漏れが発生してしまう可能性が高まるためです。 WBSは「何をすべきか」を明確にするための技術、ガントチャートはそれを「いつすべきか」を明確にするための技術としっかりと区別して計画しましょう。 ［WBS］計画 18ガントチャートと WBSのつながりとは？ ガントチャートと WBSにはつながりがあります。 このつながりをわかりやすく単純化してお伝えします。皆さんが作られた WBSを左に 90度傾けてみてください。 WBSの一番下の階層（レベル ４）は何だったでしょうか？ そうです、活動（アクティビティ）でしたよね。 WBSを左に 90度傾けると WBSの最下部にあったアクティビティが右側に来ます。ガントチャートの一番左側には通常アクティビティリストがあります。 単純化させると、 WBSの最下部のアクティビティ内容は、ガントチャートのアクティビティ内容と「イコール」になります。この点がガントチャートと WBSのつながりになります。 しかし、スケジュール策定では、単純に WBSのアクティビティをガントチャートのアクティビティリストに何も考えずに配置すればよいというものではありません。ガントチャートにアクティビティを配置する前にやるべきことがあります。次の項目から詳しく見ていきましょう。［アクティビティ］計画 19アクティビティの順序付けとは？ WBSで成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）を導き出したわけですが、これらをどの順序で対応するのかを決めていく必要があります。 例えば、先ほどの例にあった「新店舗開店プロジェクト」があったとします。成果物の一部として、「 10000店舗」「 20000商品」「 30000スタッフ」「 40000マニュアル」などがあったとします。 これらの成果物である「店舗」「商品」「スタッフ」「マニュアル」などは「何かが終わらないと次ができない関係性」にあるのか、「同時並行でできる関係性」なのか、その順序を考えます。 例えば「スタッフ」と「マニュアル」は同時並行でやろうと考えるか、「マニュアル」ができないと、そのマニュアルを対応できる適切な「スタッフ」の採用が実現しないと考えるか、です。 さらに、成果物の要素成果物（ワークパッケージ）においても、同様に順序付けをします。「 30000スタッフ」の要素成果物として「 30100採用媒体契約書」、「 30200採用面接会場申込完了書」……があったとして、「採用媒体契約書」という要素成果物と「採用面接会場申込完了書」という要素成果物を同時並行で生み出すのか、「採用媒体契約書」が確実に納品されてから「採用面接会場申込完了書」を生み出すのか、その順序を考えます。 活動（アクティビティ）においても同様です。「 30200採用面接会場申込完了書」の活動として「 30201会場候補を WEBで探す」「 30202決裁承認を受ける」「 30203申込」……があったとして、どの順序でそのアクティビティをこなすのか、それらは同時並行でできるものなのか、もしくは何かが終わらないとできないものなのかを検討して、アクティビティ

アクティビティ順序付けを行っていきます。［アクティビティ］計画 20アクティビティの順序付けをやってみよう WBSの作り方でも説明したように、アクティビティの順序付けでも WBSを作成した時の専門家や有識者とともに、プロジェクトマネージャがファシリテーションしながら進めていきましょう。 プロジェクトが大きくなり複雑化するにつれて、自分の専門分野以外の「成果物自体を生み出すプロセス」が増えてきます。プロジェクトマネージャは引き続きファシリテーションを通じて、専門家や有識者の視点からアクティビティの順序を聞き出していきましょう。 アクティビティの順序付けをする一番単純な手法をお伝えします。 WBSで使用した成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）の付箋を使います。専門家や有識者と議論しながら、付箋を次の図のような関連性を明確にしたダイアグラムにします。

同時並行でできるものは「並列」にし、何かが終わらないと次ができないものは「直列」に配置し、その順序や関連性を明確にしていきます。アクティビティの順序設定を付箋で行ったら、そのダイアグラム（図形、図式、図解）を文書化しておきましょう。 「計画 12 WBSの作り方」で皆さんが作成した WBSをもとに、アクティビティの順序付けを実践してみましょう。 まずは成果物を図のようなダイアグラムで順序設定してみましょう。 次に、それぞれの成果物の要素成果物（ワークパッケージ）を図のようなダイアグラムで順序設定してみましょう。 最後に、それぞれの要素成果物の活動（アクティビティ）を順序設定してみましょう。［アクティビティ］計画 21アクティビティの順序付けでの注意点 アクティビティの順序付けをすると、 WBS作成時に成果物や要素成果物、活動（アクティビティ）のナンバリングがプロジェクトの進行順になっていないことが多々あります。 例えば、極端な例として Ａ → Ｂ → Ｃ → Ｄというアクティビティ順序で、ナンバリングが Ａ（ 10104） → Ｂ（ 10102） → Ｃ（ 10101） → Ｄ（ 10103）となってしまう場合があります。 この場合はこの段階で Ａ（ 10101） → Ｂ（ 10102） → Ｃ（ 10103） → Ｄ（ 10104）とナンバリングを整理しましょう。この整理が後のガントチャート作成時に役に立ちます。ナンバリングを整理したら WBSや WBS辞書のナンバリングも修正しましょう。

また、アクティビティの順序付けをすると、成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）の区分けを変更したくなる場合があります。 例えば、 Ａと Ｂの 2つのワークパッケージで区分けしていたが、ひとつのワークパッケージにまとめたほうがよい、成果物 Ａの配下に Zというワークパッケージがあったが成果物 Ｂの配下に Zを入れたほうがよい、など成果物、要素成果物（ワークパッケージ）、活動（アクティビティ）の組み換えをしたほうが今後管理しやすいと感じる場合があります。 こういった場合は一旦 WBSに戻り、専門家、有識者と議論しながら、成果物、要素成果物、活動の整理をしましょう。同時にナンバリングなども整理しましょう。［アクティビティ］計画 22アクティビティ期間の見積もりをしよう アクティビティの順序付けができたら、いよいよ「時間」の要素を組み込んでいきます。まずは、それぞれの活動（アクティビティ）にどれだけの期間がかかるかを専門家や有識者とディスカッションしながら導いていきましょう。これを「アクティビティ期間の見積もり」といいます。 一番単純な手法としては、専門家や有識者とディスカッションをしながら、アクティビティの順序付けで利用した付箋に、それぞれの必要期間を書き込んでいきましょう。 図のように、直列するアクティビティの期間の合計で最も長い期間を要する経路が上位の要素成果物（ワークパッケージ）の必要期間となります。 さらに、図のように、直列するワークパッケージの期間の合計で最も長い期間を要する経路が上位の成果物の必要期間となります。 最後に図のように、直列する成果物の期間の合計で最も長い期間を要する経路がプロジェクトの必要期間となります。 このように、アクティビティ期間を明確にしていくことで、最終的にプロジェクトの期間が明確になっていきます。 しかし、プロジェクトでよくあることとして、「アクティビティの必要期間を合計してプロジェクト期間を導いたものの、プロジェクトの完了期日よりオーバーしてしまう」という事象が発生します。 つまり、「プロジェクト期日に間に合わない」という事象です。しかし、この事象は「とある要素」を考慮していないために発生していることが多いのです。 次の項目から、この「要素」についてお伝えします。

［スケジュール調整］計画 23プロジェクトにおける資源を考えよう 既述の通り「アクティビティ期間の見積もり」を実際にやってみて、各アクティビティの必要期間を積算してみると、「あれ？ これではプロジェクトの完了期日までに間に合わないぞ」という事象が発生します。 プロジェクトの完了期日までにスケジュールを合わせていく方法はいくつかありますが、まずは「資源」という要素を考えていきましょう。 プロジェクトでいう「資源」とは、プロジェクトの活動に必要な人、施設、機器、材料、インフラストラクチャ及びツールなどです。 ここで簡単な問題です。 １人が ２か月間で ２ kmの壁を塗装する仕事があります。今回は ２ kmの壁を １か月間で塗装しなくてはなりません。どうすればそれが実現できるでしょうか？ なお、コストの制約や人材の制約はないものとします。 もうおわかりですよね？ そうです。 ２人で １ kmずつ塗装すれば １か月間で収まります。つまり資源という要素を倍にして、時間という要素は半分にしたのです。 上記の問題は「人」という資源の例でしたが、例えば「 １台のパソコンで １か月かかる計算を、倍の計算能力があるパソコンで計算すれば 0. 5か月で完了する」など、機器類やその他の施設、材料、インフラ、ツールなどのあらゆる資源で同様のことを考えていきます。 プロジェクトのアクティビティには、資源を投下することで時間を短縮できるアクティビティと、資源を投下しても時間が短縮できないアクティビティとがあります。 まずは、資源を投下することで時間を短縮できるアクティビティを探し、資源を投下する前提で時間を短縮し、プロジェクトの完了期日に収まるように調整してみましょう。［スケジュール調整］計画 24クリティカルパスとは？ プロジェクトを経験された皆様の中には「クリティカルパス」という単語を聞いたことがある人もいるかもしれません。クリティカルパスとは「プロジェクト又はフェーズにとっての最速完了日を決定する一連のアクティビティ」（ ISO 21500: 2012）です。 もう少し簡単に説明すると、プロジェクトのアクティビティの順序設定と期間見積もりをした後にアクティビティの順序を示す経路の中で、所要期間が「最も長い」経路をクリティカルパスといいます。 クリティカルパスの経路が最も所要期間を要するので、クリティカルパスの終了日がプロジェクトまたはフェーズの最も速い完了日を決定するからです。 さらに単純化させて説明しましょう。 Ａ、 Ｂ、 Ｃ、 Ｄ、 Ｅ、 Ｆというアクティビティがあったとします。 順序は Ａが終わったら Ｂと Ｄができる。 Ｂが終わったら Ｃができる。 Ｄが終わったら Ｅができる。 Ｃと Ｅが終わったら Ｆができるという一部並行して作業ができる順序だったとします。この時のアクティビティの所要期間の見積もりは Ａが ２日、 Ｂが ５日、 Ｃが ５日、 Ｄが ２日、 Ｅが ３日、 Ｆが ４日だったとします。 この時のクリティカルパスは Ａ → Ｂ → Ｃ → Ｆです。なぜなら、 Ａ → Ｂ → Ｃ → Ｆの経路の合計期間は 16日で、 Ａ → Ｄ → Ｅ → Ｆの合計期間の 11日よりも長いからです。 アクティビティ期間の見積もりの段階でクリティカルパスを求めておきましょう。アクティビティの必要期間を合計してプロジェクト期間を導いたものの、プロジェクトの完了期日よりオーバーしてしまう場合には、まずはクリティカルパス上のアクティビティに対して資源などを考慮し、必要期間を最適化していきましょう。

なぜなら、クリティカルパスが最も所要期間が長い経路だからです（所要期間が短い経路を短くしてもプロジェクト全体の期間は短くなりません）。［スケジュール調整］計画 25どうしてもプロジェクト完了期日に収まらなかったら？ プロジェクト完了期日まで間に合わない場合、アクティビティの順序設定を見直したり、既述の「資源」の要素を考えながら各アクティビティの必要期間を最適化したりしながら、スケジュールをプロジェクト完了期日までに間に合うように計画していきます。特にクリティカルパス上のアクティビティを重点的に最適化していきます。 しかし、それでも合理的な理由によりプロジェクト完了期日までに間に合わないという事象が発生する場合もあります。計画が進むにつれ、計画の内容が詳細化され、詳細化されると当初想定していなかった事実や事象を発見することがあります。その時は、前工程の文書類を見て「何が想定と異なっていたのか」を導き出しましょう。 例えば、「当初は成果物 Ａと Ｂは同時並行でできる前提であったが、実際にアクティビティの順序付けを通じて成果物 Ｂは Ａが完了しなければ開始できないという条件が新たに発覚した」「アクティビティ Ａは資源を投下しても期間を短縮できないことがわかった」など、合理的な理由にもとづく事象を明確にしましょう。 これらの合理的な理由をもとに、決裁者と議論しプロジェクト完了期日を改定するか、または特定のスコープをやらないことで期日が間に合う場合はスコープを改定するかを決定しましょう。必要に応じて前工程の文書類を改定しましょう。 実際にアクティビティ期間の見積もりをやってみましょう。「計画 20 アクティビティの順序付けをやってみよう」で作ったダイアグラムをもとにアクティビティの期間、その上位の各要素成果物（ワークパッケージ）の期間、さらに上位の各成果物の期間、最終的にプロジェクト期間を導いてみましょう。そしてクリティカルパスを導いてみましょう。

［ガントチャート］計画 26ガントチャートの中の情報とは？ アクティビティの順序付けと、アクティビティ期間の見積もりが終わったら、その情報をもとにガントチャートを作っていきましょう。 ガントチャートは簡単にいえば工程表ですが、様々な情報がそこに組み込まれています。 企業や組織内でガントチャートのフォーマットが決められている場合もあります。企業や組織によってはガントチャートを専用のアプリケーションソフトウェアを使い、コンピュータ上で作成・管理している場合があります。ぜひ確認してみましょう。 もしもフォーマットなどがない場合は、エクセルなどでも作成できます。ここではガントチャートに入れるべき最低限必要な情報と、ガントチャートに入れておくと便利な情報をお伝えします。 まずは、ガントチャートの全体像を見てみましょう。次の図はガントチャートの全体像を単純化したものです。 ガントチャートに含まれる情報としては、 WBSの情報（アクティビティリスト）、責任分担情報、スケジュール関連情報、進捗情報、スケジュールの可視化情報、マイルストーン情報などがあります。 次の項目から、ひとつずつ詳しく見ていきましょう。

［ガントチャート］計画 27アクティビティリスト情報（ WBSの情報）を入力しよう ガントチャートの左側に並べるのはアクティビティです。すでにお話しした通り、この部分は WBSの情報と同一です。 まず、 １番左には WBSの成果物をアクティビティの順序付けで作ったダイアグラムの順番またはナンバリングの順番で上から配置していきましょう。 次に、それぞれの成果物の右側にそれぞれの成果物の配下にある要素成果物（ワークパッケージ）を配置していきます。要素成果物もダイアグラムの順番またはナンバリングの順番で上から配置します。 最後に、それぞれの要素成果物の右側にそれぞれの要素成果物の配下にある活動（アクティビティ）を、ダイアグラムの順番またはナンバリングの順番で上から配置しましょう。 ここで重要なのは「ダイアグラムの順番」で、上から配置していくということです。 プロジェクトが実行に移ると、プロジェクトマネージャはもちろんのこと、チームメンバーをはじめ多くの関係者がガントチャートを見ながらプロジェクトの進捗や工程を確認します。 その時にアクティビティのリストが対応順に上から順番に整理されていない場合、「次はどのアクティビティをするんだ？」と迷ってしまったり、最悪の場合アクティビティを見過ごしてしまったりする可能性があります。 「このアクティビティが終わったら次はこれだな」と容易に確認できるよう、対応順に上から順番に整理してリストを作っていきましょう。［ガントチャート］計画 28責任分担の情報を入力しよう プロジェクトマネジメントの文書のひとつとして「責任分担表」というものがあります。縦軸にアクティビティリスト、横軸に対応者の個人名や組織名が書かれた表です。 一般的にこの責任分担表を RAM（ Responsibility Assignment Matrix）や TRM（ Task Responsibility Matrix）などと呼ぶこともあります。この表では、それぞれのアクティビティに対し、各個人や組織がどの役割を担っているのかを明確にします。 一般的に、表の中には役割の頭文字を入れていき役割を明確にします。 例えば、 Ｒ（ Responsible：実行責任者）、 Ａ（ Accountable：説明責任者）、 Ｃ（ Consult：相談対応者）、 Ｉ（ Inform：情報提供先）や、 Ａ（ Approver：承認者）、 Ｍ（ Management：管理者）、 Ｓ（ Supporter：支援者）などを表に書き込み、各アクティビティでの役割を明確にします。 これらの頭文字が何を表しているのか関係者がわかるように、事前に関係者と文書で取り決めしておくか、または責任分担表の近くに各頭文字を説明する「注釈」をつけておきましょう。 また、各役割、特に実行責任者や支援者の人数は、アクティビティ期間の見積もりで考慮した「資源」も考慮し設定しましょう。 プロジェクトの関係者が多い場合、責任分担表をガントチャートとは別に作成しますが、プロジェクトの関係者がそれほど多くない場合、ガントチャートに責任分担表を組み込むことをお勧めしています。 なぜなら、ガントチャートに責任分担表を入れることにより、「いつ、だれが、何を」実施するのかという情報をガントチャートひとつで確認できるからです。

［ガントチャート］計画 29責任分担表の注意点 責任分担表で見かけるのが、役割を役割の頭文字ではなく ○ ×で記載しているパターンです。アクティビティを完了させるには担当者、承認者、支援者などの様々な役割が必要となります。 ○ ×だけではこれらの役割の情報を明確にしづらいため、既述の役割の頭文字を使い、各アクティビティで誰が何の役割を担っているのかを明確にしましょう。 責任分担表の横軸に記載する登場人物が部署名のみということがありますが、登場人物を個人名にすることをお勧めしています。部署名のみの記述だと、「誰が各アクティビティのどの役割を責任を持って対応するのか」が明確ではありません。極力部署名の他に個人名を入れましょう。 責任分担表の役割の中で、ひとつのアクティビティに「実行責任者」がとても多く設定されている場合があります。例えばひとつのアクティビティに対し、 ５名の「 R：実行責任者」が設定されている場合です。 これだと、誰が「責任者」かが明確ではありませんし、最悪の場合、責任の押し付け合いや「誰かがやるだろう」と考えてしまう場合もあります。実行責任者は １名 ～ ２名に限定し、実行責任を担う人を明確にしましょう。 ガントチャート作成段階で、全ての関係者またはチームメンバーが決定していない場合もあります。その場合、アクティビティ期間の見積もりで考慮した「資源」をもとに必要人数を導き、登場人物の「枠」を作っておき、「未定」などと記載し、今後決定し次第、個人名や組織名を記載できるようにしておきましょう。［ガントチャート］計画 30開始日と終了日を入力しよう 各アクティビティに対して開始日と終了日を設定していきます。アクティビティ順序付けで導いた順番で、アクティビティ期間見積もりで導いた各アクティビティの必要期間を考慮し、開始日と終了日を設定していきましょう。 例えば、アクティビティが Ａ（ ２日） → Ｂ（ ２日） → Ｃ（ １日）の直列の順番で、開始日が８月 １日の場合、 Ａの開始日は８月 １日、 Ａの終了日は８月 ２日、 Ｂの開始日は８月 ３日、 Ｂの終了日は８月 ４日、 Ｃの開始日は８月 ５日、 Ｃの終了日は８月 ５日のように、各アクティビティに実際の開始日と終了日を設定していきます。 要素成果物（ワークパッケージ）配下のアクティビティの開始日と終了日が設定し終わったら、その一連のアクティビティの最初のアクティビティの開始日と最後のアクティビティの終了日が、要素成果物（ワークパッケージ）の開始日と終了日になります。 例えば、先ほどの例ですとアクティビティ Ａ → Ｂ → Ｃの上位にある要素成果物の開始日は８月 １日、終了日は８月 ５日になります。 成果物配下の各要素成果物の開始日と終了日が設定し終わったら、その一連の要素成果物の最初の要素成果物の開始日と最後の要素成果物の終了日が、成果物の開始日と終了日になります。 最後に、各成果物の開始日と終了日が設定し終わったら、その一連の成果物の最初の開始日と最後の終了日がプロジェクトスケジュールの開始日と終了日となります。 ガントチャートの終了日の項目の右側に「残日数」という項目を設定しておくと、プロジェクト実行中の進捗管理に便利です。エクセルなどで終了日から「本日」を引き算する関数

関数を入れ、自動計算させると簡単に設定できます。［ガントチャート］計画 31開始日と終了日設定時の注意点 各アクティビティに実際の開始日と終了日を設定する際に注意すべき点がいくつかあります。 まず、土日祝日は稼働日なのか否かなどを考慮する必要があります。そして企業や組織特有の創立記念日や夏期休暇、年末年始の休暇などを考慮する必要があります。 さらにプロジェクトで顧客や関係会社、サプライヤの人々と仕事をする場合、これらの企業や組織の土日祝日稼働、その他休暇などを考慮する必要があります。 グローバルプロジェクトで他国の人々がプロジェクトに参加する場合、その海外法人の土日祝日、その他休日を確認する他に、時差や特徴的な文化も考慮する必要があります。 これらを考慮し開始日と終了日を設定した結果、プロジェクトの完了日に間に合わないという場合もあるかもしれません。 その場合は、改めてアクティビティの順序付け、アクティビティ期間の見積もりを再検討します。特にクリティカルパス上のアクティビティの順序、期間、資源をまずは見直し、プロジェクト期間全体の最適化をはかりましょう。

［ガントチャート］計画 32進捗情報を明示する項目を作っておこう 開始日、終了日、残日数の右側に「進捗率」という項目を準備しておきましょう。これはプロジェクト実行中の進捗確認に役立ちます。プロジェクト実行中に、プロジェクトマネージャが各アクティビティの担当者に連絡し、進捗を確認、進捗率を入力していきます。 まれに、進捗率を感覚的に記載してしまうことが散見されます。 例えば Aのアクティビティは現在進捗率 63%などと記載してしまう場合です。このような場合、ガントチャートを見たステークホルダーは「 63%の根拠は？」と疑問を持ちます。さらに根拠を確認するという非生産的なコミュニケーションも発生してしまいます。 事前に進捗率に関するルールを決め、関係者と文書で取り決めしておくか、または進捗率を説明する「注釈」をガントチャートに明記しておきましょう。 進捗率で一番単純な例では「 50%－ 50%ルール」というものがあります。 0%－未対応、 50%－実行中、 100%－完了というルールです。 これ以外にも、 0%－未対応、 25%－準備中、 50%－実行中、 75%－最終チェック中、 100%－完了とするなど、プロジェクトでのルールとして何%が何のステータスなのかをルールとして決めることが重要です。 その他に、例えば、要素成果物（ワークパッケージ）配下の全てのアクティビティ進捗率の平均値をワークパッケージの進捗率とする、成果物配下の全てのワークパッケージ進捗率の平均値を成果物の進捗率とする、全ての成果物の進捗率の平均値をプロジェクトの進捗率とする、などのルールを設定し、プロジェクト実行中の進捗管理や、定期レポーティングに備えておきましょう。［ガントチャート］計画 33スケジュールを可視化しよう 各アクティビティ、要素成果物（ワークパッケージ）、成果物の開始日と終了日を可視化していきましょう。可視化には期間を帯状のグラフ、バーチャートなどで表すことが一般的です。 横軸に時間要素（例えば日や週の情報）が設定されている表に、縦軸にある各アクティビティの開始日から終了日までを帯状のグラフ、バーチャートで表します。これを要素成果物（ワークパッケージ）、成果物でも行います。 グラフにより可視化することで、ガントチャートを利用する人が、「このアクティビティが終了したら、次はこのアクティビティに着手するんだな」「このアクティビティは残り期間が半分だ」などと直感的にスケジュールを確認することができます。 皆さんがこの可視化作業をすると気づくことがあります。それは、事前にアクティビティを順序通りに上から下に整理していたため、バーチャートが左上から右下に段々畑のように、そして水が流れるように表現されます。 事前にアクティビティの順序通りに整理していなかったらどうでしょう。バーチャートが秩序なく表現されてしまい、可視化の意味がなくなってしまいます。 このように水が流れるように、上流工程が終わったら次の下流工程に進むことを表す言葉として「ウォーターフォール（ waterfall）」という言葉が使われます。上流工程が終わったら次の下流工程に進むプロジェクトを、一般的にウォーターフォール型やウォーターフォールモデルなどと呼んだりします。

［ガントチャート］計画 34ガントチャートにマイルストーン情報を入力しよう ガントチャートにはマイルストーンの情報を必ず入れましょう。 ここで質問です。マイルストーンの情報については前工程の文書に明記してあります。それはどの文書でしょうか？ そうです、プロジェクト憲章に明記してあります。プロジェクト憲章の情報をもとに、ガントチャートにマイルストーンの日付をしっかりと記載し、さらに可視化させておきましょう。 プロジェクト憲章の情報にしたがってマイルストーンをガントチャートに明確にすると、気がつくことがあります。 例えば、マイルストーンの Ａは要素成果物 Ｚがしっかりと要求通りに完成したかをチェックするクオリティーゲートなのに、マイルストーン Ａの日よりも要素成果物 Ｚの終了日のほうが後の日付になっているなどです。 スケジュールを策定中は順序、期間、資源、土日祝日の稼働日、その他休暇などの様々な条件を考慮して具体的なスケジュールを策定していますから、前工程のプロジェクト憲章で設定したマイルストーン日と整合性がとれていない可能性があります。このような場合は、あらかじめ設定した決裁者の承認を経てプロジェクト憲章を改定しましょう。 もしも、プロジェクト憲章で設定したマイルストーンが絶対に変更できない日であれば、再度アクティビティの順序、期間、資源などを検討しスケジュールを見直していきましょう。［ガントチャート］計画 35クリティカルパスや依存関係ネットワークを明確にすると便利 以降はガントチャートに「ひと手間」加えておくことで、今後のプロジェクト実行でガントチャートを使ったプロジェクト進捗管理が便利になる方法をお伝えします。 ガントチャート上でクリティカルパスを明確にしておきましょう。 例えば、クリティカルパス上のアクティビティの期間を表すグラフ、バーチャートのバーなどを違う色で表現するなどです。 プロジェクトが大きくなり複雑化すると、同時に多くのアクティビティが実行されます。この時、最優先で進捗管理やコントロールしなければならないのがクリティカルパス上のアクティビティです。 なぜなら、すでに述べたように、クリティカルパスはプロジェクトの期間を決定づける最長のルートであり、ここが遅延してしまうとプロジェクト全体も遅延してしまうからです。 プロジェクトマネージャがクリティカルパスを容易に認識できるようにしておくことをお勧めします。 アクティビティの順序付けで作成したダイアグラムをもとに、ガントチャート上に各アクティビティの依存関係を表すネットワークパスを明確にしておきましょう。こうすることで、プロジェクト実行中にガントチャートを利用する人たちが、アクティビティの順番や依存関係を認識しやすくなります。 アクティビティの期間を表すグラフ、バーチャートのバーなどを順序や依存関係に応じて線で結び、依存関係のネットワーク

ネットワークを表現しておくのがいいでしょう。［ガントチャート］計画 36「実績」や「現在」を表現する部分を設けると便利 プロジェクトの実行に移ると、プロジェクトマネージャは、アクティビティの進捗確認や実績確認をするとともに、ガントチャートを見ながら計画と実績の差を分析し、プロジェクトをコントロールしていきます。 その時に容易に計画と実績の差を確認できるように、ガントチャート内に実績を表す場所を設けておくことをお勧めします。 例えば、アクティビティの期間を表すグラフ、バーチャートの計画を表すバーの下に実績のバーを表す場所を設けておくなどです。こうすることで、プロジェクト実行中に計画と実績の差が視覚的に認識でき、現在の状態から後工程のスケジュールがどうなるのかが考えやすくなります。 「現在」がどこなのかを表現するものをガントチャートに入れておきましょう。 プロジェクト実行中には定期的にプロジェクト進捗をしかるべきステークホルダーにレポーティングします。そのレポーティングでガントチャートを利用する場合、「現在」はどこなのかを明確にすることで、アクティビティの進捗遅れなどが容易に確認できたり、プロジェクトチームメンバーにアクティビティの進捗や時間の概念を意識付けることができたりします。 例えば、「現在」の前で終了するべきアクティビティが明確になり、進捗管理やチームメンバーのスケジュール遅延の意識付けができます。 また、チームメンバーに時間の概念を意識してもらうために「残日数」に応じて「シグナル」を表現することもあります。 例えば、残日数が 30日以上だと青信号、 14日以上 30日未満だと黄色信号、 ０日以上 13日未満だと赤信号などと表現し、チームメンバーが注意すべきアクティビティを表現することもひとつの手です。

［ガントチャート］計画 37ガントチャートを作ってみよう ここまでガントチャートの説明をしてきました。実際のプロジェクトでガントチャートが完成したら、それまでのように前工程の文書類を必ず見直し整合性が取れているか、新たに加えるべき情報はないか確認し、必要に応じてあらかじめ設定した決裁者の承認を経て改定しましょう。 プロジェクト憲章、スコープ記述書、 WBS、 WBS辞書、ガントチャート、これらの文書作成のために作った関連文書などが、整合性が取れているか確認しましょう。 また、ついつい忘れてしまいがちなのがステークホルダー登録簿の中の情報をアップデートすることです。計画が進むにつれて、計画が詳細化していきます。詳細化に応じて、新しいステークホルダーが出てきたり、ステークホルダーの要求事項、関心事項、影響度、興味・関心度が変わってきたりします。必要に応じてアップデートしましょう。 実際にガントチャートを作ってみましょう。 「計画 12 WBSの作り方」で皆さんが作成した WBSと、その後に導いたアクティビティの順序付けやアクティビティ期間の見積もりをして導いたダイアグラムなどを用いて、ガントチャートを作りましょう。 架空の登場人物を設定し責任分担表を作ってみたり、開始日、終了日、マイルストーンなどの情報は任意の日付を設定して作ってみましょう。 実際にガントチャートを作ってみることで、本書で紹介した様々な内容をより理解できることでしょう。必要に応じて、以前の項目などを確認しながら作成しましょう。ガントチャートのフォーマットは「計画 26 ガントチャートの中の情報とは？」を参考にしてください。［時間余裕（バッファ）］計画 38時間余裕（バッファ）の考え方 筆者の数々の企業に対するプロジェクトマネジメント教育研修やプロジェクトの実行支援の提供を通じて、スケジュール策定の際、よく聞かれることがあります。それは、時間余裕としてのバッファは設けるべきかという質問です。時間余裕といっても時間だけで考えてはいけません。 例えば、月に 1, 000万円のコストがかかるプロジェクトを 12か月実行すればコストは 1. 2億円かかります。これに時間余裕を １か月持ちプロジェクト期間を 13か月にすることにより、単純計算すれば 1. 3億円のコストが発生します。そうなるとプロジェクトの ROI（投資対効果）は低下します。これをよしとする企業・組織文化か否か、企業・組織の現在の財務状況はどうなのかを考える必要があります。 また、ステークホルダーによってもプロジェクトチームメンバーはバッファを欲しいと思うことが多いかもしれませんし、一方で経営層は ROIを高めるためにバッファがないことを望むかもしれません。これらを考慮する必要があります。 皆さんは「学生症候群」や「パーキンソンの法則」という言葉を聞いたことがあるでしょうか。 簡単にいうと「学生症候群」とは、時間余裕を与えたとしても最初にその時間余裕を使ってしまう傾向を表すものです。 例えば、 １時間で終わるレポートの宿題の提出日が ２週間後だった場合、時間余裕は 13日と 23時間あるわけですが、先にこの時間余裕を使ってしまい提出前にバタバタする状況です。 「パーキンソンの法則」でも「仕事の量は、完成のために与えられた時間を全て満たすまで膨張する」といわれています。つまり計画で時間余裕を設定したとしてもそれを無駄に使ってしまう可能性もあります。

［時間余裕（バッファ）］計画 39時間余裕（バッファ）を組み込む場合はどうするか？ 前項目で説明した ROIの低下や、学生症候群、パーキンソンの法則を防止したい、だけどチームメンバーがアクティビティの期日までに終わらないリスクがあるので、そのリスクを緩和したいなどの理由で、プロジェクトマネージャがどうしても時間余裕を持っておきたいという場合の時間余裕（バッファ）の設定の仕方をお伝えします。 各チームメンバーはそれぞれのアクティビティに対して時間余裕を欲しがる可能性があります。しかし、うまくアクティビティが進めば時間余裕は必要ありませんし、うまくアクティビティが進んだとしても学生症候群やパーキンソンの法則にあるように時間を無駄に費やしてしまうかもしれません。これは可能性の問題です。 したがって、各アクティビティでチームメンバーが欲しいと思うバッファをまとめて全てをプロジェクトの最後にバッファを設定しておくのです。 例えば Ａ → Ｂという工程があり、「 Ａ：作業期間 ２日、時間余裕 １日」「 Ｂ：作業時間 ５日、時間余裕 １日」だったとしたら、 Ａ： ３日 → Ｂ： ６日と設定せず、計画上は Ａ： ２日 → Ｂ： ５日の実作業期間で計画し、 Ａ： ２日 → Ｂ： ５日 →バッファ： ２日などとバッファの合計をプロジェクトの最後に設定します。 このバッファ ２日間をチームメンバーに開示しない場合もありますが、開示したとしても、この対策をすることで、各アクティビティの活動時間を無駄にすることを軽減し、さらに不測の事態が発生した場合でも時間余裕を使えます。この施策は、クリティカルパス上のアクティビティを中心に行うことが多いです。なぜなら、クリティカルパスはプロジェクトの全体期間を決めるからです。［コストの見積もり］計画 40コスト計画を策定しよう─資源が動けばコストがかかる─ 経営資源であるヒト、モノ、ジョウホウ、ジカンが動けばカネが動きます。スケジュール策定までで、皆さんはいつ・誰が・何をするのかを導きました。次は、いつ・誰が・何を・「いくらで」やるのかコストの要素を計画に組み込んでいきましょう。 プロジェクトが大きくなり複雑化するにつれて、お金が出ていく（キャッシュアウトする）タイミングが極めて重要な要素となります。これらを明確にしていきます。 プロジェクトマネジメント計画では、最低限「コスト管理表」を作成します。このコスト管理表とガントチャートにはつながりがあります。このつながりをわかりやすく単純化してお伝えします。 例えば、次の図にガントチャートのバーがあります。アクティビティ Ａは８月 １日 ～ 31日、アクティビティ Ｂは９月 １日 ～ 30日に活動します。

どのようなアクティビティでも人や装置・機器類、原材料、作業場所、ツールなどの資源が必要になります。資源にはコストがかかります。そのコストは前払いかもしれませんし、後払いかもしれません。なかにはプロジェクト開始から終了まで定期的に支払うものかもしれません。 これらを考慮し、「いつ」「いくら」コストがかかるのかを見積もりし、明確にしていきます。丁度ガントチャートのバーチャートがお金で表現されているようなイメージです。後に詳しく述べる「コスト管理表」は皆さんと親和性があるかもしれません。コスト管理表はラインマネジメントで利用する予算の予実管理表（予測実績管理表）に似ています。 全てのアクティビティに必要なコストが見積もれると、プロジェクト全体の必要コストが導き出せます。このプロジェクト全体の必要コストがプロジェクト予算となります。［コストの見積もり］計画 41コストの見積もりの前に決めておくべきこと コストの計画のためには「見積もり」が必要です。この見積もりをする前に決めておいたほうがよいことがあります。以下に紹介することは、プロジェクト憲章やスコープ記述書に明文化しておくことが望ましいです。 プロジェクトのコストの範囲を明確にしておきましょう。例えば、人件費、地代家賃は全社コストなのでプロジェクトコストではない、原材料はプロジェクトコスト……などです。プロジェクトのコストの範囲をプロジェクト憲章の「予算」項目などに明確にしておくことが望ましいです。 コストの見積もりをする際の「通貨」を決めておきましょう。コストの計画では１つの通貨で表現することが望ましいです。 円、ドル、ユーロなどどの通貨で表現するのかを、プロジェクト憲章の「予算」項目やスコープ記述書の「プロジェクトスコープ」項目などに明確にしておきましょう。 このような複数の通貨を使うプロジェクトの場合、事前に為替レートを設定しコスト計算を行いましょう。［コストの見積もり］計画 42コストの見積もりの手法は３つある コストの見積もり手法には、一般的に３つの手法があります。またこれらの３つの手法を合わせて使うこともあります。見積もりを作成した、または取得したことがある人は親和性のある手法です。 ３つの手法とは「類似見積もり」「係数見積もり」「積算見積もり」です。 「類似見積もり」とは、過去の類似プロジェクトや、企業や組織で以前に取得した見積もりを参考にする手法です。例えば、アクティビティ Ａのために Ｚという機器が必要だが、 Ｚは過去のプロジェクトで購入実績があり、その時の見積もりを参考にして見積もるという方法です。 「係数見積もり」は、その名の通り係数を使った見積もり手法です。例えば「過去に １ kmの壁を塗装するのに 50万円かかった。今回は ２ kmの壁を塗装する。コストはいくらか」といった場合です。この場合 １ km = 50万円なので、 50万円 × ２ km = 100万円などと係数を利用しコスト算出します。 「積算見積もり」とは、コストが見積もれるまでワークパッケージやアクティビティを詳細化し、それらを積算しコスト算出する方法です。例えば、アクティビティ Ａは担当が 0. 5人月で、地代は、原材料費は、機器類が……などと要素ごとにコスト算出した後、すべてを積算しアクティビティ Ａのコストを導く場合です。 プロジェクトでのコストの見積もりでは、これら ３手法を合わせて使います。 例えばアクティビティ Ａは類似見積もり、アクティビティ Ｂは係数見積もりといった具合に、各アクティビティの見積もりに最適な手法を選びます。なかには、アクティビティ

の一部分は積算見積もり、その他は係数見積もりといったように手法をミックスする場合もあります。［コストの見積もり］計画 43コストの見積もりを体験してみよう コストの見積もりでは、他の計画書類を作成するのと同様に、有識者や専門家とディスカッションしながら進めていきます。コストの見積もりは、アクティビティ単位またはワークパッケージ単位で行っていきましょう。 プロジェクトが大きくなり、複雑化すると、自分の専門分野では対応できないこともあります。ここでもプロジェクトマネージャはファシリテーションを通じて有識者や専門家から情報を聞き出していきましょう。 プロジェクトによっては、有識者や専門家に外部サプライヤなどの見積もりの取得を依頼することもあります。有識者や専門家の人的ネットワークや専門知識を生かしたほうが見積もりを短期に取得できたり、有利な条件で取得できたりする可能性があるからです。 アクティビティのコストの合計がその上位の要素成果物（ワークパッケージ）のコストになります。要素成果物のコストの合計がその上位の成果物のコストになります。成果物のコストの合計がプロジェクトの必要コスト、すなわちプロジェクト予算になります。 実際にコストの見積もりを体感してみましょう。「計画 12 WBSの作り方」以降で皆さんが作成した WBSやガントチャートをもとにコストの見積もりをしてみましょう。 ここではあくまでも体験ですから、各アクティビティに必要な資源をイメージし、だいたいいくらぐらい必要かを算出していってください。各資源の価格などをインターネットで調べてみてもよいかもしれません。 ここで重要なことは、各アクティビティのコストを見積もり、それらを合計し各要素成果物、各成果物、プロジェクトのコストを算出するプロセスを体感することです。［コストの見積もり］計画 44リスク対策にもお金がかかることに注意 コストの見積もりを体感いただきました。このコストの見積もりでは主にガントチャート上のアクティビティ、要素成果物（ワークパッケージ）、成果物に関するコストを見積もりました。 しかし、プロジェクトのコストはこれ以外にもあります。それはリスク対策のコストです。詳しくはリスク計画に関する項目で説明しますが、一般的にプロジェクトでは様々な未来のリスクに備えます。その備え自体にコストが必要になってきます。 このリスク対策のコストを考慮せずにコストの見積もりを行うと、リスク計画後にリスク対策コストが加わることにより、プロジェクト予算をオーバーしてしまう可能性があります。 これを防止する方法として、プロジェクト憲章の「予算」項目に「リスク対策予算」としてあらかじめ予算を明確化しておくか、または「主要リスク」の項目に主要リスクの対策費を明確化しておくなどの方法があります。

［コスト管理］計画 45スコープ vs時間 vs資源 vsコストの視点 各アクティビティのコストを合計し、各要素成果物（ワークパッケージ）、各成果物、プロジェクト全体のコストが算出されると、とある事象が発生する場合があります。それは「予算オーバー」です。具体的にはプロジェクト憲章で決定しているプロジェクト予算の範囲に収まらないという事象です。 実は、プロジェクト計画で重要なことは、スコープ、時間、資源、コストの４つの視点を持ってバランスよく計画をするということです。 コストの見積もりが終了すると、この重要な４つの視点の最後のパーツである「コスト」が可視化されます。ここからがプロジェクトマネージャの腕の見せ所です。 例えば、すでに述べたスケジュール策定の部分では、アクティビティの順序設定を最適化してもスケジュールがプロジェクトの完了期日までに間に合わない場合、「資源」という要素を投入することで「時間」を短縮しました。しかし資源の投入は同時にコスト増にもつながります。 さらに、スコープが広いと時間とコストがかかります。しかし、時間とコストを優先しすぎると、プロジェクトの本来の目的や目標が達成できない場合もあります。 このように、スコープ、時間、資源、コストは連携しているのです。 プロジェクトマネージャはプロジェクトの目的や目標、ステークホルダーの関心事項や要求事項などを考慮しながら、この４つのバランスをもって計画を策定していくことが求められます。 プロジェクトによっては、スコープ、時間、資源、コストのどれを優先するかを決裁者と決めた上で調整する場合や、制約条件でスコープ、時間、資源、コストのどれかを優先し計画せざるをえない場合もあります。［コスト管理］計画 46コストオーバー時に最低限やるべき３つの対応 コストオーバー時にまず確認すべきは、コスト見積もりの精度です。見積もりに不要なコストが入っていないか、適正な単価設定や算出根拠か専門家と有識者とで改めてチェックしましょう。その時、最低限やるべきことは３つあります。 まずは、関係部署、関係会社、外部サプライヤなどから見積もりをとっている場合は、必要に応じて交渉しコスト最適化に努めましょう。 スケジュール策定で説明したように、スケジュールだけではなく、コストの部分でも見積もりをする際にコスト余裕（バッファ）を含んでいる場合があります。これらもチェックしコストの最適化に努めましょう。 ２つめは、スコープ記述書やステークホルダーの要求事項、 WBS、 WBSの辞書の文書を今一度見直しましょう。 既述の通り、要求事項の収集の際に「優先順位付け」を行いました。改めてステークホルダーと議論し、スコープを調整していくことが求められます。 特に、優先順位の低い要素から議論しコスト最適化に結びつけましょう。例えば、優先順位の低いスコープの要素は、その要素がなくとも本質的なプロジェクトの目的・目標を達成できるかもしれません。 また、スコープの要素を何かで代替することでコストを削減できないかも検討しましょう。例えば、〇〇の部品を自社で生産する計画だったが、関連会社の代替部品を使用するなどです。 重要なことは、「プロジェクトの目的や目標達成のために、本当にこの要素やプロセスが必要なのか」、「何かに代替

代替することができないか」という視点をプロジェクトマネージャが持つことです。 ３つめは、アクティビティの順序付けやアクティビティの期間の見積もりで作成したダイアグラムやガントチャートを今一度見直しましょう。 「時間」という概念の中では、クリティカルパス上のアクティビティを重点的に調整しましたが、「コスト」という概念の中ではクリティカルパス以外のアクティビティも厳重にチェックします。 クリティカルパス以外のパス上のアクティビティは、プロジェクト全体の期間に影響を及ぼさないアクティビティですから、その順序設定を最適化することで資源を有効活用しコストを最適化できないかなどを考えます。 例えば、クリティカルパス以外のパス上で、同時並行で動いているアクティビティを直列にすることで、人材や装置・機器類の資源を有効活用し必要人数や必要台数を削減できないかという発想などです。 上記のような合理的かつ建設的な調整を通じてコストが最適化された場合、前工程の文書を改定し、あらかじめ設定した決裁者の承認を得ましょう。 調整をしても合理的な理由によりコストがオーバーする場合、あらかじめ設定した決裁者に合理的な理由を説明し、調整を経て、プロジェクト予算の改定承認を得ましょう。 こうした場合も前工程の文書で関連する部分を改定しましょう。［コスト管理］計画 47コスト管理表とは？ 算出したコストを「コスト管理表」にまとめます（コスト管理表の例は次項の図参照）。 コスト管理表で最低限必要な情報を紹介します。コスト管理表は縦軸にガントチャートと同様のアクティビティリストを記載します。横軸には月や週、日などの時間軸を記載します。この表の中には、算出した各アクティビティで必要なコストを、時間軸を考慮しながら入力していきます。 少々細かい話になってしまいますが、この時、経理や財務部門からの要求事項やサプライヤや納入先の要求事項を考慮しながら入力しましょう。 例えば、先払いか後払いか、財務諸表上の買掛金になる月にコストを入力するのか、それとも実際のキャッシュアウトの月にコストを入力するかなどです。 各アクティビティのコストを合計した要素成果物（ワークパッケージ）のコスト、そして要素成果物を合計した成果物のコスト、成果物を合計したプロジェクトのコスト（予算）、それぞれの月や週、日などのコストを明確にしましょう。 プロジェクト実行中には、このコスト管理表を使ってコストの予実管理をしていきます。今後のコスト管理のために同様のコスト実績用の表を作っておきましょう。またコスト予算と実績の差や予算消化率を明確にする項目を作っておきましょう。時間軸に沿って予実の差をグラフ化する場合もあります。 なお、プロジェクトで財務・経理や労務に関わる計算をしなくてはならない場合、当該コスト管理表の縦軸を財務上の勘定科目にしたものを別途用意する場合があります。 例えば税務上の計算、減価償却費計算、社会保険料や労働保険料などの計算が必要な場合などです。必要に応じて作成しましょう。［コスト管理］計画 48コスト管理表を作ってみよう 企業や組織によっては、コスト管理表と同様のものが、 ITシステムのアプリケーションとして完備されている場合があります。アプリケーションでなかったとしても、決められたツールのフォーマットがあるかもしれません。皆さんの企業や組織の中で一度確認してみましょう。 コスト管理表のアプリケーションやツール類が完備されていなかったとしても、エクセルなどで作成しコストを明確にしていきましょう。 実際にコスト管理表を作り体感してみましょう。 「計画 43 コストの見積もりを体験してみよう」で導いた各アクティビティ、各要素成果物（ワークパッケージ）、各成果物のコストをもとに、コスト管理表にコストを入力していきましょう。コスト管理表のフォーマットは次の図を参考にしてください。 この体感で重要なことは、コスト入力時に「時間」の要素を組み込むということです。そのためにガントチャートも確認しながら入力をしていきましょう。 作成し終わったら、プロジェクトのいつ一番コストがかかるかを見てみましょう。通常のプロジェクトでは、いつにいくら必要かが経営者、プロジェクトスポンサー、経理・財務担当などのステークホルダーにとって非常に重要な情報になります。 プロジェクトによっては事前に資金調達などが必要な場合があります。実際のプロジェクトではこれらのコスト計画を策定した時点でコストに関心があるステークホルダーに情報共有することをお勧めします。

［コスト管理］計画 49コスト余裕（バッファ）の考え方 筆者の数々のプロジェクトマネジメント教育研修や実行支援事業の中で、スケジュール余裕と同じく、コスト余裕（バッファ）に関する内容を聞かれることがあります。 残念ながら、企業や組織で潤沢なコスト余裕を持たせてくれるプロジェクトはあまりないでしょう。特に、経営者層やプロジェクトスポンサー、投資家、金融機関などのステークホルダーは、プロジェクトを行った上での ROIが関心事項であることが多いため、コスト余裕を計画時に計上することをよしとしないことが多いでしょう。 営利企業や組織の場合は、売上を上げる、経費を下げる、利益を上げる、投資効果を高めるというような企業としての命題があります。コスト余裕を持てば、それだけプロジェクトの ROI（投資対効果）は低下します。 また、もしも潤沢なコスト余裕を持たせてくれたとしても、スケジュール策定の項目で紹介した学生症候群やパーキンソンの法則のように、コストという資源の余裕を無駄に使ってしまうかもしれません。 しかし、それでも予算超過リスクのためにコスト余裕を持ちたいという場合は、スケジュール策定の時と同様に、個別のアクティビティ、要素成果物、成果物にはコスト余裕を設けず、これらのコスト余裕の合計をプロジェクト全体で予備予算として有しておくことをお勧めします。 企業や組織の中には、これらの予備予算をプロジェクトチームメンバーには開示しない場合もあります。また、これらの予備予算の申請・決裁などのルールを明確にしておきましょう。［リスク］計画 50リスク対応計画に入る前にゲームをしよう ここでゲームをしてみましょう。これはもともと数学の問題です。 あなたの目の前に３つのドアがあります。このうち、１つのドアの後ろには １億円の宝物があります。残り２つのドアの後ろには何もありません。あなたは３つのドアのうち、１つを選び、選んだドアを開いた時に宝物があれば宝物をもらえます。 あなたが１つのドアを選んだ後に、私が残りの２つのドアのうち後ろに何もないドアを１つ開いて「このドアには宝物がありません」とあなたに見せます。そして私は「今なら一度選択をしたドアをまだ開けられていないドアに変更してもいいですよ」といいます。 ここで問題です。あなたは「ドアを変更」するでしょうか？ 本書はプロジェクトマネジメントの本ですから、数学的なことは説明しません。しかし、数々の企業研修でこれを実施すると、ある現象が起きます。それは、ドアを変更「する」人と変更「しない」人に分かれるということです。つまり、ドアを変更したほうがよい、しないほうがよいという観点が人によって違うということです。 逆にいえば、変更するかしないかで宝物が得られないリスクの観点がバラバラということです。これはリスク対応計画で重要なインサイトになります。 特定の人にとってはリスクと思わないことも、他の人にとってはリスクである場合があり、さらにその逆もあります。 プロジェクトマネージャがひとりでリスク計画をすると、自分がリスクだと思わないことが後々大きなリスクになることもあります。 リスク対応計画はひとりでは行わず、有識者や専門家、ステークホルダー、顧客、そしてこの段階でプロジェクトチームメンバーが決定していればメンバーなどと複数人数で計画をして多面的にリスクを捉えましょう。

［リスク］計画 51リスクの概念をしっかり持とう 皆さんは「リスク」と聞くとどんなイメージを持ちますか？ 一般的には事件・事故・障害・トラブル・危険などネガティブまたはマイナスのイメージを持っていることが多いのではないでしょうか。 プロジェクトマネジメントでは、リスクを不確実の状態や事象として捉え、脅威（ネガティブ／マイナス）のリスクと、好機（ポジティブ／プラス）のリスクの双方をリスクとしています。 つまり、あらかじめ設定した計画や基準に対して、計画よりも悪い方向に下振れする可能性と良い方向に上振れする可能性の双方の観点を含んでいます。プロジェクト憲章の項目で説明したように、例えば、プロジェクトで開発する新商品の「抹茶アイスクリーム」が設定した基準よりも売れない脅威のリスクと、基準よりも売れる好機のリスクの双方がリスクとなります。 脅威と好機のリスクを考えることで適切な意思決定につながります。 例えばプロジェクトに投資するステークホルダーが脅威のリスクだけを見せられたらどう思うでしょうか。投資する意欲もそがれてしまいます。投資するステークホルダーは脅威と好機のリスクの双方を見て、適切な意思決定をする必要があります。 例えば、脅威のリスクが多くあるものの、投資するに値する好機のリスクが多くあれば、投資判断をするかもしれません。さらに、プロジェクトステークホルダー、特にプロジェクトチームメンバーのモチベーションにも影響します。 脅威のリスクだけを考えて活動していたらどうでしょうか。プロジェクトで新しきを創造する意欲が低下してしまうかもしれません。 リスク対応計画では、脅威と好機双方のリスクを計画し、明確にしていくことが重要です。［リスク］計画 52リスクを特定しよう この項目以降では、リスク対応計画で最低限行うべき重要なポイントをお伝えします。まずは「リスクの特定」です。 リスクの特定の目的は「発生した場合にプロジェクトの目的にプラス又はマイナスの影響を与えるような潜在的リスク事象及びその特性を洗い出す」（ ISO 21500: 2012）ことです。 「計画 50 リスク対応計画に入る前にゲームをしよう」で述べた通り、プロジェクトの目的や目標達成に影響を与える脅威と好機のリスクを有識者や専門家、ステークホルダー、顧客、そしてこの段階でプロジェクトチームメンバーが決定していれば、そのメンバーなど、複数人数で議論したりインタビューしたりして、多角的に洗い出し特定していきましょう。 リスク特定のためのディスカッションやインタビューは、プロジェクトマネージャがフレームワークを使って「テーマ」を持って行いましょう。 例えば、 WBS、スコープ記述書、ガントチャート、コスト管理表などのプロジェクト計画書類や SWOTなどの戦略のフレームワーク、ヒト・モノ・カネ・ジョウホウ・ジカンなどの経営資源のフレームワーク、財務諸表などのファイナンスのフレームワークなど「何のどの部分を誰と議論するのか」のテーマを決めて進めるということです。 ステークホルダーの中で製造に強い専門家は営業のリスクは見えにくいわけですし、逆に営業の専門家は製造のリスクは見えにくいわけです。経営者や投資家、プロジェクトスポンサーは、コストやスケジュールに関心が高く、それらのリスクは見えやすく、逆に細かいスコープのリスクは見えにくいかもしれません。 適切なフレームワークを使い、適切な人と、適切な場でリスク特定をしていきましょう。

［リスク］計画 53リスク登録簿を作成しよう リスクの特定を行うとともに、特定したリスクを「リスク登録簿」にまとめましょう。リスク登録簿は、特定したリスクの一覧のようなものです。企業や組織の中で指定されたフォーマットがなければ、エクセルなどで作れます。 リスク登録簿に記載するリスクは 6 W 2 Hを活用し、可能な限り具体的に記載しましょう。 リスク登録簿には数多くのリスクが記載されることがあります。プロジェクト現場でリスク登録簿を作成した後、時間が経過すると「このリスクは何がリスクなんだっけ？」ということにならないよう、具体的に記載しましょう。 また、 WBSなどをフレームワークにしてリスク特定を行った場合、 WBSのアクティビティや要素成果物（ワークパッケージ）に特化したリスクが特定されやすくなります。この場合、 WBSのどこの部分のリスクなのかを忘れないようにしっかりと記載しておきましょう。また、そのリスクが脅威・好機どちらのリスクなのかを明確にしましょう。 実際にリスクの特定、リスク登録簿の作成を体感してみましょう。 「計画 12 WBSの作り方」以降で皆さんが作成した WBS、ガントチャート、コスト管理表をもとにリスクの特定、リスク登録簿を作成してみましょう。ここではあくまでも体験ですから、 10個程度のリスクを特定し、リスク登録簿にまとめましょう。リスク登録簿のフォーマットは次の図を参考に作成してみましょう。 なお、少なくとも１つか２つは好機のリスクを特定しましょう。ここで重要なことは、リスクの特定からリスク登録簿作成までのプロセスを体感することです。［リスク］計画 54 QCDの観点をリスク登録簿に入れよう 皆さんは「 QCD」という言葉を聞いたことがあるでしょうか。これは「 Quality（品質）」「 Cost（費用）」「 Delivery（納期・引渡）」の頭文字で、ビジネスで重視される 3つの視点を表す言葉です。 既述の通り、プロジェクトマネージャの責任を単純化すると、納期までに目的や目標を達成させるために、要求事項（品質や費用を含む）を満たす成果物を納品することです。この責任の中に QCDの要素が入っています。 プロジェクトマネージャは QCDの観点を持つことが重要です。プロジェクトにおけるリスクは、この QCDに影響を与えます。 リスク登録簿をプロジェクトマネージャや主要ステークホルダーが見た時に、各リスクは QCDのどれに影響を与えるのかがわかるように、しっかりと記載しておくことをお勧めします。 例えば、既述の「社員用の登山用品のレンタル予約について、登山シーズンのため必要数 50セットを確保できない可能性がある」というリスクのみの記載だと、このリスクが具体的にプロジェクトの何に影響があるのかがわかりづらくなります。 「これにより、『登山用品をレンタルする』という要求事項が満たせない、またはレンタル会社を変更した場合、登山用品の納期が遅れる可能性がある」など QCDの観点を入れ、リスクの影響も簡潔に明文化しておくことで、リスクの内容をステークホルダーが具体的に理解できるようになります。 もしくはリスク登録簿に「影響区分」として「品質」「費用」「納期」などの項目を設けておき影響を明確にするなどの方法もあります。 影響の明確化は今後のリスク評価・分析、リスク対策のための重要な情報にもなります。

［リスク分析］計画 55定性リスク分析とは？ リスクを特定し、リスク登録簿を作成したら、それぞれのリスクを評価していきましょう。リスク評価は一般的には「定性リスク分析」から行います。 定性リスク分析は、特定したリスクを定性的に分析する手法です。例えば「 Ａのリスクは Ｂよりも高い、 Ｃのリスクは Aよりも低い」などリスクの特性や性質を明らかにし、リスクの優先順位付けをします。 次の図は単純化した定性リスク分析のためのツールです。縦軸にリスクの発生確率、横軸にリスクの影響度をとり、それぞれの軸に「高」「中」「低」を設定した ３ × ３のマトリックス図を作ります。発生確率はそのリスクが発生する頻度です。影響度はそのリスクがプロジェクトの目標達成に与える影響度合いです。 事前に特定したリスクを付箋などに書き、マトリックス図の適切な場所に配置していきます。このマトリックスは脅威のリスク用、好機のリスク用の双方を作り、脅威・好機双方の分析をしましょう。 単純な例を挙げて脅威のリスクの分析マトリックスを使ってみましょう。 月曜日朝 ９時に開始される大切な商談会議に出席し、商談成立することを目標としたプロジェクトがあったとします。あなたが会議に遅れてしまったら、会社の商談成立という目標に大きな影響を与えます。しかし、あなたがいつも利用する通勤電車は頻繁に遅延する電車です。 このプロジェクトで特定したリスクのひとつは「 ９時の商談会議に遅刻」だったとします。定性リスク分析のマトリックスのどこにリスクは配置されるでしょうか。 このリスクを記載した付箋は、リスクマトリックス内の発生確率「高」、影響度「高」のボックスに配置されることでしょう。

［リスク分析］計画 58定量リスク分析とは？ 一般的に、定性リスク分析の次に「定量リスク分析」を行います。定量リスク分析は、特定したリスクを定量的に分析する手法です。 例えば、「 Ａのリスクは ６ポイント、 Ｂのリスクは ９ポイント、 Ｃのリスクは ３ポイント」などリスクに数値を与え、数量的に分析する手法です。 この分析も脅威のリスク、好機のリスクの双方を分析します。定量リスク分析では数学的なアプローチもあり、非常に複雑な手法もあります。 本書では「実践」をテーマにしているため、最低限必要な実践的な知識を身につけましょう。 各リスクに数値を与えます。まず、定性リスク分析のマトリックスの軸に数値を割り当てます。例えば縦軸と横軸に「高 = ３ポイント」「中 = ２ポイント」「低 = １ポイント」などを設定します。 次に、それぞれの軸が交差するマトリックス内のボックスに縦軸と横軸を掛け合わせた数字を算出し割り当てます。例えば、「発生確率 ３ポイント ×影響度 ３ポイント = ９ポイント」などです。 こうすることで、マトリックス内のボックスに数値が割り振られます。そして、ボックスに配置されているリスクに数値を与えます。例えば、「発生確率 ３ポイント ×影響度 ３ポイント = ９ポイント」のボックスに配置されているリスクは ９ポイントと各リスクに数値が与えられます。 各リスクに数値が与えられると、より深い分析が可能になり、この後のリスク対応計画に生かされます。 例えば、各リスクのポイントによる対応優先付け、どのアクティビティや要素成果物（ワークパッケージ）、成果物でリスクが多いのかを定量的に把握、リスクポイントがどこまでのものを対応するのかの判断など、様々な意思決定に役立ちます。［リスク分析］計画 59定量リスク分析をやってみよう 先ほど作成したリスク登録簿の右側に「発生確率」「影響度」「リスクポイント（発生確率 ×影響度）」などの項目を加えてみましょう。次の図のように、定量リスク分析マトリックスで導き出された数値を記載していきます。

リスク登録簿がエクセルやアプリケーションだった場合、例えば、「リスクポイント（発生確率 ×影響度）」の項目でポイントが高い順に並べ替えてみましょう。こうすることで、リスク対策の優先順位が数値的に把握できます。 また「発生確率」のポイントの高い順、「影響度」のポイントが高い順などで並べ替えてみましょう。発生確率が高いリスクはどのような傾向か、影響度が高いリスクはどのような傾向か把握できます。 この方法以外にも、例えば、リスク登録簿に QCDの影響区分の項目を加えていれば、 QCDのそれぞれの影響区分のリスクを抜き出し、それぞれのリスクポイントの合計を比較することで、プロジェクトで QCDのうちどのリスクが大きいかを把握できます。 また、リスク登録簿にリスクに該当する WBSで作成したアクティビティ、要素成果物（ワークパッケージ）、成果物ナンバリングを入れ分析すれば、 WBSのどの部分にリスクが多いかが把握できます。 実際に定量リスク分析を体感してみましょう。「計画 56 定性リスク分析をやってみよう」で皆さんが作成したマトリックスに数値を与え、各リスクの数値を導きます。 そしてリスク登録簿の右側に「発生確率」「影響度」「リスクポイント（発生確率 ×影響度）」を加え、定量リスク分析のマトリックスで導いた数値を入力してみます。リスクポイントの高い順に並べ替えるなど様々な分析をしてみましょう。［リスク対応］計画 60リスク対応の優先度を決めよう プロジェクト現場でリスク特定をすると、大量のリスクが出てきます。全てのリスクに対応するのが理想的ですが、現実問題として対応するにはそれ相応の時間や資源、コストがかかり全てのリスクに対応はできません。 したがってリスクの度合いが高いものから優先度を決め、どこまでのリスクに対応するかを決定します。 対応の優先度を決める場合には、定量リスク分析で導いたリスクポイントで決める場合もありますし、その他の条件で決めることもあります。 例えば、定量リスク分析の結果、プロジェクトの方針として「影響度」を重視してリスク対応をするという場合、単純にリスクポイントのみでなく、影響度の数値も考慮し優先度を設定しなければなりません。 他には、プロジェクトの方針として「納期」を重視してリスク対応をするという場合、リスクポイントの他に QCDの Dにあたるリスクも優先度を考える上で考慮しなくてはなりません。 また、脅威のリスクと好機のリスクで対応方針も異なるかもしれません。例えば、脅威のリスクへの対応を優先するなどです。 優先度をどの基準で設定するかを、定性・定量リスク分析を行ったメンバーとともに議論し、プロジェクト全体としてのリスク優先度基準を設定しましょう。 これらの優先度基準やその条件は文書などに残しておく、もしくは後に説明するリスク管理表の注釈に基準や条件を記載し残しておくなどして、明文化しておきましょう。

［リスク対応］計画 61リスク対応の優先度と対応基準を決めてみよう 単純化したリスク対応の優先度設定と、優先度に応じたリスク対応基準設定をやってみましょう。 先ほど作成した ３ × ３の定量リスク分析のマトリックスを使います。定量リスク分析から導いた数値を使い、多面的にリスクを分析した結果、リスク対応の優先度と、優先度に応じたリスク対応基準を次のように設定したとします。・発生確率 2以上、影響度 3以上のリスクは優先度「高」と設定する。優先度「高」のリスクはリスク対応を行う。・発生確率 2以下、影響度 1以下のリスクは優先順位「低」と設定する。優先度「低」のリスクはリスク対応をせずリスクを受容する。・その他のリスクは優先順位「中」と設定する。優先度「中」のリスクはリスクポイントが高い順からリスク対応を行い、リスク対策予算を超過した段階でそれ以降の順位が低いリスクは対応せずリスクを受容する。 次の図は、マトリックスのどこが「高」「中」「低」なのかを表しています。定量リスク分析で導いた数値を加えたリスク登録簿の右側に「優先度」の項目を設け、各リスクの優先度を明確にしていきましょう。 実際に優先度を設定してみましょう。「計画 59 定量リスク分析をやってみよう」で作成した「発生確率」「影響度」「リスクポイント（発生確率 ×影響度）」を加えたリスク登録簿のリスク内容や影響を改めて見て、定量リスク分析のマトリックスのどのボックスを優先度「高」「中」「低」にするか決定しましょう。 先ほどのリスク登録簿に「優先度」の項目を加え、各リスクの優先度は「高」「中」「低」のどれかを記載しましょう。優先度に応じたリスク対応基準を決めましょう。［リスク対応］計画 62リスク対応計画を立てる前に─脅威のリスク対応策の基本─ 既述の通り、現実問題として全てのリスクを対応することは難しいのが現状です。脅威のリスク対応策としては、先ほど設定した優先度や優先度に応じたリスク対応基準にしたがって、リスクが大きいものからリスク対応を行い、リスクが小さいものはリスク対応を行わずリスクを受容するのが一般的です。 話を単純化させると、脅威のリスク対応のイメージとは、例えばリスク対応策を実施することでリスクがなくなる、またはリスクの発生確率や影響度が軽減することです。 さらに簡単に説明すると、リスク対応策を実施することで、リスク分析のマトリックスからリスクの付箋をなくしてしまう、もしくはよりリスクポイントの低いボックスに移動させるということです。 実際のプロジェクト現場では「リスクをなくす」リスク回避策は多くありません。ほとんどが「リスクを軽減させる」リスク軽減策になります。 リスク軽減策を１つまたは複数考え、発生確率や影響度を軽減し、「これ以上リスク対応しない」という優先度が低いリスクにして、最終的にリスクを受容します。リスクの受容とは、リスクを受け入れるということです。 受容したリスクに対しては、リスク対応計画で「発生した場合にどうするか」を考えておきます。例えば、リスクが発生した場合の活動案を策定しておく、リスクが発生した時の時間余裕、コスト余裕、資源余裕を確保しておくなどの対応策を決めておくことです。

［リスク対応］計画 63リスク対応計画を立てる前に─好機のリスク対応策の基本─ 好機のリスクに対する対応方針は企業や組織によって、またプロジェクトによっても異なります。経営者の目線になると、発生確率が低い好機のリスクやプロジェクトへの影響度が低いリスクに投資するよりは、発生確率や影響度が高い好機のリスクに投資し、それらの機会をより確実に得たいと思うことでしょう。 したがって、好機のリスク対応策においても、優先度や優先度に応じたリスク対応基準を設定し、リスクが大きいものからリスク対応を行い、リスクが小さいものはリスク対応を行わずリスクを受容するのが一般的です。 話を単純化させると、好機のリスク対応のイメージとは、リスク対応策を実施し確実に好機を得ることで好機のリスクをなくす、または好機リスクの発生確率や影響度を増大（強化）させることです。 さらに簡単に説明すると、リスク対応策を実施することでリスク分析のマトリックスからリスクの付箋をなくしてしまう、もしくは、よりリスクポイントの高いボックスに移動させるということです。 実際のプロジェクト現場では、残念ながら「確実に好機を得て好機のリスクをなくす」リスク対策（これを一般的に活用策という）は多くありません。 ほとんどが「好機のリスクを増大させる」リスク強化策になります。リスク強化策を 1つまたは複数考え発生確率や影響度を高め、「これ以上リスク対応しない」というリスクポイントまで到達したら最終的にリスクを受容します。 また、もともと優先度が低いリスクもリスクを受容します。受容するリスクに対してはリスクが発生した場合の活動案を策定しておく、リスクが発生した時の時間余裕、コスト余裕、資源余裕を確保しておくなどの対応策を決めておきます。

［リスク対応］計画 64その他のリスク対応策 脅威のリスク対応策としては、先ほど説明したリスクそのものを取り除く「回避策」と、リスクの発生確率や影響度を軽減させる「軽減策」の他に、リスクを第三者に転嫁・移転させる「転嫁策（移転策）」という対応策があります。 例えば、転嫁策はリスクに備える保険や、為替リスクに備えるオプション取引、担保など、一般的にお金にまつわるリスク対策で使われることがあります。 好機のリスク対策としては、先ほど説明した好機のリスクを確実に実現させる「活用策」と、リスクの発生確率や影響度を増大させる「強化策」の他に、好機を捉える能力の高い第三者とともに活動し好機を得やすくさせる「共有策」があります。 例えば、共有策は機会を得やすい専門会社とのパートナーシップ契約やジョイントベンチャーの形成などが一般的です。 実際のプロジェクト現場では、脅威のリスクでは軽減策、好機のリスクでは強化策が多いでしょう。しかし、ここで紹介したように軽減策、強化策以外にもリスクの対応策は様々あります。 リスク対策の手法はそれまでのプロジェクト経験や専門的知識によっても異なってきます。複数人数で様々な観点を用いてリスク対応策を考えていくことが望まれます。［リスク対応］計画 65リスクの軽減策、強化策の注意点 リスクの発生確率や影響度を変化させるリスクの軽減策や強化策ですが、リスク対応策を考える上で注意点があります。それは、軽減策や強化策が発生確率を変化させるものなのか、影響度を変化させるものなのか、それとも発生確率と影響度の両方を変化させるものなのか、を考える必要があります。 例えば、脅威のリスクで単純なリスクを挙げてみましょう。 「プロジェクトマネージャが新型インフルエンザにかかり ２週間以上プロジェクトを離脱し、プロジェクトマネジメントの品質が低下する」というリスクがあったとします。 この時のリスク対策として「 ①プロジェクトマネージャがインフルエンザワクチンを接種する」と「 ②プロジェクトマネージャの一部の仕事の代役が務められるプロジェクトリーダーを設定する」という２つがあったとします。 この２つのリスク対応策は傾向が異なります。 ①はインフルエンザにかかるリスクの発生確率を軽減させます。 ②はプロジェクトマネージャが離脱した際のプロジェクト目的・目標達成への影響度を軽減させます。 このように、軽減策や強化策は発生確率と影響度のどちらに働きかける対応策なのかを理解する必要があります。そして、これらの軽減策や強化策を組み合わせて、「これ以上リスク対策はしない」という優先度や基準まで持って行くことが求められます。［リスク対応］計画 66リスク対応策にはコストがかかる 「計画 44 リスク対策にもお金がかかることに注意」で説明したように、残念ながらリスク対策にはリスク対策コストがかかります。したがって、リスク対応策の効率性も求められます。 例えば、先ほどの「プロジェクトマネージャが新型インフルエンザにかかり ２週間以上プロジェクトを離脱し、プロジェクトマネジメントの品質が低下する」というリスクと、そのリスクに対応する「 ①プロジェクトマネージャがインフルエンザワクチンを接種する」と「 ②プロジェクトマネージャの一部の仕事の代役が務められるプロジェクトリーダーを設定する」という２つのリスク対応策があったとします。 例えば、 ①のワクチン接種のコストは 4, 000円、 ②の人件費は諸経費込みで年間 800万円、このプロジェクトは １年間のプロジェクトだったとします。 ①のリスク対応策を講じることでリスクポイントは ６から ３に ３ポイント下がる、 ②のリスク対応策を講じることでリスクポイントは ６から ４に ２ポイント下がるとします。 ①のコストは 4, 000円でしたから １ポイント下げるのに約 1, 333円のコストになります。 ②のコストは 800万円でしたから 1ポイント下げるのに 400万円のコストになります。これは単純化した極端な例ですが、リスク対応策によってリスク対応策のコスト効率が異なってきます。 定量リスク分析で導いた数値は、このようなリスク対応策のコスト効率の算出にも利用できます。 このように、リスク対応策を考える上で、リスク対応コストの観点を持つことが重要です。プロジェクト予算の範囲内で目的・目標を達成させるために「より効率のよいリスク対応策はないか」という視点が重要です。

［リスク対応］計画 67リスク対応策を考えてみよう 先ほどのリスク例を活用して単純化した「リスク対応策例」を見てみましょう。 「社員用の登山用品のレンタル予約について、登山シーズンのため必要数 50セットを確保できない可能性がある」というリスクで、「 ①登山用品を 50セット購入」「 ② 3社以上のレンタル会社から予約する」というリスク対応策があったとします。 ①はプロジェクトの要求事項やコスト的に厳しいという判断で ②のリスク対応策をとったとします。もともとの発生確率は ２、影響度は ３、リスクポイントは ６で、 ②のリスク対応策を講じることで発生確率は １、影響度は ３、リスクポイントは ３になったとします。 さらに残されたリスクに対して「 ③社員または社員の知り合いが有している登山用品をあらかじめ貸してもらい利用する」で発生確率は １、影響度が ２、リスクポイントは ２になったとします。 この段階で当該リスクを受容し、残されたリスクが発生した場合の対応策は「 10セット分を購入するコスト 100万円を予備予算で確保する」としたとします。この情報を次の図のように先ほどまでのリスク登録簿に情報を加えていきます。 実際にリスク対応策の作成を体感してみましょう。「計画 61 リスク対応の優先度と対応基準を決めてみよう」で作成したリスク登録簿に「リスク対応内容」「対応策（区分）」「対応コスト」、リスク対応策後の「発生確率」「影響度」「リスクポイント」「優先度」の項目を加え、リスク対応策と対策後の各種数値を考え入力しましょう。あらかじめ設定していたリスクを受容する基準になるまでリスク対応策を考えます。 この場合、例のような複数のリスク対策を記載する「行」（ No. 1-2、 No. 1-3の行）を加えましょう。もしもリスクを完全に取り除く案があれば、リスク対策後の数値は全て ０になります。［リスク対応］計画 68二次的なリスクという考え方 リスク対応策の策定をする中で、「二次リスク」の観点を持っておくことが求められます。二次リスクとは、「リスク対応をしたことにより発生する新たなリスク」です。 例えば先ほどのリスク対策とコストの関係性を説明した時に単純化した例で挙げた「プロジェクトマネージャが新型インフルエンザにかかり ２週間以上プロジェクトを離脱し、プロジェクトマネジメントの品質が低下する」というリスク対応策で、「 ①プロジェクトマネージャがインフルエンザワクチンを接種する」があったと思います。 二次リスクとは ①を実行した場合に発生する新たなリスクです。例えば、「ワクチン接種による体調不良」などが二次リスクです。このような二次リスクは、リスク対応により新たに特定されるリスクです。 リスク対応策を考える際は、「この対策により二次的に発生するリスクはないか」という観点を持っておくことが重要です。 二次リスクが発生する可能性があるリスク対応策を選択する場合は、リスク登録簿に戻り、もともとのリスク（一次リスク）が記載されているリスク登録簿の行の下に二次リスクを追加し、二次リスクのリスク対応策についても策定しリスク登録簿に入力していきましょう。

［リスク管理］計画 69リスク管理表とは？ リスク計画の中で最低限完備すべきものとしてリスク対応計画をまとめた「リスク管理表」があります。今までリスク登録簿に、リスク分析結果やリスク対応策などのあらゆる情報を追加していったと思います。これらがリスク管理表の原型となります。 このリスク管理表は、今後のプロジェクト実行時にリスク管理をする上で利用される重要な文書となります。 しかし、このままではリスク管理表は完成しません。このリスク対応を「誰」が「いつまで」に実行するのか、そしてプロジェクト実行中にそのリスク対応の進捗を管理するような項目が最低限必要になります。 具体的には今まで作成したリスク登録簿に追加した項目に、さらに「担当者」「対応開始予定日」「対応完了日」などの項目を追加するイメージです。 プロジェクトが大きくなり、複雑化するにつれて、今まで説明してきたリスクの特定方法、分析方法、各種基準、そしてその後のリスクの管理手法をどうするかを事前に定めて文書に残しておくことがあります。 このリスクマネジメントに関するルール、活動、プロセス基準などを総合的に決めておく計画書を一般的に「リスクマネジメント計画書」といいます。

［リスク管理］計画 70リスク管理表の作成が終わったら この項目タイトルを見て、勘が鋭い人は気がついていると思います。そうです、リスク対応計画を「リスク管理表」にまとめたら、前工程のプロジェクトマネジメント関連の文書類と整合性が取れているかチェックする必要があります。 リスク特定をして、主要リスクに加えるべきリスクを発見した場合、プロジェクト憲章にその情報を加え改定する必要があります。 リスクを回避するために特定の要求事項やアクティビティをやめるという決断をプロジェクトでした場合、スコープ記述書や WBS、ガントチャートを改定する必要があります。リスク対策コストによっては、コスト管理表を改定しましょう。 リスクは成果物のように目に見えません。しかしリスクを考えないと、そのリスクが発生した際にプロジェクトの目的・目標達成に影響を与えます。このリスク対応はプロジェクトの活動のひとつになります。したがって、すでに述べた「スコープ vs時間 vs資源 vsコストの視点」に関連するものになります。 現在まで策定した各種計画と整合性が取れるようにバランス感覚を持って調整をしていきましょう。各種計画に改定が必要な場合は、あらかじめ設定した決裁者の承認を受け、改定をしていきましょう。［リスク管理］計画 71リスク管理表における落とし穴 プロジェクトの計画時にリスク対応計画を策定し、それを「リスク管理表」で明確にしていきました。プロジェクト計画が承認され、プロジェクトの実行に移ると、ついついリスク管理表を見る機会が少なくなってしまう場合があります。 プロジェクト実行中にスコープ、時間（スケジュール）、資源、コストの計画と実績の差に集中しすぎるあまり、リスクマネジメントがついつい手薄になってしまうことがあるためです。 しかし、プロジェクトが実行されると、様々な現実に直面し、新たなリスクが発生します。「今後も新たなリスクが発生する」という認識でプロジェクトマネジメントを行わなければ、新たなリスクを見過ごしてしまいがちです。 プロジェクトの実行中も新たなリスクを特定し、そのリスク分析や対応策を検討し、リスクを管理していかなければなりません。新たなリスクを放置しておくと、プロジェクトの目的・目標達成に大きな影響を与えるかもしれません。 プロジェクト計画時のリスク管理表は「スタートライン」にしかすぎません。一度、リスク管理表を作成したことで、リスクやリスク対応策が明確になり安心してしまうかもしれませんが、プロジェクトの実行に移った後も定期的に「リスク管理表」を見直し、アップデートしていくことが望まれます。［リスク管理］計画 72未知のリスクと既知のリスク 今までリスク対応策をお伝えしてきたわけですが、一般的なプロジェクトマネジメントの学問にはあまり含まれていない重要なリスク観点があります。この観点はファイナンスの専門家や経営者の視点になります。筆者は MBA（経営管理修士）で経営者ですので、この機会にプロジェクトのリスクを考える際の重要な観点をお伝えします。 それは「未知」のリスクと「既知」のリスクの観点です。今までご紹介したリスク分析は「発生確率」を考慮したものでした。発生確率が考慮できるということは、すでにそのリスクに気づいているということです。 気づいているリスクは既知のリスクです。しかし、気づかないリスクもビジネスには存在します。気づいていないリスクは未知のリスクです。 経営者の先輩から「企業経営には３つの『坂（さか）』があり、それは、業績の良い『上り坂』、業績が悪い『下り坂』、そして突拍子もないことが起こる『まさか！（ま坂）』だ」と教えられたことがあります。「まさか！」はまさに気づいていない未知のリスクです。 プロジェクトではこれらの未知のリスクが発生することがあります。なぜならば、プロジェクトは未来に向けた活動であり、常に不確実性があるためです。これらを考慮し「まさか！」が起こった時の行動基準や対応策を考えておくことをお勧めします。 例えば、「まさか！」が起こった時の行動順序や意思決定をどうするのか、もしくは資源、コスト、リソースの余裕があれば、「まさか！」のためにどれぐらいの時間やコストの余裕を設けておくべきかなどです。 プロジェクトの目的・目標達成のために「まさか！」が起こる可能性をプロジェクトマネージャは常に頭に入れておきましょう。

［計画書］計画 73〈参考〉その他の計画 本書ではプロジェクトマネジメントを即実践できるように、「数百万円のプロジェクトでも数億円のプロジェクトでも共通して最低限必要な内容」に焦点を合わせています。ちなみにプロジェクトが大きくなり、複雑化することで計画書は増えていきます。 例えば、ステークホルダー、スコープ、資源、タイム（スケジュール）、コスト、リスク、品質、調達、コミュニケーションの軸でこれらの計画手法をどのような方法論で行うのか、関連する分析手法をどうするのか、各種基準をどう設けるのか、その後の管理手法をどうするか、各種計画の変更をする場合の決裁ルールなどをあらかじめ設定し、計画書としてまとめておきます。 今一度、スコープ記述書の「プロジェクトスコープ」を見ましょう。プロジェクトマネジメントの作業や活動の範囲でステークホルダーが望み、優先度が高い計画及び計画書を策定することが本質的に重要になります。計画や計画書の策定にはそれ相応のコスト、資源、時間が必要です。 さらに、ステークホルダーが求めていない計画書は活用されない可能性もあります。ステークホルダーの要求がある、もしくはその計画書がなければプロジェクトの目的・目標達成に支障がある計画書の完備を優先的に行っていくことが重要です。 企業や組織の中には、プロジェクトの規模や複雑性に合わせてプロジェクトのカテゴリ分けをしている場合があります。そしてカテゴリに合わせて作成すべき計画書のルールが明確化されている場合があります。 当然、規模や複雑性が小さいプロジェクトの計画書は少なく、大きいプロジェクトは計画書が多いです。これらの観点で計画書を完備していきましょう。［計画書の承認］計画 74プロジェクトマネジメント計画書の承認を得よう 第 ３章【計画】の章では、スコープ、スケジュール、コスト、リスクに関する様々な計画書類または計画書に至るまでの書類など、その他計画書について紹介してきました。話を単純化させると、これらの各種計画書類を１つにまとめた文書が「プロジェクトマネジメント計画書」となります。 プロジェクト憲章やスコープ記述書と同様に、このプロジェクトマネジメント計画書についても、あらかじめ設定している決裁者または主要ステークホルダーと読み合わせを行い、承認を受けることを強くお勧めします。 決裁者や主要ステークホルダーとの「合意」をもとに、プロジェクトの実行に移ることがとても重要です。 なお、承認や合意を得たことを証明するために、プロジェクトマネジメント計画書には「承認欄」を設け、決裁者や主要ステークホルダーからの署名や捺印をもらいましょう。 このプロジェクトマネジメント計画書についても、プロジェクト憲章と同じく、プロジェクト実行中に「変更」が生じる可能性があります。プロジェクトマネジメント計画書のバージョン情報もしっかりと明記しておきましょう。 プロジェクトマネジメント計画書の承認は、プロジェクトの実行に移るための重要なマイルストーンです。読み合わせや承認を得ずにプロジェクトの実行に移ることで、「誰がこんな計画にしたんだ」「こんな計画、聞いていないよ」などという状況に陥ってしまい、プロジェクトの計画のやり直しになる可能性が大きくなります。 これはプロジェクトにとって大きな痛手となりますので、このマイルストーンをしっかりと対応しましょう。［チームの結成］計画 75プロジェクトチームの結成のタイミング プロジェクトチームの結成の目的は、プロジェクトの目的・目標を達成するために必要な人的資源を得ることです。このプロジェクトチームの結成のタイミングはプロジェクトによって異なります。 例えば、すでに述べた目標設定の時点からプロジェクトチームが必要なプロジェクトもありますし、計画や実行から必要な場合もあります。しかし、プロジェクト実行時にはプロジェクトチームが必要ですから、計画終了までには結成またはその準備が必要です。 プロジェクトチームの結成には、すでに学んだプロジェクト憲章の「人的資源／能力・技術」の情報、その後のガントチャートで説明した責任分担表などの情報をもとに、企業や組織の内部、またはサプライヤなどの外部から必要な人的資源を集めていきます。 この「人的資源を集めプロジェクト活動をしていただく」というプロジェクトマネージャの活動を、初回のプロジェクトチーム結成以降、プロジェクト実行中にも継続して行うプロジェクトもあります。 例えば、アクティビティ Ａ担当の Ｘさんは １ ～４月、アクティビティ Ｂ担当の Ｚさんは ６ ～８月に必要といったように、時期やプロジェクトのフェーズによって人的資源が異なるためです。 このように、プロジェクトチームの結成は初回だけではなく、その後も必要な人的資源を迎え入れ、活動してもらう活動が継続して必要になってきます。 プロジェクトが大きくなり複雑化すると「計画 73 〈参考〉その他の計画」で紹介した「資源」の計画書の中に、いつどの人材をどのようにチームに加えどの活動していただくかなどの計画を作ります。

また、実際にプロジェクトチームの結成をした際、各種計画書の修正が必要な場合、あらかじめ設定した決裁者の承認を得た上で計画書を修正しましょう。［計画のヒント］計画 76計画のヒント ①─バランス─ ここまでお読みいただいた皆さんは、計画において「スコープ」「時間」「資源」「コスト」の４つの要素のバランスが極めて重要であることをご理解いただいたと思います。 この４つ要素の１つが増えれば、他の要素も基本的には増えます。逆に４つの要素の１つを減らす場合は、他の要素も減らさなくてはならない可能性が高いのです。 もちろん、プロジェクトマネージャの皆さんは、過去の経験や知恵を使って、１つの要素が増えても他の要素に変動がないようにする努力は必要です。しかし、最大限の努力をした結果できた計画では、４つの要素の１つが変動すれば、他の要素も変動します。それは常に「お盆」の上にボールを乗せて歩いているようなものです。 お盆の４つの角は「スコープ」「時間」「資源」「コスト」です（「計画 45 スコープ vs時間 vs資源 vsコストの視点」参照）。１つの角を上に上げれば他の角を同じぐらい上げなければ、お盆が傾きボールが落ちてしまいます。逆に１つの角を下げれば他の角を同じぐらい下げなければ、ボールが落ちます。常に４つの角を意識して計画を作ることが重要です。 残念ながら「どれだけ経営リソースを使ってもかまわないよ！」という打ち出の小槌のようなプロジェクトはほぼありません。 しかしステークホルダーは自分の関心事項を叶えるためにあらゆる要求事項を出してきます。プロジェクトマネージャは冷静に４つの要素を見ながら、合理的思考と俯瞰した視点で「現実」を見ながらステークホルダーと要求事項を調整し、バランスをとりながらプロジェクトの計画を進めていきましょう。 なお、このバランス感覚はプロジェクト実行中にさらに重要になります。プロジェクト実行中の突然のスコープ追加、コスト削減、時間短縮、資源の削減などが発生することもあります。計画段階からバランス感覚をしっかりと養っておきましょう。［計画のヒント］計画 77計画のヒント ②─３つの「しない」─ プロジェクトの計画をプロジェクトマネージャが上手く進めるために「３つの『しない』」を紹介します。それは「 ①いつまでも計画しない」「 ②ひとりで計画しない」「 ③複雑にしない」です。 まず、いつまでも計画し続けないようにしましょう。プロジェクトの計画時もコストが発生しています。計画の完成度を高めるあまり、時間だけが経過してしまうとプロジェクトの ROIが低下してしまいます。さらに、時間の経過で市場の機会を失ってしまう可能性があります。計画の期間にリミットを設け、スケジュールに明確化しておくことをお勧めします。 プロジェクト憲章に計画のスケジュールや計画のコストを明確化し、さらには計画内容の最終チェック日に関するマイルストーンを明確化しておくなどです。 次に、ひとりで計画しないようにします。これまで、専門家や有識者、主要ステークホルダーと一緒に計画をしていくことを述べてきました。プロジェクトが大きくなり複雑化することで、プロジェクトマネージャ個人の知識や経験だけでは計画できないことがあります。また、ステークホルダーにも個別の関心事項があります。リスク観点は個々人で異なります。プロジェクトの計画に必要な複数の人を“巻き込み”、プロジェクトの計画をしていきましょう。 最後に、計画書類を複雑にしないようにしましょう。例えば、プロジェクト管理ツールや文書のレイアウトをゴージャスにするのに時間をかけすぎてしまうなどです。 プロジェクト計画書は目的・目標を達成させるための「手段」です。シンプルに必要な情報を明示することが重要です。

です。プロジェクトマネージャは目的・目標の達成に本質的に何が必要かを考え活動をしていきましょう。［計画のヒント］計画 78計画のヒント ③─文書・資料管理─ すでに紹介したように、プロジェクトの計画時は、ひとつの計画書ができたとしても、他の計画書を作ったことで前工程の計画書が改定されることが多いです。これらの改定前、改定後の資料はしっかりと管理しておきましょう。 また、改定された履歴や改定理由などをしっかりとわかるようにしておきましょう。プロジェクトの計画中や実行中に、プロジェクトマネージャは多数のステークホルダーと計画内容についてコミュニケーションをとります。その際に、なぜ改定されたのか、なぜ現在の計画になったのかという経緯の情報も重要になってきます。 例えば、スコープ記述書が 10回改定されていたとしましょう。「 ４回目の改定はどういう経緯でこうなったんだい？」「この計画書のこの部分はなぜこうなったんだい？」とステークホルダーから聞かれた場合、履歴や改定理由が明確に記録されていないと答えられないかもしれません。 さらに、プロジェクト計画中に、プロジェクトマネージャの手元には、計画書のもととなった資料が集まります。企業や組織の戦略に関する資料、お客様から提供された資料、契約書類、サプライヤから提供された資料、各種データの資料、参考文献などです。これらもしっかりと整理しておきましょう。 なお、プロジェクト実行中も様々な理由により、計画内容の変更が必要となり計画書が改定されていきます。また、計画書以外にもあらゆるプロジェクト関連書類がプロジェクトマネージャに集まってきます。プロジェクトの計画中から各種資料の管理を徹底するクセをつけておきましょう。［まとめ］計画 79【計画】のまとめ ここまで、計画に最低限必要な知識と技術をお伝えしました。「計画 01 段取り八分とは？」でも説明したように、プロジェクトマネージャの労力がかかるのが計画の段階です。ひとつの計画をしても、その後の計画で前工程の計画を改定することもしばしばです。 しかし、なぜ改定が必要なのかを考えると、あらゆる計画を進めていくことによって、段階的に計画が詳細化され、より精度が上がっているから前工程の計画の修正が必要である、ともいえます。 計画を通じて未来の活動を頭の中でシミュレーションすることができることも計画で重要な要素となります。これはまさに、アスリートがイメージトレーニングをしているようなものです。イメージトレーニングはシミュレーションによって体や心を準備しパフォーマンスを高める目的があるといわれます。 プロジェクトの投資対効果のパフォーマンスを高めるためにも計画でのシミュレーションが重要になってきます。また、経営者や投資家、金融機関の立場を想像してみると、計画があやふやなものに対して投資をしたり、コストをかけたりするでしょうか。 ビジネスの現場では現実問題として「よし、これなら投資しよう」「これならコストをかけよう」と判断できる情報が必要になります。この情報としても計画の情報が重要になります。 しかし残念ながら、実際のプロジェクトでは計画通りにプロジェクトは進みません。大学院や企業研修など数々の講義やプロジェクト現場でこの話をすると「だったら計画は必要ではないのでは？」といわれることがあります。 その時に筆者は「だからこそ計画が必要」と答えます。計画というベースがなければ「なぜ計画と実績の差が出たのか」「その要因は何か」の分析ができません。この分析情報自体が企業や組織のプロジェクトマネジメント高度化や成熟化の重要な情報のひとつとなります。