ヒアリングファーストスキル

このスキルは、複雑な機能開発や技術的判断が必要なタスクにおいて、実装前にユーザーの意向を段階的にヒアリングする手法です。

目的

• 実装前にユーザーの要件・方針を明確化
• 一度に多くの質問をせず、段階的に確認
• ユーザーが答えやすい形で質問を構造化
• 認識のズレを早期に発見

適用場面

以下のような状況で、このスキルを使用してください：

• 新機能の開発開始時
• 大きな設計判断が必要な時
• 技術選定が必要な時
• アーキテクチャ設計が必要な時
• 複数の実装方針が考えられる時

スキルの実行手順

1. 質問を大項目に分類

タスクを分析し、確認が必要な事項を大項目に分類します。

例（MIDI/OSCサーバー開発の場合）：

1. ブランチとworktreeの構成
2. 技術スタック・ライブラリ
3. アーキテクチャ設計
4. 機能スコープ

2. 各大項目内で小質問を準備

各大項目について、具体的な質問を準備します。

質問設計のポイント：

• 具体的な選択肢を提示（ユーザーが答えやすい）
• 技術的な背景を簡潔に説明
• 「その他」の選択肢も用意（柔軟性を保つ）

例：

### 2. 技術スタック・ライブラリ
- **MIDIライブラリ**: どれを使用しますか？
  - `midir` (クロスプラットフォーム、人気)
  - `portmidi-rs`
  - その他
- **OSCライブラリ**: どれを使用しますか？
  - `rosc` (人気、シンプル)
  - `nannou_osc`
  - その他

3. 一つずつ確認

重要： すべての質問を一度に提示せず、大項目ごとに確認します。

## 1. ブランチとworktreeの構成

まず最初の質問です：

### ブランチ名とディレクトリ名

**Q1:** ブランチ名は `feature/midi-osc-server` で良いですか？

**Q2:** worktreeのディレクトリ名はどうしますか？
- 案1: `vantage-hub-midi-osc`
- 案2: `../vantage-hub.midi-osc` (親ディレクトリに作成)
- 案3: その他のお好みの名前

どのようにしますか？

4. 回答を受けて次へ進む

ユーザーの回答を確認し、次の大項目に進みます。

了解しました。ブランチ名は `feature/xxx`、worktreeは `案2` で進めます。

## 2. 技術スタック・ライブラリ

次の質問です：
...

5. すべての確認後に実装開始

全ての大項目の確認が終わったら、合意内容をまとめて実装に進みます。

## ✅ 確認内容のまとめ

以下の方針で実装を進めます：

1. **構成**: ブランチ `feature/xxx`, worktree `../xxx`
2. **技術**: MIDI: `midir`, OSC: `rosc`
3. **設計**: 統合サーバー、ポート 8000
4. **スコープ**: 受信 + イベント化

では実装を開始します。

ベストプラクティス

✅ 良い例

• 大項目を3-5個程度に絞る
• 各項目で2-4個の質問
• 具体的な選択肢を提示
• 技術的背景を簡潔に説明
• 一つずつ確認

❌ 避けるべき例

• 一度に10個以上の質問をする
• 選択肢なしのオープンな質問ばかり
• 技術用語の説明なし
• すべての質問を一度に提示
• ユーザーの回答を待たずに進める

テンプレート

## {大項目名}

{導入文}

### {小項目名}

**Q1:** {質問文}？
- 案1: {選択肢1} ({補足説明})
- 案2: {選択肢2} ({補足説明})
- 案3: その他のお好みの{内容}

**Q2:** {質問文}？
- {選択肢A}
- {選択肢B}

どのようにしますか？

注意事項

1. ユーザーのペースを尊重

   • 焦らず、一つずつ確認
   • 追加質問があれば対応

2. 柔軟性を保つ

   • 提案した選択肢以外も受け入れる
   • ユーザーの意見を最優先

3. 技術的助言は適度に

   • おすすめを示しても良いが押し付けない
   • 理由を簡潔に説明

4. 合意形成を明確に

   • 各大項目の終わりに確認
   • 全体のまとめを提示

成功の指標

このスキルが成功している場合：

• ユーザーが答えやすいと感じている
• 実装前に方針が明確になっている
• 手戻りが少ない
• ユーザーとの認識が一致している