はじめに
応用情報技術者試験に向けて勉強を進める中で、「プロジェクトマネジメント（PMBOK）」分野の重要キーワードを自分なりに整理しました。
この分野は以下のような特徴があり、
理解が曖昧なままだと、過去問でも正解しにくいと実感しています。
- 10の知識エリアごとに多数の用語が登場する
- 言葉の意味が似ていて混同しやすい
そこで本記事では、次のような方針で用語をまとめています。
✅ 各用語の「正しい定義」をできるだけシンプルに整理
✅ 思い出しやすくなるような「ゆるい補足メモ」付きで補完
あくまで自分用の整理メモですが、
同じように応用情報技術者試験に取り組んでいる方やPMBOKを一から学び直したい方の参考になれば幸いです。
1. 統合マネジメント
プロジェクトのすべての要素を統合し、全体を円滑に進めるためのマネジメント。
プロジェクト憲章
プロジェクト開始の正式な承認を得る文書。プロジェクトマネージャーの権限が明確に記される。
📝memo：
プロジェクト開始時に「よし、このプロジェクト始めよう」と正式に認める文書。
プロジェクトマネジメント計画書
全ての知識エリアの計画を統合した文書。変更管理や進捗管理の基準にもなる。
📝memo：
各マネジメント分野の計画をまるっとまとめた計画の親玉。これを軸にプロジェクトが回る。
統合変更管理
変更要求を一元的に受け付け、影響を評価し、必要に応じて承認・却下するプロセス。
📝memo：
「これ、やっぱり変えたいんだけど」といった変更依頼をまとめて捌く係。変更の影響をちゃんと見てから、やるかやらないかを判断する。
変更要求
スコープの拡張や縮小などを含む変更を正式に申請するプロセス。
📝memo：
「スコープ増やして！」「バグ修正したい！」などの申し出。きちんと手続きを踏んで申請。
構成管理（コンフィギュレーションマネジメント）
システムを構成する要素（ハード・ソフト等）をリスト化・管理する手法。変更の影響範囲分析などに使われる。
📝memo：
どの部品・ソフトがどう構成されているかを“棚卸し”して把握しておく仕組み。
フェーズゲート
プロジェクトの各フェーズ終了時に継続可否を判断するためのチェックポイント。
📝memo：
「ここまでOK？次のステップ進んでいい？」といったチェックポイント。プロジェクトを少しずつ進める“節目”。
2. ステークホルダーマネジメント
プロジェクトに関わる利害関係者と良好な関係を構築し、プロジェクトの成功に導く活動。
ステークホルダー
プロジェクトに影響を与える、または影響を受ける個人・組織。
📝memo：
プロジェクトに「なんらかの思惑がある」人たち。味方もいれば、厳しい目で見てくる人もいる。
ステークホルダー登録簿
ステークホルダーの氏名、連絡先、所属、役職、関与度などをまとめた文書。
📝memo：
「この人たちが関係者です！」って名簿。誰が何に関与してるか、事前に把握しておくことができる。
エンゲージメント計画
ステークホルダーごとにどのように関与させ、どのように対応するかを定めた計画。
📝memo：
あの人には丁寧に報告、この人はざっくりでOK…みたいな関係者ごとの対応マニュアル。
ステアリングコミッティ
利害関係者の代表で構成され、調整や意思決定を行う委員会。
📝memo：
「偉い人たちの集まり」。プロジェクトの重要な判断をしてくれるけど、納得させるには説明力がいる。
3. コミュニケーションマネジメント
プロジェクト内外の関係者と効果的な情報伝達を行うための管理活動。
コミュニケーションマネジメント計画
情報の内容、伝達方法、頻度、形式などを定めた計画。
📝memo：
「誰に・いつ・何を・どうやって伝えるか」を決める作戦会議の計画。行き違い防止に必須。
情報配布計画
どの情報を誰に、どのタイミングで、どのように伝えるかの詳細を定義。
📝memo：
「週次で部長に報告」「トラブルは即連絡」など、情報の出し方・渡し方をきっちり決める設計図。
情報の内容・形式・詳細度
進捗報告や成果物レビューの質に関わる要素。試験では問われやすい。
📝memo：
「要点だけでいいのか」「グラフがいるのか」など、受け手に合わせて“ちょうどいい”情報量を意識。
4. スコープマネジメント
プロジェクトで実施する作業の範囲を定義し、管理する活動。
スコープ記述書
プロジェクトで実施する作業と、除外される作業を明記した文書。
📝memo：
「ここまでがウチの仕事、ここからは関係ありません」と明記した線引き書。
責任の押し付け合い防止に◎。
WBS（Work Breakdown Structure）
作業を階層的に分解し、全体の構造を可視化する図。
📝memo：
大きな作業を、パズルのピースみたいに分解していく図。これを見れば全体像がつかめる。
ワークパッケージ
WBSの最下層にあたる作業単位。担当者やコストなどを割り当てる対象。
📝memo：
「この作業はAさんが●円でやります」みたいに割り当てる作業の粒度。WBSの最小単位。
アクティビティ
ワークパッケージをさらに細分化した作業単位。
📝memo：
ワークパッケージをさらに細かくした「やることリスト」。ToDoレベルの粒感。
5. 資源マネジメント
プロジェクトに必要な人的・物的資源を計画・管理する。
人的資源／物的資源
人員・設備・機材など、プロジェクト遂行に必要な全ての資源。
📝memo：
人・モノ・機材…とにかく必要なリソースの全部。コストにも関わるので管理が肝。
人月
1人が1か月間フルタイムで働いた工数の単位。
📝memo：
「1人が1か月働くとこれくらいの作業量」っていう工数の単位。見積もりやスケジュールの基本。
RACIチャート
責任分担を明確にするマトリクス（Responsible／Accountable／Consulted／Informed）。
-
R：Responsible（実行責任者）：
実際に作業を担当・実行する人。1つのタスクに複数いてもよい。
📝memo：
「手を動かす人」。コード書いたり資料作ったり、いわゆる“やる人”
-
A：Accountable（説明責任者）：
タスクに対して最終的な責任を持つ人。承認・判断を行う。1タスクに1人だけ。
📝memo：
「上司・リーダー的ポジション」。失敗しても「責任は私が取る」と言う人。
-
C：Consulted（相談相手）：
専門知識を持っていて、相談・レビューを受ける人。双方向のコミュニケーションあり。
📝memo：
「詳しい人に聞いてみよう枠」。アドバイザーや先輩。
-
I：Informed（報告対象）：
作業内容や進捗の報告を受ける人。基本的に一方向の情報共有。
📝memo：
「とりあえず報告はいる人」。マネージャーや他部署など。
チームマネジメント
チームビルディング、育成、コンフリクトマネジメントを含む。
📝memo：
ただの人集めじゃなく、モチベや関係性もケアする。プロジェクトの空気感を整える大事な仕事。
6. コストマネジメント（Cost Management）
プロジェクトにかかるコストの見積、予算設定、管理を行う。
類推法
過去の類似プロジェクトを参考に、規模や特性が似た実績から見積もる方法。
📝memo：
「前にこんな感じの案件あったよね？」ってパターンを使って見積もる方法。
積算法
WBSなどで細分化された各作業項目のコストを積み上げて合計する方法。
📝memo：
小さな作業の見積もりをコツコツ積み上げる。レゴみたいに合体して全体像にする。
三点見積法
楽観値、悲観値、最頻値の3つを基に、期待値を算出して見積もる方法。
📝memo：
「うまくいけばこれくらい、ヤバいとこれくらい、普通ならこれ！」という感じで現実的に見積もるやつ。
パラメトリック見積
過去データと特定のパラメータ（例：工数／ステップ数）との関係に基づいて統計的に見積もる方法。
📝memo：
「1画面に5時間かかるなら、10画面は50時間！」みたいな数式の見積。
COCOMO（COnstructive COst MOdel）
ソースコードの行数をベースに、開発規模やチームの能力等の係数を用いて見積もるモデル。
📝memo：
コード量で見積もる理系寄りな方法。「コードたくさん＝時間かかる」理論。
FP法（ファンクションポイント法）
画面数や帳票、入力・出力件数など外部から見える機能数を元にシステム規模を定量化して見積もる方法。
📝memo：
「このシステム、画面5個・帳票3個あるね」みたいに数えて見積もる。地味に正確。
EVM（出来高管理）
進捗とコストを同時に評価する指標群。
📝memo：
お金と進み具合をセットでチェック。
- PV（Planned Value）：計画された作業の予算値。
- EV（Earned Value）：実際に達成された作業分の予算値。
- AC（Actual Cost）：実際にかかったコスト。
- CV（Cost Variance） ＝EV - AC：コスト差異。
- SV（Schedule Variance） ＝EV - PV：スケジュール差異。
- CPI（Cost Performance Index） ＝EV / AC：コスト効率。
- SPI（Schedule Performance Index） ＝EV / PV：スケジュール効率。
- EAC（Estimate at Completion） ＝BAC / CPI：完成時総コスト見積り。
7. スケジュールマネジメント
プロジェクトのスケジュールを作成・管理する活動。
ガントチャート
作業と期間を棒グラフで可視化。
📝memo：
「この作業、今ここまで進んでるよ〜」が一目で分かる図。
アローダイアグラム法（ADM）
作業順序や日数を矢印と結合点で示す図。
📝memo：
作業が「矢印」、つなぎ目が「イベント」。
プレシデンスダイアグラム法（PDM）
作業の論理的関係（依存関係）をノードと矢印で表現する図示手法。
以下の4つの関係を用いて作業順序を表す。
- FS（Finish to Start）：前の作業が完了してから次の作業が開始される（最も一般的）
- SS（Start to Start）：前の作業の開始と同時に次の作業も開始できる
- FF（Finish to Finish）：前の作業が終わらないと次の作業も終わらせられない
- SF（Start to Finish）：前の作業が始まらないと次の作業が完了できない（極めて稀）
📝memo：
「Aが終わったらB始まる」とか「同時進行OK」とか、関係性で作業つなげるやつ。
クリティカルパス
最も長い作業経路。これが全体の期間を決定。
📝memo：
「ここが遅れると全部アウト！」っていう最重要ルート
クラッシング
クリティカルパス上の作業に追加のリソース（人員・コストなど）を投入することで、作業期間を短縮する方法。コストは増加するが、期間短縮効果が高い。
📝memo：
「人増やせば早くなるでしょ（お金かかるけど）」という力技
ファストトラッキング
本来は順番に実施すべき作業を可能な範囲で並行して進めることで、スケジュールを短縮する方法。リスク（再作業など）は高まるが、コスト増は抑えられる。
📝memo：
急ぎすぎて「Aが終わる前にB始める」方式。失敗リスクもあるけど時短。
8. リスクマネジメント
リスク（不確実性）を特定・分析・対応・監視する活動。
リスクの特定／分析／対応／監視
リスクマネジメントの一連のプロセス。
マイナスのリスク対応（脅威への対策）
-
回避（Avoid）：
リスクの発生を回避する。リスクのある作業を取りやめたり、計画を変更してリスク源を排除する。 -
転嫁（Transfer）：
保険や外部委託などによって、リスクの影響や責任を第三者に移す。 -
軽減（Mitigate）：
リスクの発生確率や影響を低減させる対策を講じる（例：予備期間の確保、レビュー強化）。 -
受容（Accept）：
リスクを許容し、発生した場合は対処するとして何も事前対応しない。
プラスのリスク対応（チャンスへの対策）
-
活用（Exploit）：
チャンスの発生を確実にする（例：有能な人材の早期投入）。 -
共有（Share）：
パートナー企業などとチャンスを共同で活かし、リターンも分け合う。 -
強化（Enhance）：
チャンスの発生確率や影響を高める行動をとる。 -
受容（Accept）：
チャンスが起きたら享受するが、特別な対応はとらない。 -
RBS（Risk Breakdown Structure）：
リスクを技術的・組織的・外部要因などに分類して整理するための構造図。
9. 品質マネジメント
成果物やプロセスの品質を保証・改善する活動。
QC7つ道具（旧QC七つ道具）
主に現場の定量的データに基づいた問題解決に用いられる。
-
パレート図：
問題の重要度・頻度順に並べて、改善すべき主要因を特定。 -
ヒストグラム：
データのばらつきや分布状態を視覚化。 -
散布図：
2つの変数の関係性（相関）を可視化。 -
特性要因図（フィッシュボーン図）：
問題の原因を「人・物・方法・環境」などのカテゴリに分類。 -
管理図：
製品やプロセスの安定性（異常の有無）を監視。 -
チェックシート：
現場でのデータ収集を簡易に行うための表形式。 -
層別：
データを属性別に分類し、傾向や原因をより明確に分析。
新QC7つ道具
複雑な問題の構造整理や意思決定支援に用いる。定性的情報やアイデア整理に強み。
-
親和図法：
多数のアイデアや意見を意味の近いグループに分類。 -
連関図法：
複雑な原因・結果関係を明確にする図解手法。 -
系統図法：
目的達成に必要な手段や要素を論理的に展開。 -
PDPC法：
目標達成までの道筋と途中で起こり得る問題、それに対する対策を整理。 -
マトリックス図法：
複数要素間の関係を分析し、関連の強弱を可視化。 -
マトリックス・データ解析法：
数値データ間の関連性を統計的に分析。 -
アローダイアグラム法：
タスクの順序と依存関係を視覚化し、スケジュール管理に活用。
10. 調達マネジメント
プロジェクトに必要な物品・サービスを外部から調達する活動。
RFI（Request for Information）
情報提供依頼書。
製品・サービスの導入を検討する際に、まだ仕様や要件が固まっていない段階で複数のベンダーから情報を収集する目的で発行される文書。市場調査や技術動向の把握に活用され、RFPを作成する前段階で使用される。
📝memo：
「とりあえず、どんなのあるのか教えて〜」と聞くやつ。まだ買う気はない。
RFP（Request for Proposal）
提案依頼書。
プロジェクトに必要な製品やサービスの提供者（ベンダー）に対し、提案を求める文書。要件定義、評価基準、スケジュール、契約条件などを明示し、提案内容を比較・選定するために用いられる。具体的な仕様がある程度明確になっている段階で使用。
📝memo：
「これ欲しいんだけど、どこが一番いい提案してくれる？」って真剣モード。
ベンダー選定／契約／監視
調達の一連の流れを管理。
契約タイプ
定額契約・出来高契約・コストプラス契約など。
おわりに
この記事では、応用情報技術者試験の午後問題でも頻出の「PMBOKの10の知識エリア」について、キーワードを中心に整理してみました。
あくまで自分の理解を深めるためのまとめではありますが、同じようにプロジェクトマネジメント分野を一から学び直している方や、試験対策に取り組んでいる方の参考になればうれしいです。