課題も要求も曖昧
- 見立て
- 相談・構想段階。機能を決める前に、相談が生まれた背景を理解する必要がある。
- 確認
- 現状、困りごと、発生契機、放置した場合の影響、理想状態を聞く。
- 対応
- 開発見積りを急がず、調査・構想整理を提案する。
条件別対応
案件の未判断事項と顧客準備度から、ヒアリング方針を選ぶ。
CONDITIONAL PLAYBOOK
質問を増やす前に、聞く目的を決める
同じ質問票をすべての顧客に当てず、どの判断が不足しているか、誰が判断できるか、相手がどの説明粒度なら比較できるかから、聞くことと提案の着地点を変えます。
見立て
この条件が提案判断へ何を意味するか。
確認と対応
何を聞き、今回どこまで約束するか。
RULES
条件からヒアリング方針を決める
課題は曖昧、要求だけ具体的
- 見立て
- 手段が先行している可能性がある。顧客案を要求そのものとして扱わない。
- 確認
- なぜ必要か、何が改善されるか、現行手段ではなぜ不足かを掘る。
- 対応
- 顧客案・代替案・現状維持を比較し、前提検証を提案する。
予算または期限が固定
- 見立て
- 固定条件があるなら、スコープ・段階・品質・体制のどれを動かすかが中心になる。
- 確認
- 固定理由、必須成果、一部稼働の可否、調整可能な条件を確認する。
- 対応
- 段階導入と、選択によって生じる費用・品質・運用リスクを示す。
決裁者・現場利用者が不在
- 見立て
- 聞けた内容を組織合意や業務事実として確定できない。
- 確認
- 参加者の決定範囲、決裁者の判断基準、現場確認の方法を確認する。
- 対応
- 仮定を明示し、次回は決裁者または現場を含む確認の場を設ける。
顧客のシステム理解が限定的
- 見立て
- 要件を質問だけで引き出すことは難しく、暗黙の期待が受託側へ集まりやすい。
- 確認
- 専門用語を業務上の出来事へ翻訳し、少数の選択肢を具体例で確認する。
- 対応
- プロトタイプと段階確認を挟み、判断事項・未判断事項を記録する。
担当者は詳しいが決裁者は詳しくない
- 見立て
- 実務ヒアリングは進んでも、提案内容が社内決裁へ伝わらない可能性がある。
- 確認
- 担当者向けの詳細と、決裁者の判断基準を分けて確認する。
- 対応
- 決裁者向けの価値・費用・リスクと、実務向け詳細の二層で提案する。
技術的実現性が不明
- 見立て
- 外部連携、AI精度、データ移行などが費用と成立性を左右する。
- 確認
- 仕様書、データ量、利用条件、検証可能な成功基準を確認する。
- 対応
- 本開発を確約せず、技術調査・接続検証・PoCを先行させる。
COMBINATION
実案件では条件を組み合わせる
例：課題は強い × AI案が先行 × データ不明 × 取締役個人が起点
初回の目的を機能確定や開発費確定にせず、ボトルネック、AI案の背景、過去データ、関係者構造の確認に置きます。本開発提案ではなく、業務・データ診断または限定PoCを次の候補にします。
DIAGNOSTIC ROUTING