0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

詳細設計書作成前のヒアリングテンプレート - 角が立たない確認術

0
Posted at

詳細設計書作成前のヒアリングテンプレート - 角が立たない確認術

認識齟齬を防ぎ、円滑にプロジェクトを進めるためのヒアリングテンプレートをお届けします!

📋 1. ヒアリングシート全体構成

┌─────────────────────────────────────────┐
│  ヒアリングの5W1H                        │
├─────────────────────────────────────────┤
│  Why   : なぜこの機能が必要か          │
│  What  : 何を作るのか                  │
│  Who   : 誰が使うのか                  │
│  When  : いつまでに必要か              │
│  Where : どこで使われるか              │
│  How   : どうやって実現するか          │
└─────────────────────────────────────────┘
        ↓
┌─────────────────────────────────────────┐
│  認識確認の3ステップ                     │
├─────────────────────────────────────────┤
│  Step 1: 背景・目的の確認               │
│  Step 2: 要件の具体化                   │
│  Step 3: 制約・前提条件の明確化          │
└─────────────────────────────────────────┘

💬 2. 丁寧な質問フレーズ集

2.1 基本的な聞き方パターン

【DO - 角が立たない表現】

✅ 「確認させてください」系
   "念のため確認させていただきたいのですが..."
   "理解を深めたいので、教えていただけますでしょうか..."
   "認識に齟齬がないか確認させてください..."

✅ 「私の理解では」系
   "私の理解では○○という認識ですが、この理解で合っていますでしょうか?"
   "○○という理解で進めてよろしいでしょうか?"
   "こちらで○○と解釈したのですが、いかがでしょうか?"

✅ 「具体例で確認」系
   "例えば、○○のような場合はどうなりますか?"
   "具体的には、○○という動きをイメージしているのですが..."
   "○○の場合と△△の場合で動作は変わりますか?"

✅ 「選択肢を提示」系
   "○○と△△のどちらをイメージされていますか?"
   "パターンとしては以下が考えられますが、どれが近いでしょうか?"

【DON'T - 避けるべき表現】

❌ 詰問・攻撃的な表現
   × "それはおかしいんじゃないですか?"
   × "なぜそうなるんですか?"
   × "説明が矛盾してますよね?"
   × "さっきと言ってること違いますよね?"

❌ 相手を否定する表現
   × "それは無理です"
   × "そんなのできません"
   × "常識的に考えて..."

❌ 曖昧なまま進める
   × "まあ、なんとかなるでしょう"
   × "その辺は適当に..."
   × "察します"

📝 3. ヒアリングシートテンプレート

3.1 プロジェクト基本情報

# 詳細設計ヒアリングシート

## 基本情報

**ヒアリング日時**: 2025年1月21日 14:00-15:00
**ヒアリング実施者**: YUKIKO ISHIGURO
**ヒアリング対象者**: [お名前] 様 ([部署・役職])
**プロジェクト名**: ネットワーク監視ダッシュボード開発
**バージョン**: 1.0

---

## 1. 背景・目的の確認

### 1.1 プロジェクトの背景
**質問**: 
今回のプロジェクトを始めることになった背景について、
念のため確認させていただけますでしょうか?

**回答メモ**:
_______________________________________
_______________________________________

**私の理解**:
現状、ネットワーク監視が手動で行われており、
異常検知に時間がかかっているため、
リアルタイム監視ダッシュボードが必要。
→ この理解で合っていますでしょうか? □ Yes □ 要調整

---

### 1.2 解決したい課題
**質問**:
具体的にどのような課題を解決したいと
お考えでしょうか?

**回答メモ**:
_______________________________________
_______________________________________

**確認ポイント**:
- □ 現状の問題点が明確か
- □ 課題の優先順位が明確か
- □ 定量的な目標があるか(例: 検知時間50%削減)

---

### 1.3 成功の定義
**質問**:
このプロジェクトがどうなれば成功とお考えですか?
例えば、「○○ができるようになれば成功」といった
イメージがあれば教えてください。

**回答メモ**:
_______________________________________
_______________________________________

**KPI確認**:
- □ 定量的な目標: _______________________
- □ 定性的な目標: _______________________
- □ 測定方法: ___________________________

---

## 2. ユーザー・利用シーン

### 2.1 想定ユーザー
**質問**:
このシステムを主に使われる方は
どのような方々でしょうか?

**回答メモ**:
_______________________________________
_______________________________________

**確認項目**:
| ユーザー区分 | 人数 | ITスキルレベル | 利用頻度 | 主な利用目的 |
|------------|------|--------------|---------|------------|
| ネットワーク管理者 |  |  |  |  |
| セキュリティ担当 |  |  |  |  |
| マネージャー |  |  |  |  |

---

### 2.2 利用シーン
**質問**:
具体的にどのような場面で使われることを
想定されていますか?
例えば「朝の定例チェック時」「アラート発生時」など...

**回答メモ**:
_______________________________________
_______________________________________

**シナリオ整理**:
1. **日常監視**: _________________________
2. **異常検知時**: _______________________
3. **レポート作成時**: ___________________

---

## 3. 機能要件の具体化

### 3.1 必須機能
**質問**:
「これがないと困る」という機能を
教えていただけますでしょうか?

**回答メモ**:
_______________________________________
_______________________________________

**優先度付け**:
| 機能名 | 優先度 | 理由 | リリース時期 |
|--------|--------|------|-------------|
|  | Must | | V1.0 |
|  | Should | | V1.1 |
|  | Nice to have | | V2.0 |

---

### 3.2 表示項目・内容
**質問**:
ダッシュボードに表示したい情報について、
具体的に教えていただけますか?
例えば「送信元IP」「通信量」など...

**回答メモ**:
_______________________________________
_______________________________________

**表示項目リスト**:
| 表示項目 | 必須/任意 | 更新頻度 | データソース |
|---------|----------|---------|-------------|
| 総通信量 | 必須 | リアルタイム | network_logs |
|  |  |  |  |

---

### 3.3 操作フロー
**質問**:
ユーザーが画面でどのような操作をすることを
想定されていますか?
具体的な流れを教えていただけると助かります。

**回答例で確認**:
「例えば、以下のような流れをイメージしているのですが...
 1. ダッシュボードを開く
 2. 異常なIPを発見
 3. そのIPをクリックして詳細を見る
 4. 必要に応じてアクションを取る
この理解で合っていますでしょうか?」

**回答メモ**:
_______________________________________
_______________________________________

---

### 3.4 画面イメージ
**質問**:
画面のイメージについて、参考になるものや
「こんな感じ」というものはありますか?

**方法**:
- 手書きで簡単に描いていただく
- 参考サイトを見せていただく
- 類似システムを参考にする

**回答メモ**:
_______________________________________
_______________________________________

**添付**: □ 画像 □ URL □ 手書きメモ

---

## 4. データに関する確認

### 4.1 データソース
**質問**:
表示するデータはどこから取得しますか?
念のため確認させてください。

**回答メモ**:
_______________________________________
_______________________________________

**データソース一覧**:
| データ種類 | 取得元 | 更新頻度 | データ量 | 保持期間 |
|----------|--------|---------|---------|---------|
| 通信ログ | Splunk | リアルタイム | 50GB/日 | 90日 |
|  |  |  |  |  |

---

### 4.2 データ鮮度
**質問**:
データの更新頻度について、
どの程度リアルタイム性が必要でしょうか?

**選択肢で確認**:
「以下のどれが近いイメージでしょうか?
 A) 数秒以内(完全リアルタイム)
 B) 1分以内
 C) 5分以内
 D) 時間単位でOK」

**回答**: □ A □ B □ C □ D □ その他(_______)

**私の理解**:
業務上、○○の理由で○分以内の更新が必要。
→ この理解で進めてよろしいでしょうか?

---

### 4.3 データ量
**質問**:
扱うデータの規模感を教えていただけますか?
例えば、1日あたりのレコード数など...

**回答メモ**:
_______________________________________
_______________________________________

**パフォーマンス要件**:
- 1日あたりのデータ量: ________________
- 同時アクセスユーザー数: ____________
- 画面表示の許容時間: ________________

---

## 5. 非機能要件

### 5.1 パフォーマンス
**質問**:
画面表示の速度について、
どの程度を期待されていますか?

**回答メモ**:
_______________________________________
_______________________________________

**パフォーマンス目標**:
- ダッシュボード初期表示: _____秒以内
- 検索・フィルタ適用: _____秒以内
- グラフ更新: _____秒以内

---

### 5.2 可用性
**質問**:
システムの稼働時間について、
要件はありますでしょうか?

**選択肢で確認**:
- □ 24時間365日稼働
- □ 営業時間のみ(平日9-18時)
- □ その他: _______________

**ダウンタイム許容**:
- 計画メンテナンス: □ 可 □ 不可
- 許容ダウン時間: _____________

---

### 5.3 セキュリティ
**質問**:
アクセス制限やセキュリティ要件について
確認させてください。

**回答メモ**:
_______________________________________
_______________________________________

**セキュリティチェック**:
- □ 認証が必要
- □ ロールベースのアクセス制御
- □ ログの記録が必要
- □ データの暗号化が必要
- □ 特定ネットワークからのみアクセス可

---

## 6. 制約・前提条件

### 6.1 技術的制約
**質問**:
使用する技術やツールについて、
制約はありますでしょうか?

**回答メモ**:
_______________________________________
_______________________________________

**技術スタック確認**:
| 項目 | 指定 | 理由 |
|------|------|------|
| Splunkバージョン |  |  |
| ブラウザ |  |  |
| 画面解像度 |  |  |

---

### 6.2 運用制約
**質問**:
運用面での制約があれば教えてください。
例えば「深夜のメンテナンスは不可」など...

**回答メモ**:
_______________________________________
_______________________________________

---

### 6.3 予算・スケジュール
**質問**:
スケジュールについて確認させてください。

**回答メモ**:
_______________________________________
_______________________________________

**マイルストーン**:
| マイルストーン | 希望時期 | 必須/調整可 | 備考 |
|--------------|---------|-----------|------|
| 要件確定 |  |  |  |
| 設計完了 |  |  |  |
| 開発完了 |  |  |  |
| リリース |  |  |  |

---

## 7. 例外・エッジケース

### 7.1 異常系の動作
**質問**:
データが取得できない場合や
エラーが発生した場合、どのように
表示すればよいでしょうか?

**シナリオ別確認**:
| シナリオ | 想定動作 | 表示内容 |
|---------|---------|---------|
| データが0件 |  |  |
| 検索タイムアウト |  |  |
| Splunk接続エラー |  |  |

---

### 7.2 境界値
**質問**:
データの上限・下限について、
確認させてください。

**例で確認**:
「例えば、通信量が極端に大きい場合
 (例: 100TB)はどう表示すればよいですか?」

**回答メモ**:
_______________________________________
_______________________________________

---

## 8. 将来の拡張性

### 8.1 今後の展開
**質問**:
今後、機能追加の可能性はありますか?
あらかじめ考慮しておいた方が
良いことがあれば教えてください。

**回答メモ**:
_______________________________________
_______________________________________

**将来機能メモ**:
- V2.0で追加したい機能: _____________
- 連携したいシステム: _______________

---

## 9. 最終確認

### 9.1 認識齟齬チェック
**私の理解の整理**:

以下が今回ヒアリングさせていただいた内容の
理解ですが、合っていますでしょうか?

1. **目的**: 
   ネットワーク異常を早期発見するための
   リアルタイム監視ダッシュボード

2. **主要機能**:
   - 通信量Top 10表示
   - 時系列グラフ
   - IPクリックで詳細表示

3. **非機能要件**:
   - 画面表示5秒以内
   - 24時間365日稼働
   - リアルタイム更新(30秒間隔)

4. **スケジュール**:
   - 設計完了: 2週間後
   - リリース: 1ヶ月後

→ この理解で進めてよろしいでしょうか?

□ Yes, この理解でOK
□ 一部修正が必要(修正内容: ___________)
□ 大きく異なる(再度ヒアリング希望)

---

### 9.2 次のアクション
**確認事項**:
- □ 次回ミーティング日時: ______________
- □ 資料提供依頼: ____________________
- □ 承認が必要な項目: ________________
- □ 設計書レビュー予定日: _____________

---

### 9.3 質問・懸念事項
**私からの確認・提案**:

現時点で、以下の点について
ご相談させていただきたいです:

1. ○○について、△△と□□の
   どちらが良いかご検討いただけますか?

2. ○○の実装には追加で○日必要ですが、
   スケジュールの調整は可能でしょうか?

---

## 10. 添付資料

□ 画面イメージ(手書き)
□ 参考URL
□ データサンプル
□ 既存システム仕様書
□ その他: _______________

---

**ヒアリング実施者サイン**: _______________
**日付**: 2025年1月21日

🎯 4. シーン別質問テンプレート

4.1 要件が曖昧な場合

【パターン1: "いい感じに"と言われた】

❌ NGな反応:
"いい感じってどういう感じですか?(イラッ)"

✅ OKな対応:
"ありがとうございます!
 具体的なイメージを共有させていただきたいので、
 例えば以下のAとBではどちらが近いでしょうか?
 
 A) シンプルで見やすい(最小限の情報)
 B) 情報量多め(詳細データも表示)
 
 または、参考になる画面イメージなどが
 あれば教えていただけると助かります!"

4.2 要件が頻繁に変わる場合

【パターン2: 前回と違うことを言われた】

❌ NGな反応:
"前回と話が違いますよね?"

✅ OKな対応:
"ありがとうございます。
 念のため確認させてください。
 
 前回のヒアリングでは○○という理解で
 進めさせていただいていたのですが、
 今回△△という新しいご要望をいただきました。
 
 こちらは、
 - 要件の変更(○○ではなく△△にする)
 - 要件の追加(○○に加えて△△も)
 どちらでしょうか?
 
 また、スケジュールへの影響について
 確認させていただいてもよろしいでしょうか?"

4.3 技術的に難しい要求の場合

【パターン3: 実現困難な要件を言われた】

❌ NGな反応:
"それは無理です"
"そんなのできません"

✅ OKな対応:
"ご要望ありがとうございます。
 
 ○○を実現する方法として、
 以下の選択肢が考えられます:
 
 【案A】完全実現(工数: +2週間、コスト: +○○円)
   メリット: ご要望通りの実装
   デメリット: スケジュール遅延
 
 【案B】部分実現(工数: +3日、コスト: +○円)
   メリット: スケジュール影響少
   デメリット: 一部機能制限
 
 【案C】代替案(工数: 変更なし)
   メリット: スケジュール通り
   デメリット: ○○の部分は△△で代替
 
 どの方向性が良いかご相談させていただけますか?"

4.4 ステークホルダーの意見が割れている場合

【パターン4: AさんとBさんで意見が違う】

❌ NGな反応:
"どっちが正しいんですか?"
"決めてください"

✅ OKな対応:
"ご意見ありがとうございます。
 
 現在、以下の2つの方向性をいただいています:
 
 Aさんのご意見:
 - ○○を優先したい
 - 理由: △△のため
 
 Bさんのご意見:
 - □□を優先したい
 - 理由: ××のため
 
 どちらも重要なご指摘と理解しております。
 
 【提案】
 両立する案として、以下はいかがでしょうか?
 - フェーズ1で○○を実装
 - フェーズ2で□□を追加
 
 または、判断基準として
 「今回のプロジェクトで最も重視するのは?」
 という観点で優先順位を決めさせていただく
 のはいかがでしょうか?"

📊 5. ヒアリング後の確認メールテンプレート

件名: 【確認】○○プロジェクト ヒアリング内容まとめ

○○ 様

お世話になっております。
YUKIKO ISHIGURO です。

本日はお時間をいただき、ありがとうございました。
ヒアリングさせていただいた内容を以下にまとめましたので、
認識に相違がないかご確認いただけますでしょうか。

---

## ヒアリング内容サマリー

### 1. プロジェクト目的
- ネットワーク異常の早期発見
- 手動監視からの脱却
- 月次レポート作成時間の50%削減

### 2. 主要機能(優先度順)
1. **Must**: リアルタイム通信量表示
2. **Should**: 異常IP自動検知
3. **Nice to have**: レポート自動生成

### 3. 非機能要件
- 画面表示: 5秒以内
- 稼働時間: 24時間365日
- 同時アクセス: 10ユーザー

### 4. スケジュール
- 設計完了: 2025年2月5日
- 開発完了: 2025年2月28日
- リリース: 2025年3月1日

---

## 確認事項・アクションアイテム

### 🔍 要確認事項
以下の点について、追加でご確認いただけますでしょうか:

1. **データ保持期間**
   現状「90日」でヒアリングしましたが、
   法的要件等で変更の可能性はありますでしょうか?

2. **アクセス権限**
   部署ごとに表示データを制限する必要は
   ありますでしょうか?

### 📋 ご提供いただきたい資料
可能であれば、以下の資料をご共有いただけると
設計がスムーズに進みます:

- [ ] 既存のネットワーク構成図
- [ ] Splunkのインデックス一覧
- [ ] ユーザーリスト(アクセス権限含む)

### 📅 次回ミーティング
- 日時: 2025年1月28日 14:00-15:00
- 議題: 詳細設計書レビュー
- 準備物: 設計書ドラフト

---

## その他

ご不明点や追加のご要望がございましたら、
お気軽にご連絡ください。

何卒よろしくお願いいたします。

---
YUKIKO ISHIGURO
Email: yukiko@example.com
Tel: 000-0000-0000

✅ 6. ヒアリングチェックリスト

実施前チェック

## ヒアリング準備チェックリスト

### 事前準備
- [ ] ヒアリングシート印刷(または画面共有準備)
- [ ] 関連資料の確認(要件定義書等)
- [ ] 質問リストの作成
- [ ] 録音・議事録担当の確認
- [ ] 時間配分の計画(60分の場合)
  - 導入: 5分
  - ヒアリング本体: 45分
  - まとめ・次回確認: 10分

### 心構え
- [ ] 相手の言葉を最後まで聞く
- [ ] メモを取りながら聞く
- [ ] わからないことはその場で確認
- [ ] 想定と違っても柔軟に対応
- [ ] 時間を守る

実施後チェック

## ヒアリング後チェックリスト

### 即日対応
- [ ] 議事録作成(24時間以内)
- [ ] 確認メール送信
- [ ] 録音データの整理
- [ ] 不明点のリストアップ

### 1週間以内
- [ ] 詳細設計書ドラフト作成
- [ ] レビュー依頼
- [ ] 追加質問の実施

### フォローアップ
- [ ] 回答待ち項目の管理
- [ ] 次回MTGの日程調整
- [ ] 関係者への情報共有

このテンプレートを使えば:
✅ 認識齟齬を最小化
✅ 角を立てずに確認
✅ 後から「聞いてない」を防げる
✅ プロフェッショナルな印象

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?