Home
要件定義を計画する
実践ガイド
文書情報
プロジェクト概要
🚧 レビュー・承認(※追記予定）
業務要件
機能要件
非機能要件
🚧 インプット(※追記予定)
🚧トレーサビリティ(※追記予定)
🚧 SoR 向け(※追記予定）
🚧 SoE 向け(※追記予定）
制約条件一覧
リード文
🎯 概要
- 目的: 設計・実装・開発プロセスの選択肢を制限する「制約条件」を漏れなく可視化し、対応方針の合意とトレーサビリティを確保する
- スコープ: 法規制、契約・顧客指定、既存システム/基盤の制約、社内標準・運用/セキュリティ方針、組織/体制、予算・スケジュールなど
- 対象外: チーム内の好みや方針（例: 「慣れているからSpringが良い」）、設計判断（アーキテクチャ選定理由など）そのものは「制約」ではなく別管理
- 推奨する実施タイミング: 要件定義の早期（見積・提案段階〜要件定義の初期）に洗い出し、以降は変更管理として継続更新する
- 関連するステークホルダー: プロジェクトマネージャー、顧客担当者、システムアーキテクト、セキュリティ/法務、運用部門、基盤/ネットワーク担当
📥 重要な前提知識・インプット
- 前提知識:
- 制約と要件（特に非機能要件）・設計判断・リスクの違い
- 変更管理（誰が、いつ、何を根拠に変更できるか）の考え方
- インプット（例）:
- 契約条件・RFP・顧客の指定事項（クラウド可否、利用製品、データ保管場所など）
- 適用される法規制・業界ガイドライン（個人情報、監査、医療/金融など）
- 既存システム/周辺システムの仕様と制約（改修可否、インターフェース、保守期限）
- 社内標準・セキュリティ/運用ポリシー（利用可能な技術、脆弱性対応、監視要件など）
- 予算・スケジュール・体制（必達日、要員計画、外部委託条件など）
- インフラ/ネットワーク制約（閉域網、プロキシ、利用可能なリージョン等）
📄 成果物の定義
- ドキュメントテンプレート: テンプレリンク
- 必須要素:
- 制約一覧（ID、種別、内容、根拠/出典、適用範囲、変更可否・変更手続き、影響、対応方針、承認者/合意状況、備考）
- 制約間の依存関係（他の制約・要件・設計判断・リスクへのリンク）
- 変更履歴（追加/変更/解除、理由、日時、変更者）
✅ 品質基準・レビュー観点
✅ 品質チェックリスト:
| チェック項目 | チェック内容 |
|---|---|
| 制約の定義適合 | 「外部からの強制」「変更困難」「クリア必須」のいずれかが曖昧な項目が混在していない |
| 根拠の明確性 | 法規制条文、契約条項、顧客指定、社内標準などの出典が追跡できる |
| 網羅性 | 法規制・契約・既存資産・社内標準・体制・予算/日程など主要カテゴリが一通り確認されている |
| 影響分析 | 制約が機能/非機能/運用/コスト/スケジュールに与える影響が記載されている |
| 対応方針の妥当性 | 回避・緩和・受容・交渉の方針が整理され、必要な合意/承認者が明確である |
👁️🗨️レビュー観点:
- 要件との整合性: 制約により満たせない要件がある場合、要件変更や代替案が合意されているか
- 実現可能性: 制約下で実装・運用が成立するか（体制、技術、期間、予算）
- トレーサビリティ: 各制約が根拠に紐づき、設計判断・リスク・課題とリンクできるか
- 更新容易性: 変更手続きと責任者が決まり、最新版が参照される運用になっているか
🧪成果物のサンプル
## 4. 制約条件
プロジェクト実施上の制約事項を記載する。
**記述例:**
| 制約ID | 制約種別 | 制約内容 | 出典/根拠 | 備考 |
| --- | --- | --- | --- | --- |
| CST-001 | 法規制 | 個人情報保護法に基づき、顧客情報は国内データセンタに保存すること | 法規制 | クラウド利用時も適用 |
| CST-002 | 技術的制約 | 会計システムは既存パッケージを利用するため改修不可 | 現行システム仕様書 | 業務一覧 BUS-003（請求処理）は非対象 |
| CST-003 | 技術的制約 | DBは社内標準のPostgreSQLを利用すること | 社内技術標準 | バージョンは最新LTS |
| CST-004 | 組織的制約 | 運用はシステム部が一元管理し、部門ごとの運用分担は不可 | 運用方針 | SLA関連文書と整合 |
| CST-005 | 予算 | 保守費用は、年間600万円以内 | プロジェクト計画書 | 相応の理由があれば増額可能 |
| CST-006 | スケジュール | 本番稼働日は2026年11月1日を厳守 | プロジェクト計画書 | 必要ならスコープの縮小を議論する |
---🔄 設計の進め方・プロセス
🧭 プロセス1: 制約の洗い出し（収集）
実施内容:
制約の候補を、資料と関係者ヒアリングから網羅的に収集する。
収集元（例）:
- 契約・RFP・顧客指定
- 法規制・監査要件
- 既存資産/周辺システム仕様
- 社内標準・セキュリティ/運用方針
- 予算・スケジュール・体制
ポイント: 「要件」や「設計判断」と混同しないよう、出典を必ずメモする。
🧩 プロセス2: 分類・定義の確定（制約として成立するかの判定）
実施内容:
各項目が制約の定義に該当するかを判定し、種別と適用範囲を確定する。
判定観点:
- 外部強制（出典があるか）
- 変更困難（交渉余地・変更手続きが必要か）
- クリア必須（満たさない場合の不適合が明確か）
出力例: 種別、適用範囲（全体/特定サブシステム/環境）、変更可否/手続き。
🧠 プロセス3: 影響分析と対応方針の決定
実施内容:
制約がもたらす影響を整理し、対応方針（回避/緩和/受容/交渉）と設計・プロセス上のルールを決める。
具体例:
- 国内保管必須 → 利用リージョン固定、バックアップ先の制約
- 改修不可パッケージ → 連携方式の限定、追加要件の扱い（要件変更/運用回避）
- 必達日 → スコープ調整基準、段階リリース方針
ポイント: 制約によって満たせない要件が出る場合、要件側の合意（変更/優先度調整）までセットで管理する。
✅ プロセス4: 合意・承認（根拠とセットで確定）
実施内容:
制約の内容・根拠・対応方針について、承認者を明確にして合意を取得する。
ポイント:
- 「誰がOKと言ったか」を残す（顧客/法務/セキュリティ/運用など）
- 承認が必要な制約は、承認日と承認者を必須で記録する
🔁 プロセス5: 変更管理（追加・変更・解除）
実施内容:
制約の変更要求が出た場合の手続きを定義し、変更履歴と影響を更新する。
ポイント:
- 変更理由、影響範囲、代替案、承認者を必ず残す
- 制約の変更がリスク・課題・設計に波及する場合はリンクして追跡する
🚨 よくある失敗と予防策
🚧 実例収集後、追記予定
📚 参考資料・関連リンク
- 参考（典拠になりうるもの）:
- 適用される法規制、業界ガイドライン、監査基準
- 契約書、RFP、SLA、顧客セキュリティ基準
- 社内標準（技術標準、セキュリティ標準、運用標準）
- 既存システム仕様書、運用設計書、ネットワーク設計書
- 関連する他のガイド（例）:
- 非機能要件定義、セキュリティ要件、運用設計
- リスク管理、課題管理、変更管理
- ツール・テンプレート:
- 制約一覧テンプレ（表形式）、根拠リンクの管理方法（Notionのページリンク等）
テンプレートサイト: 📄
テンプレート集