| name | feature-modeling |
| description | ドメインスコープからフィーチャーモデルと概念モデルを作成する。 共通性・可変性分析を行い、フィーチャーツリー、概念モデル（エンティティ・ ユースケース・ビジネスルール）、フィーチャー間の制約を構造化する。 「フィーチャーを整理したい」「何が変わりうるか分析したい」 「概念モデルを作りたい」「依存関係を定義したい」といった要求があった 場合に使用する。ドメインスコーピングの成果物が存在することが前提。 ジェネレーティブプログラミングのドメイン分析活動。
|
フィーチャーモデリングと概念モデリング
ドメインスコープに基づき、共通性・可変性分析を行いながらフィーチャーモデルと概念モデルを作成するスキル。
ジェネレーティブプログラミングのドメイン分析活動。
前提確認
docs/domain/domain-scope.md が存在するか確認する- 存在しない場合、先にドメインスコーピング（
/domain-scoping）を行うことを推奨するが、必要に応じてこの活動から始めてもよい
手順
ステップ1: 共通性・可変性分析
ドメインの構成要素を洗い出しながら、各要素が共通（安定）か可変（変化しうる）かを同時に判定する。「何があるか」と「それは変わるか」を対比しながら分析するのが核心。
以下の4つの観点で、要素を洗い出すたびに共通/可変を判定する。
1-1. エンティティと関係
- システムが扱う主要なデータ（人、モノ、コト）を洗い出す
- 各エンティティの属性と、エンティティ間の関係を整理する
- 各エンティティ・属性・関係について: これは安定か？変わりうるか？を判定する
1-2. ユースケース
- 利用者がシステムで行う主要な操作を列挙する
- 各ユースケースに関わるエンティティを紐づける
- 各ユースケースについて: これは安定か？将来追加・変更されうるか？を判定する
1-3. ビジネスルール
- システムが守るべきルール・制約を洗い出す
- どのルールがどのエンティティ・ユースケースに関係するかを整理する
- 各ルールについて: これは不変か？規制や方針の変化で変わりうるか？を判定する
1-4. 外部との境界
- システム内部と外部の境界を明確にする（外部サービス、UI、データソースなど）
- 各境界について: 接続先や連携方式は安定か？差し替わりうるか？を判定する
可変要素の詳細化
可変と判定した要素については、以下を追記する:
- 変化の駆動要因: なぜ変わりうるのか（技術進化、ビジネス要件、規制、スケーリングなど）
- 変化のタイプ:
- 差し替え型: 現在の実装を別の実装に置き換える（例: 決済プロバイダの変更）
- 追加型: 既存の選択肢に新しい選択肢を追加する（例: 新しい通知チャネルの追加）
- パラメータ型: 設定値の変更で対応できる（例: 閾値の変更、対応通貨の追加）
- 構造型: データモデルやアーキテクチャレベルの変更（例: マルチテナント化）
ステップ2: フィーチャーツリーの構築
ステップ1の分析結果からフィーチャーを抽出し、ツリー構造に組織化する。
- 各フィーチャーに名前・説明・現在の状態（有効/無効/未実装）を付与する
- 親子関係、グループ関係を定義する
- 各グループの選択ルール（AND / OR / XOR / 任意）を明確にする
- 共通要素のフィーチャーは「固定」としてマークする
- 可変要素のフィーチャーは差し替え可能ポイントとして明示する
ステップ3: フィーチャー間の制約と影響関係の定義
フィーチャー間の依存関係を洗い出す:
- requires: AがBを必要とする
- excludes: AとBは両立しない
- impacts: Aの変更がBに影響を与える（壊れはしないが確認が必要）
変更波及パスを記録する: あるフィーチャーを変更したとき、影響が波及するフィーチャーの連鎖。各関係の理由も記録する。
ステップ4: 成果物の出力
以下のファイルを出力する:
docs/domain/feature-model.md — フィーチャーモデル。テンプレート: templates/feature-model-template.mddocs/domain/concept-model.md — 概念モデル（エンティティ・ユースケース・ビジネスルール・境界の共通性/可変性分析結果）。テンプレート: templates/concept-model-template.mddocs/domain/constraints.md — フィーチャー間制約と影響関係。制約パターンは references/constraint-patterns.md を参照
ステップ5: バリデーション
フィーチャーモデルに矛盾がないか検証する:
- 循環依存がないこと
- 現在有効なフィーチャーの組み合わせが制約に違反していないこと
問題があればユーザーに報告し、修正を提案する。
ステップ6: 次のステップの案内
次の活動として「共通アーキテクチャの設計」（/architecture-design）が推奨されるが、必要に応じて他の活動に進んだり、ドメインスコーピングに戻って成果物を更新してもよい。
