「予算の話をどう切り出せばいいのだろう」と迷っているうちに、開発会社への相談が止まってしまうことがあります。
本当のゴールは、予算内に機能を詰め込むことではありません。最終的には、現場で使えるシステムを作り、業務が前に進む状態にしたいはずです。
この記事では、予算額だけで範囲を決める前に、何を伝えると提案を受けやすいかを整理します。AIや開発ツールによって作れる範囲は変わり続けるため、金額だけで線を引くより、目的・業務・優先順位を持って相談する方が現実的です。
予算が決まっていなくても相談して大丈夫です
「まだ予算が固まっていないので、相談してよいのか分からない」
システム開発を考え始めた段階では、予算も範囲もはっきりしていないことが多いです。予約フォーム、申込管理、通知メール、管理画面、CSV出力、ログイン、決済、分析画面。思いつく機能を並べるほど、どれも必要に見えてきます。
ただ、最初の相談で完璧な予算表や要件定義書を用意する必要はありません。むしろ早い段階で相談した方が、「既存ツールで足りる部分」「小さく作ると判断しやすい部分」「本開発まで待つべき部分」を分けやすくなります。
大切なのは、予算だけで可能性を閉じる前に、何を実現したいのかを共有することです。「この業務を楽にしたい。どこから始めるのがよいか」を相談する方が、提案の余地が広がります。
先に結論
開発会社に相談する前に、無理に予算と範囲を決め切らなくて構いません。先に整理したいのは、次の4つです。
- 何の業務を楽にしたいか
- 誰が入力し、誰が確認するか
- 最初に確認したい画面や流れはどこか
- 予算感がある場合は、上限ではなく相談材料として伝える
AIや開発支援ツールの進化によって、短期間で作れる範囲は変わり続けています。一方で、業務の目的、利用者、データの扱い、運用責任は、ツールが進化しても確認が必要です。
だから、相談時は「予算内で全部できますか」より、「この業務を使える形にしたい。最初にどこから作ると判断しやすいですか」と伝えるのがおすすめです。
予算だけで断定しない方がよい理由
予算ごとの範囲をはっきり断定すると、読みやすく見えます。ただし、実際の相談では危うさもあります。
| 予算だけで決め切るリスク | 起きやすいこと | 相談時の見方 |
|---|---|---|
| 可能性を狭める | 相談前に難しいと思い込んで、連絡する前に止まってしまう。 | まず課題と目的を伝え、始め方を相談する。 |
| 比較がずれる | 同じ金額でも、画面品質、データ設計、運用対応の範囲が違う。 | 金額ではなく、含まれる判断材料を比べる。 |
| 変化に弱い | AIや開発ツールの進化で、作り方や効率が変わる。 | 最新の作り方を前提に、相談時点で見積もってもらう。 |
予算は大事です。ただし、予算は「相談を止めるための線」ではなく、「どの始め方がよさそうかを一緒に考えるための材料」として扱う方が安全です。
相談前に伝えるとよいこと
開発会社に連絡するときは、細かい仕様より先に、次の情報があると話が進みやすくなります。
1. いま困っている業務
「予約の確認に時間がかかる」「申込後の連絡漏れがある」「Excelの最新版が分からない」など、実際に困っていることを書きます。きれいな資料でなくて構いません。
2. 最初に使う人
社内担当者なのか、既存顧客なのか、イベント参加者なのか。誰が入力し、誰が確認するかで、作るべき画面や注意点が変わります。
3. まず見たい流れ
「フォームに入力する」「管理者が一覧で確認する」「通知が届く」など、最初に見たい流れを1つに絞ります。全部を一度に作るより、最初に確認したい流れを共有する方が提案を受けやすくなります。
4. 予算感と優先順位
予算がある場合は、上限として固定するより「このくらいから相談したい」「段階的に進めたい」と伝える方がよいです。予算が未定なら、未定のままで構いません。
小さく始めるときの考え方
小さく始めるとは、安く済ませることだけではありません。最終的に使えるシステムへ進むために、最初の判断材料を作ることです。
たとえば、予約管理なら最初からすべての例外や決済まで作るのではなく、「予約入力」「管理者確認」「通知」のどれが一番重要かを見ます。申込管理なら、「フォーム」「一覧」「ステータス変更」「CSV出力」のうち、現場が最初に使う部分を選びます。
GOV.UK Service ManualのDiscovery phaseでは、サービスを作る前に、解くべき問題、利用者、制約、改善機会を理解することが説明されています。いきなり完成版を作る前に、問題と利用者を具体化する考え方は、小規模な民間案件でも参考になります。
デジタル庁のデジタル社会推進標準ガイドラインでも、サービス・業務改革と情報システム整備を合わせて扱う考え方が整理されています。画面や機能だけでなく、業務の変え方を一緒に見ることが重要です。
予算はいつ伝えるべきか
予算が決まっている場合は、隠す必要はありません。ただし、伝え方が大事です。
「全部込みでお願いできますか」ではなく、次のように伝えると、相談が前に進みやすくなります。
- このくらいの予算感から始めたい
- まず何を確認できるか相談したい
- 段階的に作る場合の進め方を知りたい
- 本開発に進む前に、最初の判断材料がほしい
予算が未定の場合は、「まだ予算は決まっていません」と正直に伝えて問題ありません。その代わり、困っている業務、使う人、最初に確認したい流れを伝えると、相談相手も提案しやすくなります。
AIで作れる範囲は変わり続ける
AIや開発支援ツールによって、画面作成、文章生成、簡易な実装、既存サービスとの組み合わせは以前より速く進めやすくなっています。だから、古い相場感だけで相談前に可能性を閉じるのはもったいない場合があります。
一方で、AIがあっても、業務の責任や運用の判断が消えるわけではありません。個人情報を扱うのか、誰が確認するのか、外部サービスとどうつなぐのか、失敗したときに誰が対応するのか。ここは人が確認する必要があります。
Agile AllianceのMinimum Viable Product (MVP)解説では、MVPを単に最小機能を出すことではなく、顧客や事業の前提を学ぶための考え方として説明しています。金額に合わせて機能を削るだけでなく、何を学ぶかを決めることが重要です。
範囲が曖昧なまま連絡してよいケース
次のどれかに当てはまるなら、範囲が固まっていなくても相談して構いません。
- 業務を楽にしたいが、システム化すべきか分からない
- 既存ツールで続けるか、個別開発するか迷っている
- 予算はあるが、何を優先すべきか決められない
- 社内で説明するために、画面や流れのたたき台がほしい
- 本開発の見積もりを取る前に、まず方向性を見たい
逆に、「要件が全部決まってから連絡しよう」と考えすぎると、相談のタイミングが遅くなります。開発会社に聞くべきことまで自分たちで抱え込んでしまうからです。
そのまま使える相談文
最初の連絡は、次のくらいで十分です。
業務を一部システム化したく、まず相談したいです。 現在は〇〇を使って△△を管理していますが、□□で困っています。 最終的には現場で使える形にしたいですが、最初にどこまで作るのがよいか分かっていません。 予算はまだ未定です。予算感が必要であれば、分かる範囲で共有できます。 まず、進め方と最初に確認すべき範囲を相談できますか。
この時点で、完璧な資料や画面設計は不要です。むしろ、未定の部分も含めて共有した方が、現実的な進め方を相談しやすくなります。
次にやること
まず、作りたいものを一文で書いてください。次に、その下に「いま困っている業務」「最初に使う人」「最初に確認したい流れ」を1つずつ書きます。
予算が決まっていれば添えて構いません。決まっていなければ、無理に決めなくて大丈夫です。金額で可能性を閉じる前に、どこから始めると使えるシステムに近づくかを相談してください。
もし、そもそも業務システムに進むべきか迷う場合は、先に業務システムをいきなり作る前に確認したいことを読むと整理しやすくなります。MVP、試作、本開発の違いが曖昧な場合は、MVP開発・試作・本開発の違いも参考になります。
小さく始めることは、妥協ではありません。最終的に使えるシステムへ進むために、早い段階で相談し、判断材料をそろえる方法です。
参考情報
この記事では、次の公的・公式・実務情報を確認しました。参照日はすべて2026年7月8日です。
- デジタル庁「デジタル社会推進標準ガイドライン」: ページ最終更新日 2026年6月12日。DS-100、DS-110、DS-120は2025年6月19日更新、策定日または最終改定日 2025年5月27日。DS-121 アジャイル開発実践ガイドブックは策定日または最終改定日 2021年3月30日。
- GOV.UK Service Manual「How the discovery phase works」: Published 4 August 2016, Last updated 21 June 2021.
- Agile Alliance「Minimum Viable Product (MVP)」: MVPを学習のための概念として扱う解説を確認。ページ上で公開日・更新日は確認できませんでした。
