アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
d9-test-data-tool
D9 テストデータ作成ツールの新規作成・更新を行う。テストデータ要件定義書の作成後、開発者にテストデータ作成を依頼する段階で呼び出す。
実行スコア 未検証
インストール方法を見る含まれるファイル(2)
- SKILL.md8.1 KB
- template.md1.1 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
D9: テストデータ作成ツール
遵守すべき重要ルール
- 列は ER図の属性名で記載する: テストデータテンプレートの列は、ER図の属性名にする。ER図が無ければ概念データモデルの名前にする。テーブル名・カラム名は記載しない。
- 仕様と画面と初期投入データから決まる値は記載する: 一意に決まる値は記載する。決まらない値は、決め方を記載する。
- 要件定義書の範囲の外に出ない: 要件定義書に無い要件から表を作らない。
- 上流の成果物を直さない: 上流の漏れや誤りに気づいたら、直さずにユーザーへ伝える。
- ID を振り直さない: 採番済みの
TDT-*は変えず、欠番も再利用しない。
インプットする成果物
| 成果物のパス | 内容 |
|---|---|
docs/D9.test-design/test-data-requirements.md | テストデータ要件定義書。エンティティ、必要な状態、件数、属性(値)の条件、依存、関連テスト観点を、テストデータ作成要否の表と条件の表に利用 |
docs/D3.system-design/er-diagram.md | ER図。テストデータテンプレートの列名に利用 |
docs/D2.system-requirements/conceptual-data-model.md | 概念データモデル。ER図が無いときだけ、テストデータテンプレートの列名に利用 |
docs/D3.system-design/screen-designs/*.md | 画面設計書。画面の表示内容を、テストデータテンプレートに利用 |
docs/D2.system-requirements/wireframes/*.html | ワイヤーフレーム。画面設計書が無いとき、画面の表示内容を、テストデータテンプレートに利用 |
db/dml/seed/ | 初期投入データ。起動時に入る識別子を、テストデータテンプレートに利用。無いときは、識別子は空欄にする |
アウトプットする成果物
| 成果物のパス | 内容 |
|---|---|
docs/D9.test-design/test-data-tool.md | テストデータ作成ツール |
アウトプットに使用するテンプレート
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d9-test-data-tool/template.md | テストデータ作成ツールのテンプレート |
処理
1. 分岐する
- もし
docs/D9.test-design/test-data-requirements.mdが無いなら、テストデータ要件定義書が先である旨を伝えて終了する。 - もし
docs/D9.test-design/test-data-tool.mdが無いなら、§2(新規作成)に進む。 - それ以外なら、§3(更新)に進む。
2. 新規作成
2.1 テストデータ作成要否の表を記載する
要件定義書の TDR-* を上から、1行ずつテストデータ作成要否の表に記載する。関連要件IDとエンティティは要件から引く。
- 必要: 手順を始める前に、テストデータを用意しておく必要がある。
- 不要: 手順を始める前に、テストデータを用意しなくてよい。用意する行が無いとき、手順の中でできるとき、起動時に既にあるとき。
- 作成方法: 必要な行は「手動」か「スクリプト」、不要な行は「—」とする。画面の操作だけで手順を始める前の状態にできるときは「手動」。画面の操作だけでは用意しにくいとき、データ数が多いときは「スクリプト」。
2.2 テストデータテンプレートを記載する
2.1 で作成方法をスクリプトとした要件を上から進め、要件ごとに1つの見出しと、条件の表と、テストデータテンプレートを記載する。不要な要件と、作成方法が手動の要件は、テストデータテンプレートを記載しない。エンティティ名は要件から引き、ER図の名前と食い違うなら直さずにユーザーへ伝える。ER図が無ければ概念データモデルの名前を見る。条件の表の依存のエンティティが、テストデータ作成要否の表に無いときは、直さずにユーザーへ伝える。
- 条件の表: 関連要件ID、必要な状態、件数、属性(値)の条件、依存、関連テスト観点を、要件から引く。
- テストデータテンプレートの列: ER図でそのエンティティが持つ属性を、図の並びで列にする。ER図が無ければ概念データモデルの属性を使う。
- テストデータテンプレートの行: 必要な状態に業務状態の名前があるときは、その名前を業務状態の列に記載し、1状態1行にする。必要な状態に業務状態の名前が無いときは、件数を満たす行を記載する。
- 値: 画面設計書の表示内容を記載する。画面設計書が無いときは、ワイヤーフレームの表示内容を使う。属性(値)の条件が求めている内容は、画面の表示から記載する。複数の値は「/」でつなぐ。初期投入データから決まる識別子は引く。初期投入データが無いときは、識別子の列は空欄にする。その場で採番する値は「{自動採番}」を記載する。日時の列は、決め方を「{}」で記載する。
2.3 仕上げる
TDT-* をテストデータ作成要否の表の上から通し連番で振る。作成方法がスクリプトの行は、テストデータテンプレートの見出しにも同じ ID を記載する。そのあと「完成時のセルフチェック」を実施する。
3. 更新
- インプットした成果物で変わった箇所に関わる行とテストデータテンプレートを §2 の手順で見直す。新しい行には最大値の次の ID を振り、不要になった行とテストデータテンプレートは削除する。
- すでに埋まった値は消さない。
- もし要件を追加・削除・変更したなら、その旨をユーザーに伝える。
完成時のセルフチェック
- 要件定義書の全
TDR-*が、テストデータ作成要否の表の関連要件IDに現れている - テストデータ作成要否の表の関連要件IDに、要件定義書に無い
TDR-*が現れていない - テストデータ作成要否の表の全行に
TDT-*がある - 作成方法がスクリプトの行だけが、テストデータテンプレートの関連要件IDに現れている
- テストデータテンプレートの見出しの
TDT-*が、作成方法がスクリプトの行の ID と一致している - 用意する行が無い、手順の中でできる、起動時に既にある、のいずれかの行が、作成要否は不要になっており、作成方法が「—」になっている
- 作成要否が必要の行の作成方法が、「手動」か「スクリプト」になっている
- テストデータテンプレートの列が、そのエンティティについて ER図が定めた属性と一致している
- テーブル名・カラム名が記載されていない
- 画面の表示内容が、テストデータテンプレートに記載されている
- 初期投入データがあるときは、その識別子がテストデータテンプレートに記載されている。無いときは、識別子の列が空欄になっている
- その場で採番する値が「{自動採番}」になっている。日時の列に決め方が記載されている
- 条件の表の関連要件ID・必要な状態・件数・属性(値)の条件・依存・関連テスト観点が埋まっており、「同上」等で省略されていない
- 条件の表の依存のエンティティが、テストデータ作成要否の表に無いときは、その旨をユーザーへ伝えている
TDT-*に重複が無い。更新時は既存の ID と行の対応が変わっていない
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
コメント
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
同じリポジトリのスキル
ビジネス要件定義書(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策定後、ドメイン共通要求仕様書の作成前に呼び出す。