Mercurialのシステム開発は、要件整理から定着までの6フェーズで進めます。各フェーズで成果物と合格条件を決め、次の段階へ進む前に確かめます。
全体像は、Mercurialのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Mercurialのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Mercurialのシステムの全体像
Mercurialは、開発者それぞれの環境にリポジトリと変更履歴を持つ分散型のバージョン管理システムです。
開発者はclone、commit、pull、push、mergeで変更を共有します。業務で使うには、サーバーの設置に加えて、作業から本番リリース、監査、復旧までを設計する必要があります。
中核機能と周辺機能の分け方
開発基盤に組み合わせる機能は、接続とレビュー、認証と権限、運用と連携に分けて整理します。
- 接続・レビュー：HTTPSまたはSSH、Web UI、コードレビューの組み合わせ。
- 認証・権限：LDAPやActive Directory、SSO、リポジトリ単位の権限を設けます。
- 運用・連携：CI/CD、監査ログ、バックアップ、監視、課題管理の設計。
JiraやRedmineなどの課題管理ツール、チャット、成果物保管と連携する場合は、どのシステムを正とするかを決めます。さらに、連携に失敗したときの再実行を誰が担当するかも定めておきます。
既存環境では、リポジトリ数や容量に加えて、周辺設定も洗い出します。
- 履歴と構成：サブリポジトリ、bookmark、named branch、phase、topic、evolve関連の設定。
- 運用資産：フック、CIジョブ、デプロイ鍵、リリースタグ、過去の監査記録。
これらは移行後の動作や復旧の可否を左右するため、構築前に一覧表へ記録しておきます。
Mercurialを残すかGitへ移行するかの判断
まず、既存のワークフローが、Mercurialのphaseやtopic、変更履歴の扱いにどれだけ結び付いているかを確かめます。判断は、条件ごとに比べて行います。
- Mercurialを続ける場合：公開済み変更の書き換えを制限してリリース事故を防ぎたい組織には、続ける合理性があります。
- Git中心の場合：ホスティング、CIプラグイン、人材、社内標準がGit中心なら、教育費や属人化が負担になります。
- 比較軸：現行開発の生産性、セキュリティと監査、5年間の運用費、採用・引き継ぎ、移行時の事業停止リスク。
- 保留する場合：Mercurialを安定して運用しつつ、新規開発だけをGitへ寄せる段階移行という選び方もあります。
Mercurial公式のリリース情報によると、2026年6月29日に7.2.3が公開されています。また、2025年には7.0.1がzstdの脆弱性に対応しました（出典: Mercurial公式Release、2025〜2026年）。
OSSはライセンス費を抑えやすい要素です。ただし、利用バージョンとPython、OSの更新経路は保守対象に含めます。暗号ライブラリと配布パッケージの更新経路も、忘れずに見ておきます。
Mercurialのシステム開発の進め方と6フェーズ
進め方の基本は、要件整理から定着までの6フェーズです。各段階で合格条件を置いておくと、レビューができない、退職者の権限が残る、復旧できないといった問題を、構築後になって知る事態を防げます。この手順は、新規導入、刷新、Git移行のいずれにも使えます。
フェーズ1：要件整理による現状とゴールの固定
まず、誰が、どのリポジトリを、どの頻度で、どの環境へリリースするかを一覧にします。その際は、棚卸し表に次の情報を記録します。
- リポジトリ情報：名称、管理部門、利用者数、容量、最終更新日、重要度、保存年限。
- 依存関係：サブリポジトリ、接続方式、CIジョブ、外部連携。
- 運用状況：通常手順に加え、緊急リリース、障害復旧、退職者の引き継ぎ、監査対応。
要件は「必須」「できれば」「今回は対象外」に分けて整理します。必須の例には、社内SSO、二要素認証、最小権限が挙げられます。
保護ブランチ相当の制御と日次バックアップ、復旧訓練も、必須要件の例です。さらに、CI結果の保存と監査ログの保持も、必須要件の例です。
Mercurialを続けるか移行するかの仮説も置きます。ただし、その結論はPoCで検証します。この段階では、構成図、課題一覧、要件定義書に加えて、移行対象の一覧と成功指標もまとめます。
フェーズ2：選定による構成と責任分界の決定
候補ごとに、対応範囲と運用責任を比べます。そのうえで、PoCや契約で確かめる内容を明らかにします。
- 自社運用：OSSを組み合わせた構成と、社内の運用体制の検討。
- Mercurial対応クラウド：運用範囲とサービス条件を比べます。
- 企業向けSCM製品：製品の機能と責任分界の比較。
- Gitへの段階移行：移行範囲と既存資産の扱い方。
Heptapodは、HTTPS、SSH、Web UIに対応し、課題管理も提供します。さらに、マージリクエスト、オンデマンドCI/CD、コンテナレジストリも提供します（出典: Heptapod公式Features、2026年確認）。
GitLabの全機能がMercurialでも同じように使えるかは、PoCで確かめます。特に、subrepository、bookmark、LFS相当の大容量ファイルは注意が必要です。また、外部課題管理との連携も確認対象です。
RhodeCodeは、Mercurial、Git、Subversionをまたいで権限管理やレビューを行いたい企業に適しています。
クラウドを使う場合は、データ所在地、バックアップ保持期間、SLAを契約前に確認します。さらに、障害時の連絡先、退会時のエクスポート、個人情報の扱いも確かめます。
自社運用では、Mercurial担当者に加えて、OS、ネットワーク、認証の責任者も決めます。また、バックアップと監視の各責任者も置きます。
フェーズ3：設計・開発による安全な標準構成の作成
まず、標準構成で押さえる要点を整理します。
- 通信と認証：HTTPSまたはSSHに絞り、SSOやLDAPと連携させます。
- アクセス権：管理者、開発者、レビュー担当者、閲覧者、CI用サービスアカウントに役割を分けて設定。
- 履歴と承認：公開済みの変更を表すphase、短期作業のtopicやbookmark、named branchの使い分けを決めておきます。
開発者PCから本番環境までの経路は、図にしておきます。途中には、リモートリポジトリ、レビュー、CI/CDがあり、成果物を経て本番環境に至ります。さらに、管理画面とリポジトリへのアクセスも分けて設定します。
入社、異動、退職とアカウントを自動で連動させると、退職者の権限が残る事態を減らせます。共有アカウントは、原則として使いません。
変更を誰でも書き換えられる状態だと、リリース済みの履歴や監査記録の信頼性が下がります。そのため、禁止する操作はサーバー側のフックで制御します。
レビューが必須となる条件、タグを付ける人、緊急変更の承認手順も、文書にまとめておきます。
CI/CDでは、代表リポジトリのclone後に、依存取得、静的解析、単体・結合テストを自動で実行します。さらに、成果物の生成とデプロイ承認も、同じ流れに組み込みます。
既存のCIがMercurialを扱えない場合は、ミラーや変換を安易に追加しない方針です。履歴、権限、失敗時の再実行方法まで含めて、どこまでを誰が受け持つかを設計します。
フェーズ4：テストによる機能・性能・復旧の検証
代表リポジトリを使って、機能と性能をまとめて検証します。画面の表示も、合わせて確認します。
- 基本機能：clone、pull、push、merge、レビュー、権限エラー、タグ付け、CI実行。
- 性能・表示：高負荷時のclone時間、同時push、差分表示、検索、Web UI応答。
- 記録とデータ：ログを確認し、本番に近い容量と履歴のテストデータを使います。
合格の判断は、実際に近い規模のリポジトリで下すことが大切です。ログの記録も、測定の対象に含めます。
セキュリティでは、退職者アカウントの無効化と秘密鍵の失効を確認します。さらに、権限の横断と監査ログの改ざん防止も確かめます。
バックアップの暗号化と外部公開の設定も確認します。復旧テストでは、障害や破損、誤削除を想定します。認証基盤の停止も、想定に含めます。
目標復旧時間と目標復旧時点を測定します。合格条件には、別環境へ復元して、開発者がcloneできるところまでを含めます。
フェーズ5：稼働における段階移行と切り戻しの準備
全リポジトリを一度に切り替えず、まずは重要度の低いパイロットから始めます。移行手順と切替管理も、段階に分けて進めます。
- 利用者へ案内し、接続先を変更します。
- 実際のチームで、認証、レビュー、CI、リリース、問い合わせの流れを確かめます。
- 問題がなければ、重要度の高いリポジトリへ広げ、責任者と切替日時を割り振ります。
Git移行では、ソースのみを移す方法、ソースと履歴を移す方法、履歴とメタデータまで移す方法を使い分けます。
GitHub公式は、Mercurialからソースと履歴を移す経路を案内しています。変換には、Mercurial、Git CLI、Pythonを使います（出典: GitHub Docs「Migration paths to GitHub」、2026年確認）。
コストは、リポジトリの価値に応じて配分します。現役の重要なリポジトリは履歴まで確認し、古いアーカイブはスナップショットにします。
切替計画には、最終バックアップと書き込み停止、変換または同期を明記します。さらに、利用者確認と切り戻し期限も書いておきます。
旧環境については、切り戻し先として残す期間、アクセスを許可する人、移行後に変更を入れないルールも決めます。
また、GitHub公式は、リポジトリごとのドライラン、移行前後の通知、CI/CDや連携の再設定を推奨しています。そのため、運用の切り替えまでを稼働作業として見積もります。
フェーズ6：定着による属人化しない運用の仕組み
説明会で伝えたうえで、標準手順を日常業務へ組み込みます。担当者が不在でも運用できるよう、手順を用意しておきます。
- 開発者向け：cloneからレビュー、リリースまでの短い手順書。
- 管理者向け：ユーザー追加、権限変更、バックアップ確認、障害一次対応の手順書。
新入社員が半日程度で基本操作を再現できるか、担当者が不在でも権限変更や復旧連絡ができるかを確かめます。
運用指標としては、利用リポジトリ数やCI成功率を使えます。レビューの滞留時間、cloneやpushの失敗率も、指標になります。
復旧訓練の所要時間、未使用アカウント数、脆弱性対応の完了日数も、指標として数えられます。毎月、ログとバックアップを確認します。
四半期ごとに、権限を見直し、復旧訓練を行います。Mercurialのリリース情報を追い、セキュリティ更新の際は、影響の調査と更新の判断を誰が担うかを規程に記します。
Mercurialのシステム開発にかかる費用相場とコストの内訳
Mercurial本体は無料ですが、実際の費用は、調査、設計、移行、認証連携の合計です。CI/CD、バックアップ、監視、教育、保守も、費用に加わります。
国内の専用受託価格は、公開されている例が限られます。この数字は、リサーチノートにある国内業務システム案件の目安と、公開SaaS料金からの推定です。個別案件の確定額ではありません。
規模別の初期費用と期間の目安
規模ごとの初期費用と期間の推定レンジを見ると、規模が大きくなるほど金額と期間が広がることが分かります。検証範囲や可用性要件も、見積もりに影響します。
- 調査・PoC：50万〜200万円程度、2〜8週間。
- 小規模な自社運用：300万〜800万円程度、2〜4か月程度。
- 中規模基盤：800万〜3,000万円程度、4〜9か月程度。
- 大規模案件：3,000万円〜1億円以上、9か月〜2年以上となる可能性。
調査・PoCでは、リポジトリの洗い出しと権限の確認、代表リポジトリのclone・push、CI連携、移行可否を検証します。
小規模構成には、HTTPSとSSHの基本的な接続、権限、バックアップ、簡易CIが含まれます。
中規模基盤には、SSO、監査ログ、冗長化が含まれます。さらに、複数環境、チケット連携、既存リポジトリの移行も入ります。
大規模案件では、多拠点や数百〜数千の利用者、災害対策が含まれる場合があります。高可用性や厳格な監査が加わることもあります。
この金額は、国内業務システムの工数と技術者単価を当てはめた推定です。リポジトリ数や連携数によって、大きく変動します。
移行費とランニングコストを分けた計算
移行方法、サービス料金、保守範囲を分けて見ると、継続費用を比べられます。
- Git移行：500万〜2,000万円程度、2〜6か月程度。
- RhodeCode Cloud：Starterは月額80ドル、Teamは月額180ドルです。
- RhodeCode Cloud Enterprise：月額600ドル。
Starterの料金には、10席が含まれます。この料金例の出典は、RhodeCode公式のCloud Tiers（2026年確認）です。
別のページでは、RhodeCode Enterpriseが、1ユーザー年額75ドル、最低10ユーザーと案内されています。
履歴やタグ、ブランチ、作者情報だけを変換するなら、比較的費用を抑えられます。一方で、CIの書き換えや権限の再設計、並行稼働が加わると、工数が増えます。さらに、レビュー運用、教育、全件のドライランも、工数を押し上げる要素です。
履歴が不要なアーカイブと、監査や保守に履歴が必要な現役システムを分けると、移行費の対象を絞れます。
料金体系、為替、ストレージ、通信、CIの追加費用は、変わることがあります。そのため、見積もりの時点で公式料金と契約条件を確認します。
保守費の目安として、一般的な業務システムでは、初期開発費の年15〜25%程度を置くことがあります（出典: NotebookLM業務システム費用Q&A、2026年）。
保守費は、どこまでを含むかで変わります。たとえば、Mercurial本体やOS、Pythonの更新、脆弱性対応、監視は、範囲に入る場合があります。さらに、問い合わせ、復旧訓練、CIランナーの従量課金も、対象に含まれることがあります。
月額保守とクラウド利用料は、まとめずに内訳を分けて比べます。
Mercurialのシステム開発で見積もりを取る際のポイント
見積もりの差は、ライセンス費よりも、対象範囲と責任分界から生まれます。作業名だけを書いて依頼すると、後から予算が膨らむことがあります。
認証、CI、バックアップ、教育、切り戻しは、別料金になることがあります。RFPには、リポジトリ、利用者、連携、移行、運用を分けて書きます。
見積もりの入力となる要件とインベントリ
見積もりに渡す情報は、容量、利用者、接続、運用目標などに分けて、そろえておきます。
- 規模：リポジトリ数、総容量、最大容量、履歴保存年限、利用者数、同時利用ピーク。
- 構成：開発拠点、認証方式、権限グループ、CIジョブ数、外部連携数。
- 運用・移行：バックアップ世代数、目標復旧時間、Git移行時の各種対応表。
Git移行の際は、bookmark、named branch、phase、tag、subrepo、作者名の対応表も用意します。
GitHubの計画では、移行元リポジトリの名前、所有者、URLを一覧にすることを推奨しています。さらに、最終更新日時、プルリクエストや課題数も、同じ一覧に含めるよう勧めています。
公式ガイドは、全リポジトリのドライランで、移行できるデータと所要時間を確かめる流れを示しています（出典: GitHub Docs「Planning your migration to GitHub」、2026年確認）。
移行できないデータも、あわせて確認します。この考え方は、Mercurialを残す刷新案件にも当てはめられます。
複数社の同じ条件による比較
Mercurial継続、Heptapodなどでのホスティング、Git移行では、必要な経験が異なります。そこで、対応実績と責任範囲を、同じ条件で各社に尋ねます。
- 技術経験：公開可能な実績、対応Mercurialバージョン、履歴やメタデータの移行方法。
- 実装範囲：CI/CDの実装、SSO、監査、バックアップの担当範囲。
- 契約条件：納品物、変更単価、データ返却、障害時SLA、窓口やデータ所在地。
見積書は、工程ごとに分かれているものを選びます。区分には、調査・要件整理、PoC、設計、構築が含まれます。さらに、移行、テスト、教育、稼働支援、保守も分かれているかを見ます。
固定額と準委任の使い分け、追加変更の単価、ソースコードとIaCの引き渡しも確認します。
海外のサービスや企業の場合は、日本語窓口や時差を比べます。データ所在地、準拠法、請求通貨も、比較の対象です。
見積書に反映するリスクと受け入れ条件
典型的なリスクを洗い出し、発生条件や影響、回避策、発生時の責任者を決めます。
- 互換・移行：Git中心ツールとの互換性不足、サブリポジトリ漏れ、作者やタグの欠落。
- 運用・復旧：CI書き換え遅延、バックアップ復元不能、担当者の退職。
- 受け入れ：Webレビュー、指定時間内の復元、退職者アカウントの無効化を条件にします。
「移行完了」は、履歴の表示、タグの一致、ブランチまたはbookmarkの対応確認に分けて判定します。
ビルドの再現、レビューと課題の責任者の追跡、新しい接続先への切り替えも、個別に確認します。納品時には、未解決の制約の一覧を受け取ります。
将来のアップデートや追加連携に備えて、その前提も残しておきます。
Mercurialのシステム開発でよくある質問
費用、クラウド、Git移行、国内企業への依頼ごとに、判断の前提をまとめます。
Mercurialのシステムは無料で構築できますか？
本体や一部の関連ソフトは無料ですが、構築と運用には費用がかかります。認証、権限、バックアップ、監視では、人件費が発生します。
CI/CD、脆弱性対応、教育、障害復旧にも費用がかかります。そのため、ライセンス費だけでなく、5年間の運用工数と保守体制を含めた総保有コストで判断します。
Mercurialをクラウドで運用できますか？
運用できます。Heptapodは、MercurialのHTTPS、SSH、Web UIに対応し、CI/CDや課題管理も提供します。
RhodeCode Cloudのように、MercurialとGitを一つの基盤で扱えるサービスもあります。
SSOの方式、データ所在地、バックアップを確認します。さらに、CIの従量課金、SLA、契約終了時のエクスポートも確かめます。機密性、規制、可用性の要件に適合するかは、PoCで検証します。
MercurialからGitへ移行すると履歴は消えますか？
適切な変換と検証を行えば、履歴を残して移行できる場合があります。ただし、phase、bookmark、named branch、subrepositoryは、そのまま対応しないことがあります。
フック、レビュー、課題の履歴にも、同じ確認が必要です。重要なリポジトリは、ドライランでコミット数、作者、日時を比べます。さらに、タグ、ブランチ、差分、ビルド結果も照らし合わせます。
移行後の旧環境は、一定期間、読み取り専用で残しておきます。
Mercurialのシステム開発を日本企業へ依頼できますか？
依頼はできます。ただし、Mercurial専門を掲げる国内の受託会社は、公開情報が限られています。一般的な開発会社に対しても、Mercurialの実案件の経験を確かめます。
履歴移行、認証・権限、CI/CD、バックアップ復旧の経験を、一つずつ尋ねます。海外の専門企業と国内の要件整理・運用支援会社を組み合わせる方法もあります。
日本語窓口や時差、責任分界は、契約書に明記します。
まとめ：6フェーズとPoCによるMercurialの判断の進め方
リポジトリの洗い出しと代表リポジトリのPoC
全リポジトリ、利用者と権限、容量を一枚の表にまとめます。CI、外部連携、バックアップも、同じ表に入れます。
現役の代表リポジトリを使い、Mercurial継続、対応クラウド、自社運用、Git移行を比べます。履歴、レビュー、CI、復旧を検証しておくと、予想外の追加費用を抑えやすくなります。
構築後の定着と保守まで含めた見積もりの確認
構築費に加えて、稼働後の運用費と判断条件も含めて確認します。
- 保守範囲：稼働後の担当と費用の分担。
- 進め方：要件整理から定着までの6フェーズで進めます。そのうえで、リポジトリ、権限、CI/CD、バックアップ、監査、連携を洗い出します。
- 判断とPoC：業務・技術・運用費から継続か移行かを比べ、代表リポジトリの履歴、レビュー、CI、性能、復旧を確かめます。
- 費用目安：規模や移行範囲に応じた個別見積もり。
- 見積もり条件：リポジトリ数、容量、利用者、認証、CI、可用性を伝えます。移行範囲も含めて、納品物、保守、復旧訓練、契約終了時のデータ返却を比べます。
脆弱性対応、OSやPythonの更新、権限の見直しの費用を確認します。さらに、復旧訓練、利用者教育、問い合わせ対応の費用も確かめます。担当が明確なら、Mercurial継続でもGit移行でも安定運用できます。
推定レンジは、PoCが50万〜200万円、小規模自社運用が300万〜800万円、中規模基盤が800万〜3,000万円です。
Git移行は500万〜2,000万円程度です。Mercurial専用の公開相場はないため、個別見積もりを取ります。
▼全体ガイドの記事
・Mercurialのシステム開発の完全ガイド
▼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を創業。