こんにちは。12月10日のProduct Manager Advent Calendarを担当します、ヤフーの里山と申します。普段はYahoo!ブラウザというアプリのプロダクトマネージャーをしています。

世間で少しずつではありますが、「アプリの会社」として認識されてきた感のある「Yahoo! JAPAN」ですが、PC同様に、圧倒的なユーザー数を抱えるアプリをいくつも運営しています。今回はそんなヤフーのアプリのプロダクトマネージャーが考えていることを書き出してみたいと思います。

プロダクトマネージャーとは

プロダクトマネージャーの定義はヤフーとしては明示されていませんが、プロダクトのグロースに対して責任を持つ人であると考えています。

ヤフーでは基本的にはユーザーサービス毎に責任者としてサービスマネージャーがいます。サービスのくくりは様々で、サービス内にプロダクトがひとつの場合は、サービスマネージャーがプロダクトマネージャーということになりますし、そのサービスに複数プロダクトを抱える場合は、プロダクト別にプロジェクトマネージャーを置くことがあり、その場合はプロジェクトマネージャーがプロダクトマネージャーになるということになります。

いずれにしても、プロダクトマネージャーがヤフーでの正規の役職やラベルではないため、各種マネージャーがプロダクトのグロースに責任をもっているということを明確化したい場合にプロダクトマネージャーと名乗る場合がほとんどです。

プロダクトの価値の深掘り

ヤフーでは定期的に定性調査や定量調査を実施し、どの機能がユーザーに支持されているのか、ユーザーはその領域にどのような課題感を持っているのかを分析しています。その結果、アプリの方向性の指針となる、「コアバリュー」というものを定義し、メンバー間でアプリの提供する価値の考え方がブレないように進めています。

定量調査で得るのは現在のプロダクトの状態

以下は実際に私がマネジメントしているYahoo!ブラウザーというアプリで、とある月の初日にDLした人たちが一ヶ月間のどの機能を使ったかという機能別UU(ユニークユーザー)を取ったものです。

そのUUによって、機能別の「ユーザーに支持されている機能」、「定着施策が必要な機能」、「支持されていない機能」に大きく分類されます。このように、定量調査・分析からアプリの今の健康状態がわかります。

単純に考えると、「ユーザーに支持されている機能」をさらに伸ばすか、「定着施策が必要な機能」の訴求や磨き込みを頑張るかというお話になりますが、気をつけないといけないのは、この数字は非常に大切な気づきをくれる反面、「現時点のアプリがユーザーにどう見えているか」ということであって、「私たちがユーザーに何を届けたいか」であったり、「ユーザーの求める課題を解決しているかどうか」と結びついているわけではないということです。

ユーザーに何を届けるかを決めていくには、ユーザーがどのような価値基準を持っているかを知らなければなりません。

定性調査で得るのはユーザーの価値基準

定量調査とともに必要になってくるのが、定性調査です。定性調査とはターゲットユーザーの意識や価値観に注視して、意見を元に情報収集・分析をする手法です。

ヤフーでは、多くの社員を抱えているので、社内メンバー、もしくはその家族へのヒアリングなども数多く実施しています。手法としては、シナリオを元に対象者に行動してもらい、それを観察します。そのときのメモを元に「なぜ」その行動を取ったのかを細かく質問していきます。また、そのときに、競合との比較や、周りへおすすめする度合い、おすすめしたい機能などまで詳しく聞き込みます。

また、以下のような行動観察のサービスを利用することもあります。

UIscorp
https://client.uiscope.com/

ユーザーへの行動観察後の質問ができないのが難点なので、前述の社員へのインタビューと並行したりもしますが、アプリを継続的に行動観察できるという意味ではPDCAが回しやすく、非常に便利です。

その後、インタビューの発言や、行動観察で気づいたことなどをまとめカテゴリ分けしていきます。

そこから、ニーズをまとめ、動機と理由の推測からユーザーの価値観に対する仮説を立てていきます。

定量調査で得たユーザー行動と、定性調査で得たユーザーの価値観をもとに、アプリの方向性であるコアバリューを立てていきます。

コアバリューをしっかり握る

リリース後のアプリといえども、コアバリューの見直しは非常に大事です。時代とともにユーザーの価値観が変化する場合もありますし、社内の開発メンバーの入れ替えによって結果的に方向性がぶれてしまうことがあるからです。

コアバリューの前に、私たちの実現したい世界や、なぜ私たちがやるのかといった「Why」の定義をします。その上で、私たちがユーザーに届けたい最大の価値として「コアバリュー」を定義します。

コアバリューとしては以下のようなものです。
「<ユーザーターゲット>の＜カテゴリへの課題＞へ＜ソリューション＞を提供する」

ユーザーターゲットは日本人なのか、どういう世代なのか...etc
カテゴリへの課題は顕在化した問題なのか、潜在的な課題なのか...etc
ソリューションは情報なのか、体験なのか...etc

アプリ毎にコアバリューは様々に変わります。

コアバリューを作ることで、ユーザーに伝えたいビジョンの共有ができ、チーム内でプロダクトを検討する上での「基準」や「優先順位」ができあがって来ます。

自走できる組織のできる最もコアな要素かもしれません。

目標指向とKPIツリードリブン

ヤフーでは、開発チーム全員が明確に数値目標を持ち、期ごとに簡単には達成できない目標を置いてグロースしています。厳しい目標があるからこそ知恵を絞り、コアバリューとアプリの事業成長の両立を考えていけると思います。

簡単には達成できない目標を達成する場合、知恵を絞るという部分をいかに体系的に整理しておくかという観点は非常に大事です。プロダクトの状態を定量的に可視化するためのツールとして、私たちは「KPIツリー」を利用しています。

KPIツリードリブンで「勘を排除」

アプリを事業として行う最終ゴールとはなんでしょうか？当然事業としてやるからには利益と結びつく必要があります。ただ、アプリが直接売上を得るものもあれば、間接的に会社貢献するものもあります。例えば、企業へのファンを増やしブランディングを行うような場合です。

その最終ゴールを設定し、可視化するというのは非常に大事です。私たちはそのゴールを「KGI(重要目標達成指標)」と呼んでいます。

「KGI」を設定したときに、ただただ達成するためにがむしゃらに開発をしていてもまったく機能しません。「勘」の要素が多すぎるのです。その勘を排除するには、計算式が成り立つレベルまで要素を噛み砕き、達成に必要な要素を分解する必要があります。

例えば、アプリにおいて、クリック課金型広告の「広告売上」をKGIに設定すると、一日の広告売上は以下の計算式で試算できます。

「一日の広告売上」 = 
「一日の利用者数（DAU：Daily Active User）」
x 「ひとりあたりの一日の広告のタップ数」

さらに、「一日の利用者数（DAU：Daily Active User）」を試算してみると、以下のようになるでしょう。

「DAU」 = 「インストール当日の起動数」
+ 「昨日のインストール数」x「翌日も起動する割合（翌日リテンション）」
+ 「一昨日のインストール数」ｘ「翌々日も起動する割合（2日リテンション）」
+　...

気が遠くなるかもしれませんが、このすべての要素を成長させるわけではありません。省略できることも数多くあります。

インストールからある一定の日数を過ぎた場合、アプリを起動してくれるのは、そのアプリを使うことが習慣化した、コアなファンのみになり、その人はほぼアンインストールをしません。つまり、インストールからある一定日数以上たった人は、「既存DAU」としてまとめてしまえる場合があります。

また、昨日起動したユーザーと今日起動したユーザーに圧倒的な行動の差がなければ、それらをまとめてしまえるでしょう。例えば、インストール翌日と７日後のユーザー行動を追えば、ある程度アプリの健康状態がわかるかもしれません。

「インストール数」も、プロモーションによる出稿と、アプリストアからの自然流入、自社サービスからの流入などもあるでしょう。

結果的にこの例の場合、「広告売上」というKGIを伸ばすために必要な要素は以下のようになります。

カスタマージャーニーとは？｜事例５選から学ぶカスタマージャーニーマップの作り方
http://ecbible.net/contents-marketing/customer-journey

とはいえ、コアバリューを元にKPIツリーを作っているのなら、おのずと初日に体験してほしい一番の価値は整理していると思うので、その機能の訴求方法に仮説を立てて進めるのも良いかと思います。いずれにせよ、ユーザーは初日ですべての機能を体験できるわけではないので、段階的な成長訴求を実施すべきだと考えます。

アクティブ率に気をつける

KPIツリーのところで少し触れましたが、ある日のインストールから数ヶ月も立つユーザーを「既存DAU」としたとき、そのDAUは、すでに自分たちの日常に合わせて使うようになるので、「使うときは使う、使わないときは使わない」というのが明確になっていると推測されます。

この状態で、「今日使っていないユーザー」に新たな価値を提供することで、ユーザーのリテンションが高まり、よりアクティブに使ってもらえるようになります。この状態を、アクティブ率という指標で見ています。インストール数を母数にする場合もありますが、私は、DAU/MAU　(Monthly Active User：月に利用しているユニークなユーザ)で見ることが多いです。

以下は、あるアプリのDAUの推移ですが、うまくユーザーに価値がマッチすると大きく伸ばすことができることがわかります。

エンジニア知見からのアプローチ

私はプロダクトマネージャーをやっていますが、あくまでも社内ではPMというラベルであり、ベースとなる職種はエンジニアです。エンジニアを出自とするマネージャーだからこそ考えることができる観点もあります。

以下、エンジニア知見を元にして気にしているところを紹介します。

開発プロセスは明確に

開発プロセスの明確化は特に意識しています。私のマネジメントしているYahoo!ブラウザーでは「Scrum」を採用しています。ヤフーではプロダクトマネージャーはScrumでいうプロダクトオーナーと同義になります。

Scrumを適用するときに特にメリットだと感じているのは以下の3点です。

• タスクの優先順位付けが柔軟に変更できる
• プランニングで開発陣と開発内容についてコミットすることでメンバーに無理をさせないで済む
• ベロシティ管理によってメンバーの開発効率の成長を促せる

個人的には、２つめの「メンバーに無理をさせない」は肝だと思っています。メンバーのモチベーションを下地に思い切り開発をすることを推奨していません。そのスプリント（期間）でやれないものはプランニング時にバックログに戻してもらえれば良いと思っています。私たちのような事業会社のプロダクトマネージャーとしては、現在の生産性からリリース日などの見通しがつくだけで良いのです。

私個人的には、アジャイル開発プロセスの中でも「XP」の「週40時間労働」というプラクティスが好きです。自分の時間を作って自分らしく働きたいですし、周りにもそうしてほしいです。40時間という数字自体はそんなに簡単に達成できるものではないですが、メンバーがタスクの見積もり精度を向上させたり、開発効率を成長させたりすることで、そういう世界が実現できるように、枠組みは維持したいと思っています。

危険な問題は大枠で手綱を握る

プロダクトの開発をやっていると、技術の陳腐化やユーザーの行動変化などを理由に、プロダクトの大きな手術をしないといけない場合があります。そのような場合は言葉が空中戦になって、メンバーの認識の差異が大きくなることも少なくありません。また、予定している機能によっては設計変更を何度も検討しないといけない場合もあります。そのままだと品質リスクが問題化してしまいます。

こういう場合は、実装方針の方向性をエンジニア観点から大枠で握ったりします。私たちのプロジェクトでは現在プロダクトの大手術の真っ最中ですが、ホワイトボードに、付箋でこしらえたクラス図を作り、私の席の近くにおいています。メンバーが集って話すことで意思疎通を柔軟にはかれますし、結果的にメンバーの議論の真ん中に入ることができ、実装方針の意思決定をすることもできます。

クラス図を付箋で作って議論のテーブルにする

ワイルドなチャレンジを

技術的なチャレンジにも目を配らせています。例えばAndroidの標準APIを利用して書くよりも、とあるOSSのライブラリを利用したほうが設計がシンプルになるメリットがある一方で、学習コストを鑑みると標準のAPIで実装したほうが早いんじゃないかというデメリットがある場合、私はたいていOSSの方を推奨します。

結果的にメンバーの知見が広がればいいですし、ワイルドにチャレンジしないと楽しくないんじゃないかと思えるからです。

オフショア開発

プロダクトマネージャーはリソースの問題にも手を打っていかないといけません。特にアプリエンジニアは、関東で枯渇している印象が強く、もっと計画的に確保計画を立てないと、プロダクトの成長などおぼつかない状況です。

ヤフーの場合、現在ベトナムにも開発拠点を持っています。リモートで開発部隊を持つには、気にしないといけない点が数多くあります。

ここは、先日、ヤフーのTechBlogに詳しく載せたので、参照していただければと思います。

海を超えたチームプレー！〜アプリ開発のオフショア化〜
https://techblog.yahoo.co.jp/advent-calendar-2016/offshore-app-dev

カスタマーサポート

ヤフーにはカスタマーサポート部隊があります。アプリ内から問い合わせできるフォームを持ち、ユーザーの不満にできるだけ応えられるように頑張っています。また、GooglePlayのレビューも開発チームで毎日見ています。

ユーザーからのご意見やご要望は、カスタマーサポート部隊で集約して分析してもらい、定期的にミーティングを行い、メンバー間で共有、解決策を検討するというフローを回しています。

まとめ

いかがだったでしょうか。あくまでもこれは、私個人がこの２年間、戦略担当やプロダクトマネージャーとして気にしてきたことです。チーム規模が異なれば、気にする部分も異なるでしょう。まとめてみて感じている部分は以下の２点です。

意思決定の機会はとにかく広く多い

意思決定するのは大変なことです。責任もあります。これだけ整理して意識していても、プロダクトがグロースする時期、しない時期それぞれあります。変動要素だらけなので、ときにはどうしようもないときもありますが、どれだけ前向きに準備して着実に実施できるかが大事だと思っています。

自分の色を出す前に「当たり前」のことを実践できるか

プロダクトマネージャーのやりがいとしては、プロダクトに自分の色を出すことができることですが、まずは市場環境とユーザーへ提供する価値を整理し、数値分析をどうやって行い、伸ばしていくかという当たり前のことが土台にないと、やっぱり足元がぐらつくと思います。

これだけまとめましたが、私も失敗の連続です。ただ、前進するしかやりようがないので、今回体系化できるようになるべく整理してみました。私は自分の組織で自分のノウハウを横展開していきたいと思います。