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

Monorepoのシステム開発は、現状調査、要件と責任範囲の合意、小規模な検証、段階移行の順に進めると、安全な運用へとつながります。

発注では、発注形態を選び、RFPや契約を用意し、費用と委託先を比べてから、発注後の段階的な進め方に入ります。全体像は次の完全ガイドでも確認できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Monorepoのシステムを発注する前に知っておきたい全体像

発注の成否は、何を共有し、何を分けて、誰が運用するかで決まります。まず押さえたいのは、Monorepoがソースコードの管理方法であり、モノリスとは異なるという点です。

Monorepoの位置づけと、システムや実行ファイルとの違い

Monorepoの特徴は、管理対象、コードのレビュー方法、実行・デプロイ構成の面から捉えると分かりやすくなります。

• 管理対象：複数のアプリ、サービス、共通ライブラリ、インフラ定義を、一つのリポジトリにまとめて扱います。
• 配置例：販売管理画面、在庫API、請求バッチ、認証パッケージを同じリポジトリに置きつつ、ビルドとデプロイは別々に行えます。
• 一元レビュー：共通の型定義や認証処理を変えるとき、利用側との整合性を同じコミットで見直せます。

同じデータベースを使うことや全アプリの同時リリースは、必須ではありません。そのうえで、発注時にはRFPに「リポジトリは一つ、デプロイはアプリ単位」「共通パッケージは公開APIを定める」と書いておくと、モノリス化を避けられます。

外注を検討しやすい企業と、内製を優先したい企業

次の状況に当てはめて、外注の必要性とリポジトリの構成を検討します。

• 外注を検討：複数のチームやサービスがあり、共通コードの重複や長いCI、リリースのばらつき、依存関係の把握不足に悩む場合。
• 既存統合：Gitの移管に加えて、ビルド、テスト、権限、デプロイも見直す必要がある場合。
• 内製を優先：アプリが一つで共通コードが少なく、開発者が一人か二人の場合。
• polyrepoを検討：機密性の異なる部門や、異なるリリース統制が必要になる場合があります。委託先には、採用しない条件も尋ねます。

Monorepoの発注形態の選び方

発注形態には、一括請負のほか、現状調査だけを専門会社に依頼する方法や、社内責任者と外部の基盤チームが段階的に導入する方法もあります。どの役割を社内に残すかによって、選び分けます。

要件が固まっている場合の請負型と成果物の明確化

構成、ツール、移行対象が決まっていれば、請負型で成果物と納期を合意しやすくなります。CI/CDやテスト、文書、受入条件も、請負の範囲に含めて決めておきます。

条件は、「既存5リポジトリを統合し、3アプリを個別デプロイ可能にする」のように、検証できる形で書きます。

既存コードの品質や依存関係が分からないまま移行一式を固定価格にすると、委託先のリスク料や後からの変更契約が増えるおそれがあります。そこで、現状調査と要件定義を先に行い、成果物を工程ごとに分けます。

要件が揺れている場合の準委任型と調査・設計

移行対象が多く、テストが足りず、業務ヒアリングも必要な場合は、準委任型で一定期間の調査と設計を依頼できます。

準委任型は仕様変更に対応しやすい一方で、発注側が優先順位を決めて成果物をレビューしないと、期間が長引きがちです。

月次報告に加えて、依存関係図や移行計画、CI実行時間を成果物に含めます。テストカバレッジや未解決リスクの一覧も受け取り、「調査」で終わらせず、所有チームと依存関係の一覧化、移行順序と中止条件の提案まで明記します。

内製移管を目指す場合の伴走型と共同開発

内製移管を目指す場合は、社内体制と要件の確かさに応じて、契約や着手範囲を決めます。

• 共同開発：設計原則やCI改善の経験が不足する場合に、外部の基盤担当者と社内の担当者が、ワークスペースやタスク定義、権限、運用手順を一緒に実装します。
• 引渡し対象：ソースコードのほか、CI定義やIaC、テスト、設計判断の記録、教育内容を含めます。
• 契約の目安：要件と優先順位を決められるなら準委任型、納品物と受入条件を固定できるなら請負型になります。
• 着手方法：どちらも難しい場合は短期調査から始めます。1〜2ドメインでPoCを行い、効果と運用負荷を測ったうえで、本開発へ進みます。

RFPと要件整理での共有範囲と分離範囲

RFPは、目的や課題を発注側と委託先で共有するための文書で、使うツール名を決めるものではありません。対象範囲や品質、運用体制、見積条件も、同じ文書に書きます。

アプリの一覧だけでなく、パッケージ間の依存関係や所有チームも整理します。さらに、リリース単位とアクセス制御も洗い出します。

現状と目的の業務・技術・経営による整理

業務面では、販売や在庫、顧客、請求といった対象と、その利用者を記載します。技術面では、リポジトリ数やアプリ数、パッケージ数、言語を整理します。ビルド時間やCIサービス、デプロイ先、テストの有無も、併せて整理します。

経営面では、リリース頻度や重複開発、監査、事業継続のうち、どれを改善したいかを明記します。目標は、「Monorepo導入」ではなく、共通認証を関連アプリに同じプルリクエストで反映する、といった成果で書きます。

変更のないアプリをCIで再実行しないことや、委託終了後に社内でリリースできることも、成果の例になります。たとえば、CI時間やレビュー待ち時間を測定指標にできます。さらに、重複コードやデプロイ失敗率、障害時の影響範囲も、測る対象にできます。

対象範囲・対象外・受入条件の記載

対象範囲、対象外、受入条件は、項目ごとに分けて書きます。

• 対象範囲：移行する・しないリポジトリや統合パッケージ、テスト補修、CI/CD、権限やブランチ保護を記載します。
• 対象外：機能追加やDB統合、UI刷新、24時間監視などを、委託の範囲から外すと明記します。
• 受入条件：統合の有無より、検収時に確認できる動作で決めます。

受入条件には、変更したアプリの影響範囲テストが自動で実行され、アプリ単位でリリースできることを含めます。加えて、失敗時の復帰、社内担当者による手順の再現、確認するログや画面も合意します。

範囲外が曖昧なままだと、各社の前提が異なり、見積価格を比べられません。

セキュリティと運用要件の事前整理

多数のサービスを一つのリポジトリで管理するため、権限の設計が欠かせません。そのため、RFPの段階で、誰がどこまで変更や承認をできるかを定めておきます。

• アクセス管理：CODEOWNERSやブランチ保護、必須レビュー、SSO・多要素認証、退職者の無効化。
• 監査と検査：監査ログや秘密情報の検査、依存パッケージの脆弱性とライセンスの確認。
• 責任者の設定：部署や委託先が異なる場合に、ディレクトリごとの担当と承認を分けられるかを確かめます。

依存パッケージの確認では、GitHubのDependency reviewのように、条件に応じてマージを止められる機能もあります（出典: GitHub Docs「Dependency review」、2026年確認）。

見積もりでは、設定費だけでなく、検知後の承認や例外申請、更新の運用費も確認します。

ソースコード以外も含めた契約形態と責任分界

納品物には、アプリのソースコードに加えて、構成やワークスペース設定、CI/CDやIaCも入ります。さらに、テストや依存関係一覧、SBOMのほか、運用手順と設計判断記録も含まれます。これらがそろっていないと、納品後に社内で改修できません。

成果物については、形式や保管場所、引渡し時期も確認します。

成果物・著作権・改修権・OSSの扱い

ソースコードに加えて、設計書やテスト、CIを引渡しの範囲に入れます。コンテナや監視設定、スクリプトの扱いも決めておきます。自社で改修することや、別の会社へ移すことがあり得る場合は、利用や改修、保守委託に支障のない権利関係を確認します。

著作権の条項では、成果物の利用範囲や著作者人格権も扱い、必要に応じて専門家に相談します。また、OSSについては、ライセンスや著作権表示、NOTICEを確認し、ソース開示義務と脆弱性対応の責任も確かめます。

委託先の汎用部品を使う場合は、自社で使える範囲と、別案件へ再利用する条件を分けて決めます。共通パッケージの権利が曖昧だと、移管や監査の障害になりやすくなります。

工程ごとの仕様変更・障害・脆弱性の責任分界

共通パッケージの変更は複数のアプリに影響するため、誰が変更を承認し、影響をどう分析するかを先に決めます。加えて、テスト失敗時の一次対応、リリース判断、ロールバックの担当も、先に分けておきます。

基盤を委託先が作る場合も、業務仕様の最終判断や夜間障害の受付担当を明確にします。保守契約では、問い合わせの時間や重大度別の初動、復旧目標を確認します。加えて、依存更新やCI調査、リリース支援の回数も確かめます。

原因によって担当が変わる場合は、アプリ、共通パッケージ、CI基盤の切り分け手順と連絡先も納品物に含めます。

ベンダーロックインと内製移管の条件

特定のCIやキャッシュを使う場合は、解約後もビルドやテスト、デプロイを再現できるかを確認します。

Turborepoの公式説明では、共有キャッシュは重複作業を減らし、成果物をHMAC-SHA256で署名して、完全性と真正性を検証できます（出典: Turborepo公式「Remote Caching」、2026年確認）。

移管とサービス解約の条件は、次の項目をRFPと契約に記載します。

• サービス管理：データの保存場所と削除方法、秘密鍵の管理、代替手段。
• 移管の準備：管理者アカウント、リポジトリのエクスポート、CI再構築、バックアップ復元テスト。
• 引継ぎと撤退：未解決チケットの一覧、社内担当者への引継ぎ期間、移管できない構成を選ぶ理由と撤退コスト。

Monorepoのシステム発注費用相場と見積もりの内訳

Monorepo構築の国内統一相場は公表されていません。費用は、リポジトリ数やパッケージ数、言語によって変わります。加えて、テスト品質やCI/CD、セキュリティ、移行の複雑さも影響します。

下の概算は、一般的な人月単価と作業範囲によるものです。そのうえで、同じRFPを複数社に渡し、工数と前提を分けて比べます。

小規模な新規構築の約240万〜800万円という目安

小規模な新規構築の概算は、対象範囲と人月単価を分けて確認します。

• 作業範囲：3〜6パッケージ、Webアプリ1〜2個、workspace、lint、単体テスト、CI、READMEの整備。
• 概算：4〜8人月、約240万〜800万円。人月60万〜100万円で計算した編集上の推定で、平均価格ではありません。
• 上振れ要因：認証や外部API、インフラ構築、監査対応、既存データ移行を含む場合。

SIAの2026年記事では、人月単価は60万〜200万円程度と説明されています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年7月）。

PMやアーキテクト、セキュリティ、テスト担当が、何人月含まれるかも確認します。

既存統合の約600万〜2,500万円以上という幅

既存統合は、対象の数や対応範囲によって金額が変わるため、規模ごとに概算を分けて見ます。

• 既存統合の規模：5〜20リポジトリ、10〜50パッケージを対象に、依存整理、テスト補修、個別デプロイ、権限・レビュー設計を行う場合。
• 既存統合の概算：10〜25人月、約600万〜2,500万円。期間は3〜8か月程度で、業務機能改修やデータ移行を含むと増えます。
• 費用が増える作業：環境差や再現できない手作業の解消が、費用の中心になる場合もあります。
• 大規模案件：複数言語・クラウド、監査ログ、SBOM、SSO、災害対策を含む場合、25〜80人月、約1,500万〜8,000万円程度の推定です。

いずれも、一般的な人月単価と作業量による概算です。見積書は、工程ごとに分けてもらいます。調査や設計、移行、CIやテストのほか、セキュリティや教育、保守も対象にします。

CI・キャッシュ・保守に分けたランニングコスト

月々の費用と作業費は、対象と利用条件に分けて確認します。

• 運用費の対象：ホスティングやCIランナー、リモートキャッシュ、成果物保管、監視、商用サポート、脆弱性対応。
• 月額の仮置き：月額5万〜50万円程度を暫定予算として置く場合もあります。一般的な予算の仮説で、特定サービスの料金は保証しません。
• 変動条件：利用者数やCI回数、ビルド時間、容量、保持期間、契約プランによって変わります。
• 人月の積算：工数と単価を明確にし、何人日をどの成果物に使うか、追加作業の単価も確認します。

デジタル庁のガイドブックは、1人月を原則20人日として積算する考え方を示しています（出典: デジタル庁「標準ガイドライン実践ガイドブック」、2025年5月改定）。

委託先の選定と見積比較で確認すべきポイント

委託先は、Monorepoの知識だけでなく、要件整理から運用移管まで扱えるかで選びます。また、ツール会社やホスティング事業者、受託開発会社、クラウドインテグレーターは、それぞれ役割が異なります。提案を比べるには、先にRFPで支援範囲と評価基準を決めておきます。

実績の確認：件数より課題と規模

実績面談では、案件の規模や担当者の経験を、次の観点で確かめます。

• 案件の規模：解決した課題やアプリ・パッケージ数、チーム数、新規構築か既存移行かを聞きます。
• 進行と成果：採用したCIや移行期間、導入後に測った指標を確認します。
• 担当者：提案の窓口に加えて、設計・実装・運用移管を担うメンバーとの面談も含めます。
• 設計の説明：設計判断を自社の業務に置き換えて示せるかを見ます。

たとえば、Nxの2026年事例では、Casewareが700以上のプロジェクトを統合したと紹介されています。

さらに、同社は93％のキャッシュヒット率と週181日分の計算時間削減も達成したとされています（出典: Nx「Scaling 700+ Projects: How Nx Became a No-Brainer for Caseware」、2026年3月）。ただし、これはベンダーが掲載した事例で、他社での再現までは保証されません。自社で測る指標と計測方法を提案できるかで、会社を評価します。

見積比較：総額より前提・工数・除外項目の確認

各社の見積もりを同じ前提で比べるため、次の項目を確認します。

• 工程と費用：調査、要件定義、設計、移行、CI/CD、テスト、セキュリティ、文書、教育、管理、保守ごとに分けて示します。
• 見積条件：担当、人数、期間、単価、成果物、前提をそろえて確認します。
• 除外項目：「既存テストを利用」「クラウド費は別途」「業務確認は発注者が担当」などの前提が、価格差の理由になります。
• 短納期：品質や体制、段階リリースへの影響も、見積もりの中で押さえます。
• 急ぐ場合：削る範囲と、品質・体制への影響、段階リリースで代替できるかを、見積もりに記載してもらいます。

特に、通常の70％以下のスケジュールを求めると、並列開発や予備工数が必要になり、費用が1.2〜1.4倍になる傾向が示されています（出典: SIA株式会社「受託開発の費用相場」、2026年7月更新）。

避けたい提案と、質問しておきたいリスク

提案の前提と、導入後に起こり得るリスクを次の観点で確かめます。

• 効果の断定：「必ず安くなる」「ツールだけでCIが速くなる」という説明には注意します。
• 設計とキャッシュ：依存の密結合は影響範囲を広げます。入力・出力の定義や再現性が不十分だと、古い成果物やキャッシュミスが起こり得ます。
• 面談での質問：polyrepoが適する条件や移行の中止基準、復帰方法、秘密情報を含めない設計、離任時の引継ぎ、契約終了時の移管。

回答が、技術面にとどまらず、業務影響や費用、納期、責任者まで具体化されているかを見ます。

発注後の小さな検証と、Monorepoの段階的な広げ方

全社統合を急がず、現状調査からPoC、段階移行、運用移管へと順に進めます。各段階で成果物と継続判断を用意しておけば、効果が出ない場合に範囲や設計を見直せます。

発注側は、業務責任者や技術責任者、セキュリティ担当、契約担当を最初の段階から参加させます。

最初の調査：現状の数字と移行候補の確定

調査とPoCでは、次の項目を確認したうえで、移行候補と継続判断を決めます。

• 現状調査：所有チーム、言語、依存パッケージ、ビルド・テスト時間、デプロイ頻度、障害履歴、権限、秘密情報の保管先。
• 候補の選定：共通UIや型定義のように依存を管理しやすいものと、認証や業務ロジックのように影響の大きいものに分けます。
• PoC：代表的な2〜3アプリと共通パッケージを使い、変更箇所のテスト、個別デプロイ、失敗時の復帰を確かめます。
• 効果の判断：CIが30分から20分になっても、保守工数が増えれば成功とは限りません。速度や品質、レビュー負荷、運用費、社内理解度を見ます。

段階移行におけるリリースとロールバックの準備

移行では、リリースと復帰の条件を先に決めてから、順に進めます。

1. 依存の少ない共通パッケージや新規アプリから移し、業務影響の大きい基幹機能は後回しにします。
2. ブランチ保護やレビュー、テストの体制を先に準備したうえで、成果物保管や承認、監視、復帰手段も用意します。
3. 既存環境と新環境を一定期間並行稼働させます。DBも変える場合は、コードとデータの移行を別々に判断します。
4. 新CIで再現可能にビルドでき、必要なテストが通ることを確かめます。
5. 担当チームが手順書でリリースでき、復帰演習も終えたことを完了条件とします。
6. 問題が起きたときに旧構成へ戻す範囲を、事前に決めます。

運用移管後のガバナンスの定例化

運用体制と引継ぎ条件をRFPや契約に含めておくと、導入後の追加費用を予測しやすくなります。

• 運用ルール：公開API、依存方向、命名、テスト、リリース、例外承認を、継続して守ります。
• 定例確認：変更の多いパッケージやCI失敗率、キャッシュヒット率を見ます。
• 運用状況：脆弱性やライセンス例外、レビュー滞留、リリース失敗の状況も、確認の対象にします。
• 移管完了：資料を受け取るだけでなく、社内担当者が変更、テスト、リリース、復帰を実行できることです。
• 社内管理：委託を続ける場合も、管理者を最低一人置き、外部サービス契約や秘密鍵、バックアップ、障害連絡先を自社で押さえます。

よくある質問

発注では、既存資産や契約、費用、社内体制について疑問が出やすいものです。そこで、発注前に相談の多い質問を取り上げ、判断の基準を示します。

Monorepoのシステム発注費用はいくらですか？

作業範囲に基づく概算では、小規模な新規構築が約240万〜800万円、既存統合が約600万〜2,500万円程度です。

統一の相場はないため、この幅は目安として捉えます。

費用は、リポジトリ数やテスト補修、CI/CDによって変わります。権限やセキュリティ、移行対象も影響します。そのため、人月と単価、成果物、除外項目をそろえて比べます。

Monorepoの移行は請負契約と準委任契約のどちらが良いですか？

要件と受入条件が明確なら請負型、調査や移行方針が固まっていないなら準委任型が検討しやすくなります。

調査と基本設計を準委任で、合意した範囲の実装を請負で進める方法もあります。

どちらの契約でも、成果物と責任分界を文書にします。変更手続きや知的財産、引継ぎも、同じ文書に書いておきます。

TurborepoとNxはどちらを選べばよいですか？

TurborepoとNxは、重視する点によって候補が分かれます。

• Turborepo：TypeScriptやJavaScriptが中心で、軽量な実行とキャッシュを重視する場合に候補になります。
• Nx：プロジェクトグラフや境界ルール、生成、分散CIなどの管理を重視する場合に候補になります。

多言語・大規模ビルドやMicrosoft環境など別の前提があれば、RushやBazelも比べます。ツール名よりも、依存関係やCI、権限、運用をどう実装するかの提案を確認します。

Monorepoではなくpolyrepoを選ぶべきケースはありますか？

あります。強い権限分離や異なるリリース・監査の単位、少ない共通コードといった条件があるなら、polyrepoの方が管理しやすい場合があります。

Monorepo導入を前提にせず、共有コード量や変更頻度、組織境界、CIの課題を確かめたうえで比較します。

まとめ

発注前に決めておきたいのは、何をリポジトリで共有し、何をアプリやチーム単位で分けるかです。そのうえで、目的と現状をRFPに整理し、受入条件と契約、成果物を決めます。保守や移管条件も確認します。

前提と成果物をそろえた費用の比較

統一の相場がないため、人月や単価、対象リポジトリに分けて比べます。テストやCI、セキュリティは工程ごとに、教育や保守は別に見ます。なお、新規構築は約240万〜800万円、既存統合は約600万〜2,500万円程度が、作業範囲に基づく概算です。

ここに挙げた金額は確定した価格ではありません。そのうえで、同じ前提で複数社に見積もりを依頼し、抜け漏れと将来の運用費も比べます。

現状調査と小さなPoCからの開始

全社統合を急がず、代表的なアプリと共通パッケージでPoCを行います。PoCでは、CI時間やキャッシュ、変更の安全性を確認し、レビュー負荷や社内運用の可否も見ます。

効果が測れた範囲は段階的に広げる一方で、polyrepoが適する領域は残します。委託先には、導入を勧める条件に加えて、採用しない条件と撤退方法も提案してもらいます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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