モノリシックアプリからマイクロサービスへ移行した際の課題と学びの開発ノート

プロジェクト背景：レガシーモノリスの限界を打破する決断

創業10年を迎えたEコマース企業では、長年成長を支えてきたモノリシックなバックエンドが、機能追加やトラフィック増加に耐えられずパフォーマンス劣化やリリースのたびにブレーキがかかる状況に直面していました。特定モジュールの不具合が全体に影響を及ぼし、デプロイが数時間単位でダウンタイムを必要とするなど、ビジネスへの機会損失も無視できないレベルです。そこでCTOは、信頼性や開発スピードを回復するため、「マイクロサービス化」を決断しました。移行にあたっては、既存の業務システムと並行運用しながら徐々に置き換える「ストラングラ・パターン」を採用することとし、フェーズごとの予算と発注スケジュールを策定しました。この段階で、システム全体のアーキテクチャ図を描き、ドメイン駆動設計（DDD）の考え方でバウンデッドコンテキストを切り出す作業に着手。開発会社への要件説明では、予算感と費用相場を示しつつ、大規模リプレースのリスクを分散するフェーズ分割を明確にしました。

移行戦略策定と開発会社選びのポイント

マイクロサービス移行プロジェクトでは、要件定義からフェーズ設計、ベンダー選定まで全社横断の合意形成が必須です。まず社内外のステークホルダーを巻き込み、移行目的（可用性向上・スケール性確保・開発効率改善）を整理。そのうえで、以下の観点で開発会社を比較検討しました。

• 実績：Java／Spring Boot、Node.js、Goなど複数言語のマイクロサービス開発経験

• 設計力：DDDやEvent-Driven Architectureの理解、可観測性（Observability）設計経験

• インフラ対応：Kubernetes／Docker、CI/CDパイプライン構築スキル

• 予算管理：人月単価と工数明細の透明性、フェーズごとの費用相場提示

• コミュニケーション：定例報告、専用チャットワーク、ドキュメント管理（Confluence）体制

RFPには「フェーズ1で注文サービスの分離」「フェーズ2で在庫・支払いサービスの分離」というロードマップと、各フェーズの発注ボリュームと予算枠を盛り込みました。最終的に、小規模PoCをスピーディに回せるB社を採択。B社はステージング環境を半年間無償提供し、予算超過リスクを軽減する提案が評価ポイントとなりました。

ドメイン分割とAPI設計の教訓

移行初期の課題は「どこでドメインを切り出すか」。DDDの書籍をベースにモデリング会議を実施したものの、業務チームごとに解釈が異なり、API仕様の齟齬が頻発。最初の週次ワークショップでは、同じ言葉でも意味合いが違う「注文」「支払い」「配送」の境界が曖昧でした。その結果、フェーズ1の注文サービスのAPI定義が完了した段階で早速仕様変更が発生し、追加費用が膨らむ事態に。
これを防ぐため、以下の対策を実施しました。

1. ユビキタス言語の定義：全チーム参加の用語集を作成し、Confluence上でバージョン管理

2. Swagger/OpenAPI 管理：API仕様書をGit管理し、PRで変更履歴を必ずレビュー

3. モックサーバーの活用：フェーズ1要件完了時にMockServerでプロトタイプを全チームに配布し、早期フィードバックを回収

4. 契約書連動：RFPに「仕様変更は事前合意後に別途見積」と条項化し、開発会社との発注契約でコスト管理を徹底

これにより、フェーズ2以降のAPI分割での手戻りが大幅に減少し、システム開発の見積相場と実費が乖離しにくくなりました。

CI/CDと環境構築の工夫

マイクロサービス化で開発スピードを落とさないためには、CI/CDパイプラインと開発環境の自動化が必須です。B社は以下のような仕組みを提案・実装しました。

• GitOps導入：Argo CDとGitHubを連携し、GitのPull Request承認だけでステージング／本番が自動デプロイ

• インフラコード化：Terraform＋HelmでKubernetesクラスターとマニフェストをコード管理し、環境差異を排除

• マルチステージパイプライン：PRビルド→ステージングデプロイ→ステージングE2Eテスト→本番マージ→本番デプロイというフローをGitLab CIで実現

• テスト自動化：ユニットテストに加え、契約テスト（Contracts）や培養環境での負荷テストをパイプラインに組み込み

これらにより、従来はスプリント末に2日かかっていた統合テストとリリース作業が1時間以内で完了し、オーバーヘッドを大幅に削減。予算や費用を抑えながら、品質を担保して継続的デリバリーを実現しました。開発会社選びでは、GitOpsやKubernetes実績、Terraform経験を評価軸に加えると失敗リスクがさらに低減します。

モニタリングとオブザーバビリティの強化

マイクロサービス化後は、従来の単一ログ監視だけではサービス全体の可観測性が不十分になるため、E2Eトレーシングやメトリクス収集を強化しました。まず、OpenTelemetryを導入し、各サービスから分散トレースを収集。JaegerとPrometheus＋Grafanaを組み合わせ、リクエストフローの可視化とレイテンシ分析を行います。具体的には、注文サービスから在庫サービス、支払いサービスへの呼び出しチェーンをトレースし、どのコンポーネントで遅延が発生しているかをダッシュボードで一目で把握できるように設定しました。

次に、Prometheusで事前に定義したSLI（Service Level Indicator）として、エラーレート、レスポンスタイムの95パーセンタイル、CPU／メモリ使用率を収集。これらをKPIとしてGrafanaのダッシュボードにまとめ、チーム全体で常時モニタリングします。アラートルールはしきい値を厳しめに設定し、PagerDutyに連携。深夜や週末でも迅速に対応できるオンコール体制を構築しました。

ログ集約にはELKスタックを採用し、サービス名やリクエストIDでフィルタリングして詳細ログを即座に追跡可能に。これにより、従来は障害発生から原因特定まで数時間を要していたものが、平均15分以内にまで短縮しました。また、ログフォーマットは統一的なJSONにし、構造化ログとしてElasticsearchに格納。これにより、特定エンドポイントやエラータイプごとの集計が容易になり、定期的なレポート生成も自動化できました。

さらに、ビジネスロジックレベルのモニタリングとして、カスタムメトリクスをアプリケーションコード内に埋め込みました。例として「注文作成成功数」「在庫引当失敗数」「支払いトランザクション完了数」などをPrometheusに送信し、業務KPIと技術KPIを紐づけたダッシュボードを実現。これにより、ビジネス責任者もシステム状況をリアルタイムに把握でき、技術チームとのコミュニケーションが円滑になりました。オブザーバビリティ強化によって、問題の早期検知とボトルネック解消が進み、システム全体の稼働率99.95％を達成しています。

インシデント対応とポストモーテム

可観測性を担保しても、インシデントは必ず発生します。ある日、夜間バッチ処理によるDB負荷が原因で在庫サービスがタイムアウトを連発し、連鎖的に注文サービスにも影響が出たことがありました。まずはGrafanaのアラートで異常を検知し、オンコールエンジニアがPagerDuty経由で通知を受領。即座に障害対応ルームを立ち上げ、該当サービスのログとトレースを仮想マシン上でリアルタイムに共有しました。

障害対応のファーストアクションは、自動スケール設定されたステージング環境で同様の負荷試験を再現し、バッチクエリのボトルネックを特定すること。DBインデックスの欠如とキャッシュ設定ミスが原因だったため、その場で一時的なクエリ修正とRedisキャッシュの導入を実施。ステージングでの確認後に本番環境へリリースし、サービス復旧を完了しました。ダウンタイムは約45分に収まり、ビジネス影響を最小化しています。

インシデント収束後は必ずポストモーテムを実施。チーム全員が参加し、KPT（Keep, Problem, Try）のフレームワークで振り返りを行いました。

• Keep：迅速なアラート連携とオンコール体制の有効性

• Problem：バッチ処理の負荷見積り不足とキャッシュ要件の抜け漏れ

• Try：バッチは非ピーク時間帯にシフトし、負荷試験の自動化を強化

ポストモーテムレポートはConfluenceにまとめ、関連JIRAチケットを作成。バッチスケジューラの再設計や負荷テスト強化タスクをスプリントバックログに登録し、次スプリントで必ず対応する体制を整えました。インシデント対応とポストモーテムを通じて、フェーズ2以降のマイクロサービス移行でも同様の問題を未然に防ぐ知見が蓄積されました。

チームコミュニケーションの改善施策

大規模移行プロジェクトでは、複数チームと外部開発会社が並行して作業を行うため、コミュニケーションの設計が成果に直結します。オンラインとオフラインを横断するハイブリッド開発チームの課題は、情報の非対称性とエスカレーションの遅延です。これを解消するために、まず以下の仕組みを整備しました。

1. 情報ハブ：Confluenceを全チーム共通の情報ポータルとし、ドキュメントの更新は必ずチケットIDと関連付けるルールを徹底

2. チャットOps：Slackに#prod-alerts、#staging-alerts、#dev-alertsを用意し、監視アラートとCI/CD結果を自動投稿

3. 定例フォーマット：週次ステータス会は「進捗／課題／次アクション」の3点報告に統一し、時間を30分に短縮

4. ペアレビュー：異なるチームや開発会社のメンバー同士でコードレビューを実施し、ノウハウ共有と品質担保

5. エスカレーション階層：障害や仕様変更リクエストは、チャットOpsで即時に全関係者へ通知し、30分以内に優先度判断

これにより、情報の伝達ロスや属人化が大幅に減少。特に、#prod-alertsチャネルへの監視アラート自動投稿が功を奏し、オンコール以外のチームメンバーも状況把握でき、協力体制が強化されました。コミュニケーションフローを明文化し、発注契約時に「チャットツール利用」「定例会出席要件」を盛り込むことで、開発会社への期待値を明確化しました。

予算管理と費用最適化の実践

移行プロジェクトでは、当初想定を超える工数や追加要件が発生しやすく、予算超過リスクが常に存在します。そこで、フェーズごとの予算管理を徹底しました。各フェーズ開始前にWBSを細分化し、要件定義、設計、実装、テスト、リリース、移行作業の工数を明細化。開発会社からは「人月単価×工数」「外部サービスライセンス料」「インフラ利用料」「予備費」を内訳で提出してもらい、社内承認用の資料を作成しました。

コスト最適化策としては、下記を実践しています。

• フェーズ分割：MVPフェーズに絞った初期投資を全体予算の60％以内に抑制

• サーバーレス活用：バッチや通知機能をAWS Lambdaに置き換え、アイドルコストをゼロ化

• オープンソース優先：商用ライセンスの代わりにOSS監視ツール（Prometheus, Jaeger）を導入

• フリーランス活用：テスト自動化コードやドキュメント整備の一部をフリーランスに委託し、1人月あたりのコストを25％圧縮

• 予約インスタンス：Kubernetesクラスタ用のEC2を1年予約で40％割引活用

これらの取り組みにより、当初の予算1.2億円を1.1億円に圧縮。フェーズ3のAI予測の予算20％相当分を先行内製化に振り向けることができました。予算管理はPower BIで可視化し、残工数とコストをリアルタイムに把握。経営層への報告資料に

外部パートナーとの協働ノウハウ

複数の開発会社やクラウドベンダーを巻き込むマイクロサービス移行では、外部パートナーとの協働が要となります。契約フェーズでは、発注書（PO）とSOW（Statement of Work）を細かく分け、成果物基準、検収条件、支払いスケジュールを厳格化。変更管理プロセスも定義し、仕様変更は必ず書面承認と見積書更新をセットにするルールを徹底しました。

協働推進のポイントは次の3つです。

1. 透明性の徹底：JIRAで全チケットを共有し、ステータスやコメント履歴を全員が閲覧

2. 定量的評価：ベンダーのコミット履歴やレビュー遅延などをKPI化し、月次評価ミーティングでフィードバック

3. ナレッジ移転：社内SE向けに隔週のハンズオン勉強会を開催し、外部技術ノウハウを内製化

また、Slackチャンネルにおける「ありがとうBot」で貢献を可視化し、心理的安全性を担保。パートナーとの関係構築が円滑になり、緊急時にも迅速な協力体制を実現しました。

移行プロジェクトの成功要因と今後の展望

本移行プロジェクトで成功の鍵となった要因を振り返ると、以下が挙げられます。

• 綿密なフェーズ設計と予算分割管理

• DDDによるドメイン分割とユビキタス言語統一

• GitOps＋CI/CDでのリリース自動化

• 可観測性強化による迅速な問題検知

• インシデント対応とポストモーテムでのPDCA徹底

• チーム／パートナー間の情報透明化

これらの取り組みにより、開発スピードは従来比2倍、システム稼働率は99.95％、デプロイ頻度は週1回から週5回に改善。コスト感も当初の想定内に収まり、フェーズ2以降のAI予測機能やスケールアウトに充てる予算を確保できました。

今後は、マイクロサービス間のAPIゲートウェイ統合認証やサーキットブレーカーによるフォールバック設計、サービスメッシュ（Istio）導入によるトラフィック管理を検討中です。また、AI予測モデルのマイクロサービス化やイベントドリブン連携強化で、さらなるビジネス価値創出を目指します。