Skill.md検索

プロジェクトのスコープを可視化：システムが何を解決し、誰のためで、どの範囲までを対象とするかを1つのドキュメントに統一することで、ステークホルダー全員が同じゴール認識で進められます。 ドメイン用語を標準化：チーム内で「顧客」「ユーザー」など同じ概念に複数の呼び方がされるのを防ぎ、コミュニケーションロスを削減できます。 機能開発の優先順位を客観的に判定：コアドメイン（競争優位）と支援ドメイン（必要だが差別化要素ではない部分）を分けることで、リソース配分の根拠が明確になります。 隣接ドメインとの境界を明確化：スコープ外の領域を事前に定義することで、機能追加時に「これ含める？」といった議論を減らせます。 次のフェーズへのロードマップが描ける：サブドメインの特定と関係整理により、フィーチャーモデリングや概念モデル化へ自然に進められます。 新規プロジェクトの企画・立ち上げを担当するPM・プロダクトマネージャー 複雑なシステムの開発範囲を整理したい技術リード ビジネス側とエンジニア側で「何を作るか」の認識を統一したい組織 アジャイル開発でも必要な基本設計を高速で実施したいチーム ドメインスコーピングは5つのステップで進みます：（1）システムの目的・利用者・ビジネス文脈の確認、（2）スコープ内/外の明確な線引き、（3）サブドメインの識別と関係整理、（4）ドメイン用語の収集と標準化、（5）成果物をdocs/gp/01-domain-scope.mdに出力（テンプレートはtemplates/domain-scope-template.mdを使用）。既存プロジェクトのコード・ドキュメント・設定ファイルも分析対象に含めます。次のステップは「フィーチャーモデリングと概念モデリング」（/feature-modeling）が推奨される関連スキルです。このスキルはジェネレーティブプログラミングのドメイン分析活動に位置づけられ、アーキテクチャ設計やコード生成の基礎となります。

ドメインスコープから共通性・可変性を分析し、「何は安定で何は変わりうるか」を構造化できます。 フィーチャーツリーと概念モデルを自動生成し、エンティティ・ユースケース・ビジネスルール・境界を可視化できます。 可変要素の変化駆動要因と変化タイプを明記し、差し替え型・追加型・パラメータ型・構造型の変更に対応できます。 フィーチャー間の依存関係と制約を定義し、変更波及パスを事前に把握できます。 ジェネレーティブプログラミング・プロダクトラインの設計を進める設計者 ドメインモデルを構造化して次段階の実装設計に進みたい人 「何が変わりうるか」を明確にして、拡張可能なアーキテクチャを設計したい人 ドメインスコープ（docs/domain/domain-scope.md）を前提として、共通性・可変性分析を4つの観点（エンティティと関係、ユースケース、ビジネスルール、外部との境界）で実施します。各要素について安定か変わりうるかを判定し、可変要素は変化駆動要因と変化タイプ（差し替え・追加・パラメータ・構造）を詳細化します。フィーチャーツリーはツリー構造に組織化し、各フィーチャーに名前・説明・状態（有効/無効/未実装）を付与、選択ルール（AND/OR/XOR）を明確にします。フィーチャー間の制約（requires/excludes/impacts）を定義し、変更波及パスを記録します。成果物は feature-model.md・concept-model.md・constraints.md の3ファイルで、循環依存チェック・フィーチャー組み合わせの制約検証を実施します。

ドメイン仕様書（DSL）に基づいて、構成の知識から自動的にコードを生成・変更する仕組みを構築できます。 AIスキル、プロンプトテンプレート、コードジェネレータのいずれかの方式を選定・実装し、フィーチャー追加時に仕様書を更新するだけでシステムを進化させるサイクルを実現できます。 既存システムの構成変更時に差分を自動検出し、必要な変更波及箇所を特定することで、手作業によるコード変更の負担を削減できます。 サンプル仕様書からのテスト生成により、生成ロジックの正確性を事前に検証できます。 複数の機能・フィーチャーを管理し、コード生成を自動化したいシステム開発チームのアーキテクト ドメイン駆動設計（DDD）を実践しており、仕様からの一貫性あるコード生成を目指すエンジニア テンプレートエンジンやコードジェネレータの構築経験がある開発チーム ジェネレータ実装は5ステップです：①生成方式の決定（AIスキル/プロンプトテンプレート/コードジェネレータの選定）、②生成ルール実装（マッピングルール、組み合わせルール、インターフェース検証を実装可能な形に変換）、③変更生成実装（差分検出、変更特定、制約に基づく影響範囲確認）、④検証試行（サンプル仕様からの生成確認、フィーチャー変更時の再生成確認、アーキテクチャ適合性確認）、⑤完了案内。以降は仕様書を書いてシステムを「発注」し、フィーチャー変更を仕様書に反映して進化させるサイクルで開発を進めます。