トップ > プラットフォーム > DMMプラットフォーム 共通ナビゲーションが担う役割と課題

DMMプラットフォーム 共通ナビゲーションが担う役割と課題

プラットフォーム 開発プロセス

サムネイル

はじめに

DMM プラットフォーム開発本部 Naviグループのtaketadaです。
本記事では、Naviグループとその担当機能である共通ナビゲーション(共通ナビ)について、以下の項目でお話しさせていただきます。

  • 共通ナビとは？
  • 共通ナビの役割とは？
  • Naviグループとは？
  • 共通ナビが抱える課題とその解消への取り組み

共通ナビとは？

共通ナビとは、DMM全体でヘッダー、フッター領域に共通的に組み込まれるナビゲーションプロダクトを指します。
プロダクト自体の歴史は古く、これまでDMM内の複数のグループが運用に携わってきました。

共通ナビはサーバーレスなWeb APIの形で提供され、リクエストに応じてブラウザ側にHTMLをレスポンスし、それを各事業部（サービス）が読み込むことで表示することができます。
各事業部側ではAPIのリクエストパラメータを変更することによって表示項目を変更することができます。

共通ナビの役割とは？

共通ナビには以下のような役割があります。

DMM全体のナビゲーションシステム

共通ナビはDMMのほとんどのフロントエンドアプリケーションに共通で組み込まれているため、DMMの各サービス間のナビゲーション・送客と回遊を促す役割があります。

DMMの複数サービスで統一されたインターフェースの提供

共通ナビは単体でDMMの売上に直接貢献するプロダクトではありませんが、組み込まれた複数サービスにおいて、統一されたインターフェースを提供できるため、DMMサービス全体の使いやすさに貢献できる側面があります。

独自の成長戦略を求められる

共通ナビは、単体で動作するWebアプリケーションではなく、Webアプリケーション内に組み込まれるマイクロフロントエンドのプロダクトです。
そのため、通常のWebアプリケーションとは異なった考慮事項があります。
一般的なWebアプリケーションのベストプラクティスをそのまま導入するのではなく、自分たちで成長戦略を考える必要があります。

2023/07に発足した、DMM内では比較的新しいグループとなります。
共通ナビの保守・運用を他の部署から引き継ぎ、担当しています。
チーム編成は、2024/04現在、マネージャ1名を含む5名のエンジニアで構成されています。

構成メンバーは新規にジョインしたメンバーが大半で、それぞれの経験を活かし職務にあたっています。
共通ナビとその関連アプリケーションの開発・運用全領域に携わるため、メンバーにはWebアプリケーションエンジニアとして広い職能が求められます。

共通ナビが抱える課題

Naviグループが共通ナビを保守・運用していく中で、グループ内でいくつかの課題があることがわかりました。
その中で取り組んだ課題と、解消への取り組みのー部をここで紹介します。

  • リリースによる表示崩れの発生
  • リリースの頻度が少なく変更のリードタイムが長い
  • 事業目標や目指す指標が明確でない

リリースによる表示崩れの発生

Naviグループによる運用開始時、機能リリースに際して表示崩れが頻発することがあり、障害検知の遅れとともにその修正対応に追われる形となっていました。
この原因の1つとして、別の部署からアプリケーションを引き継いだため十分な知見がなく、コード変更の影響範囲がわからなかったという側面がありました。

解消への取り組み

Four Keysによる開発生産性の可視化

まず現状を把握するため、リリースによる変更障害率やサービス復元時間を含めた、グループの開発パフォーマンスを可視化することからはじめ、その指標としてFour Keysを採用することとしました。

指標 説明
デプロイの頻度 組織による正常な本番環境へのリリースの頻度
変更のリードタイム commit から本番環境稼働までの所要時間
変更障害率 デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 組織が本番環境での障害から回復するのにかかる時間

引用元： エリート DevOps チームであることを Four Keys プロジェクトで確認する

計測した各指標の値を振り返り、都度改善するための打ち手を考えることを開発のワークフロー自体に組み込みました。

VRT(Visual Regression Testing)の導入

人の手による確認ではどうしても漏れが発生するため、Playwrightとreg-suitによるVRTを導入しました。
これにより、各環境のリリース前に故障に気付けるような仕組みを作りました。

変更のリードタイムが長くリリースの頻度が少ない

Four Keysを運用していく中で、変更のリードタイムの長さとリリースの頻度の少なさが課題となっていました。
当初のブランチ戦略としては、Git flowベースのブランチモデルを採用し、機能リリースは1週につき1,2回の頻度で行っていました。
develop, staging, masterの各ブランチへのマージをトリガーとしてCIから各環境にデプロイするフローは、各環境へ段階的に変更を適用するため時間を要し、結果的にリリースの度に大きな変更を行う結果となっていました。

解消への取り組み

GitHub flowの採用

機能を小さな単位で頻繁にリリースするため、GitHub flowを採用しました。
mainブランチに各機能ブランチをチェックアウト、マージすることでCIから各環境へデプロイするシンプルなフローによって、1日に何度も機能リリースができるようになりました。

事業目標や目指す指標が明確でない

Naviグループは比較的新しい組織のため、グループとして何を成すべきかの事業目標・指針が定まっていませんでした。そのため、取り組むべき案件の優先度設定が難しく、発生する依頼や課題に対して発生した順に取り組んでしまう形となっていました。

解消への取り組み

KGI、CSF、KPIの策定

Naviグループが提供できる価値・利益を洗い出し、事業目標としてKGIを設定して、そこに至るためのCSFとKPIの値をグループ内で決定しました。
これにより、自分達のやるべきことを自分達で判断する際の指標を数値ベースで考えることができるようになりました。

Performance Budgetの策定

共通ナビはDMM全体に共通的に組み込まれるという特性上、そのWeb Performance指標の悪化はそのまま各事業部に影響します。
そのため、Naviグループでは共通ナビに対して、独自にPerformance Budgetを策定し、その値を今後の開発戦略上で参照する形としました。

まとめ

本記事では、共通ナビとNaviグループの取り組みについて、駆け足になりましたが、紹介させていただきました。

今後Naviグループでは以下のような内容に取り組んでいく予定です。

  • 共通ナビのリプレイス
  • 事業部側の導入コスト削減、複数の組み込み選択肢の提供
  • DMM全体で共通に組み込まれている特性を活かした施策提案

また、現在Naviグループでは一緒に働いてくれるメンバーを募集中です。
以下からご応募ください。

https://dmm-corp.com/recruit/