要件インタビュー
曖昧なリクエストを実行可能な仕様に変換するための構造化フレームワーク。
インタビューフレームワーク
フェーズ 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: ユーザーが技術者でない限り平易な言葉を使用