要求〜詳細設計 深掘りスキル（日本語）

使うタイミング

• •要求定義、要件定義、基本設計、詳細設計をまとめて改善したいとき
• •仕様はあるが、曖昧さ・抜け漏れ・設計の弱さを減らしたいとき
• •反復するたびに「検証の厳しさ」を上げたいとき

ゴール

• •4成果物を整合させ、変更に強い設計セットにする
• •各反復でレビュー負荷を引き上げ、品質を頭打ちにしない

成果物（必須）

1. •要求定義（なぜ作るか、誰のどの課題を解くか）
2. •要件定義（何を満たせば完了か、受け入れ条件）
3. •基本設計（責務分割、境界、主要データ/処理フロー）
4. •詳細設計（実装可能な粒度の仕様、I/O、例外、テスト観点）

反復ワークフロー

1. •スコープ固定

• •対象機能、対象外、制約（納期/コスト/法規/性能）を明記する。

1. •現状測定

• •4成果物の不足を抽出する（曖昧語、未定義語、受け入れ不能な要件）。
• •rg で重複・矛盾・古い用語を検出する。

1. •SoT順で修正

• •要求定義 → 要件定義 → 基本設計 → 詳細設計の順に更新する。
• •上流を直してから下流を同期する（逆順禁止）。

1. •負荷を上げて再検証

• •下記「負荷レベル」に沿って同じ成果物を再レビューする。
• •レベルを1つ上げるたびに、前レベルの不備をゼロにして進む。

1. •結果を記録

• •修正箇所、検証結果、残課題、次レベル入口条件を残す。

負荷レベル（段階的）

L1: Correctness（基礎整合）

• •用語定義、主語、対象読者、前提条件が明確。
• •「要求→要件→設計」の参照リンクがつながる。

L2: Testability（検証可能性）

• •全要件に受け入れ条件がある。
• •詳細設計に正常系/異常系/境界値の観点がある。

L3: Operability（運用耐性）

• •障害時の挙動、ロールバック、監視項目が明記される。
• •非機能要件（性能、信頼性、セキュリティ、コスト）を数値化する。

L4: Stress（高負荷レビュー）

• •悪条件シナリオ（ピーク負荷、依存障害、データ不整合）を追加。
• •設計のボトルネックと劣化時挙動を明記する。

L5: Decision Pressure（意思決定圧）

• •トレードオフ表（採用/不採用/理由/代替案）を必須化する。
• •「やらないこと」を明文化し、スコープ膨張を抑制する。

重点チェック観点

• •Traceability: 要求ID → 要件ID → 設計要素 → テスト観点が追跡できるか
• •Non-duplication: 同じルールが複数文書でズレていないか
• •Verifiability: 実装前にレビューだけで合否判定できるか
• •Maintainability: 変更時にどこを直せばよいか明確か

実行コマンド例

# 設計語の重複・矛盾候補を抽出
rg -n "TODO|未定|要検討|TBD|暫定|後で" doc

# 要求/要件/設計の関連文書を一覧化
rg --files doc | rg "requirements|overview|architecture|design|adr|traceability"

出力フォーマット

• •今回の対象レベル（L1-L5）
• •変更方針（3行以内）
• •更新ファイルと更新理由
• •レベル判定（Before/After）
• •残課題と次レベル入口条件

ガードレール

• •大規模リライトより、追跡可能な最小差分を優先する。
• •不明点は断定せず、仮説と不足情報を分離して記載する。
• •4成果物のうち1つだけ更新して終わらない（必ず相互整合を取る）。