01
発注判断メモ
目的、対象者、対象業務、制約、確認すべき問いを1枚に整理します。
01 SYMPTOMS
こういう状態なら、ここから入る
01
社内では必要性がありそうだが、何を作るかを一文で説明できない
02
複数社の見積もりが、範囲も前提も違って比較できない
03
画面、業務フロー、データ、権限の話が会議ごとに入れ替わる
02 MATERIALS
初回相談で返すもの
提案資料だけで終わらせず、社内説明や見積もり比較に使える形へ戻します。
02
受入条件のたたき台
画面や機能の話を、検収時に確認できる条件へ落とします。
03
概算レンジの前提
金額だけでなく、何を含み何を含まないかまで比較できる形にします。
03 RTB
本当に任せてよいかを見る材料
抽象的な強みではなく、この相談場面で見るべき証拠を置きます。
成果物サンプル
発注判断メモ
目的、業務、利用者、制約、受入条件を同じ紙面に置きます。
判断材料
受入条件
何ができたら十分かを、見積もり前に確認できる粒度へ落とします。
次に確認すること
不足情報リスト
発注者側で確認すべき社内事情、データ、承認条件を残します。
実案件ログ
議事録から、1日で確認用デモへ
発注前のヒアリング内容を、画面で確認できる検証用プロトタイプへ落とし込みました。
- 会話の断片を業務フローと画面単位に整理
- 確認すべき問いをデモで見られる状態へ変換
- 次回打ち合わせで不足情報を確認できる資料として使用
04 CONDITIONS
見送り条件も先に置く
相談者側が社内で判断しやすいように、今すぐ着手しない条件も言語化します。
01
利用者や決裁者がまだ特定できていない
02
業務量や発生頻度が分からず、投資判断の前提が置けない
03
既存システムやデータの制約が確認できていない
05 SERVICES