マイクロサービス化の開始を公表
急成長が招いた技術的限界
2010年代後半、メルカリは国内CtoC市場で圧倒的な取引量とユーザー基盤を確立していた。一方で、その成長はサービス開始当初に構築したシステムアーキテクチャに大きな負荷を与えていた。単一のコードベースと密結合した構成は、機能追加や改修のたびに全体への影響を考慮する必要があり、開発速度と安定性の両立が難しくなっていた。
また、取引量の増加に伴い、障害発生時の影響範囲が拡大し、サービス全体を止めかねないリスクが高まっていた。事業としては国内外での拡張や新規サービス展開を視野に入れていたが、既存のアーキテクチャのままでは、将来の成長を支える基盤として限界があるという認識が、社内で共有されつつあった。
基盤刷新を前提とした構造転換
こうした課題を受けて、2018年7月、メルカリはシステムのマイクロサービス化に着手することを公表した。機能単位でサービスを分割し、開発・デプロイ・運用を独立させることで、開発効率と耐障害性を高めることを目的とした判断であった。
この取り組みは、短期的な開発速度の低下や移行コストを伴うことが前提であり、即時の事業成果を狙った施策ではなかった。それでも、将来の事業拡張と組織拡大を見据え、技術的負債を放置せずに構造的な刷新に踏み切るという、長期視点に立った意思決定がなされた。
持続的開発体制への転換
マイクロサービス化の開始により、メルカリはシステムを段階的に分割し、チーム単位での開発と運用を可能にする体制へと移行していった。これにより、特定機能の改修や新機能追加が全体に与える影響を抑えつつ、開発サイクルを回すことが可能となった。
短期的には移行負荷や運用の複雑化といった課題も顕在化したが、結果としてこの判断は、サービスの安定性と拡張性を確保する基盤を整えることにつながった。2018年のマイクロサービス化は、メルカリが一過性の成長企業から、長期運営を前提としたプラットフォーム企業へ移行するための重要な転換点となった。
マイクロサービス化で注目すべきは、システムの分割にとどまらず組織構造まで相似形に切り直そうとした点にある。CTOの若狭氏が述懐するように、サービスの切り方が正解かわからない段階で組織も同時に切り直した結果、ソフトウェアは修正できても組織の再編には数週間〜数ヶ月を要するという非対称性に直面した。元Google出身者が「Googleでは誰もマイクロサービスとは言っていなかった」と振り返る点も示唆的であり、急成長スタートアップが大企業の技術手法を導入する際の難しさを浮き彫りにしている。