開発ブリーフ - 発注者への 15 の質問

良い開発ブリーフは、何週間ものやり取りを省き、「ついでにこれも」から予算を守ります。基本的な質問への答えがないと、チームは要件を推測し、発注者は工期と価格に驚きます。以下は、見積もりとキックオフの前に聞くべき 15 の質問です。答えはアイデアをウィッシュリストではなく、明確なスコープに変えます。

• ブリーフの目的 - 目標、境界、成功基準を固定する
• いつ聞くか - 提案書の前、キックオフの前
• 誰が答えるか - 意思決定者とプロダクトオーナー。「みんな少しずつ」ではない
• 得られるもの - 明確なスコープ、現実的な工期、透明な予算
• ルール - 答えがない = 手戻りと隠れコストのリスク

なぜ開始前にブリーフを集めるのか

サイト、サービス、連携の開発は、コードではなく不確実性で止まりがちです。目標が曖昧で、優先順位が毎週変わり、「must-have」が終盤に出る - 工期とコストは膨らみます。

ブリーフは官僚作業ではありません。プロジェクトの意味に関する短い契約です：何を、誰のために、どんな結果へ、どんな制約の下で。これらの質問を早く閉じるほど、見積もりは正確になり、双方は落ち着きます。

発注者への 15 の質問

1. 解決するビジネス課題は何か？

「サイトが必要」ではなく、今何が痛いか：リード不足、依頼の混乱、手作業、古いカタログ。課題がアーキテクチャと機能優先を決めます。

2. ターゲット層は誰で、主なシナリオは何か？

ユーザーは誰か：B2B購買、小売顧客、社員、パートナー。主要なシナリオ1つは、副次的な10個より重要です。

3. プロジェクト成功をどう判断するか？

測定可能な基準が必要です：リード数、コンバージョン、注文処理時間、エラー削減、コンテンツ公開速度。KPIがなければ「完了」は主観のままです。

4. 工期は？厳しいデッドラインはあるか？

展示会、季節、製品リリース向けのローンチは計画を変えます：今MVPか、後で全体スコープか。優先なしのデッドラインは、だいたい手戻りを意味します。

5. 現実的な予算レンジは？

予算の幅は、非現実的なスコープを早期に切る助けになります。数字のない「だいたい安く」より、正直なレンジの方が良いです。

6. 既にあるものは？サイト、CRM、ERP、API、コンテンツ

棚卸しは費用を節約します。稼働中CRMの連携やカタログ移行は別ボリュームであり、「最後の些細な作業」ではありません。

7. ローンチ時に必須の連携は何か？

決済、倉庫、1C/ERP、メール、分析、メッセンジャー。連携リストは、フレームワーク選定より工期に強く影響します。

8. スタック、ホスティング、セキュリティの制約はあるか？

社内標準、オンプレミス、情報セキュリティ要件、クラウド禁止 - これらはベンダー選定後ではなく、見積もり前にブリーフへ入れるべきです。

9. 誰が意思決定し、誰が工程を承認するか？

意思決定者が1人だとプロジェクトは速く進みます。承認が5部門を通りオーナーがいない場合 - 待機と意見変更のバッファを見込んでください。

10. v1のmust-haveは何か、後回しにできるものは？

「ローンチに必要」と「後で欲しい」を分けます。核が明確なMVPは、「全部いっぺんに」より早く価値を出し、安く済みます。

11. 「こうあるべき」参照と「こうであってほしくない」反例はあるか？

サイトや製品のリンクは、UXとトーンの議論を何時間も節約します。反例も有用です：好みと期待の境界を示します。

12. コンテンツ、文言、写真、アクセス権限は誰が用意するか？

コンテンツはしばしばボトルネックになります。文言やサービスアクセスが遅れると - デザインと開発は停止します。

13. 必要なユーザー役割とアクセスレベルは？

ゲスト、顧客、マネージャー、管理者、パートナー - 画面と権限が異なります。画面設計の前に役割モデルを書いてください。

14. 法務、個人データ、業界要件はあるか？

GDPR / 各国のプライバシー法、医療、金融、公共部門 - 保存設計、同意、ログ、契約を変えます。「後から追加」はできません。

15. ローンチ後のプロダクトサポートは誰が担うか？

更新、監視、コンテンツ修正、インシデント対応。計画にサポートがなければ - 稼働中プロダクトは早く古くなります。

答えを実務でどう使うか

答えを1ページに要約します：

この表から提案書とロードマップを作りやすくなります。空欄があるなら - 「後で細かく」ではなく、未解決リスクです。

ブリーフの典型的な失敗

• 願望（「きれいにして」）と成果（「リードを30%増やす」）を混同する。
• 連携を「ボタン1つ」扱いし、独立作業として見ない。
• 発注者側のプロダクトオーナーを置かない。
• 優先順位なしでバックログ全体をmust-haveにする。
• サポートを無視する：サポートオーナーなしのローンチは初日から負債です。

まとめ

開発ブリーフは、目標、対象、KPI、工期、予算、連携、制約、役割、サポートについての短くても厳格な15の質問です。開始前の答えが充実するほど、見積もりは正確になり、途中のサプライズも減ります。

ブリーフ作成、MVPの優先順位付け、答えに基づく開発見積もりが必要なら - ご連絡ください。

よくある質問

ブリーフ記入にはどれくらいかかりますか？

通常は営業日1-2日です。意思決定者と基本データへのアクセスがあれば可能です。意思決定が部署に分散している場合は難しくなります。そのときは数週間のメールより、1-2時間の短いワークショップが有効です。

ブリーフなしで見積もれますか？

「から〜まで」の幅は出せますが、精密な金額は出せません。 目標、連携、成功基準がなければ、見積もりはほぼ必ずぶれます。ブリーフは不確実性を減らし、双方を誤った期待から守ります。

ブリーフは技術仕様書の代わりになりますか？

いいえ - ブリーフは仕様書への入力です。 意味と境界を固定します。仕様書は画面、データ、API、役割、受入基準を記述します。ブリーフがないと、仕様書は肥大化し途中で変わりがちです。

発注者が予算を知らない場合は？

幅とスコープ案を提示してください： MVP / 標準 / 拡張。現実的なスコープを選びやすくなります。「予算無制限」は実務上、ほぼ常に優先順位が未整理であることを意味します。

開発中にブリーフを更新すべきですか？

はい。目標、デッドライン、must-haveが変わったときです。 ブリーフは生きた境界ドキュメントです。スコープ拡大は工期か予算を明示的に変える必要があります。そうでなければチームは借金で働きます。