SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

メルカリの「Platform Engineering」7年間の取り組み~プラットフォームをどのように立ち上げ発展させたのか【PEK2024】

「Platform Engineering Kaigi 2024」メルカリ 中島大一(deeeet)氏 講演レポート

  • X ポスト
  • このエントリーをはてなブックマークに追加

プラットフォームチームの成長と全社プラットフォームへの拡大に向けた取り組み

 こうしてメルカリのプラットフォームが立ち上がると、次にプラットフォームチームは拡大フェーズに向けた取り組みに着手した。具体的には、プラットフォームチームの組織改革と、「シングルプラットフォーム」への移行だ。

 拡大フェーズにおける最初の取り組みは、プラットフォームチームの組織改革だった。この時期の、あるメンバーの作業を例に取ると、CI/CDの改善を行った後には、ネットワーク関連の作業に取り組むなど、時期によって全く異なる作業をする必要があったという。このようにチームが扱う領域が広がりすぎると、認知負荷が高くなってしまう。

 「メンバーそれぞれが専門性を持ち、各プロジェクトごとに異なる課題を抱えていた。一つのチームだけで優先順位をつけて、それぞれの課題に取り組むのは限界があった」と、deeeet氏は言う。

 またメンバー数を15名に迫る勢いで、将来的にもさらなる採用を計画していた。そこで、メンバー数の増加と、認知負荷の上昇に対処するため、それまで1チームだったプラットフォームチームを、複数のサブチームに分割した。チームの分割は、以下の3つの戦略に沿って進められた。

(1)開発サイクルの各フェーズに沿ってチームを配置

 各開発フェーズでは、それぞれ全く異なるドメイン知識が要求される。そこで、フェーズごとにチームを配置することで、専門性に特化した改善ができるようにした。例えば、テストやデプロイフェーズにはCI/CDチームを、オペレーションにおける可観測性の改善のためにオブザーバビリティチームを配置した。

(2)「プラットフォームチームのためのプラットフォームチーム」を設置

 各サブチームで必要なインフラを準備するよりも、共通の仕組みで提供できた方が効率的だ。そのため、Kubernetesなどを管理するプラットフォームインフラチームや、ネットワークを管理するネットワークチームといった、その他のサブチームを支えるチームを設置した。

CI/CDやオブザーバビリティといった開発フェーズごとの専門チームや、プラットフォームインフラやネットワークなどの「プラットフォームチームのためのプラットフォームチーム」など、複数のサブチームに分割
CI/CDやオブザーバビリティといった開発フェーズごとの専門チームや、プラットフォームインフラやネットワークなどの「プラットフォームチームのためのプラットフォームチーム」など、複数のサブチームに分割

(3)外部からのインターフェースとなるDXチームを設置

 プラットフォーム内部のサブチームが、独自にツールやドキュメントを提供すると、インターフェースがバラバラになり、それを利用する開発チームの認知負荷が上昇してしまう。そこで設置したのが、DX(デベロッパー・エクスペリエンス)チームだ。このチームは、各サブチームのAPIやツール、ドキュメントなどに一貫性を持たせ、開発チーム側から一つのプラットフォームとして利用できるようにする。いわば抽象化レイヤーを提供する役割を担う。

各サブチームが提供するAPIやツール、ドキュメントに一貫性を持たせ、認知負荷を下げるDXチーム
各サブチームが提供するAPIやツール、ドキュメントに一貫性を持たせ、認知負荷を下げるDXチーム

 このような組織変更の結果、各サブチームが専門性を発揮できるようになり、抜本的な改善が可能になったという。その中には、セキュアなCI/CD基盤への刷新といった、大きなプロジェクトも含まれる。

 拡大フェーズにおける次の取り組みは、シングルプラットフォームへの移行だ。言い換えれば、冒頭にdeeeet氏が述べた「メルカリグループのすべての開発者と事業が利用するプラットフォーム」になるということだ。

 シングルプラットフォームを実現するために、まず行ったのは、古いインフラで動くレガシーシステムの移行だ。通常、プラットフォームの立ち上げは、新規開発を想定することが多い。しかしdeeeet氏によれば、ある段階からは古いシステムも視野に入れていくことが重要だという。古いシステムが残っているのは、その会社にとって価値が高いシステムだからだ。それらを新しいプラットフォームに移行することで、プラットフォーム自体の価値も向上するのだ。とはいえ、古いモノリスの移行は非常にコストがかかる作業だ。すべてをマイクロサービス化するのではなく、モノリスのままで移行したシステムもたくさんあるという。「古いインフラが必要なくなったので、全体の運用コストを削減し、古いインフラを管理していたメンバーを新しい領域にアサインできた。またプラットフォームを移行したことで、新しいサービスと同じ開発プロセスで開発できるようになった」と、deeeet氏はレガシーシステム移行のメリットについて語る。

 もう一つは、プラットフォームへの新規事業の取り込みだ。多くの人は、すでにプラットフォームがあるのだから、新規事業でもそれを活用するのが当然だと考えるかもしれない。しかし実際には、「新しいテクノロジーを利用したい」「既存事業から隔離したい」といった理由で、新規事業でインフラの検討から始めてしまう場合が多いという。しかしプラットフォームに必要な要件は似通っているにも関わらず、事業ごとに新たにインフラを選定していたら、大きな無駄が生じてしまう。

 「プラットフォームで何ができるか理解されていないのは、プラットフォームチームの説明が不足しているからでもある。だから依頼を待つのではなく、新規事業の話を聞いたらすぐに参加して、意識的に議論に加わることが必要だった」と、deeeet氏は言う。

 シングルプラットフォームへの取り組みを通じて、メルカリでは、新規事業立ち上げのためのゴールデンパス(規定手順)や、利用可能な技術スタックなどの標準化が進んだ。その結果、毎回同じ議論を繰り返すことを防ぎつつ、新規事業立ち上げと新規技術投資の切り分けも進みつつあるという。

グローバルな事業を支えるプラットフォームを目指して

 最後にdeeeet氏は、メルカリのプラットフォームの今後について、展望を語った。プラットフォームの進化には、2つの方向がある。1つは、新規事業など新しいワークロードを取り込む水平方向の進化だ。もう1つは、セキュリティの向上など、既存機能や使いやすさを改善する垂直方向の進化だ。

 現在は、日本のメルカリの商品を海外から購入する越境ビジネスが伸びているという。これに対応するために、水平方向の進化では、国外のリージョンでもプラットフォームを展開できるようにすることが目標だ。またリージョンが増えればプラットフォームの複雑さが増すので、垂直方向の進化では、開発者にとっての複雑さをどう隠蔽するかが課題となる。

 「今後メルカリのプラットフォームは、国外を含めたビジネスを支えるグローバルなシングルプラットフォームへと進化することを目指す」と述べ、deeeet氏は講演を終えた。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

Innerstudio 鍋島 理人(ナベシマ マサト)

 ITライター・イベントプロデューサー・ITコミュニティ運営支援。 Developers Summit (翔泳社)元スタッフ。現在はフリーランスで、複数のITコミュニティの運営支援やDevRel活動の支援、企業ITコンテンツの制作に携わっている。 Twitter:@nabemasat Facebook Web

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/19938 2024/12/26 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング