要件定義ヒアリング（非エンジニア向け）
非エンジニアが AI に小さな業務改善ツールを開発してもらう前に、機能・仕様・目的を確実に固めるためのヒアリング設計手法。すぅ AI駆動PM が考案・公開した「進捗率機能付きヒアリングプロンプト」が代表的な実装例。
なぜ小さなツールでも要件定義が必要か
「小さいから大丈夫だろう」という思い込みが最大の落とし穴。Google Apps Script・GitHub Actions・Dify/n8n などのツール開発であっても、要件定義なしに開発を依頼すると以下のリスクが生じる：
- 完成後に「思っていたものと違う」と気づく
- 「この機能がないと業務が回らない」という必須要件の漏れ
- 「APIが使えない環境だった」という技術制約の後出し
要求と要件の明確な分離
要件定義の最も重要な設計原則。
| 区分 | 定義 | 言葉 | 例 |
|---|---|---|---|
| 要求 | ユーザーのニーズ・望ましい結果 | ユーザー語 | 「週の集計を自動で終わらせたい」 |
| 要件 | 要求を技術仕様・設計方針に変換 | 設計者語 | 「週1回金曜17時に自動実行。失敗時は再実行ボタン表示」 |
要求と要件の間に差分が生じる場合は、必ず理由と代替案を明記する：
- 差分の種類：機能縮小 / 仕様変更 / 優先度変更 / スコープ外化
- 理由の型：技術制約 / セキュリティ / コスト / 運用負荷 / リスク回避
MoSCoW による優先度付け
要求の優先度を4段階で区分する：
| ランク | 意味 |
|---|---|
| M（Must） | 必須。満たせないならリリース不可 |
| S（Should） | 強く推奨。次点 |
| C（Could） | できれば含めたい |
| W（Won’t for now） | 今回は対象外（理由と再検討条件を記載） |
ヒアリングの7フェーズ構造
進捗率（全100%）とともに進行する：
| フェーズ | 内容 | 進捗率配分 |
|---|---|---|
| 1 | 解決したい問題の特定 | 20% |
| 2 | 想定ユーザーの明確化 | 15% |
| 3 | ユースケースの具体化 | 25% |
| 4 | 入出力・処理フローの定義 | 20% |
| 5 | ツール・API実現可能性調査 | 10% |
| 6 | 設定・導入・運用 | 5% |
| 7 | エラー対応・運用方針 | 5% |
進捗を可視化することで「どこまで進んでいるか」「何が残っているか」を非エンジニアでも把握できる。
課題解決保証型エージェントの設計
要求を「言われた通りに実装する」のではなく、「解決したい課題を最優先して最適な方法を提案する」設計思想。
具体的には：
- Slack API が使えない環境 → メール通知や他の通知方法を代替提案
- より簡単に実装できる方法がある → 代替実装を提示
- コストが高い場合 → 無料代替手段を提案
技術要件の実現可能性調査
要件に含めるツール・APIの実現可能性を事前調査する：
- 公式ドキュメントで機能・利用制限・料金体系を確認
- APIの機能範囲と実際の実装可能性を明確に区別する
- 技術的制約が判明した場合の代替案を事前準備
- ノーコード・ローコードツール（Dify・n8n・Make・Zapier）の活用可能性も検討
Warning
「絶対にできる」と断定できない場合は、その旨を要件定義に明記すること。確認できていない技術的実現可能性を前提にした要件定義は後の手戻りを招く。
非エンジニア向けUX設計の原則
ツールの設計自体にも非エンジニア配慮が必要：
- 設定：フォーム入力のみ（5分以内で完了）
- 操作：ボタン操作中心（1クリック実行）
- 誤操作防止：確認メッセージ＋やり直し機能
- 機密情報：Secrets機能（GitHub Secrets / Vercel環境変数 / GCP Secret Manager）に登録し、画面では存在チェックのみ
ヒアリングの基本ルール
- 一度に1項目のみ質問する（複数質問は絶対にしない）
- 「はい、わかりました」で進めず、根拠・例・比較・判断基準を求める
- あいまい語（簡単・すぐ・多い）は必ず数値・時間・頻度で定義する
- 未確定は
{TBD: ○○}として決定者・期限・判断材料を記す - 既存ファイルは参照せず、口頭回答のみをベースにヒアリングを進める
- 各質問で「不明や判断できない場合は『不明』で回答しても大丈夫」と伝える
出力物の構成
ヒアリング完了後に3つのファイルを生成する：
要求整理ファイル
- ユーザーの言葉（ユーザー語）でニーズ・望ましい結果をそのまま記載
- 要求の優先度（MoSCoW）を明記
- 未確定要求はTBDに記載（決定者・期限・判断材料）
要件定義ファイル
- 要求を技術仕様・設計方針・実装方針に変換
- 「解決したい問題→要件対応表」（解決保証）を含む
- Mermaid図による業務フロー可視化（自動/手動境界・分岐・失敗時収束点）
- UX設計方針・ツール/API調査結果を統合
議事録ファイル
- ヒアリングの全過程を時系列で省略なし記録
- 深掘り質問とその回答も完全記録
- 進捗表示の履歴をすべて記録
Cursor での実装例
プロンプトを commands/06_要件定義作成.md として保存し、/06_要件定義作成 で実行する。ChatGPT など他のAIチャットで使う場合は推論モデル（GPT-5 thinking など）が推奨される。
関連
- すぅ AI駆動PM — 手法の考案者
- 非エンジニア向け。小さい業務改善ツール開発用の要件定義ヒアリングプロンプト — ソース記事（プロンプト全文公開）
- AI駆動PM（プロジェクトマネジメント） — 上位概念
- 業務フロー設計 — ヒアリング後の成果物（Mermaid図）に接続
- Mermaid（Obsidianダイアグラム） — 業務フロー可視化で使用
- Cursor — プロンプトの主な使用環境（commands機能）
- GitHub Actions — ヒアリング対象ツールの代表例
- Notion AIレビュー自動化（要件定義） — 同著者の組織向け要件定義レビュー自動化
- 非エンジニア向けGitHub自動化 — ヒアリング対象ツールの実装先