要件定義時に「仮定して進める条件」を明確化し、関係者間の認識齟齬や後戻りを予防します。

• 目的: 要件定義書を作成するにあたり、計画や要件、仕様を定める上での「前提条件（仮に置く条件）」を明確化し、関係者間の認識齟齬や後戻りを防ぐ
• スコープ: 要件定義書に影響する前提（体制・業務運用・対象範囲・既存資産・外部連携・データ・環境・制約・移行・運用など）を対象とする。実装方式やアーキテクチャの確定は本ページの対象外
• 推奨する実施タイミング: 要件定義の立ち上げ直後〜要件確定前（合意形成の初期に明文化し、変更があれば履歴付きで更新する）
• 関連するステークホルダー: 業務部門（利用部門）、システムオーナー、PM、要件定義担当、運用担当、既存システム担当、外部連携先

• 前提知識:
  • 前提条件と制約条件の違い（前提: 仮に置く条件、制約: 守らなければならない制限）
  • 要件の種類（業務要件・機能要件・非機能要件）と前提条件が与える影響
  • 合意形成・変更管理（前提が崩れた場合の扱い）
• インプット（例）:
  • プロジェクト計画（体制、スケジュール、レビュー運営方針）
  • 現行システム資料（構成、DBスキーマ、外部連携、運用手順）
  • 業務ヒアリング結果（対象範囲、運用ルール、利用者像）
  • 既知の制約事項（法規・社内規程、利用可能な製品・基盤、セキュリティ要求）
  • 前提にしたい事項の“根拠候補”（契約、議事録、メール、既存実績など）

• 成果物: 要件定義書内の「前提条件」セクション、または独立した「前提条件一覧」（本ページの位置づけ）
• 必須要素（最低限）:
  • 前提条件の一覧（カテゴリ別）
  • 影響範囲（どの要件・仕様・計画に影響するか）
  • 根拠／根拠不明の場合はその旨（不確実性の明示）
  • オーナー（確認・維持する責任者）
  • 有効期限／見直しタイミング（いつまで前提として扱うか）
  • 前提が崩れた場合の対応方針（再見積、再スコープ、設計変更など）

✅ 品質チェックリスト:

👁️‍🗨️ レビュー観点:

• 抜け漏れ: 体制、利用者規模、既存資産、外部連携、データ、環境、運用、移行など主要カテゴリが網羅されているか
• 実現可能性: 前提条件が現実的か（関係者の稼働、現行資産の前提、期日など）
• リスク: 不確実な前提がリスクとして認識され、代替案や確認計画があるか
• 整合性: 前提条件が要件・計画・見積の前提と矛盾していないか

## 前提条件

計画や要件、仕様を定める上で、仮に置く条件（証拠や実証なしに確実であると仮定して進める条件）を記載する。

### 前提条件一覧（例）
- 業務部門が毎週の定例レビューに参加できる
- 想定利用者数は最大1,000人である
- 既存DBは現行スキーマのまま利用可能である

### 前提が崩れた場合
- 影響分析（要件・スコープ・方式・見積への影響）を実施し、関係者で再合意する

---

• 要件定義書（章立て・テンプレ）
• 議事録／合意事項一覧（前提の根拠として参照）
• リスク一覧（不確実な前提はリスク化して追跡）

テンプレートサイト: 📄テンプレート集