Webシステムの発注は、業務課題を整理し、発注形態と契約を選び、同じ条件で提案を比べる順に進めます。この順で進めると、予算超過や納期遅延を防ぐ助けになります。
▼全体ガイドの記事
・Webシステム開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
Webシステムを発注・外注する前に知る全体像
Webシステムは、利用者の操作に応じてデータを処理する仕組みです。
情報を見せるWebサイトとは、役割そのものが異なります。
ログイン、権限管理、検索、申請・承認、決済が必要な場合は、画面以外も発注範囲に含めます。
在庫更新や外部API連携も、発注範囲の対象になります。
データベース、認証、監視、障害対応も、発注範囲の対象です。
発注前に、必要な処理と運用範囲を確かめておきます。
WebサイトとWebシステムの違い
Webサイトは、企業情報や商品情報などを閲覧してもらうことが主な目的です。一方で、Webシステムは利用者ごとに処理を実行し、データを登録・更新・連携します。
- Webサイト：情報の閲覧が中心です。
- Webシステム：利用者ごとのデータ処理を担います。
問い合わせフォームだけなら、Webサイトの機能として扱える場合があります。会員履歴や自動振り分けに加えて、承認、請求、外部同期まで行う場合は、Webシステムとして設計します。発注時は、画面数だけでなく、誰がどのデータをどんな条件で処理するかを伝えます。
発注前に決めるべき三つのこと
発注前に、課題、利用者と業務範囲、成果を測るKPIを整理しておきます。現状と目標を並べておくと、機能の要否を判断する材料になります。
- 業務課題：入力作業や申請の滞留など、解決したい問題。
- 利用者と業務範囲：誰がどの業務で使うか。
- KPI：受注から在庫引当までの時間など、成果を測る指標。
目的が曖昧なまま機能を増やすと、見積金額が上がりがちです。
稼働後に使われない画面も残りがちです。
発注形態の選び方
発注形態は、業務を製品に合わせられるか、独自機能がどこまで必要か、社内に人材がいるかで選びます。初期費用だけで決めると、後から生じる負担を見落としかねません。そのため、月額利用料、追加開発、データ移行、解約時の移行負担も含めて、3年程度の総保有コストで比べます。
SaaS・パッケージが向く場合
標準機能を使う方法には、サービス利用型と業務テンプレート型があります。
- SaaS：サービスを月額または従量で利用します。
- パッケージ：業務テンプレートに設定やカスタマイズを加えます。
SaaSは、申請、顧客管理、予約、勤怠などを早く始めたい場合に向きます。
SaaSもパッケージも、ゼロからの開発より短期間で済む方法です。ただし、ユーザー数、データ容量、API回数のほか、権限、バックアップ、解約時のデータ形式も、導入前に確かめておきます。
ローコード・部分開発・スクラッチの使い分け
発注側は、業務の定型度や独自機能の必要性に応じて、開発方法を選びます。
- ローコード：申請や台帳などの定型処理に使います。
- 部分開発：既存サービスに足りない機能を、API連携などで補います。
- カスタム開発：独自業務や競争優位に関わる機能を作ります。
独自機能を作る場合は、クラウド上のカスタム開発やスクラッチ開発を選べます。
最小限のMVP（Minimum Viable Product）で反応を確かめてから拡張する方法も有効です。
要件が変わりそうな新規サービスは、最初から大規模な基盤を契約すると負担が膨らみます。未使用機能への投資や仕様変更の負担が増えやすいためです。
RFPと要件整理の準備範囲
RFP（提案依頼書）は、開発会社に提案と見積もりを依頼する資料です。
RFPは、完成した仕様書である必要はありません。各社の提案を同じ条件で比べるための準備であり、発注先に丸投げする文書ではありません。知っている事実、決めたい事項、提案してほしい事項は分けて書きます。
IPAの「DX SQUARE 要件定義とは？」も、要件定義をユーザー企業とベンダー企業の認識合わせと説明しています。
RFPに記載する目的・利用者・業務フロー
開発会社に提案を依頼する前に、業務と必要な条件をRFPにまとめます。
- 目的と条件：背景・課題、対象ユーザー、希望時期、予算を書きます。
- 業務範囲：現行業務、対象データ、既存システム、外部連携を示します。
- 画面要件：権限、入力項目、検索条件、登録後の処理、エラー時の扱いを含めます。
- 運用と共有資料：運用担当を決め、資料があれば業務フロー図、現行帳票、サンプルデータ、既存API仕様を共有します。
資料を共有する先とは、守秘義務を結びます。
機能要件と非機能要件の書き分け
RFPでは、システムの処理内容と品質・運用の条件を分けて示します。
- 機能要件：システムが実行する処理です。
- 非機能要件：品質や運用に関する条件です。
機能要件には、会員登録、ログイン、検索、承認といった処理があります。
機能要件には、通知、決済、CSV入出力なども含まれます。
非機能要件には、同時アクセス数、応答時間、稼働時間があります。加えて、バックアップ、復旧目標、対応ブラウザも含まれます。アクセシビリティ、監査ログ、保守窓口も対象です。
「安全に」「快適に」といった表現は、各社の提案を比べる材料になりにくいです。要件は、ピーク時の同時利用者数や障害時の一次回答時間など、確認できる表現で書きます。
発注側は、データを何時間前まで復元するかも決めておきます。
要求を具体的にしておくと、各社の提案の差が見えてきます。
認証・権限・個人情報・データ移行の定義
個人情報や決済情報を扱う場合は、ID・パスワードだけでよいか、多要素認証が必要かをRFPに含めます。
発注側は、部署・役職ごとの閲覧・編集範囲と、操作ログの保存期間も定めます。
個人情報保護委員会の現行ガイドラインも、アクセス制御、識別・認証、不正アクセス防止を安全管理措置の論点に挙げています。
- 通信設定：IPAの2025年4月公開「TLS暗号設定ガイドライン」の推奨設定を確認します。
- 委託先：脆弱性診断、秘密情報、再委託先、事故報告の期限を確かめます。
委託先への確認事項を先に決めておくと、各社のセキュリティ要件を同じ基準で比べられます。
旧システムやExcelにある顧客・商品・取引データは、件数も調べておきます。発注側は、欠損・重複の状態と移行後の照合方法も早めに確かめます。
決めないまま開発を進めると、稼働直前に整形作業が発生します。その結果、追加費用やリリース延期につながります。そこで、移行対象は要件整理の段階で決めておきます。
契約形態と開発の進め方
契約形態は、工程の性質に合わせて選びます。全工程を最初から一つの契約に固定しない方法もあります。
要件整理、設計・開発、テスト・移行、保守改善の区切りで、納品物と責任を決めておきます。そうすると、前提の変化を扱いやすくなります。
発注者側も、納期と品質を管理します。発注者側は、会議体、承認者、変更手続き、検収基準も、契約書と合わせて定めます。
請負契約が向く工程
請負契約を使う工程では、納品物と変更時の扱いを明確にします。
- 契約の基本：合意した納品物を完成させ、検収を受ける形です。
- 適用条件：受け入れ条件と引き渡すものが明確な工程に適しています。
- 納品物：画面、機能、設計書、テスト結果などを定めます。
- 変更管理：仕様変更の定義、承認者、追加工数の算定方法を契約か別紙に明記します。
要件が曖昧なまま固定金額と完成責任を置くと、変更が出たときに追加見積もりや納期調整が起きます。
準委任契約が向く探索・継続の工程
準委任契約は、専門家として一定の業務を遂行する契約です。要件定義、技術検証、アジャイル開発、運用改善に使いやすい方法です。
- 探索：要件定義や技術検証など、成果の形を探る工程。
- 継続業務：アジャイル開発や運用改善など、作業を続ける工程。
稼働時間だけでなく、週次の成果と課題一覧を確認します。
決定事項と次週の計画も、あわせて見ておきます。
IPAの「情報システム・モデル取引・契約書」は、請負と準委任の報酬請求権などを整理しています。
契約内容は、法務担当者や専門家にも確認します。
検収・知財・データ返却の取り決め
契約では、検収条件、知的財産、システム資産の管理と引き継ぎを定めます。
- 検収：期間、不具合の定義、無償修正の範囲を確認します。
- 知的財産：著作権、ソースコードの帰属、第三者ライブラリの扱いを定めます。
- 資産管理：クラウド、ドメイン、暗号鍵、データベース、ログの管理主体を決めます。
- アカウント移管：発注者名義にするか、委託先管理時の退去手順を決めます。
- 委託管理：再委託、担当変更、秘密保持、個人情報、事故時の連絡先を確認します。
管理主体が曖昧なままだと、別の会社への移管や内製化が難しくなります。
Webシステム外注の費用相場
費用は機能数だけでなく、利用者数、権限、外部連携で変わります。さらに、データ移行や性能、セキュリティ、運用時間でも変わります。
一律の金額は断定できないため、公開相場と、リサーチノートに基づく規模別の実務目安を分けて示します。公開相場と実務上の概算は性質が異なります。そのため、実際の予算は同じRFPを複数社に渡して確かめます。
公開情報から見る初期費用のレンジ
次の公開相場は、秋霜堂株式会社「システム開発の費用相場」（2026年7月更新）とSIA株式会社「システム開発の費用・相場」（2026年公開）に基づきます。
- SaaS：初期費用は無料〜100万円が目安です。
- パッケージ：100万〜300万円、フルスクラッチは300万円以上です。
- 人月単価：SIA株式会社の記事では60万〜200万円程度です。
秋霜堂の価格帯には、機能を限定した小〜中規模の案件が含まれます。
要件定義や大規模移行を含む案件には、そのまま当てはまりません。
規模別の実務目安（100万〜5,000万円以上）
規模や連携の複雑さに応じた概算を並べると、予算検討の起点になります。
- 小規模：会員・予約・申請・簡易業務アプリは100万〜300万円、1〜3か月。
- SaaS設定中心：API連携を含め50万〜300万円、数週間〜3か月。
- 中規模：顧客管理、受発注、在庫、社内ポータルは500万〜1,500万円、3〜8か月。
- 大規模：EC・金融・公共系、複数拠点の基幹連携は1,500万〜5,000万円以上、6〜18か月。
前の一覧の金額と期間は、リサーチノートに基づく概算です。
中規模は権限や複数連携、大規模は24時間運用を含む想定です。
後半の二つのレンジと期間は、公表相場、NotebookLMリサーチの「複数領域のスクラッチ開発は半年〜1年以上」という整理、一般的な工程量からの推定です。
数字は、公定価格や統計的な平均とは別の目安です。見積もりでは、想定人月や担当ロール、工程を確認します。さらに、除外事項と前提条件も確かめます。
相場から外れる場合は、その理由を説明してもらいます。
発注側は、金額だけで判断しないことが特に大切です。
初期費用と3年TCOの比較
開発時の支出と稼働後に続く支出を分けると、総費用を比べやすくなります。
- 開発費：要件定義と設計（画面・UX、アーキテクチャ）、実装とテスト、データ移行、リリース支援、プロジェクト管理。
- 運用費：基盤（クラウド、データベース、ストレージ）、監視、バックアップ、ドメイン、メール・SMS。
- 継続費用：決済手数料、脆弱性診断、保守契約、追加開発も確認します。
- 3年TCO：初期費用に36か月分の運用・移行・教育・改善費を加えます。
管理費やテスト費は、実装費に含める会社もあれば、別に計上する会社もあります。そのため、総額だけの比較は危険です。
人件費は「人月単価×工数」で考えます。たとえば、3人が2か月稼働する場合は6人月です。
単価だけでなく、PM、業務担当、デザイナー、エンジニア、テスターの構成も見ます。初期費用が低くても、ユーザー数やAPI利用量に応じて月額が増えるサービスがあります。そのうえで、障害や手作業が減る効果も含めて社内で比べます。
委託先の選び方と見積比較のポイント
委託先は、知名度や総額だけでなく、自社業務への理解と稼働後の責任で選びます。
候補を3〜5社程度に絞り、同じRFP、質疑回答、期限をそろえて提案を依頼します。そうすると、各社の違いが見えてきます。打ち合わせでは、候補企業が不明点をどう質問するか、どのリスクを先に指摘するかも評価します。
類似事例と実際の担当チーム
実績の内容と、契約後に案件を担当するチームを確かめます。
- 案件条件：利用者数、データ量、外部連携、セキュリティ水準、開発期間、稼働後の保守体制。
- 実施体制：要件定義担当、PM、開発者、テスト担当、保守窓口。
類似事例は、業界名だけで判断せず、自社の規模や進め方に合うかを確認します。
大手企業向けの実績が、自社の規模に合うとは限りません。
再委託やオフショア開発がある場合は、範囲と責任者を明らかにします。
品質管理と情報管理の扱いも確かめます。
同じ項目に分けた見積書の比較
各社の見積もりを同じ工程と機能範囲にそろえると、金額差の理由を判断できます。
- 工程：要件定義と設計、実装とテスト、移行、教育、インフラ、保守。
- 機能範囲：管理画面と権限、エラー処理、スマホ対応、CSVやAPI、決済、ログ。
比較表には、各社の金額、工数、担当を記録します。納品物や期間も、同じ表に入れておきます。見積書に「一式」とある場合は、内訳と前提を質問します。
バックアップ、脆弱性診断、受け入れテストも確認します。
安い見積もりでは、重要作業が除外されていないかに注意します。
金額差が大きい場合は、要件理解や品質、体制の前提をそろえて比べます。
製品利用や外部費用の前提も確かめます。
代替案があれば、条件ごとの差を説明してもらいます。たとえば、必須機能を保つ案、納期を優先する案、将来の拡張性を優先する案などです。
提案の品質と運用・引き継ぎの評価
提案書では、開発方法やスケジュール、リスクを確認します。さらに、意思決定の方法、テスト方針、移行計画も見ます。
- 引き継ぎ：ソースコード、設計書、設定、テストコード、運用手順書の受領形式を決めます。
- APIの安全性：認証、認可、レート制限、入力検証、ログ、監視を提案に含めます。
納品後の監視や障害対応も確認します。利用状況を見ながら改善を続けるためです。社内担当者への教育や別会社への移管も、契約前に確認しておきます。
NISTのSP 800-228更新1は、クラウドネイティブAPIのリスクを開発前と稼働時に確認する考え方を示しています。この考え方では、基本から高度な対策へ、段階的に進めます。
診断と監視は、データや事業停止の影響に応じて選びます。ただし、すべてを最高水準にそろえる必要はありません。
よくある質問
発注方法を検討する担当者から寄せられることの多い疑問に答えます。最適な方法は、自社の条件で変わります。
ここでの回答を金額や契約の断定に使わず、RFPと候補先との質疑で具体化してください。
Webシステムの発注先は何社くらいに相談すべきですか？
候補を3〜5社程度に絞り、同じRFPと条件で2〜3社から正式提案と見積もりを受けます。
候補が多いと、質疑と比較に時間がかかります。そこで、業界や規模、技術、保守要件に合う会社を先に選びます。
見積もりの数よりも、同じ前提で比べられることが重要です。
要件が決まっていなくてもWebシステム開発を依頼できますか？
依頼できます。要件定義や技術検証は、準委任などの探索工程として先に発注する方法が適しています。
- 相談前の整理：目的、利用者、現状業務を整理して相談します。
- 相談で伝えること：困りごと、希望時期、予算上限も伝えます。
- 探索の区切り：要件整理の納品物と、次工程へ進む判断基準を決めておくと、予算を管理しやすくなります。
安い見積もりと高い見積もりはどこを見比べればよいですか？
総額よりも、要件範囲、工数、体制、納品物をそろえて比べます。テスト、移行、保守、除外事項も、同じ条件にそろえます。
- SaaSや既存部品の活用：安さの理由なら合理的です。
- 除外の有無：要件定義やセキュリティ、移行、障害対応が除外される場合もあります。
- 各社への確認：同じ質問をしたうえで、3年TCOと事業停止リスクも含めて判断します。
外注後に自社で運用できるようにするには何を確認すべきですか？
外注後も自社で運用を続けるため、次の項目を契約の段階で取り決めておきます。
- 資料の受け渡し：ソースコード、設計書、テスト結果、環境情報の範囲と権限を決めます。
- 運用に必要な情報：アカウント、データ、ログ、手順書も、範囲と権限を取り決めます。
- 障害対応の窓口：問い合わせ窓口、障害の優先度と対応時間を契約に含めます。
- 契約の範囲：バックアップ、復旧、脆弱性対応、追加開発の単価も含めます。
- ベンダー依存の回避：教育と引き継ぎの期間を設けると、特定の会社だけが分かる状態を減らせ、ベンダーロックイン対策になります。
まとめ
機能の依頼より前に、業務課題、利用者、データ、KPIを整理します。これが、必要なシステムを決める出発点です。
SaaS、パッケージ、ローコード、カスタム開発、スクラッチを、柔軟性や運用負担で比べます。そのうえで、拡張性やデータ返却も判断材料になります。
RFPと契約で発注の前提をそろえること
RFPには、機能・非機能要件、認証・権限、セキュリティを書きます。さらに、移行、テスト、保守、引き継ぎも含めます。納品物が固まった工程は請負、探索や継続改善は準委任など、工程に合う契約を検討します。
検収や変更管理、知財は契約書に盛り込みます。さらに、ソースコード、クラウドアカウント、データ返却も含めます。
見積もりの比べ方（範囲と3年TCO）
相見積もりでは、工数、体制、納品物を同じ条件で比べます。さらに、除外事項と運用費も見ます。公開相場は、検討の起点として使います。
最終費用は、要件と品質水準で決まります。
リスクや稼働後の改善、内製化まで具体的に提案できる委託先を選びます。
▼全体ガイドの記事
・Webシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。