C4モデル レベル1(システムコンテキスト図)の新規作成・更新・レビューを支援する。対象システムを中心に、利用者(アクター)と連携先の外部システムを Mermaid で図示する D2 成果物。アクター一覧・外部システム一覧の整備後に呼び出す。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 成果物のパス | 内容 |
|---|---|
docs/D1.business-requirements/actor-list.md | アクター一覧(人(Person)の定義元。ACT-* の名称・役割・ID をそのまま図・表に引く) |
docs/D2.system-requirements/external-system-list.md | 外部システム一覧(外部システム(System_Ext)の定義元。EXT-* の名称・区分・連携目的をそのまま図・表に引く) |
docs/D1.business-requirements/product-requirement-document.md | PRD(対象システム(System)の説明・内製スコープ境界の定義元。§プロダクト概要から中央システムの説明と内製/外部の境界を引く) |
| 成果物のパス | 内容 |
|---|---|
docs/D2.system-requirements/c4-level1-system-context.md | システムコンテキスト図(Mermaid flowchart・C4風)+ 登場要素表。骨組みは .claude/skills/d2-c4-level1-system-context/template.md に従う |
flowchart・C4風)flowchart LR の3カラム構成にする: 利用者(左)→ 対象システム(中央)→ 外部システム(右)。C4 専用記法(C4Context)は要素が増えると中央へ線が放射状に集中し可読性が落ちるため用いない。classDef で 利用者=青系 / 対象システム=濃い青 / 外部システム=灰系。各ノードラベルに ID(ACT-* / EXT-*)を併記する。利用者 --> システム、外部システムは全て システム --> 外部システム。逆向きの関係を作らない(例: 受け取り系も利用者起点の向きに統一する)。subgraph でグルーピング: 左を社内/社外、右を自社別システム/外部サービス 等で括ると見通しが良い。引受査定 / 本人確認依頼)。選定:
ACT-1〜ACT-6)、および統制・運用でシステムを直接操作するアクター(権限・基準・例外統制の業務部門責任者、目視判断・証跡提示を行うコンプライアンス部、監査証跡を検証する内部監査部、監査ログ監視の CSIRT 等)が対象。システムを直接操作せず報告・受領・監督に留まる者(監督官庁 等)は載せない(§描く対象の範囲)。EXT-* をそのまま引く(本書では外部システムを定義・採番しない)。EXT-* は原則すべて登場させる。ACT-1〜ACT-6)が漏れなく登場し、外部システム一覧の EXT-* がすべて登場すること。登場要素表の各列:
ACT-*(アクター一覧)、外部システムは EXT-*(外部システム一覧)をそれぞれ流用する(本書は ID を定義しない)。対象システムは単一のため付番しない(—)。人 / 対象システム / 外部システム。ACT-* は アクター一覧、EXT-* は 外部システム一覧。まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アクター一覧の新規作成・更新・レビューを支援する。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策定後、ドメイン共通要求仕様書の作成前に呼び出す。