課題が具体的、AI案がある、予算感がある、取締役が起点。
L3前後と誤認し得るAI見積システムの機能・概算提案へ進むAI見積相談：開発提案を急がない判断
課題感の強いAI相談を、情報分類・多軸診断・商談設計によって業務・データ診断へ切り替えた例。
ANONYMIZED CASE
実案件をもとに、企業・人物を特定できる情報を除き、一部の表現と数値を簡略化しています。
CONTEXT
受領時点では「AI見積システム」の相談に見えた
業種製造業系
仕様に応じた部品・工数を含む見積業務
課題見積に約1週間
リードタイム短縮への問題意識は強い
顧客側の案AIで部品を判断
具体的だが、成立条件と代替案は未確認
情報経路仲介者の報告書
顧客発言、要約、要件化が混在
最初の注意点課題認識が高く、解決案が具体的でも、それだけでは開発範囲・費用・AI適用可能性を判断できない。
MODEL COMPARISON
単一レベルでは、進んでいる情報が未判断を隠す
価値だけが先行。原因、データ、評価、実行条件、組織合意は未確認。
本開発条件は未成立ボトルネックとAI評価可能性の診断へ進む平均点を出さない理由進んでいる「課題認識」と具体的な「解決仮説」が、提案を止める未判断を相殺してしまうためです。
EVIDENCE RECLASSIFICATION
報告書の記述を、情報源・主張・確認状態へ戻す
扱い課題仮説の起点には使うが、改善効果の基準値にはしない。実案件で時間内訳を確認する。
扱い実務担当者と直近案件をたどり、探索・判断・待ち・手戻りのどこが支配的か確かめる。
扱い正式要件にしない。目的、代替案、データ、評価方法を確認するまで比較案として残す。
扱い本開発予算や期限とは扱わず、固定理由と調整可能範囲を本人へ確認する。
MULTI-AXIS ASSESSMENT
案件の現在地を領域ごとに読む
価値課題認識は高い＋
- 根拠
- 見積に約1週間という報告
- 未判断
- 時間内訳、件数、事業影響、成功条件
業務原因は仮説＋
- 根拠
- 部品選定が難しいという要約
- 未判断
- 実作業、待ち、手戻り、例外の実態
解決AI案が先行＋
- 根拠
- AI部品判断が必須との記載
- 未判断
- 利用場面、代替案、対象・対象外
実現性未調査＋
- 根拠
- データや評価方法の記載なし
- 未判断
- 見積・仕様・BOM・原価・工数の紐付き
実行条件肌感・希望のみ＋
- 根拠
- 予算感、調査段階という共有
- 未判断
- 上限、期限理由、担当体制、調整可能範囲
意思決定取締役個人が起点＋
- 根拠
- 相談開始者として記載
- 未判断
- 実務・代表・ITの関与と判断基準
顧客準備業務課題は説明可能＋
- 根拠
- 困りごととAI案は言語化されている
- 未判断
- 業務とシステム・AIの役割分担
提案を止める中核の未判断
「1週間」のボトルネック、AIが担う対象タスク、過去データの紐付き、正解と合否基準、関係者間の合意。
DIAGNOSTIC ROUTING
二つの診断を商談の中心へ置く
DIAGNOSTIC 01業務ボトルネック診断
実作業、探索、判断、転記、他部署待ち、承認待ち、手戻り、例外へ分ける。
→DIAGNOSTIC 02AI・データ実現性タスク、データ、評価、運用の4領域で、AIを評価可能な状態か確かめる。
→ボトルネック未確認
部品判断を短縮しても、最大時間が他部署待ちや手戻りなら全体は縮まらない。
AI・データ未確認
見積・仕様・BOM・原価・工数の紐付きと、正解の評価方法が分からない。
導出PoCの前に診断
検証データと合否基準を作れるか確認してから、限定PoCの可否を決める。
MEETING DESIGN
判断結果を初回商談の設計へ変える
目的
ボトルネックとAI評価可能性を確認する。
優先質問
実案件の時系列、判断基準、データの紐付き、正解と許容誤差。
扱わない・決めない
AI機能詳細、開発費、本開発スコープ、AI精度の約束。
次回参加者
見積実務担当、業務責任者・決裁者、データ・システム管理者。
依頼資料
過去見積、仕様書、BOM、実績原価・工数、改訂履歴。
終了条件
追加計測、必要データ、次回参加者、双方の宿題を担当者付きで合意する。
PROPOSAL DECISION
開発提案から、判断材料を作る提案へ切り替える
受領時の想定AI見積システムの提案
→機能、開発範囲、概算費用を提示する。
プレイブック適用後業務ボトルネック診断＋AI・データ実現性診断
原因、データ、評価方法を確認し、限定PoCへ進めるか判断する。
PLAYBOOK REVIEW
この案件で確認できた設計原則
01
課題認識と発注準備は別困っていることは、本開発を決められることを意味しない。
02
具体的な解決案ほど出所へ戻す「AI必須」は正式要件ではなく、未確認の解決仮説だった。
03
AIは評価可能性を見る出力できるかより、正しさを後から判定できるかがPoC可否を決める。
04
診断も提案の出口不確実性が価値と費用を左右するなら、判断材料を作ること自体を成果にする。
05
商談は終了条件から設計する聞けることを並べず、次回へ進むための合意から質問を逆算する。
改修前のケース評価設計思想 8.5 / 10多軸化は有効
改修前のケース評価初回商談の実務性 7 / 10根拠管理・診断・商談設計を今回補強
v0.7の再評価は次の実案件で行います。評価点を上げることではなく、誤った開発提案を止め、次の判断を一貫して導けるかを確認します。