No.01
プロジェクト
Project
明確な目的を達成するために、有期的・一回性で行われる業務活動。期間・予算・成果物が定義され、ルーティン業務（オペレーション）とは明確に区別される。プロジェクトは「始まり」と「終わり」があるからこそ管理対象になる。
PM Glossary
プロジェクトマネジメント 関連用語集
50 のキーワード
プロジェクトの失敗要因の多くは、技術や能力ではなく 「言葉が揃っていない」 ことに起因します。「スコープ」「ベースライン」「リスク」「クリティカルパス」──同じ単語を口にしていても、PM・経営層・現場メンバーが思い浮かべているものは驚くほどズレています。
本ページでは、JG CORPORATION のコンサルタント・PM が日々のプロジェクトで扱う PM 関連の重要キーワードを 5 つのカテゴリ・50 語 に整理し、それぞれを 2〜3 行のシンプルな説明にまとめました。さらに最下部には、用語の理解を実践に橋渡しするためのトピックとして、「実行可能なプロジェクト計画」とは何か を 6 つの原則・アンチパターン比較・チェックリストの形で掲載しています。
01
PM の基礎
FOUNDATIONSNo.02
プロジェクトマネジメント
Project Management
プロジェクトの目的を、制約条件の中で計画的に達成するための知識・スキル・ツール・技法の体系。立ち上げ・計画・実行・監視/コントロール・終結の 5 プロセス群と、スコープ・スケジュール・コスト等の知識エリアから構成される。
No.03
QCD
Quality / Cost / Delivery
プロジェクトの三大制約条件＝品質・コスト・納期。1 つを動かせば他が動くトレードオフ関係にあり、PM の仕事は「どの QCD バランスでプロジェクトを着地させるか」を意思決定し続けることに他ならない。
No.04
制約条件 / 前提条件
Constraints / Assumptions
プロジェクトの自由度を縛る条件（予算上限・期限・規制・人員制限など）と、検証なしに「そうである」と置く前提。前提が外れるとリスクが顕在化するため、必ず憲章・計画書に明文化する。
No.05
プロジェクト憲章
Project Charter
プロジェクトを公式に立ち上げるための承認文書。背景・目的・成功基準・概算スコープ／予算／期間・主要ステークホルダー・PM 権限などを記す。憲章なしに走り出すプロジェクトは「誰のための、何の達成か」が共有されていない危険な状態。
No.06
ステークホルダー
Stakeholder
プロジェクトに影響を与える／影響を受けるすべての関係者。経営層・顧客・現場ユーザー・ベンダー・規制当局まで含む。誰が「賛成派／反対派／中立」なのかをマッピングし、巻き込み方を設計するのが PM の重要業務。
No.07
スコープ
Scope
プロジェクトで「やること」と「やらないこと」の境界。プロダクトスコープ（何を作るか）とプロジェクトスコープ（どの作業を行うか）を分けて定義する。明文化されていないスコープはスコープクリープの温床となる。
No.08
PMO
Project Management Office
プロジェクトマネジメントの標準化・支援・統制を担う組織機能。複数 PJ の進捗統合・テンプレート提供・教育・品質監査などを行う。支援型／統制型／指揮型の 3 タイプがあり、組織成熟度で使い分ける。
No.09
プロジェクトライフサイクル
Project Life Cycle
プロジェクトを「立ち上げ → 計画 → 実行 → 監視/コントロール → 終結」と段階的に進める枠組み。ウォーターフォール（予測型）・アジャイル（適応型）・ハイブリッドで形は変わるが、節目の意思決定ポイントが必要なのは共通。
No.10
PMBOK / PMI
PMBOK Guide / PMI
米国 PMI（Project Management Institute）が編纂するプロジェクトマネジメントの国際的なナレッジ標準。最新版（第 7 版）では原則ベース＋テーラリング重視へ進化。PMP 資格はこの体系をベースに設計されている。
02
計画立案
PLANNINGNo.11
WBS
Work Breakdown Structure
プロジェクトの成果物・作業を階層的に分解した「作業構造図」。最下位の「ワークパッケージ」まで分解することで、見積り・スケジュール化・担当割当てが可能になる。PM 計画のすべての出発点。
No.12
マイルストーン
Milestone
プロジェクトの重要な節目を示すゼロ工数のポイント（要件確定／設計レビュー完了／カットオーバー等）。マイルストーンを置くことで進捗の客観評価と関係者間の期待値合わせができる。
No.13
ガントチャート
Gantt Chart
作業の開始・終了・依存関係・進捗を横棒で可視化したスケジュール表。直感的だが、ガント線を引いただけでは「実行可能な計画」にはならず、WBS・依存関係・リソース割当てがあって初めて意味を持つ。
No.14
クリティカルパス
Critical Path Method (CPM)
プロジェクト全体の納期を決定する作業の連鎖。この経路上のタスクが 1 日でも遅れれば全体納期に直撃するため、PM は最優先で監視する。フロート（余裕日数）がゼロの作業群とも言える。
No.15
ベースライン
Baseline
スコープ・スケジュール・コストについて「正式に承認された基準計画」。実績との差異（バリアンス）を測るための原点で、変更には正式な変更管理プロセスを経る必要がある。
No.16
見積り技法
Estimation Techniques
類推見積り・パラメトリック見積り・ボトムアップ見積り・三点見積り（PERT）など、不確実性を含む作業を量的に見積もるための技法群。フェーズ初期は粗く、後期は精度を高めるローリングウェーブで運用する。
No.17
リソースアサインメント
Resource Assignment
タスクに具体的な担当者・工数・スキルを割り当てること。「誰がやるか」が決まっていないタスクは実行できない。複数 PJ の人材取り合いを避けるためのリソース平準化（レベリング）も併せて重要。
No.18
工数 / 期間
Effort / Duration
工数は「人 × 時間」で表す作業量、期間は「カレンダー上の経過日数」。10 人日の作業を 2 名で 5 日かけるのか、5 名で 2 日に圧縮するのか──両者を分けて議論できると、計画の議論が一気に正確になる。
No.19
バッファ / コンティンジェンシー
Buffer / Contingency Reserve
不確実性に備えてあらかじめ確保しておく余裕時間・予算。プロジェクト全体のバッファ（CCPM のプロジェクトバッファ等）と個別タスクの安全余裕を分け、可視化して管理することで「サバ読みのサバ読み」を防ぐ。
No.20
プロジェクト計画書
Project Management Plan
スコープ・WBS・スケジュール・コスト・品質・人的資源・コミュニケーション・リスク・調達・ステークホルダーの各計画を統合した中核文書。「ガントチャート＝計画書」ではなく、ガントは計画書の一部に過ぎない。
03
実行と統制
EXECUTION & CONTROLNo.21
スケジュール管理
Schedule Control
ベースラインと実績を比較し、遅延・先行を早期に検知・是正する活動。進捗の見方は「終わったか／終わっていないか（バイナリ）」が基本で、「8 割完了」のような曖昧な報告は赤信号。
No.22
課題管理（Issue）
Issue Management
すでに発生している問題を一覧化し、担当者・期限・状態を管理する仕組み。リスクが顕在化したもの＝課題、と捉えると整理しやすい。課題管理表（Issue Log）が形骸化すると現場の温度が PM に届かなくなる。
No.23
リスク管理
Risk Management
未来に発生しうる不確実事象を識別・分析・対応・監視する活動。回避・転嫁・低減・受容の 4 戦略から選び、定期的にリスクログを更新する。「リスクを書き出した瞬間に半分は対策が始まる」と言われるほど可視化が重要。
No.24
変更管理
Change Control
スコープ・スケジュール・コストに対する変更要求を正式に審議・承認するプロセス。変更管理委員会（CCB）が窓口となり、影響評価のうえベースラインを更新する。「黙って受け入れる」運用が崩壊の第一歩。
No.25
EVM
Earned Value Management
出来高（EV）・計画値（PV）・実コスト（AC）を使って、スケジュール／コストの進捗を定量的に評価する手法。SPI/CPI でプロジェクトの「健康診断」ができ、感覚値に頼らない報告が可能になる。
No.26
ステータス会議
Status Meeting
定期的に進捗・課題・リスク・意思決定事項を共有する場。長時間化させず「決める／確認する／引き上げる」を 30 分で回す設計が重要。週次・隔週・デイリーなど、PJ の鼓動に合わせた頻度に調整する。
No.27
RAID ログ
Risks / Assumptions / Issues / Decisions
プロジェクトの4 大ログ＝リスク・前提条件・課題・意思決定を一元管理する考え方。海外案件で頻繁に使われ、PMO の標準テンプレートとして整備すると、PJ をまたいだ振り返り・教訓の蓄積がしやすくなる。
No.28
是正処置 / 予防処置
Corrective / Preventive Action
是正処置は発生した逸脱を計画値に戻すアクション、予防処置は未発生のリスクを抑えるアクション。両者は CAPA とも呼ばれ、PDCA を回す具体的な「打ち手」として記録・追跡される。
No.29
クラッシング / ファストトラッキング
Crashing / Fast-tracking
遅延を取り戻すための 2 大スケジュール短縮技法。クラッシングはリソース追加でコストと引き換えに期間短縮、ファストトラッキングは本来直列の作業を並列化してリスクと引き換えに期間短縮を狙う。
No.30
エスカレーション
Escalation
現場で判断・解決できない課題を上位層・PMO・ステアリングコミッティに引き上げること。「いつ・誰に・どのレベルで上げるか」を最初に決めておくと、PM が抱え込んで遅延が拡大する事態を防げる。
04
手法と進め方
METHODOLOGYNo.31
ウォーターフォール
Waterfall
要件 → 設計 → 実装 → テスト → 移行と工程を順番に進める伝統的アプローチ。要件が明確で変更が少ない領域（基幹システム、規制対応）で強みを発揮する一方、要件不確実性が高い案件では硬直化しやすい。
No.32
アジャイル
Agile
短い反復（イテレーション）で動く成果物を作りながらフィードバックで方向修正する開発思想。アジャイル宣言の 4 つの価値観・12 の原則を基盤に、Scrum / XP / Kanban 等の具体手法が派生する。
No.33
スクラム
Scrum
アジャイルの代表的フレームワーク。プロダクトオーナー・スクラムマスター・開発チームの 3 役と、スプリント／プランニング／デイリー／レビュー／レトロという 5 つのイベントで構成される。
No.34
カンバン
Kanban
タスクを「To Do / Doing / Done」等のレーンで可視化し、WIP（仕掛り）数を制限することで流れを最適化する手法。トヨタ生産方式に源流を持ち、開発・運用・営業など幅広い業務に応用可能。
No.35
SAFe
Scaled Agile Framework
大規模組織でアジャイルをスケールさせるためのフレームワーク。アジャイルリリーストレイン（ART）・PI Planning などの仕組みで、複数チーム・複数プロダクトの整列を図る。エンタープライズアジャイルの代表格。
No.36
ハイブリッド
Hybrid
フェーズや成果物の特性に応じてウォーターフォールとアジャイルを使い分けるアプローチ。要件・設計はウォーターフォール、開発はアジャイル、というのが日系大企業 IT で実際に最もよく見られる現実解。
No.37
PRINCE2
PRINCE2
英国政府発祥のプロセスベース PM 方法論。7 つの原則・7 つのテーマ・7 つのプロセスで構成され、欧州・公共セクターを中心に普及。PMBOK が「知識体系」なのに対し、PRINCE2 は「手順方法論」寄り。
No.38
リーン
Lean
トヨタ生産方式を起源にした「ムダを徹底的に削ぎ落とす」思想。リーン・スタートアップ、リーンソフトウェア開発、リーン UX など派生概念は多岐にわたる。価値ストリーム・流れ・プル・継続改善が共通言語。
No.39
PMP
Project Management Professional
PMI が認定するPM の国際資格。PMBOK ガイドをベースに、予測型・適応型・ハイブリッドの幅広い知識を問う。大型 SI・コンサル案件では RFP の要件に明記されることもある事実上の業界標準。
No.40
ステージゲート
Stage-Gate
プロジェクトをステージに区切り、各境界（ゲート）でGo/No-Go・修正の意思決定を行う管理手法。新規事業・新商品開発で広く使われ、悪い投資を早期に止める「ストップ可能性」を担保する。
05
人と品質
PEOPLE & QUALITYNo.41
RACI
Responsible / Accountable / Consulted / Informed
タスクに対する役割を実行・説明責任・相談・報告の 4 種で割り当てるマトリクス。「誰が手を動かし、誰が責任を持つか」を明確にし、Accountable は 1 人に絞るのが鉄則。曖昧な役割は遅延の主因となる。
No.42
ステークホルダー分析
Stakeholder Analysis
関係者を「関心度 × 影響力」等のマトリクスにマッピングし、巻き込み戦略を設計する手法。Power/Interest グリッドが定番。賛成派・反対派・無関心派をそれぞれ別の打ち手で動かす。
No.43
コミュニケーションプラン
Communication Plan
誰に・何を・どの頻度・どのフォーマットで伝えるかを事前に設計した計画書。経営層には KPI ダッシュボード、現場メンバーには Slack 日次共有、というように受け手別に最適化する。
No.44
プロジェクトチーム
Project Team
PM の指揮下でプロジェクトを実行する集団。タックマンモデル（Forming → Storming → Norming → Performing）で表される成長プロセスを踏まえ、PM はチームビルディングを意識的に設計する。
No.45
リソースヒストグラム
Resource Histogram
時間軸上に必要リソース量を棒グラフで可視化したもの。山積みすると、特定週に人員が集中しすぎる「リソース山」が見え、リソース平準化（レベリング）の判断材料になる。
No.46
品質マネジメント
Quality Management
成果物が要求を満たすことを保証する活動。品質計画・品質保証（QA：プロセス監査）・品質管理（QC：成果物検査）の 3 つから成る。「テストで品質を作る」のではなく「プロセスに品質を組み込む」のが基本思想。
No.47
教訓（Lessons Learned）
Lessons Learned
プロジェクト中・完了時に「何がうまくいき、何がうまくいかなかったか」を記録・蓄積する仕組み。組織知化されないと毎回同じ失敗を繰り返す。次の PJ の「立ち上げインプット」として再活用する文化が肝。
No.48
プロジェクト完了報告
Project Closure Report
プロジェクトの正式な終結を宣言する文書。スコープ達成状況・QCD 実績・教訓・残課題・引き継ぎ事項などを整理する。完了報告が出ない PJ は組織にとって「終わっていない」状態のまま残り、リソースが滞留する。
No.49
チェンジマネジメント
Organizational Change Management
システムや業務の変更を組織に定着させるための活動。「作って終わり」ではなく、トレーニング・コミュニケーション・推進体制まで設計する。Kotter の 8 段階・ADKAR モデルなどが代表的フレーム。
No.50
リーダーシップ / サーバントリーダーシップ
Leadership / Servant Leadership
PM に求められる「人を動かす力」。指示命令型から、メンバーの成功を支援するサーバントリーダーシップへと潮流は移っている。PMBOK 第 7 版でも、リーダーシップが原則の一つとして明示されている。
TOPIC
実行可能なプロジェクト計画とは何か
WHAT MAKES A PROJECT PLAN ACTUALLY EXECUTABLE?
「ガントチャートはきれいに引いてあるのに、なぜか動かないプロジェクト」──現場でよく目にする光景です。計画書がある＝計画があるわけではありません。計画は本来、明日からチームメンバーがそれを見て手を動かせる粒度・解像度になっていて初めて「実行可能（executable）」と呼べます。
JG CORPORATION のコンサルティング現場で繰り返し確認している、実行可能なプロジェクト計画の 6 つの原則・典型的な落とし穴・レビュー時のチェックリストを、最後にまとめます。新規プロジェクトの計画レビューや、進行中 PJ の健康診断にお使いください。
01
成果物が先、作業は後
最初に決めるのは「作業リスト」ではなく 「何を作るか（成果物）」。WBS は成果物指向で分解し、各ワークパッケージから作業が逆算される。作業ベースで作る WBS は、成果物との対応が崩れ、抜け漏れが生じやすい。
02
担当者の名前が入っている
「開発チーム」「インフラ担当」ではなく、必ず個人名を割り当てる。RACI で Accountable は 1 人。匿名のタスクは誰も実行責任を負わないため、計画上は存在しても現実には動かない。
03
完了条件が定義されている
各タスクに Definition of Done（何が揃ったら「完了」とみなすか）が書かれていること。「設計書ができた」ではなく「レビュー承認＆チェックリスト合格」のように、客観的に判定可能な状態を定義する。
04
1〜2 週間で完了する粒度
1 つのタスクが 5〜10 営業日に収まる粒度まで分解されている。これより大きいタスクは進捗が「8 割完了」状態で止まりがちで、実態の遅延が見えなくなる。アジャイルのストーリーポイントとも親和する考え方。
05
依存関係とクリティカルパスが明示
タスク間の先行・後続関係が引かれており、クリティカルパスが特定されている。クリティカルパスを知らない PM は、どの遅延が本当に致命的かを見分けられず、すべてに同じ温度で対応してしまう。
06
リスクと前提条件が書かれている
計画の根拠となる前提条件（人員確保、外部仕様の確定時期、ライセンス取得など）と、それが崩れた場合のリスクが計画書に明文化されている。前提が暗黙のまま走るプロジェクトは、必ずどこかで前提崩壊事故を起こす。
動かない計画書のパターン
- ガントチャートはあるが、WBS・成果物との対応がない
- タスクの担当が「○○チーム」止まりで個人名がない
- 「完了」の定義が曖昧で「8 割完了」が連発する
- 1 タスクが 2〜3 ヶ月にわたる超大粒度
- 依存関係が引かれておらず全タスクが並列に見える
- 前提条件・リスクの記載がない（暗黙の前提だらけ）
- ベースラインがなく、変更がいつの間にか反映されている
- 計画書を作った人と実行する人が違い、引き継がれていない
実行可能な計画のパターン
- 成果物指向 WBS から逆算されたタスクリスト
- すべてのタスクに個人名と工数が割り当てられている
- Definition of Done で完了判定が客観化されている
- 1 タスク 1〜2 週間粒度で「進捗バイナリ」化できる
- 依存関係とクリティカルパスが可視化されている
- 前提条件・リスク・対応策がログとして更新されている
- 正式なベースラインがあり、変更管理プロセスで更新
- 計画作成段階から実行者本人がレビュー・合意している
キックオフ前 / マイルストーン前のレビューチェックリスト（16 項目）
- 目的：プロジェクトの目的・成功基準が 1 文で言えるか
- スコープ：「やらないこと」が明文化されているか
- 成果物：成果物一覧と各受け入れ基準が定義されているか
- WBS：成果物指向で 1〜2 週間粒度まで分解されているか
- 担当：すべてのタスクに個人名が割り当てられているか
- RACI：Accountable が各タスクで 1 人に絞られているか
- 工数：見積り根拠（類推・三点・パラメトリック）が記録されているか
- 依存関係：先行・後続が引かれ、クリティカルパスが特定されているか
- マイルストーン：節目と Go/No-Go 判定基準が決まっているか
- 前提：暗黙の前提が文書化され、責任者が割り当てられているか
- リスク：上位 10 リスクに対し、回避／低減／転嫁／受容の方針があるか
- 変更管理：変更要求のフローと CCB が定義されているか
- コミュニケーション：誰に何をいつ報告するかが計画されているか
- 品質：レビュー／テスト／検査のプロセスが計画に組み込まれているか
- ベースライン：スコープ・スケジュール・コストが正式承認されているか
- 実行者の合意：実際に手を動かすメンバーが計画に Yes と言っているか