はじめに

こんにちは、プラットフォーム事業本部の石垣雅人(@i35_267)です。 DMM.comのサービスで利用されるプラットフォーム基盤においてProduct Owner(以下、PO)を務めております。

弊チームでは、DMM.comのサービスで利用されるユーザーレビュー基盤を中心に開発しております。
今回は、弊チームで取り組んでいる開発プロセスについて、2019年4月9,10日に開催された「DevOps Days Tokyo 2019」で登壇してきた内容を補足説明しながらご紹介したいと思います。

登壇内容

セッションは、以下のタイトルで登壇してきました。

「Data-Driven x DevOps」という題名で、DevOpsといった開発スタイルにData-Drivenのエッセンスをどう馴染ませてプロセスを作っていくかについて述べてきました。主に以下の2点をお話しました。

「Data-Driven x DevOps」とは何か
BMLループで開発プロセスを構築する
- BMLループとは何か
- Idea → Build = 仮説から開発へ(何を作るか)
- Build → Product = どう作るかを考える
- Product → Measure = プロダクトの状況を計測する (ビッグデータ基盤へ集約)
- Measure → Data = 計測から構造化されたデータとして可視化する
- Data → Learn = データからどう学習するか
- Learn → Idea = 学習から仮説立案

ひとつずつ述べていきます。

「Data-Driven x DevOps」とは何か

まずは、DevOpsといった文脈になぜData-Drivenを加えたかについて述べていきます。

一番、大事だと思っているのがプロダクトをグロースさせる文化を作ることです。
なぜ、エンジニアが開発してプロダクトを作るかと言うと、プロダクトをより多くのエンドユーザーに利用してもらうためです。
その中で「DevOps」の文脈だけでプロダクトのグロースを考えるのは弱いと感じています。そこで、Data-Drivenの考え方を入れた上で組織としてこの2つを織り交ぜた文化を作り上げることが必要になってくると感じています。

では、DevOpsのような考え方だと弱いとはどういうことでしょうか。
例をあげます。下図をご覧ください。

左図で、簡単な開発プロセスを紹介します。

プロダクトバックログを作るにあたってPOが仮説を立ててストーリーベースでプロダクトバックログを作成していきます。
それをスプリントバックログへ落とし込み開発チームが開発→リリースします。
リリースしたものがインクリメント(=成果物)となり市場へ投入されます。

そして、DevOpsの責務範囲については右図で示していますが、DevOpsというとイメージされるのが、デプロイメントパイプランを整備してデプロイ回数の向上などの継続的デリバリーだと思います。
これには、ひとつ重要な観点が必要だと思っていてそれはビジネス価値との関係性です。

それは、デプロイ回数が上がれば上がるほど、プロダクトのビジネス価値が上がるわけではないということです。

場合によっては、リリースしたことでビジネス価値を下げるものもあるでしょう。
こうしたことを減らすためにData-Drivenのエッセンスを入れることで、よりヒット率をあげてDevOpsの恩恵を受けられるようにしましょう。というのがData-Driven x DevOpsの概要になります。

BMLループで開発プロセスを構築する

Data-Driven x DevOpsの関係性が分かったところで、この両方を組み合わせた開発プロセスを理解した上で、とても良いフレームワークがLeanStartupの中で提唱されているBMLループというがあります。

0. BMLループとは何か

簡単にループを説明すると以下の流れで開発プロセスを作っていきます。

Idea → Build = 仮説から開発へ(何を作るか)
Build → Product = どう作るかを考える
Product → Measure = プロダクトの状況を計測する (ビッグデータ基盤へ集約)
Measure → Data = 計測から構造化されたデータとして可視化する
Data → Learn = データからどう学習するか
Learn → Idea = 学習から仮説立案

といったプロセスで体系的に開発を進めていきます。
責務に分けると以下のような形です。

1. Idea → Build = 仮説から開発へ(何を作るか)

まずは、IdeaからBuildするフェーズです。
ここは、「何を作るか」という文脈で、優先度順位づけしていきます。

ポイントしては、この前のループ(Learn → Idea)で「仮説の妥当性」が担保されていることが前提になります。そのため、ここのループでの優先度の考え方は、仮説実行にかかるコスト（開発コスト、リソース等）を費用対効果として見て、優先順位を変えます。

つまり、「仮説の妥当性」や「効果予測モデル」がきちんと立っていることを前提に話すと以下の仮説があるとします。

開発チーム稼働率100％でMVP構築に3ヶ月かかるが効果が高そうな施策
開発チーム稼働率50％でMVP構築に1日ぐらいで効果がそこまで高くないもの

チームとして今システムリプレイス案件などで稼働が避けない場合は、POとしては2を選んだりします。

2. Build → Product = どう作るかを考える

開発するものが決まったら、次は開発をしていきます。

ここでは、高速にDevOpsを回していくために必要な項目をデリバリーパフォーマンスの4つについて紹介したいと思います。
詳しくは、LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加速するという書籍に述べられているので、ご興味ある方はご覧ください。

リードタイムの削減
これは、開発が始まってからリリースするまでにかかった時間です。このリードタイムを短縮することによって、すばやく機能を開発してリリースできるということでとても重要な観点です。
デプロイ頻度の短縮
デプロイの頻度が仮に1年に1回だとしたら、それが1ヶ月に1回や毎日できるようにしようといった指標です。これができないのはデプロイパイプラインが整備されていなかったり、リリースにおけるステークホルダーとの調整などが入ることがよくある起因です。
MTTRの短縮
MTTRとは「平均修復時間」のことです。つまり、障害や不具合が起こってからどれだけ早く復旧できるかが鍵になります。アジリティー高く、どんどん挑戦して失敗ができる環境を作るためには、その失敗からの復旧が迅速になされることも重要です。
変更失敗率の軽減
変更失敗率とは、本番環境での稼働に失敗した率のことです。つまり、MTTRの部分でどんどん挑戦して失敗できる環境が大事と述べましたが、すべて失敗していては意味がありません。
そういった意味でいかに失敗率を下げるのかがプロダクトの開発には重要になってきます。

3. Product → Measure = プロダクトの状況を計測する (ビッグデータ基盤へ集約)

このフェーズから、本格的にData-Drivenの文脈に入ってきます。
まず、Data-Drivenにおける第一優先事項は、「データ」が存在することです。つまり、ビッグデータ基盤のようなDWH(データウェアハウス)のことを指しており、これがないと分析もできないのでまずはデータを集約することが大事になっていきます。

DMM.comでは、下図のような構成でユーザーの行動ログを集約しています。
各サービスにJSLibrary経由でTracking APIを利用してHadoopに集約しています。それらのビッグデータを使ったレコメンドエンジンや検索エンジンなどのさまざまなプロダクトを作っています。

ユーザーの行動としては、購入履歴や閲覧・クリック履歴、ユーザーの属性などさまざまな要素を取得しています。
もう1つ、大事な観点としては ビックデータ基盤から職種関係なく、全員がSQLを書いて取得できることです。
これをエンジニアだけではなく、営業やカスタマーサポートなど全員が書けることで、今まではエンジニア側に依頼として来ていたものが減ります。データ抽出といった定常業務がエンジニアとしてはなくなり、依頼している側の待っている時間のリードタイムも減るためメリットが多いです。

4. Measure → Data = 計測から構造化されたデータとして可視化する

よくある問題点として、ビッグデータ基盤はあるがそこからデータの可視化やデータ活用がうまくいかないといった声があります。
それはそのとおりで、膨大なビッグデータ基盤からビジネス価値があるデータを取得できなければ意味がありません。
ここでは、さまざまな指標がある中で一番はじめに行うべき「KPI」の可視化について説明していきます。

何か施策を実施する際には必ず効果としてみたい数値があると思います。
そういった通知をKPIとして設定して常にチームが監視している状態が望ましいです。

KPIを決める前にKGIとCSFについて理解していないといけません。
下図に説明があります。

KGI = 中長期的な目標
CSF = KGIを達成する上での要因
KPI = CSFの要因に対する達成する数値

例を出すと、KGIが業界1位のサービスになるだったら、そのために必要なCSF(要因)としてアクティブユーザー数を上げるだとするとKPIはMAUを1万にする。
といった具体的な数値目標になります。

ここまでが、KPIについての概要でしたが、3つほどポイントがありますのでご紹介します。

「ポイント1 KPIは定数ではなく変数にあるべき」

これはプロダクトが直接影響を与えられない部分をKPIとしてしまうと外部要因で数値が動いてしまい、目標値としてはふさわしくないということです。

例えば、自分が検索エンジンのプロダクトを関わっていたとして、CTR(Click Through Rate)のようなクリック率は影響を与えられますが、 検索対象のコンテンツ数について影響を与えられません。
こういったような自分のプロダクトの管轄外の部分についてはKPIとしては設定するべきではないと考えています。

「ポイント2 KPIは定数ではなく変数にあるべき」

先行指標とは、少し未来の数値のことです。
逆の言葉で遅行指標というものがありますが、行動に対して起こったあとの数値のことです。

KPIについては、先行指標といった数値を置くことが推奨されており目標値として、相関指標や因果指標からある程度未来の予測値を作成し、それに向かって施策を実行するのが良いからです。

「ポイント3 先行指標の選定」

ポイント2の項目にかぶる部分もありますが、KPIを先行指標として設定するにあたって、「どんなものが先行指標となり得るか」を考えなければなりません。
そのために必要なのは、プロダクトに関係ある「相関指標」を可視化し続けることです。相関指標とは、AとBは関係しているといった形でプロダクトに関係ありそうな数値のことです。
例えば、アクティブユーザー数を伸ばしたいと考えていたときには、月のアクティブユーザー数の変移に相関がないか、ユーザーの属性ごとに偏りがないかを見ていきます。
こういった地道な可視化から、プロダクトに最適なKPIを設定していきます。

Facebookの例を出します。
Facebookは「エンゲージメントを高めたい！」といったCSFがありました。そして、相関指標として以下のことを見つけることに成功しました。

「アカウント作成後、10日以内に複数の友達とつながればそのユーザーはエンゲージメントする」

これが分かってしまえば、KPIとしては新規登録したユーザーに対して、10日以内に複数の友達とつながる率を80％にする。といったKPIが出来上がります。
あとは、このために施策を実行するだけです。例えば、新規登録したユーザーに対して一番はじめにレコメンドで友達そうな人をリストとして表示するなどです。

5. Data → Learn = データからどう学習するか

ここでは、データ分析のアプローチについて紹介でします。
ここまでのループで、データ集約→データからKPI策定ときたので次のそのデータを使ってどのように分析をしていくかについてです。

3つあります。

現状理解 (ビジネスモデル理解からのCSF,KGI,KPI)
仮説検証型アプローチ(仮説実行に対して、その結果がどうなっているかの通知)
探索的アプローチ(ユーザーの行動からボトルネック特定や仮説立案)

現状理解については既に述べた通りですし、仮説検証型アプローチについてはスライドに記載してありますのでそちらをご覧ください。

今回は、その中でも「探索的データ分析」について紹介します。

いわゆる、ユーザーの行動を可視化することによってボトムアップで仮説を立案していきます。

今回は、「ファネル」といったユーザーがコンバージョンするまでの行動について探索的に分析してみたいと思います。

やり方としては、上図のほうにユーザーがサイトへ流入してからコンテンツを買うまでの流れを数値化しています。その中でファネル遷移率を数値として可視化して、遷移率が低い部分をボトルネックとして見ていきます。
上図の例ですと、数値はサンプルですが、レコメンド閲覧からのカート追加が50％と高いことが分かります。
逆にカート追加からの決済率が0.6％と低いことが分かります。

ここから仮説を出すことができます。

例えばですが、カート追加から決済までフローが長いのかもしれないですし、UI/UXが悪いのかもしれないなど、相関関係の可視化を進めていくことができます。そこから仮説実施による改善を行っていきます。

ポイント
一般的にサイトの購入数が上がらないといった問題が挙がった時に流入を増やそうとします。
しかし、探索的データ分析をしてみると実は流入は確保できていてカート追加から決済までの部分が弱いといった事実は見えてきます。
こういったユーザーの行動からのか仮説立案方法も有効です。

6. Learn → Idea = 学習から仮説立案

最後にこれまでのフェーズで学習してきたことから仮説を立案していきます。

ここでは、特に手法というよりかは仮説立案の心得を紹介します。
「Data-Driven」と「Data-informed」についてです。

仮説立案で気をつける部分は、「データの奴隷」になってはいけないことです。
そういった意味で「Data-informed」という考え方は、データの中に意思決定があるのではなく、意思決定する上での１つの情報としてデータがあるといった考え方です。
つまり、定量的なデータも必要ですが、定性的なデータや直感も時には大事にしながら、仮説や施策の優先度を考えていきしょうといった形です。

まとめ

いかがだったでしょうか。今回は、「開発プロセス」をキーワードにBMLループを使ってプロセス設計について述べていきました。少しでも、参考になれば幸いです。

最後に

最後に採用情報をお伝えさせてください。私がPOを務めるプラットフォーム事業本部 Customer Decision Support Teamでは、一緒に働いてくれる仲間を探しています。 2018年7月に立ち上げたばかりでまだまだポテンシャルを秘めたチームです。少しでもご興味のある方はぜひご応募ください！

また、プラットフォーム事業本部には、各プロダクトチームと連携してDMM.comの多様なビックデータからデータ分析してくれるアナリストチームやビックデータ基盤を作っているエンジニアが存在します。そちらも採用募集しておりますので、ぜひご応募ください。

dmm-corp.com

DMMにおけるユーザーレビュー基盤の変革(開発プロセス編)【DevOps Days Tokyo 2019】

シェア