前提条件管理とは？アサンプションログの作り方と運用法を解説

前提条件管理（アサンプションログ）とは

前提条件管理は、プロジェクトの計画や意思決定の基礎となる「前提条件（Assumption）」を明示的に記録・監視・検証するプロセスです。その記録文書がアサンプションログ（Assumption Log）です。

PMBOKでは、前提条件を「証明や実証なしに真実・現実・確実と見なされる要因」と定義しています。例えば「必要な人員が予定通り確保できる」「外部APIの仕様変更はない」といったものが前提条件です。

前提条件が崩れるとプロジェクトリスクに直結します。アサンプションログは「プロジェクト憲章の作成」プロセスで初めて作成され、プロジェクト完了まで継続的に更新されます。リスク登録簿と連携して運用する文書です。

構成要素

アサンプションログは以下の記録項目で構成されます。

記録項目	説明
ID	前提条件を一意に識別する番号
前提条件の内容	何を前提としているかの記述
影響度	前提が崩れた場合のプロジェクトへの影響の大きさ
確信度	前提条件が成立する見込みの高さ
ステータス	監視中、確認済み、要対応、クローズなどの状態
対応アクション	前提が崩れた場合の備えや検証のための行動
担当者	検証・監視の責任者
記録日・更新日	登録日と最終更新日

実践的な使い方

ステップ1: 前提条件を洗い出す

プロジェクト開始時に、計画の基盤となっている前提条件を網羅的に洗い出します。スコープ、スケジュール、コスト、資源、技術、外部環境の各観点でチーム全員に「何を前提としているか」を問いかけます。制約条件（変更不可能な条件）との区別も重要です。

ステップ2: ログに記録し優先度を評価する

洗い出した前提条件をアサンプションログに記録します。各項目について「影響度」と「確信度」を評価し、影響度が高く確信度が低い前提条件を優先的に管理対象とします。

ステップ3: 定期的に検証・更新する

プロジェクトの進行に伴い、前提条件の妥当性を定期的に検証します。ステータス会議や週次レビューに組み込むのが効果的です。新たに発見された前提条件も随時追加します。

ステップ4: 崩れた前提をリスクとして管理する

前提条件が崩れた場合や崩れそうな兆候がある場合は、リスク登録簿に転記して正式なリスク対応プロセスに移行します。事前に準備した対応アクションを発動させます。

活用場面

• プロジェクト立ち上げ: プロジェクト憲章の作成時に初期の前提条件を整理する
• スコープ定義: 要件定義で暗黙に置かれている前提を明文化する
• ステークホルダー調整: 関係者間で前提条件の認識を揃え、齟齬を防ぐ
• リスク管理: 前提条件の分析からリスクを早期に特定する
• 変更管理: 前提条件の変化をトリガーとして変更要求を発行する

注意点

暗黙の前提を見逃さない

最もリスクが高いのは「誰もが当然だと思っている」暗黙の前提条件です。「この前提は本当に成立するか」と意識的に問いかけ、言語化されていない前提を掘り起こすことが重要です。

前提条件と制約条件を混同しない

前提条件は「成立すると仮定している事柄」であり、制約条件は「変更できない条件」です。例えば「予算は1億円以内」は制約条件、「追加予算の承認が得られる」は前提条件です。両者は管理方法が異なります。

形式的な運用に陥らない

ログを作成しても更新・検証しなければ意味がありません。定期レビューの仕組みと、前提が崩れた際の対応プロセスをあらかじめ設計しておくことが不可欠です。

まとめ

前提条件管理は、プロジェクトの計画基盤を明示的に記録・監視し、潜在リスクの早期発見を可能にする手法です。アサンプションログを通じて、暗黙の前提を見える化し、チーム全体でリスク認識を共有できます。リスク登録簿との連携運用が、プロジェクト成功の確率を高める鍵です。

参考資料

• PMBOKに出てくる前提条件ログとは何か？ - Promapedia（前提条件ログの定義と活用法の日本語解説）
• Project Assumptions: A Quick Guide with Examples - ProjectManager（プロジェクト前提条件の具体例と管理ガイド）
• Assumptions Log - Project Management Knowledge（アサンプションログの定義と記録項目の解説）