D1: ユーザーストーリー一覧

inputする成果物

成果物のパス	内容
docs/D1.business-requirements/product-requirement-document.md	上流の PRD(ドメイン共通要求 / 直接利用アクターの抽出元 / ドメイン並びの起点)
docs/D1.business-requirements/domain-requirements/*.md	上流のドメイン要求仕様書群(各ドメインの業務ルール <DOM>-BR-* / 業務運用 <DOM>-IRR-* から導出)
docs/D1.business-requirements/actor-list.md	アクター一覧(ACT-* ID の参照元)
docs/D1.business-requirements/business-requirement-document.md	BRD(スコープ・KPI・フェーズ2 境界の根拠)
docs/D1.business-requirements/user-story-list.md	既存ユーザーストーリー一覧(更新・レビュー時のみ参照。新規作成時は未存在)

outputする成果物

成果物のパス	内容
docs/D1.business-requirements/user-story-list.md	ユーザーストーリー一覧本体(単一のフラット表)

使用するテンプレート

出力時は以下のテンプレートを読み込み、その列構成・書き方ヒントに従う。

テンプレートのパス	内容
.claude/skills/d1-user-story-list/template.md	ユーザーストーリー一覧テンプレート(列構成・書き方ヒント)

章構成

本書は 「本書について」「想定読者」「注記」「受け入れ基準」 等の編集メタ章を持たない。タイトル(# ユーザーストーリー一覧)直下に単一のフラット表のみが置かれる構成。前提・位置づけ・編集チェック観点は本スキル(および テンプレ冒頭の HTML コメントブロック)に集約し、成果物本体には残さない。スプレッドシート/Excel への移送を想定し、ドメイン別の章分割は行わない。

# ユーザーストーリー一覧

| ID | ドメイン / 区分 | アクター(As a) | やりたいこと(I want) | なぜなら(So that) | Acceptance Criteria | 紐づく要求 ID |
|---|---|---|---|---|---|---|
| US-1   | 意向把握 | 営業職員: ACT-1   | ... | ... | ... | DOM-HEAR-BR-1 |
| US-2   | 申込受付 | 代理店募集人: ACT-2 | ... | ... | ... | DOM-APPL-BR-3 |
| US-3   | 横断     | 申込人: ACT-5     | ... | ... | ... | DOM-COMMON-SEC-1 |

並列モデル下での参照列の単一化: ドメイン共通要求(DOM-COMMON-*)とドメイン要求(DOM-<コード>-*)は 並列・参照関係なし の関係であり、各ストーリーは原則どちらか片方のみを参照する。そのため参照列は1列(紐づく要求 ID)に集約する。「区分=横断」のストーリーは共通要求 ID を、ドメイン区分のストーリーはドメイン要求 ID を記載する(ID 接頭辞からどちらの要求か判別可能)。

新規作成時の振る舞い

新規作成時(docs/D1.business-requirements/user-story-list.md 未存在)は ユーザーへのヒアリングを行わず、上流(PRD・ドメイン要求仕様書群・アクター一覧・BRD)と業界一般知識から直接生成する。

1. 上流成果物を読み込み、ドメイン定義書 §一覧のドメイン並びを取得する(本書の行並び順がこれに従う)
2. 各ドメイン要求仕様書について、業務ルール(<DOM>-BR-*)・業務運用イレギュラー対応(<DOM>-IRR-*)を起点に「誰が・何を・なぜ・どう完了と判定するか」の 4 要素に分解し、Connextra 形式のストーリーを導出する
3. ドメイン由来のストーリーは、当該ドメイン要求の BR/IRR/DATA ID を 紐づく要求 ID 列に記載する(ドメイン要求は並列モデルのため DOM-COMMON-* を併記しない)
4. ドメイン共通要求仕様書配下の各要求のうち、特定ドメインに帰属しない真の横断要求(認証・ログイン体験・横断通知・監査体験 等)について 区分=横断 のストーリーを別途導出し、紐づく要求 ID 列に DOM-COMMON-* を記載する
5. 並び順: ドメイン定義書 §一覧のドメイン並びを踏襲し、各ドメインのストーリーを連続させた後、最後に横断ストーリー(区分=横断)を並べる
6. 1 ストーリー = 1 アクター: 業務上のニーズが実質同一に見えても、複数アクターを 1 行に混在させない。アクターごとに独立した行として導出する(別アクターは別ストーリー)
7. 各列の埋め方:
   • ID: US-<連番> 形式の通し番号(例: US-1, US-2 …)。ドメイン情報は ID に含めず「ドメイン / 区分」列で表現する
   • ドメイン / 区分: ドメイン名(例: 意向把握)または 横断
   • アクター(As a): アクター名と ID をコロン区切り(例: 営業職員: ACT-1)。アクター一覧の ID をそのまま使う(本書独自のユーザー ID を作らない)。1 ストーリー 1 アクター
   • やりたいこと(I want): 業務上やりたいこと。機能名・画面名・テーブル名・API 名等の How は混入させない
   • なぜなら(So that): 業務上の価値・根拠
   • Acceptance Criteria: 当該ストーリーが完了と言える条件を 1〜3 項目の短い箇条書き(セル内改行は <br> + ・)。業務言語で記述。詳細な Given-When-Then は下流ユースケース・テスト計画に降ろす
   • 紐づく要求 ID: 当該ストーリーが派生した要求 ID。ドメイン由来なら DOM-<コード>-BR-* / DOM-<コード>-IRR-* / DOM-<コード>-DATA-*、横断由来なら DOM-COMMON-*(複数あればカンマ区切り)
8. 上流参照は並列モデルにより以下 2 パターンのいずれかに必ず該当する:
   • パターンA(ドメイン業務由来): 紐づく要求 ID に DOM-<コード>-* のみ記載。区分はそのドメイン名
   • パターンB(区分=横断、共通要求由来でドメイン非帰属): 紐づく要求 ID に DOM-COMMON-* のみ記載
   • 両方を同時に参照することはない(共通要求とドメイン要求が同じ要求実体を語らない=並列モデルの厳密な MECE)。例外的に両者が同居する場合は、ストーリーの主題が曖昧になっていないかを再点検する
9. 上流から確定できない値には要確認マーカーを付ける(例: アクターの曖昧性・業務ルールの主体不明・AC の業務観点が確定できない 等)
10. 将来段階導入のストーリーには [フェーズ2] ラベルを付ける(PRD・ドメイン要求仕様書の同種ラベルと表記を揃える)
11. ID は US-<連番> 形式の通し番号。ドメインや区分は ID に含めず「ドメイン / 区分」列に降ろす(CLAUDE.md §8 の「単一種類しか振らない成果物では <成果物略号>-<連番>」に準拠)

留意事項

• 本書はフラット表のみ: 「本書について」「想定読者」「注記」「受け入れ基準」 等の編集メタ章を持たない。タイトル直下に単一の表のみを置く。前提・編集チェック観点は本スキル(および テンプレ冒頭 HTML コメント)に集約する
• ドメイン別の章分割をしない: スプレッドシート/Excel 移送を想定したフラット構造を厳守する。### {{ドメイン名}} のような subsection を復活させない。区別は表の「ドメイン / 区分」列で表現する
• 業務言語に留まる: やりたいこと・Acceptance Criteria のいずれも業務言語で書く。機能名・画面名・テーブル名・API 名等の How(D2 以降)は混入させない。「業務」の観点に立ち、システム実装が想起される語に「業務」を冠する(例: 状態→業務状態、例外→業務運用イレギュラー対応)
• AC は短い箇条書きサマリ: 1〜3 項目の短い箇条書きで業務観点の完了条件を示す。詳細な Given-When-Then はユースケース一覧・テスト計画に降ろす。多行 GWT を 1 セルに詰めない(Excel 移送が崩れる)
• アクター ID は二重採番しない: アクター一覧の ACT-* をそのまま使う(本書独自の USR-* 等を作らない)。アクター列の表記は アクター名: ACT-N のコロン区切り
• ドメイン共通要求とドメイン要求は並列・参照関係なし: 上流参照は 2 パターン(A: ドメイン由来 / B: 横断由来)のいずれかに必ず該当する。両方を同時に参照することはない(同じ要求実体を両側で語らない=並列モデルの厳密な MECE)
• 横断ストーリーの規律: 区分=横断 のストーリーは ドメイン共通要求仕様書由来かつ特定ドメインに帰属しないものに限る。特定ドメインに帰属するストーリーは当該ドメインの行として書き、横断側に流さない(共通要求の「3 ドメイン以上で共通」原則に揃える)
• 網羅性はスキル側で担保: 「全業務ルールから 1 つ以上派生しているか」「全直接利用アクターに 1 つ以上割り当たっているか」等の網羅性チェックは本スキル「完成時のセルフチェック」で担保し、成果物本体に編集チェック章を設けない
• フェーズ2 ラベル: 初期フェーズ対象外のストーリーには [フェーズ2] ラベルを付ける。PRD・ドメイン要求仕様書の同種ラベルと表記を揃える
• 上流との整合性: ドメイン定義書 §一覧のドメイン並び・横断要求と、各ドメイン要求仕様書の業務ルール・業務運用 と矛盾させない。「紐づく」列の ID が上流で実在することを必ず確認する

完成時のセルフチェック

執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。

• 「本書について」「想定読者」「注記」「受け入れ基準」 等の編集メタ章を復活させていないか(タイトル直下が単一表のみになっているか)
• ドメイン別の ### {{ドメイン名}} subsection を作っていないか(フラット表 1 枚に集約されているか)
• 全ドメイン要求仕様書の主要業務ルール(*-BR-*)・業務運用(*-IRR-*)から少なくとも 1 つ以上のストーリーが導出されているか
• すべての直接利用アクター(PRD §「体験設計 > システム利用ユーザー」配下)に少なくとも 1 つのストーリーが割り当てられているか
• ドメイン共通要求仕様書配下の主要要求から少なくとも 1 つ以上のストーリー(ドメイン由来 or 区分=横断)が導出されているか
• 各ストーリーが Connextra 形式の 3 要素(As a / I want / So that)を満たし、業務言語で書かれているか
• 各ストーリーに業務観点の AC が 1〜3 項目の短い箇条書きで付与され、画面名・機能名・API 名等の How が混入していないか
• 上流参照が 2 パターン(A: ドメイン由来 DOM-<コード>-* のみ / B: 横断由来 DOM-COMMON-* のみ)のいずれかに該当し、両方を同時に参照していないか(並列モデル MECE 違反になっていないか)
• 「紐づく要求 ID」列のドメイン要求 ID(DOM-<コード>-*)が当該ドメイン要求仕様書に実在するか(参照切れがないか)
• 「紐づく要求 ID」列の共通要求 ID(DOM-COMMON-*)がドメイン共通要求仕様書に実在するか(参照切れがないか)
• アクター列が アクター名: ACT-N 形式で、アクター一覧の ID と一致しているか(US 独自のユーザー ID が作られていないか)
• 機能名・画面名・テーブル名・API 名等の How(D2 以降)が「やりたいこと」「なぜなら」「Acceptance Criteria」 のいずれにも混入していないか
• 並び順が ドメイン定義書 §一覧のドメイン並びを踏襲し、最後に 区分=横断 のストーリーが連続して並んでいるか
• ID が US-<連番> の通し番号で重複なく連続しているか(ドメイン情報を ID に含めていないか)
• 1 ストーリー 1 アクターが守られているか(アクター列に複数 ACT-ID が混在していないか)
• 将来要件に [フェーズ2] ラベルが付与され、PRD・ドメイン要求仕様書の同種ラベルと表記が揃っているか
• セル内改行に <br> + ・ が使われ、スプレッドシート移送時に潰れにくい形式になっているか
• {{ や XXX のプレースホルダ、不要な要確認マーカーが残っていないか

下流への伝搬関係

作成・更新時は以下の下流成果物との整合を意識する:

下流成果物	ユーザーストーリー一覧から何を引く
ユースケース一覧	各ストーリーを起点に具体的な操作シナリオを展開。Acceptance Criteria を Given-When-Then 形式に詳細化
機能一覧(D2)	ストーリーの「やりたいこと」を実現するための機能を導出。横断由来ストーリー(紐づく要求 ID が DOM-COMMON-*)は横断機能として統合
画面要件群(D2)	ストーリーのアクター × やりたいこと × Acceptance Criteria を画面要件項目に展開
テスト計画	Acceptance Criteria を起点に業務観点テストケースを設計