はじめに: なぜ「規模感」を先に把握すべきか
「Webシステムを作りたい」とご相談いただいたとき、最初にお聞きするのは予算でも納期でもなく、「どの規模のシステムを想定しているか」です。
なぜなら、規模によって:
- 必要な体制（人数・役割）
- 工程の重みづけ
- 適切な開発手法（ウォーターフォール / アジャイル / PoC先行）
- 妥当な費用レンジ
がまったく変わるからです。
本記事では、Webシステムを小規模・中規模・大規模の3レンジに分け、それぞれの費用感・特徴・落とし穴を解説します。
規模別レンジの全体像
規模 | 工数目安 | 期間目安 | 費用レンジ | 主な利用シーン |
|---|---|---|---|---|
小規模 | 30〜80人日 | 2〜4ヶ月 | 300〜800万円 | 業務効率化ツール、社内ポータル、シンプルなSaaS MVP |
中規模 | 100〜300人日 | 4〜8ヶ月 | 1,000〜3,000万円 | 顧客向けWebサービス、ECサイト、業務基幹の一部 |
大規模 | 400人日以上 | 8ヶ月以上 | 4,000万円〜 | 基幹システム、マルチテナントSaaS、複雑な業務基盤 |
上記は中央値の目安です。技術スタック・要件難易度・体制（オフショア活用等）で前後します。
小規模（300〜800万円）
典型的なプロジェクト
- 部門内で使う業務ツール（申請・承認・台帳管理）
- 既存サービスの機能限定版MVP
- 社内向けダッシュボード
- ノーコード/ローコードでは実現できない、ちょっとした業務システム
体制の例
- PM 兼 エンジニア（1名、専任 or 半専任）
- フロントエンド/バックエンド エンジニア（1〜2名）
- 必要に応じてデザイナー（スポット）
重みづけ
- 要件定義はコンパクトに（業務担当者と直接対話）
- 設計ドキュメントは最低限
- アジャイル / 短いウォーターフォールが向く
- テストは自動化を絞り込む
よくある落とし穴
- 「小さい」と思って雑な要件定義 → 結局、想定外の業務が見つかり工数が倍増する
- PMを置かない → 進捗が見えなくなり、途中で炎上
- 保守を考えない作り → 半年後に動かなくなる
適した発注スタイル
固定価格契約。スコープを最初にがっちり決めて、変更は別見積もりで対応する。
中規模（1,000〜3,000万円）
典型的なプロジェクト
- 顧客向けWebサービスの本格立ち上げ
- ECサイト（独自要件あり）
- 業務基幹システムの一部リプレース
- マッチングプラットフォーム
体制の例
- PM（1名、専任）
- アーキテクト/テックリード（1名）
- フロントエンドエンジニア（1〜2名）
- バックエンドエンジニア（2〜3名）
- デザイナー（要件定義〜UIデザイン）
- QA / テスター（1名 or スポット）
重みづけ
- 要件定義に十分な時間を確保（全体の15%前後）
- 設計ドキュメントを残す（基本設計、画面遷移、API仕様）
- テスト自動化（単体テスト、E2Eの一部）
- 運用設計（モニタリング、ログ、デプロイ自動化）
よくある落とし穴
- POが社内に居ない → 意思決定が遅れて開発が止まる
- 設計を省略 → 中盤で全体構造の問題に気づき、大規模リファクタが必要に
- テストを後回し → リリース前のテストフェーズで品質問題が爆発
適した発注スタイル
- 要件定義フェーズは個別契約（着手金型）
- 開発フェーズはマイルストーン分割の準委任契約 or 段階別固定
- 仕様変更ルールを契約書に明記
大規模（4,000万円以上）
典型的なプロジェクト
- 全社基幹システム
- マルチテナントSaaS
- 複雑な業務ロジックを持つ業界特化システム
- 複数システム連携のハブ
体制の例
- プロジェクトマネージャー（1〜2名）
- アーキテクト
- 開発リーダー（フロント/バックエンド/インフラ各1名）
- 開発メンバー（5〜10名以上）
- QAチーム（複数名）
- インフラ/SRE
- 顧客側プロダクトオーナー
- ステアリングコミッティ
重みづけ
- 要件定義は外部コンサルや業務分析専門家を入れる
- 設計レビュー・アーキテクチャレビューを複数回
- 段階リリース前提でロードマップ設計
- セキュリティ・性能・可用性の非機能要件が大きなテーマ
よくある落とし穴
- 「全部いっぺんに作る」発想 → 失敗する確率が極めて高い。必ずフェーズ分割する
- 要件凍結幻想 → 業務要件は半年で変わる前提で、変更管理プロセスを設ける
- ガバナンス不足 → 意思決定スピードが落ちて炎上
適した発注スタイル
- 要件定義は別契約（コンサル契約）
- 開発フェーズは複数のサブプロジェクトに分割
- 各フェーズで再見積もり前提
- リスク予備費（10〜20%）を別計上
自社プロジェクトはどのレンジか？判断軸
以下の質問に答えてみてください。
A. 利用ユーザー数
- 〜50名: 小規模
- 50〜5,000名: 中規模
- 5,000名以上 or 一般顧客向け: 中〜大規模
B. 機能数（画面数の目安）
- 〜10画面: 小規模
- 10〜30画面: 中規模
- 30画面以上: 大規模
C. 連携する外部システム
- なし: 小規模
- 1〜3システム: 中規模
- 4以上 or リアルタイム連携: 大規模
D. 業務の複雑さ
- 申請・承認のような単純フロー: 小規模
- 業務固有のロジックあり: 中規模
- 業界特有の複雑な業務: 大規模
E. 非機能要件
- 通常: 小規模
- 性能要件あり、可用性重要: 中規模
- 24/365稼働、セキュリティ最高水準: 大規模
3つ以上が同じレンジに該当すれば、そのレンジが目安です。複数レンジに分散している場合、要件の優先度を整理する必要があります。
規模別: 失敗を避けるための原則
小規模で失敗しない原則
- 1ヶ月以内のスプリントを切り、毎月動くものを確認する
- 要件は3行で書ける単位に分解する
- リリース後の保守体制を最初に決める
中規模で失敗しない原則
- POを社内で確保する（兼務でも可、ただし意思決定権を持つ人）
- 要件定義に全体の15%以上の時間を投下する
- 中間リリースを2〜3回計画する
大規模で失敗しない原則
- 「最初の1年で動くもの」を絞り込む（MVP戦略）
- 段階リリース前提でロードマップを描く
- ガバナンス（意思決定機関）を設計する
- 「使われないシステム」を作らない検証フェーズを必ず置く
「使われないシステム」についてはこちらの記事で詳しく解説しています。
安すぎる見積もりに要注意｜適正価格の判断基準
複数社から見積もりを取ると、1社だけ極端に安い金額を提示してくるケースがあります。安さには必ず理由があり、その多くは「体制の省略」か「見積もり範囲の狭さ」です。
安すぎる見積もりに共通する特徴は以下の3つです。
- ブリッジSEやPMを置かない体制：発注者の業務ルールが開発者に正しく伝わらず、完成品が業務フローと噛み合わない。結局やり直しになり、当初予算を大幅に超過する
- 保守・運用費が含まれていない：初期開発だけの金額で安く見せているが、リリース後のサーバー費用・障害対応・機能改修は別途請求される。年間の総コストで比較すると逆転することが多い
- テスト工程が圧縮されている：品質管理プロセスが不十分なまま納品され、本番稼働後にバグが頻発する。修正対応で開発元に追加発注が必要になる
適正価格を見極めるには、金額だけでなく「その金額で何が含まれているか」を確認することが必要です。見積もりの内訳を比較するための具体的なチェック項目は、見積もり比較チェックリストで解説しています。不安な場合は、ゼロスタートのように初期費用を抑えた小さなプロトタイプから始めて、開発会社の実力を確認してから本格発注に進む方法が有効です。
まとめ
Webシステム開発の費用は、規模を先に決め、規模に合った発注スタイルを選ぶことで初めて妥当性を判断できます。同じ「1,000万円」でも、小規模をオーバースペックで作ったのか、中規模を適正に作ったのか、大規模を圧縮したのかで意味が全く違います。
弊社では、お客様の要件をヒアリングした上で、最適な規模感と発注スタイルをご提案しています。
関連記事
まずは小さく始めるなら
ゼロスタートなら、初期費用0円で動くプロトタイプから始められます。
よくある質問（FAQ）
Q. Webシステム開発で予算超過が起きる原因は何ですか？
A. 最も多い原因は要件定義の甘さです。「小さい」と思って雑な要件定義で進めると、想定外の業務が途中で見つかり工数が倍増します。中規模以上ではPO（プロダクトオーナー）不在による意思決定の遅延も典型的です。発注前に見積もり比較チェックリストで費用の内訳を確認しておくと予算超過のリスクを下げられます。
Q. 小規模開発と大規模開発の体制はどう違いますか？
A. 小規模（300～800万円）はPM兼エンジニア1名＋開発1～2名で済みますが、大規模（4,000万円以上）はPM・アーキテクト・開発リーダー複数名・QAチーム・SREなど10名以上の体制が必要です。規模に合わない体制で始めると、小規模なら進捗が見えなくなり、大規模ならガバナンス不足で炎上します。
Q. 開発費用の見積もりを比較するコツはありますか？
A. 同じ「1,000万円」でも、小規模をオーバースペックで作ったのか、中規模を適正に作ったのかで意味が違います。まず本記事の判断軸（利用ユーザー数、画面数、外部連携数、業務複雑さ、非機能要件）で自社プロジェクトの規模を特定し、規模に合った発注スタイルを選んでください。内訳の詳しい読み方はシステム開発費用の内訳ガイドで解説しています。
Q. 運用・保守コストはどの程度見込めばよいですか？
A. 開発規模によりますが、初期費用の15～25%程度を年間の運用・保守費として見込むのが一般的です。モニタリング、ログ管理、デプロイ自動化、セキュリティパッチ適用、障害対応が主な内訳です。RFP段階で運用フェーズの体制と費用を明記しておくと、リリース後に「保守契約が決まっていない」事態を防げます。見積もりの全体像は見積もり完全ガイドを参照してください。