PART 07 — リスクと前提条件
プロジェクト憲章 汎用フレームワーク

7-1. 前提条件の明示

このプロジェクトが成立するために必要な条件のリストを作成する。前提条件は「崩れたときにプロジェクト全体が揺らぐもの」を選ぶ。

前提条件例	崩れた場合の影響
外部APIが公開されていること	コア機能が実現不可能になる
一定の開発リソースが確保できること	スケジュールが根本から崩れる
第三者ライブラリのライセンスが商用利用可能なこと	法的リスクが発生する

7-2. リスクの洗い出し

発生しうる問題・その影響度・対策のセットで管理する。リスクは「ゼロにする」ではなく「事前に把握して備える」ことが目的。

リスク	影響度	対策
外部APIの仕様変更	高	手動入力フローを代替手段として維持
開発メンバーの離脱	中	ドキュメントを充実させ属人化を防ぐ
セキュリティインシデント	高	対応フロー・連絡先を事前に定義
外部サービスのコスト増	中	代替サービスを事前にリストアップしておく

リスクマトリクスの作り方

リスクは洗い出すだけでなく、優先度をつけて管理することが重要だ。発生確率と影響度の2軸でマトリクスを作り、優先的に対処すべきリスクを特定する。

影響度 ＼ 発生確率	高	中	低
高	最優先対処（リスク回避・転嫁）	対処計画が必要	モニタリング継続
中	対処計画が必要	モニタリング継続	受容可能
低	モニタリング継続	受容可能	受容可能

リスク対応策には4種類ある。「回避（リスクの原因を取り除く）」「軽減（影響を小さくする）」「転嫁（保険・外部委託等でリスクを他者に移す）」「受容（低リスクとして許容する）」の中から状況に応じて選択する。

憲章レビューチェックリスト

すべてに ✅ がつくまで、プロジェクトを開始しない。このリストは憲章の「完了の定義」でもある。

チェック項目	対応セクション
✅ 目的が一文で説明できる	PART 01 — 1-1
✅ 完了の定義（完成したと判断する基準）がある	PART 01 — 1-2
✅ KPIが数値で定義されている	PART 01 — 1-3
✅ 非ゴールが明示されている	PART 01 — 1-4
✅ インスコープ・アウトオブスコープが明確に分かれている	PART 02 — 2-1/2-2
✅ 将来候補（Phase N）として記録した要求がある	PART 02 — 2-3
✅ 認証方式と理由が記載されている（認証ありの場合）	PART 03 — 3-1
✅ パスワードハッシュ化・セッション管理方針がある（独自認証の場合）	PART 03 — 3-2/3-3
✅ データ保護・削除方針が記載されている（個人データを扱う場合）	PART 03 — 3-4/3-5
✅ 技術スタックとその選定理由がある	PART 04 — 4-1
✅ 各フェーズに完了基準がある	PART 06 — 6-1
✅ 前提条件とリスクが列挙されている	PART 07 — 7-1/7-2
✅ 関係者全員が内容をレビュー・承認している	全セクション

リスク・前提条件管理でよくある失敗パターン

リスク管理は「リストを作って終わり」になりがちだ。実際に機能させるには継続的な更新とオーナー設定が不可欠。

失敗パターン	何が起きるか	防止策
リスクをリストアップするだけで対応策を書かない	リスクが顕在化したとき「対応策がない」状態で緊急対応が始まり、影響が拡大する	各リスクに「発生確率・影響度・対応策・オーナー」をセットで定義する
前提条件に変化があっても更新しない	外部API仕様が変わったのに「変更なし」を前提にした設計が進み、詳細設計で発覚する	週次の進捗会議で前提条件の変化を確認するアジェンダを設け、変化があれば即更新する
リスクオーナーを設定しない	誰も監視していないリスクが静かに進行し、手遅れになってから発覚する	リストの各リスクに「誰が監視・対応するか」を明記し、定例会議でステータスを確認する