システム受託プレイブック
⌘ K

プレイブックの使い方

案件資料を受け取った時点から、次のヒアリングと出せる提案を判断するためのナレッジです。

PURPOSE

質問集ではなく、判断の道具として使う

課題感が強いことと、本開発を提案できることは同じではありません。価値・業務・解決・実現性・実行条件・意思決定の現在地を分け、情報源・主張の種類・確認状態を確かめて、次の商談で何を明らかにするかを決めます。

中心となる問いいま何が分かっていて、何をまだ提案条件として使えないのか。

WORKFLOW

資料受領から提案選択までの流れ

  1. 01
    情報を分ける

    発言・記述ごとに、情報源、主張の種類、確認状態を記録する。

  2. 02
    案件の現在地を読む

    領域ごとの状態と不足している判断を整理する。

  3. 03
    必要な診断を選ぶ

    業務原因が曖昧ならボトルネック、AI案があるならAI・データ実現性を確認する。

  4. 04
    相手に合わせる

    顧客準備度、ポジション、判断スタイルから聞き方と見せ方を変える。

  5. 05
    商談を設計する

    目的、優先質問、扱わない・決めないこと、参加者、資料、終了条件を一枚にする。

  6. 06
    提案タイプを選ぶ

    商談で確認できた範囲に合わせ、次に約束できる成果を決める。

CORE PRINCIPLES

変えない基本原則

01

共通レベルに揃えない課題・要求・予算・顧客理解は、それぞれ固有の状態で表します。

02

領域の状態と情報の確認状態を分ける「要求が具体的」と「その要求が根拠確認済み」は別の情報です。

03

案件フェーズは導出する平均点ではなく、中核となる未判断事項から提案可能範囲を決めます。

04

顧客理解は人ごとに見る担当者、現場、決裁者では理解と判断可能範囲が異なります。

05

仮説を正式要件へ昇格させない具体的な解決案ほど、誰の案で、何を根拠に、誰が合意したかを確かめます。

KNOWLEDGE MAP

判断したいことからページを選ぶ