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

提案判断マップ

各領域の現在地から「足りない判断 → 次のヒアリング → 出せる提案」を導く。

案件を一つの成熟度で表さない

課題は確認済みでも、実現性は未調査、予算は希望のみというように、各領域は異なる順序で進みます。案件全体をL1〜L4へ置くのではなく、領域ごとの状態を並べて現在地を読みます。

判断領域

何が分かり、何が未判断かから、聞く内容と提案の種類を決める。

確認状態

その判断材料を、どこまで提案条件として信頼できるかを記録する。

DECISION AREAS

領域固有の現在地を見る

左から右へ機械的に進めるのではなく、いまどの状態で、提案に必要な何が不足しているかを見ます。

価値なぜ取り組むのか
困りごとが出ている影響が分かっている原因仮説がある実態を確認している優先度が決まっている

ヒアリングの勘所課題の大きさではなく、何が変われば取り組む価値があるかを確認する。

業務誰のどの業務を変えるのか
対象者候補がいる通常業務が分かる例外と頻度が分かる現場で確認している変更後の役割が決まっている

ヒアリングの勘所説明だけで確定せず、現場・実データ・例外処理まで確認する。

解決何をどこまで実現するのか
要望が出ている利用場面が分かるユースケースが整理されている優先順位がある対象・対象外が決まっている

ヒアリングの勘所機能名ではなく、利用場面・優先理由・対象外を明らかにする。

実現性技術・データ・運用上成立するか
未調査懸念が判明している検証事項が決まっている調査・PoC中成立条件を確認している

ヒアリングの勘所中核の不確実性が残る場合は、本開発ではなく調査やPoCを出口にする。

実行条件予算・期限・体制が成立するか
条件未確認希望が出ている理由と制約が分かる調整可能範囲が分かる実行条件が確保されている

ヒアリングの勘所予算と期限を単独で聞かず、変えられる条件と変えられない条件を確認する。

意思決定誰が何を基準に決めるのか
窓口がいる関係者が分かる決裁者が分かる判断基準と過程が分かる判断できる場が整っている

ヒアリングの勘所担当者の理解と組織の合意を分け、誰がどこまで決められるかを確認する。

CASE SNAPSHOT

案件の現在地を組み合わせて読む

状態名だけでなく、根拠・未判断・次の一手を一緒に記録します。以下はAI見積相談を簡略化した例です。

価値課題認識は高い
根拠
見積作成に約1週間かかるという報告
未判断
時間の内訳と事業影響
次の一手
処理時間・待ち時間・手戻りを分ける
業務原因は仮説
根拠
部品選定が難しいという要約
未判断
実際のボトルネックと例外
次の一手
実務担当者と実例を確認する
解決AI案が先行
根拠
AIによる部品判断が必須との記載
未判断
代替手段との比較と利用場面
次の一手
正式要件とせず解決仮説に戻す
実現性未調査
根拠
利用可能な過去データは未確認
未判断
データの存在・紐付き・評価方法
次の一手
データ診断の要否を確認する
実行条件希望のみ
根拠
予算感と調査段階という共有
未判断
上限、時期の理由、体制
次の一手
固定条件と調整可能範囲を確認する
意思決定個人起点
根拠
取締役が相談を開始
未判断
実務・代表・ITの合意と判断基準
次の一手
関係者と次回参加者を特定する

DERIVED DECISION

進んでいる領域より、提案を止める未判断を見る

この例からの判断

課題認識は高い一方、原因、データ、評価方法、組織合意が未確認です。AI見積システムの本開発へ進まず、ボトルネックとAI適用可能性を確認する診断・検証提案へ切り替えます。

  • 課題が深いことを、解決策の正しさの根拠にしない。
  • 具体的な要望があっても、情報源と確認状態を確かめる。
  • 本開発に必要な中核条件が未確認なら、調査・PoCを次の意思決定にする。