hearing-first

実装前にユーザーの意向を段階的にヒアリングする手法
Category: discovered
Tags: github, community
Version: 1.0.0
Author: walid
Downloads: 0
Updated: 2025-11-22
Source: chronista-club/fleetflow
Download the latest version (v1.0.0) from this page.
SKILL.md

---
title: Hearing-First Skills
description: 実装前にユーザーの意向を段階的にヒアリングする手法
version: 1.0.0
author: Vantage Hub Contributors
created_at: 2025-11-02
updated_at: 2025-11-02
tags:
  - hearing-first
  - requirements-gathering
  - user-interview
  - incremental-approach
  - design-thinking
categories:
  - skill
  - methodology
  - communication
---

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

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

## 目的

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

## 適用場面

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

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

## スキルの実行手順

### 1. 質問を大項目に分類

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

**例（MIDI/OSCサーバー開発の場合）：**
1. ブランチとworktreeの構成
2. 技術スタック・ライブラリ
3. アーキテクチャ設計
4. 機能スコープ

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

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

**質問設計のポイント：**
- 具体的な選択肢を提示（ユーザーが答えやすい）
- 技術的な背景を簡潔に説明
- 「その他」の選択肢も用意（柔軟性を保つ）

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

### 3. 一つずつ確認

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

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

まず最初の質問です：

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

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

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

どのようにしますか？
```

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

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

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

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

次の質問です：
...
```

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

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

```markdown
## ✅ 確認内容のまとめ

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

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

では実装を開始します。
```

## ベストプラクティス

### ✅ 良い例

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

### ❌ 避けるべき例

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

## テンプレート

```markdown
## {大項目名}

{導入文}

### {小項目名}

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

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

どのようにしますか？
```

## 注意事項

1. **ユーザーのペースを尊重**
   - 焦らず、一つずつ確認
   - 追加質問があれば対応

2. **柔軟性を保つ**
   - 提案した選択肢以外も受け入れる
   - ユーザーの意見を最優先

3. **技術的助言は適度に**
   - おすすめを示しても良いが押し付けない
   - 理由を簡潔に説明

4. **合意形成を明確に**
   - 各大項目の終わりに確認
   - 全体のまとめを提示

## 成功の指標

このスキルが成功している場合：
- ユーザーが答えやすいと感じている
- 実装前に方針が明確になっている
- 手戻りが少ない
- ユーザーとの認識が一致している