[ウェブエキスパートドラフト休止のお知らせ](https://webexpert-draft.jp/articles/92)

https://s3-ap-northeast-1.amazonaws.com/wdraft/blog/16c39544-345c-4f9f-9d71-9fe5b3ced169.png

去る6月7日、転職ドラフトが主催するイベント「Product Manager Party 〜 キャリア編 〜」を開催いたしました。ゲストにはSansan株式会社のCTO藤倉様と freee株式会社のプロダクトマネージャー坂本様。モデレーターにはプロダクトマネージャーカンファレンス実行委員長を務める関様をお招きし、盛りだくさんのコンテンツで大盛況に終わりました。本記事では、その一連の模様を余すことなくお伝えいたします。

こちらの記事はProduct Manager Party 〜 キャリア編 〜のイベントレポートの1/4記事目です。その他の記事は下記からご覧になれます。

プロダクトマネージャーに必要な3つのスキル(freee坂本様)
なりたいPM像から今の自分を見つめ直す(リブセンス松栄)
先輩PM3人に聞く!プロダクトマネージャーとしてのキャリアと成長(坂本様 関様 藤倉様 リブセンス内田)

最初の登壇者はSansan株式会社の藤倉様です。藤倉様には「Sansan におけるプロダクトマネージャの日常」というタイトルで、Sansanのプロダクトマネージャーが日々どういったことをされているのかをご紹介頂きました。

Sansan におけるプロダクトマネージャの日常

Sansan におけるプロダクトマネージャーの役割

この会場の中にはプロダクトマネージャーとして、これからやっていきたいという方だったりとか、既に活躍をされている方がいらっしゃると思います。その方々に意味のあることをお伝えできればなと思っています。

まずはプロダクトマネージャーの役割です。Sansanにおける定義ということなんですが、読んで字の如くプロダクト開発の企画立案とか評価、要するに開発をして、リリースするものが、どういう内容になっているのかということを管理していくような役割です。開発チームの中、当社はスクラムベースの開発プロセスをとっているので、スクラムチームにおけるPOに相当するのがうちのプロダクトマネージャーの役割かなとなっています。

ただ全社的な役割としては、最終的なプロダクトのオーナーは社長にしています。また、うちの社内ではチーフプロダクトオフィサー(CPO)という役割もあるので、彼らと議論をして調整をしながら現場で回していくというのがプロダクトマネージャーの役割かなと思います。またプロダクトマネージャーはものをリリースして終わりじゃなくて、作ってリリースをしたものを、マーケットや、ユーザーの目とか耳とかにどう届けるのかにも責任を持っています。

これが、組織的なイメージです。ごちゃっと人間のアイコンが並んでいるのが、一つのスクラムチームのイメージです。一つのチームには、プロダクトマネージャー、デザイナー、エンジニアがいます。エンジニアが平均で4名から6名ぐらいですかね。プロダクトマネージャーやデザイナを含めて、できれば最大8名で収まるようにチームを作っています。部門には総勢90名くらいいるので、これが10とかあるようなイメージです。上の方にはプロダクトオーナーやチーフプロダクトオフィサーがいます。

チームの分け方も、機能カットであったりマーケットカットであったりと、いろんな切り方をしています。Sansanの根源的価値であるような、名刺管理、共有の機能設計するチームとかスマホアプリの開発を担当するチームがあります。また、名刺管理のサービスからは想像しにくいかもしれませんが、メッセージ機能とかレコメンド機能もあります。Sansanの世界観を広げていくような機能に向き合っているチームが担当しています。市場別で言うと、グローバル向けの機能開発を行なっているチームもあります。日本国内でも必要な機能ですけれども、グローバルだと優先度が高いというようなものを開発するチームですね。

プロダクトのニーズと事業のニーズのバランス

プロダクトマネージャーが、日々どういう意思決定をしているかみたいなものを、参考になるかなと思ってもってきました。我々内部的にはプロダクトマップと呼んでいるんですが、こういうものを持っています。これは何かと言うと、プロダクトの企画がどういうプロダクト価値を実現するものであるというのを表しています。どのくらいのリソースをどの領域に使っているかということを見るためにも使っています。

例えばプロダクトのビジョンというのは、1年後や2年後にプロダクトがどうあるべきかという話から落とし込まれるようなものですね。一方で事業のニーズというのは今すぐに必要なものなので、優先度を考える上ではよく衝突するわけですね。事業ニーズだけに応えていたらプロダクトが成長しないので。

グローバルへの進出というのも、プロダクトというよりは事業としてのビジョン、欲求になりますね。あとプロダクトのニーズとは、性能改善とかUXの刷新とか、ソフトウェアとしてのニーズもあります。開発リソースを適正なバランスで、どこに、どれだけ向けているかということを考えるためにも内部的に作っています。

あとはプロダクトマネージャーが日々どんなイメージで働いているか。時系列で向かって左から右に流れているようなイメージなんですけれど、大小様々なプロダクトがあって、1人のプロダクトマネージャーと一緒に動くエンジニアがだいたい1チームだったら3名とか、5名くらい。2チームぐらい見てると、10名ぐらいになるので、並行してプロジェクトがガンガン回っているのを、常に順繰り、順繰り担当しています。

矢印の左側にあるような、課題の定義とかKPIの設計とか、結構時間がかかります。そのタイミングがかぶっちゃうと、自分のタスクが溢れちゃうし、開発チームが作るものがないなって状態になるので、自分がボトルネックにならないようにタイミングをマネージをしながらやっていくということをプロダクトマネージャーはやっています。だいたい1人につきいつもプロジェクトが平均4個とか、5個とか。多い人であれば、6個ぐらいは平均して回しているようなイメージかなと思います。

Sansan のプロダクト開発事例

具体例を1個だけ持ってきました。Sansanにはスマートフォンアプリがあります。名刺管理共有をプロダクトのコンセプトにしているので、基本的には名刺なんですけれども、そこにフィードという機能を追加しようという企画がありました。これは、実際、5月のゴールデンウィーク直後ぐらいにリリースしたんで、まだ1ヶ月も経ってないんですけれども、そのプロジェクトの実例を紹介したいと思います。

Sansanのフィードに出てくるのは気づきを与えるニュースです。例えば、私は今日リブセンスさんにお邪魔していて名刺交換をさせて頂きましたが、それをSansanに登録しておくとリブセンスさんのウェブにあがっているような直近のニュースであったりとか、もしくは社内で既にこの人と知り合いなんですよみたいな気づきを与える情報が表示されます。あと、社外から人事異動情報なんかも連携してもってきているので、あなたの知り合いの方が昇進されましたよみたいなニュースがでます。それを作ろうということで企画が開始しました。そして、スマートフォンアプリには、画面下部に機能のタブがあります。そこにフィードというタブを一番左に追加しようと、そんな話になったときの事例です。

そもそもなんですが、なぜフィード機能を作ろうと思ったかと言うと、当然事業の目標としては収益の最大化になります。我々はサブスクリプション型のビジネスなので、長く継続して利用していただければその分お支払いいただけるわけで、継続率はやっぱり重要な事業上の指標の一つになっています。継続率を上げてSansanのサービスを日々企業様の中で多く使っていただければ解約されないわけです。

全ユーザー数を分母にして、アクティブに使っていただいている方の割合をDAU率として指標にしています。このDAU率はいろいろな要素で構成されていますが、因数分解をすると、どれだけの頻度でアプリを使ってもらえているかが重要です。数あるKPIの中でもレバレッジが効きそうものを探した時に、スマホアプリは復帰率がまだ上がりきってないので改善の余地があると考えました。スマホアプリは移動時間中に使っていただくのがメインになるため、隙間時間に見てもらうにはニュースがが必要だったわけです。

開発前は、タブの機能は4つでフィード機能はありませんでした。ここにフィード機能を追加する時に、UXデザイナーとタブのデザインについて議論しました。
まずはデザインしてみようということで、作成したのがこんな感じです。全部で百種類くらいはデザインしました。最終的にデザイナーからは、これでどうだというのが挙がってきました。先ほどお話したように、フィード機能を追加しないといけないので、タブに追加しないといけないのですけれども、タブにある機能の数が増えます。

フィードを使っていただくのはもちろん重要なのですけれど、それ以上に名刺を撮影するっていう動線は重要です。そのため、真ん中にあるカメラアイコンのところの目止まりをよくしたい。Sansanアプリの中で重要なアクションに利用しているブルーを使った案がデザイナーから上がってきましたが、それでは成立してないだろうということで、最終的にはこの案に落ち着きました。強調しなければならないのでカメラのアイコンを一回り小さくして、塗りつぶしの領域を増やしたらどうだろうというようなことを、デザイナーと議論しながら、最終的な形をプロダクトマネージャーとして判断しました。

モックアップでは導線の細かな部分や画面のアニメーションまでは詰め切ってはいないので、開発期間ではそれらの詳細をエンジニアと毎日議論していました。そして、あと1ヶ月ぐらいでリリースできるというタイミングでは、新機能をユーザーの皆さんに伝えていく方法を考え始めます。ユーザー様とプロダクトの接点は複数あるので、その中でどう誘導していくのがいいのか、どういう温度感で伝えていくのかを考えます。最終的には、広報とも連携して、ニュースリリースをどういうタイミングで打つかとか、様々計画していきます。

プロダクトマネージャーの責任

リリースした結果、スマホアプリの復帰率が上昇して、一応の目標値は達成しました。Sansanにはウェブのアプリケーションとスマートフォンアプリケーションがあって、それぞれ利用されているユーザー層はあまりかぶっていません。そのため、ここで上昇したユーザ数がそのままSansan全体の利用率に上乗せることになり、大きなインパクトになりました。撮影機能の利用率は結果として下がりました。

撮影機能の利用率というのは、分母がアプリを起動したユーザー数、分子がその中で撮影機能を使ったユーザー数になっています。フィード機能を見るためにアプリを起動してもらうと、分母が増えます。ただしそのユーザの方々は、フィードを見にきてるので名刺撮影はしません。移動中には名刺交換をしていないためです。

当然の話しですが、KPIの設定としては間違えました。撮影機能の利用数は維持されていたのですが、目標値は絶対数にしておかなくてはいけませんでした。契約の開始から終了までの間でお支払いいただく利用料の合計のことを、ライフタイムバリュー、LTVと呼んで事業上の指標にしていますが、これについてはまだリリースしたばかりなので、これから計測していきたいと思っています。

プロダクトマネージャーの役割は、プロダクトの企画を考えてエンジニアと一緒に開発をしていく役割だということは理解されていると思いますが、そこには非常に大きな責任を伴います。

例えばプロダクトのコンセプトを作るというのは、プロダクトのブランドそのものを作ることと同じです。そこで失敗したら、その事業そのものを毀損することになるので、すごく重要な仕事をすることになります。また、エンジニアと一緒に開発をするということは数百万円単位の先行投資をしてるのと同じことです。それを日々判断しなければならないので、プロダクトマネージャーの責任は非常に大きいと思います。

一方で、開発チームはお金ではなくて人間です。仕事の流れとしては、関係者にきちんと説明をする義務があります。デザイナやエンジニアのみんなが納得をしてものを作れないと、それはやはりプロダクトマネージャーの責任になると思います。課題をきちんと言語化して、彼らに理解してもらえるように伝えて、最高のパフォーマンス出せる状態を作るということも、プロダクトマネージャーとして非常に重要な仕事になるので、チームビルドも意識しておかなければならないということも、付け加えておきたいと思います。

以上になります。ありがとうございました。

こちらの記事はProduct Manager Party 〜 キャリア編 〜のイベントレポートの1/4記事目です。その他の記事は下記からご覧になれます。

プロダクトマネージャーに必要な3つのスキル(freee坂本様)
なりたいPM像から今の自分を見つめ直す(リブセンス松栄)
先輩PM3人に聞く!プロダクトマネージャーとしてのキャリアと成長(坂本様 関様 藤倉様 リブセンス内田)

facebook
twitter
SIGN UP
SIGN IN


このサービスを友だちに薦めたいですか?