「見積もりは経験だけで決めてもよいのだろうか。」

プロジェクトを成功させるためには、現実的なスケジュールや予算を計画することが重要です。

その土台となるのが見積もり（Estimate）です。

この記事では、見積もりの意味や目的、代表的な見積もり手法、PMBOK®︎との関係、実務で意識すべきポイントについて解説します。

一言でいうと

見積もりとは、「プロジェクトに必要な期間・コスト・工数・資源などを予測する活動」です。

見積もりとは

見積もりとは、プロジェクトを実施するために必要な工数、期間、コスト、資源などを予測することです。

プロジェクトの初期段階では情報が限られているため、見積もりはあくまで予測であり、プロジェクトが進むにつれて精度を高めていきます。

PMBOK®︎では、見積もりはスケジュールマネジメントやコストマネジメントなどの計画プロセスで重要な活動として位置付けられています。

見積もりが重要な理由

見積もりが不正確だと、その後に作成するスケジュールや予算、要員計画にも大きな影響を与えます。

例えば、次のような問題が発生する可能性があります。

• スケジュールが現実的ではない
• 予算不足になる
• 要員が不足する
• 納期遅延や品質低下につながる

適切な見積もりを行うことで、実現可能な計画を立てることができます。

代表的な見積もり手法

類推見積もり（Analogous Estimating）

過去の類似プロジェクトを参考に見積もる方法です。

短時間で実施できますが、過去の実績に大きく依存します。

パラメトリック見積もり（Parametric Estimating）

単価や生産性などの統計データを用いて算出する方法です。

例えば、「1画面あたり20時間」といった基準を利用します。

ボトムアップ見積もり（Bottom-Up Estimating）

WBSで分解した最小単位の作業ごとに見積もり、それらを積み上げる方法です。

時間はかかりますが、高い精度が期待できます。

三点見積もり（Three-Point Estimating）

楽観値・最頻値・悲観値の3つを用いて見積もる方法です。

不確実性を考慮した、より現実的な見積もりが可能になります。

見積もりの精度は段階的に高まる

プロジェクト初期は情報が少ないため、見積もりの精度は高くありません。

要件が明確になり、設計が進むにつれて精度は向上します。

そのため、見積もりは一度作成したら終わりではなく、必要に応じて見直すことが重要です。

見積もりと予算の違い

つまり、見積もりをもとに予算が作成されます。

実務ではこんな場面で活用される

例えば、新しいWebシステムを開発するプロジェクトを考えます。

プロジェクトマネージャは、まずWBSを作成し、各アクティビティの工数をボトムアップ見積もりで算出します。

さらに、過去のプロジェクト実績も参考にしながら見積もりを補正し、最終的な期間とコストを算出します。

その見積もりをもとに、スケジュールや予算を作成し、スポンサーの承認を得てプロジェクトを開始します。

よくある勘違い

見積もりは「約束」ではない

見積もりは、現時点で得られる情報をもとにした予測です。

要件変更や新たなリスクによって見積もりが変わることは珍しくありません。

経験だけで見積もるのは危険

経験は重要ですが、それだけでは精度に限界があります。

WBSや過去実績、統計データなどを活用し、客観的な根拠を持って見積もることが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、見積もり手法や見積もり精度に関する問題が出題されます。

午後試験では、次のような観点を説明できることが重要です。

• どの見積もり手法を採用したか
• 見積もりの根拠は何か
• 見積もり精度をどのように向上させたか
• 見積もり結果を計画へどのように反映したか

「経験で見積もった」だけではなく、「WBSや過去実績などを活用し、根拠のある見積もりを実施した」と説明できることが評価につながります。

PM道場のワンポイント

見積もりは、「未来を当てること」ではなく、「現時点で最も合理的な予測をすること」です。

プロジェクトでは、不確実性をゼロにすることはできません。

だからこそ、根拠を明確にし、不確実性も考慮した見積もりを行うことが重要です。

優れたプロジェクトマネージャは、「当たる見積もり」ではなく、「説明できる見積もり」を作成しています。

関連用語

• WBS
• 予算
• コストベースライン
• コストマネジメント
• スケジュールベースライン
• ローリングウェーブ計画法
• リスク分析
• アクティビティ

まとめ

見積もりとは、プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

見積もりの精度はプロジェクトの進行とともに高まり、その結果はスケジュールや予算の基礎となります。

プロジェクトマネージャにとって、根拠のある見積もりを行うことは、現実的な計画を立てるための重要なスキルと言えるでしょう。

関連記事

• WBSとは？
• 予算とは？
• コストベースラインとは？
• コストマネジメントとは？
• スケジュールベースラインとは？
• ローリングウェーブ計画法とは？

よくある質問（FAQ）

Q. 見積もりとは何ですか？

A. プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

Q. PMBOK®︎で代表的な見積もり手法には何がありますか？

A. 類推見積もり、パラメトリック見積もり、ボトムアップ見積もり、三点見積もりなどがあります。

Q. 見積もりと予算の違いは何ですか？

A. 見積もりは必要な期間や費用を予測する活動であり、予算はその見積もりをもとに承認された資金計画です。

「ベンダーとの認識違いで、スケジュール遅延が発生してしまった。」

プロジェクトでは、外部企業や協力会社と連携する場面が多くあります。

そのような状況で重要になるのがベンダーマネジメント（Vendor Management）です。

この記事では、ベンダーマネジメントの意味や目的、進め方、RFPとの関係、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ベンダーマネジメントとは、「外部の企業や協力会社と適切な関係を築き、契約内容や品質、進捗を管理しながらプロジェクト成功へ導く活動」です。

ベンダーマネジメントとは

ベンダーマネジメントとは、プロジェクトで利用する外部企業（ベンダー）を管理し、期待する成果を得るための活動です。

ベンダーとは、製品やサービス、開発作業などを提供する企業や組織を指します。

プロジェクトでは、自社のメンバーだけですべてを実施することは難しく、外部の専門企業へ業務を委託することがあります。

その際、単に作業を依頼するだけではなく、目的や期待値を共有し、協力関係を築くことが重要になります。

PMBOK®︎では、ベンダーマネジメントは調達マネジメントやステークホルダーエンゲージメントと関連する重要な活動として扱われています。

ベンダーマネジメントが重要な理由

外部企業へ作業を委託すると、プロジェクトマネージャは直接すべてを管理できるわけではありません。

そのため、適切な管理を行わないと、次のような問題が発生します。

• 成果物の品質が期待を下回る
• 納期遅延が発生する
• 契約範囲外の作業が増える
• 認識違いによる手戻りが発生する
• 問題発生時の対応が遅れる

ベンダーを「作業を任せる相手」ではなく、「プロジェクトを成功させるパートナー」と考えることが重要です。

ベンダーマネジメントの進め方

1. 期待事項を明確にする

契約前に、目的、成果物、品質基準、スケジュールなどを明確にします。

RFP（提案依頼書）を活用し、ベンダーへ期待する内容を伝えることも重要です。

2. 役割と責任範囲を明確にする

発注側とベンダー側の役割分担を明確にします。

例えば、次のような項目です。

• 成果物作成の責任者
• レビュー担当者
• 問題発生時の連絡先
• 承認プロセス

責任範囲が曖昧だと、「どちらが対応するのか分からない」という問題につながります。

3. 進捗と品質を確認する

定期的な進捗確認やレビューを実施します。

重要なのは、問題が発生してから確認するのではなく、早期に兆候を把握することです。

4. 問題発生時は協力して解決する

ベンダー側で問題が発生した場合、責任追及だけでは問題解決につながりません。

原因を確認し、プロジェクト全体として最適な対応策を検討します。

ベンダーマネジメントで管理する主な項目

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで外部開発会社へ一部機能の開発を委託したとします。

プロジェクトマネージャは、契約した後も次のような管理を行います。

• 週次進捗会議の実施
• 成果物レビューの実施
• 課題一覧の共有
• 品質状況の確認
• 変更要求への対応調整

その結果、ベンダーと自社が同じ目標に向かって協力でき、プロジェクトを成功へ導くことができます。

よくある勘違い

ベンダーマネジメントは監視することではない

ベンダーを細かく監視し、指示するだけでは良い関係は築けません。

重要なのは、期待する成果を共有し、協力しながら問題を解決することです。

契約したら管理は不要ではない

契約はスタート地点です。

契約後も、進捗・品質・課題を継続的に確認し、必要に応じて調整する必要があります。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、外部委託や協力会社との調整に関する問題が出題されます。

午後試験では、次のような観点を説明できることが重要です。

• ベンダー選定時に何を評価したか
• 契約内容や役割分担をどのように明確化したか
• 進捗・品質をどのように管理したか
• 問題発生時にどのように協力して解決したか

「ベンダーへ依頼した」ではなく、「協力関係を構築し、プロジェクト成功に向けて管理した」と説明できることが評価につながります。

PM道場のワンポイント

ベンダーマネジメントで重要なのは、ベンダーを管理することではなく、同じゴールへ向かうパートナーシップを築くことです。

外部企業へ委託すると、「発注者」と「受注者」という関係になりがちです。

しかし、プロジェクト成功という目的は同じです。

優れたプロジェクトマネージャは、契約だけに頼るのではなく、日々のコミュニケーションによって信頼関係を構築しています。

良いベンダーマネジメントは、問題が起きた後の対応ではなく、問題が起きにくい関係づくりから始まります。

関連用語

• 調達マネジメント
• RFP
• 契約
• 要求事項
• ステークホルダーエンゲージメント
• コミュニケーションマネジメント
• 品質管理
• 変更要求

まとめ

ベンダーマネジメントとは、外部企業や協力会社と適切な関係を築き、契約内容や品質、進捗を管理しながらプロジェクト成功へ導く活動です。

重要なのは、単に作業を管理することではなく、ベンダーと協力して同じ目標へ向かうことです。

プロジェクトマネージャにとって、ベンダーマネジメントは外部リソースを最大限に活用するための重要なスキルと言えるでしょう。

関連記事

• RFPとは？
• 調達マネジメントとは？
• 契約とは？
• 要求事項とは？
• ステークホルダーエンゲージメントとは？
• 品質管理とは？

よくある質問（FAQ）

Q. ベンダーマネジメントとは何ですか？

A. 外部企業や協力会社と適切な関係を築き、品質・進捗・契約などを管理しながらプロジェクト成功へ導く活動です。

Q. ベンダーマネジメントで最も重要なことは何ですか？

A. ベンダーを単なる作業委託先ではなく、プロジェクト成功に向けたパートナーとして考え、協力関係を築くことです。

Q. RFPとベンダーマネジメントの関係は何ですか？

A. RFPはベンダー選定前に期待する内容を伝える文書であり、ベンダーマネジメントは選定後も含めて継続的に関係を管理する活動です。

「もしシステム障害が発生した場合、誰が何をするのでしょうか？」

プロジェクトでは、事前にリスクを洗い出していても、実際に問題が発生する可能性があります。

そのような不測の事態に備え、あらかじめ対応方法を決めておく計画がコンティンジェンシープラン（Contingency Plan）です。

この記事では、コンティンジェンシープランの意味や目的、作成方法、リスク対応計画との違い、実務での活用方法について解説します。

一言でいうと

コンティンジェンシープランとは、「リスクが実際に発生した場合に備えて、あらかじめ決めておく対応計画」です。

コンティンジェンシープランとは

コンティンジェンシープランとは、特定のリスクが発生した場合に、どのような対応を行うかを事前に定めた計画です。

リスクマネジメントでは、リスクを完全になくすことはできません。

そのため、

• リスクが発生した場合に何をするか
• 誰が対応するか
• どのタイミングで対応を開始するか
• どのような判断が必要か

を事前に決めておきます。

PMBOK®︎では、リスク対応を計画する際に、リスクが発生した場合の対応策としてコンティンジェンシープランを準備します。

コンティンジェンシープランが重要な理由

問題が発生した後に対応方法を考えると、判断や対応が遅れる可能性があります。

例えば、以下のようなケースです。

• 担当者が不在になり、作業を引き継げない
• システム障害発生時に対応窓口が決まっていない
• 納期遅延が発生してから対応策を検討する

このような状況では、混乱が発生し、さらに大きな影響につながる可能性があります。

コンティンジェンシープランを準備しておくことで、発生時に迅速な対応が可能になります。

コンティンジェンシープランとリスク対応計画の違い

コンティンジェンシープランは、リスク対応計画の一部として扱われることがあります。

例えば、

リスク：重要メンバーが離脱する可能性がある

リスク対応：複数人が対応できるように知識共有を進める

コンティンジェンシープラン：離脱した場合は、予備メンバーを投入し、○日以内に引き継ぎを完了する

というように整理できます。

コンティンジェンシープランの作成方法

1. 対象となるリスクを選定する

すべてのリスクに対して詳細な計画を作成する必要はありません。

影響度が大きく、発生した場合に迅速な対応が必要なリスクを対象にします。

2. 発動条件（トリガー）を決める

コンティンジェンシープランでは、「いつ実行するか」を明確にすることが重要です。

この判断基準をリスクトリガー（Risk Trigger）と呼びます。

例：

• 予定日から3日以上遅延した場合
• 品質不良が一定数を超えた場合
• 主要メンバーが離脱した場合

3. 対応内容と担当者を決める

発生時の混乱を防ぐため、具体的な行動を決めます。

実務ではこんな場面で活用される

例えば、プロジェクトの主要メンバーが長期間参加できなくなるリスクを考えます。

事前に以下のようなコンティンジェンシープランを準備します。

• 副担当者を設定する
• 重要資料を共有フォルダへ保存する
• 定期的に知識共有を行う
• 離脱時は副担当者へ引き継ぐ
• 必要に応じて追加要員を依頼する

このように、発生後の行動を事前に決めることで、プロジェクトへの影響を抑えることができます。

よくある勘違い

コンティンジェンシープランは「悲観的な計画」ではない

コンティンジェンシープランを作成すると、「問題が起きる前提で考えている」と感じる人もいます。

しかし、目的は問題を予測して悲観することではありません。

不確実な状況でも、冷静に対応できる準備を整えることが目的です。

すべてのリスクに作成する必要はない

すべてのリスクへ詳細な計画を作成すると、管理負荷が大きくなります。

影響度や発生可能性を考慮し、重要なリスクに絞って作成することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、リスク発生時の対応判断や危機管理が重要なテーマになります。

論文では、以下の観点を説明できることが重要です。

• どのようなリスクを想定したか
• なぜ事前に対応計画を準備したか
• どのような発動条件を設定したか
• 発生後にどのような対応を行ったか

単に「リスク対応を準備した」と書くのではなく、「発生時の混乱を防ぐために、事前に判断基準と行動を明確化した」と説明できることが重要です。

PM道場のワンポイント

コンティンジェンシープランは、問題が発生した時に慌てないための「未来への準備」です。

優れたプロジェクトマネージャは、問題が起きないようにするだけではなく、起きた場合にもプロジェクトを継続できる仕組みを作っています。

特に重要なのは、計画書を作成することではありません。

「誰が」「いつ」「どの条件で」「何をするか」を明確にしておくことです。

リスクをゼロにできないからこそ、発生後の対応力を高めることがプロジェクト成功につながります。

関連用語

• リスク（Risk）
• リスクマネジメント
• リスク対応
• リスク登録簿（Risk Register）
• リスクトリガー
• コンティンジェンシー予備
• 課題（Issue）
• エスカレーション

まとめ

コンティンジェンシープランとは、リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

重要なのは、問題発生後に慌てて対応するのではなく、あらかじめ判断基準や行動を明確にしておくことです。

プロジェクトマネージャには、不確実性をなくす力だけではなく、不確実性に備える力が求められます。

コンティンジェンシープランは、そのための重要なマネジメント手法です。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• リスク分析とは？
• リスク対応とは？
• リスク登録簿（Risk Register）とは？
• エスカレーションとは？

よくある質問（FAQ）

Q. コンティンジェンシープランとは何ですか？

A. リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

Q. リスク対応計画との違いは何ですか？

A. リスク対応計画は対応方針を決めるもの、コンティンジェンシープランは発生時の具体的な行動を決めるものです。

Q. すべてのリスクにコンティンジェンシープランは必要ですか？

A. いいえ。影響度が大きく、発生時に迅速な対応が必要な重要リスクを対象に作成します。

プロジェクトの現場では、このように問題を抱え込んでしまうケースがあります。

しかし、問題への対応が遅れるほど、プロジェクトへの影響は大きくなる可能性があります。

そこで重要になるのがエスカレーション（Escalation）です。

この記事では、エスカレーションの意味や目的、適切なタイミング、プロジェクトマネージャが実践すべきポイントについて解説します。

一言でいうと

エスカレーションとは、「自分や現在のチームだけでは解決できない問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動」です。

エスカレーションとは

エスカレーションとは、問題やリスク、判断が必要な事項を、上位者や関係する意思決定者へ引き上げることです。

プロジェクトでは、プロジェクトマネージャだけでは判断できない問題が発生することがあります。

例えば、

• 予算追加が必要になる
• 納期変更の判断が必要になる
• 組織間の調整が必要になる
• 重要なリスクが顕在化する

このような場合、適切なタイミングでエスカレーションを行うことで、迅速な意思決定につなげることができます。

エスカレーションが重要な理由

プロジェクトでは、問題そのものよりも「発見後の対応の遅れ」が大きな影響を与えることがあります。

例えば、以下のようなケースです。

• 小さな遅延を報告せず、後から重大な遅延になる
• 品質問題を抱え込み、リリース直前に発覚する
• 判断待ちの事項が放置され、作業が停止する

早い段階でエスカレーションすることで、選択できる対応策が増えます。

つまり、エスカレーションは「問題が大きくなってから助けを求める行為」ではなく、「問題を大きくしないための予防的な行動」です。

エスカレーションするべきタイミング

エスカレーションの判断で重要なのは、「解決策が決まってから報告する」のではなく、「問題だと認識した段階で共有する」ことです。

例えば、以下のような状況ではエスカレーションを検討します。

• プロジェクト目標へ影響する可能性がある
• 自分の権限では判断できない
• 複数チームに影響する
• 期限までに解決できない可能性がある
• 追加予算や人員が必要になる

エスカレーションで重要な報告内容

エスカレーションでは、単に「問題があります」と伝えるだけでは十分ではありません。

最低限、以下の内容を整理して共有します。

原因分析や対策案が完成していなくても、まず状況を共有することが重要です。

エスカレーションと報告の違い

エスカレーションは単なる報告ではなく、問題解決のために適切な人へ判断をつなぐ活動です。

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで、重要な機能の開発が遅れる可能性が判明したとします。

プロジェクトマネージャが一人で原因分析や対策検討を続けると、対応が遅れる可能性があります。

そこで、以下のようにエスカレーションします。

• 現在判明している事実を共有する
• 納期影響の可能性を伝える
• 原因分析中であることを説明する
• 必要な支援や判断を依頼する

この段階では、完璧な解決策を提示する必要はありません。

重要なのは、問題を早期に共有し、組織として対応できる状態を作ることです。

よくある勘違い

エスカレーションは失敗報告ではない

エスカレーションを「問題を起こしたことを認める行為」と考えてしまうことがあります。

しかし、実際にはプロジェクトを成功させるためのマネジメント活動です。

原因分析が終わるまで待つ必要はない

原因分析や対策検討には時間がかかります。

その間に問題の影響が広がる可能性があります。

まず事実を共有し、その後詳細分析を進めることも重要な判断です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、問題発生時の対応や関係者調整が重要なテーマになります。

論文では、以下のような観点が評価されます。

• 問題をどのタイミングで認識したか
• 誰へどのように共有したか
• 必要な判断や支援をどのように得たか
• その結果、プロジェクトをどう改善したか

優れたPMは、問題を隠すのではなく、適切なタイミングで組織の力を活用します。

PM道場のワンポイント

エスカレーションで大切なのは、「解決してから報告する」ことではなく、「問題だと思った時点で共有する」ことです。

プロジェクトマネージャは、すべての問題を一人で解決する役割ではありません。

必要な人へ情報を届け、適切な判断を引き出すことも重要な役割です。

特に、コミュニケーションが苦手なPMほど、「原因を整理してから伝えなければならない」と考えがちです。

しかし、早期共有によって、より多くの選択肢を持って対応できます。

優れたプロジェクトマネージャは、エスカレーションによって問題解決のスピードを高めています。

関連用語

• リスク（Risk）
• 課題（Issue）
• 問題管理
• 意思決定
• ステークホルダー
• コミュニケーションマネジメント
• 報告
• プロジェクトスポンサー

まとめ

エスカレーションとは、自分やチームだけでは解決できない問題や判断事項を、適切な相手へ共有し、支援や判断を得る活動です。

重要なのは、問題が大きくなってから行うのではなく、影響が広がる前に実施することです。

プロジェクトマネージャに求められるのは、すべての問題を一人で解決する力ではありません。

組織の力を活用し、プロジェクトを成功へ導くための判断を行う力です。

関連記事

• リスク（Risk）とは？
• 課題（Issue）とは？
• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• プロジェクトスポンサーとは？

よくある質問（FAQ）

Q. エスカレーションとは何ですか？

A. 解決が難しい問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動です。

Q. エスカレーションはいつ行うべきですか？

A. 問題の影響が広がる可能性があると判断した時点で、早めに実施することが重要です。

Q. 原因分析や対策案がなくてもエスカレーションしてよいですか？

A. はい。まず事実や影響を共有し、必要な支援を得ることが重要です。

「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」

という考え方について書きました。

では、そのコミュニケーションは、いつ設計すればよいのでしょうか。

私の答えは、プロジェクト開始時のキックオフミーティングです。

キックオフミーティングというと、次のような「説明会」のイメージを持っている方も多いでしょう。

• プロジェクトの目的を説明する
• スケジュールを共有する
• 体制を説明する

もちろん、それらも大切です。

しかし、人見知りだった私にとって、キックオフミーティングの一番の目的は違いました。

「初対面」を終わらせること。

これが、私にとってのキックオフミーティングの本当の価値でした。

人見知りにとって一番難しいのは「最初の一言」

私は昔から人見知りでした。

特に苦手だったのは、初対面の人との会話です。

プロジェクトが始まると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 「何を話せばいいんだろう。」
• 「今話しかけても迷惑ではないかな。」

そんなことばかり考えてしまい、自分から話しかけることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

しかし、その「そのうち」は、決まってトラブルが起きたときでした。

キックオフをやらないと、プロジェクトは「いつの間にか」始まってしまう

ある時、キックオフミーティングを実施しなかったプロジェクトがありました。

気付けば、それぞれが作業を始め、プロジェクトは静かにスタートしていました。

しかし、そのプロジェクトではチームマネジメントがうまくいきませんでした。

プロジェクトメンバーは、

• 何のためにこのプロジェクトをやるのか
• どれほど重要なプロジェクトなのか

を十分に理解できていませんでした。

そのため、当事者意識も生まれにくく、PMである私が後から一人ひとりとコミュニケーションを取り、プロジェクトへの意識を高めていく必要がありました。

人見知りの私にとって、それは非常に大きな負担でした。

今振り返ると、問題はコミュニケーション能力ではありません。

プロジェクトのスタートを設計できていなかったのです。

キックオフは「説明会」ではなく「チームを作る場」

それ以来、私は必ずキックオフミーティングを実施するようになりました。

ただし、目的は説明ではありません。

私が一番大切にしているのは、

「このプロジェクトを成功させるチームを作ること」です。

そのために、必ず次のことを伝えています。

• このプロジェクトの目的
• なぜ今このプロジェクトが必要なのか
• ステークホルダーが期待していること
• 会社として期待していること
• PMとして、このプロジェクトにかける思い

スケジュールや体制は資料を見れば分かります。

しかし、

「このプロジェクトは重要なんだ。」

という熱意は、PM自身の言葉でしか伝えられません。

私は、この時間がプロジェクトメンバーの当事者意識を育てるのだと思っています。

不安を話してもらう時間が、未来のリスクを減らす

キックオフでは、もう一つ必ず行っていることがあります。

一人ひとりに、不安なことを話してもらうことです。

プロジェクトの規模によって時間は調整しますが、できる限り全員に話してもらいます。

すると、

• この技術は経験がありません
• スケジュールが少し心配です
• 他案件との兼務があります

など、さまざまな声が聞こえてきます。

これは単なる自己紹介ではありません。

私はこの時間を、リスクを見つける時間だと思っています。

さらに、この時間にはもう一つ大きな意味があります。

全員が一度は発言することで、

「話してもいい場なんだ。」

という空気が生まれます。

この最初の一言が、その後の相談のしやすさにつながっていくのです。

最初の30分が、その後数か月のコミュニケーションを変える

キックオフが終わると、不思議なくらいコミュニケーションが楽になります。

• チャットを送る
• 電話を掛ける
• 相談する

どれも心理的なハードルが下がるのです。

特に電話では、その効果を強く感じます。

相手は、私の顔を思い出しながら話してくれている。

私も、「一度話した相手だから」という安心感があります。

トラブルが起きたときも、

「すぐ連絡してください。」

と言えば、すぐに対応してくれることが増えました。

私はこれを、キックオフで築いた信頼関係のおかげだと考えています。

PMBOK®には「キックオフをやりましょう」とは書かれていない

PMBOK®には、

「必ずキックオフミーティングを実施しましょう。」

とは書かれていません。

しかし、コミュニケーション・マネジメントでは、必要な情報を必要な人へ適切なタイミングで届けることが重要だとされています。

また、ステークホルダー・エンゲージメントでは、ステークホルダーとの良好な関係を構築し、維持することが求められます。

私は、この考え方を実践する最初の機会がキックオフミーティングだと考えています。

単なる説明会ではありません。

チームを作り、信頼関係を築き、コミュニケーションを始めるための最初のイベントなのです。

おわりに

私は今でも人見知りです。

初対面の人と話すことが得意になったわけではありません。

それでも、キックオフミーティングを大切にするようになってから、コミュニケーションに対する苦手意識は大きく減りました。

理由は簡単です。

自分を変えたのではなく、コミュニケーションが生まれる環境を設計したからです。

キックオフミーティングは、プロジェクト開始の儀式ではありません。

チームが同じ方向を向き、安心して相談できる関係を作るための第一歩です。

だから私は、人見知りのPMほどキックオフミーティングを大切にしてほしいと思っています。

あなたへの問いかけ

あなたのプロジェクトのキックオフミーティングは、「説明会」で終わっていませんか。

それとも、チームを作るための最初のコミュニケーション設計になっているでしょうか。

役割や責任が曖昧なまま進めてしまうと、作業漏れや意思決定の遅れ、関係者間の認識違いにつながります。

こうした問題を防ぐためによく利用されるのが「RACI」です。

この記事では、RACIの意味や4つの役割、実務での活用方法、PMBOK®やプロジェクトマネージャ試験で重要なポイントまでわかりやすく解説します。

一言でいうと

RACIとは、「仕事ごとに役割と責任を明確にするための役割分担表（責任割当の考え方）」です。

RACIとは

RACIとは、各作業に対して「誰が実施し、誰が最終責任を持ち、誰に相談し、誰へ情報共有するか」を整理するフレームワークです。

一般的には、責任割当マトリックス（RAM：Responsibility Assignment Matrix）の形式で表現されます。

役割を明確にすることで、責任の重複や抜け漏れを防ぎ、スムーズなプロジェクト運営につながります。

RACIの4つの役割

RACIの具体例

例えば、「設計書レビュー」を行う場合、次のように整理できます。

このように整理することで、誰が何を担うのかが一目で分かります。

RACIを使うメリット

• 責任者が明確になる
• 意思決定がスムーズになる
• 作業漏れや責任の押し付け合いを防げる
• 関係者との認識を合わせやすい
• 新しいメンバーでも役割を理解しやすい

OBS・WBSとの関係

RACIは単独で作るものではありません。

通常は、WBSで整理した作業と、OBSで整理した組織や担当者を組み合わせて作成します。

つまり、

• WBS：「何をやるか」
• OBS：「誰が関わるか」
• RACI：「それぞれがどのような役割を担うか」

という関係になります。

実務ではこんな場面で活用される

例えば、顧客から要件変更の依頼があったとします。

RACIが整理されていれば、「変更内容を評価する担当者」「承認する責任者」「相談すべき関係部署」「結果を報告する相手」が明確になります。

その結果、「誰が判断するのか分からない」という状況を防ぐことができます。

よくある勘違い

ResponsibleとAccountableは同じではない

Responsibleは「作業を行う人」、Accountableは「最終責任を負う人」です。

小規模プロジェクトでは同じ人が兼ねることもありますが、大規模プロジェクトでは分けることが一般的です。

Accountableは複数人にしない

一つの作業に最終責任者が複数いると、責任の所在が曖昧になります。

そのため、原則としてAccountableは1人に設定します。

全員をConsultedにしない

相談相手が多すぎると、意思決定に時間がかかります。

本当に意見が必要な人だけをConsultedに設定することが重要です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、「役割分担」「責任の明確化」「関係者との調整」が重要なテーマとして出題されます。

午後Ⅱ論文では、「役割をどのように整理し、責任の曖昧さを防いだか」を具体的に説明できると高い評価につながります。

PMBOK®でも、RACIは責任割当マトリックス（RAM）の代表例として紹介され、プロジェクトチームの役割と責任を明確にするための手法として活用されています。

PM道場のワンポイント

RACIは「役割を決める表」ではなく、「責任の曖昧さをなくすための仕組み」です。実務では、「担当は決まっているのに、誰も判断しない」という状況がよくあります。これは、Responsibleは決まっていても、Accountableが曖昧だからです。

逆に、「全員で相談して決めよう」とすると、誰も決断できず、プロジェクトは止まってしまいます。

優れたプロジェクトマネージャは、RACIを使って「誰が実施するか」だけでなく、「誰が最終的に決めるのか」まで明確にしています。

プロジェクトのスピードは、責任の明確さで決まると言っても過言ではありません。

関連用語

• RAM（責任割当マトリックス）
• OBS
• WBS
• ステークホルダー
• プロジェクトマネージャ
• ガバナンス
• コミュニケーションマネジメント
• 組織構造

まとめ

RACIとは、作業ごとに役割と責任を整理し、プロジェクトに関わるメンバーの責任範囲を明確にするためのフレームワークです。

Responsible・Accountable・Consulted・Informedを適切に設定することで、責任の曖昧さを防ぎ、スムーズな意思決定やコミュニケーションにつながります。

プロジェクトを円滑に進めるためには、「誰が作業するか」だけでなく、「誰が最終責任を持つか」を明確にすることが重要です。

関連記事

• OBSとは？
• WBSとは？
• プロジェクトマネージャとは？
• ステークホルダーとは？

よくある質問（FAQ）

Q. RACIとは何ですか？

A. 作業ごとに「実施者」「最終責任者」「相談相手」「情報共有先」を明確にするための役割分担フレームワークです。

Q. ResponsibleとAccountableの違いは何ですか？

A. Responsibleは実際に作業を行う担当者、Accountableは最終的な責任を負い、承認や意思決定を行う責任者です。

Q. RACIはどのような場面で使われますか？

A. WBSで整理した作業ごとに役割と責任を明確にしたい場面や、複数部署が関わるプロジェクトで責任範囲を整理したい場面で活用されます。

• 令和7年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

チームの育成について、どのように育成したのか、なぜその育成方法をとったのかを論理的に説明できると良いです。

設問ア｜プロジェクト目標と不健全な状態を具体的に説明する

設問アでは以下3点について論じます。

• ① システム開発プロジェクトの目標
• ② 目標の達成が危ぶまれると考えたメンバーやチームの想定された不健全な状態
• ③ その状態を引き起こすと考えた人間的側面での背景や事象

① システム開発プロジェクトの目標

ここで重要なのは、目標を定量的に示すことです。
設問ウにおいて、目標達成にどのような貢献をしたかの説明が求められるため、定量的に説明しておくことで、根拠のある分かりやすい説明ができます。

例えば以下のような内容です。

• 納期遵守率100%
• レビュー指摘件数20%削減
• 生産性15%向上
• 障害件数30%削減

② 不健全な状態

ここでは、具体的で分かりやすい説明を心がけると良いです。
実際にどのような状態だったのか、プロジェクトマネージャとしてどのように把握したのかを説明できると良いです。

例えば以下のような内容があります。

• メンバーからのエスカレーション
• 打合せで発言が少ない
• レビュー遅延が頻発している
• 成果物の品質低下
• 作業の押し付け合いが発生している

単に「雰囲気が悪かった」と書くのではなく、どのような事象から問題を把握したのかまで説明すると、説得力が増します。

③ 人間的側面での背景や事象

問題文にもあるように、背景としては、異なる慣習や価値観を持つメンバーや急なメンバー交代などがあります。

例えば以下のような背景です。

• グローバルプロジェクトで複数国のメンバーが参加していた
• 急な離任により引継ぎ不足が発生した
• 経験差が大きいチーム構成だった

また、事象としては以下のような内容があります。

• 協力する姿勢が見られない
• 一体感が不足している
• 士気が上がらないメンバーが多い
• 課題を共有しない

ここでは、技術面ではなく「人間関係」に焦点を当てることが重要です。

設問イ｜健全な状態と育成計画を論理的に説明する

設問イでは以下2点を論じます。

• ① 目指したメンバーやチームの健全な状態と、その状態を目指した理由
• ② 人間的側面に着目して作成したチームの育成計画（工夫したことを含める）

① 目指した健全な状態

健全な状態とはどのような状態なのかを具体的に説明します。
設問アで説明した不健全な状態と対になる状態を示せると良いです。

例えば以下のような状態です。

• メンバー同士が自主的に助け合う
• 会議で積極的に発言する
• 問題を早期共有する
• レビューを協力して実施する

また、なぜその状態を目指したのかも説明します。
ここでは、プロジェクト目標との関連を示すことが重要です。

例えば、「納期遵守率100%を達成するためには、課題の早期共有が必要だった」などのように説明できると、論理的な文章になります。

② 人間的側面に着目したチームの育成計画

人間的側面という言葉は難しく感じますが、ここでは以下のような内容を意識すると良いです。

• 協力
• 信頼関係
• 一体感
• 士気

つまり、チームとして目標達成を目指すための人間関係改善について説明できれば良いです。

信頼関係を築くための施策

• 1on1ミーティングを実施した
• 雑談時間を設けた
• 困りごとを相談しやすい雰囲気を作った

協力体制を作るための施策

• ペア作業を導入した
• レビューを相互実施にした
• 進捗共有会を毎日実施した

一体感を高めるための施策

• チーム目標を見える化した
• 成功事例を全員へ共有した
• 感謝を伝える場を設けた

士気向上の施策

• 小さな成功を積極的に称賛した
• 成果を定量的に共有した
• メンバーへ役割と責任を与えた

さらに、チームメンバーの自己組織化について説明できると良いです。

自己組織化とは、メンバーがプロジェクト目標達成のために、自律的に責任を持って行動することです。
また、チーム育成についても、メンバー自身が主体的に関わる状態を指します。

工夫としては以下のような内容があります。

• メンバーから責任者を選出した
• 育成計画をメンバーと一緒に作成した
• 改善活動をチーム主体で運営した

設問ウ｜育成計画の成果を定量的に説明する

設問ウでは以下2点について論じます。

• ① 育成計画を実行した過程で発生した問題と解決策
• ② 育成計画の実行結果がプロジェクト目標にどのように貢献したか

① 発生した問題と解決策

ここでは、育成中にどのような問題が発生したのかを具体的に説明します。

例えば以下のような問題です。

• 会議が形骸化した
• 一部メンバーしか発言しなかった
• 改善活動が継続しなかった

さらに、その問題がなぜ発生したのかも分析できると良いです。
ここで使いやすいのが「なぜなぜ分析」です。

なぜを繰り返すことで原因を深掘りでき、解決策の根拠を強くできます。

例えば以下のような流れです。

• なぜ発言しないのか → 発言しづらい雰囲気だった
• なぜ雰囲気が悪いのか → 否定的な意見が多かった
• なぜ否定的なのか → レビュー方針が統一されていなかった

そのうえで、具体的な解決策を書きます。

• 発言ルールを決めた
• レビュー観点を標準化した
• ファシリテータを配置した

さらに、解決策によってどのように改善したのかまで説明できると良いです。

② 育成計画がプロジェクト目標へ貢献した内容

ここでは、設問アで説明した定量的目標と比較して説明することが重要です。

例えば以下のように比較します。

• 改善前：納期遅延率30%
• 改善後：納期遵守率95%

• 改善前：レビュー指摘件数120件
• 改善後：レビュー指摘件数70件

不健全な状態のままだった場合と、健全な状態へ改善した場合を比較することで、育成の効果を論理的に説明できます。

まとめ

この問題では、単に「教育しました」と書くだけでは不十分です。
チームの状態をどのように把握し、なぜその状態になったのかを分析し、どのような育成を実施したのかを論理的に説明することが重要です。

特に以下3点を意識すると、説得力のある論述になります。

• 定量的に説明する
• 人間的側面を具体的に書く
• 改善前後を比較して成果を書く

午後Ⅱは「論理性」が重要です。
状態・原因・改善・成果の流れを意識して答案を作成しましょう。