「開発会社に相談したい。でも、何をどこまで決めてから話せばいいのか分からない。」そう感じているなら、それは準備不足ではありません。
作りたいものがまだ言葉になっていない段階では、費用も、期間も、必要な機能もぼんやりして見えます。むしろ、そのぼんやりした状態を整理するために初回相談があります。
この記事は、完璧な仕様書を作るためのものではありません。相談前に「ここまで考えておけば話が進みやすい」という材料を、15項目に分けて整理するためのチェックリストです。
相談前に不安になるのは自然です
「こんな状態で相談しても、ちゃんと見積もってもらえるのかな」
開発会社に声をかける前は、不安が出やすいです。作りたいものの名前はあるけれど、機能を書き出すと急に難しくなる。参考サービスはあるけれど、自社に必要な範囲が分からない。予算を先に言うべきか、相場を聞くべきかも迷う。
特に初めての開発外注では、「要件をまとめてください」と言われても、その要件が何を指すのか分かりにくいものです。画面の数なのか、機能の一覧なのか、業務フローなのか、デザインなのか。全部を最初からきれいに揃えようとすると、相談する前に手が止まってしまいます。
でも、最初に必要なのは完璧な資料ではありません。開発会社が「何を確認すれば見積もりや提案に進めるか」を判断できる材料です。未決のままでよい項目もあります。仮置きで進められる項目もあります。相談の中で一緒に詰めた方がよい項目もあります。
この記事では、開発会社に相談する前の整理を「決め切る作業」ではなく、相談の質を上げるための下準備として扱います。
まず押さえたい考え方
開発外注前の準備で大事なのは、すべてを細かく決めることではありません。むしろ、決めるべきことと、相談しながら決めることを分けることです。
最初に見ておきたいのは次の3つです。
- 何のために作るのか
- 最初に誰が使うのか
- どこまで作れば最初の価値を確認できるのか
この3つが曖昧なままだと、開発会社ごとに違う前提で見積もりが出やすくなります。ある会社は大きなシステムを想定し、別の会社は小さな試作を想定する。金額差が出ても、何を比べればよいのか分かりません。
逆に、この3つがメモでも整理できていれば、画面設計や細かい仕様が未定でも相談は進めやすくなります。「ここはまだ未定です」と言えることも、立派な準備です。
開発外注前チェックリスト15項目
以下の項目は、相談前にすべて完璧に埋める必要はありません。まずは書けるところだけで大丈夫です。空欄が残った項目は、初回相談で確認したいこととして持っていけば十分です。
1. 作りたいものの目的
売上を増やしたいのか、業務時間を減らしたいのか、新規サービスの反応を検証したいのかを一文で書きます。
例: 「問い合わせ後のヒアリングを自動化して、商談前の確認時間を減らしたい」
2. 解決したい課題
「予約管理が煩雑」「申込情報の転記が多い」「顧客に見せるデモがない」など、今困っている状態を具体的に書きます。
3. 最初に使う人
自分だけ、社内メンバー、既存顧客、一般ユーザー、イベント参加者など、初回リリースで誰が使うのかを決めます。
4. 利用シーン
いつ、どこで、どの端末で使うのかを整理します。スマホ中心か、PC中心かだけでも画面設計は変わります。
5. 現在の代替手段
スプレッドシート、Notion、LINE、メール、手作業など、今どう対応しているかを書き出します。代替手段があるほど、最初に置き換える範囲を決めやすくなります。
6. 必須機能
初回リリースでないと価値が出ない機能だけを書きます。できれば3から5個に絞ります。
7. 後回しにできる機能
分析、細かい権限管理、複雑な通知、外部連携など、最初からなくても検証できるものを分けます。
8. 管理画面の必要性
誰がデータを確認・編集するのかを決めます。管理画面が必要な場合、一覧、検索、詳細、ステータス更新のどこまで必要かを整理します。
9. 入力・出力するデータ
ユーザーが入力する項目、管理者が確認する項目、CSVやPDFなど出力したいものを分けます。
10. 外部連携
決済、メール、LINE、Google Sheets、カレンダー、既存システムなど、接続したいサービスを洗い出します。
11. 予算感
未定でも構いません。30万円未満、30から80万円、80から150万円、150万円以上など、現実的に検討できる範囲を持っておきます。
12. 希望時期
いつまでに相談したいのか、いつまでに使い始めたいのかを分けて書きます。イベントや補助金など期限がある場合は必ず伝えます。
13. 運用担当者
リリース後に誰が更新、問い合わせ対応、データ確認をするのかを決めます。運用者が決まっていない機能は複雑になりすぎやすいです。
14. 成功条件
「月10件の申込が入る」「手作業を週5時間減らす」「商談で見せられるデモにする」など、作った後に何を見て成功とするかを決めます。
15. 一番不安なこと
費用、納期、技術的に可能か、運用できるか、失敗しないかなど、相談時に必ず聞きたいことを一つ選びます。
相談前に確認する表
15項目をすべて文章で埋めるのが大変な場合は、まず下の表だけでも確認してください。未整理の欄は、そのまま初回相談で聞く項目になります。
| 項目 | 確認すること | 未整理だと起きやすい問題 |
|---|---|---|
| 課題 | 何を解決したいか | 機能だけ増えて目的がぼやける |
| 利用者 | 誰が最初に使うか | 画面や権限設計がズレる |
| 利用シーン | PC中心か、スマホ中心か | 使いにくい画面構成になりやすい |
| 現在の管理方法 | Excel、LINE、メール、紙など今の運用 | 現場の流れに合わないシステムになる |
| 最小機能 | 最初に必要な機能 | 見積もりが膨らみ、着手しにくくなる |
| 後回し機能 | 今は作らない機能 | MVPにならず、検証前に費用が大きくなる |
| 管理画面 | 誰が何を確認・編集するか | 管理側の作業が残り、運用で詰まる |
| 外部連携 | 決済、通知、Google Sheets、LINEなど | 技術範囲と費用感が後から変わる |
| 予算 | 上限感、段階的に使える金額 | 提案内容が現実的な範囲から外れる |
| 期限 | いつまでに相談・利用開始したいか | 開発範囲の調整ができない |
| 運用担当 | 作った後に誰が使い、更新するか | 導入後に使われなくなる |
| 成功条件 | 何ができれば最初の成功か | 完成の判断基準が曖昧になる |
課題
- 確認すること
- 何を解決したいか
- 未整理だと起きやすい問題
- 機能だけ増えて目的がぼやける
利用者
- 確認すること
- 誰が最初に使うか
- 未整理だと起きやすい問題
- 画面や権限設計がズレる
利用シーン
- 確認すること
- PC中心か、スマホ中心か
- 未整理だと起きやすい問題
- 使いにくい画面構成になりやすい
現在の管理方法
- 確認すること
- Excel、LINE、メール、紙など今の運用
- 未整理だと起きやすい問題
- 現場の流れに合わないシステムになる
最小機能
- 確認すること
- 最初に必要な機能
- 未整理だと起きやすい問題
- 見積もりが膨らみ、着手しにくくなる
後回し機能
- 確認すること
- 今は作らない機能
- 未整理だと起きやすい問題
- MVPにならず、検証前に費用が大きくなる
管理画面
- 確認すること
- 誰が何を確認・編集するか
- 未整理だと起きやすい問題
- 管理側の作業が残り、運用で詰まる
外部連携
- 確認すること
- 決済、通知、Google Sheets、LINEなど
- 未整理だと起きやすい問題
- 技術範囲と費用感が後から変わる
予算
- 確認すること
- 上限感、段階的に使える金額
- 未整理だと起きやすい問題
- 提案内容が現実的な範囲から外れる
期限
- 確認すること
- いつまでに相談・利用開始したいか
- 未整理だと起きやすい問題
- 開発範囲の調整ができない
運用担当
- 確認すること
- 作った後に誰が使い、更新するか
- 未整理だと起きやすい問題
- 導入後に使われなくなる
成功条件
- 確認すること
- 何ができれば最初の成功か
- 未整理だと起きやすい問題
- 完成の判断基準が曖昧になる
迷ったら3つに分ける
チェックリストを書いていると、「これは今決めないといけないのか」「相談してからでいいのか」で迷うはずです。その時は、項目を3つに分けると進めやすくなります。
先に決めたいこと
後から変えると設計や見積もりに大きく影響する項目です。たとえば、誰が使うのか、ログインが必要か、決済を扱うか、外部システムと連携するか、個人情報を保存するかなどです。
ここが変わると、画面数、データ設計、セキュリティ、運用費が変わることがあります。完全な仕様でなくても、方向性だけは先に共有しておくと安全です。
仮置きして進められること
後から差し替えても大きな手戻りになりにくい項目です。ラベル文言、細かい並び順、初期表示、通知文面、管理画面の表示項目などです。
ここは「まずはこの前提で見積もってください」「初回はシンプルに置きます」と伝えれば十分です。仮置きだと分かっていれば、開発会社も過剰に作り込まずに提案できます。
相談しながら詰めたいこと
実際に画面を見たり、業務フローを聞いたりしないと判断しにくい項目です。入力項目の多さ、スタッフが操作しやすい管理画面、通知タイミング、ユーザーに見せる文言などです。
ここは、最初から確定させるより、小さな試作や画面イメージを見ながら決めた方がよい場合があります。
相談前に用意するとよい資料
資料はきれいに整っていなくて構いません。見た目より、現状が分かることの方が大事です。
- 作りたいものを説明する短いメモ
- 既存の業務フローやスプレッドシート
- 参考にしているサービスのURL
- 手書きの画面イメージ
- ユーザーやスタッフから聞いている困りごと
- 他社見積もりや過去に相談した内容
資料がない場合は、この記事の15項目を箇条書きで埋めるだけでも相談しやすくなります。大事なのは、相談前にすべてを完成させることではなく、会話の入口を作ることです。
コピー用相談前テンプレート
開発会社や支援者に最初の相談を送るときは、長い要件定義書よりも、今分かっている前提がまとまった短いメモの方が使いやすいです。下のテンプレートをコピーして、書けるところだけ埋めてください。
相談前にそのまま使えるメモ
空欄が残っていても大丈夫です。分からない項目は「相談で確認したい」と書いておくと、初回相談の議題にできます。
相談したい内容: 解決したい課題: 想定利用者: 最初に必要な機能: 後回しでよい機能: 現在の管理方法: 希望時期: 予算感: 外部連携の有無: 一番不安なこと:
次にやること
まずは15項目のうち、今すぐ書けるものだけを埋めてください。分からないところは空欄のままで構いません。その代わり、空欄には「相談で確認したい」と書いておくと、初回相談の議題になります。
もし「作るべき機能がまだ分からない」「本開発の前に見せられる形で試したい」という状態なら、いきなり大きな開発見積もりを取る前に、まず今の業務のどこを仕組み化できるか確認する方が進めやすくなります。
開発会社への相談は、全部決まってから行く場所ではありません。決めるべきことを一緒に見つける場でもあります。だから、まずは不安なところを一つ言葉にするところから始めてください。そこから、必要な機能も、予算感も、最初に作る範囲も見えやすくなります。
