SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

ProductZineウェビナーレポート

組織にプロダクトマネジメントを正しく導入し、運用するには? 国内No1登山アプリYAMAPが失敗から学んだ作法

選択肢をとことん考え尽くし、データ分析を経てベストなものを決定

 続く「Decision Make」のスピーカーは土岐氏。YAMAPは無料で利用できるが、有料の月会費または年会費を支払うプレミアム会員制度も提供している。2021年の8月までに、8万人のプレミアム会員を獲得するという計画を立てた。そのために土岐氏らプロダクトマネージャーは、ほかの事業部門のリーダーたちと議論し、魅力的な特典の開発や特典のアピール、それから無料会員への機能制限を加えていくことを決定する。どんな機能制限を加えるかの意思決定にデータ分析が活用された。

 土岐氏は「ヘビーに使っている20%のユーザーにプレミアム契約をしてほしいと思っていました。しかし、実際の課金率は7.8%で、健全な課金モデルの設計が必要だと感じました。そのためには無料のユーザーにもしっかり使ってもらい価値を認識していただき、ヘビーに利用する際に有料の契約をしていただく流れを作らなければならないのですが、制限を多くすると価値が届かないですし、制限が少ないとビジネスが成り立たなくなります。このバランスを見つけるために行った意思決定の作法があります」と説明した。

あるべき状態と、実際の入会者数には大きな違いがあった
あるべき状態と、実際の入会者数には大きな違いがあった

 その意思決定の作法とは3段階あり、まずは、思いつく限りの機能制限をブレストし、次にデータ分析による予測をし、最後に分析では捉えられないメリット・デメリットを検討して決定する流れだ。土岐氏は「『思いつく限り』の目安として、私がイメージしているのが、1万通りは考えるというものです。実際には無理ですが、まずは全ての選択肢をひたすら考えました。データ分析では、各選択肢での対象者数の予測をします。例えば地図のダウンロード数を制限する場合、どのくらいの規模のユーザーが該当し、さらにどのくらいが契約するかを予測するのです。LookerというBIツールを使ってシミュレーションして分析していきました」と解説した。

 分析したデータだけでは意思決定を行わず、実際の使用感なども含めて徹底的に検討、ディスカッションをして決定する。また、なぜその結論に至ったかのロジックは必ず残しておくことが重要だという。こうして、地図のダウンロード数制限は月間2点までが妥当と決定され、プレミアム会員数増に貢献した。

適切なリリースには、関係者のバランスを保つマネジメントが重要

 「Deliver」のパートは大塩氏が担当。意識決定したアイデアをどのようにユーザーに提供する形にするかだ。適切なプロダクトマネジメントがなされない状態でリリースしてしまうと、だれにも使われなかったり、ネガティブなフィードバックが集まって炎上したりする恐れがある。

 大塩氏は「プロダクトマネジメントは“三点支持”をすることだと思っています。この言葉はクライミングではおなじみで、四肢のうち三肢で体を支えて、次の手がかりや足場に移動するための基本姿勢です。プロダクトにおいては、ビジネス目標、ユーザー課題、リソース・技術の3つのバランスで成り立っていると思います。プロダクトマネージャーがいないと、このバランスを保てず、ビジネスの成功が難しくなります」と説明した。

プロダクトマネージャーは〝三点支持〟をしてバランスを保つ
プロダクトマネージャーは“三点支持”をしてバランスを保つ

 ここで大塩氏は実際に“三点支持”ができなかった失敗談を話した。YAMAPで以前、ユーザーが登山で歩いた軌跡に、立ち止まったポイントを示す「休憩マーク」を記す機能をつけたことがあった。しかし、この機能はユーザーの反感を買い、「休憩しているわけではない」「希少植物の撮影場所が知られてしまう」「マークだらけで軌跡が見えない」といった意見が集まり炎上した。ユーザー課題を見誤り、求められていない機能を提供してしまったのだ。

 では、“三点支持”はどのように保たれるべきなのだろう。大塩氏は、ひとつの答えとしてPRD(Product Requirements Document/プロダクト要求仕様書)を挙げた。

大事なのは仕様の個々の項目ではなく〝三点支持〟が担保されている状態
大事なのは仕様の個々の項目ではなく“三点支持”が担保されている状態

 大塩氏は「特にここで大事なのが、ユーザー課題です。仮説がふわふわしたままプロジェクトが進行してしまうことがありますが、そうすると休憩マーク機能のときのように、ユーザーさんが求めてないものを定義してしまい、炎上のリスクが高まります。そこで、しっかりとユーザー課題をクリアしたほうがいいと3万人のユーザーアンケートを行いました。一つ一つの回答に目を通すのは大変でしたが、課題を整理したのです」と述べた。

 社内発のあいまいな仮説によるアイデアは、必要のない価値観の押し付けとなってしまう恐れがあるため、徹底した検証が必要だ。また、一部の声の大きいユーザーの意見に惑わされないよう、アイデアによって影響を受けるターゲットが広い場合は、調査も広範囲に行うべきだとした。

 PRDを適切に作ることで、“三点支持”を保てる可能性が高まるが、そこには細かなUI/UXの設計までは含まれない。大塩氏は「細かい画面の仕様はPRDに入れるのは難しいので、開発が走りだしたらみんなで磨きをかけていきます。みんなでディスカッションしたりですとか、ユーザーさんに使ってみてもらったり、または自分たちで実際使ったり。メンバー自ら山に登って新機能の検証もします。プロダクトマネージャーは意思決定の責任を持っていますが、『俺についてこい』と引っ張るよりは、できるだけメンバーのみんなに自由を与え、決定が必要なときに関与するといった距離感が大事です」と説明した。

 開発を担当しているエンジニアだけ、またUIの設計を担当しているデザイナーだけなど、特定のメンバーだけの評価は避けて、チーム全員が使い、同じ視点で議論できるようにするマネジメントが求められるのだ。

次のページ
組織内にプロダクトマネジメントを定着させるには? PMの権限の範囲は?

この記事は参考になりましたか?

ProductZineウェビナーレポート連載記事一覧

もっと読む

この記事の著者

森 英信(モリ ヒデノブ)

就職情報誌やMac雑誌の編集業務、モバイルコンテンツ制作会社勤務を経て、2005年に編集プロダクション業務やWebシステム開発事業を展開する会社・アンジーを創業。編集プロダクション業務においては、IT・HR関連の事例取材に加え、英語での海外スタートアップ取材などを手がける。独自開発のAI文字起こし・...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/14115 2021/05/14 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー