🦠
アーキテクチャ選定の事例と学び ～モノリス、マイクロサービス、モジュラーモノリスの共生と最適化～ レポート
公開
2025-04-14
更新
2025-04-14
文章量
約4275字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
目次
はじめに
1. タイミー「反省 モジュラモノリス 〜タイミーの試行錯誤と現在地〜」（須貝俊さん）
サービス概要とシステム構成
なぜモジュラーモノリスを選んだか
モジュラーモノリス化の現状
いま振り返ると「やるべきではなかった」？
2. ZOZO「一歩ずつ成長しながら進めるZOZOの基幹システムリプレイス」（岡本拓実さん、作田航平さん）
ZOZO基幹システムとリプレイスの全体像
実施した二つのアプローチ
今後と運用の工夫
3. Q&Aで語られたポイント
Q. モジュラーモノリスを導入して実際に良かった副産物は？
Q. アーキテクチャ変更と組織変更の順序はどうあるべき？
Q. リプレースで「いつでも戻せる設計」をどう実現したか？
4. 全体を踏まえた感想
はじめに
2025年3月12日、「アーキテクチャ選定の事例と学び ～モノリス、マイクロサービス、モジュラーモノリスの共生と最適化～」というイベントがオンラインで開催されました。 モノリスからマイクロサービスへ移行すべきか、あるいはモジュラーモノリスを選択するべきか―。サービスの規模拡大や複雑化を背景に、アーキテクチャの“最適解”を模索する場面に直面している企業やチームも多いと思います。 本イベントでは、株式会社タイミーと株式会社ZOZOが、それぞれの開発現場における実例を通じて「アーキテクチャ選定の現実」と「失敗や成功の学び」を共有しました。本レポートでは、両社のセッション概要とQ&Aでのやりとりをまとめ、お二人（お三方）が語ったポイントを整理します。
1. タイミー「反省 モジュラモノリス 〜タイミーの試行錯誤と現在地〜」（須貝俊さん）
サービス概要とシステム構成
タイミーは「働きたい時間と、働いてほしい時間をマッチングする」隙間バイトサービスです。ワーカーにとっては履歴書不要・面接不要・即日給料を受け取れるメリットがあり、企業にとっては急な人員確保を可能にし、人事コストを抑えるメリットがあります。
タイミーのバックエンドは、単一のRailsアプリケーション（モノリス）をベースに運用してきましたが、事業の成長に伴い一部機能をサブシステムとして切り出すなど、やや複合的なアーキテクチャを構成しています。巨大なモノリスをどう扱うかがテーマとなり、モジュラーモノリス化を一時期大きく推進しました。
なぜモジュラーモノリスを選んだか
須貝さんは、以下の課題を解決するために「モジュラーモノリス化」に取り組んできたと語りました。
複雑な依存関係 変更の影響範囲が把握しづらく、開発速度の低下を懸念。
認知負荷の増大 業務ドメインが多岐にわたるため、1チームが全ドメインを理解するのは非現実的。
責任範囲の曖昧さ アラート対応などにおいて、どのチームがオーナーシップを持つか分かりにくい。
2022年頃、モジュラーモノリスを支えるツールとして「Packwerk」（Shopify製）がRails界隈で注目され、タイミーでもそれを導入してアプリケーションをパッケージに分割し始めました。
モジュラーモノリス化の現状
1年以上の運用を経た結果、パッケージ数は48個ほどに増加。全コードの2/3ほどが何らかのパッケージに組み込まれる状態になっています。 ただし、Packwerkを導入したからといって依存関係が自動的にシンプルになるわけではなく、「依存関係自体の複雑さ」は別途設計・リファクタリングを続けないと解消されない点が痛感されたとのこと。また、パッケージのオーナーが明確化しやすくなる一方で、「モジュール同士の境界が曖昧な箇所」に関する課題は引き続き手動で解決が必要になりました。
いま振り返ると「やるべきではなかった」？
須貝さんいわく、「振り返ればモジュラーモノリスを全体に適用する必要はなかったのでは」と思う部分があると正直に語っています。例えば一部のドメイン（銀行振り込み機能など）をサブシステムに分離したように、「事業のコア課題を解決するための分割」のほうが優先度が高く、汎用的なモジュール分割は後回しでもよかったかもしれないと感じているとのことです。 「そもそもPackwerkはRailsの“レール”を外れることになる。コードオーナー設定などのメリットはあるが、ツール導入が目的化してしまわないよう慎重に考えるべきだろう」と語りました。
2. ZOZO「一歩ずつ成長しながら進めるZOZOの基幹システムリプレイス」（岡本拓実さん、作田航平さん）
ZOZO基幹システムとリプレイスの全体像
ZOZOでは、社員や出店者が利用するバックオフィス業務向けシステムを「基幹システム」と呼んでいます。ECサイト運用だけでなく、物流倉庫の管理機能などフルスクラッチで構築してきました。2004年から約20年にわたり大規模なアーキテクチャ変更はなされず、技術スタックはVBScript、単一データベースのモノリスという形で運用されてきたとのことです。
しかし、サポート終了期限やレガシー化による開発生産性の低下、単一DBの障害リスクなど課題が顕在化し、「基幹システムリプレイスプロジェクト」が立ち上がりました。
実施した二つのアプローチ
モジュラーモノリス化への移行 VBScriptのレガシー環境から、新たな基盤へ機能を段階的に移管。データベースは共有のままにし、トランザクションをそのまま活かした形で、コードを段階的に移すのが特徴です。いわゆる「不健康なモジュラーモノリス」を一度経由し、徐々に改良して理想のモジュラーモノリスへ近づける方針を採っています。
一部機能をマイクロサービスへ切り出し 「障害分離を強く求める」箇所（たとえば発送業務）については、物理DB分割も行って、マイクロサービスに切り出しました。ここでは「トランザクションがこの範囲で完結しているか」が鍵であり、切り出しやすい機能は発送関連に限られたとのことです。 物流周辺機能においてはマイクロサービス化が有効だった一方で、他の機能は無理にマイクロサービスへせずモジュラーモノリスで十分と考え、実際に並行運用しているそうです。
今後と運用の工夫
ZOZOでは現場の業務ドメインが複雑に絡み合うため、厳密なドメインモデルを一足飛びに導入するのではなく、まず「移行しやすさ」と「既存利用者への混乱を最小限に抑える」観点を優先しているといいます。 開発組織も、ドメイン単位でチームを編成して進めることで、分割範囲を自然に決めやすくし、ユーザーへの影響を段階的にコントロール。運用中は「新実装と旧実装を並列稼働し、発行SQLを比較」することで安全性を高めるなど、実際のビジネスに即したリアルなアプローチが印象的でした。
3. Q&Aで語られたポイント
ここでは参加者からの質問に対する発表者の主な回答をまとめます。
Q. モジュラーモノリスを導入して実際に良かった副産物は？
菅井さん（タイミー） コードオーナーを設定しやすくなった。パッケージ単位で誰が責任を持つか明確化できたのは想定外の大きなメリット。
岡本さん / 作田さん（ZOZO） オンプレからクラウド移行の流れも伴って監視体制が整い、素早いアラート検知が可能になった。加えて、新技術の活用を通じて視野が広がり、チーム内の学習意欲やモチベーションが高まった。
Q. アーキテクチャ変更と組織変更の順序はどうあるべき？
菅井さん いわゆる「コンウエイの法則」は存在するが、逆コンウエイ戦略を鵜呑みにするのは危険。アーキテクチャの寿命は長いので、組織の変更を待つのか、アーキテクチャを先に変えるのか、ケースバイケースで考える必要がある。
岡本さん ドメイン単位にチームを編成する方向はよいが、ドメイン自体が既存業務からどう変化するか見極める必要がある。組織とアーキテクチャを完全に一致させるのは理想論だが、現実は難しく、まずドメイン視点を取り入れる意義が大きい。
Q. リプレースで「いつでも戻せる設計」をどう実現したか？
菅井さん（タイミー） Packwerkでモジュラーモノリス化する場合、ファイル移動と設定程度が中心なので、大きな副作用が少ない。戻すのも比較的容易。
岡本さん / 作田さん（ZOZO） 新旧実装を並行運用し、SQLレベルで比較したり、現場に「今日は新環境を使う／明日は旧環境に戻す」など段階的に導入する。切り戻し可能な状態を保つことが前提となっている。
4. 全体を踏まえた感想
今回のイベントでは、それぞれの企業がモノリス、モジュラーモノリス、マイクロサービスを組み合わせながらシステムを成長させている姿が具体的に語られました。印象的なのは、どちらも「理想のアーキテクチャ」に一直線で向かうのではなく、あえて“中途半端”な状態を経由することを受け入れている点です。
菅井さん（タイミー）の「なんとなく分割を進めても、事業ドメインで本当に必要な分割でなければ効果が薄い。むしろ課題を明確にしてから取り組むべきだった」という言葉は、多くの現場に通じる示唆があるでしょう。一方でZOZOの事例は、物流機能をマイクロサービスとして切り出しつつ、ほかの大部分はモジュラーモノリスで段階的に移行する方針。「全機能を一挙に分散させず、必要なところだけ最初にやる」という穏健なアプローチが、安定したサービス運用とのバランスを保っています。
これらの事例を見ても、アーキテクチャ選定は「うまくいっていない理由を冷静に見極め、トレードオフとコストを勘案しながら最適な変化を選ぶ」ことが本質であると言えます。理想形を夢見るより、まず一歩ずつ「いま何が事業的に重要か」「どの技術がそれを支えられるか」を問い続ける。そうした姿勢こそが、現場のリアルな勝ち筋なのではないでしょうか。
アーキテクチャ設計には、華やかな言葉や概念が溢れがちです。しかし両社の話から浮かぶキーワードは「段階的な実行」「あえて不健康な状態を経由する」「戻れる安全策を組む」といった地道な取り組みでした。モノリスであれモジュラーモノリスであれ、あるいは部分的なマイクロサービスであれ、大きな一歩を踏み出すには現実と折り合いをつけながら進むしかないのです。
このイベントを通じて、アーキテクチャ選定における正解は一つではないことが、改めて浮き彫りになりました。大切なのは、事業やチームが置かれたフェーズを認識し、戦略的に変化のコストを捉えること。そのうえで、少しずつ「もっとも価値ある部分」を優先して変えていく姿勢を持ち続ければ、将来的なリファクタや抜本的改善に繋げられる。アーキテクチャはあくまで“手段”であり、本当に解決すべきは「システムが事業成長を妨げないようにする」ことなのだと実感させられる内容でした。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
