レガシーシステムリアーキテクチャに着手しようとすると、モノリスをどこまで細かく分割するのか、段階移行かフルスクラッチかどちらを選ぶのか、DDDやAPI-first設計をどこから導入すればよいのかなど、判断すべき論点が一度に押し寄せます。技術トレンドの話題性だけで進め方を決めると、自社の開発体制やトラフィック規模に見合わない分割になり、かえって運用負荷が増すことも珍しくありません。出発点となるのは、自社の技術的負債がどこに、どの程度集中しているかを具体的に把握することです。
本記事では、リアーキテクチャ検討前に整理すべき自社の技術的負債の状況、分解パターン・移行アプローチによる種類分け、比較すべき評価軸、Strangler Fig型・フルスクラッチ型・ハイブリッド型の選び方、PoCやアーキテクチャスパイク、ADR(Architecture Decision Record)の進め方を解説します。これから移行方針を固めようとするアーキテクトや情報システム部門の方が、自社に合った進め方を具体的に絞り込めるように整理しています。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・レガシーシステムリアーキテクチャの完全ガイド
リアーキテクチャ検討前に整理すべき技術的負債の状況
最初に行うべきは、移行手法を選ぶことではなく、自社システムのどこに、どのような密結合が存在するのかを具体的に洗い出すことです。密結合の所在によって、適した分解パターンも移行アプローチも変わってきます。
密結合の所在とビジネスロジックの暗黙知を可視化します
データベースのテーブル設計が複数機能から直接参照されている、特定のバッチ処理が他の複数機能の前提条件になっている、担当者の頭の中にしか残っていない例外処理があるなど、密結合の形はシステムによって異なります。ソースコードの静的解析だけでなく、実際の改修時にどの範囲まで影響調査が必要になっているかを担当エンジニアにヒアリングすると、机上の想定より広い依存関係が見つかることがあります。
洗い出した依存関係は、口頭の申し送りで終わらせず、機能名・依存先・影響度・想定リスクを一覧化した技術的負債の台帳として残しておくと、後述する分解パターンの選定やPoC対象スライスの優先順位づけに直接活用できます。台帳は一度作って終わりにせず、改修のたびに更新していくことで、リアーキテクチャ着手時点の依存関係を正確に反映した状態を保てます。
開発体制の規模とトラフィック量を確認します
マイクロサービス化は、1日あたりのリクエスト数がきわめて多い、あるいは開発者数が数十人規模に達しているような組織で効果を発揮しやすい一方、開発者が15〜20人に満たない組織では、サービス間の運用オーバーヘッドがメリットを上回ってしまう可能性があります。自社の現在の開発体制と、数年先に見込む事業拡大の規模を照らし合わせ、どこまで細かく分割する必要があるかの仮説を立てておくと、後述する種類分けの判断がしやすくなります。
レガシーシステムリアーキテクチャの主な種類
リアーキテクチャは、どこまで分解するか、どのように移行するかという二つの軸で類型化できます。実際のプロジェクトはこれらを組み合わせて進めることが多く、名称よりも自社の制約に合った組み合わせを選ぶことが重要です。
分解の粒度によるモジュラーモノリス型とマイクロサービス型
モジュラーモノリス型は、一つのアプリケーションの中でモジュール境界を明確に保ちながら、将来的なサービス分割の余地を残す進め方です。マイクロサービス型は、境界づけられたコンテキストごとに独立したサービスとしてデプロイ・運用する進め方で、チームごとの独立性やスケーラビリティを重視する組織に向きます。開発者数やトラフィックがまだそれほど多くない段階からマイクロサービス型に踏み切ると、運用の複雑さだけが先行しやすい点には注意が必要です。
移行方法によるStrangler Fig型とフルスクラッチ型
Strangler Fig型は、旧システムを稼働させたまま段階的にサービスを切り出していく移行方法です。フルスクラッチ型は、新しいアーキテクチャをゼロから構築し、ある時点で一斉に切り替える方法を指します。両者の中間として、共通化しやすい業務領域だけを先に切り出し、独自性の高い業務は当面既存システムに残すハイブリッド型も選択肢になります。次章以降では、この移行方法の選び方を具体的な評価軸に沿って解説します。
移行アプローチを比較する評価軸
移行アプローチは、印象や流行で選ぶのではなく、期間・投資回収・事業への影響・運用体制という共通の評価軸で比較すると、自社にとっての優先順位が見えやすくなります。
スケジュールとROI回収のタイミングを比較します
段階移行は、パイロットフェーズ、主要ドメインの再構築、本番移行、最適化という順に数か月単位で価値を積み上げていくため、スプリントごとに小さな投資回収を見込みやすいという特性があります。フルスクラッチ型は、新アーキテクチャが稼働し始めるまでの数年間、大きな投資回収が見込めない期間が続くため、経営層への説明では投資回収の時間軸をどちらの前提で描くかが重要な論点になります。ING BankやBBVAの事例では、段階的なリプレースと並行稼働を組み合わせることで、移行途中でも既存業務を止めずに進めた点が特徴として語られています。
経営層への説明では、フェーズごとの完了時点で何が達成されるかをあらかじめマイルストーンとして定義し、投資額と得られる価値を対応づけて示すと、途中経過での予算承認を得やすくなります。段階移行はスプリント単位の小さな成果を積み上げる分、報告のたびに進捗が見えにくいと受け止められることもあるため、技術的な達成度だけでなく、業務上どの課題が解消されたかをあわせて共有することが有効です。
事業中断リスクと運用学習曲線を比較します
段階移行では、切り替えの範囲を小さく保てるため、事業を中断するリスクを抑えやすく、運用チームも段階的に新しい技術要素へ習熟していけます。フルスクラッチ型は、初日から高度な運用スキルが求められる場面が多く、コンテナオーケストレーション、分散トレーシング、サービスメッシュといった新しい要素を一度に運用へ組み込む負荷が大きくなります。運用チームの現在のスキルレベルと、学習にかけられる時間的余裕も、比較評価に含めるべき項目です。
Strangler Fig型・フルスクラッチ型・ハイブリッド型の選び方
評価軸を踏まえたうえで、自社の制約に応じてどのアプローチを軸に据えるかを判断します。原則としてビッグバン型のフルスクラッチは非推奨とされ、既存システムが物理的・論理的に延命できない場合の最終手段と位置づけられています。
事業を止められない場合はStrangler Fig型を軸にします
取引が24時間止められない業務基幹システムや、顧客影響の大きいシステムでは、旧システムと新サービスの並行稼働を前提とするStrangler Fig型が現実的な選択になります。切り出す順序を業務価値とリスクの両面から決め、最初のスライスで移行手順と境界設計の妥当性を検証してから、以降のスライスへ展開していく進め方が定着しています。
延命が困難な場合に限りフルスクラッチ型を検討します
使用言語やミドルウェアのサポートが終了し、セキュリティパッチの提供も止まっているなど、既存システムの延命自体が困難な場合は、フルスクラッチによるゼロからの再構築を検討せざるを得ない局面もあります。この場合も、いきなり全業務を対象にするのではなく、コアドメインから優先順位をつけて構築範囲を区切ることで、投資額とリスクを一定程度コントロールできます。ハイブリッド型として、共通化しやすい業務をクラウドネイティブな新基盤に寄せ、独自性の高い業務は既存システムとの連携を維持する構成も、現実的な折衷案として選ばれています。
PoC・アーキテクチャスパイク・ADRの進め方
アプローチの方向性が定まったら、実際に手を動かして技術的実現可能性を検証するPoCフェーズに進みます。このフェーズではROIを求めず、境界設計や移行手順が現実的に機能するかどうかの確認に専念します。
イベントストーミングとモックAPIで境界仮説を検証します
境界づけられたコンテキストの仮説は、業務プロセスをイベント単位で可視化するイベントストーミングを通じて検証します。過剰な細分化を避けるため、最初は3〜5程度のコアドメインに絞ってスモールスタートすることが推奨されます。API-first設計についても、OpenAPIやProtocol Buffersでスキーマを定義したうえでPrismやMockoonなどのツールでモックサーバーを立て、実装前に利用側チームが並行して開発を進められるかを確かめます。あわせてPactなどのツールで消費者側と提供側の契約テストをCI/CDパイプラインに組み込んでおくと、後続の統合時に仕様の食い違いを早期に検知できます。
アーキテクチャスパイクとADRで判断根拠を記録します
アーキテクチャスパイクでは、Kubernetesでのコンテナ運用、分散トレーシング、集中ログ管理、CI/CD基盤との連携、複数サービスにまたがる処理を扱うSagaパターンの実現性といった技術要素を実際に検証します。成功の目安は、最初のモジュールがAPIまたはサービスとして分解され、CI/CD経由でデグレなく独立して稼働することです。あわせて、なぜその設計を選んだのかという背景、チーム規模やトラフィック量、DevOps成熟度といった判断根拠をADR(Architecture Decision Record)として記録しておくと、後から設計を見直す際にも当時の前提を振り返ることができます。
ADRに残す項目は、決定のタイトル、検討時点の状況、決定事項、検討した代替案とそれを採用しなかった理由、想定されるトレードオフの5点を最低限そろえておくと、後任者が読んだだけで当時の判断過程を追えるようになります。PoCの段階で作成したADRは、本格移行フェーズに入ってから発生する設計変更の際にも、変更前後の差分を説明する基礎資料として活用できます。
選定・移行で陥りやすい失敗
移行方針そのものが妥当でも、進め方を誤ると計画は行き詰まります。よくある失敗パターンをあらかじめ把握しておくことで、進行中の軌道修正がしやすくなります。
スコープクリープと基盤整備の遅れが計画を遅延させます
最初は小さく始めたはずのスライスに、関連機能の改善要望が次々と追加され、当初の見積もりを超えていくスコープクリープは、段階移行で特に起こりやすい失敗です。また、分散トレーシングや集中ログ管理といったオブザーバビリティ基盤の整備を後回しにしたまま本番移行を進めると、障害発生時に原因の切り分けができず、運用が立ち行かなくなります。基盤整備は最初のスライスに含めておくべき前提条件として扱う必要があります。
暗黙のビジネスロジックと分散型モノリス化に注意します
ドキュメント化されていない例外処理や、担当者の経験則に基づく判断ロジックが分解の途中で見つかると、境界設計をやり直す必要が生じ、計画全体が遅れます。また、境界の切り方を誤ったまま進めると、一つの変更に複数サービスの同時改修が必要になる分散型モノリスに陥り、サービス化のメリットを得られないまま運用コストだけが増えるという結果を招きます。PoC段階で境界の妥当性を十分に検証しておくことが、この失敗を避ける最も有効な手段です。具体的な候補となる製品・プラットフォームは、レガシーシステムリアーキテクチャのパッケージ・クラウド製品一覧で紹介していますので、あわせてご確認ください。
レガシーシステムリアーキテクチャ導入前に確認しておきたいポイント
移行方針とPoCの進め方を固めた後も、実際の着手前に確認しておくと判断がぶれにくくなる点をまとめます。
開発チームが小規模でもリアーキテクチャは可能です
小規模なチームでも、モジュラーモノリスとしての境界整理から始めれば、無理にマイクロサービス化しなくてもDDDの利点を得られます。開発体制の拡大に合わせて段階的にサービスを切り出す前提で設計しておくと、将来の選択肢を狭めずに済みます。
並行稼働期間のコストは事前に見積もっておきます
Strangler Fig型では、旧システムと新サービスを同時に運用する期間が発生するため、その間の二重運用コストを移行計画の中で見込んでおく必要があります。並行稼働の期間が想定より長引く可能性も踏まえ、余裕を持った予算計画を立てることが重要です。
PoCの成功基準は事前に数値で定義します
「うまくいった」という印象論で終わらせず、独立稼働の達成、契約テストの合格、CI/CDでのデグレなし移行といった具体的な合格条件を事前に定義しておくことで、PoC後に本格移行へ進むかどうかの判断を客観的に行えます。
まとめ
レガシーシステムリアーキテクチャの選定では、まず自社の技術的負債と開発体制の規模を可視化し、分解の粒度と移行方法という二つの軸で種類を整理したうえで、スケジュール・事業中断リスク・運用学習曲線という評価軸で候補を比較することが重要です。原則としてビッグバン型のフルスクラッチは避け、事業を止められない制約が強いほどStrangler Fig型を軸に据えることが現実的な選択になります。
PoCで境界設計の妥当性を検証してから本格移行へ進みます
イベントストーミングによる境界仮説の検証、API-first設計に基づくモック開発と契約テスト、アーキテクチャスパイクによる技術要素の実現性確認を経て、最初のモジュールが独立稼働することを確認できて初めて、本格的な移行に踏み出す判断材料がそろいます。ADRとして判断根拠を残しておけば、途中で計画を見直す際にも一貫性を保てます。
自社だけで判断が難しい場合は外部の技術支援も選択肢です
境界設計の妥当性検証やアーキテクチャスパイクの実施には、DDDやクラウドネイティブ基盤の実践経験が求められる場面が多く、社内だけで判断し切れないケースも少なくありません。既存の基幹システムとの連携を維持しながら段階的に移行を進める必要がある場合、標準的なフレームワークだけでは対応しきれない独自要件が出てくることもあります。riplaはフルスクラッチ開発の立場から、境界設計の壁打ちからPoCの技術検証、既存システムと連携する段階的な構築までを一貫して支援しています。
▼全体ガイドの記事
・レガシーシステムリアーキテクチャの完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。