「サイバー流！ PMスキル場」連載VOL,5
里見 幸生（さとみ さき）
タップル PM
2019年に株式会社サイバーエージェントへ新卒入社後、タップルへ配属。2年間、プランナーとしてキャンペーンや課金率向上の企画・開発へ従事した後、新機能「ウィッシュカード」のグロースチームのリーダーに就任。現在はタップルのPMとして、機能のグロースのための企画立案から仕様設計、開発ディレクションまでを一貫して担う。
連載「サイバー流！ PMスキル場」 サイバーエージェントの各事業のプロダクトを担うPM（プロダクトマネージャー、プロジェクトマネージャー）達が、 「サービスフェーズ×ドメイン」で変化するPMの役割や経験談を語ります。
こんにちは。タップルでPMをしている里見と申します。
今回は、私がウィッシュカード機能のグロースチームのリーダーに就任してから、どのように機能をグロースさせたのかについて、経験談を交えてお話ししたいと思います。
「気の合う相手ともっとつながる」ウィッシュカード機能とは
まず、今期私がグロースに注力した「ウィッシュカード」機能についてご紹介したいと思います。
「ウィッシュカード」とは、やりたいことや行きたい場所を表すカードです。ユーザーはカードをプロフィールに追加したり、特定のカードを追加している人を検索したりすることで、気の合う相手とつながることができます。
従来より、タップルでは「趣味でつながる」をコンセプトに様々な機能を提供してきましたが、タップルならではの「気の合う相手とつながる」マッチング体験をさらに強化すべく、2021年5月にこちらの「ウィッシュカード」機能がリリースされました。
また、機能のリリースと同時にサービスの顔となるアプリアイコンの変更や、プロダクトのカラーリニューアルも実施しており、「ウィッシュカード」機能を新生タップルの中核となる機能にしていきたいという想いも込められていました。
こうした背景で生まれた機能をグロースさせるという大きなミッションに、私がどう向き合ったかをお話ししたいと思います。
手探りなチャレンジと社内最多のメンバーを抱える責任
新しいミッションはこれまでと2つの点で大きく異なっていました。
①過去事例がなく、施策効果の予測が立てにくい
新機能「ウィッシュカード」にはまだ施策事例がなく、どの画面を改修すれば利用率をあげられるのか等、予測が立てにくい状況でした。
私がこれまで担当していた課金転換率を向上させるというミッションは、過去に多くの施策や分析が実施されていたため、事例をもとに戦略や施策の方向性をある程度考えやすかったのですが、今回の「ウィッシュカード機能」は手探りの中で実行していく必要がありました。
②社内最多の開発チームの体制
先述したように過去事例もなく不確かなチャレンジの中、チームメンバーは社内最多の人数がアサインされました。ウィッシュカード機能をいち早くプロダクトの中核機能に育てるためです。
従来、タップルでは同職種（PM，iOSエンジニア，androidエンジニア，serverエンジニア，デザイナー）のメンバーが1名ずつのチーム体制が多い中、今回のチームは同職種内で約2名ずつアサインされていたため、チームメンバーの力を最大限引き出すために役割分担をより強く意識することが必要でした。
この2つの難易度に私がどう向き合ったかについてお話ししていきたいと思います。
スピード重視の開発で短期間で成果へ結びつける
過去の施策事例がない上に、初めは機能の利用者数も多くなく、ウィッシュカード機能に関するデータが出揃っていない状態でした。
そこで、データや知見を得るためにも、いち早く施策事例を作ろうとスピード優先で開発することを決めました。その中で、私が意識したことは下記の2つです。
・顕在化している課題は開発のリードタイムを短縮する
・仮説に基づいた施策は議論を深めるより検証で確かめる
チームメンバーと共通認識を持つことで開発のリードタイムを短縮する
チームリーダーへ就任後、まず初めにユーザビリティテスト(※)の結果をもとに機能のUXの改善を進めました。
※ユーザビリティテスト：実際のターゲットユーザーに機能を利用してもらい、操作感や機能設計に関する課題を発見する手法のこと
その際、テスト結果の振り返りや実施する施策の決定は、開発メンバーを交えてワークを行いながら進めていきました。どんなことをやるのか、どういった理由でやるのかをチームメンバーと議論し、実施背景や施策の意図をすり合わせながら決めることで、簡単な施策ならオリエンテーションや詳細な仕様書がなくても、開発メンバー主導ですぐに進めてもらうことができます。
▼実際のワークの図
①ユーザビリティテストを通して発見した改善点を重要性×時間(コスト)で4象限に分ける
②①で「重要性が高く、時間(コスト)がかからない」へ分けられた改善点の内、どのステップから取りかかるべきかまとめる
仮説を深追いせず、短期間で成果へつなげる
仮説をもとに進める施策に関しては、とにかく検証を回してユーザーの反応を見ることに徹しました。当時のデータや知見がない状況においては、どれだけ議論を重ねても仮説に確証を持つことが難しいからです。
特に上記のような言葉の印象の違いやデザインの見え方による違いは、議論を深めても確実な正解にたどり着くことが難しいため、いち早くリリースしてユーザーの反応を見ることが適していると考えています。
実際に発案から3週間という短期間で、文言の検証では利用ユーザー数が30%増加し、モジュールの配置の検証では、パターンBにおいて、他の機能の利用率を低下させることなく、特集モジュールの利用ユーザー数が50%増加するなど、大きな成果を残すことができました。
最適化された役割でチームとして最高の成果を出す
新しいチーム体制は従来に比べてチームの規模が大きく、開発メンバーのリソースを考慮すると、これまでの2倍以上のスピードで企画や仕様設計を進める必要がありました。
そこで意識したのは、職種間の役割と同職種内の役割の分担です。
まず、エンジニアリーダーには施策ごとのアサイン調整や開発のサポートを、分析担当のメンバーにはそれぞれの施策の検証設計を主体で進めてもらいました。PM自身が企画に集中できる環境を作るためだったのですが、それぞれ専門性の高いメンバーに任せたことで、エンジニアメンバーの伸ばしたい技術スキルに寄り添ったアサインや、リスク考慮の漏れが少ない検証設計など、結果的にこれまでの私主体の進め方ではできなかったことが実現しました。
また、PMも2名体制だったため、PM間での役割分担もチーム運営における重要なポイントです。
基本的に、仕様策定や開発ディレクションなどの実行部分は全て後輩PMに任せ、私はチーム内の開発環境を整えることに注力しました。他チームとの連携やトラブル時の対応に関しては、組織内での経験が比較的長い私の方が適任だと考えたためです。
今回のチームにおけるPMの役割として、戦略や企画の立案に加え、私が意識したことは下記の3つです。
・他チームとのリソースやスケジュール調整
・トラブル時の再発防止対応
・KPTや1on1を通したチーム内開発フローの改善
こうして役割分担を明確化、かつそれぞれの役割を得意なメンバーに任せることで、従来の2倍以上のスピードで施策を打ち続けることができました。
施策ごとに開発規模が異なるため、単純比較は難しいですが、前任チームでは4ヶ月半で11施策のリリースだったのに対し、今回のチームでは3ヶ月半で2倍以上の27施策をリリースすることができました。結果、新機能の利用ユーザー数は3ヶ月半で約8倍に増加し、ウィッシュカード機能はサービスのコンセプトを伝える中核機能として育ちつつあります。
「組織を軸に」開発のあり方や自分の役割を定義する
今回私が記事にまとめた開発の進め方やPMの役割はあくまで一例です。
PMはサービスフェーズやドメインだけでなく、ミッションやチームの規模によっても柔軟にやり方を変えられるスキルが求められると考えています。なぜなら、1つのサービス内でも様々な性質や期間のミッションがあり、それぞれ相性の良い進め方が異なるからです。
タップルはサービスの提供を開始してから今年で7年目を迎えます。プロダクトとしては成熟期に入りつつあるとも言えますが、より良い価値提供のためにサービスの運用や大型機能の開発を絶えず続けています。
そのため、タップルには様々なミッションが存在しており、特定の機能の運用を担うチームでは、設計→開発→検証までのPDCAサイクルを素早く回し、いち早く目標達成へ近づけることが求められたり、ユーザーの体験を革新的に変える中長期規模の新機能開発を担うチームでは、ユーザーのニーズを見極めるために企画設計に入るまでに入念なリサーチが求められたり、とミッションの性質や期間によって適した進め方は大きく異なってきます。
また実行体制に関しても、ミッションに適した規模のチームが組織されるため、その都度チーム内で求められる役割が異なってきます。
特定のスキルだけを磨くのではなく、自分のミッションが組織の中でどういった位置付けであるかを正しく見極め、自分のスタイルを変えられるPMでありたいと考えています。
今回の記事を読んで、弊社におけるPMの役割や働き方が少しでも具体化されていれば幸いです。
＞連載Vol,1 「ABEMAのプランナーからPMへ転向した話」
＞連載Vol,2 「入社1年目の新米PdMが大型機能をリリースした話」