| name | interview |
| description | 曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面:
- ユーザー要件が不明確または不完全な場合
- 新機能を開始し要件を収集する必要がある場合
- ユーザーのニーズ、制約、優先順位を理解する必要がある場合
- ビジネスリクエストを技術仕様に変換する場合
- ユーザーが詳細なしに「～したい」「～を追加して」と言う場合
Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
|
| allowed-tools | AskUserQuestion, Read, Write |
| model | sonnet |
| user-invocable | true |
要件インタビュー
曖昧なリクエストを実行可能な仕様に変換するための構造化フレームワーク。
インタビューフレームワーク
フェーズ 1: コンテキストの理解
全体像を理解するためにオープンな質問から始める:
1. ゴール: 「どのような問題を解決しようとしていますか？」
2. ユーザー: 「この機能を使うのは誰ですか？」
3. 成功: 「これが成功したとどのように判断しますか？」
4. 動機: 「なぜ今これが必要ですか？」
フェーズ 2: 機能要件
トレードオフ質問を使用する（オープンエンドではなく）:
悪い質問:
「どのような機能が欲しいですか？」
良い質問:
「ユーザー認証について、どちらを希望しますか？
- ソーシャルログイン（実装が速い、サードパーティに依存）
- カスタム認証（コントロールが多い、構築に時間がかかる）
- 両方（柔軟性が最大、複雑さも最大）」
質問テンプレート
技術的な判断
[機能] について、どちらを希望しますか？
A) [選択肢 A] - [利点] ただし [欠点]
B) [選択肢 B] - [利点] ただし [欠点]
C) 制約に基づいて推奨してほしい
スコープの境界
[機能] に以下を含めるべきですか？
- [サブ機能 1]: はい / いいえ / 後で
- [サブ機能 2]: はい / いいえ / 後で
- [サブ機能 3]: はい / いいえ / 後で
優先順位
重要度順にランク付けしてください（1-5）:
- [ ] 機能 A
- [ ] 機能 B
- [ ] 機能 C
フェーズ 3: 非機能要件
具体的な選択肢で制約を収集:
パフォーマンス
許容できるレスポンスタイムは？
- リアルタイム（<100ms）
- インタラクティブ（<500ms）
- バックグラウンド（<2s）
- 非同期（数分～数時間）
スケール
想定する同時接続ユーザー数は？
- チーム（10-50）
- 部門（50-500）
- 組織（500-5000）
- パブリック（5000+）
可用性
必要な稼働率は？
- ベストエフォート（95%）
- 営業時間（99%）
- 常時利用可能（99.9%）
- クリティカル（99.99%）
セキュリティ
データの機密性レベルは？
- パブリック（制限なし）
- 社内（従業員のみ）
- 機密（関係者のみ）
- 制限付き（規制対象データ）
フェーズ 4: エッジケース
境界について質問:
次の場合はどうすべきですか？
- ユーザーにインターネット接続がない場合
- データが無効または不正な場合
- ユーザーに権限がない場合
- システムが高負荷の場合
- ユーザーが操作を途中でキャンセルした場合
- 同時編集が発生した場合
フェーズ 5: 既存の制約
制限を特定:
考慮すべき制約はありますか？
- 統合が必要な既存システム？
- 技術的な制限？
- 予算や時間の制限？
- コンプライアンス要件（GDPR, HIPAA, SOC2）？
- チームのスキル制約？
インタビューチェックリスト
終了前に確認:
出力形式
インタビュー後、以下の要約を作成:
# 要件サマリー: [機能名]
## コンテキスト
- **課題**: [この機能が解決する問題]
- **ユーザー**: [対象ユーザー]
- **成功指標**: [成功の測定方法]
## 機能要件
| ID | 要件 | 優先度 |
|----|------|--------|
| FR-001 | ユーザーは～できる | P0 |
| FR-002 | システムは～すべき | P1 |
## 非機能要件
| カテゴリ | 要件 |
|----------|------|
| パフォーマンス | [目標] |
| セキュリティ | [要件] |
| スケーラビリティ | [期待値] |
## 制約
- [制約 1]
- [制約 2]
## スコープ外
- [項目 1]
- [項目 2]
## 未解決の質問
- [残っている曖昧さ]
## 次のステップ
1. 要件をレビューし承認
2. 詳細な仕様を作成
3. 実装計画を開始
効果的なインタビューのコツ
- まず聞く: 具体的な質問の前にユーザーの説明を聞く
- 頻繁に要約: 「つまり～ということですね」で理解を確認
- 専門用語を避ける: ユーザーが技術者でない限り平易な言葉を使用
- すべてを文書化: 「当然」の要件も含めて
- 「なぜ」を聞く: リクエストだけでなく動機を理解
- トレードオフを提示: 長所/短所を含む選択肢を提示
- 辛抱強く: 良い要件には時間がかかる
避けるべき一般的な落とし穴
| 落とし穴 | 問題点 | 代替案 |
|---|
| 誘導質問 | 回答にバイアスがかかる | 中立的に質問する |
| はい/いいえのみ | ニュアンスを見逃す | コンテキストを求める |
| 専門知識を前提とする | ユーザーを混乱させる | 用語を定義する |
| NFR のスキップ | 不完全な仕様 | 常に質問する |
| 急ぐ | 詳細を見逃す | 時間をかける |
ルール（L1 - ハード）
要件の正確性にとって重要。違反すると不正確な実装につながる。
- ALWAYS: 要件収集時は AskUserQuestion ツールを使用する（推測を防ぐ）
- NEVER: 明示されていない要件を推測しない（推測は手戻りの原因）
- NEVER: 非機能要件をスキップしない（不完全な仕様になる）
- ALWAYS: 進める前にスコープの明示的な確認を得る
- NEVER: 未解決の質問があるまま進めない（曖昧さは誤った判断の原因）
- MUST: 各インタビューフェーズ（コンテキスト、機能、非機能、エッジケース、制約）で AskUserQuestion を使用する
デフォルト（L2 - ソフト）
品質にとって重要。適切な理由がある場合はオーバーライド可能。
- インタビュー中に議論したトレードオフを文書化する
- 結論前にユーザーに理解を要約して返す
- 構造化された質問テンプレートを使用する（コンテキストに応じて適応可能）
- 指定された形式で要件サマリーを作成する
ガイドライン（L3）
より良いインタビューのための推奨事項。
- consider: リクエストだけでなく動機を理解するために「なぜ」を聞くことを検討
- prefer: オープンエンドの質問よりトレードオフ質問を推奨
- consider: 「当然」の要件も文書化することを検討
- recommend: ユーザーが技術者でない限り平易な言葉を使用
