「開発会社に見積もりをお願いしたいけれど、いきなり大きな金額が出てきたらどうしよう」と不安になることがあります。

相談前の段階では、必要な機能も、使う人の動きも、既存業務とのつなぎ方もまだ曖昧です。そのまま完成版の見積もりを取ると、比較したいのに前提がそろわず、結局どの提案がよいのか判断しにくくなります。

この記事では、大きな見積もりを取る前に、小さな試作で確認した方がよいケースを整理します。見積もりを安くするためではなく、何を作るべきか、何を後回しにできるか、どこにリスクがあるかを見えるようにするための実践メモです。

見積もり前に迷うのは自然です

「まだ仕様が固まっていないのに、見積もりを依頼してよいのだろうか」

開発相談の前には、こうした迷いが出やすくなります。予約管理、申込受付、社内台帳、顧客管理、通知、CSV出力、外部サービス連携。必要そうな機能を書き出すほど、全部を入れた見積もりを取るべきか、最初は小さく相談すべきか分からなくなります。

見積もり自体は必要です。ただし、前提が曖昧なまま「完成版でいくらですか」と聞くと、提案側はリスクを多めに見たり、安全側に大きく見積もったりしやすくなります。反対に、安く見える見積もりでも、運用・例外対応・データ移行・外部連携が含まれていなければ、後から追加になることがあります。

だから、最初に考えたいのは金額の大小だけではありません。本開発の見積もりに進む前に、何が分かれば判断できるのかです。そこが見えていないなら、小さな試作を挟む価値があります。

先に結論

大きな見積もりを取る前に試作した方がよいのは、次のようなケースです。

  1. 利用者の画面や操作の流れがまだ想像しにくい
  2. 既存業務のどこを置き換えるかが決まっていない
  3. 管理画面、通知、CSV出力、外部連携の必要範囲で迷っている
  4. 社内説明や稟議のために、文章だけでなく動く画面が必要
  5. 本当に使われるか、現場の反応を見てから本開発へ進みたい

試作は、完成版の縮小コピーではありません。GOV.UK Service ManualのAlpha phaseでは、最もリスクの高い仮説を試すために、必要最小限の複雑さでプロトタイプを作り、学んだうえで次へ進む考え方が説明されています。

Ready Mockでも、見積もり前の試作は「全部を少しずつ作る」より「判断に必要な流れを1つ選ぶ」方が向いていると考えています。予約なら「空き状況を見て申し込む」。申込なら「入力して担当者に通知される」。社内台帳なら「登録して一覧で確認する」。最初の1本を動かすだけでも、見積もりの前提はかなり具体化します。

見積もり前の試作で分かること

見積もり前の試作で分かるのは、完成版の正確な金額ではありません。分かるのは、見積もりの前提にすべきことです。

たとえば、文章では「予約システム」と書いていても、実際には次のように必要なものが違います。

  • お客様が空き枠を見て予約するだけでよい
  • 担当者が仮予約を承認してから確定したい
  • 店舗、担当者、部屋、コースごとに空き枠を分けたい
  • 既存のGoogle Calendarや決済サービスとつなぎたい
  • 予約後のリマインドやキャンセル待ちまで必要

この違いを言葉だけで詰めるのは大変です。小さな試作で画面と流れを見ると、「ここは必要」「ここは後でよい」「ここは既存ツールで足りる」が話しやすくなります。

デジタル庁のデジタル社会推進標準ガイドラインは、サービス・業務改革と情報システム整備を合わせて扱う共通ルールや参考ドキュメントをまとめています。民間の小規模な開発相談でも、画面だけではなく、業務の変え方や運用まで一緒に見る姿勢は参考になります。

試作を挟んだ方がよい5つのケース

次の表に当てはまる項目が多いほど、いきなり完成版見積もりに進むより、先に試作した方が判断しやすくなります。

ケース試作で見ること本開発前に決めやすくなること
画面の使い方が曖昧

スマホや管理画面で、入力・確認・修正が自然にできるか

必要な画面数、入力項目、確認導線
既存業務が複雑

紙、Excel、メール、口頭確認のどこを置き換えるか

最初に自動化する範囲、残す手作業
外部連携がある

決済、メール、カレンダー、既存台帳とのつなぎ方の難所

連携の優先順位、代替運用、後回しにできる部分
社内合意が必要

担当者や決裁者が、文章だけでなく画面を見て判断できるか

稟議資料に入れる効果、範囲、段階的な進め方
利用者の反応が読めない実際の担当者や一部利用者が、迷わず使えそうか

本開発に進むか、方向転換するか、既存ツールで足りるか

これは法律や制度上の分類ではなく、Ready Mockで相談前整理に使う実務上の目安です。大事なのは、「作れるか」だけでなく、そのまま大きく作ってよい前提かを確認することです。

試作は完成版のミニチュアではない

見積もり前の試作でよくある失敗は、完成版に必要そうな機能を全部少しずつ入れようとすることです。

予約、申込、管理、通知、分析、権限、決済、外部連携、メールテンプレート、CSV出力。全部を少しずつ入れると、見た目は豪華になります。ただ、どの仮説を確認したかったのかがぼやけます。

GOV.UK Service ManualのDiscovery phaseでは、作る前に、解くべき問題、利用者、制約、改善機会を理解することが説明されています。さらに、discoveryではサービスを作り始めるべきではない、と明示されています。

この考え方を小規模な民間案件に置き換えるなら、見積もり前に必要なのは、完成版の一部を急いで作ることではありません。先に「何が分かれば本開発へ進めるのか」を決め、その確認に必要な最小限の画面や流れを作ることです。

最初の試作に入れる範囲

試作に入れる範囲は、業務の種類によって変わります。ただし、見積もり前の相談では、次の考え方が使いやすいです。

1. 入口から出口まで1本だけ通す

最初は「主要な流れを1本だけ」通します。申込フォームなら、入力、確認、送信、担当者通知、管理一覧まで。予約なら、空き枠を見る、希望日時を選ぶ、申込む、担当者が確認するまで。

細かい例外を全部入れる必要はありません。まずは、業務の芯になる流れが自然かどうかを見ます。

2. 実データではなく仮データでよい

見積もり前の試作では、個人情報や本番データを使わない方が安全です。仮の申込者、仮の予約枠、仮の顧客データで動きを見れば、最初の判断には十分なことが多いです。

本番データ移行や権限管理が必要かどうかは、試作を見た後に本開発の論点として分けます。

3. 外部連携は本物でなくてもよい

決済、メール配信、Google Calendar、CRMなどとつなぐ予定があっても、最初から全部を本接続する必要はありません。外部連携は、仕様や制約が変わりやすく、費用にも影響しやすい部分です。

まずは、どのタイミングで何を渡す必要があるかを画面や仮の通知で確認します。外部連携が本当に必要だと分かってから、公式ドキュメントや制約を見て本見積もりに入れる方が安全です。

4. 管理画面は「判断できる一覧」から始める

高機能な管理画面を最初から作る必要はありません。見積もり前の試作では、担当者が次の対応を判断できる一覧があれば十分な場合があります。

必要なのは、検索、ステータス、担当者メモ、CSV出力、詳細画面のうち、どれが最初の運用に必要かを確認することです。

試作後に見積もりが具体化する理由

試作を挟むと、開発会社に聞くべき内容が変わります。

試作前は「全部でいくらですか」になりがちです。試作後は、次のように聞けます。

  • この試作を本番利用できる品質にするには何が必要か
  • 本開発に入れる機能と後回しにする機能はどれか
  • 外部連携、権限、データ移行、運用管理はどの段階で必要か
  • 既存ツールで代替できる部分はどこか
  • 先に作ると手戻りが大きい部分はどこか

GOV.UK Service ManualのBeta phaseでは、alphaで選んだ最良の案を実際に構築し、既存サービスとの統合や本番移行を考える段階としてbetaが説明されています。試作で学んだ後に、本番品質、運用、既存業務との接続を見積もる流れは、小規模案件でも参考になります。

見積もり前の試作は、見積もりを不要にするものではありません。むしろ、見積もりの前提をそろえ、比較しやすくするための準備です。

試作を急がなくてよいケース

すべての案件で試作が必要なわけではありません。次のような場合は、先に見積もりや実装相談へ進んでもよいことがあります。

  • 既存サービスの導入や設定でほぼ足りる
  • 画面や業務フローがすでに明確で、関係者の合意も取れている
  • 既存システムの軽微な修正で、影響範囲が限定されている
  • 法令、契約、業務ルールによって作る範囲がほぼ決まっている
  • すでに利用者検証済みで、本番品質への実装だけが残っている

この場合でも、相談前に「何を変えるのか」「誰が使うのか」「どのデータを扱うのか」は整理しておきます。試作するかどうかは目的ではなく、判断材料を得るための手段です。

相談前チェックリスト

見積もり前に試作するか迷ったら、次の項目を確認してください。

業務と利用者

  • いま困っている業務を一文で説明できるか
  • 入力する人、確認する人、承認する人を分けているか
  • 紙、Excel、メール、チャット、口頭確認のどこを置き換えたいか
  • 最初に確認したい利用者の動きが1つに絞れているか

画面とデータ

  • スマホ入力が必要か
  • 管理者は一覧を見るだけでよいか、ステータス変更も必要か
  • CSV出力や外部サービス連携が必要か
  • 本番データを使わずに仮データで確認できるか

判断材料

  • 試作を見れば、社内で進める判断ができるか
  • 既存ツールで足りるかどうかを確認したいか
  • 本開発の見積もり前に、後回しにできる機能を分けたいか
  • 試作後に「進む」「やめる」「方向を変える」の判断ができそうか

3つ以上当てはまるなら、いきなり完成版見積もりを取るより、最初に1本の業務導線を試作する方が話が進みやすいです。

そのまま使える相談メモ

開発会社や試作サービスに相談するときは、次のように伝えると十分です。

本開発の見積もりを取る前に、小さな試作が必要か相談したいです。 現在は〇〇を使って△△を管理していますが、□□で困っています。 完成版として必要そうな機能は複数ありますが、最初は「利用者が入力し、担当者が確認する」流れを見たいです。 外部連携や管理画面は必要かもしれませんが、まずは試作で判断したいです。 本開発に進む前に、どこまで作ると見積もり前提が具体化するか相談できますか。

この時点で、完璧な仕様書は不要です。むしろ、分からないことを隠さず共有した方が、試作で何を確認すべきかが見えやすくなります。

次にやること

まず、作りたいものを「業務の流れ」で1本だけ書いてください。

例として、「お客様が希望日時を選び、担当者が確認し、必要なら連絡する」「申込者がフォームを送り、担当者が一覧で確認し、CSVで出す」のような形です。

次に、その流れを見れば何を判断できるのかを書きます。使いやすさを見たいのか、社内説明に使いたいのか、外部連携の必要性を判断したいのか。目的が決まると、試作に入れる範囲も自然に絞れます。

もし、そもそも試作・MVP・本開発の違いが曖昧な場合は、先にMVP開発・試作・本開発の違いを読むと整理しやすくなります。予算が固まっていない場合は、システム開発の予算が決まっていないときの相談方法も参考になります。

見積もり前の試作は、遠回りではありません。大きく作る前に、現場で使えるか、どこまで必要か、何を後回しにできるかを確認するための近道です。

参考情報

この記事では、次の公的・公式・実務情報を確認しました。参照日はすべて2026年7月10日です。

  • デジタル庁「デジタル社会推進標準ガイドライン」: ページ最終更新日 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。作る前に問題、利用者、制約、改善機会を理解する考え方を参照しました。
  • GOV.UK Service Manual「How the alpha phase works」: Published 4 August 2016, Last updated 8 May 2019。最もリスクの高い仮説を、必要最小限の複雑さのプロトタイプで試す考え方を参照しました。
  • GOV.UK Service Manual「How the beta phase works」: Published 4 August 2016, Last updated 19 February 2021。alphaで選んだ案を実際に構築し、既存サービスとの統合や本番移行を考える段階として参照しました。
  • Agile Alliance「Minimum Viable Product (MVP)」: MVPを学習のための概念として扱う解説を確認しました。ページ上で公開日・更新日は確認できませんでした。