モノリシックシステムの発注は、現状診断、要件整理、契約・委託先の選定、移行・保守の順に進みます。必要な範囲を見極めれば、その範囲だけを外注できます。
発注前の判断から委託先の選び方まで、工程の順に見ていきます。全体像は、モノリシックのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・モノリシックのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
モノリシックのシステムを発注・外注する前に決めること
発注前には、モノリスを採用するかどうかだけでなく、業務の条件も整理しておく必要があります。条件が曖昧なままでは、構成や外注範囲を決められません。
発注側は、対象業務と利用者、処理量を整理します。
変更頻度、停止可能時間、社内の運用体制も、発注前に押さえておく項目です。
構成と外注範囲は、セットで考えます。安定して稼働しているモノリスでも、内部の境界を整理してからクラウドへ移すほうが効果的な場合もあります。
現行システムの課題の診断（業務と技術の両面）
まずは、現行システムのどこで困っているかを言葉にしておきます。「古い技術だから刷新する」という理由だけでは、刷新の成果や優先順位を決められないためです。
- 手作業：受注のたびに在庫・請求・会計へ入力する
- 処理時間：月末のバッチ処理に時間がかかる
- 属人化：担当者しか修正方法を知らない
- 改修影響：1つの改修で全機能のテストが必要になる
診断の対象は、業務フロー、コード、DBです。
加えて、外部連携と帳票、夜間バッチを見ます。利用者と権限、監視・バックアップも、対象に含めます。
仕様書が不足していても、ソースコードやテーブル定義、画面を手がかりにすれば、全体像を復元できます。
帳票、障害記録、現場ヒアリングも、復元の材料になります。
変更が多い領域、停止時の損失が大きい領域、廃止しても困らない領域に分けると、発注範囲を絞れます。
一括発注・工程分割・段階移行の使い分け
発注形態は、責任窓口と会社間の引き継ぎを踏まえて選びます。
段階移行の場合は、既存システムを動かしたまま、機能単位で移していきます。
- 一括発注：1社に任せ、窓口を一本化しやすい
- 工程分割：要件定義から保守まで工程別に発注し、発注側が引き継ぎと責任分界を管理する
- 段階移行：稼働を続けながら機能を移すため、二重運用や整合性確認が生じる
一括発注では、提案会社の判断に依存しやすくなります。一方、工程分割は比較の透明性を高めやすいものの、会社間の調整負担が生じます。
段階的に刷新する場合は、受注、顧客、在庫などから優先順位を決めます。
新旧のデータ連携と切り戻しの条件は、先に設計しておきます。
AWSのStrangler Figパターンは、機能を段階的に移し、新旧の経路を切り替えていく考え方です（出典: AWS Prescriptive Guidance「Decomposing monoliths into microservices」、2026年確認）。
二重運用が生じるため、段階移行が常に安いとは限りません。
モノリシックのシステムの発注・外注の順番と手順
外注は、現状把握から始めます。発注方式を決め、RFPを作って提案を依頼します。
次に、要件定義と契約を進め、設計・開発から移行・受入テストへと移ります。最後に、保守を開始します。
要件が固まる前から相談しても構いません。
不明点のうち、仮定のまま進める範囲と、調査して確定させる範囲は、分けて記録しておきます。
発注側の責任者と業務担当者の事前決定
外注後も、発注側の作業は残ります。そのため、決裁者と業務責任者、IT担当者を先に決め、法務・購買の担当者も決めておきます。
担当が曖昧なままだと、開発会社が仮仕様で進めた後に現場の要望が出て、手戻りが起きます。
- 業務情報：業務フロー、利用者数、拠点数、月間処理件数、ピーク時処理量
- システム情報：連携先、データ件数、帳票、希望稼働日、予算レンジ
- 社内工数：ヒアリング、レビュー、意思決定、受入テスト、現場周知の時間
要件定義の初期は、ヒアリングや資料確認に週1〜2日程度を見込んでおきます。
社内の工数も、外注費とは別に予算化します。
候補会社への提案依頼（同じ前提と期限）
候補の数と依頼条件をそろえておくと、提案を同じ基準で比べやすくなります。
- 候補探し：取引先の紹介、開発実績検索、業界団体、マッチングサービスを使う
- 候補数：RFP提出先は3〜5社程度、最終比較は2〜3社程度に絞る
- 依頼条件：質問、回答期限、成果物、税区分、保守期間、再委託の有無をそろえる
- 提案内容：課題理解、採否方式、前提・除外、リスク対策、体制、工程、費用を求める
候補を増やしすぎると、評価が浅くなりがちです。
各社へ異なる情報を渡すと、機能やテストを含まない見積もりを選んでしまうおそれがあります。
Cataly Designの2026年公開記事は、目的整理と要件の洗い出しから始め、複数社の比較、設計、開発・テスト・運用へと進む流れを示しています（出典: Cataly Design「業務システム開発の費用相場」、2026年）。
RFPと要件整理に書く内容
RFPは、開発会社へ提案を依頼するための資料です。完成した仕様書がなくても、発注理由、対象業務、成功の基準を共有すれば、提案の前提をそろえられます。
モノリシックシステムでは、画面一覧に加えて、裏側で動くデータと連携もRFPに含めます。
機能要件の書き方（業務シナリオと優先順位）
機能要件は、業務シナリオの形で示します。入力者と承認者を示したうえで、在庫・請求・会計への連携や例外処理も、シナリオの中で読み取れるようにします。たとえば、見積登録から承認、受注、在庫引当、出荷、請求、会計連携までを、一連の流れとして記載します。
通常処理と例外処理（取消・返品・分割請求など）は、分けて書きます。
- 必須範囲：稼働日に必要な機能
- 追加範囲：初期リリース後に追加する機能
- 廃止・代替範囲：廃止する機能や別手段へ置き換える機能
画面数に加えて、帳票、承認経路、権限を明記します。CSV、バッチ頻度、通知、検索条件、履歴保持期間も、RFPに書いておく対象です。
優先順位が示されていないRFPでは、全機能が必須と解釈されがちです。そのぶん、費用と期間が膨らみがちになります。
非機能要件の数値化と運用条件の合意
非機能要件は、数値や運用条件に置き換えて、RFPに記載します。
- 対象領域：可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、環境
- 性能・復旧：同時利用者数、検索応答時間、月間稼働率、復旧目標時間を数値化する
- 運用条件：障害が複数業務へ及ぶ可能性を踏まえ、バックアップ頻度、ログ保存期間、業務ごとの停止許容時間、復旧手順を定める
- 個人情報保護：最小権限、管理者権限分離、多要素認証、通信・保存データの暗号化を含める
- セキュリティ運用：監査ログ、脆弱性対応、委託先管理、インシデント連絡体制を定める
上流工程で非機能要件を整理するときは、IPAの非機能要求グレードが基準になります（出典: IPA「システム構築の上流工程強化」、2026年確認）。委託先への確認項目を整理する入口としては、IPAのセキュリティ要件リストがあります（出典: IPA「IT製品の調達におけるセキュリティ要件リスト」、2026年確認）。
データ移行と成果物の範囲の明確化
移行作業と納品物は、見積もりと契約の前提として範囲を決めておきます。成果物は、実行ファイルのほかに、設計や試験に関する資料まで含めて考えます。
- 移行データ：対象テーブル、保存年数、コード変換、重複・欠損データ、移行後の照合
- 移行体制：旧システムの保存方法、データクレンジングの担当、リハーサル回数
- 設計・試験成果物：実行ファイル、要件定義書、設計書、データ辞書、API仕様、テスト仕様と結果
- 運用・引き渡し：移行・運用手順、インフラ、復旧手順、ソースコード、IaC、管理者アカウント
OSSや汎用ライブラリを含む場合は、利用許諾とライセンス表示について、誰が責任を負うかを確認します。
モノリシックのシステム開発の契約形態
成果物の完成を約束する請負と、専門作業の遂行を委託する準委任を、工程に応じて使い分けます。
契約の名称だけでは、責任の範囲は決まりません。そのため、工程、成果物、検収の条件を契約書に記載します。加えて、作業時間と変更管理、報告の条件、損害と再委託の条件も書いておきます。
経済産業省のモデル契約書は、フェーズごとの契約、仕様変更、複数ベンダーや工程分割発注の扱いを整理しています（出典: 経済産業省「情報システム・モデル取引・契約書」、2026年確認）。
請負契約の完成条件と検収の明確化
請負では、完成条件と変更の手続きを定めたうえで、成果物を検収します。
- 対象工程：完成条件を定めやすい基本・詳細設計、機能開発、テスト仕様書など
- 検収基準：業務シナリオ、権限、外部連携、帳票、性能、障害動作、移行後の照合
- 変更管理：変更申請、影響調査、追加工数、納期変更、承認者を決める
要件が曖昧なまま一括で固定すると、変更が生じたときに問題になります。また、納期を優先して要件定義や総合テストを削ると、検収後の障害対応費が増えることがあります。
モノリスでは、1機能の変更が他の機能やデータへ影響しやすいため、契約書や変更管理表に手順を定めておきます。
準委任契約の向く工程（調査・要件定義・伴走）
準委任は、工程や要件がまだ確定していない段階で候補になります。要件が未確定のときは、固定の契約を結ぶ前に、調査と要件整理を準委任で依頼するほうが安全な場合もあります。
- 向く工程：現行調査、業務ヒアリング、要件定義、技術検証、プロジェクト支援、要件が変わりやすい開発
- 要件未確定時：調査・要件整理を準委任で頼み、その成果から開発契約へ進む方法がある
- 作業と報告：時間単価だけでなく、担当者、残す資料、報告会議体を定める
準委任では、作業時間を請負の完成保証と混同しないようにします。そのうえで、成果物、品質目標、責任分界、障害対応を確認します。発注者が意思決定し、外注先が専門知識と作業を提供する関係です。
知的財産と引き継ぎ条件の契約前の取り決め
開発費を支払っても、ソースコードや設計書の権利が自動的に発注者へ移るとは限りません。
- 権利の対象：個別プログラム、画面、データ定義、設計書、試験成果物、汎用ライブラリ、OSSを分ける
- 利用条件：著作権、利用許諾、改修・再委託の可否、著作者人格権を確認する
- 引き継ぎ：リポジトリ、クラウドアカウント、API仕様、データ出力、管理者権限を決める
- 保守条件：受付時間、復旧目標、脆弱性修正、OS・FW更新、法改正、バックアップ、月次報告を分ける
- 契約終了：追加開発単価と引き継ぎ期間・費用を明記し、成果物とアクセス権を発注者が保持する
ベンダーロックインを避けるには、これらを契約で定めておくことが重要です。
モノリシックのシステムを発注・外注する費用相場の目安
モノリシック固有の公的な一律価格はありません。費用は、対象業務と画面・利用者・連携数、データ量によって変わります。性能や可用性、移行難易度、保守範囲も、金額を左右します。
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万円程度
- 保守範囲：問い合わせ、監視、障害復旧、脆弱性修正、法改正、軽微な改修、バックアップ、性能改善の有無を分ける
- 保守費の目安：初期開発費の年15〜25％程度、または月額で初期費用の5〜15％程度
単価は、職種、スキル、地域、稼働率によって変わります。そのため、人月数と担当範囲も確認します。保守費は、契約範囲をそろえたうえで比べます。
別の相場情報では、人月単価を60万〜200万円程度としています（出典: Cataly Design・SIA、2026年）。
クラウド、ライセンス、ログの費用は、別枠で確認します。監視やバックアップ、外部APIの従量課金も、総額とは分けて見ておきます。
委託先の選定と見積比較で確認する点
委託先は、現行解析から稼働後の保守まで説明できるかで選びます。知名度や最安値だけで決めないようにします。
画面制作の実績からは、データ移行や業務ルール、権限の扱いを判断しにくいものです。夜間バッチ、性能試験、障害対応の力も、見えにくいままです。
同業・同規模の事例に加えて、提案段階での質問への対応も確認します。
現行解析・データ移行・運用の実績の確認
実績の件数だけでなく、自社に近い案件の範囲や、具体的な解析・運用の方法を確認します。
- 案件の近さ：業務、利用者規模、連携数、既存状態、停止制約、担当範囲を聞く
- 技術的な対応：コード解析、設計書復元、データ品質確認、性能試験、切り戻し条件を確認する
- 体制の継続性：開発・保守担当、再委託の有無、担当交代時の知識移転を確かめる
- 24時間対応：一次受付、原因調査、復旧判断、経営報告、ベンダー・クラウド事業者への連絡を分ける
提案書に体制図、役割、稼働率、連絡先、対応時間がない場合は、契約前に補足を求めます。
一式見積もりを避けた前提と除外事項のそろえ方
総額の安さを比べる前に、同じ作業を見積もっているかを確認します。そのためには、工程や成果物の条件をそろえることが欠かせません。
- 比較範囲：要件定義、現行分析、画面・帳票、API、データ移行
- 納品・運用：テスト、教育、リリース支援、保守
- 見積条件：「含む」「別途」、作業量、回数、完了条件、対象外
極端に安い提案の場合は、要件定義が短すぎないか、テストが単体だけになっていないかを確認します。
移行や教育が発注者の作業に回されていないか、保守が別の会社になっていないかも確かめます。
高い提案にも、不要な機能やサービスが含まれている可能性があります。RFPの必須、希望、対象外と照合しながら、必要な品質に対して費用が説明されているかを見ます。
評価表による価格・技術・体制・保守の採点
提案を見る前に、評価項目と配点を決めておきます。そのうえで、価格以外の適合度も比べます。
- 価格・提案：価格20点、業務理解・提案20点
- 実績・体制：現行解析・移行実績20点、開発体制・連絡15点
- 品質・継続性：品質・セキュリティ15点、保守・引き継ぎ10点
- 方式比較：現状維持、モジュラーモノリス化、段階移行の費用・期間・リスク・発注側作業を比べる
配点は案件ごとに変えられます。また、最安と最高の会社に同じ追加質問を投げかけ、採用しない案とその理由も示せるかを確認します。
業務成果を基準に提案する会社は、技術の選択を目的にしていない可能性があります。
モノリシックのシステムの発注・外注でよくある質問
発注・外注では、費用や契約のほかに、モノリスを残すかどうかの判断、要件が固まる前の相談、複数社の比較でも迷いやすい点があります。
モノリシックのシステムはそのまま外注しても問題ありませんか？
問題ありません。利用者数や処理量が予測しやすく、変更頻度が高くなく、データの整合性を重視する場合や、少人数で運用する場合は、そのまま外注するのが合理的な場合があります。
モノリスやモジュラーモノリスを含め、現行維持、クラウド移行、内部整理、段階分割を、同じ条件で比べます。
要件が固まっていなくても開発会社へ相談できますか？
相談できます。業務フロー、困っている場面、利用者、期限、予算、既存資料を共有すれば、調査や要件定義だけを準委任で頼むこともできます。
確定している条件、仮定の条件、追加調査が必要な条件を分けて示してもらいます。調査のあとに開発費を再見積もりする流れは、契約に反映しておきます。
モノリシックのシステムは何社から見積もりを取るべきですか？
RFP提出先は3〜5社程度、詳しく比較する会社は2〜3社程度が目安です。
会社数を増やすよりも、RFPと質問、回答期限をそろえることが先決です。工程、成果物、除外事項、保守条件もそろえます。
最終比較では、価格、実績、体制に加えて、次の3つの観点で提案の中身を見ます。
- 要件理解
- 品質・セキュリティ
- 引き継ぎ
安さや高さの理由を説明できる会社を選びます。
モノリシックのシステムを発注・外注する方法のまとめ
まずは技術方式を決めずに、現行業務、データ、連携、変更頻度、障害時の許容範囲、運用体制を診断します。
発注側は、モノリスを継続する案、モジュール整理、クラウド移行、機能単位の段階移行、全面再構築を比べます。
発注成功の鍵は、要件・契約・見積もりを同じ前提でそろえること
業務シナリオと優先順位をRFPにまとめ、非機能要件を数値にし、移行データと成果物を定めます。
未確定の調査・要件定義には準委任を、完成条件を定められる設計・開発には請負を使うなど、工程に合う契約を選びます。
見積もりは、解析、設計、開発、テストの工程に分けます。移行、教育、保守は、別の項目として扱います。そのうえで、前提と除外事項を比べます。
価格よりも現行資産の理解と運用までの伴走を重視した委託先選び
委託先が、現行コード、データ移行、性能・セキュリティ試験、切り戻し、保守について説明できるかを確認します。
発注側の作業、将来の変更費用、契約終了時の引き継ぎまで含めて比べることは、長く使えるシステムにつながります。
▼全体ガイドの記事
・モノリシックのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。