はじめに
EXNOA プラットフォーム事業 ブラウザプラットフォーム部の高野です。DMM GAMESのオンラインゲームプラットフォームの開発・保守を担当しています。
本記事では、オンラインゲームプラットフォームのシステムリプレイス状況と、システムリプレイスを進めることにより普段かかわりのある職能とエンジニアとの関わり方について、この約2年半の変化を紹介します。
なぜシステムをリプレイスしているのか
2020年時点でDMM GAMESのプラットフォームは、サービスの成長とビジネス要件の実現を優先するために、アーキテクチャを変えずスピード優先での機能実装を繰り返したことにより、複雑かつ巨大なモノリスアーキテクチャとなっていました。
1-1. 2020年時点のプロジェクトとサービスの関係図
それぞれのサービスが依存しあっているため、1つのプロジェクトで実装を行う際、サービスごとに影響がないかの確認と、影響ある場合はそれを回避するための実装を行う必要があり、デリバリー速度が低下していました（現在も部分的に残っています）。
また、常に複数のプロジェクトが並行して動いているため、影響のあるプロジェクトのメンバー間でのコミュニケーションについても無視できないぐらいコストがかかっていました。
上記の問題から、アーキテクチャの変更を行わずに人を増やしても開発速度が上がらない状況であるため、DMM GAMES はマイクロサービス化することにより、チーム毎の役割（機能・サービス）を明確化しメンテナンス性の向上、デリバリー速度の向上を目指すフェーズに至りました。
1-2. 目指す組織の形
ここからは、時系列で振り返りながら変遷についてご説明していきます。
2020年頃のシステムとエンジニア組織
組織体制図
2-1. 2020年時点の開発組織体制図
こちらは、リモートワーク開始とほぼ同時期の体制になります。
この当時の組織の特徴としては、開発本部の下にそれぞれの職能ごとの部を配置していました。また、その中にそれぞれのグループやチームに分ける、いわゆる職能別組織になっていました。
システム構成とそれぞれのチームの依存関係
2-2. 2020年時点の各職能とプロジェクトの関係図
システムはリプレイス開始前の状態のため、巨大なモノリスアーキテクチャのままでした。また、プロジェクトを担当する際はそれぞれの部署から担当者をアサインし、進行する体制を取っていました。
この時の問題点と、それをどのように改善しようとしていたか
既存システムの知見が部署内のエンジニアで分散しており、属人化されたシステムとなっていました。そのため、エンジニアの人数を増やしても、スケールアウトしづらい状況になっていました。また、前述した通り、既存システムは複雑かつ巨大なモノリスアーキテクチャとなっているため、保守するだけで精一杯の状況でした。
上記2点の問題点に対して、直近で属人化を完全に排除するところまでは進められないため、それぞれのチームの特性等は特にこだわらずに、 プロジェクトを割り当てて知見を貯めていました。
また、別軸ではプラットフォームのニーズに合わなくなってきたサービスのクローズについても検討し、負債の脱却について検討し始めました。
2021年ごろのシステムとエンジニア組織
組織体制図
3-1. 2021年当時の開発組織体制図
前年度と比較すると、部内のグループがそれぞれのチームの役割と直結した分かれ方になりました。ただ、前年度と同じく、いわゆる職能別組織になっていました。
システム構成とそれぞれのチームの依存関係
3-2. 2021年当時のチームとプロジェクトの関係
DMM GAMESプラットフォームのリプレイスチームができてリプレイスを進めることになり、 リプレイスされたサービスを既存の開発チームが受け取ってエンハンス・運用していく方針となりました。
知見の共有も兼ねて、DMM GAMESプラットフォーム担当のグループから数名が、リプレイスチームのプロジェクトに参加するようになりました。
また、一部のサービスについてリプレイスが完了し、他のサービスとの依存関係が解消されるなど、リプレイスチームの成果が徐々に見えてきました。
この時の問題点と、それをどのように改善しようとしていたか
この時期特に問題となっていたものとしては、まず、前年度から一部サービスのリプレイスを進める中で、リプレイス後のサービスの受け入れ体制が整備できていないという点。
それから、既存システム改修との両軸でデリバリー速度を早くしたいという組織目標がある中で、現状のチームの役割が明確ではなく、部署間でのミーティングや調整が多くなり、デリバリー速度に影響している点の２点ありました（1年間通してそれ以外にも多数ありましたが割愛します）。
改善策として、効率化と平準化に注力し、手探りでチーム編成を考えるフェーズと定義し、以下の施策を進めました。
- リプレイスの受け入れ体制の整備
- 大型案件の案件テンプレート整備
- JIRAの積極活用(スプリント、ストーリーポイント、ベロシティ計測)
- プロダクトに関する資料(知見とか仕様とか)
- slackチャンネルの可視化
- etc...
2022年から現在までのシステムとエンジニア組織
組織体制図
4-1. 2022年現在の開発組織体制図
前年度までは、職能ごとに部が分かれていましたが、担当領域ごとに部を配置し、その配下にチームを配置しました。
具体的には、フロントエンドエンジニア、バックエンドエンジニアで分かれていたチームが合流。ディレクターとデザイナーで分かれていたチームも合流しました。
また、プロジェクトの開発、判断、コミュニケーション等のフローを整備する部の立ち上げが行われました。
システム構成とそれぞれのチームの依存関係
4-2. 2022年時点の各チームとサービスの関係図
既存システム内でもキャンペーンサービスのみになりますが、キャンペーンの部分に責任を持つチームを配置するなど、チームと役割についても明確になり始めました。
また、リプレイス済みのサービスが増えてきたため、SREチームができるなど、リプレイス後の運用面での体制についての整備も進み始めています。
この時の問題点とどのように改善しようとしていたか
4-3. 2022年上期体制での職能関係図
組織体制の問題点としては、2022年上期の体制では、図の通り画面・機能・デバイスなど、切り分けられる単位でのチーム分けができていない体制になっています。
そのため、エンジニア間、ディレクターとデザイナー間での連携は円滑に行えていますが、エンジニアとディレクター・デザイナー間での連携が弱い部分がありました。
リプレイス関連の問題点としては、リプレイス後の各サービスにリプレイスチーム側で改修を加える箇所があるため、 どのサービスを受け渡すかの検討や、リプレイス後のサービスへの機能追加等をどのチームがどのように進めるかの方針が決まっていない状況でした。
DMM GAMESプラットフォーム部は規模の大きいシステムを担当していることから完全な職能混在には至らなかったため、 画面・機能・デバイスなど切り分けられる単位でチーム分けができておらず、前述したような問題が発生していました。
4-4. 2022年現在、理想とするチーム体制図
現在進行形で進めていますが、問題に対して（また、これがDMM GAMESの理想形として）図のようなチーム体制を取り、各チームの役割を明確化してチームの構成とシステム構成が一対一になる組織を目指し、チームビルディングを進めています。
最後に、これから目指すところなど
リプレイス開始前と比べて、エンジニア、デザイナー、ディレクターがチームとしてプロジェクトを進めやすくなりました。
また、システム面では機能の修正による影響範囲が予測しやすくなり、結果的にデリバリー速度が向上しました。
組織全体としてはまだまだリプレイス後の運用とは合わない箇所や違和感を感じる箇所がありますが、分析・共有してより良いものに作り替えていければと思っています。
EXNOAでは、DMM GAMESプラットフォームを一緒に開発していくメンバーを募集しています。今回の記事をお読みいただきご興味のわいた方はぜひご応募ください。
フロントエンドエンジニア（東京（六本木））の採用について - 合同会社EXNOA
