القائمة
PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。
التثبيت باستخدام 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-data-model |
| description | PlantUML の ER 図を使用したデータモデル設計を支援。概念→論理データモデルの段階的設計とテーブル定義。「データモデルを設計したい」「ER 図を作りたい」「テーブル定義を作成したい」「データベース設計を始めたい」「正規化を検討したい」といった場面で発動する。データモデルを先に設計することで、実装時のテーブル設計の手戻りを防ぐ。 |
PlantUML の ER 図を使用して、概念データモデル→論理データモデルの順でデータモデルを設計する。
データモデルはシステムの「記憶」を定義する設計。ドメインモデルが業務ロジックの構造を表すのに対し、データモデルはデータの永続化構造を定義する。両者の整合性がシステム全体の一貫性を保証する。
| 種類 | パス | 備考 |
|---|---|---|
| ガイド | @docs/reference/データモデル設計ガイド.md | データモデル設計の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
| 成果物 | docs/design/data-model.md | データモデル設計 |
業務の言葉でエンティティとリレーションシップを識別する。この段階では物理的な実装を考えない。ユースケースの「名詞」がエンティティ候補になる。
概念モデルを具体的なテーブル構造に落とし込む。正規化は第 3 正規形を基本とし、パフォーマンス要件に応じて非正規化を検討せよ。
PlantUML を使用して ER 図を作成する。テーブル間の関係を可視化することで、設計レビューの効率が上がる。
docs/design/data-model.md として出力する既存の docs/design/data-model.md がある場合は、まずその内容を確認する。不足しているエンティティや更新が必要なリレーションシップのみを修正する。
Example:
ユーザー: 「概念モデルはできた。論理モデルを作りたい」
回答: 既存の data-model.md の概念データモデルを確認し、
各エンティティのテーブル定義（カラム・データ型・制約）を作成する。
主キー・外部キーの設計を行い、ER 図を PlantUML で更新する。
orchestrating-analysis — 分析フェーズ全体のワークフロー案内analyzing-architecture — 前段のアーキテクチャ設計analyzing-domain-model — 並行して進めるドメインモデル設計analyzing-tech-stack — 後続の技術スタック選定（DB 選定に影響）