はじめに: なぜ「規模感」を先に把握すべきか
「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
- 顧客側プロダクトオーナー
- ステアリングコミッティ
重みづけ
- 要件定義は外部コンサルや業務分析専門家を入れる
- 設計レビュー・アーキテクチャレビューを複数回
- 段階リリース前提でロードマップ設計
- セキュリティ・性能・可用性の非機能要件が大きなテーマ
よくある落とし穴
- 「全部いっぺんに作る」発想 → 100% 失敗する。必ずフェーズ分割する
- 要件凍結幻想 → 業務要件は半年で変わる前提で、変更管理プロセスを設ける
- ガバナンス不足 → 意思決定スピードが落ちて炎上
適した発注スタイル
- 要件定義は別契約（コンサル契約）
- 開発フェーズは複数のサブプロジェクトに分割
- 各フェーズで再見積もり前提
- リスク予備費（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戦略）
- 段階リリース前提でロードマップを描く
- ガバナンス（意思決定機関）を設計する
- 「使われないシステム」を作らない検証フェーズを必ず置く
「使われないシステム」についてはこちらの記事で詳しく解説しています。
まとめ
Webシステム開発の費用は、規模を先に決め、規模に合った発注スタイルを選ぶことで初めて妥当性を判断できます。同じ「1,000万円」でも、小規模をオーバースペックで作ったのか、中規模を適正に作ったのか、大規模を圧縮したのかで意味が全く違います。
弊社では、お客様の要件をヒアリングした上で、最適な規模感と発注スタイルをご提案しています。
関連記事
まずは小さく始めるなら
ゼロスタートなら、初期費用0円で動くプロトタイプから始められます。