前提・制約・依存関係 作成レシピ

Assumptions, Constraints and Dependencies Writing Recipe

本書は、変化があったときに判断・対応できる前提・制約・依存関係を作るための手順である。本書では問い、具体化手順、レビュー観点を扱う。

1. このレシピの使い方

• 最初に、スコープから「成立しないと何が困るか」「守らなければならない境界」「他者または先行成果物に求める条件」を抜き出す。
• 次に、候補からスコープなど上位文書で確定済みの決定事項を除き、残った条件だけを前提、制約、依存関係のいずれか一つに分類し、影響と変化時の対応を対にして書く。除いた境界は該当章の冒頭で参照先を明示して委譲する。
• 最後に、未確定事項を断定せず、確認先または決定時期を TODO: / UNDECIDED: / ASSUMPTION: で明示する。
• 守る成果や境界（Why）、前提・制約・依存（What）、確認・監視・変化時対応（How）を整理し、項目 ID、based_on、根拠、影響、対応の同じ行で追跡する（Trace）。上位文書で確定済みの境界や詳細設計は再掲しない。

2. 作成前に集める情報

項目	集める情報
スコープと対象外	対象範囲、意図的に含めないもの、境界判断の原則
成立条件	人、情報、環境、先行成果物、意思決定など、欠けると進行できないもの
守るべき限界	公開範囲、責務境界、互換性、費用、期日、技術選択に関する制限
依存先	外部組織、サービス、先行成果物、承認、提供物、判断イベント
影響	変化した場合に影響するスコープ、期日、品質、運用、公開適性
確認と判断	状態を確認する方法、変化のトリガー、所有者、最終判断者

3. 全体の作成手順

1. 直接参照したスコープ・上位成果物を based_on に限定して記載する。
2. 候補のうち、スコープで確定済みの境界・対象外は登録せず、該当章の冒頭で参照先を明示して委譲する。
3. 成立条件を前提条件として書き、根拠、影響、確認方法、変化時の対応を補う。
4. 守るべき限界を制約事項として書き、適用範囲と逸脱条件を明確にする。
5. 他者・外部・先行成果物から受ける条件を依存関係として書き、成立条件を定める。意思決定待ちの依存は、プロジェクト登録簿へ登録して本書から項目 ID を参照する。
6. 変化の種別ごとに、最初に確認することと対応方針をまとめる。
7. 監視・変更管理に、見直す契機と変更記録に残す情報を置く。
8. 表の各行について、前提・制約・依存の分類、根拠、所有者、対応が欠けていないか確認する。

4. 各章の書き方

4.1. 前提条件

問い:

• 何が真または利用可能であることを前提にしているか。
• その前提が崩れると、誰の作業またはどの成果物に影響するか。
• どの記録・確認で変化を検知できるか。

書き方:

• 「〜できる」「〜である」という成立条件を一文にし、根拠と影響を分離する。
• 単なる希望や目標は前提にしない。確認できない場合は仮置きであることを明示する。
• スコープで定義済みの境界は前提として再掲せず、章冒頭でスコープの該当章へ委譲する。
• リポジトリ、作業環境、外部ツールなど、継続的な提供が必要な基盤は前提ではなく依存関係（4.3.）として書く。
• 例: 「店頭で使う端末を利用できる」を前提として、利用不可時の代替記録を対応に置く。

4.2. 制約事項

問い:

• 必ず守るべき限界は何か。
• どの成果物・利用場面・期間に適用するか。
• 何が起きたら逸脱として扱うか。

書き方:

• 「〜しない」「〜に限定する」のように、禁止または限界を判定可能に書く。
• 技術制約は製品名だけで固定せず、再利用性、公開適性、運用責任などの意図を添える。
• スコープの対象外・境界の判断基準と同内容の制約は再掲せず、上位文書に現れない運用上の制約だけを書く。
• 詳細な設計方法や受入条件は、対応する後続成果物に委譲する。

4.3. 依存関係

問い:

• 誰または何から、どの情報・提供物・判断を受ける必要があるか。
• 受け取れたと判断する条件と、変化を知る契機は何か。
• 依存先が変わった場合に、どの文書または判断を見直すか。

書き方:

• 依存先を「外部サービス」だけに限定せず、先行成果物や承認も記載する。
• 依存先名だけで終わらせず、必要な理由と成立条件を添える。
• 意思決定待ちの依存はプロジェクト登録簿へ登録し、本書からは登録項目 ID を参照する。
• 期限や責任者が未確定なら、推測で埋めず決定先を残す。

4.4. 影響評価と対応方針

問い:

• 前提・制約・依存が変化した場合、どれ（スコープ、期日、品質、公開適性、運用責任）に影響するか。
• 最初に確認すべき範囲とその根拠は何か。
• 一次対応を担うロールと、最終判断者は誰か。

書き方:

• 影響は「困る」「遅れる」ではなく、スコープ、期日、費用、品質、公開適性など該当する領域名で記載する。
• 対応方針には「除去、軽減、受容、再判断」のいずれを行うかを示し、次に判断する人を記載する。
• 最終判断者を未確認のロールで補わない。未確定なら TODO: として記録先を示す。

4.5. 監視・変更管理

問い:

• 本書をいつ、どのような契機で見直すか。
• 変更時に残すべき情報（項目 ID、変化内容、影響範囲、判断者など）は何か。
• どの役割が構造整合を確認し、どの部分を人間の責任者が最終判断するか。

書き方:

• 「定期的に確認する」ではなく、「スコープまたは実践の型一式が変わったとき」「新たな機密情報検出時」などの具体的な契機を記載する。
• 変更記録には項目 ID、変化内容、影響範囲、判断者、対応状況を残す。記録先が未定なら TODO: とする。
• 文書構造の整合確認は ARC 、公開可否やスコープ変更などの最終判断は人間の責任者が行うと明示する。

5. 深掘り手順

1. スコープ外を読み、境界を越えたときの制約候補を抽出する。
2. 対象を成立させるために必要な人、情報、環境、先行成果物を列挙する。
3. 各候補に「変化したら何が止まるか」を問い、影響がないもの、またはスコープで確定済みのものは登録しない。
4. 変化を最初に知る方法と、一次対応を担う所有者を決める。
5. 未確認の事実は、確認先とともに未確定として残す。

6. 良い例 / 悪い例

観点	良い例	悪い例
重複排除	スコープ外で確定済みの境界は、章冒頭の参照で委譲する	スコープの対象外を言い換えて前提・制約として再掲する
運用化	憲章などが結論だけを示す制約に、監視方法・トリガー・所有者を添えて展開し、展開元を明記する	憲章などがすでに継続監視・記録先を持つ判断ゲートを、要約して重複登録する
分類	「単一店舗で運用する」を前提として記載する	「単一店舗で進める」を種別なしで書く
分類	「作業環境の継続利用」を依存関係として記載する	「作業環境を継続利用できる」を前提条件として書く
制約	「個人情報を公開資料に含めない」と逸脱時の対応を併記する	「情報管理に注意する」とだけ書く
依存	「先行するスコープ文書」と、その成立条件を記載する	「他の資料を参照する」とだけ書く
トリガー	「対象外の機能を初期対象へ追加しようとした」と書く	「必要に応じて確認する」と書く
未確定	「TODO: 公開判断の記録先を決定する」と書く	未確認の責任者や期限を断定する

7. レビュー観点

観点	確認内容
重複排除	スコープなど上位文書の決定事項を再掲せず、参照で委譲しているか。上位文書がすでに継続監視・記録先を持つ事項を重複登録していないか。
分類	各行が前提、制約、依存のいずれか一つに分類されているか。リポジトリ・作業環境など継続提供が必要な基盤を前提条件に含めていないか。
根拠	内容がスコープまたは直接参照した成果物と矛盾しないか。
変化への備え	影響、確認方法、トリガー、所有者、対応方針があるか。
技術制約	特定製品への過度な依存、実装詳細、責務外の設計が混入していないか。
下流入力	業務、受入、計画・統制の担当者が、必要な条件と未確定事項を識別できるか。
公開適性	個人情報、機密情報、非公開情報を含めていないか。

8. 仕上げチェック

• 「全体の作成手順」で示した章立てと必須表がそろっている。
• スコープなど上位文書の決定事項を再掲せず、委譲する場合は章冒頭に参照がある。
• 各項目に影響と変化時の対応が対で記載されている。
• 前提、制約、依存の各章があり、種別を混在させていない。
• 未確定事項を推測で埋めず、確認先または決定時期を明示している。
• 技術設計、実装詳細、最終判断の代替を書き込んでいない。
• 各項目について、守る成果または境界、成立条件、影響、確認・対応方法を同じ ID から追跡できる。