モノリシックのシステム開発の発注/外注/依頼/委託方法について

モノリシックのシステムを発注・外注するなら、最新技術へ置き換えることを目的にせず、現行業務のどこを残し、どこを整理し、どこを作り直すかを決めてから依頼することが重要です。

モノリシックのシステム開発は、画面だけでなく、データ、権限、外部連携、帳票、バッチ、移行、運用までが一体になりやすいため、発注形態や契約、RFP、見積もりの見方を誤ると、開発途中の追加費用やリリース後の保守負担につながります。本記事では、発注前の判断から委託先の選定、2026年時点の費用相場、契約上の注意点まで、外注を進める実務を解説します。

▼全体ガイドの記事
・モノリシックのシステム開発の完全ガイド

モノリシックのシステムを発注・外注する前に何を決めますか？

発注前に決めるべきなのは、モノリスを採用するかどうかだけではありません。対象業務、利用者、処理量、将来の変更頻度、停止できる時間、社内の運用体制を整理し、構成と外注範囲を合わせて考えます。安定稼働しているモノリスを無理に分割するより、内部の境界を整理してクラウドへ移す方が効果的なケースもあります。

最初に、現行システムが本当に困らせていることを言語化します。たとえば、受注登録のたびに在庫・請求・会計へ手入力している、月末のバッチ処理に時間がかかる、担当者しか修正方法を知らない、1つの改修で全機能のテストが必要になる、といった事象です。「古い技術だから刷新する」という理由だけでは、外注先が作るべき成果や優先順位を決められません。

診断では、業務フロー、コードベース、データベース、外部連携、帳票、夜間バッチ、利用者と権限、監視・バックアップを一覧にします。仕様書が不足していても、ソースコード、テーブル定義、画面キャプチャ、帳票サンプル、障害記録、現場ヒアリングを組み合わせれば、現行資産の全体像を復元できます。特に「変更の多い領域」「止まると損失が大きい領域」「廃止しても困らない領域」を分けると、発注範囲を絞りやすくなります。

発注形態は、すべてを1社へ任せる一括発注、要件定義・設計・開発・保守を工程ごとに分ける工程分割発注、既存システムを動かしながら機能単位で移す段階移行に分けて考えられます。一括発注は責任の窓口を一本化しやすい一方、提案会社の判断に依存しやすくなります。工程分割発注は比較の透明性を高めやすい一方、会社間の引き継ぎや責任分界を発注側が管理する必要があります。

既存モノリスを段階的に刷新する場合は、受注、顧客、在庫などの業務領域から優先順位を決め、旧システムとのデータ連携や切り戻し条件を先に設計します。AWSのStrangler Figパターンは、モノリス全体を一度に作り直さず、機能を段階的に移して新旧の経路を切り替える考え方です（出典: AWS Prescriptive Guidance「Decomposing monoliths into microservices」、2026年確認）。ただし、移行中は二重運用や整合性確認が増えるため、段階移行が常に安いとは限りません。

モノリシックのシステムの発注・外注はどの順番で進めますか？

モノリシックのシステムを外注する流れは、現状把握、発注方式の比較、RFP作成、候補会社への提案依頼、要件定義、契約、設計・開発、移行・受入テスト、保守開始の順に進めると整理しやすいです。実務では要件が完全に固まっていない段階から相談して構いませんが、不明点を仮定のまま進める範囲と、調査して確定する範囲を分けて記録します。

外注すれば発注側の作業がなくなるわけではありません。経営判断をする決裁者、業務上の正解を判断する業務責任者、技術とセキュリティを確認するIT担当者、契約を確認する法務・購買担当者を決めます。担当が曖昧なままだと、開発会社が仮の仕様で進めた後に、現場から異なる要望が出て手戻りが発生します。

発注側では、現行の業務フロー、利用者数、拠点数、月間処理件数、ピーク時の処理量、連携先、データ件数、帳票、希望稼働日、予算レンジを集めます。要件定義の初期は業務担当者のヒアリングや資料確認に週1〜2日程度を見込み、開発中はレビューと意思決定、移行前後は受入テストと現場周知の時間を確保します。社内工数も、外注費とは別に予算と計画へ含めます。

候補会社は、過去の取引先からの紹介、システム開発会社の実績検索、業界団体やマッチングサービスなど複数の経路で探します。最初から候補を増やしすぎると、質問への回答や評価が浅くなるため、RFPを提出する会社は3〜5社程度、最終比較は2〜3社程度に絞る方法が現実的です。2026年公開のCataly Designの外注手順でも、目的整理、要件洗い出し、複数社比較、設計、開発・テスト・運用の順序が示されています（出典: Cataly Design「業務システム開発の費用相場」、2026年）。

会社ごとに異なる情報を渡すと、安い見積もりが実は機能やテストを含んでいない、といった比較ミスが起きます。質問事項、回答期限、提案に含める成果物、見積もりの税区分、保守期間、再委託の有無をそろえます。提案書には、発注者の課題をどう理解したか、採用する方式と採用しない方式、前提・除外事項、リスクと対策、体制、工程、費用を明記してもらいます。

RFPと要件整理には何を書けばよいですか？

RFPは、開発会社へ提案を依頼するための資料です。完成した仕様書でなくても、なぜ発注するのか、どの業務を対象にするのか、何を成功とみなすのかを共有できれば、提案の前提をそろえられます。モノリシックのシステムでは、目に見える画面一覧だけでなく、同じ処理の裏側で動くデータと連携をRFPに含めることが欠かせません。

機能要件は、「受注管理機能が必要です」と書くだけでなく、利用者が何を入力し、誰が承認し、在庫・請求・会計へ何を連携し、例外時にどう処理するかを業務シナリオで示します。たとえば「見積登録→承認→受注確定→在庫引当→出荷→請求→会計連携」の一連の流れを、通常処理と取消・返品・分割請求などの例外処理に分けます。

機能は、稼働日に必須の範囲、初期リリース後に追加する範囲、廃止・代替する範囲に分類します。画面数だけでなく、帳票の種類、承認経路、権限ロール、CSV入出力、バッチ頻度、通知、検索条件、履歴保持期間を明記します。優先順位がないRFPは、会社側がすべてを必須と解釈し、費用と期間が膨らみやすくなります。

非機能要件には、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境を含めます。IPAの非機能要求グレードは、これらの項目を上流工程で整理するための基準です（出典: IPA「システム構築の上流工程強化」、2026年確認）。「速い」「止まらない」ではなく、ピーク時の同時利用者数、検索応答時間、月間稼働率、復旧目標時間、バックアップ頻度、ログ保存期間のように数値化します。

モノリスでは一つの障害が複数業務に波及する可能性があるため、業務ごとの停止許容時間と、全体障害時の復旧手順を確認します。個人情報を扱う場合は、最小権限、管理者権限の分離、多要素認証、通信・保存データの暗号化、監査ログ、脆弱性対応、委託先管理、インシデント連絡体制をRFPへ入れます。IPAのIT製品調達向けセキュリティ要件リストも、委託先に求める確認項目を整理する入口になります（出典: IPA「IT製品の調達におけるセキュリティ要件リスト」、2026年確認）。

既存モノリスの外注で見落とされやすいのがデータ移行です。移行対象のテーブル、過去何年分を残すか、コード体系の変換、重複・欠損データの扱い、移行後の照合、旧システムの保存方法を明記します。データクレンジングを発注者が行うのか、開発会社が担当するのか、移行リハーサルを何回行うのかも、見積もりと契約の前提にします。

成果物は、実行ファイルだけでは不十分です。要件定義書、基本・詳細設計書、データ辞書、API仕様、テスト仕様と結果、移行手順、運用手順、インフラ構成、バックアップ・復旧手順、ソースコード、IaC、管理者アカウントの引き渡し範囲を決めます。第三者のOSSや汎用ライブラリを含む場合は、利用許諾とライセンス表示の責任も確認します。

モノリシックのシステム開発はどの契約形態で委託しますか？

システム開発では、成果物の完成を約束する請負契約と、専門的な作業の遂行を委託する準委任契約を工程に応じて使い分けます。契約名だけで責任が決まるのではなく、対象工程、成果物、検収、作業時間、変更管理、報告、損害や再委託の条件を具体的に記載することが重要です。経済産業省のモデル取引・契約書は、フェーズごとの準委任・請負、仕様変更手続き、マルチベンダーや工程分割発注を整理しています（出典: 経済産業省「情報システム・モデル取引・契約書」、2026年確認）。

請負契約は、合意した成果物を完成させ、発注者が検収する工程に向いています。基本設計、詳細設計、機能開発、テスト仕様書など、完成条件を定義しやすい範囲で採用します。検収基準には、単に画面が表示されることだけでなく、業務シナリオ、権限、外部連携、帳票、性能、障害時の動作、データ移行後の照合を含めます。

請負で注意したいのは、要件が曖昧なまま一括固定することです。モノリシックのシステムは、1機能の変更が他の機能やデータへ影響しやすいため、仕様変更の申請方法、影響調査、追加工数、納期変更、承認者を契約書や変更管理表に定めます。納期だけを優先して要件定義や総合テストを削ると、検収後の障害対応でかえって費用が増えます。

準委任契約は、現行資産の調査、業務ヒアリング、要件定義、技術検証、プロジェクト支援、要件が変わりやすいアジャイル開発など、作業の遂行を委託する工程に向いています。要件が確定していない段階で、いきなり完成責任を伴う固定契約にするより、まず調査・要件整理を準委任で依頼し、その成果をもとに開発契約へ進む方法が安全な場合があります。

準委任では、時間単価や人月だけでなく、誰が何を調べ、どの資料を残し、どの会議体で報告するかを定めます。作業時間を請負の完成保証と混同しないよう、成果物、品質目標、責任分界、障害時の対応を別に確認します。開発会社へ丸投げせず、発注者が意思決定を担い、外注先は専門知識と作業を提供する関係を作ることが大切です。

開発費を支払えば、ソースコードや設計書の権利が自動的にすべて発注者へ移るとは限りません。個別に作成したプログラム、画面、データ定義、設計書、テスト成果物、汎用ライブラリ、第三者OSSを分け、著作権の帰属、利用許諾、改修・再委託の可否、著作者人格権の扱いを確認します。契約終了時に別会社へ移管できるよう、リポジトリ、クラウドアカウント、API仕様、データエクスポート、管理者権限の扱いも決めます。

保守契約では、障害一次受付の時間帯、復旧目標、脆弱性修正、OSやフレームワークの更新、法改正対応、バックアップ確認、月次報告の範囲を分けます。月額保守に含まれない追加開発の単価や、契約終了時の引き継ぎ期間・費用も明記します。ベンダーロックインを避けるポイントは、単に複数社へ分散することではなく、発注者が成果物とアクセス権を継続的に保持することです。

モノリシックのシステムを発注・外注する費用相場はいくらですか？

モノリシック固有の公的な一律価格はないため、費用は対象業務、画面数、利用者数、連携数、データ量、性能・可用性、移行難易度、保守範囲で変わります。2026年公開の相場情報を基準にすると、単一業務のカスタムシステムは100万〜500万円、複数業務を統合する基幹システムは1,000万〜3,000万円以上というレンジが示されています（出典: Cataly Design「業務システム開発の費用相場」、2026年）。これは一般的な業務システムの目安であり、モノリスの正式見積もりでは現行調査が必要です。

新規のモノリシックな業務システムは、1業務・基本的な登録検索・少数の帳票・外部連携が少ない小規模なら、300万〜700万円程度を一つの仮置きにできます。複数部署で受発注・在庫・顧客などを統合し、APIやCSV、詳細な権限と帳票を含む中規模なら、700万〜1,500万円程度が目安になります。全社基幹、大量データ、会計やERP連携、高可用性、監査ログ、災害対策を含む大規模では、1,500万円以上となり、5,000万〜1億円超や1年以上の期間も想定します。

別の2026年相場情報では、小規模を100万〜300万円、中規模を500万〜1,000万円、大規模を1,000万円〜数千万円以上、人月単価を60万〜200万円程度としています（出典: SIA「システム開発の費用・相場」、2026年）。各社の分類は異なるため、金額だけを平均してはいけません。自社の対象範囲と同じ前提に置き換え、要件定義・移行・テスト・保守が含まれているかを比較します。

既存モノリスのクラウドリフト、リライト、リビルド、段階的な分割では、新規開発と異なり、現行コードの解析、失われた仕様の復元、データクレンジング、旧新システムの接続、移行リハーサル、切り替え、切り戻し、安定化が発生します。小規模なクラウドリフトやモジュール整理は500万〜1,500万円程度、中規模のリライトやAPI化・データ移行は1,500万〜5,000万円程度、大規模な基幹刷新や段階的なマイクロサービス化は5,000万円〜数億円以上という推定レンジで考えます。

これらは公開相場と必要工程から組み立てた記事上の目安であり、モノリス刷新の全国平均ではありません。既存資産が読めない、データ品質が低い、停止できない、連携先が多い、24時間運用が必要という条件が重なるほど、調査と移行の費用が増えます。AWSの段階移行ガイダンスが示すように、新旧の経路を一定期間管理する設計は、全面停止を避けやすい一方、移行中の監視や整合性検証を予算に含める必要があります（出典: AWS Prescriptive Guidance、2026年確認）。

見積書は、要件定義、現行資産分析、基本・詳細設計、環境構築、実装、単体・結合・総合・性能・セキュリティ試験、データ移行、教育、リリース、安定化、保守に分けてもらいます。費用の中心は人件費で、2026年の公開情報では全体の60〜70％が人件費、人月単価は60万〜160万円程度、別の相場整理では60万〜200万円程度とされています（出典: Cataly Design・SIA、2026年）。職種、スキル、地域、稼働率で変わるため、単価だけでなく人月数と担当範囲を確認します。

保守費は、問い合わせ対応だけか、監視、障害復旧、脆弱性修正、法改正、軽微な改修、バックアップ、性能改善まで含むかで差が出ます。初期開発費の年15〜25％程度、または月額で初期費用の5〜15％程度という目安を置くこともありますが、これは契約範囲をそろえた場合に限って比較します。クラウド利用料、ライセンス、ログ保管、監視サービス、バックアップ保管、外部APIの従量課金もランニングコストとして別枠で確認します。

委託先の選定と見積比較では何を確認しますか？

委託先は、知名度や最安値だけでなく、現行資産の解析から稼働後の保守までを一つの流れで説明できるかで選びます。モノリシックのシステムでは、Web画面の制作実績だけでは、データ移行、業務ルール、権限、夜間バッチ、性能試験、障害対応の力を判断できません。同業・同規模の事例と、提案段階での質問への向き合い方を確認します。

実績を確認するときは、「業務システムを何件作ったか」ではなく、自社に近い業務、利用者規模、連携数、既存システムの状態、停止制約、担当範囲を質問します。現行コードが読みにくい場合の解析手順、設計書を復元する方法、データの品質を確認する方法、性能試験のシナリオ、リリース失敗時の切り戻し条件を、担当者が具体的に説明できるかを見ます。

開発中の担当者と稼働後の保守担当者が同じか、再委託先がいるか、担当者交代時にどのように知識を移すかも確認します。24時間対応が必要なら、一次受付、原因調査、復旧判断、経営層への報告、ベンダーやクラウド事業者へのエスカレーションを分けます。提案書に体制図と役割、稼働率、連絡先、対応時間がない場合は、契約前に補足を求めます。

見積比較では、総額の安さより、同じものを見積もっているかを先に確認します。要件定義、現行分析、画面・帳票、API連携、データ移行、テスト、教育、リリース支援、保守が「含む」か「別途」かを横並びにします。一式と書かれた項目には、作業量、成果物、回数、完了条件、追加単価、対象外を質問します。

価格が極端に安い提案では、要件定義が短すぎないか、テストが単体テストだけになっていないか、移行や教育が発注者作業へ移されていないか、保守が別会社になっていないかを確認します。反対に高い提案でも、過剰な機能や不要なサービスが含まれている可能性があります。RFPの必須・希望・対象外と照合し、必要な品質に対して費用が説明されているかを見ます。

候補会社の比較では、価格だけで決めない評価表を作ります。たとえば価格20点、業務理解と提案内容20点、現行解析・移行の実績20点、開発体制とコミュニケーション15点、品質・セキュリティ15点、保守・引き継ぎ10点のように、重視する項目へ配点します。配点は案件ごとに変えて構いませんが、提案を見る前に基準を決めると、営業資料の印象や担当者の話しやすさだけで判断しにくくなります。

最終面談では、最も安い会社と最も高い会社に、同じ追加質問をします。「モノリスをそのまま残す案」「モジュラーモノリスへ整理する案」「段階移行する案」を比較してもらい、費用、期間、リスク、発注者側の作業を説明してもらいます。自社に都合のよい案だけでなく、採用しない方がよい案とその理由まで示す会社は、技術選択を目的化せず、業務の成果を基準に提案している可能性があります。

モノリシックのシステムの発注・外注でよくある質問

ここでは、モノリシックのシステムを発注・外注するときに、特に判断に迷いやすい質問へ回答します。費用や契約だけでなく、モノリスを残す判断、要件が固まっていない段階での相談、複数社比較の進め方も確認してください。

問題ありません。利用者数や処理量を予測しやすく、変更頻度が高くなく、データ整合性を重視し、少人数で運用する企業では、モノリスやモジュラーモノリスが合理的な選択になる場合があります。外注先には、マイクロサービス化を前提にせず、現行維持、クラウド移行、内部整理、段階分割を同じ条件で比較してもらいます。

相談できます。現状の業務フロー、困っている場面、利用者、期限、予算レンジ、既存資料を共有し、現行調査や要件定義だけを準委任で依頼する方法があります。提案時には、確定している条件、仮定している条件、追加調査が必要な条件を分けてもらい、調査後に開発費を再見積もりする流れを契約へ反映します。

RFPを提出する候補は3〜5社程度、最終的に詳しく比較する会社は2〜3社程度が目安です。会社数を増やすより、同じRFP、同じ質問、同じ回答期限で、工程・成果物・除外事項・保守条件をそろえる方が有効です。最終決定では、価格、実績、体制、要件理解、品質・セキュリティ、引き継ぎを分けて評価し、安さの理由と高さの理由を説明できる会社を選びます。

モノリシックのシステムを発注・外注する方法のまとめ

モノリシックのシステムを発注・外注するときは、最初に技術方式を決めるのではなく、現行業務、データ、連携、変更頻度、障害時の許容範囲、運用体制を診断します。そのうえで、モノリスを使い続ける、モジュールを整理する、クラウドへ移す、機能単位で段階移行する、全面的に再構築するという選択肢を比較します。

発注側は、業務シナリオと優先順位をRFPへまとめ、非機能要件を数値化し、移行データと成果物を定義します。要件が固まっていない調査・要件定義は準委任、完成条件を決められる設計・開発は請負など、工程に合う契約を選びます。見積もりは一式の総額で判断せず、解析、設計、開発、テスト、移行、教育、保守を分け、前提と除外事項を横並びにします。

委託先は、モノリスやマイクロサービスという言葉だけでなく、現行コードの解析、データ移行、性能・セキュリティ試験、障害時の切り戻し、稼働後の保守まで具体的に説明できるかを確認します。最も安い提案を選ぶのではなく、必要な品質を満たす範囲で、発注者側の作業、将来の変更費用、契約終了時の引き継ぎまで含めて比較することが、長く使えるシステムにつながります。

▼全体ガイドの記事
・モノリシックのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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