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