※本記事で紹介する内容は、2026年2月20日に実施したイベント時点でのものです。
理想的な解決策「マイクロサービス」化ではなく、「モジュラーモノリス」を目指した理由
カード発行枚数3341万枚（2025年12月末時点）を誇る楽天カード会員専用オンラインサービス「楽天e-NAVI」。そのシステム内部を見渡したとき、深見氏の目の前には大きく4つの壁が立ちはだかっていた。
第1に、無数に増築された機能を誰も全容把握できないという「増大するプロダクト」。第2に、長年のシステムの仕様や歴史的な経緯が、開発に長く携わる一部のベテランエンジニアの頭の中にのみ存在する「属人化した知識」。第3に、長年の開発の積み重ねによって1つのクラスファイルが2000行を超えるような状態が散見される「カオスなコードベース」。そして第4に、これらの問題を解決しようにも、システムを安全に改修するためのテストコードが圧倒的に不足しているという「リファクタリング耐性の低さ」があった。
これらの課題が限界に達しつつある中、楽天カードの組織内ではある機運が高まっていた。特定の領域、例えばキャッシングの機能を修正しただけで、全く関係のない明細確認機能にバグを発生させてしまうような密結合状態を解消するため、システムを独立した複数の小さなサービスに分割する「マイクロサービス」化を推進すべきだという声だ。
機能ごとに独立したデプロイが可能になり、業務知識もサービス単位で切り離せるマイクロサービスは、一見すると理想的な解決策に思えた。「サービスごとに分離していて、独立したデプロイもできる。加えて、独立・分離していくことで、その業務知識も独立した単位で分けていける」と、深見氏自身も当初はその方向性に強く賛同していたという。
しかし、冷静に現状を分析するにつれ、重大な懸念が頭をもたげてきた。分離したいサービス間の依存関係がそもそもはっきりと可視化されていない状態で、システムを綺麗に切り離すことなど不可能ではないかという疑念だ。
さらに、テストケースすら十分な量が揃っていない状況で、複雑に絡み合ったシステムをいきなりネットワーク越しに通信する別々のサービスへと分割することは、事業を停止させかねない巨大なリスクを伴う。結果として得られるのは、複雑な通信経路と依存関係の辛さだけが倍増する「分散モノリス」という最悪のアンチパターンに陥る危険性であった。
そこで深見氏が打開策として見出したのが、「モジュラーモノリス」というアーキテクチャの考え方だ。これは、システム全体を単一のアプリケーション（モノリス）として稼働させた状態を維持しながら、内部のソースコードやモジュール構成のレベルで業務領域ごとに厳格な境界を設け、疎結合な状態へと整理・整頓していくアプローチである。
大きく育ったプロダクトを1つの塊と見立て、その内部を徹底的に整頓することで業務の境界を明確にする。その結果、それぞれの機能が疎結合であることが証明できれば、その時点で初めて安全にマイクロサービスへと移行することができる。もし疎結合でなければ、モノリスのまま保守性を高めた状態で運用を続ければよい。
この仮説は、現在のカオスな状態から安全に未来の理想形へと向かうための、極めて現実的で強力な戦略となった。
