ユーザーストーリー一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)とドメイン要求仕様書群を上流とし、利用者視点での要求事項を Connextra 形式の単一フラット表(1 ストーリー 1 アクター・ID は通し連番)で一覧化する文書。
ドメイン別の章分割をせずスプレッドシート/Excel への移送を想定したフラット構造。下流のユースケース一覧・機能一覧(D2)・画面要件群(D2)・テスト計画の起点となる。PRD・ドメイン要求仕様書群の策定後、利用者視点での要求集約段階で呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
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 | 既存ユーザーストーリー一覧(更新・レビュー時のみ参照。新規作成時は未存在) |
| 成果物のパス | 内容 |
|---|---|
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)と業界一般知識から直接生成する。
<DOM>-BR-*)・業務運用イレギュラー対応(<DOM>-IRR-*)を起点に「誰が・何を・なぜ・どう完了と判定するか」の 4 要素に分解し、Connextra 形式のストーリーを導出するBR/IRR/DATA ID を 紐づく要求 ID 列に記載する(ドメイン要求は並列モデルのため DOM-COMMON-* を併記しない)区分=横断 のストーリーを別途導出し、紐づく要求 ID 列に DOM-COMMON-* を記載する区分=横断)を並べるUS-<連番> 形式の通し番号(例: US-1, US-2 …)。ドメイン情報は ID に含めず「ドメイン / 区分」列で表現する意向把握)または 横断営業職員: ACT-1)。アクター一覧の ID をそのまま使う(本書独自のユーザー ID を作らない)。1 ストーリー 1 アクター<br> + ・)。業務言語で記述。詳細な Given-When-Then は下流ユースケース・テスト計画に降ろすDOM-<コード>-BR-* / DOM-<コード>-IRR-* / DOM-<コード>-DATA-*、横断由来なら DOM-COMMON-*(複数あればカンマ区切り)紐づく要求 ID に DOM-<コード>-* のみ記載。区分はそのドメイン名区分=横断、共通要求由来でドメイン非帰属): 紐づく要求 ID に DOM-COMMON-* のみ記載[フェーズ2] ラベルを付ける(PRD・ドメイン要求仕様書の同種ラベルと表記を揃える)US-<連番> 形式の通し番号。ドメインや区分は ID に含めず「ドメイン / 区分」列に降ろす(CLAUDE.md §8 の「単一種類しか振らない成果物では <成果物略号>-<連番>」に準拠)### {{ドメイン名}} のような subsection を復活させない。区別は表の「ドメイン / 区分」列で表現するACT-* をそのまま使う(本書独自の USR-* 等を作らない)。アクター列の表記は アクター名: ACT-N のコロン区切り区分=横断 のストーリーは ドメイン共通要求仕様書由来かつ特定ドメインに帰属しないものに限る。特定ドメインに帰属するストーリーは当該ドメインの行として書き、横断側に流さない(共通要求の「3 ドメイン以上で共通」原則に揃える)[フェーズ2] ラベルを付ける。PRD・ドメイン要求仕様書の同種ラベルと表記を揃える執筆完了時に以下の観点で出力を検査し、不備があれば修正したうえで出力を完了とする。
### {{ドメイン名}} subsection を作っていないか(フラット表 1 枚に集約されているか)*-BR-*)・業務運用(*-IRR-*)から少なくとも 1 つ以上のストーリーが導出されているか区分=横断)が導出されているかDOM-<コード>-* のみ / B: 横断由来 DOM-COMMON-* のみ)のいずれかに該当し、両方を同時に参照していないか(並列モデル MECE 違反になっていないか)DOM-<コード>-*)が当該ドメイン要求仕様書に実在するか(参照切れがないか)DOM-COMMON-*)がドメイン共通要求仕様書に実在するか(参照切れがないか)アクター名: ACT-N 形式で、アクター一覧の ID と一致しているか(US 独自のユーザー ID が作られていないか)区分=横断 のストーリーが連続して並んでいるかUS-<連番> の通し番号で重複なく連続しているか(ドメイン情報を ID に含めていないか)[フェーズ2] ラベルが付与され、PRD・ドメイン要求仕様書の同種ラベルと表記が揃っているか<br> + ・ が使われ、スプレッドシート移送時に潰れにくい形式になっているか{{ や XXX のプレースホルダ、不要な要確認マーカーが残っていないか作成・更新時は以下の下流成果物との整合を意識する:
| 下流成果物 | ユーザーストーリー一覧から何を引く |
|---|---|
| ユースケース一覧 | 各ストーリーを起点に具体的な操作シナリオを展開。Acceptance Criteria を Given-When-Then 形式に詳細化 |
| 機能一覧(D2) | ストーリーの「やりたいこと」を実現するための機能を導出。横断由来ストーリー(紐づく要求 ID が DOM-COMMON-*)は横断機能として統合 |
| 画面要件群(D2) | ストーリーのアクター × やりたいこと × Acceptance Criteria を画面要件項目に展開 |
| テスト計画 | Acceptance Criteria を起点に業務観点テストケースを設計 |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。