プロダクトグロースのためのデータ活用 - NTT Communications Engineers' Blog

データ駆動型の意思決定が重要視される現代のビジネス環境において、プロダクト開発におけるデータ活用は不可欠です。この記事では、開発中の新サービス COTOHA Insight Detector（仮称。以下、CID）でのデータ活用を通じて得られた知見と、データ活用の重要性について紹介します。

はじめに
なぜデータ活用が大切か
プロジェクトのゴールとチームの課題
プロジェクトの実施内容
プロジェクトの振り返りと今後
おわりに

はじめに

こんにちは、デジタル改革推進部データドリブンマネジメント推進部門（以下、DDM）の組橋とコミュニケーション＆アプリケーションサービス部（以下、C&A） CIDチームの村上です。

（組橋）DDMは、全社のデータ活用を推進する部署で、現在私は今回紹介するような各プロダクトのデータ活用の支援を実施したり、データ活用の研修を実施しています。

（村上）C&Aは、新サービスやアプリケーションを開発する部署で、現在私はCIDのプロダクトオーナーをしています。今回はDDMのメンバーと一緒にリリース前のサービスに対するデータ活用を実施したプロジェクトの内容について説明します。

なぜデータ活用が大切か

本題に入る前に、なぜデータ活用が重要なのかについて触れておきます。

プロダクト開発において、ユーザーの声を聞くことは重要です。しかし、ときには「人はウソをつく」こともあります。これはなにも悪意があってウソをつくことを指しているわけではありません。ユーザーの言葉が実態と乖離しているケースが発生しうるのです。

例えば、ユーザーが「この機能は結構使う」と言っていても、実際のデータを見るとほとんど使用していないことがあります。他にも「これは基本機能なので、新規ユーザーのほとんどが使うだろう」と想定していても、実際にはかなりのユーザーが離脱していることもあります。

このような齟齬が生じる理由は、人間の記憶や認識が必ずしも正確ではないからです。また、ユーザーが自身の行動を客観的に把握できていない場合もあります。そのため、主観的な意見や直感だけでなく、データで検証することが重要になります。

プロジェクトのゴールとチームの課題

CIDのデータ活用プロジェクト（以下、本プロジェクト）におけるゴールは下記の通りと定めました。

ユーザー行動に関する定量的な仮説検証をCIDチームのみで実施できるようにすること

このゴールとした理由については、プロダクト開発における下記のような課題をチームで抱えていたことに起因します。

プロダクト開発の課題
- PoCなどを通じてご利用いただいているお客さまからは好評をいただいているものの、実際にはあまり使われないことがある
データ分析の課題
- ログをただ出しているだけで整理されていない（トラシュー目的のみ）
- どうすれば定量的に検証できるか不明

まず１点目の「良いと言ってるのに使ってくれない」と言う課題についてです。どんなプロダクトも技術的に優れている、あるいはUIが綺麗であるとしても、最終的にユーザが使ってくれないと意味がありませんし売れません。そのためには開発段階からさまざまなターゲットユーザへのヒアリングやPoCなどを通し、どんな問題を解決するためにどんな人がどのように使ってくれるのか、と言う仮説検証をたくさん実施することになります。その仮説検証について、特に「定性評価」を行なって評価する場合は、ターゲットユーザにある機能についてどう思っているかインタビューをします。このインタビューでは、「とても良い」「便利で使いやすい」「もう少しサクサク動いてほしい」などポジティブ/ネガティブ問わず、さまざまな評価を得られます。場合よってはポジティブな意見の割合が大きく、それを信じて特定の機能を価値あるものとして採用したとしても、実際にはユーザに使われない、なんてことがとてもよくあります。

これは社交辞令、日本人的な調和を優先とした回答、相手への配慮など色々な要因があると思われます。しかし、先ほど述べた通り、直感は大切ですが「人はウソをつく」ので、やはりデータによる細かい検証が必要だと思います。今のプロダクト開発は「定性評価」は欠かさず実施していましたが、データを用いた「定量評価」により各機能の利用状況などを仮説検証する、と言う流れはまだできていませんでした。

２点目についてですが、こちらもプロダクト開発にはよく見られる問題です。トラブルシューティングや安全な運用のためにアプリケーションの動作ログそのものは保持しているのですが、それが開発段階でデータ分析の観点では生かされていなかった、と言うものになります。また先述のような「定量評価」を素早く実施するためにどのような形でデータを保持するのか、どんな観点でデータを集計すればいいのかなど、雰囲気はわかっていても実際に自分たちで一気通貫に実施する経験やノウハウが足りていませんでした。

プロジェクトの実施内容

先のゴールを達成するために、本プロジェクトでは下記について実施しています。

ゴール設定
ヒアリングシート
CJM作成
データ取得、分析環境の準備
仮説作成
検証

ゴール設定

最終的なゴールについては先に述べた通りですが、ゴールについてはプロダクトやチーム状況で変化します。例えば別のチームでは、すでにサービスはリリース済みで、ユーザ離脱のタイミングをカスタマージャーニーマップに沿ってフェーズ遷移の分析をすることによる「顧客流入・離脱の仮説検証」に取り組んでいました。一方自分たちのチームでは、まだサービスリリース前ということもありPoCなどは何件も実施していましたが、流入離脱を分析できるほどまだデータがなかったこともあり、既存機能の仮説検証をする方向でゴールを設定しました。

ヒアリングシート

企業の多くがそうであるように、NTT Comでもデータ分析組織であるDDMと実際に分析を実施したいサービス開発部署とで組織が分かれていることもあり、まずはお互いにプロダクトの状況をしっかり把握することが肝要でした。そこで、下記のような内容を項目別に整理してみました。プロダクト開発においては、エレベータピッチ、リーンキャンバスやバリュープロポジションキャンバスなどで整理されているものが多く含まれていると思います。

プロダクトの背景
NSM/KPI等の指標
収支状況
ペルソナ
プロダクトの特徴
社内ステークホルダー
データ活用状況　等

これらを活用することで、プロダクトの現在の状況や課題についてDDMと認識を合わせていきました。

CJM作成

カスタマージャーニマップ（以下、CJM）とは、顧客が商品やサービスを購入・利用するまでの道のりをわかりやすく整理したもので、プロダクト開発の際にも活用されます。プロダクト開発用に全体のCJMは作成済みだったのですが、今回ゴールで設定していた「既存機能の仮説検証」に対応するため、トライアル時のユーザが触る機能をかなり詳細化したものを作り直しました。こうすることでユーザが目的を達成するためにトライアルでどの機能をどういう順番で触り、どこに不満を感じどんな感情に変わっていくのか仮説を細かく定義でき、データ分析でどこを対象に定量検証するか、のイメージを固められました。

データ取得、分析環境の準備

具体的にどんな仮説を検証するのかは後述しますが、今回データ分析を実施するにあたり、商用環境のログを構造化していく必要があります。 NTT Comでは社内にDLXという社内の共用データ分析環境があるので、それを使う案やGCP（我々のプロダクトを構築している）上だけで完結させる案を検討しましたが、PJや案件の状況に応じて変わると思います。検討したポイントは下記です。

学習コストがどのくらいか
分析にかかる時間はどのくらいか（リアルタイム性）
データ設置に関するセキュリティ
変更容易性
データ連携のやりやすさ

最終的にはGCP上で完結させ、StackDriverからGCSに書き出したログを定期的に構造化して、分析を実施する形に落ち着きました。

仮説作成

今回ゴールである「ユーザー行動に関する定量的な仮説検証をCIDチームのみで実施できるようにすること」を達成するために、「既存機能について定量的な仮説検証」に取り組みました。自分たちのプロダクトはいくつかの機能がすでにユーザヒアリングなどを通して価値があると判定されたものがいくつか存在しています。そのうちの１つの機能について下記のような仮説を考えました。

当初の仮説：
「ユーザは分析結果画面で結果を確認するときに、＜対象別、課題表示＞、＜課題別、対象表示＞
両方のモードを使い分けて課題特定をしているはずだ。」

CIDにはVOC（お客さまの声）を分析する機能があるのですが、それを①「対象」別にどんな「課題」を持っているのかを表示する機能に加えて、②「課題」別にそれがどんな「対象」に分布しているのかを表示する機能が具備されています。今回はこの②が本当に価値あるかを定量的に明らかにしようというわけです。

結論から述べるとこの仮説はデータ分析には不適切だと言うことがわかりました。この仮説には下記の要素が抜け落ちているからです。

仮説検証後の具体的なアクション
仮説の判定をする具体的な目標数値

どちらもデータ分析結果が明らかになった後で決めると余計なバイアスがかかってしまうという共通の問題があります。 1については、結果が明らかになった後でその後のアクション（別の機能をためそう、検証機能自体を拡張しようなど）を決定してしまうとデータ分析の結果前提で自分たちの都合の良いアクションを決定してしまう可能性があります。 2については、例えば以下のような2つの仮説があるとき、両者は利用率が結果30%だったという結果は共通ですが、判定結果としての受け取り方が全く異なります。

利用率が20%を超えると思っていたが、30%だった。
利用率が40%を超えると思っていたが、30%だった。

後から数値を決めてしまうと都合のいいように判定結果を変えられてしまいます。

以上を踏まえて、ブラッシュアップ後の仮説は下記の通りとしました。

プラッシュアップ後の仮説：
「課題自体を特定したいユーザは分析結果画面で結果を確認するときに、＜対象別、課題表示＞モードの表示回数と比較して、＜課題別、対象表示＞モードの表示回数が50%以上となっているはずだ。」

合わせて仮説検証後の具体的なアクションも下記と定めました。

50%以上の場合：高頻度に＜課題別、対象表示＞モードを活用していると考えられるため、「課題を特定し、それに対して対策を講じるべき対象を決める」と言うケースにおいてCIDの価値を感じてくれているので現状のままでOK。
50%未満の場合:この機能が使われていない。課題ベースで分析の深掘りをしない理由を深ぼってヒアリングする。単純に機能に気がついていないのか必要性を感じないのかなど理由を探る。

実際にデータを見る前にここまで決めてからやっとデータの中身精査に取り掛かりました。

検証

下記は実際にあるPoCで使い始めたお客さまの一定期間の例です。

モード	表示回数	割合
＜対象別、課題表示＞	145	-
＜課題別、対象表示＞	17	11.7%

ユーザのヒアリング内容をもとに開発した機能は、実際に触った後のヒアリングでもとても肯定的な意見が多かったにも関わらず、実際のところ想定よりも使われていなかったことがわかりました。正直この結果はユーザインタビューによる定性的な調査結果とは少しずれている結果だったので、チームとしても新しい発見であり真摯に受け止めて次回以降のユーザヒアリングに繋げていこうと思います。

最後に実際に実施した際に起きた問題点などについてもすこし触れておこうと思います。

分析の課題

キャッシュによる分析誤差
- 一部の機能についてはAPIコール回数などで定量評価をしようとすると、キャッシュが動作するなどして実際よりコール回数が小さくなってしまうなどの問題があるため、ユーザ行動を正確に把握するためにはフロントエンド側でもログをGoogle Analyticsなどで取得する必要がありました。
ログの構造化が煩雑
- ログ設計もトラブルシューティング目的がメインだったりすると、後からリクエストやレスポンスのパラメータを詳細に見ようとした時にうまくシリアライズされていないと中身がわからなかったり、jsonとして読み取れなかったりして苦労することがありました。具体的には下記のような形のログだと分析ができません。