フレームワーク活用ガイドひとことで言うと#
プロジェクト計画の土台となる前提条件（Assumption）を一覧に明文化し、各前提の確度・影響度・検証予定を管理するツール。前提が崩れたときに「何が、どこに、どれだけ影響するか」を即座に評価できる状態を保つ。
押さえておきたい用語#
- 前提条件（Assumption）
- 計画時点では確定していないが「こうであろう」と仮定して進める事項。例：「外部APIの応答速度は500ms以下」「4月に新メンバーが2名入る」。
- 制約条件（Constraint）
- 前提条件と異なり、変更できない固定条件。予算上限や法令順守義務など。前提と制約は混同されやすいが性質が異なる。
- トリガーイベント
- 前提条件の有効性が変わる契機となる出来事を指す。「API仕様変更のアナウンス」「人事異動の内示」など。
- 影響度（Impact）
- 前提が崩れた場合にスコープ・スケジュール・コストに及ぶ影響の大きさ。高・中・低の3段階で評価する。
プロジェクト前提条件ログの全体像#
こんな悩みに効く#
- 「そもそもその前提、合ってたっけ？」とプロジェクト中盤で気づく
- 前提が崩れたときに影響範囲がわからず、対応が後手に回る
- 計画書に書かれていない暗黙の前提が人によって違う
基本の使い方#
プロジェクトの初期段階で、関係者全員が「これは確定ではないが、こうだと仮定して計画している」事項を書き出す。
- 技術前提: 既存システムのAPI仕様は変更なし、レスポンスタイム○ms以内
- 人的前提: 4月に○名増員、担当者の異動なし
- ビジネス前提: 予算追加なし、法規制の変更なし
- 外部前提: ベンダーの納期遵守、サードパーティサービスの継続
1つのPJで 10〜20件 が目安。「当たり前すぎて誰も言わない」ものほど危険なので、あえて明文化する。
洗い出した前提をログに記録し、以下の属性を付与する。
| 属性 | 説明 |
|---|---|
| 確度（高/中/低） | 前提が正しい可能性の見込み |
| 影響度（高/中/低） | 崩れた場合のQCDへの影響 |
| 検証日 | いつまでに確定させるか |
| オーナー | 誰がこの前提を検証するか |
| 対応策（プランB） | 崩れた場合の代替案 |
確度「低」かつ影響度「高」 の前提が最もリスクが高いため、早期検証の対象にする。
週次の進捗会議で前提条件ログの確認を 5分 組み込む。
- ステータスを更新（有効／要確認／崩れた）
- 新たに判明した前提を追加
- 「崩れた」前提は変更依頼（Change Request）プロセスに接続
- 検証日が近い前提をオーナーにリマインド
具体例#
状況: 決済機能を持つSaaSを開発中。前提条件「決済API v2の仕様は変更なし」を確度「高」で登録していたが、API提供元が突如 v3への移行を6か月後に義務化 すると発表。
前提条件ログが即座に機能
- ログ上のA-05「決済API v2仕様変更なし」のステータスを「崩れた」に変更
- 影響分析：スコープ（API連携部分の再実装 +15人日）、スケジュール（2週間延伸）、コスト（+120万円）
- プランBとして「v3移行を現PJに組み込む」を変更依頼として起票
ログに「崩れた場合の影響」が事前に記載されていたため、発覚から対応決定までわずか 2日。ログがなかった過去の類似ケースでは対応に 3週間 かかっていた。
状況: 商業施設の内装工事（工期6か月、予算1.5億円）。前提条件「現場監督Aが全期間専任」を確度「中」で登録していた。
週次レビューで検知
- 第3週のレビューでオーナー（人事部長）から「A氏に別現場への異動の打診がある」との情報
- ステータスを「要確認」に変更し、検証日を翌週に設定
- プランBとして「監督B（経験年数はAより浅い）を後任に充てる場合、品質管理のダブルチェック体制が必要」と明記
結果、A氏は異動が確定。しかし事前にプランBを策定していたため、後任Bへの引継ぎをスムーズに実施。品質問題ゼロで竣工し、工期遅延もなかった。前提条件ログがなければ「突然の異動」で 2〜3週間の混乱 が生じていた可能性が高い。
状況: シード期のスタートアップ。新プロダクトのMVP開発（予算800万円・3か月）を進行中。前提条件「シリーズAで5,000万円を6月までに調達」を確度「中」で登録。
調達遅延の兆候を早期検知
- 第4週のレビューで、VCとの交渉が想定より長引いていることを確認
- 確度を「中→低」に引き下げ、プランBを具体化
- プランB：MVP機能を 12機能 → 7機能 に絞り込み、残り5機能はシリーズA後に延期
調達は結局 3か月遅延 したが、MVPは7機能の縮小版で予定通りリリース。ユーザーからのフィードバックを元にシリーズA調達後の追加開発に反映し、最終的にはユーザー数 月3,000人 を達成。「前提条件ログのおかげで、資金ショートする前にスコープを調整できた」とCEOが振り返っている。
やりがちな失敗パターン#
- 前提条件を計画書に埋め込んだまま更新しない — 計画書の奥に書かれた前提は誰も見返さない。独立したログとして週次でレビューする仕組みが必要
- 「当たり前のこと」を記録しない — 「メンバーが辞めない」「予算が減らない」など自明に見える前提こそ崩れると影響が大きい。あえて明文化する
- プランB（代替案）を用意しない — 前提が崩れてから初めて対策を考えるのでは遅い。影響度「高」の前提には必ず代替案を併記する
- 前提と制約を混同する — 制約は変更不可、前提は変わりうるもの。混同すると「制約だから仕方ない」と思考停止したり、逆に「前提なので変更できる」と安易にスコープを広げたりする
まとめ#
プロジェクト前提条件ログは、計画の「見えない土台」を可視化するツールだ。キックオフで暗黙の前提を全員で言語化し、確度と影響度を評価し、週次でレビューし続ける。前提が崩れたときに慌てるのではなく、事前にプランBを準備しておくことで、変化への対応速度が格段に上がる。