相談する

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

Mercurialのシステム発注は、資産の棚卸しから始め、要件と受入条件を整理したうえでPoCで確かめ、段階的に契約と構築を進めると、安全な運用基盤につながります。

最初に今の資産と業務への影響を調べ、そのあとで発注の形態や委託範囲を決めることになります。

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

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

Mercurialのシステムを発注する前の全体像

Mercurialの発注対象を接続と権限、開発支援、保守と統制の3層で示す図。
運用の責任範囲を3層に分けて整理できます。

Mercurialは、リポジトリと変更履歴を開発者がローカルに持つ分散型のバージョン管理システムです。ネットワークが不安定でも、コミットや差分確認を進めやすいのが特徴です。

チーム開発ではclone、pull、push、mergeを組み合わせて使います。特に発注対象は、クライアントソフトだけでなく、安全にコードを扱う運用全体です。

発注対象の一式（リポジトリから運用監視まで）

RFPに書く対象は、接続・権限・開発支援・保守の観点で分けて示します。

  • 接続と権限：Mercurialリポジトリ、HTTPSまたはSSHでの接続、認証、グループとリポジトリ単位の権限
  • 開発支援：コードレビュー、課題管理、CI/CD、JiraやRedmine、チャットとの連携
  • 保守と統制：バックアップ、監査ログ、監視、退職者アカウントの停止、復旧テスト

LDAP、Active Directory、SSO、二要素認証との連携が必要なら、追加要件として明記します。また、コードを保管できても、退職者のアカウント停止や復旧テストができなければ、業務で使えるシステムとはいえません。

継続利用とGit移行の判断の切り分け

まず現行資産と業務への影響を調べ、Mercurialの継続利用とGit移行を比べます。流行だけで移行を決めず、業務上の価値を基準に判断します。

  • 機能と履歴：拡張機能、phase、bookmark、named branch、subrepo、フック
  • 開発運用：CIジョブ、利用者の習熟度、履歴を監査に使う価値
  • 費用と委託範囲：業務への影響と3〜5年の総保有コスト、新規採用か既存資産の保守・移行か

新規採用の相談と、重要な既存資産の保守・移行の相談とでは、求める委託先も違います。

Mercurialのシステムの発注形態の選び方

要件と完成条件が固まった構築・改修は請負型が合います。一方、調査やPoC、棚卸し、段階移行は、準委任型のほうが合わせやすいです。

着手後に履歴や拡張機能の問題が見つかることは少なくありません。そのため、全工程を固定価格にせず、調査と本番構築を分けて扱います。

調査・PoC・移行判断の準委任型による開始

資産の量や履歴変換の成否が分からないときは、準委任型で現状調査を依頼します。また、CIが古いサーバーに依存している場合も、先に調べます。

  • 作業条件：作業時間、担当者、週次報告、調査対象
  • 提出物：リポジトリ台帳、依存関係一覧、リスク一覧、PoC結果、移行方針案

調査結果を踏まえたうえで本番構築や移行を請負型で契約すると、見積もりの前提がそろいます。

完成条件が明確な構築・改修の請負型による依頼

HTTPS・SSH接続、SSO連携、バックアップを定義できれば、請負型で発注できます。監視、レビュー画面、CIランナーも、発注範囲に含めて定義します。ただし、受入条件は機能名だけでなく、検証できる状態で定めておく必要があります。

  • 対象リポジトリ：代表リポジトリ3個を新環境へ移す
  • 接続確認：開発者が一定時間以内にclone・pushできる
  • 受入テスト：権限テストと復旧テストに合格する

完成条件が曖昧なまま請負にすると、追加要望や仕様の解釈の違いが、変更契約の場面に集中します。

クラウド・自社運用・企業向け製品の要件による比較

Mercurial対応クラウドは、初期構築を短くしやすい選択肢です。そのうえで、セキュリティ要件や周辺業務の独自性も併せて比べます。

  • Mercurial対応クラウド：HTTPS・SSH、Web UI、課題管理、レビュー、CI/CDをまとめやすい
  • 自社運用・専用環境：機密性、データ所在地、社内SSO、独自監査、災害対策を重視する場合
  • スクラッチ開発：承認や資産管理など周辺業務に独自性がある場合に限る

たとえば、Heptapod HostingはMercurialのHTTPS・SSH・Web UI、課題管理、マージリクエスト、オンデマンドCI/CDを案内しています（出典: Heptapod Hosting「Features」、2026年8月確認）。

スクラッチ開発の場合も、Mercurial本体を作り直さないのが基本です。

ポイント

完成条件を文章で書けるかどうかが、請負型と準委任型を分ける目安です。書けない部分は、先に準委任型で調査して条件を固めます。

RFPと要件整理によるMercurialの外注範囲

RFPに整理する要件を、基本情報、利用と公開範囲、開発依存、認証・権限・監査・復旧の4項目で示す図。
資産台帳から復旧条件まで、要件の抜けを見渡せます。

RFPには、Mercurialを使うという点だけでなく、誰が何を安全に行える状態にするかを書きます。技術名だけでは、委託先によって対象範囲の受け取り方が変わってしまいます。

対象の範囲がそろっていないと、金額や提案内容を比べられません。たとえば、リポジトリ数やCIの責任、移行対象の扱いが委託先ごとに違えば、見積もりの数字を並べても比較になりません。

業務目的や現行構成、将来方針を一枚の全体像にまとめます。非機能、移行、保守も、同じ全体像に含めます。

リポジトリ・履歴・利用者の台帳化

台帳には、資産を特定する情報、利用状況、開発上の依存関係を記録します。

  • 基本情報：リポジトリ名、所有部門、URL、最終更新日、容量、ファイル数
  • 利用と公開範囲：利用者、管理者、公開範囲、重要度
  • 開発依存：ブランチ、bookmark、タグ、phase、subrepo、フック、拡張機能、CIジョブ、連携先

履歴を監査や障害解析に使うなら、全履歴を残す必要があります。一方、業務で参照しない古いアーカイブであれば、現行ソースだけを移すスナップショット方式も候補になります。

認証・権限・監査・復旧の非機能要件

RFPには、認証から復旧までの条件を書き込みます。あわせて、関連ソフトの更新を誰が担当するかも決めておきます。

  • 認証と権限：TLS、SSH鍵、SSOやLDAP、二要素認証、最小権限、退職者アカウントの無効化
  • 監査と脆弱性：監査ログの保存期間、脆弱性対応、Mercurial本体や依存環境の更新担当
  • バックアップと復旧：バックアップ世代数、復旧目標時間、復旧目標時点

Mercurial 7.0は2025年3月に公開され、7.1系を経て7.2.3が2026年6月29日に公開されています（出典: Mercurial公式「News archive」、2026年8月確認）。また、OSSでも、本体やPython、OSの保守は必要です。暗号ライブラリや配布パッケージも、保守の対象になります。

PoCの合格基準の数値化

PoCでは、代表的な現役リポジトリを1〜3個選び、操作と移行の条件を確かめます。

  • 基本操作：clone・pull・push、ブランチやbookmarkの運用、変更履歴の検索
  • 開発と安全性：レビュー、CI、権限拒否、バックアップからの復旧
  • 評価指標：clone時間、CI成功率、復旧時間、履歴の欠落数、利用者の手順理解度
  • Git移行：作者情報、タグ、ブランチ、サブリポジトリ、大容量ファイル、CI定義、権限

評価を「操作できた」で終わらせず、設定した指標で結果を判定します。Git移行では、記載した項目を別々に検証します。

ポイント

RFPには、利用者や履歴、認証、復旧まで同じ粒度で書いておくと、委託先の提案を並べて比べられます。技術名だけで済ませないことが、比較の前提になります。

Mercurialの外注で選ぶ契約形態と責任分界

契約書は名称だけで判断せず、成果物と検収、変更管理の条件を確かめます。知的財産と秘密保持、再委託の扱いも、契約書に書き込みます。

障害対応とデータ返却の条件も、契約書で明確にしておく必要があります。海外ベンダーへ委託する場合は、準拠法や時差、サポート言語を契約前に確かめます。さらに、SLAとデータ所在地、ソースコードの取り出し方法も、契約前に決めておきます。

検収基準と仕様変更の契約書への明記

請負契約では、検収の方法と変更の承認手順を明文化しておきます。

  • 検収条件：期間、テスト環境、合格条件、不具合の定義、修補期限、再検収、切り戻し
  • 機能テスト：権限別のclone・push、レビュー記録、CI失敗時の通知
  • 運用テスト：バックアップ復元、監査ログ、リポジトリ削除の防止

開発中に出た要望は、変更要求として扱い、追加費用や納期、影響範囲を記録したうえで承認します。

ソースコード・履歴・IaCの引き渡し可能な状態

納品物はソースコードだけに限らず、復元と運用に必要な成果物をそろえます。

  • 開発資産：リポジトリ履歴、設定ファイル、拡張機能、フック、CI/CD定義、Infrastructure as Code
  • 運用資料：依存パッケージ一覧、バックアップ手順、監視設定、テスト結果、運用マニュアル
  • 権利情報：第三者OSSのライセンス、独自開発部分の権利帰属

受託者のアカウントだけに管理権限を置くと、発注者が復元や移管を進められません。そこで、発注者が自社の管理者として復元・移管できるかを確認します。また、権利情報は契約と納品物一覧に記載します。

保守契約における更新・障害・復旧の責任の区分

保守契約では、対応条件を定めたうえで、保守と開発の費用枠を分けます。

  • 対応水準：受付時間、重大度、一次回答、復旧目標、月間作業時間
  • 保守作業：脆弱性対応、本体やOSの更新、バックアップ確認、復旧訓練
  • 契約終了：データ返却、アカウント削除、バックアップ消去証明

障害対応と機能追加を同じ月額枠に入れると、優先順位が曖昧になります。そのため、保守、軽微な改修、大規模な移行・開発は分けて扱います。

Mercurialのシステム発注費用相場とコストの内訳

Mercurialの初期費用目安を、現状調査・PoCから大規模・高可用性基盤まで4段階で示す図。
規模が上がるにつれて費用レンジも広がります。

Mercurial専用の国内受託開発は公開価格が少ないため、次に示すのは推定レンジです。

この推定は、業務システム一般の費用情報と、リポジトリ管理や移行に必要な作業を組み合わせたものです。相場は予算枠を考えるための目安で、特定の案件の金額を断定するものではありません。

ソフトウェアが無償でも、人件費は発生します。調査や認証、CIの作業には人手が欠かせず、移行や監視、バックアップにも人件費がかかります。教育と脆弱性対応も、同様に人件費の対象です。

規模別の初期費用の幅（50万円〜1億円以上）

初期費用の目安は、調査・PoC、小規模、中規模、大規模・高可用性の順に上がっていきます。

  • 現状調査・PoC：棚卸しやclone・push、CI連携の検証を含め50万〜200万円程度
  • 小規模な自社運用基盤：300万〜800万円程度
  • 中規模の業務開発基盤：800万〜3,000万円程度
  • 大規模・高可用性基盤：3,000万〜1億円以上の範囲で見積もります

MercurialからGitへの移行は、履歴変換やCIの書き換え、並行稼働、教育を含めると、500万〜2,000万円程度の推定レンジです（出典: NotebookLM「業務システム全般_16」一次Q&Aおよびリサーチノート、2026年確認）。

SaaS料金・インフラ・保守の初期費用との区分

RhodeCode Cloudの公開料金例は、いずれも10席込みで、プランごとに月額料金が違います。

  • Starter：10席込みで月額80ドル
  • Team：10席込みで月額180ドル、追加席は1席5ドル
  • Enterprise：10席込みで月額600ドル、追加席は1席4ドル

ここに挙げたのは、ライセンスとホスティングの価格です（出典: RhodeCode公式「Cloud Tiers」、2026年8月確認）。

要件定義や設定、移行の費用は、別途となる可能性があります。社内認証やCIランナーの費用も、含まれていないことがあります。教育、為替、税金、保守委託費も、同様に別途かかる場合があります。

Heptapod Hostingは、アクティブユーザー課金とCIの実利用課金で成り立っています。そのため、利用者数だけでなく、実行時間やストレージも確認します。

3〜5年の総額による継続利用と移行の比較

継続利用と移行とでは、発生する費用の項目が違います。そのため、3〜5年の総額で条件をそろえて比べます。

  • 継続利用：サーバーやクラウド、ストレージ、バックアップ、監視、脆弱性対応、保守要員
  • 移行：変換、CI・連携の書き換え、教育、並行稼働、切り戻し、移行後の運用

初期費用が安くても、属人化や復旧の遅れが大きい場合には、TCO（総保有コスト）は上がります。

機能の数よりも、生産性や監査、復旧、将来の人材確保まで含めて評価します。

ポイント

費用は規模と前提条件で大きく変わるため、条件をそろえたうえで複数社の見積もりを比べます。公開料金と受託作業費は分けて見るのが基本です。

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

Mercurial対応の会社は、Git中心の市場に比べて候補が限られます。そのため、実担当者が技術と運用の中身を説明できるかを確かめ、経験だけで決めないことが大切です。

役割別の委託先候補の比較

依頼する役割に合う専門性があるかを確かめ、候補ごとの対応範囲を比べます。

  • Mercurial・Heptapod：Octobus、Cloudcrane SAS（Orbeetブランド）の公開活動を確認
  • 企業向け統合管理：Mercurial・Git・SVNに対応するRhodeCode
  • Git移行・設計：GitHub Expert Services
  • 第三者支援・教育：MARTINSFELD。Heptapodのクラウド基盤ではClever Cloudも候補

候補となる各社には、日本語の窓口の有無や個別の受託範囲、SLA、契約条件を問い合わせ、最終的に判断します。

見積書の工程・成果物・前提条件の分解

見積書の作業範囲と前提を照らし合わせられるよう、工程と納品物に分けて読みます。

  • 設計と構築：現状調査、要件定義、基本設計、環境構築、認証・権限
  • 開発と移行：レビュー、CI/CD、バックアップ・監視、履歴移行、テスト
  • 導入と運用：教育、リリース、保守
  • 見積前提：担当者、作業期間、納品物、除外事項、リポジトリ数・容量・利用者数

移行検証や復旧訓練、ドキュメント、脆弱性対応が除外された低額の提案は、後から追加費用になりやすいです。

面談での技術・運用・引き継ぎの確認項目

面談では、実担当者に経験と運用、認証、復旧を尋ねます。

  • 経験と運用：「Mercurialを残した企業案件の担当経験はありますか」「phaseやbookmarkをどうレビュー運用しますか」
  • 調査と認証：「subrepoや独自フックをどう調べますか」「LDAP・SSO・二要素認証はどこまで構築しますか」
  • 障害と復旧：「CIランナーの障害時は誰が復旧しますか」「バックアップからの復旧証跡を提示できますか」
  • 移行検証：履歴、作者、タグ、ブランチ、大容量ファイル、CI、権限の検証順を尋ねる

営業担当だけでなく、実装や運用の責任者にも回答を求めると、体制が実際にあるかを確かめられます。

ポイント

見積書の前提条件と除外事項を読み、実担当者が技術と運用を説明できるかで候補を絞ります。経験の有無だけで決めないことが大切です。

Mercurialのシステム発注・外注でよくある質問

外注では、Mercurialという技術を採るかどうかや既存資産の扱いを、まず確かめます。運用責任や移行範囲、契約後の引き継ぎも見ておきます。発注前によくある質問に回答します。

Mercurialのシステムを新規採用しても問題ありませんか？

既存資産とチームの習熟度があり、対応するホスティングやCI、人材を確保できる場合に検討します。そのうえで、Gitが主流だからという理由だけでは判断せず、Mercurialを残す業務上の価値と将来の保守・採用コストを、RFPとPoCで確かめます。

MercurialからGitへ移行すると履歴は消えますか？

移行方式によって変わります。GitHub公式は、MercurialをGitへ変換してからGitHubへpushする手順を案内しています。

作者情報を対応表で変換し、履歴を含めて取り込む方法もあります（出典: GitHub Docs「Importing a Mercurial repository」、2026年確認）。

subrepoや独自メタデータ、大容量ファイルは、別途確認が必要です。CIや権限も、個別に確かめます。そのため、一括で切り替えず、ドライランと代表リポジトリの受入テストを行います。

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

推定レンジは、現状調査とPoCが50万〜200万円程度、小規模な自社運用が300万〜800万円程度です。中規模基盤は800万〜3,000万円程度で、Git移行は500万〜2,000万円程度が目安になります。

費用は、リポジトリの規模や認証、CIの有無で変わります。可用性や履歴、教育、保守の扱いも、費用に響きます。そのため、公開料金と受託作業費を分けて、複数社から見積もりを取ります。

日本企業だけでMercurialの外注先を探せますか？

国内だけに絞ると、Mercurial専門の公開実績は多くありません。そのため、GitやSubversionの移行、認証・監視・バックアップ、レガシー基盤の保守経験も含めて、候補を探します。

海外企業を選ぶ場合は、日本語対応を前提にせず、時差、契約、データ所在地、障害連絡、引き継ぎ資料の言語を確かめます。さらに、専門性と国内のプロジェクト管理力を分担する共同体制も選択肢になります。

まとめ

発注では、コマンドやライセンスだけでなく、開発基盤として全体を整理します。対象はリポジトリから監査、保守まで含みます。

Mercurialを続けるか、ホスティングを刷新するか、Git移行にするかは、資産の棚卸しとPoCで決めます。進め方としては、まず準委任型で調査と要件整理を行い、完成条件が固まった範囲から請負型で構築するのが比較的安全です。

費用は、PoCが50万〜200万円程度、小規模構築が300万〜800万円程度です。中規模は800万〜3,000万円程度、Git移行は500万〜2,000万円程度を、まずは出発点として考えます。

見積もりでは、前提条件と除外事項を明細にしてもらうことが欠かせません。金額だけでなく、履歴やCI、復旧の条件を比べます。引き継ぎや実担当者、責任分界も、比較の対象です。

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

▼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を創業。