business-requirements-interview

ビジネス要件インタビュー

プロジェクトのアイデアを分析し、ギャップを特定して、状況に応じた質問をします。

プロセス

1. アイデアを理解する

ユーザーにプロジェクトの説明を求めます：

「プロジェクトについて説明してください。解決したい問題、対象者、達成したいことを教えてください。」

回答を分析します：

• 分野（CLI、ウェブアプリ、API など）
• 明確な点と不明確な点
• 不足している要素（ユーザー、範囲、制約）
• 質問すべき内容

2. 状況に応じた質問をする

一般的なフォームではなく、そのプロジェクトに合わせた質問を作成します。

例 - CLI バリデーター：

ユーザー：「CI/CD 用の YAML バリデーターを作りたい」

質問：

1. 「どのスキーマ形式ですか？JSON Schema、カスタム DSL、コードベースのものですか？」
2. 「誰が使いますか？CI/CD 専用ですか、それともローカル開発でも使いますか？」
3. 「エラー出力の形式は？JSON、文章、または両方ですか？」
4. 「パフォーマンス要件は？数千のファイルですか、それとも数十ですか？」

例 - ウェブダッシュボード：

ユーザー：「メトリクス用の分析ダッシュボード」

質問：

1. 「誰が閲覧しますか？経営幹部、プロダクトマネージャー、アナリスト、または複数ですか？」
2. 「どのようなメトリクスですか？収益、利用状況、エンゲージメントですか？」
3. 「リアルタイムですか、それともバッチ処理ですか？データの鮮度はどの程度必要ですか？」
4. 「データソースは？データベース、API、データウェアハウスですか？」

3. 回答に応じて調整する

回答ごとに次の質問を調整します：

• CI/CD → 終了コード、自動化
• ローカル開発 → UX、エラーメッセージ
• 複数のユーザー → アクセス制御

質問の種類

明確化： 「『検証』とは、スキーマ、ビジネスルール、またはその両方を指していますか？」

範囲： 「v1 に含めるのはどれですか：[具体的なリスト]。それとも v2 ですか？」

優先順位： 「速度、詳細なエラー、拡張性のうち、どれが最も重要ですか？」

制約： 「技術、スケジュール、チームに関して、これに影響する制限はありますか？」

成功： 「どうなれば機能していると判断できますか？どのメトリクスが重要ですか？」

構造テンプレート

生成する前に、こちらを確認してください： references/structure-template.yaml

ここには、必要な YAML 構造が正確に示されています。テンプレートとして使用してください。

重要な構造ルール：

• overview.scope → in_scope と out_of_scope の配列を持つ OBJECT（| を使った文字列ではありません）
• timeline → phase、duration、milestones を持つ OBJECT（文字列ではありません）
• functional_requirements[].id → 連番にします：FR-1、FR-2、FR-3（番号を飛ばさず、FR-001 は使いません）
• use_cases[].actor → personas[].name のいずれかと完全に一致するか、「System」である必要があります

必須の網羅項目

次の詳細を集めてください：

• 問題：何が問題か、誰に関係するか、なぜ重要か
• 価値：測定可能な効果
• 範囲：v1 に含めるもの／含めないもの
• ユーザー：対象者、目標、課題
• ユースケース：主要なシナリオ 3～5 件
• 要件：具体的でテスト可能な要件 5～10 件
• 成功：定量化できる目標
• 制約：技術、ビジネス、スケジュール
• リスク：起こりうる問題

避けること

❌ 一般的な質問：「どのような問題を解決しますか？」 ✅ 具体的な質問：「エラーは JSON（機械向け）、文章（人向け）、またはその両方で表示しますか？」

❌ 広すぎる分類：「1. 開発者 2. チーム 3. エンタープライズ」 ✅ 文脈に沿った分類：「1. 設定を検証する開発者 2. 標準を適用するプラットフォームチーム 3. 両方」

進捗の追跡

{base_directory}/artifacts/business-interview.jsonl に保存します：

{"category":"analysis","question":"initial_idea","answer":"CLI YAML validator","timestamp":"2024-05-14T10:30:00Z"}
{"category":"schema","question":"Schema format?","answer":"JSON Schema","rationale":"Industry standard","timestamp":"2024-05-14T10:32:15Z"}

出力

完了したら、{base_directory}/requirements/business-requirements.yaml を生成します。

重要： references/structure-template.yaml の YAML 構造に厳密に従ってください。

スキーマの詳細については、references/output-spec.md を参照してください。

出力には次の項目を必ず含めてください：

• project、version、generated（ルートフィールド）
• overview（problem、value_proposition、scope）
• personas（name、description、goals、pain_points）
• use_cases（name、actor、description、outcome）
• functional_requirements（id: FR-1、FR-2...、category、description、priority、rationale）
• non_functional_requirements
• success_criteria
• constraints
• dependencies
• timeline
• assumptions
• risks

ID 形式： FR-1、FR-2、FR-3（連番で、欠番なし）

完全な例については、references/example.yaml を参照してください。

生成する前に確認してください：

「次の内容で要件ドキュメントを作成する準備ができました：

• 課題と価値提案
• ユースケースを含む3つのペルソナ
• 8つの機能要件
• 成功基準と制約

進めてもよろしいですか？」

検証

sherpy validate -t business-requirements -f {base_directory}/requirements/business-requirements.yaml --strict

エラーがあれば、すぐに修正してください。

ギャップ分析

次の点を確認してください：

• ✅ 具体的でテスト可能な要件
• ✅ 目標がそれぞれ異なる明確なペルソナ
• ✅ 測定可能な成功基準
• ✅ 明示されたスコープの境界
• ✅ 緩和策を含む特定済みのリスク

ギャップがある場合：「[ギャップ]に気付きました。今すぐ対応しますか、それとも続行しますか？」

次のステップ

1. sherpy validate で検証する
2. ギャップを確認する
3. /technical-requirements-interview
4. /implementation-planner

主な違い

旧： 定型的な質問、汎用的な選択肢、すべてのプロジェクトで同じ 新： まず分析し、状況を踏まえた質問を行う、適応型で、対話を知的に進める