プロジェクト企画書1枚
なぜやるか、何を出し、どう成功を測るか
以下の背景を、1枚のプロジェクト企画書に整理してください。順序：1）課題（誰が、どんな場面で、いくらの損失か。数字で示す）；2）やらない場合に何が起きるか；3）目標と非目標（各3つ以内）；4）進め方（5ステップ以内）と最大のリスク；5）成功指標（ベースライン→目標→測定時期）；6）必要なリソースと意思決定ポイント。1枚に収め、ビジョンや形容詞は削り、「体験を向上させる」のような検証できない目標は書かないこと。 [背景] [リソース制約]
使い方
企画書が必ず耐えなければならない問いは「何をやらないか」と「何をもって失敗とするか」。この二つがない1枚は、願望リストです。
向いている場面
- 四半期計画で限られた開発リソースを奪い合う。レビューの前に、なぜやる価値があるのか、何をもって成功とするかを1枚で示す必要がある。
- 部門横断のプロジェクトで、プロダクト、開発、法務の認識が揃わない。「完成」のイメージが人によって違い、会議が長くなる一方。
向いていない場面
- 探索的な調査で、方向性がまだ固まっていない段階。指標と非目標を固定すると試行錯誤の余地を潰すので、まず小規模な検証をします。
- すでに承認済みで実行中の通常の反復開発。もう一度企画書を書くのは二重の手続きなので、スケジュールと受け入れ条件を書けば足ります。
例
入力
客服は週に約600件の「請求書の宛名間違い」チケットを処理し、1件平均18分。財務によると3割は顧客が提出時に税番号を選び間違えたもの。セルフ修正画面を作りたい。開発は2人×6週間を投入できる。
得られるもの
最初の段落は課題と損失だけにし、週600件×18分で約180時間、その3割が税番号の選択ミスだと書きます。目標は「セルフ修正率60%以上、チケットを週240件まで削減、公開後4週間で測定」とし、非目標として請求フローと税務当局との連携には触れないと明記します。進め方は5ステップ以内、最大リスクは税番号の検証が外部 API に依存することで、リソースは2人×6週間と書き、財務が2週間以内にルールを確定する意思決定ポイントを添えます。
よくある誤用
- 冒頭に「事業の急速な成長に伴い」と書く。レビューする人には課題が見えず、テンプレートを埋めているだけに映ります。
- 成功指標を「効率向上、問い合わせ削減」と書く。ベースライン、目標値、測定時期がなく、公開後に続けるべきか判断できません。
こう変えると効く
- 「リソースが半分しか出ないなら、どちらを削るか」を足す。レビューでは「人が足りない」より説得力があります。
- 「公開後にどんなシグナルが出たら中止するか」を足し、サンクコストになる前に撤退条件を決めます。