ストーリー
田
田中VPoE
「ロードマップのPhase 1で取り組むFAQ自動回答が決まった。しかし、実際に着手する前にフィージビリティ(実現可能性)を評価する必要がある。」
あなた
「ここまでの分析で実現可能だとわかっているのでは?」
あ
田
田中VPoE
「Step 3での評価は概要レベルだ。フィージビリティ評価では、技術的・ビジネス的・運用的な実現可能性をより詳細に検証する。ここで無理があるとわかれば、計画を修正する最後のチャンスだ。」
あなた
「着手する前の最終チェックということですね。」
あ
田
田中VPoE
「そうだ。技術的実現性、ビジネス実現性、運用実現性の3つの観点で評価しよう。」
フィージビリティ評価の3つの観点
フィージビリティ評価
├── 1. 技術的実現性(Technical Feasibility)
│ └── この技術で本当に実現できるか
├── 2. ビジネス実現性(Business Feasibility)
│ └── 予算・期間・人員の制約内で実現できるか
└── 3. 運用実現性(Operational Feasibility)
└── 導入後に安定的に運用できるか
1. 技術的実現性
評価項目
| 項目 | 評価ポイント | 判断基準 |
|---|
| AI技術の成熟度 | 選択した技術は十分に成熟しているか | 類似事例が複数存在する |
| データの十分性 | 必要なデータが量・質ともに確保できるか | PoC開始に必要な最低限のデータがある |
| 精度の見込み | 業務要件を満たす精度が達成できるか | 類似ケースの精度実績がある |
| システム統合 | 既存システムとの連携が技術的に可能か | API等の連携手段がある |
| インフラ要件 | 必要なインフラが調達可能か | クラウドサービスで対応可能 |
NetShop社FAQ自動回答の技術的実現性
| 項目 | 評価 | 根拠 |
|---|
| AI技術の成熟度 | ○ | RAGベースのFAQチャットボットは多数の実績あり |
| データの十分性 | ○ | FAQ 200件+問い合わせログ30万件がZendeskに蓄積 |
| 精度の見込み | △ | カテゴリ分類の整理が必要。整理後は85%以上の精度が見込める |
| システム統合 | ○ | Zendesk APIで連携可能、ECサイトへのチャットウィジェット埋め込みも容易 |
| インフラ要件 | ○ | GCPの既存環境を活用可能 |
2. ビジネス実現性
評価項目
| 項目 | 評価ポイント | 判断基準 |
|---|
| 予算 | 必要な投資額が確保済みか | 年間AI予算の範囲内 |
| 期間 | 目標期限内に実現可能か | マイルストーンが現実的 |
| 人材 | 必要なスキルを持つ人材がいるか | 社内または外部で確保可能 |
| ROI | 投資に見合うリターンが見込めるか | ROIがプラス |
| ステークホルダーの合意 | 関係者の承認が得られるか | スポンサーが確保できている |
NetShop社FAQ自動回答のビジネス実現性
| 項目 | 評価 | 根拠 |
|---|
| 予算 | ○ | Phase 1予算800万円は年間予算3,000万円の27% |
| 期間 | ○ | 3ヶ月で実現可能(類似プロジェクトの実績あり) |
| 人材 | △ | ML経験者1名では不十分。外部パートナーの活用が必要 |
| ROI | ○ | 年間2,520万円の削減効果、ROI 68% |
| ステークホルダー | ○ | CS部長がスポンサー、社長も支持 |
3. 運用実現性
評価項目
| 項目 | 評価ポイント | 判断基準 |
|---|
| 運用体制 | 導入後の保守運用体制があるか | 担当者と責任範囲が明確 |
| モニタリング | AIの性能を監視する仕組みがあるか | ダッシュボードと閾値が設定可能 |
| 障害対応 | AI障害時の代替手段があるか | フォールバック手順が定義済み |
| 継続改善 | AIの精度を継続的に改善する仕組みがあるか | フィードバックループの設計 |
| ユーザーサポート | 利用者からの問い合わせに対応できるか | サポート体制の構築 |
NetShop社FAQ自動回答の運用実現性
| 項目 | 評価 | 根拠 |
|---|
| 運用体制 | △ | AI推進チーム3名で対応可能だが、夜間対応は未定 |
| モニタリング | △ | GCPのモニタリングツールを活用可能。ダッシュボード設計が必要 |
| 障害対応 | ○ | 有人チャットへの切り替えフローを設計済み |
| 継続改善 | △ | ユーザーフィードバックの収集仕組みを構築する必要あり |
| ユーザーサポート | ○ | CS部のリーダーが社内サポートを担当 |
フィージビリティ総合判定
判定基準
| 判定 | 基準 |
|---|
| Go | 3観点すべてが○、または△が1つ以下 |
| Conditional Go | △が2つ以上だが、対策により解消可能 |
| No Go | ×が1つ以上、または△が3つ以上で対策困難 |
NetShop社FAQ自動回答の総合判定
| 観点 | 判定 | 主な課題 |
|---|
| 技術的実現性 | ○(△1つ) | データ整理が必要 |
| ビジネス実現性 | ○(△1つ) | 人材の外部調達が必要 |
| 運用実現性 | △(△3つ) | 運用体制・モニタリング・改善の仕組み構築が必要 |
総合判定: Conditional Go
条件:
- カテゴリ分類の整理をPhase 1の最初の1ヶ月で実施
- 外部パートナー(RAG構築の経験者)を確保
- 運用設計をPoC段階で並行して策定
フィージビリティ評価のテンプレート
| 項目 | 内容 |
|---|
| ユースケース名 | (評価対象のユースケース) |
| 技術的実現性 | ○/△/× と根拠 |
| ビジネス実現性 | ○/△/× と根拠 |
| 運用実現性 | ○/△/× と根拠 |
| 総合判定 | Go / Conditional Go / No Go |
| 条件(Conditional Goの場合) | (必要な条件のリスト) |
| 推奨アクション | (次に取るべきアクション) |
まとめ
| 項目 | ポイント |
|---|
| 3つの観点 | 技術的・ビジネス的・運用的実現性を総合評価 |
| 技術的実現性 | 技術の成熟度、データ、精度、システム統合 |
| ビジネス実現性 | 予算、期間、人材、ROI、ステークホルダー合意 |
| 運用実現性 | 運用体制、モニタリング、障害対応、継続改善 |
| 総合判定 | Go/Conditional Go/No Goの3段階で判断 |
チェックリスト
次のステップへ
次は「PoC設計」として、フィージビリティ評価を通過したユースケースのPoC計画を具体的に設計しよう。
推定読了時間: 30分