レガシーシステムなどが原因で起きていた“価値提供スピードの遅さ”　アジリティ低下の解決のために実施した、システムリプレイスの「技術的戦略」と「運用アプローチ」

松下氏の自己紹介

松下健太郎氏：私からは「開発のアジリティ向上のためのシステムリプレイス」と題して発表します。よろしくお願いします。

最初に自己紹介をさせてください。松下健太郎と言います。合同会社EXNOAのブラウザプラットフォーム部に所属しています。チームリーダーをやっていて、本発表で触れる、システムリプレイスのプロジェクトの推進をメインでやっています。

略歴です。DMM.comに2016年に新卒で入り、DMM全体で使われる認証基盤のリプレイスに3年間携わりました。その後にEXNOAに転籍をして3年間またリプレイスをしているということで、これまでリプレイスメインでやってきています。

合同会社EXNOAについて

続いて会社紹介をします。合同会社EXNOAですが、「DMM GAMES」を運用している会社です。サービス開始から今12年が経っていて、比較的に歴の長いサービスですね。会員数は3,400万人で、240本のオンラインゲームを配信しています。

そして5つの事業を展開していて、主要なものは2つあります。1つが他社タイトルを中心に多様なゲームを配信しているプラットフォーム事業。もう1つはゲームデベロッパーと協力して新しいゲームを作っていく、パブリッシング事業があります。

そして、私が所属しているプラットフォーム事業は、さまざまなデバイスでゲームが遊べるプラットフォームを運営していて、3つのデバイス向けにプラットフォームを展開しています。

本日話すのはブラウザゲームという領域で、SPやPCのブラウザで遊べるゲームを提供しているプラットフォームを運営しています。代表的なゲームのラインナップとしては、『艦隊これくしょん -艦これ-』、『刀剣乱舞 ONLINE』みたいなものが挙げられます。

プロダクト開発組織の課題

本題に入っていきたいんですが、開発のアジリティを高めるためにシステムリプレイスに取り組んだので、その事例について紹介します。

弊社の開発組織では、開発のアジリティが低く、結果的にエンドユーザーへの価値提供のスピードが遅いという課題が長年ありました。アジリティというのは何かというと、ここでは素早く効率良く状況の変化に対応していく能力のことを指しています。スピード感のある開発が全体的にできていなかったという感じですね。

どうしてこういう課題があったのかというと、レガシーシステムが一因としてありました。

（スライドを示して）弊社のシステムをかなり簡略化したのが右の図です。これはぜんぜん実態に即していないんですが、モノリスが複数あるような構成になっていました。

これの何がよろしくないかというと、変更時の影響範囲が不明瞭なので、リリース前に十分な検証をしないと想定外のバグが出てしまう。あとは、システムと組織の構造を一致させることができないので、弊社で運用しているシステムをたくさんいるチームですべて見るみたいな構造になっていて、認知負荷が高かったりとか。

あとは、新しい案件をやる時も、開発チームが開発でぶつかってしまったりとかがありました。あとは、ナレッジ共有がどうしても人についてしまう。組織につくんじゃなくて人についてしまうので、属人化が進んで、退職した時に困るようなことがあったりしました。

このアジリティ低下の解決策として、システムリプレイスを実施することにしました。

これは3年ほど前、2020年の夏頃からやっています。このシステムリプレイスの技術的な戦略面と運用設計の両軸からアジリティが低いという課題について立ち向かおうとしているのが、現在になります。

リプレイスの方針と進行について

ここからは、リプレイスについて見ていきたいと思います。リプレイスの方針ですが、まずスコープは、基本的にエンドユーザー向けに提供している機能をリプレイスすることにしています。

これはどうしてかというと、組織としてエンドユーザーに価値を提供することに重きを置いているので、ここをまず高速化できるようにしていくことを目指しています。

技術面の戦略でいうと、複数のモノリス構成からマイクロサービスへの移行を進めています。狙いは、変更時の影響範囲を小さくすることで、開発者の認知負荷を下げていきたいと思っています。

そして、リプレイスに関しては、専任チームで進行しています。これはどうしてかというと、これまでの開発組織として、機能追加とか機能強化に対して、けっこうリソースを割く方向性があって。そういう状況下だと、リプレイスを進めるのが難しい。ということで、リプレイスを専任チームとして切り出すことで、集中してこの課題に立ち向かえるようになっています。

ここまで3年間リプレイスをしてきました。エンドユーザー向けの機能を中心に、すでに5つのプロダクトのリプレイスをしていて、もうエンドユーザーに展開しています。まだまだリプレイスするものがあるので、引き続きリプレイスはやっております。

開発のアジリティを高めるための仕組み1　マイクロサービス

ここからは技術的な戦略について見ていきたいと思います。開発のアジリティを高めるために、いろいろな仕組みを用意しています。順番に見ていきます。

まずはマイクロサービスですね。UIとビジネスロジックを分離することをコンセプトに置いているので、まずフロントエンドとバックエンドを分離しています。

フロントエンドに関しては、機能レベルでアプリケーションを分割しています。バックエンドに関しては、ドメインモデリングを行って、ビジネスドメインごとにバックエンドを分割しています。

そして弊社のシステムの傾向として、フロントエンドを改修する頻度が高いのですが、フロントエンドを改修した際に、その影響がバックエンドに波及しないようにBFF（Backend For Frontend）層を設けています。

なので、このBFF層でフロントエンド向けのデータを返すことによって、フロントエンドとバックエンドがそれぞれの責務に注力できるというような考え方でアーキテクチャを組んでいます。

実際にこれをやったことによって、変更時の影響範囲を小さくして、独立したデプロイを実現しています。結果的に、開発者の認知負荷の低減とかリードタイムの短縮、デプロイに関しても恐れなくできるようになっています。

BFFに関してはブログ記事に載せています。

バックエンドはGoでできているんですが、Goの利用事例に関しても登壇が行われていて情報が載っているので、興味があればご確認ください。

開発のアジリティを高めるための仕組み2　デザインシステム

続いての仕組みとしては、デザインシステムがあります。これは、UIスタイルの統一管理と、UIの振る舞いの標準化を目的に作りました。

今何があるかというと、デザイントークンと呼ばれるタイポグラフィとかカラーとか、スペースみたいなものであったり、あとはカードコンポーネントのようなUIコンポーネント集とアイコンが定義されています。

デザインデータに関しては「Figma」で定義して、デザイナーが管理しています。そしてUIコンポーネントはReactで実装して、フロントエンドエンジニアが管理しています。

これの何が良かったかというと、従来はデザイナーがデザインしたものをエンドユーザーに提供する前に、煩雑なフローと多くの職種が関わって提供していたんですね。デザインシステムができたことによって、これを共通言語にできるということで、コミュニケーション数がだいぶ減ったかなと思っています。

UIスタイルの統一でいうと、ボタン1つをとっても「似たようなものがたくさんあるけれども同じじゃない」みたいなこともあったりしていました。デザインシステムが導入されている箇所については、一貫した体験がエンドユーザーに提供できているんじゃないかなと考えています。

そして、UIコンポーネントですが、先ほど紹介したアーキテクチャだと、どうしても複数のアプリケーションができます。それは複数のチームで開発されていくんですが、複数チームが開発したとしても開発工数としては減らせるというか、実際、地道に作っていくところに比べると削減できているのかなと考えています。

開発のアジリティを高めるための仕組み3　共通インフラ基盤

そして次は、共通インフラ基盤ですね。リプレイスのシステムは基本的にコンテナで動かしているんですが、コンテナを動かすためのインフラ基盤が整備されています。実行環境としては「Kubernetes」を採用しています。

開発チームとインフラチームの責任分界点が明確化されているので、インフラチームがKubernetesクラスターを運用していて、開発チームから見るとインフラが抽象化されたようなかたちになっています。

開発チームはアプリケーション実行に責任を持つということで、Kubernetesのマニフェストを書いたりデプロイしたり、あとはログやメトリクスを「Datadog」で見るみたいなかたちで、一通りの運用を担っています。

こういう環境があることで、開発者はアプリケーションの開発と運用そのものに注力できるようなかたちになっています。

運用設計の基本的な考え方

ここまでが技術戦略です。ここまではあくまで仕組みの話で、実際にはこれを運用するための人とかプロセスとか組織とか、そのあたりに対してもアプローチしていくことが大事だと考えます。そこで次は運用設計になります。

運用設計の基本的な考え方ですが、エンドユーザーへの価値提供に注力するということを大事にしています。

「価値提供っていったい誰がするの？」となった時に、弊社の組織の場合は価値提供を責務とするチームがいます。目指していることとして、エンハンスするチームの開発者がリプレイスシステムを変更できるように支援していくということを基本的に考えています。

運用するためにやってきたこと1　責務ベースのチームへの移行

運用するためにいろいろやってきたことも紹介したいと思います。まずは責務ベースのチームへの移行です。これまではすべてのシステムを全開発者で見るような構図でしたが、マイクロサービスへの移行によって、管轄システムの割り当てが可能になりました。管轄システムの割り当てができるようになって、責務ベースのエンハンスチームを作りました。

これでどうなったかというと、開発者の一定の認知負荷の低減はできたかなと考えています。特に改修範囲が明確な案件に関しては、スムーズに取り組めるようになったと思っています。

一方で課題もあります。事業を成長させていく上では、どうしてもチームを横断する案件も一定頻度生じてくることがだんだんわかってきました。なので今後はこういったものに対してどうやって立ち向かうかというところも組織内で議論していかないといけないかなと思っています。

運用するためにやってきたこと2　コア機能・インフラの一元管理

次は、プラットフォームのコア機能・インフラの一元管理です。これは、特定の機能によらず、利用されるシステムやインフラを一元的に管理しようということで進んでいます。例に挙げているのは、会員とか決済のシステムですね。

これまでは複数モノリス構成だったので、会員とか決済にまつわるシステムがいろいろなところに点在していましたが、マイクロサービスへの移行によってある程度集約して管理されるようになりました。

そうすると管轄チームを作ることができるようになるので、エンハンスチームは管轄チームから会員のシステム、決済のシステムの提供を受けて開発することができています。インフラも同様ですね。なので、本来機能を開発していく上で注力するべきところにフォーカスできるような環境作りが整ってきています。

運用するためにやってきたこと3　開発と運用スキルの獲得支援

そして最後は、開発と運用スキルの獲得支援になります。これは何かというと、リプレイスシステムに関してはこれまでリプレイスチームが生み出しているので、どうしてもリプレイスチームにナレッジが寄りがちなんですね。

ただ、機能開発や保守はエンハンスチームがやっていかないといけない。そうなった時に、ナレッジの移転がどうしても必要になってくる。これをどうやって行うかという話です。

独力で行うということはどういうことかというと、システムの内部品質を担保しつつも、エンドユーザーへの素早い価値提供の両方を担えるようなかたちでの支援を行っています。

（スライドを示して）代表的な例だと、ここに書いてあるコードレビューや設計相談になります。この設計相談とは何かというと、新しいエンハンス案件が生じた時に……。リプレイスチームとエンハンスチームは必要に応じて相談をしています。例えば「マイクロサービスの責務をどうしたらいいかとか」「アーキテクチャをどうしたらいいか」という相談を定期的にやっています。

「リプレイスシステムとしてはこうやって開発していけばいいんだ」というようなインプットを定期的に継続的に行うことによって、最終的にエンハンスチームが独力で開発をできるような状態を目指していっています。

コードレビューも同様で、案件の内容に関して言うのではなくて、内部品質に関してレビューをするようなかたちですね。ほかにはドキュメントです。ドキュメントでリプレイスシステムのナレッジを溜める場所を作って運用していたり、あとはシステム課題について情報共有するような場を定期的に設けていたりします。

最近では少しずつ成果が見えてきている

今話した技術的な戦略、運用設計でさまざまな取り組みを行ってきました。最近では少しずつ成果が見えてきて。（スライドを示して）こちらはリプレイスチームの「Findy Team+」というSaaSのデータですが、デプロイ頻度や、サイクルタイムと呼ばれるコミットからプルリクのマージまでの時間で、まぁけっこう良い数字が出てきています。

ただ、これはあくまでもリプレイスチームの数字なので、先ほども話したとおり、エンハンスチームの生産性も上げられるようにということを今後取り組んでいきたいと思います。

（スライドを示して）こちらもSaaSのデータです。

2023年にDMM.comが「Findy Team+ Award」を受賞したんですが、EXNOAの組織もけっこう貢献しているんじゃないかなと思っています。

今後やりたいこと

まとめです。弊社の組織では、開発のアジリティ向上のためにリプレイスを実施していまして、技術的な戦略と運用設計の両軸から課題解決を目指しています。

今後やりたいことですが、大きく2つあります。まずは開発組織の開発生産性の可視化です。これをどうしてやりたいかというと、開発プロセスのボトルネックの検出をやりたいからです。今までは「なんとなく遅い」とか「なんとなく早い」という感じでしたが、定量的に分析できたほうがなにかと対策を打てるのではないかと考えています。

あとは、機能追加と保守のリソース配分に、生産性が上がったとか下がったとかの（データを）意思決定に使えたら良いのではないかなと思っています。

リプレイス（を必要と）するところまでシステムがそういう状態になるというのはあまりよろしくないと思っていて。今作ったリプレイスシステムに関しては寿命が長いものにしたいし、アジリティも高い状態を維持していきたいと考えています。そうなった時に、開発生産性というデータを利用して意思決定できたら良いんじゃないかなと考えています。

そして最後はリプレイスシステムの組織への浸透です。ここまで3年間リプレイスをしてきましたが、物を生み出すということに注力してきたせいもあって、エンハンスチームの開発生産性はまだまだ上げられる余地があると思っています。組織全体が生産性良く開発できるのも理想だし、事業（のこと）とかを考えたとしても良いことだと思うので、そこへの貢献を今後やっていきたいと考えています。