القائمة
RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Marp Markdown スライドデッキの作成・拡張・再生成を支援。PlantUML 図表、AI 画像バリアント、漫画画像バリアント、PPTX/HTML 出力に対応。`tmp/k2works-wiki/スライド/YYYYMMDD` などの日本語技術スライドフォルダの構築・更新、コードサンプル追加、ビジュアル要約スライド追加、`スライド.images.md` / `スライド.images.ai.md` / `スライド.images.ai.manga.md` の生成、Marp HTML/PPTX デッキの再生成時に使用。
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
企業事例（与件文）を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析（SWOT・VRIO・BMC）から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
| 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-architecture — 前段のビジネスアーキテクチャ分析analyzing-inception-deck — 前段のインセプションデッキanalyzing-usecases — 後続のユースケース・ユーザーストーリー詳細化orchestrating-analysis — 分析フェーズ全体のワークフロー案内