feature-modeling

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.md
• docs/domain/concept-model.md — 概念モデル（エンティティ・ユースケース・ビジネスルール・境界の共通性/可変性分析結果）。テンプレート: templates/concept-model-template.md
• docs/domain/constraints.md — フィーチャー間制約と影響関係。制約パターンは references/constraint-patterns.md を参照

ステップ5: バリデーション

フィーチャーモデルに矛盾がないか検証する:

• 循環依存がないこと
• 現在有効なフィーチャーの組み合わせが制約に違反していないこと

問題があればユーザーに報告し、修正を提案する。

ステップ6: 次のステップの案内

次の活動として「共通アーキテクチャの設計」（/architecture-design）が推奨されるが、必要に応じて他の活動に進んだり、ドメインスコーピングに戻って成果物を更新してもよい。