Webシステム開発の発注/外注/依頼/委託方法について

Webシステムの発注・外注は、作りたい機能を伝えて見積もりを取るだけでは成功しません。自社の業務課題と必要な成果を整理し、SaaS・パッケージ・スクラッチ開発などの発注形態、契約、運用保守まで一体で決めることが、予算超過や納期遅延を防ぐ基本です。

この記事では、Webシステム開発を依頼する前の準備から、RFP（提案依頼書）の作り方、請負・準委任の選び方、2026年時点の費用相場、委託先と見積書の比較方法までを順番に解説します。Webサイト制作との違いにも触れながら、初めて発注する担当者が社内稟議とベンダー選定を進められる状態を目指します。

▼全体ガイドの記事
・Webシステム開発の完全ガイド

Webシステムを発注・外注する前に知る全体像

まず押さえたいのは、Webシステムが「情報を見せるWebサイト」ではなく、利用者の操作に応じてデータを処理する仕組みだという点です。ログイン、権限管理、検索、申請・承認、決済、在庫更新、外部API連携などが必要になれば、画面の見た目だけでなくデータベース、認証、監視、障害対応まで発注範囲に含めて考えます。

Webサイトは企業情報や商品情報などを閲覧してもらうことが主目的ですが、Webシステムは利用者ごとに異なる処理を実行し、データを登録・更新・連携します。たとえば、問い合わせフォームだけならWebサイトの機能として扱える場合がありますが、会員ごとの履歴管理、担当者への自動振り分け、承認、請求、外部サービスとの同期まで行うならWebシステムとして設計する必要があります。発注時は「画面を何枚作るか」だけでなく、「誰が、どのデータを、どの条件で、どこまで処理するか」を説明することが重要です。

発注前には、第一に解決したい業務課題、第二に利用者と業務範囲、第三に成功を測るKPIを整理します。「入力作業を減らしたい」「申請の滞留を見える化したい」「受注から在庫引当までの時間を短縮したい」のように、現状と目標を並べると、必要な機能と不要な機能を区別しやすくなります。目的が曖昧なまま機能を増やすと、見積金額は上がる一方で、稼働後に使われない画面が残りやすくなります。

発注形態はどれを選ぶべきですか？

発注形態は、業務を製品に合わせられるか、独自性をどこまで実装するか、社内に運用できる人材がいるかで選びます。初期費用の安さだけで決めるのではなく、月額利用料、追加開発、データ移行、サービス終了時の移行負担を含む3年程度の総保有コストで比べると、判断を誤りにくくなります。

SaaSは、ベンダーが提供するサービスを月額または従量で利用する方法です。申請、顧客管理、予約、勤怠など、一般的な業務を早く始めたい場合に向いています。パッケージは業務テンプレートを導入し、必要に応じて設定やカスタマイズを加える方法です。どちらもゼロから作るより短期間になりやすい一方、ユーザー数、データ容量、API回数、権限設定、バックアップ、解約時のデータ形式を事前に確認する必要があります。

申請や台帳など定型処理はローコード、既存サービスに足りない部分はAPI連携や追加開発、独自の業務フローや競争優位に関わる部分はクラウド上のカスタム開発やスクラッチ開発、という分け方が現実的です。全機能を一度に作らず、最小限のMVPで利用者の反応を確認してから拡張する方法も有効です。特に、要件がまだ変わりそうな新規サービスは、最初から大規模な基盤を契約すると、使わない機能への投資と仕様変更の負担が膨らみやすくなります。

RFPと要件整理はどこまで準備すればよいですか？

RFPは、開発会社に提案と見積もりを依頼するための資料です。完成した仕様書でなくても構いませんが、発注者が知っている事実、決めたい事項、提案してほしい事項を分けて書くことが大切です。IPAの「DX SQUARE 要件定義とは？」でも、要件定義はユーザー企業とベンダー企業の認識を合わせる工程と説明されています。RFPを整えることは、発注先に丸投げするためではなく、同じ条件で提案を比較するための準備です。

最低限、背景と解決したい課題、対象ユーザー、利用開始希望時期、予算の考え方、現行業務の流れ、対象データ、既存システム、外部連携、納品後の運用担当を記載します。画面一覧を作る場合は、画面名だけでなく、利用者の権限、入力項目、検索条件、登録後に起きる処理、エラー時の扱いまで分かるようにします。業務フロー図、現行帳票、サンプルデータ、既存APIの仕様があれば、守秘義務を結んだ候補先に共有します。

機能要件は、会員登録、ログイン、検索、承認、通知、決済、CSV入出力など、システムが実行する処理です。一方、非機能要件は、同時アクセス数、応答時間、稼働時間、バックアップ、復旧目標、対応ブラウザ、アクセシビリティ、監査ログ、保守窓口など、品質と運用に関する条件です。「安全に」「快適に」では比較できないため、たとえばピーク時の同時利用者数、障害時の一次回答時間、データを何時間前まで復元できればよいかのように、確認できる表現へ変換します。

個人情報や決済情報を扱うなら、ID・パスワードだけでよいのか、多要素認証が必要か、部署・役職ごとに何を閲覧・編集できるか、操作ログを何期間保存するかをRFPに含めます。個人情報保護委員会の現行ガイドラインは、アクセス制御、識別・認証、外部からの不正アクセス防止などを安全管理措置の論点として示しています。TLSについては、IPAが2025年4月公開の「TLS暗号設定ガイドライン」で推奨設定を整理しています。委託先に対しては、脆弱性診断、秘密情報の管理、再委託先、事故報告の期限も質問します。

データ移行は後回しにされがちですが、旧システムやExcelにある顧客・商品・取引データの件数、欠損や重複の状態、移行後の照合方法を早めに確かめます。移行対象を決めないまま開発を始めると、稼働直前にデータ整形の作業が発生し、追加費用とリリース延期につながります。

契約形態と開発の進め方はどう決めますか？

Webシステムの外注では、契約形態を工程の性質に合わせることが重要です。最初から全工程を一つの契約に固定するより、要件整理、設計・開発、テスト・移行、保守改善の区切りで成果物と責任を定めると、前提の変化を扱いやすくなります。納期と品質を管理するのは発注者側でもあるため、契約書だけでなく、会議体、承認者、変更手続き、検収基準まで決めます。

請負契約は、合意した成果物を完成させ、検収を受けることを中心にした契約です。画面、機能、設計書、テスト結果などの納品物と、受け入れ条件が明確な場合に適しています。ただし、発注時点で要件が曖昧なのに完成責任と固定金額だけを先に置くと、変更のたびに追加見積もりや納期調整が起きます。仕様変更の定義、変更依頼の承認者、追加工数の算定方法を契約または別紙に明記します。

準委任契約は、一定の業務を専門家として遂行することを目的にした契約です。要件定義、技術検証、アジャイル開発、運用改善のように、作業を進めながら成果の形が変わる工程で使いやすい方法です。時間や体制を基準に精算することが多いため、稼働時間だけでなく、週次の成果、課題一覧、意思決定事項、次週の計画を確認できるようにします。IPAの「情報システム・モデル取引・契約書」では、請負契約と準委任契約の報酬請求権などが整理されています。実際の契約は自社の法務担当者や専門家と確認します。

契約書では、検収期間、瑕疵や不具合の定義、無償修正の範囲、著作権やソースコードの帰属、第三者ライブラリの扱いを確認します。加えて、クラウドアカウント、ドメイン、暗号鍵、データベース、ログの管理主体を明確にします。発注者名義のアカウントにするか、委託先が管理する場合の退去手順を決めておかないと、別会社への移管や内製化が難しくなります。再委託の可否、担当者変更、秘密保持、個人情報の取扱い、事故時の連絡先も同じです。

Webシステム外注の費用相場はいくらですか？

Webシステムの費用は、機能数だけでなく、利用者数、権限の複雑さ、外部連携、データ移行、性能、セキュリティ、運用時間で大きく変わります。したがって、「Webシステムなら一律いくら」と断定することはできません。以下は公開相場と、リサーチノートに基づく規模別の実務上の目安を分けたレンジです。実際の予算は、同じRFPを複数社へ渡して確認します。

2026年7月更新の秋霜堂株式会社「システム開発の費用相場」では、SaaS型の初期費用を無料〜100万円、パッケージ型を100万〜300万円、フルスクラッチを300万円以上の公開目安として整理しています。これは機能が限定された小〜中規模案件を含む相場情報で、要件定義や大規模な移行を含む案件へそのまま当てはめるものではありません。また、2026年公開のSIA株式会社の相場記事では、人月単価を60万〜200万円程度としています。出典: 秋霜堂株式会社「システム開発の費用相場」、2026年7月更新、SIA株式会社「システム開発の費用・相場」、2026年公開。

リサーチノートで整理した実務上の概算では、小規模な会員、予約、申請、簡易業務アプリは100万〜300万円、期間は1〜3か月が一つの目安です。既存SaaSやパッケージの設定とAPI連携中心なら、初期50万〜300万円、数週間〜3か月程度を想定します。中規模の顧客管理、受発注、在庫、社内ポータルで権限や複数連携を含む場合は500万〜1,500万円、3〜8か月程度です。大規模EC、金融・公共系、複数拠点の基幹連携、24時間運用を含む場合は1,500万〜5,000万円以上、6〜18か月程度が目安になります。

後半二つのレンジと期間は、公表相場、NotebookLMリサーチの「複数領域のスクラッチ開発は半年〜1年以上」という整理、一般的な工程量からの推定であり、公定価格や統計的な平均ではありません。見積もりを受け取ったら、金額だけでなく、想定人月、担当ロール、対象工程、除外事項、前提条件を確認し、レンジから外れる理由を説明してもらいます。

見積書では、要件定義、画面・UX設計、アーキテクチャ設計、実装、テスト、データ移行、リリース支援、プロジェクト管理を別項目で確認します。開発会社によって、管理費やテスト費が実装費に含まれる場合と、別計上される場合があるため、単純な総額比較は危険です。人件費は「人月単価×工数」で考え、たとえば3人が2か月稼働する場合は6人月です。単価だけでなく、PM、業務担当、デザイナー、エンジニア、テスターの構成を見ます。

稼働後には、クラウド、データベース、ストレージ、監視、バックアップ、ドメイン、メール・SMS、決済手数料、脆弱性診断、保守契約、追加開発の費用が発生します。初期費用が低くても、ユーザー数やAPI利用量で月額が増えるサービスがあります。3年TCOでは、初期開発費に36か月分の運用費、移行費、教育費、改善費を加え、障害や手作業が減る効果も含めて社内で比較します。

委託先の選び方と見積比較のポイント

委託先は、知名度や見積総額だけでなく、自社の業務を理解し、稼働後まで責任を持てるかで選びます。候補を3〜5社程度に絞り、同じRFP、同じ質疑回答、同じ期限で提案してもらうと、提案内容の差が見えやすくなります。発注前の打ち合わせでは、候補企業が分からない点をどのように質問し、どのリスクを先に指摘するかも評価します。

類似事例は、業界名だけでなく、利用者数、データ量、外部連携、セキュリティ水準、開発期間、稼働後の保守体制まで確認します。大手企業向けの実績があっても、自社の規模に合う進め方とは限りません。提案時に、要件定義を担当する人、プロジェクトマネージャー、主な開発者、テスト担当者、保守窓口を示してもらい、契約後も同じ体制が続くかを確認します。再委託やオフショア開発がある場合は、範囲、品質管理、情報管理、責任者を明らかにします。

比較表には、要件定義、設計、実装、テスト、移行、教育、インフラ、保守を横に並べ、各社の金額、工数、担当、納品物、期間を記録します。見積もりの「一式」は、内訳と前提を質問します。特に、管理画面、権限設定、エラー処理、スマートフォン対応、CSV、API、決済、ログ、バックアップ、脆弱性診断、受け入れテストが含まれるかを確認します。安い見積もりほど、除外事項に重要な作業が移っていないか注意します。

見積もりの差が大きい場合は、安い会社を選ぶ前に、要件の理解、想定する品質、開発体制、再利用する製品、外部費用の扱いをそろえます。提案内容に代替案がある場合は、必須機能を維持しながら初期費用を下げる案、納期を優先する案、将来拡張性を優先する案のように、条件ごとの違いを説明してもらいます。

提案書では、開発方法、スケジュール、リスク、意思決定の方法、テスト方針、移行計画、リリース後の監視と障害対応を読みます。Webシステムは納品した時点で終わりではなく、利用状況を見ながら改善します。ソースコード、設計書、環境設定、テストコード、運用手順書をどの形式で受け取れるか、社内担当者へどのような教育を行うか、別会社へ移管できるかを契約前に確認します。

クラウドやAPIを使う案件では、認証、認可、レート制限、入力検証、ログ、監視を提案に含めます。NISTのSP 800-228更新1は、クラウドネイティブAPIのリスクを開発前と稼働時のライフサイクルで確認し、基本的な対策から高度な対策へ段階的に進める考え方を示しています。すべてを最高水準にするのではなく、扱うデータと事業停止時の影響に応じて、必要な診断と運用監視を選びます。

よくある質問

発注方法を検討する担当者から、よく寄せられる疑問に回答します。自社の条件によって最適解は変わるため、回答をそのまま金額や契約の断定として使わず、RFPと候補先との質疑で具体化します。

候補を3〜5社程度に絞って相談し、同じRFPと条件で2〜3社から正式な提案・見積もりを受ける進め方が現実的です。候補が多すぎると質疑と比較に時間がかかるため、自社の業界・規模・技術・保守要件に合う会社を先に選びます。見積もりの数より、同じ前提で比較できることが重要です。

依頼できますが、いきなり完成品の固定見積もりを求めるのではなく、要件定義や技術検証を準委任などの探索工程として先に発注する方法が適しています。目的、利用者、現状業務、困っていること、希望時期、予算の上限だけでも整理して相談します。要件整理の成果物と、次の開発工程へ進む判断基準をあらかじめ決めておくと、予算を管理しやすくなります。

総額ではなく、要件の範囲、工数、担当体制、納品物、テスト、移行、保守、除外事項をそろえて見比べます。安い理由がSaaSや既存部品の活用であれば合理的ですが、要件定義、セキュリティ、データ移行、障害対応が除外されている可能性もあります。各社へ同じ質問を行い、3年TCOと事業停止リスクまで含めて社内で判断します。

ソースコード、設計書、テスト結果、環境情報、アカウント、データ、ログ、運用手順書の受け渡し範囲と権限を確認します。リリース後の問い合わせ窓口、障害の優先度、対応時間、バックアップと復旧、脆弱性対応、追加開発の単価も契約に含めます。担当者への教育と引き継ぎ期間を確保し、特定の会社だけが分かる状態を減らすことが、ベンダーロックイン対策になります。

まとめ

Webシステムの発注・外注を成功させるには、機能の依頼から始めず、業務課題、利用者、データ、KPIを整理することが出発点です。そのうえで、SaaS・パッケージ・ローコード・カスタム開発・スクラッチを、初期費用だけでなく柔軟性、運用負担、拡張性、データ返却まで含めて選びます。

RFPには、機能要件だけでなく、非機能要件、認証・権限、セキュリティ、データ移行、テスト、保守、引き継ぎを書きます。成果物が固まった工程は請負、探索や継続改善は準委任など、工程に合う契約を検討し、検収、変更管理、知財、ソースコード、クラウドアカウント、データ返却を明文化します。

相見積もりでは、同じ条件で各社の工数、体制、納品物、除外事項、運用費を比較します。公開相場は判断の起点であり、最終的な費用は要件と品質水準で決まります。候補先が発注前にリスクを指摘し、稼働後の改善と内製化まで具体的に提案できるかを見極めることが、長く使えるWebシステムにつながります。

▼全体ガイドの記事
・Webシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。