マイクロサービス移行の外注｜分割設計の線引きと発注5ステップ

ベンダーの提案書に「マイクロサービス化により将来の拡張性を確保します」と書かれている。金額は想定の2倍、期間は18ヶ月。妥当なのかどうか判断できないまま、稟議に上げるべきか迷っている。マイクロサービス移行の発注を検討する現場では、こうした状況が珍しくありません。

判断が難しい理由ははっきりしています。マイクロサービス移行の成否を決めるのは「どこでサービスを切るか」という分割設計であり、それは技術の問題であると同時に、自社の業務がどういう単位で動いているかという業務ドメインの問題だからです。技術だけでは決められず、かといって社内にアーキテクチャを評価できるエンジニアがいない。この板挟みが、発注判断を止めています。

そして、分割設計まで含めて外部に丸投げすると、システムが物理的には分かれているのに、実際には相互に依存しあって一体でしか動かせない「分散モノリス」に陥りやすくなります。モノリスの不便さはそのままに、分散システムの複雑さだけが上乗せされた状態です。この状態は稼働後しばらく経ってから顕在化するため、契約が終わったあとに問題が発覚します。

そこで有効なのが、「全部を外注する／全部を内製する」の二択から離れ、社内が握る意思決定と、外部エンジニアに任せる実行を分けて設計するという進め方です。分割の境界を決める権限を社内に残したまま、設計の具体化と実装は外部の力を使う。この線引きさえ設計できれば、社内にアーキテクトがいなくても移行は進められます。

本記事では、マイクロサービス移行を外部エンジニアに依頼する際の進め方を、発注者の視点から整理します。移行前に社内で決めるべきこと、外注でよくある失敗パターン、発注の5ステップ、役割分担の線引き、外注先の選び方と提案書の確認ポイント、契約形態、費用と期間の見立て方まで順に解説します。

マイクロサービス移行を外注する前に社内で決める3つのこと

外注先を探し始める前に、発注者側で言語化しておくべきことがあります。移行の目的、許容できる期間と停止リスク、移行後の運用主体の3つです。これが曖昧なまま提案を受けると、提案書に書かれた分割案が妥当なのかを評価する物差しを持てず、結果的に判断そのものを外部に委ねることになります。

マイクロサービス移行のメリット・デメリットを発注判断の言葉に置き換える

マイクロサービスのメリット・デメリットは技術記事で語られることが多いのですが、発注判断に必要なのは技術特性そのものではなく、それが費用・期間・運用体制にどう跳ね返るかという翻訳です。

重要なのは、これらのメリットが「サービス数を増やせば増えるほど得られる」ものではないという点です。Martin Fowler 氏は、マイクロサービスを採用する前提条件として、サーバーを数時間で立ち上げられる迅速なプロビジョニング、基本的な監視、迅速なアプリケーションデプロイの能力を挙げ、これらの基礎能力がない状態でマイクロサービス化を進めるべきではないと指摘しています（Microservice Prerequisites - martinfowler.com）。

つまり、移行費用として見積もるべきものはアプリケーションの分割作業だけではありません。CI/CD、監視、ログ集約といった運用基盤の整備が同時に必要になります。提案書の金額が想定より高い場合、この基盤整備分が含まれているかどうかを確認すると、金額の内訳が読み解けるようになります。

移行の目的を「スピード」「スケール」「組織分割」のどれに置くか

マイクロサービス移行の目的は、大きく3つに整理できます。どれを主目的に置くかで、切り出すべきサービスの優先順位が変わります。

• スピード（変更のリードタイム短縮）: 頻繁に改修が入る機能を優先的に切り出す。改修頻度の高い機能から順に独立させることで、効果が早く出ます
• スケール（負荷対策・コスト最適化）: 負荷が集中する機能を優先的に切り出す。アクセスの多い参照系や、バッチ処理などリソースを大量に使う部分が候補になります
• 組織分割（チームの独立性確保）: 事業部門ごとに担当領域を分けたい場合に、業務の責任範囲に沿ってサービスを切ります

この3つは同時に達成できるとは限りません。たとえば「改修頻度が高い機能」と「負荷が集中する機能」が別の場所にある場合、どちらを先に切るかで最初の1年の成果がまったく変わります。目的が言語化されていないと、この優先順位を外部の提案に委ねることになり、提案の妥当性を検証する軸を失います。

目的を決める際は、現状の困りごとを数字で押さえておくと有効です。「1機能の改修に何週間かかっているか」「月間で何件の改修要望が滞留しているか」「ピーク時のレスポンスタイムはいくらか」といった実測値があれば、移行後に何がどれだけ改善すれば成功と言えるのかを、成功基準として契約に書き込めるようになります。

全面移行しない選択肢（モジュラーモノリス・一部だけ切り出し）も比較対象に入れる

提案を受ける前に、「マイクロサービス化しない」選択肢も机上に載せておくことをおすすめします。目的が「改修のリードタイム短縮」であるなら、必ずしも全面的なマイクロサービス化が最短経路とは限らないためです。

比較対象になる選択肢は主に3つあります。

1. モノリスのまま内部構造を整理する（モジュラーモノリス）: デプロイ単位は1つのまま、コード内部をモジュール単位に整理して依存関係を整理する方法です。分散システムの運用コストを負わずに、変更の影響範囲を局所化できます
2. 一部の機能だけをサービスとして切り出す: 改修頻度や負荷が突出している機能だけを独立させ、残りはモノリスのまま維持します。前述の Martin Fowler 氏も、まず少数のサービスだけを切り出して残りはそのままにする段階的な移行を推奨しています
3. 全面的にマイクロサービス化する: システム全体をサービス群に再構成します。効果は大きい一方、期間・費用・運用体制の要求水準がもっとも高くなります

コードの見通しの悪さや技術的負債そのものが課題である場合は、アーキテクチャの分割より先に既存コードの改善を検討したほうが費用対効果が高いケースもあります。既存コードの負債を外部と一緒に解消していく進め方については、レガシーコード改善の外注で扱っている論点が参考になります。

提案を受ける際は、この3つを比較検討したうえでマイクロサービス化を選んだ、という経緯を社内で共有できる状態にしておくと、稟議での説明が通りやすくなります。

マイクロサービス移行の外注でよくある3つの失敗パターン

マイクロサービス移行の失敗は、技術力不足よりも発注設計の抜けから起きることが少なくありません。ここでは、発注者側の視点から見た代表的な3つの失敗パターンと、それぞれ「どの意思決定が誰の手にも渡っていなかったか」を整理します。

失敗1｜サービス分割の境界設計を丸投げして分散モノリスになる

もっとも典型的なのが、サービスをどこで切るかの判断を外部に完全に委ねてしまうケースです。

サービスの境界は、本来は業務の単位に沿って引かれるべきものです。たとえば「受注」と「在庫」を別サービスにするかどうかは、その会社で受注業務と在庫業務がどれだけ独立して動いているかによって答えが変わります。外部のエンジニアは既存コードの構造は読み取れますが、業務がどういう責任分担で回っているかまでは分かりません。その結果、コードの見た目の分かれ方に沿って機械的に分割されてしまうことがあります。

こうして生まれるのが分散モノリスです。サービスは複数に分かれているのに、1つの業務処理を完了するために毎回すべてのサービスを呼び出す必要があり、どれか1つを変更すると他も同時にデプロイしなければならない状態です。モノリスの結合の強さは残ったまま、ネットワーク越しの通信・分散トランザクション・複数サービスの監視といった運用負荷だけが増えます。

この失敗の本質は、技術的な設計ミスというより、分割の根拠を発注者がレビューする機会が発注プロセスに組み込まれていなかったことです。分割案が出てきたときに「なぜこの単位で切るのか」を業務側が確認する工程がなければ、業務知識は設計に反映されません。

失敗2｜移行だけを外注し、監視と障害対応の担い手が決まっていない

2つ目は、移行プロジェクトの範囲を「実装と本番リリースまで」と定義してしまい、稼働後の運用体制が空白のまま本番を迎えるパターンです。

モノリスであれば、監視対象は1つのアプリケーションと1つのデータベースでした。マイクロサービスに移行すると、サービスの数だけ監視対象が増え、加えてサービス間の通信も監視対象になります。障害が起きたときも「どのサービスで起きているか」を特定する工程が先に入るため、切り分けの難易度が上がります。

この状態で運用の担い手が決まっていないと、リリース直後から社内の情シス部門に想定外の負荷がかかります。あるいは、移行を担当した外部エンジニアに障害対応のたびに個別依頼をかけることになり、契約外の作業として追加費用が発生し続ける状況になります。

防ぐためには、発注範囲を決める段階で「稼働後の監視は誰が見るのか」「一次切り分けは社内か外部か」「夜間・休日の対応をどうするか」を移行スコープの一部として決めておく必要があります。運用設計と運用要員の確保は、移行の後工程ではなく、移行と同時に進める工程だと位置づけてください。

失敗3｜一括請負で全面移行を契約し、途中の設計変更が全て追加費用になる

3つ目は、全面移行を1本の請負契約でまとめて発注してしまうパターンです。

マイクロサービス移行の難しさは、着手時点では分割単位を確定できないところにあります。最初のサービスを切り出して初めて、既存システムのどこに想定外の依存があったか、どのデータが複数機能から参照されていたかが判明します。つまり、進行中に分割案が変わるのが通常です。

ところが請負契約は、契約時に定めた成果物を完成させることを目的とする契約です。契約後に分割案を見直したい場合、それは仕様変更として扱われ、追加費用と納期延長の交渉が必要になります。移行の途中で「この分け方は良くない」と気づいても、変更コストが高すぎて当初案のまま進めるという判断になりやすく、結果として分割の境界を丸投げした場合と同じ状態に行き着きます。

さらに、全面移行を一括で契約すると、途中で立ち止まって続行可否を判断する機会がありません。効果が出ていないと分かっても、契約上は完成まで進めるしかない構造になります。

この失敗も、技術ではなく契約設計の問題です。フェーズを分けて発注し、フェーズの区切りごとに評価と続行判断を挟む形にすれば、変更を仕様変更ではなく次フェーズのスコープ調整として扱えるようになります。

マイクロサービス移行を外注する進め方5ステップ

ここからは、発注者が主導する前提でのマイクロサービス移行の手順を5段階で示します。各ステップで「社内が担う作業」「外注する作業」「そのステップで得るべき成果物」を対応させておくと、どこまでを誰に依頼するかの線引きが具体化します。

ステップ1｜現状把握と分割候補の洗い出しは社内が主導する

最初のステップは、既存システムの現状把握と分割候補の洗い出しです。ここは社内が主導すべき工程です。

社内が用意するのは、業務の単位と課題の実態です。具体的には、システムが担っている業務を機能ではなく業務プロセスの単位で書き出すこと、直近1〜2年でどの機能に改修が集中したかを整理すること、現在困っていること（改修のリードタイム、障害の傾向、性能のボトルネック）を数字で示すことです。これらは社内にしかない情報で、外部が代わりに調べることはできません。

一方、コードの依存関係の可視化、データベースのテーブル参照関係の調査、技術的に切り出しが困難な箇所の特定は、外部エンジニアに依頼できます。この調査だけを短期の準委任契約で切り出して発注する方法もあり、本格的な移行を発注する前に外注先の実力を測る機会にもなります。

なお、既存システムの状態が悪く、そもそもコードの可読性やテストの不在が課題の中心にある場合は、分割の前段として負債の棚卸しが必要になります。この判断軸についてはレガシーコード改善の外注を参考にしてください。

ステップ2｜ストラングラーパターンで段階移行するか、部分切り出しに留めるかを決める

分割候補が見えたら、どういう方式で移行するかを決めます。代表的な方式が、ストラングラーパターン（strangler fig パターン）による段階的な置き換えです。

これは、既存のモノリスを残したまま、機能を1つずつ新しいサービスに置き換えていく方式です。AWS の規範ガイダンスでは、この移行プロセスを「変換（モダナイズしたコンポーネントをレガシーと並行して作成する）」「共存（モノリスの境界に HTTP プロキシを組み込み、外部からの呼び出しを新サービスへ振り分ける。モノリスはロールバック用に残す）」「排除（トラフィックが新サービスに移ったら、モノリスから旧機能を廃止する）」の3ステップとして整理しています（strangler fig パターン - AWS 規範ガイダンス）。

発注者にとってこの方式が持つ意味は、各段階で切り戻せるという点にあります。新サービスに問題があればプロキシの振り分け先を旧機能に戻せるため、一括で切り替えるビッグバン移行に比べて事業停止リスクを抑えられます。同時に、旧機能と新サービスを並行して維持する期間が発生するため、その分の運用コストが上乗せされます。

もう一方の選択肢が、既存機能には手を入れず、新規機能だけを独立したサービスとして作る方式です。既存システムの改修リスクを負わずに済む反面、既存部分の課題は解消されません。「新規開発が多く、既存部分は安定している」という状況では合理的な選択になります。

どちらを選ぶかは、停止をどこまで許容できるか、並行稼働のコストを何ヶ月負担できるか、既存部分の課題がどれだけ深刻かで決まります。この判断材料は社内にあるため、方式の最終決定は発注者側で行い、外部には各方式の実現性と工数の比較を出してもらう、という役割分担が現実的です。

ステップ3｜パイロット1サービスで外注先の設計力を確かめる

方式が決まったら、いきなり全面移行に着手せず、まず1サービスだけを切り出すパイロットを実施します。

パイロットの目的は3つあります。1つ目は外注先の設計力を実物で確認すること、2つ目は自社システム固有の難所を早期に洗い出すこと、3つ目は以降のフェーズの工数見積もりの根拠となる実績値を得ることです。

対象サービスの選び方には目安があります。業務上の重要度が高すぎず（失敗しても事業影響が限定的）、かといって簡単すぎず（技術的な難所を1つは含む）、既存機能との依存が比較的少ないもの、という条件を満たす機能が適しています。多くの場合、参照系の機能や、比較的独立した通知・帳票・マスタ管理といった領域が候補になります。

パイロットで発注者が確認すべきは、動いたかどうかだけではありません。以下の点を確認すると、その外注先に以降のフェーズを任せられるかの判断材料になります。

• 分割の境界を決めた根拠を、業務の言葉で説明できるか
• 既存モノリスとのデータ整合性をどう保っているかを説明できるか
• 切り戻し手順が用意され、実際に検証されているか
• 監視・ログ・障害検知の仕組みが同時に整備されているか
• 実際に要した工数と、事前見積もりとの乖離がどの程度だったか

パイロットを別契約として切り出しておけば、この段階で外注先を変更する判断もできます。最初から全面移行を1社に一括発注してしまうと、この選択肢が失われます。

ステップ4｜段階移行中の並行稼働とデータ整合性をどう設計するか

パイロットの評価を経て本格移行に入ると、旧システムと新サービスが同時に本番稼働する期間が始まります。このフェーズで発注者が意識すべき論点はデータ整合性です。

典型的な論点は次のようなものです。移行済みサービスと未移行のモノリスが同じデータを参照している場合、どちらを正とするのか。両方に書き込みが発生する場合、どうやって同期するのか。同期にタイムラグがある場合、業務上どこまでのズレなら許容できるのか。

この最後の問いは、技術ではなく業務の問題です。たとえば在庫数の反映が数秒遅れても業務が回るのか、それとも即時でなければ受注が破綻するのかは、業務側にしか答えられません。ここを外部に判断させると、技術的には正しくても業務上は使えない設計になる、あるいは過剰に厳密な整合性を求めて工数が膨らむ、という結果になりがちです。

発注者は、移行対象ごとに「許容できる遅延」と「絶対にズレてはいけないデータ」を明示してください。この情報を渡すことで、外部エンジニアは同期方式や整合性の担保方法を適切な水準で設計できるようになります。

また、並行稼働の期間が延びるほどコストが積み上がる点にも注意が必要です。旧システムと新サービスの両方を維持し、データ同期の仕組みも稼働させ続けるため、期間そのものがコスト要因になります。フェーズごとに並行稼働の終了条件を決めておくと、期間の間延びを防げます。

ステップ5｜運用移管と旧システム停止の判断基準を先に決める

最後のステップは、運用の移管と旧システムの停止です。ここでよく起きるのが、「念のため」旧システムを止められないまま何年も維持費を払い続ける状態です。

これを防ぐには、停止の判断基準を移行の着手前に決めておくことが有効です。判断基準の例としては、旧機能への呼び出しがゼロの状態が一定期間続いていること、新サービス側で月次・年次を含む業務サイクルを一巡していること、障害発生率が旧システムと同等以下に収まっていること、といった条件が挙げられます。

運用移管については、引き渡しの成果物を契約時に定義しておきます。ソースコードとインフラ構成だけでなく、サービス構成図、サービス間の依存関係図、監視項目とアラートの一覧、障害発生時の切り分け手順、デプロイ手順、といった運用ドキュメントを成果物に含めておかないと、外部エンジニアの契約終了と同時に運用ノウハウが消えます。

引き渡し後に社内だけで運用できるのか、継続的に外部の支援を受けるのかも、この段階までに決めておくべき事項です。外部支援を継続する場合は、移行フェーズとは別の運用支援契約として体制と稼働時間を定義します。

どこまでを外部エンジニアに任せるか｜役割分担の線引き

ここまでのステップを通して見えてくるのが、社内が握るべき意思決定と、外部に任せる実行の線引きです。この線引きこそが、マイクロサービス移行の外注設計における中心的な論点になります。

社内が握るべき意思決定（業務ドメインの境界・優先順位・投資判断）

社内に残すべきなのは、「自社の業務がどう動いているか」を知らなければ答えられない問いです。具体的には次のような領域です。

これらを外部に委ねると、提案の妥当性を検証する基準そのものを失います。逆に言えば、この6項目さえ社内で決められれば、技術的な設計と実装は外部に任せても、判断の主導権は保てます。

社内にアーキテクトがいなくても、この6項目は業務を知る担当者が答えられる内容です。アーキテクチャの知識が必要なのは、この意思決定を技術的な設計に翻訳する部分であり、そこは外部の力を借りられます。

外部エンジニアに任せやすい領域と、任せる際の前提条件

一方、外部に任せやすいのは、社内固有の業務知識よりも技術的な専門性が効く領域です。

• 既存コードの依存関係の可視化・技術的制約の洗い出し
• 社内が決めた業務境界を、技術的なサービス境界と API 設計に落とし込む具体化
• サービスの実装・テスト・データ移行スクリプトの作成
• コンテナ基盤・CI/CD パイプライン・監視基盤の構築
• 性能試験・負荷試験の実施と改善
• 運用ドキュメント・障害対応手順の整備

ただし、これらを任せるには前提条件があります。社内が決めるべき6項目が言語化され、文書として外部に渡せる状態になっていることです。この前提が満たされないまま実行を依頼すると、外部エンジニアは判断材料がないまま設計せざるを得ず、結果として本記事の冒頭で触れた「分割設計の丸投げ」と同じ構造になります。

また、移行先のインフラをクラウドに移すことを同時に検討している場合は、アプリケーションの分割とクラウド移行を同じ担当者に任せるかどうかも論点になります。求められるスキルセットが異なるため、体制と人材要件を分けて考えたほうが調達しやすいケースがあります。クラウド移行側の人材要件についてはAWS移行エンジニアを業務委託で確保する方法で整理しています。

体制パターン3つ（外部テックリード型／外部実装チーム型／全面委託＋社内レビュー型）

社内のリソース状況に応じて、体制の組み方には主に3つのパターンがあります。

外部テックリード型は、アーキテクチャ設計と技術判断を担う外部エンジニアを1〜2名確保し、実装は社内エンジニアが担当する形です。社内に実装できるエンジニアはいるが設計を主導できる人がいない場合に適しています。移行のノウハウが社内に蓄積されやすい一方、社内エンジニアの稼働を確保できないと進みません。

外部実装チーム型は、社内にプロダクトオーナー的な役割を置き、設計の具体化と実装を外部チームに任せる形です。社内に開発リソースがない場合の現実的な選択肢になります。社内側に、外部からの質問に答え、判断を返せる担当者を専任に近い形で置けるかどうかが成否を分けます。

全面委託＋社内レビュー型は、設計から実装・運用まで外部に委託し、社内は要所でのレビューと承認に徹する形です。社内リソースがもっとも少なくて済みますが、レビューの実効性を担保する仕組みがないと丸投げと変わりません。この形を取る場合は、分割案のレビュー会をフェーズごとに契約上の義務として定めるか、外部の第三者にセカンドオピニオンを依頼する仕組みを併用することを検討してください。

いずれの体制でも共通するのは、社内側に「決める人」を明示的に置くことです。誰が分割の境界を承認するのか、誰が続行・中止を判断するのかが不明確だと、体制の形にかかわらず判断が滞ります。

マイクロサービス移行の外注先の選び方と提案書の確認ポイント

体制の方向性が決まったら、外注先の選定に入ります。ここでは外注先タイプごとの向き不向きと、提案書を評価する際の質問セットを整理します。

外注先タイプ別の向き不向き（受託開発会社／フリーランス・複業／SES）

実務上は、これらを組み合わせる形が現実的です。たとえば、設計を主導する外部アーキテクトをフリーランスで1名確保し、実装は受託開発会社に依頼する、といった構成です。この場合、設計と実装の責任分界点を契約時に明確にしておく必要があります。

なお、マイクロサービス化に伴ってコンテナ基盤（Kubernetes 等）の構築が必要になる場合、その部分を同じ外注先に任せるべきかは別途検討が必要です。アプリケーション開発とプラットフォーム運用では求められる専門性が異なるためです。この判断についてはKubernetes外注の判断軸で詳しく扱っています。

提案書で必ず確認したい5つの質問

提案書を受け取ったら、次の5つを質問してください。回答の具体性が、その外注先の実力と、こちらの状況をどこまで理解しているかを示します。

1. この分割単位にした根拠を、業務の言葉で説明してください

「疎結合にするため」「一般的な分割パターンだから」といった技術一般論しか返ってこない場合、自社の業務構造が設計に反映されていない可能性があります。「御社の受注業務と在庫管理が別部門で運用されているため」のように、こちらが渡した業務情報に紐づいた説明が返ってくるかを確認します。

2. 移行中のデータ整合性をどう担保しますか。ズレが発生した場合の検知と復旧はどうしますか

並行稼働期間中のデータ同期方式、想定される遅延の大きさ、不整合が発生した場合の検知手段と復旧手順まで説明できるかを見ます。ここが曖昧なまま進むと、稼働後にデータ不整合の調査で多大な工数が発生します。

3. 移行前後で性能はどう変わりますか。劣化した場合の対策は用意されていますか

サービス間がネットワーク通信になるため、処理によっては応答時間が悪化します。どの処理で劣化が想定され、どう対策するのか（キャッシュ、非同期化、呼び出し回数の削減など）を確認します。性能試験を実施する計画が含まれているかも重要です。

4. どういう条件になったら中止・方針転換を提案しますか

この質問への回答は、外注先が自社の成功を優先しているか、契約完遂を優先しているかを見分ける材料になります。「効果が出ない場合はモジュラーモノリスへの方針転換も提案します」のように、こちらの利益に沿った回答が返ってくるかを見てください。

5. 引き渡し時の成果物を具体的に列挙してください

ソースコード以外に、サービス構成図、API 仕様、依存関係図、監視項目一覧、障害切り分け手順、デプロイ手順、環境構築手順が含まれるかを確認します。ここで列挙された内容を、そのまま契約の成果物定義に落とし込みます。

契約形態と責任分界点をフェーズごとに決める

マイクロサービス移行の外注では、契約形態の選び方が失敗の防止に直結します。分割単位が進行中に変わるという特性を、契約設計にどう織り込むかが論点です。

準委任契約と請負契約をフェーズごとに使い分ける

システム開発の外部委託（業務委託）で使われる契約形態は、主に請負契約と準委任契約です。実務では両者をまとめて「業務委託契約」と呼ぶことが多いのですが、業務委託という名称の契約書であっても、中身が請負なのか準委任なのかによって受託側が負う責任の範囲は変わります。請負契約は仕事の完成を目的とし、成果物の完成責任を受託側が負います。準委任契約は業務の遂行を目的とし、専門家としての注意義務をもって業務にあたることが求められます。契約書の表題ではなく、条文で定められた義務の内容がどちらの類型にあたるかを確認してください。

2020年4月1日施行の改正民法では、準委任契約に2つの類型があることが明文化されました（民法 - e-Gov法令検索、第648条・第648条の2）。作業量など履行の割合に応じて報酬を支払う「履行割合型」と、業務の結果もたらされる成果に対して報酬を支払う「成果完成型」です。成果完成型を使えば、準委任契約でも成果物の納品を報酬の条件に紐づけられます。

マイクロサービス移行では、フェーズごとに契約形態を使い分ける設計が有効です。

要件が固まっていない設計・検討フェーズを請負契約にすると、要件確定の遅れが受託側のリスクとして見積もりに上乗せされ、結果的に費用が高くなります。逆に、対象が明確なパイロットや個別サービスの実装を準委任にすると、成果に対する責任が曖昧になります。フェーズの性質に合わせて選び分けることが、双方にとって合理的です。

なお、アジャイル型の開発を前提とする場合、IPA（独立行政法人情報処理推進機構）が公開している情報システム・モデル取引・契約書（アジャイル開発版）が参考になります。このモデル契約は準委任契約を採用しており、変更を前提とした開発における役割分担の考え方が整理されています。ウォーターフォール型を含む一般的な契約については情報システム・モデル取引・契約書（第二版）が公開されています。

移行案件の契約に入れておきたい4条件

契約形態の選択に加えて、マイクロサービス移行に固有のリスクをカバーする条件を契約に盛り込んでおきます。

1. フェーズごとの成果物定義

各フェーズの終了時に何が納品されるかを列挙します。前述の提案書確認で列挙してもらった成果物（構成図、依存関係図、監視項目一覧、障害切り分け手順など）を、そのまま成果物定義に転記します。「ソースコード一式」だけの定義は避けてください。

2. 分割案を変更する場合の合意手順

進行中に分割単位を見直す事態は想定内として扱い、その場合の手順を決めておきます。誰が変更を提起し、誰が承認し、工数と費用への影響をどう扱うかを定めます。この条項があることで、変更が「仕様変更に伴う追加費用交渉」ではなく「合意済みの手順に沿った調整」になります。

3. フェーズごとの上限金額

準委任契約では稼働時間に応じて費用が発生するため、フェーズごとに上限金額を設定します。上限に近づいた時点で報告する義務を定めておくと、想定外の超過を防げます。

4. 中止・撤退の条件

どういう状態になったら次フェーズに進まない判断をするかを、契約段階で合意しておきます。パイロットフェーズの結果が事前に定めた基準（性能、工数の乖離率、障害発生率など）を満たさない場合は次フェーズに進まない、という形です。あわせて、中止時点までの成果物の帰属と、中止時の精算方法も定めておきます。

この4条件のうち、特に効果が大きいのが2番目の「分割案を変更する場合の合意手順」です。分割設計の失敗は、多くの場合「途中で気づいたが変更コストが高すぎて直せなかった」ことによって固定化します。変更の手順が契約に組み込まれていれば、気づいた時点で軌道修正できます。

マイクロサービス移行の費用と期間の見立て方

マイクロサービス移行の費用は、システムの規模と状態によって大きく変わるため、一律の相場を示すことは困難です。ここでは金額を断定する代わりに、何が費用と期間を左右するのかという構造を整理します。この構造が分かれば、提案書の金額が何によって決まっているかを読み解けるようになります。

マイクロサービス移行の費用と期間を左右する5つの要因

1. 切り出すサービスの数

もっとも直接的な要因です。ただし単純な比例関係ではありません。1つ目のサービスには基盤整備（CI/CD、監視、デプロイパイプライン）のコストが集中し、2つ目以降は基盤を再利用できるため単価が下がる傾向があります。逆に、サービス数が増えるほどサービス間の連携パターンが増え、テストと運用の複雑さは増していきます。

2. データベースを分割するかどうか

アプリケーションだけを分割してデータベースは共有したままにするか、データベースもサービスごとに分けるかで、工数は大きく変わります。データベースを分割する場合、既存のテーブル間の参照関係を解きほぐし、複数サービスにまたがる処理のデータ整合性を設計し直す必要があります。この作業が移行工数の主要因になることが少なくありません。

3. 並行稼働期間の長さ

旧システムと新サービスを同時に維持する期間は、インフラ費・運用費・データ同期の仕組みの維持コストが二重にかかります。段階移行の期間設計が、そのままコストに反映されます。

4. 既存仕様の文書化状況

既存システムの仕様書が存在しない、あるいは実態と乖離している場合、コードから仕様を読み解く工数が上乗せされます。テストコードがない場合は、移行前後で挙動が同じであることを検証する手段を用意する工数も必要になります。この部分は、社内に既存システムを知る担当者がいるかどうかでも変わります。

5. 移行中の機能開発を凍結できるかどうか

移行中も並行して機能追加や改修が発生する場合、旧システムと新サービスの両方に同じ変更を反映する必要が生じることがあります。これは工数の増加だけでなく、移行完了の遅延要因にもなります。事業要請上、開発を止められないケースは多いため、その場合は「移行中に追加開発を受け入れる前提での工数」として見積もりに織り込む必要があります。

提案書の金額に納得感が持てない場合は、この5要因のうちどれが金額を押し上げているのかを質問してください。内訳が説明できない提案は、見積もりの根拠が曖昧である可能性があります。

予算超過を防ぐフェーズ分割と中止条件の合意

費用の不確実性に対処する方法は、全体の金額を精緻に見積もることではなく、意思決定のタイミングを増やすことです。

具体的には、次の3つを組み合わせます。

フェーズごとに契約を分ける: 現状調査、パイロット、段階移行の各フェーズ、運用移管をそれぞれ別の契約単位にします。最初に確定させるのは調査フェーズの費用だけで、以降のフェーズは前フェーズの結果を踏まえて見積もります。

パイロットで単価と生産性を実測する: パイロットフェーズで、1サービスあたりに実際どれだけの工数がかかったか、事前見積もりとの乖離がどれだけあったかを記録します。この実績値があれば、以降のフェーズの見積もりを自社の実データに基づいて検証できます。ベンダーの提示する工数が妥当かどうかを、一般論ではなく自社の実績で判断できるようになります。

中止条件を先に合意する: 前述のとおり、次フェーズに進まない条件を事前に定めます。稟議上も、「全体でN億円」ではなく「まず調査フェーズにX万円、パイロットにY万円、その結果を見て全体計画を再提出」という形にできれば、承認のハードルは下がります。

この進め方には、全体像が見えにくいという難点があります。しかし、着手時点では分割単位が確定しないという移行の性質を踏まえると、精緻な全体見積もりは実際には推測に近いものになります。段階的に確度を上げていく進め方のほうが、結果的に総額のぶれを抑えられます。

まとめ｜分割設計を社内に残したまま外部の実装力を使う

マイクロサービス移行の外注で問題が起きるのは、技術力が足りないからではなく、意思決定の所在が曖昧なまま発注が進むからです。本記事で整理した骨格を、最後にまとめます。

• 社内が握る6つの決定を先に言語化する: 業務ドメインの境界、切り出す優先順位、停止・遅延の許容度、データ整合性の要求水準、投資判断と続行・中止の決定、移行の成功基準。この6項目は業務を知る担当者が答えられる内容であり、社内にアーキテクトがいなくても決められます
• 実行は外部に任せてよい: 依存関係の可視化、サービス境界と API の具体化、実装、基盤構築、テスト、運用ドキュメント整備は、外部の専門性が効く領域です
• パイロットから段階的に発注する: 全面移行を一括契約せず、調査 → パイロット → 段階移行 → 運用移管とフェーズを分け、各区切りで続行判断を挟みます
• 契約にレビュー機会と変更手順を埋め込む: 分割案の変更手順、フェーズごとの成果物定義、上限金額、中止条件の4条件を契約に入れることで、分割設計の失敗を途中で修正できる状態を作ります

「丸投げする」か「全面内製する」かの二択で考えると、社内にアーキテクトがいない時点で選択肢がなくなります。しかし、決定は社内に残し、実行を外部に委ねるという第三の進め方であれば、現在の体制のままでも移行は始められます。

最初の一歩は、現状把握と分割候補の洗い出しです。システムが担う業務を業務プロセスの単位で書き出し、直近1〜2年でどの機能に改修が集中したかを整理し、困りごとを数字で示す。この3つを社内で用意できれば、外部エンジニアに調査を依頼する準備は整います。まずは調査フェーズだけを短期の準委任契約で切り出し、そこから全体計画を組み立てる進め方が、リスクを抑えた着手方法になります。

関連情報

外部エンジニアの活用範囲や契約形態の検討にあたっては、発注判断の材料を整理したお役立ち資料もご用意しています。社内で決めるべきことと外部に任せる領域の整理にご活用ください。

既存システムの分割設計や移行体制についてご相談がある場合は、お問い合わせフォームからご連絡ください。要件が固まる前の段階からご相談いただけます。