アプリ開発の企画書は、思いついた機能を承認してもらうためだけの書類ではありません。
誰のどの行動を変えるか、初版で作らないものは何か、どの観察結果なら企画を変えるかを関係者で共有する判断記録です。
一枚目で課題と投資判断を示し、後ろに調査計画、画面の試作品、費用と日程を必要なだけ加えます。
企画書を持ち込む相談先に迷う方へ、目的別の無料相談ガイドでは相談テーマに合う相手と用意する資料を整理しています。
| 一枚目で答える問い | 書けなければ戻る場所 |
|---|---|
| 誰がいつ困るか | 行動観察と聞き取り |
| 何が今より変わるか | 現在の手順と負担の測定 |
| 初版でどこまで作るか | 中心操作と範囲外の決定 |
| 何を見て続行するか | 成功指標と中止条件 |
企画書は決定と変更の理由を残す
良い企画書は完成形を断言するのではなく、現時点の根拠と次に変える条件を分けます。
経営者には投資額と期待する変化、開発者には中心操作と制約、運用者には更新対象と問い合わせ責任が必要です。
読み手ごとに別の企画を作らず、一つの課題文からそれぞれの判断へつながる構造にします。
会議で決まった変更には日付、根拠、影響する範囲を添えます。
後から機能が増えた理由を追えることが、企画書を保守する価値です。
一枚目には誰のどの瞬間かを書く
「社内の情報共有を効率化する」だけでは、対象者も開始条件も測れません。
「店舗責任者が閉店後に紙の在庫数を本部へ転記する三十分を、入力と送信の十分へ短縮する」と書きます。
英国政府のユーザーニーズ調査指針は、利用者がサービスで達成したい結果を理解し、解決策ではなく課題へ焦点を当てる考え方を示しています。
課題文には対象者、起きる場面、現在の行動、負担、望む結果を入れます。
アプリ名やAIなどの手段は、課題文が固まるまで見出しへ置きません。
企画書テンプレートは八項目で埋める
項目の順番は、作るものより作る理由を先にします。
- 対象者と利用場面
- 現在の手順と困りごと
- アプリで変える結果
- 初版の中心操作
- 初版で作らない範囲
- 成功指標と測定期間
- 調査、開発、公開の担当
- 費用、日程、中止条件
各項目を一文で埋め、説明できない欄だけ調査へ戻します。
空欄を推測で埋めるより、「未確認」と書いて担当者と確認日を置くほうが判断に使えます。
画面一覧や技術構成は、八項目から必要性を説明できるものだけを別紙にします。
在庫確認アプリの記入例で粒度をそろえる
企画名だけでは伝わらないため、同じ例を八項目へ通します。
| 項目 | 記入例 |
|---|---|
| 対象者 | 毎日閉店後に在庫を報告する店舗責任者 |
| 現在の負担 | 紙から表計算へ転記し本部へメールする三十分 |
| 変える結果 | 商品ごとの数を一度入力して本部へ送れる |
| 初版 | 商品選択、数量入力、送信、送信済み一覧 |
| 範囲外 | 発注予測、会計連携、一般顧客向け画面 |
| 成功指標 | 四店舗の試用で報告時間の中央値を測る |
| 運用担当 | 本部が商品一覧を更新し店舗の質問を受ける |
| 中止条件 | 報告時間が減らず入力ミスが増える場合 |
Digital.govのプロトタイプ作成指針を使い、商品選択から送信までを紙の画面で具体化してから開発規模を見積もります。
利用者理解に関する英国政府の資料へ照らし、店舗責任者だけでなく商品一覧を更新する本部担当者の用事も企画へ含めます。
調査計画を企画書の中へ埋め込む
企画書の根拠が「担当者の経験」だけなら、反対意見が出たときに検証できません。
答える問い、対象者、方法、実施日、記録場所、判断日を一つの表へします。
英国政府のユーザー調査計画は、調査目的、対象グループ、方法を定め、学びに応じて計画を更新する進め方を案内しています。
在庫確認の例なら「閉店後のどの工程に最も時間がかかるか」を四店舗で観察し、紙の試作品を使う前後の手順を記録します。
調査計画の公式解説にある研究課題の優先付けを参考に、企画の続行判断へ使わない質問は今回の調査から外します。
紙の画面で反対意見を早く集める
文章だけの企画書は、読む人が別々の画面を想像します。
入力、確認、完了の三画面を紙で作り、店舗責任者と本部担当者に役割どおり操作してもらいます。
Digital.govのプロトタイプ解説が示すように、試作品は設計案を早く試し、判断に必要な反応を得るために使えます。
「分かりやすいですか」と聞かず、商品を選び送信を取り消すところまで依頼して迷いを観察します。
試作で変えた項目は企画書の課題、範囲、指標のどれへ影響したかを記録します。
要件定義へ渡す前に未決事項を分離する
企画書は作る価値と範囲を決め、要件定義書は動作や品質を実装できる粒度へ落とします。
「使いやすい画面」という企画上の希望は、要件定義で「店舗責任者が三操作以内に送信できる」といった受入条件へ変えます。
未決事項は本文へ紛れ込ませず、担当者、期限、決まらない場合の代替案を一覧にします。
技術選定、外部サービス、個人情報、既存システム連携は、見積もりへの影響が大きい順に解決します。
要件定義へ渡した後も、対象者や成功指標が変わったら企画書の版を更新します。
アプリ開発の企画書に関するよくある質問
アプリ開発の企画書には何を書きますか？
対象者、利用場面、現在の課題、変えたい結果、初版の中心操作、作らない範囲、成功指標、担当と費用を記載します。
調査で未確認の項目には担当者と確認日を置き、根拠が得られた時点で版を更新します。
企画書と要件定義書の違いは何ですか？
企画書はなぜ作るか、誰の何を変えるか、投資を続ける条件を共有する資料です。
要件定義書は企画の範囲を受け、機能、データ、性能、安全性、運用、受入条件を実装可能な形へ具体化します。
テンプレートをそのまま使ってもよいですか？
項目の漏れを防ぐ土台として使えますが、不要な欄を埋めること自体を目的にしません。
企画固有の対象者、利用場面、作らない範囲、成功指標、中止条件を具体的に書き、判断へ使わない欄は削ります。
課題と範囲外と変更条件が企画書を締める
企画書は機能を多く見せる資料ではなく、作る理由と作らない境界と検証後の選択を同じ場所へ残す資料です。
- 一枚目は対象者の困る瞬間から始める
- 初版の中心操作と範囲外を対にする
- 成功指標には測定期間と中止条件を添える
- 試作品で変えた理由を企画書の版へ戻す
企画書の前提となる課題候補がまだ絞れない場合は、アプリ開発のアイデアを出す方法の行動採集から始めると根拠を集められます。
