シェア
はてブ
2023年9月、ファインディ株式会社は「フロントエンドの開発生産性」と題したオンラインカンファレンスを開催。第一線で活躍しているエンジニアを招いて、フロントエンド領域における開発生産性を向上するための組織づくりや戦略について語っていただきました。
本稿では、合同会社DMM.comのフロントエンドグループにてマネージャーを務めている小西一平さんのセッション「組織状況の変化の中で運用するフロントエンドエコシステム」の内容をご紹介します。
同社は、フロントエンドの開発生産性とUI/UXの一貫性の向上を目的として、2021年にフロントエンドグループを立ち上げました。エコシステムを整備することで当初の目的は達成しつつあったものの、しばらくしてから別の課題が発生してしまったのだそう。新たな課題とはどんなものだったのか、その対処法とは？
■プロフィール
小西 一平（こにし いっぺい）
合同会社DMM.com プラットフォーム事業本部 第3開発部
フロントエンドグループ／マネージャー
2019年に合同会社DMM.comにフロントエンドエンジニアとして入社。プラットフォーム事業本部の会員機能、決済機能等の開発を経て、プラットフォーム全体のフロントエンドの開発生産性とUI・UXの一貫性向上のためフロントエンドグループを立ち上げ、モノレポとデザインシステムを中心としたエコシステムを運用している。
2年前に誕生したPFの新組織・フロントエンドグループ
小西：はじめに、DMMやプラットフォーム事業本部（以下：PF）、フロントエンドグループがどのようなものなのか、簡単にご紹介します。
DMMは設立25年目で、グループ会社は25社、グループ全体の従業員数は4,628名（2023年2月時点）のメガベンチャーです。「なんでもやってるDMM」というキャッチフレーズの通り、スポーツや農業、AIなど、さまざまな領域で計60以上の事業を展開しています。
私が所属しているPFは、DMMアカウントや決済など、各事業に共通の機能を提供している事業部です。機能ごとにチームがわかれていて、フロントエンドアプリケーションの数は40ほどあります。PFで開発するアプリケーションには、APIを使って連携するもの、Webアプリケーションとして連携するものの2パターンあるのも特徴ですね。ちなみに、2022年からスタートした新サービス「DMM TV」では、後者のパターンを採用しています。
サービスのアプリケーションとPFのWebアプリケーションを行き来するような形でPFの機能が使われている
続いて、私が所属するフロントエンドグループについてご紹介します。フロントエンドグループを一言で説明すると「PFのフロントエンド全体をより良くするための横断的な活動を行っている組織」です。
そもそも、なぜフロントエンドグループを立ち上げたのかというと、理由は二つあります。一つ目は、PF全体で技術スタックを統一することになったからです。当時のPFは機能ごとにさまざまな技術スタックが使われていました。ただ、それでは開発生産性の観点で課題があったため、レガシーなアプリケーションのリプレースプロジェクトが立ち上がったあたりで、バックエンドをGo言語に揃えることになったのです。フロントエンドもそれに追随する形で技術スタックを統一することになりました。
二つ目は、フロントエンドエンジニアの人材不足です。チーム専任のエンジニアを用意するのが難しいケースもあり、バックエンドエンジニアがフロントエンドも担当する、といった状況が珍しくありませんでした。そういった課題を解決するため、フロントエンドグループを立ち上げたのです。
グループ誕生から2年でスタンダード化に成功
小西：ここからは、フロントエンドグループの活動を具体的に解説していきます。フロントエンドグループでは、CI/CDやモノレポで使う技術スタックを徹底し、各アプリケーションに共通で必要となる機能をライブラリとして提供しています。
例えば、Next.jsを使った新規アプリケーションの開発を開始する際、DMMアカウントの情報取得やログ出力などボイラープレート的に必要となる部分は、わたしたちが提供しているライブラリが利用可能です。また、デザインシステムではFigmaとReactで一貫したコンポーネントを提供しており、デザイン時はFigmaの、実装時はReactのコンポーネントをそれぞれ選んで利用する形でUIを構築していくことができます。CIによる自動テスト、Storybook、VRT 、自動デプロイも最初から利用できるため、開発しやすい環境が構築できていると思います。
立ち上げから2年が経過し、現在はエコシステムを使ったフロントエンド開発がスタンダード化しました。特別な事情がなければ、モノレポ基盤上でNext.jsにて開発しています。リプレースが進行中のものもありますが、現時点でモノレポ基盤上には10個のアプリケーションが存在していて、主要アプリケーションの多くはエコシステムに乗ってきたかなという段階ですね。
また、最初は1チームのみの利用で運用していたのですが、現在は6チームにまで増えました。デザインシステムだけ、静的アセット配信の基盤だけ、といった部分的な利用も含めると、より多くのチームや他部署の方に利用されています。
意思決定とサポートのコスト増加…新たな課題発生の原因とは
小西：エコシステムを整備することで、開発生産性を向上するとともにUI/UXの一貫性を保つことはできているのですが、変化に伴って新たな課題もいくつか発生しました。大きな課題は「意思決定コストの増加」「サポートコストの増加」です。
「意思決定コストの増加」は、認知負荷の増加が原因だと考えています。プロダクトが成長するにつれ、開発に必要なコンテキストも増加してしまったのです。また、ボトルネックの移動も原因の一つですね。エコシステムによって新規開発時の開発コストは下げられました。しかし、フェーズの異なるアプリケーションが混在することでユースケースごとに異なるボトルネックが発生してしまい、優先順位をつけるのが難しくなってしまったのです。
「サポートコストの増加」については、利用者数が増加したことで利用方法が多様化し、サポートすべきユースケースが増えたことが原因です。利用者数が増加すると利用者一人ひとりとの距離が生まれるため、密なコミュニケーションの機会は減ってしまいます。それにより、私たちの方でトラブルを検知するのが難しくなってしまい、想定外の利用方法でエラーが発生してしまうことがありました。
課題解決の鍵は「チーム分割」と「モノレポ基盤のCD改善」
小西：新たに発生した課題を解決するために、私たちはさまざまな対応を行っています。本日はその中の一例として「チーム分割」と「モノレポ基盤のCD改善」についてご紹介させてください。なお、前者は意思決定コストを下げるため、後者はサポートコストの増加に対する解決策です。
「チーム分割」はその名の通り、フロントエンドグループの中で責務を整理してチームを分割すること。私たちの場合は、モノレポ基盤やデザインシステムといった基盤部分を担当するエコシステムチームと、アプリケーション開発で使用する技術スタックなどの各アプリケーション開発に関わる部分を決定するアプリケーションチームの二つに分けました。関心領域ごとに細かくチームを分けたかったのですが、エンジニアが不足しているため、現状ではそこまで踏み込めていません。
また、チーム分割は認知負荷の削減には効果的なのですが、責務が曖昧な領域が発生してしまう点については注意が必要です。フロントエンドグループとして方針がブレないようにするために、こまめな情報共有も必要です。これらの点については明確な対応策が見つかっておらず、現段階ではチーム間でコミュニケーションをとりながら、手探りで進めている状況ですね。
次に「モノレポ基盤のCD改善」についてご紹介します。モノレポ基盤のデプロイ周りはフロントエンドグループが完全に管理していて、かつ新規開発での利用が前提でした。そのため、AWSのDCSにDockerのイメージをデプロイすることしかできないCDの処理になっていました。
ただ、次第に独自インフラ向けのデプロイをしたい、デプロイ時に固有の処理を行いたいといった要望が出てくるようになりまして。そこで、フロントエンドグループとして担保したい部分は担保しつつ、より柔軟に使える仕組みに変える意思決定をしたというわけです。
具体的には、責務の整理とインターフェースとしてのGitHub Actionsを作成しました。まず責務については、モノレポ基盤上でのデプロイ全般をフロントエンドグループが管理する体制から、ビルドトリガーの提供とビルドおよびキャッシュの管理というスタイルに変更しました。GitHub Actions上でのインターフェースを作成した件については、ビルド用のComposite Actionの提供と、各種処理の入口となるファイルを提供するという形ですね。
改善前
改善後
上記の改善によって、利用者はフロントエンドグループが提供している仕組みを利用し、任意のデプロイ処理やデプロイ時の処理を記述できるようになりました。デプロイ周りの要望に対しては、ドキュメントを共有するだけで対応可能です。フロントエンドグループとしては、Composite Actionの中でビルドやキャッシュの最適化ができるようになりましたし、コストを下げることにも繋がりました。
より良いUXを目指し、取り組みは続いていく
小西：現在はエコシステムを前提に今後のことを考えられるようになった段階であり、今後はカスタマージャーニー全体の最適化に取り組んでいきたいなと。例えば「DMM TV」のように、サービスのアプリケーションとPFのWebアプリケーションを行き来するのは、UX的には最適な方法ではないでしょう。各サービスの中でより低コストで利用できるPFの機能を提供していきたいですし、複数アプリ間での静的リソースの最適化にも挑戦したいなと考えています。
