메뉴
RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
インセプションデッキの Markdown から PowerPoint スライド（.pptx）を自動生成。pptxgenjs を使用し、テンプレート準拠の 12 枚構成プレゼンテーションを出力する。「スライドを生成したい」「インセプションデッキの pptx を作りたい」「プレゼン資料を出力したい」「スライドを更新したい」といった場面で発動する。Markdown から自動生成することで、内容更新のたびに手動でスライドを作り直す手間を排除する。
開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
| name | analyzing-requirements |
| description | RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。 |
RDRA 2.0（リレーションシップ駆動要件分析）に基づき、システム価値→外部環境→境界→内部構造の 4 層で要件を体系的に整理する。
RDRA の価値は、要件を「何となくの要望リスト」ではなく「なぜそれが必要か」の根拠付きで構造化できること。各層の出力が次の層の入力になるため、トレーサビリティが自然に確保される。
| 種類 | パス | 備考 |
|---|---|---|
| ガイド | @docs/reference/要件定義ガイド.md | RDRA 2.0 の進め方詳細 |
| テンプレート | @docs/template/要件定義.md | 編集禁止。コピーして使用する |
| 入力 | @docs/strategy/business_architecture.md | ビジネスアーキテクチャ分析書 |
| 入力 | @docs/strategy/inception-deck.md | インセプションデッキ |
| 成果物 | docs/requirements/requirements_definition.md | テンプレートを基に作成 |
各層は上から下に向かって具体化されていく。上位層が曖昧だと下位層の定義がブレるため、この順序で進めることが重要。
「なぜこのシステムが必要か」を明確にする。インセプションデッキの「なぜやるのか」をシステムの文脈で具体化する。
「どのような業務の中でシステムが使われるか」を整理する。ビジネスアーキテクチャ分析書のバリューストリームや組織マップが入力になる。
「システムの内と外の接点は何か」を定義する。外部環境の分析結果から、システムが担う範囲を確定する。
「システム内部でどのような情報をどう扱うか」を設計する。後続のデータモデル設計・ドメインモデル設計の基礎になる。
docs/requirements/requirements_definition.md として出力する既存の docs/requirements/requirements_definition.md がある場合は、まずその内容を確認する。不足している層や更新が必要な部分のみを修正する。
Example:
ユーザー: 「システムコンテキストは作った。業務フローを整理したい」
回答: 層 2（システム外部環境）の業務フロー作成に進む。
既存のシステムコンテキスト図のアクターを起点に、
各アクターの業務プロセスを PlantUML アクティビティ図で可視化する。
analyzing-business — 前段のビジネスアーキテクチャ分析analyzing-inception-deck — 前段のインセプションデッキanalyzing-usecases — 後続のユースケース・ユーザーストーリー詳細化orchestrating-analysis — 分析フェーズ全体のワークフロー案内