「カスタマーサポート用の AI チャットボットを構築する必要があります。」
聞き覚えがありますか？これはプロジェクトを始める間違った方法です。そして、チームが構築を完了してもビジネスがまだ満足しない最大の理由です。
優れた BA はソリューションから始めません — 彼らは問題から始めます。
1. 問題、症状、ソリューション — 三つの異なるもの
この違いを理解することがあらゆるビジネス分析の基盤です：
| 例 | |
|---|---|
| 症状 | 「顧客がソーシャルメディアで多く不満を言っている」 |
| 問題（根本原因） | 「チケットの平均解決時間が4日で、競合他社の2倍」 |
| ソリューション | 「シンプルなチケットの60%を自動処理する AI チャットボットを構築する」 |
多くの BA がステークホルダーから症状を受け取り、実際の問題を分析するステップを飛ばしてソリューションに直接飛びつきます。
結果：間違った問題に対して正しいソリューションを構築する。
2. SCQ フレームワーク — 効果的な問題ステートメントの構造
McKinsey は問題をフレーミングするために Situation → Complication → Question フレームワークを使用しています。BA への応用：
Situation（現状）
現在の状態、誰が影響を受けているか、規模を説明する。
「カスタマーサポートチームは現在15名のエージェントで1日2,000件のチケットを処理しています。」
Complication（問題点）
何が起きているかを正確に指摘する、データがあれば含める。
「初回解決率（FCR）は45%しかなく、業界ベンチマークの70%を大きく下回っています。各チケットは平均1.8回の再作業が必要です。」
Question（答えるべき質問）
方向性に向けて質問を提示する — 所定の答えではなく。
「ヘッドカウントを増やさずに Q3 までに FCR を ≥ 65% に引き上げるにはどうすればいいか？」
3. チェックリスト：良い問題ステートメントに必要なもの
書いた後に確認してください：
- 測定可能なデータが含まれている（%、$、日数、回数など）
- ビジネスへの影響を説明している（症状だけでなく）
- 特定のソリューション名が含まれていない
- ステークホルダーに読んで聞かせたとき、彼らの問題であることに同意できる
- 誰が影響を受けているかとどの規模でが特定されている
4. 実例：正しくフレーミングする前後
❌ 前（ソリューションファースト）
「顧客オンボーディングプロセスに AI を統合して自動化する必要があります。」
✅ 後（問題ファースト）
「最初の7日間のオンボーディング完了率は38%しかなく、目標の60%を下回っています。分析によると、62%の顧客が書類確認ステップで離脱しており、手動プロセスに2〜3日かかるためです。目標は確認時間を4時間以内に短縮し、Q2 までに完了率を55%に改善することです。」
5. 根本原因に到達するための「5つのなぜ」
要求を受け取ったとき、「なぜ？」を5回聞く：
- 「チャットボットを構築する必要がある」→ なぜ？ → 「サポートチームが過負荷になっているから」
- 「サポートチームが過負荷」→ なぜ？ → 「チケット量が6ヶ月で40%増加したから」
- 「チケット40%増加」→ なぜ？ → 「新製品が多くの UX バグとともにリリースされたから」
- 「多くの UX バグ」→ なぜ？ → 「ローンチ前にユーザビリティ調査が行われなかったから」
真の問題： ユーザーリサーチの欠如であり、チャットボットの欠如ではありません。
5 つのなぜを使うと、本当のソリューションが当初の要求よりもずっとシンプルで安価であることを発見できるかもしれません。
6. AI の文脈における問題フレーミング
AI 機能については、もう一層のフレーミングを加えます：AI は本当に必要か？
AI ソリューションの構築に同意する前に、BA は次のことを質問しなければなりません：
- この問題はよりシンプルなルールベースのロジックで解決できないか？
- AI を学習/ファインチューニングするためのデータが利用可能で十分な品質があるか？
- AI が間違えた場合、ユーザーとビジネスへの影響はどうか？
- 従来のソリューションと比較した AI の ROI はどれくらいか？
AI が常に正解というわけではありません。そして BA はこれらの質問をすることを期待されている人物です。