ホーム ／ リソース ／ 予算と見積の考え方
Pricing 予算と見積の考え方 見積書の一項目ごとに、
検収のしかたまで明記します。
カスタムシステムの予算は、何を作り、何と連携し、誰が使い、公開後に誰が責任を持つかで決まります。JoinX の見積書は、システムをエリア、モジュール、個々の機能に分け、各項目に仕様、検収方法、想定日数を記載します。今回対象外とする事項も明記します。日数は見積の根拠であり、検収の対象は仕様に書かれた成果です。
合計金額だけでなく、 項目ごとに確認できる一覧です。
投信会社のウェブサイトにおけるアクセシビリティ専用ページの見積を例にしています（内容は書き換え済み、金額は省略）。説明にカーソルを合わせる（またはタップする）と、見積書の該当箇所が分かります。
プロジェクト窓口・営業窓口・見積日
| エリア | モジュール | 項目と仕様 | 想定日数 |
|---|---|---|---|
| 1 フロント | データ検索 | 検索フォームと結果表
| 3 |
| 2 フロント | 資料ダウンロード | 資料の分類とダウンロード
| 3 |
| 3 共通 | プロジェクト管理 |
| 4 |
| 共通 | 機能テスト |
| 3 |
- 1すべての項目に仕様がある
「検索機能」と書くだけではなく、正常時、入力エラー時、該当なし、失敗時のそれぞれでどう動くかを明記します。検収では、これらを一つずつ確認する基準になります。
- 2エリアとモジュールで整理
フロント、管理画面、アプリ、API を分けて記載し、さらにモジュールに分けます。費用の内訳が一目で分かり、どれを先に作り、どれを後回しにするかも決めやすくなります。
- 3見えない作業も項目化
要件ヒアリング、フローとワイヤーフレーム、進捗報告、テストと再テストを、それぞれ独立した項目にします。見積の金額に大きな差が出るときは、たいていこれらが含まれているかどうかの違いです。
- 4やらないことを明記
対象外の事項は見積書に直接書きます。後から追加する場合は別途お見積りするため、検収の段階で認識のずれに気づくことはありません。
- 5検収と保証のルール
納品後の検収方法、修正までの期間、保証の対象は、契約前に取り決めます。
- 6お渡しする成果物
ソースコード、仕様書、デザインファイルをすべてお渡しし、著作権はお客様に帰属します。どの環境を誰が用意するかも、事前に明記します。
予算に差が出るのは、 たいていこの6点です。
連携する既存システムの数
ERP、POS、決済、物流、会員システムなど。連携が一つ増えるごとに、接続仕様、テスト、例外処理が増えます。
利用者と権限の種類
会員、現場スタッフ、管理職、本部の管理者など、役割が多いほど画面、フロー、権限設定が増えます。
既存データの移行
Excel や旧システムからデータを移す場合は、整理、項目の対応づけ、形式変換を行い、移行後のデータが正しいかを検証します。
対応するプラットフォーム
ウェブのみか、iOS・Android アプリと管理画面も必要か。プラットフォームごとに設計、開発、ストア公開の作業があります。
公開後のサポート水準
5×8 から 7×12 までのサポート時間帯、サーバーとシステム管理、監視とバックアップ。運用範囲によって、公開後の毎月の工数が決まります。
セキュリティと法規制の要件
金融、医療、公共機関、アクセシビリティ認証などの要件があると、確認項目、文書、監査対応が増えます。
要件が固まっていないうちは、 総額を急がないでください。
要件があいまいなほど総額の精度は下がり、高すぎる見積になるか、後から追加が続くかのどちらかになります。そのため、通常はフェーズごとに見積を出し、各フェーズの終わりに続けるかどうかをご判断いただきます。
要件の整理
現場に伺い、一緒にフローを描き、操作できるプロトタイプを作ります。範囲、優先順位、例外ケースをこの段階で明確にします。
開発と公開
フェーズ1で確定した仕様に沿って項目ごとに開発し、定期的にデモを行います。納品後は仕様に沿って項目ごとに検収し、正式に公開します。
運用と継続開発
サーバー、保守、セキュリティ、サポートは運用契約に基づいて行います。新しい要望は別途お見積りし、同じチームが引き続き対応します。
3つの契約方式。 状況に合わせて選べます。
| 方式 | 向いている状況 | 予算の動き方 |
|---|---|---|
| 固定範囲 | 要件が明確で変更が少ない場合。例：フローとプロトタイプがすでにあるシステム | 総額が明確。範囲外の要望は別途お見積り |
| フェーズ分けの反復開発 | 作りながら検証が必要な場合。例：新規プロダクトや初めてのデジタル化 | フェーズごとに見積を出し、結果を見て次を決める |
| PoC／MVP | 技術的な実現性や市場の反応を先に確かめたい場合。例：AI 活用や新サービス | 範囲をあえて絞り、少ない予算で答えを得る。コアとなるセキュリティと品質の要件は変えない |
期間の目安を先につかめます。
以下は代表的なケースの目安です。正確な期間は提案時に明記します。
契約の前に、 これらを確認してください。
「なぜ会社ごとに見積がこんなに違うのですか？」
同じ作業の単価が違うのではなく、範囲が違うことがほとんどです。各社の見積書を並べて、項目ごとに比べてください。要件ヒアリング、設計、テストと再テストは記載されているか。仕様はどこまで詳しく書かれているか。対象外には何が書かれているか。再委託はあるか。公開後は誰が責任を持つか。総額だけで比べると、最も安い見積は、最も記載が少ない見積であることが少なくありません。
「見積書の日数は何を意味しますか？」
日数は、各項目の作業量を見積もるための根拠で、どの項目が重いかを見分けられるようにするものです。検収で確認するのは仕様どおりにできているかどうかで、実際に何日かかったかではありません。
「途中で機能を追加したくなったら？」
追加できます。まず、その変更が期間と費用にどう影響するかを評価し、ご確認いただいたうえで開発に組み込みます。範囲外の要望は別途お見積りするので、検収の段階で初めて総額が膨らむことはありません。見積書に対象外を明記するのはそのためです。
「MVP から始めると、品質が低くなりませんか？」
いいえ。MVP で絞るのは今回検証したい課題の範囲であり、品質の基準ではありません。コアのフローには、セキュリティ、テスト、保守性の要件を同じように満たします。だからこそ、その後も同じシステムの上で育てていけます。
御社のシステムの費用感を知りたいですか？
仕様書を先に用意していただく必要はありません。解決したい課題だけお持ちください。まず範囲を一緒に見極め、予算が膨らみやすいポイントをお伝えします。