documentation-criteria

# ドキュメント作成基準 ## 作成判定マトリクス | 構造スケール | 基本ドキュメント | 作成順序 | |-------------|----------------|---------| | 小規模 | なし | 直接実装 | | 中規模 | Design Doc、作業計画書 | Design Doc -> 作業計画書 | | 大規模 | PRD、Design Doc、作業計画書 | PRD -> Design Doc -> 作業計画書 | フロントエンド/フルスタックの作業では、Design Doc の前に UI Spec を追加する。適格なADRバッチは Design Doc の前に完了させる。適格なADRが存在する場合、スケー��は最低でも中規模に引き上げられる。 大規模変更のPRD要件は、新規PRDの作成、関連PRDの更新、現行の製品文書がない場合のリバースPRD作成のいずれかで満たす。どのスケールでも、プロダクトスコープが変わる場合は既存PRDを更新する。 ## 構造スケール（Structural Scale） 分類するのはリポジトリ上のレイアウトではなく判断負荷である。ファイル数は補助的なエビデンスにとどまる。 | スケール | 判断負荷 | |---------|---------| | 小規模 | まとまった成果が1つで、1つの責務境界の中にリポジトリが支持する明白な実装が1つあり、未解決の持続的な選択がない | | 中規模 | まとまった成果が1つで、境界をまたいだ調整を伴うか、持続的になりうる選択を含む | | 大規模 | 独立して価値を持つ成果が複数あり、それぞれ別個の設計判断を要する | レイヤーをまたぐ実装であっても、まとまった成果1つに資する場合は中規模のままでよい。適格なADRが存在する場合、スケールは最低でも中規模に引き上げられる。 ## ADR判定フィルタ ADRを作成するのは、候補となる決定が両方のフィルタを通過する場合に限る: 1. **選択に判断を要する（Choice）**: 確認済み要件・受理済みADR・リポジトリのエビデンスを適用した後も、妥当かつ実質的に異なる選択肢が2つ以上残る。 2. **選択が持続的である（Durability）**: その選択が、後続の作業が維持しなければならない責務境界・依存・共有契約・永続化モデル・技術・可逆性・ライフサイ��ルコストのいずれかを変える。 決定ポイント1つにつきADRを1つ作成する。分離すると双方の決定が誤解を招く場合に限り、密結合した選択をまとめる。 しばしば適格となる例としては、外部依存の選定・置換、アーキテクチャ境界をまたぐ所有権の移動、永続化戦略の変更、共有契約の確立などがある。ローカルな実装詳細や容易に元へ戻せる選択は Design Doc に属する。ファイル数・ネストの深さ���状態数・パイプラインの長さは複雑性のエビデンスであって、ADRのトリガーではない。 ## 各ドキュメントの詳細定義 ### PRD（Product Requirements Document） **目的**: ビジネス要件とユーザー価値を定義 **含むもの**: - ビジネス要件とユーザー価値 - 成功指標とKPI（各指標に数値目標、測定方法、期間を明記） - ユーザーストーリーとユースケース - 受入条件（AC）に連番ID（AC-001, AC-002, ...）を付与し、下流でのトレーサビリティを確保 - MVPへの収束 — ...