PM memorandum

Product Managementにまつわる記事をポストします。twitter: @kyosu_ke

株式会社メルカリを退職しました

これはなにか

いわゆる、退職エントリと言うやつである。

先日、約2年と6ヶ月の間勤めた株式会社メルカリの最終出社を終えた。

多大なる感謝と濃密すぎる2年半で、めっちゃ長文になったけど、ご勘弁を。

目次

  • なぜメルカリに入ったのか
  • メルカリでなにをしたのか
  • メルカリで得たもの
  • 内側から見たメルカリ
  • では、なぜ辞めるのか?
  • なぜそれをやるのか?
  • ぐちゃぐちゃした思いの中で、ひとつ明確に言えること
  • 最後に

なぜメルカリに入ったのか

メルカリに入る前は、サイバーエージェントで一貫してゲーム畑のPMをやっていた。

SFでのアメリカ支社の立ち上げ→大型ソシャゲタイトルの運用→自社IPタイトルの新規リリースetc.と、いろいろと経験を積ませてもらった。

きっかけはBizDevのミートアップだった。「ちっちゃいベンチャーヤマト運輸と提携、ってどんなマジック使ってんのよ?」くらいの、ほぼ冷やかしと言っても過言ではない気持ちで参加したミートアップだった。

そこから「業務理解のための面談」を重ねて、気がついたらオファーを頂いていた。

元ウノウ・ジンガ→某チケットフリマの創業メンバーの友人が、最後のひと押しとして「今のメルカリには今しか入れないよ」的な、何かを言っているようで何も言っていないような、しかし僕にぶっ刺さった深イイ言葉をくれて、決断した。

とはいえ、自分のジャッジなので、そこは自分で考えて決めており、当時のノートを見返すと、こんなことを考えつつ、US市場に再挑戦するための意思決定していた。

f:id:kyosu-ke:20190214220345j:plain
よくわかんないけど、いろいろ考えた風味

当時、新卒採用時に自分をアメリカ配属にしてくれた担当役員の方が退任されており、海外市場へ向けたサービスに挑戦する機会は減っていた。

帰国してからは、「まずは地力を上げて、いつか来る大リーグでのバッターボックスに備えよう」という気持ちで一生懸命素振りをしていた。

しかし、当たり前のことだが、素振りをしていても、大リーグでホームランを打つことはできない。

その理由はシンプルで、打席に立っていないからである。

メルカリでなにをしていたのか

メルカリでもまた、US担当→JP担当→話題のメルペイ関連業務と、大変にいろいろな機会を頂き、最終的にメルカリUSで9ヶ月、メルカリJPで1年と9ヶ月の期間を過ごすことになった。

それぞれのステージで、これまでのモノの考え方が、いい意味で覆される経験をし、躓くたびに、「なにくそ」という気持ちとともに知的好奇心、探究心が満たされる2年半だった。

アサインは念願のメルカリUS

転職時の思いもあり、もちろんメルカリUSのアプリを担当するプロダクトマネジャーとしてメルカリに入社した。

f:id:kyosu-ke:20190214025824j:plain
入社初日に撮ったエントランス。タイプロゴが旧ロゴ

当時はほとんどのリソースをUSアプリに振り切っており、僕も東京オフィスから、USアプリを開発するチームへの配属となった。

余談だが、入社の翌日にメンター兼上長がKR0案件(全社プライオリティトップの超重要案件)にアサインされ、「明日から1ヶ月アメリカ出張になったから、あとよろ!」って感じで放置プレイ セルフOJTの機会をいただき、これがGO BOLDか(そうじゃない)と思ったことを覚えている。

メルカリUSでは、検索周りの改善、オンボーディングの改善、アプリの下タブ化(ハンバーガーメニュー→タブバー)、ホーム改修、ファセットを利用した絞り込み検索など、様々なチャレンジをさせてもらった。

この頃は今以上に技術の「ギ」の字もわかっておらず、多くのひとに迷惑をかけながら仕事をさせてもらい、根気よく教えていただいた結果、今の自分がある。

f:id:kyosu-ke:20190214024830j:plain
JP アプリの下タブ化に先行すること丸2年、USは下タブ化されていたのだ

メルカリJPへの異動

そこからJPへの異動が決まり、メルカリチャンネルの0→1の立ち上げ、スマートフォンに特化したカタログ出品や、検品業者を挟んだ新取引スキーム「あんしんスマホサポート」、決算説明会で取り上げられたカテゴリーグロース戦略の一端を担うなど、ここでもあげるとキリがないほど機会を頂いた。

特にメルカリチャンネルは上海出張から帰国するやいなや、企画→デザイン&仕様策定→開発→ QA→リリースまで含めて全行程2.5ヶ月でリリースしており、タレント起用の大型プロモーションも仕込んであり、スピードもクオリティも求められるプロジェクトだった。

f:id:kyosu-ke:20190214010844p:plain
※本当に最高のプロジェクトだった

引用元: 本日夜10時~「ガイアの夜明け」でメルカリの舞台裏に密着! #メルカリな日々 2017/10/10

また、スマートフォンのプロジェクトでは、自分の未熟さから、企画から0スタートをしなおすという失敗もあり、学びが多かった。

もともと、個人最適を突き詰めたい宗派に属しているのに、なぜか全体非最適が許せない性格で、障害対応やら、組織の狭間におちるルーズボールを拾って過ごしていたら、社内に関わる人も増えてきて、気づくと最後の9ヶ月はマネジャーとして過ごしつつ、メルカリ本体の数字を伸ばすチームと、メルペイをメルカリに組み込むチームのマネジャーを兼務していた。

ここでも見える世界がぐっと広がり、自分でも施策を持ちつつも、チームのスループットを上げる思考に時間を割くようになった。

メルカリでのマネジメントの経験を通じて、当然様々な学びを得ることができたが、書けないことも多いのと、さらにものすごく長くなるので割愛。

メルカリで得たもの

USチーム、JPチーム両方での経験を通じて、この記事であげたような、プロダクト・サービス・カスタマーに向き合う姿勢を学んだ。

kyosu-ke.hatenadiary.jp

このブログでの発信含め、これらはほぼ全てメルカリで得たものと言っても過言ではない。

日々発生する、BIチームとのやりとりからは、どうKPIを扱い、どう課題を設定し、解決策にアプローチするか、といった問題解決の基礎的な部分を学んだ。

このBIチームと問題解決を通じて、その考え方をINPUTし、また別の課題でOUTPUTしてフィードバックを得るというループはPdMにとっての最大の福利厚生であったと思う。

特に、この記事のお二人にはめっちゃ学ばせてもらった。メルカリでこの2人と働くと、企画者としての第三の目が開眼するので超絶オススメ。

一緒にモノを作る大切な仲間である、エンジニア、デザイナー、QAのみなさんからは、ものづくりの楽しさ、お客様に触っていただけるモノを世に出すことの、苦しみ・喜び・楽しさを教えてもらった。

f:id:kyosu-ke:20190214025131j:plain
ほんとに愛しかない。

また、プロダクトチームの良さがフォーカスされて伝わりがちだが、むしろそれ以外のPR, CS, リーガル, 人事, BizDev, マーケ, ファイナンス その他のコーポレート部門の仕事こそ神がかっていて、「プロダクト以外の面でのサービスの伸ばし方」のベストプラクティスを学べたのは今後の大きな資産である。

内側から見たメルカリ

人材のブラックホールと呼ばれているだけあって、各職種でトップクラスのプロプレイヤーがたくさんいる。 そういった人たちと働くのは本当に楽しく、吸収するものが非常に多い。

本来USをやりたかったのでJPに異動になったとき「転職時の本来の目的とズレるし、モチベーション続かないのでは…」と一瞬危惧したのだが、そんなものは全くの杞憂で、非常に楽しく学び続け、気づいたらUSへの拘りは小さくなっていた。

それくらい、毎日が楽しいのである。

組織の特徴として、よく挙げられる点だが、やはり下記は外せないし中から見ててもそのとおり。

  • 風通しがよく、積極性と論拠がしっかりあれば、のびのびとなんでもやれる空気がある
  • プロダクトを愛し、お客様のほうを向いている人が多い
  • 年齢層も比較的高めで、落ち着いて仕事に集中できる
  • 働き方もフレキシブルで、子持ち家庭にとってかなり働きやすい

控えめに言って最高な環境だった。

では、なぜ辞めるのか?

なぜそんな最高の環境にいながら、辞めるのか。

ズバッと一言で理由を言い切るのは難しいのだが、次の挑戦として、医療ドメインでVertical SaaSを提供する会社、株式会社ドクターズプライムを友人と共に創業した。

救急車のたらい回しをなくすサービスで、救命救急の領域で病院と医師をつなぐ橋渡しを行う、SaaSプロダクトを提供する。

医療領域のバーティカルSaaSで、プロダクトの類型としては、マッチングプラットフォームに分類される。

広義での医療系スタートアップはたくさん出てきているが、「医療」と一口に言っても、ドメインをよく見ると、DNA解析、創薬、ヘルスケア、予防医学、遠隔診療、電子カルテ、診断領域と切り口は様々である。

救急救命の現場もまた、解決すべき課題が多く、構造的な問題により、失われている命があることは否定できない。

なぜそれをやるのか?

ソーシャルゲーム → CtoCマーケットプレイスと来て、なぜ救命救急のSaaSを創業するのか?

うまく言葉がまとまらないのだが、いくつかの理由がある。

2人の祖母の死と病

先週末、母方の祖母の三回忌があった。

2年前の2017年の2月、アメリカ出張中に、母から電話で話したいという旨のLINEが来た。

当時SF市内にあったオフィスで、ユーザーインタビューを終えた後に電話をかけると、母方の祖母が亡くなったと聞かされた。

急遽、帰国して最後の別れを告げた。

そのときに、人はいつか死ぬ、という当たり前のことを理解した。

また、時を同じくして、大学を卒業するまで一緒に暮らしていた父方の祖母が胃癌の宣告を受けた。

僕にとっては追い打ちをかけるような、急な知らせで、最終的に彼女は胃の殆どを切除し、情報の非対称性と無力さを強く感じた。

この経験に、人の死、命の有限さ、それを前にした無力さを突きつけられた。

パートナーの存在

一緒に会社を創業したパートナーがいる。

代表取締役を務める彼は、当時通っていた中高一貫校の同級生である。

青春時代を共に過ごし、のちに聖路加国際病院という、救命救急で有名な病院の救命救急リーダーを務めた後、医療系ベンチャートップセールスとしてビジネスの現場に立っていた。

彼と久しぶりに再開し、会話を重ねる中で、気兼ねせずに率直に話ができる間柄でありながら、自分のプロダクトを作りサービスを運営していく知識・経験と、彼の医療ドメインの知識とセールスの経験が、お互いに補完し合える関係性であることに気がついた。

僕は自然にしていると、他人を意識し、気を遣い、萎縮して、忖度してしまうような人間なので、ナチュラルに遠慮・気兼ねせずに思ったことが言える関係性には非常に助けられている。

メルカリでの体験と着想

最後に、メルカリでの経験も、この意思決定に影響を与えており、背中を押されている。

「モノを欲しいと思う【需要】に対して、モノを渡して対価を得る【供給】を、【直接マッチ】させる」というメルカリの仕組みを抽象化して考えると、救命救急の分野にも応用ができることに気がついた。

メルカリというサービスの企画・運営経験が、自分のプロダクト・サービスの輪郭をはっきりさせてくれたと言える。

また、運良くメルカリ上場の瞬間に立ち会えており、全員が一体感をもって生み出す、その熱量を目の当たりにして、このような組織と瞬間を自分たちの手でも作りたい、と感覚的に思ってしまったことも、この決定に少なからず影響を与えている。

ぐちゃぐちゃした思いの中で、ひとつ明確に言えること

入社の前からその先まで、とりとめもなく、長文を書いてしまい、ほぼ自分史みたくなってしまったが、メルカリは掛け値なしに素晴らしい環境で、先日リリースされたメルペイをはじめとして、仕込んでいる種もあり、これからも輝く場であり続けると思う。

「それでもなぜ辞めるのか?」という問には、きれいに回答できないのだが、ここまで述べてきたような色んな思いが綯い交ぜになって、こうなっている。

そんな中でも、明確にひとつ言えるのが、僕自身も30歳になり、3人目の子供が生まれようとしている中で、「はっきりとした形で世の中に対してポジティブな変化を起こすこと」を、自分自身に対して求める気持ちが強くなっているということだ。

世の中の構造を変え、人々の生活をより良くすることで、子どもたちの世代に対して、自分自身に対して、「自分たちの手で、世の中をより良い方向に変えた」と誇れる仕事をしていきたいと思っている。

最後に

一緒に働く仲間を募集しています!

職種としては、フロントエンドエンジニア、バックエンドエンジニア、デザイナーを募集しています。

サービスの状況としては、ベータ版としてローンチしているモバイルwebを中心に、プロダクトの磨き込みをしており、一通りの機能が整った段階でiOS/Android等のネイティブアプリを展開していく予定です。

すでに数十の病院さまと、数百の医師の方々にご参加頂いていて、現場のニーズも強く、手触り感のあるかたちで順調な滑り出しをしています。

技術スタック的にはこんな感じです!

Frontend

  • TypeScript
  • React
  • Almin
  • Sass
  • Webpack
  • Jest
  • Prettier
  • Yarn
  • Netlify

Backend

Programing Language

  • Go

Public Cloud

Logging, Analytics

  • Stackdriver Logging
  • BigQuery

Other

  • Serverless

少しでもピンと来た方は、まずは副業からでも良いですし、とりあえずお茶・寿司・肉でもOKですし、インターン募集しています。

そのほかの職種についても随時募集しているので、下記twitterのDMか、採用情報ページまでお気軽にご連絡ください!

twitter: @kyosu_ke

与えてもらった機会と、関わっていただいた皆さんすべてに本当に感謝しています。

めちゃくちゃお世話になりました!

こういう会社を作りたいと思える、最高の会社でした!!

ありがとうございました!!

f:id:kyosu-ke:20190214011820j:plain
メルカリでの最後の一枚

ものづくりのプロトコルの作り方と大切にしている29の価値観

これはなにか

プロダクトを作るにあたって私が大切にしている29個の価値観を列挙したものだ。

経験上、チーム内でものづくりの前提となる価値観が揃っていると無駄な議論が減り、物事が進みやすい。 私は「ものづくりのプロトコルを合わせる」という表現を使うが、これが合っていると、ものづくりが非常にスムースになる。

この記事ではどうやって、この「ものづくりのプロトコル」の作り方と、事例として私が大切にしている価値観を、自分用のメモがてら書き出した。

ものづくりのプロトコルの作り方

価値観の抽出の仕方

自分が大切に思う価値観を抽出する前提条件として、下記の目線で書き出している。

  • 自分の中で当たり前となっているものもすべて書き出す
  • プロダクトの定義は、プロダクト≒サービスとなるような広義の意味とする
  • プロダクトそのものでなくても、プロダクトに関係する領域であれば、広く書き出す
  • チームや組織のあり方は扱わない

ブラックボックスになっている価値観を可視化し、判断基準をあわせることが目的なので、言うまでもないように思えることのほうが、むしろ大切である。

また、組織論を含めると「プロダクトの意思決定の基準となる価値観」からズレてしまうため、扱わない。

どう決めるかよりも、決定の基準を揃え、スムースなプロダクトづくりを行うための「value」を揃えることが重要である。

※行動規範・判断基軸になるという意味では、組織におけるvalueの位置付けに相似する

すり合わせ&プロトコル

チームメンバー各自の大切にしている価値観を書き出し、すり合わせを行う。

人数規模によっては、中心人物の価値観をベースに、メンバーの声を聞きながら加筆修正を加えていく形でもよいだろう。

ゼロから立ち上げ、これからチームメンバーを集めるフェーズの場合は、先にチームで大切にしたい価値観を定義しておくことで、ミスマッチが防ぎやすくなるだろう。

プロダクト作りで大切にしている29の価値観

最後に事例として、私が大切にしている29の価値観をあげる。一度ですべて書きあげられるものでもないと思うので、今後メンテナンスしていきたい。

粒度やスタイルなど、作成の事例として参考になれば幸いである。

ユーザーファースト

  • 01. ユーザーにメリットのないアクションを取らせない
  • 02. マーケティング活動もユーザーメリット有りきで考える
  • 03. 運営・開発の都合をユーザーに押し付けない
  • 04. ユーザーに考えさせない
  • 05. ユーザーが受け身でも完結できるようにする
  • 06. とにかくシンプルに、わかりやすく直感的に
  • 07. 論理的な正しさ < ユーザーの感情面での正しさ
  • 08. ユーザーの期待値をコントロールし、ユーザーの期待を裏切らない
  • 09. 規約やルールで縛らず、自然とそうしたくなる仕組みを
  • 10. ユーザーに会いにいく

分析や狙いどころの考え方

  • 11. 穴の空いたバケツに水を入れない
  • 12. すべては検証
  • 13. 分析は意思決定を行うためにある
  • 14. 主観と客観を分離して考える
  • 15. ファクトの上で議論する
  • 16. 相関で短絡せずに因果をさぐる
  • 17. データで証明された命題の成立理由を言語化する
  • 18. Vanity Metrics < Actionable Metrics
  • 19. Squeeze Toyの概念: ひとつずつフォーカスする

施策の考え方

  • 20. オペレーションありきの成立は成立ではない、仕組み化する
  • 21. オペレーションは尊いが、オペレーションに逃げるのは悪
  • 22. 小さく検証してから仕組み化する
  • 23. すべての方針や仕様に狙いを持つ
  • 24. ソリューションを考えるのはユーザーの仕事ではない
  • 25. 成功するか学習するか
  • 26. まず最速で価値提供して、プロダクトの価値を感じてもらう
  • 27. 最小単位でリリースして、とにかく届けてフィードバックを得る
  • 28. 体験としての早いは正義
  • 29. 仕様のひとつひとつに優先度をつけ、いつでも切れるようにする

まとめ

ステークホルダーの多いプロダクトづくりでは、前提の価値観が揃わないことによる無駄なコミュニケーションや議論が、プロダクトの速度を落としていく。

この枠組を利用して、意思決定の前提となる価値観を可視化し、すばやくユーザーに価値を提供していきたい。

PdM職の細分化 3つのロール

これはなにか

Product Manager Advent Calendar 2018の16日目の記事です

この記事は、定義が曖昧なPdMという職種の役割を、構造的に分解した記事である。

ソフトウェアエンジニアに様々なサブカテゴリーがあるように、PdMも細分化されたサブカテゴリーがあると考えており、本記事ではPdMのサブカテゴリーを構造的に分解する。

なお、ハード面への言及に限定し、リーダーシップなどソフト面については扱わない。

誰に向けたものか

この記事はこんな方に読んでもらうことを想定している。

  • PdMらしき仕事をはじめた駆け出しの企画職
  • PdMを育成する立場になった新任マネジャー
  • 役割に合うPdMが採りたい採用担当者

解決したいことと目的

この記事では、職種としての全体像が不透明なことに由来する、下記を解決することを目的としている。

  • PdMという職種にどんな方向性があるかわからなく、将来設計やキャリアの指針が定まらない
  • いまの業務が全体のどこに位置するかわからなく、徒労感がつのる

前置きが長くなったが、本編に入る。

PdM職のロールマップ

PdMをロール別に3つのサブカテゴリーに分解し、企画のバリューチェーンの上流から下流までマッピングすると、下記の図のようになる。

また、ここでは企画に関連する他専門職種についても、その相対的な位置を示している。

f:id:kyosu-ke:20181216110857j:plain
横軸に3種のロールをおき、縦軸に企画の進行過程をとる

ロールは3種あり、詳細は次項目以降で詳述する。

企画のバリューチェーンは、調査分析〜リリースするまで、企画の流れを上から下にマップしたものである。

また、企画のバリューチェーンについては下記の記事に詳しく書いている。興味のある方はこちらからどうぞ。

kyosu-ke.hatenadiary.jp

また、役割を便宜上3つの職種ラインに分けているが、実際の現場では複数の役割を兼ねて働くことのほうが多いため、一人のPdMが必ずしも一つの役割しか持たないというわけではない。

PdMの3つのロール

ここからは、前出の図に則って、PdMの3つのロールについて詳述する。

機能プランナー | Feature Planner

このロールは新規機能の追加、既存機能の改善、など機能を企画する役割だ。

新規アプリの立ち上げもこのロールに含まれる。 PdMといって、真っ先に思い浮かぶのはこの役割だろう。

具体的には、ユーザーの課題やニーズを捉え、その課題やニーズに対して、適切な解法として機能を考えて、ユーザーに届けるところを担う。

アプリ内マーケター | In-App Marketer

このロールはサービス内でのキャンペーンやコミュニケーション設計を企画・実行する役割だ。

具体的には、ポイント配布キャンペーンやセール等のインセンティブキャンペーンや、Push通知やお知らせ配信などのノンインセンティブコミュニケーションを中心として、ユーザーセグメントに応じた適切なコミュニケーションを図ることを担う。

コンテンツマネジャー | Contents Manager

このロールはサービス内のコンテンツを更新、拡充させていくことを担う役割だ。

具体的には、オウンドメディアの運営や、メディアであれば記事の編集、動画系サービスであれば番組企画などを担う。 ECサイトでのトレンドランキングやメルマガ運営や、CGM系のサービスであれば、コンテンツを投稿してもらうためのトピック運営などもここに該当する。

3つのロールと企画工程によるタスクマップ

ここまで、ロールマップの説明を展開してきたが、これらの理解をベースにもう一歩、構造化を進める。

PdMの業務は3つのロール x 企画工程でマッピングすることができる。(※図内の①〜⑨はイメージを掴むための一例である)

f:id:kyosu-ke:20181216213441j:plain
PdMのタスクは3つのロール x 企画工程によるマッピングで定義できる

企画工程はシンプル化するために3つにまとめているが、任意の切り方で捉えて構わない。

そして、このマッピングを利用して、下記の3点を考えることができる。

  • [過去]これまでの業務経験は、マップのどこを埋めるものだったのか?
  • [現在]いま取り組んでいる業務は、マップのどこに当てはまるのか?
  • [未来]これからどんな業務を選択し、マップのどこを埋めたいのか?

今後どういった方向を目指すのかを考えた上で、このタスクマップを使うことで、これまでの経験を棚卸しし、いまの業務に意味を与え、今後の業務選択の指針を作ることができる。

こういった整理により、曖昧で見通しの立ちにくいキャリアイメージを構造的に捉えることができるのではないかと思う。

キャリアパスのあり方

最後にほんの一例に過ぎないが、キャリアパスについてまとめる。 上述のPdMの3つのロールでの経験を積んでいくと、掛け合わせで新たなキャリアパスが見えてくる。

1/ グロースハッカー | Growth Hacker

上記の分類に従えば、アプリ内マーケターとしての経験および、機能プランナー、コンテンツマネジャーとしての企画設計の経験が必要なキャリアであろう。 加えて、ユーザー獲得マーケティングの経験もあると立体的に業務が遂行できるだろう。

2/ UXデザイナー | UX Designer

機能プランナーを経て、定性調査への適正や興味が強くある場合、ユーザーニーズを紐解き、それを実現する設計に注力するためにUX Designerになるという道がある。 ユーザー体験を作るために、インターフェース設計が必要になる場面が多いので、ユーザーインターフェース(UI)への深い理解と経験も必要になる。

3/ プロダクトオーナー | Product Owner

プロダクトのすべてを司る "Mini-CEO"としての役割である。 プロダクトによって必要度合いの濃淡はあれど、このキャリアのためには、前述のPdMの3ロール全領域に精通する必要があるだろう。 またそれだけではなく、オペレーション構築・最適化、事業計画・会計、組織開発・採用等も重要なため、それらの知識と経験も同時に必要になる。

まとめ

エンジニア、デザイナー、会計、マーケティング、リーガルなど他職種は学問として存在するが、PdMには学問が存在せず、俯瞰して体系的に全体像を学ぶ機会は少ない。

私自身が暗闇の中を進む中で、手探りで描いてきた地図であるが、だれかの役に立つと幸いである。

プロジェクトマネジャーからプロダクトマネジャーへの転向に必要な3つの変化

これはなにか

本記事はプロジェクトマネジャーがプロダクトマネジャーに転向する際におさえるべき重要な点をまとめたものだ。

私自身、プロジェクトマネジャーからプロダクトマネジャーへと転向しているが、その際にいくつか重要なポイントが存在した。 この記事が、同じようにプロジェクトマネジャーからプロダクトマネジャーへ変わったばかりの方や、これから転向しようと思っている方の助けになれば幸いだ。

以降、プロジェクトマネジャーをPjM、プロダクトマネジャーをPdMと略称表記する。

PdM は PjMの延長線上にはない

f:id:kyosu-ke:20180916000545j:plain

字面が似ているせいか、「PdMはPjMの延長線上にある」と考えている方も一定数いると思う。(私自身そう思っていた)

しかし、そうではない

共通する部分はあるが、PjMとPdMでは、それぞれの役割に求められるものが異なるため、転向する場合、3つのポイントについて大きく認識を改める必要がある。

  • 実行の担保 → 結果の担保
  • 管理・調整 → 方針・意思決定
  • 開発現場視点 → ユーザー視点

まずは、議論の土台となる、PjMとPdMそれぞれの役割について記述し、のちに各ポイントについて詳述する。

PjMの役割と主な業務

役割

PjMは割り当てられたリソースで期日までにアウトプットを出すことにコミットする役割である。 よって、プロジェクトの進行上の課題に対してのアクションがメインになる。

たとえば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つことになる。

  • 新規: プロダクトを期日までにリリースすることに責任を持つ
  • 運用: プロダクト改善施策を期日までにリリースすることに責任を持つ

主な業務

PjMの主な業務としては下記が挙げられる。進行の管理および調整ごとの占める割合が多い。

  • 開発進行管理
  • 仕様の調整
  • 工数アサインメントの調整

PdMの役割と主な業務

役割

一方、PdMの役割は、プロダクトが生み出す成果にフォーカスしている。 プロダクトをリリースした先にある「成功」を担保する役割である。

当然、一口に「成功」と言っても、定義がなければ判断がつかないため、「なにが成功であるか」を定義することも重要な役割の一つである。

例えば、新規プロダクトと運用プロダクトでは下記のようなミッションを持つ。

  • 新規: プロダクトがPMFに到達することに責任をもつ
  • 運用: プロダクト改善施策により目標KPIを達成することに責任を持つ

主な業務

よって主となる業務としては、方針決定・意思決定が中心になる。 また、意思決定を行うにあたり、必要な情報を集めるための分析も広義として当てはまる。

  • 戦略方針の決定
  • 仕様の策定
  • 分析・振り返り

3つのポイント

前置きが長くなったが、ここからPjM → PdMに転身する際の3つのポイントについて詳述する。

f:id:kyosu-ke:20180915235438j:plain

実行の担保 → 結果の担保

5W1Hでたとえるなら、When, HowからWhat, Whyへの視点の変更である。

PjMは担当しているプロジェクトを期限内(When)に限られたリソースで(How)させることに責任がある。 一方PdMは担当プロダクトの成長に責任があるため、実行だけでは役割を果たせない。

実行レベルから業務領域をストレッチして、実行の前段階に存在する、なにをやるのか(What)、そしてそれはなぜか(Why)を明確にしなければならない。 また、最後にその結果がどうであったのかを分析により確認し、次のWhat, Whyにつなげていく。

管理・調整 → 方針・意思決定

上記の責任領域の変更に伴い、帳尻を合わせや整理からロードマップ作成、製品仕様の意思決定にウェイトをよせる必要がある。

PjMであれば、進行に問題が合った場合に、仕様のスコープ削減を提案したり、リソースを要求するなど、整合性が取れない部分の最終意思決定をエスカレーションできる。

一方でPdMになると、そのエスカレーションを受けて、意思決定を行う側になり、理想と現実のギャップに対して、最終的な結果責任を引き受ける役割を担う。

開発現場視点 → ユーザー視点

PdMはより視点をユーザーにフォーカスさせる必要がある

PjMの視点では、いかに期待された機能を、期待された期日に出すかという視点になるため、最終的には期待値を調整することで整合性を保つことができる。( ex. 仕様のスコープを削ってもらう、リソースを追加してもらう、期限を延ばしてもらう)

よって、要求仕様とリソースがマッチしない場合に、収めることを優先して考えるインセンティブが働きやすい。

一方、PdMの視点では、ユーザーに届ける価値が全てとなるので、開発している機能の中心的な価値がなにかを見極め、仕様削減や必要に応じたリリース延期等の意思決定を行う必要がある。 「収めること」ではなく「どんな価値を届けるか」にフォーカスする必要がある。

PjM から PdMになるには

ではPjMからPdMになるには、具体的にはどうしたらよいのか?

主に3つのパターンがある。

  • 1) 急拡大中の組織に入る
  • 2) 新規立ち上げの組織に入る
  • 3) 既存のチーム内で転向させてもらう

1) 急拡大中の組織に入る

急拡大中の組織では、関わる人が増えていく中で、ステークホルダーをまとめ上げながら、実行を推進する力が重宝されるタイミングがある。

また、業績がよく、急拡大している組織であれば、やることが山程ある状態が想定されるので、ポジションへのニーズが強い可能性がある。

2) 新規立ち上げの組織に入る

設立間もないスタートアップ等の組織の場合、人材ニーズによっては近接領域であるPjMからPdMへ転向するチャンスが開ける可能性がある。

採用力のある組織の場合は、PdM経験のある人が採用できてしまうため望みは薄いが、一般的なスタートアップであれば道はあるはずだ。

3) 既存のチーム内で転向させてもらう

自社内や既存チームであれば、PjM業務で組織内の信頼・評価を重ねることで、チャンスを掴める。

所属する組織のカルチャーにもよるが、可能であればこの選択肢が一番無難とも言える。 なぜなら組織内評価を引き継ぐことができ、これまでのステークホルダーとの関係値をもとに成果を上げやすい状態で始めることができるからである。

まとめ

PjMとPdMは似ているようで、実は全く異なる役割を担っており、転向する際には大きな視点の変更が強いられる。

また、PdMはPjMの延長線上にはないため、転向を目指す場合は戦略的に行動を起こす必要があるといえる。

企画の議論が噛み合わなくなる4つの要因

これはなにか

企画会議などで施策の議論を行う際に、議論が噛み合わないことの要因を4つにまとめたものである。

上長、メンバー、メンター、メンティー、同僚、他部署など、バックグラウンドや立場が異なる人と議論をする際に「なぜそういう結論になるのか?」「そうですね…(話が全然伝わらない)」といったような議論が噛み合わない瞬間が発生しうる。そういった状況の背景に、なにが潜んでいるかを分解した。

PMという職種は他職種に比べて、業務に占めるコミュニケーションの割合が多くなる。この分解が今後の議論に役立てば幸いだ。

議論が噛み合わなくなる4つの要因

『議論が噛み合わない』とはなにか

通常、議論は参加者の主張から始まり、反駁を通じて論理を積み上げて、最終的にひとつの結論にたどり着く、という形で終了する。

ところが、論理的に積み上げていっても、収束せずに、お互いの主張が平行線のままで、結論に到達しないケースがある。 そのような場合、どちらか妥協をするか、次回の議題として解決しないまま終了をするということになる。

議論が噛み合わない要因

論理的な思考能力を持ち合わせているはずの、大の大人が複数人もあつまって、なぜこのような結末になるのか。

それは下記の4つの要因のどれか、ないしは複数が、その議論に当てはまっているからである。

f:id:kyosu-ke:20180819222518j:plain

今回は、議論が噛み合わなくなる要因を、『議論を開始する前後』x『知識・理解』という2軸をもとに、下記の4つに分類した。

  • 前提条件の違い
  • 事例知識の違い
  • 立場・目線の違い
  • 解釈の違い

以降、議論のすれ違いを生む、4つの違いについて詳述する。

前提条件の違い

議論の前提となる基礎情報を指す。

例えば、機能開発の議論であれば、解決すべき課題や、当該プロジェクトに掛けることができる期間や、投資できるコストなどがこれに当たる。

議論を始める前から決まっているものであり、議論の出発点、土台であるため、議論を始める前にすり合わせておきたい要素である。

事例知識の違い

過去事例や競合事例などの知識の量の差を指す。

これらの知識に差があると、事例知識の乏しい側から見たときに、議論の途中で論理の飛躍があるように感じられることがある。

議論の途中で、隠れた前提として、類似するケースや事例を前提・参考に議論が展開される場合に起こりやすい。

このケースを防ぐには、相手の中での成功体験や、よく使うフレームワークなどを理解することが肝要だ。

立場の違い

立場が違うことで、同じ事象を見ていても注目している要素が異なる場合がある。

例えば、担当者レベルでは会員登録数を見ているが、上長レベルではLTVを重視していて、結局はLTVによった議論が展開される場合などである。

このケースを防ぐには、すり合わせた前提以外にも別の論点が含まれていると感じた時点で、重要論点の整理を行うことが必要である。

解釈の違い

解釈の違いとは、事象の捉えかたの違いを指している。

同じ事象や数値を見ていても、人によって解釈に差が出てくる。

具体的には、ある数値を見たときに、その数値を大きいと見るか、小さいと見るかという違いや、複数のKPI間の重要度に関する見解の差などを指す。

「解釈の違い」以外3つの要因では、「議論の開始前」であるか「知識ベース」であったため、事前の対処ないしは、知識量の増加で対応できた。

しかし、この「解釈の違い」については、物の見方の違いであるため、双方のチューニングが合うまで、どこまでも平行線になる

※「価値観の違い」や「宗派の違い」とも言い換えることができる

双方のチューニングが合っていない状態においての議論は、最終的に「キメの問題」として処理されるか、お互いの違いを認め、どちらかの歩み寄りによって結論づくことが多く、短期的な解決は難しい。

まとめ

議論が噛み合わない場合は、大抵この4つのに当てはまっている場合がほとんどである。

建設的な議論を行うためには、「解釈の違い」以外の項目について極力事前に差分がなくなるように努めることが重要である。

一方で「解釈の違い」だけが議論の噛み合わなさの原因と言い切れるまで、議論を煮詰めることができていれば、最後はキメの問題として議論を進展させ、意思決定を行うことができるだろう。

PMの志向の3類型

これはなにか

PMが持つ志向を、大きく3つに類型化したものである。

各志向には特徴があり、企画の進行フェーズに沿って、活きるフェーズ、欠けやすい視点、フォローの方法が異なる。

読まれた方が、自分はどんな志向なのかを考えるきっかけになれば幸いである。

PMの志向の3類型

なにを重視し、どういった志向なのかは、ひとりひとり異なる。

それらの志向について、下記の3つの類型に大別した。

f:id:kyosu-ke:20180813033341j:plain

また、これらの志向は「どういったことに意識が向きやすい状態か」を表しているため、経験を通じて、変化していくものである。

よって、生まれ持った性質を表しているわけではない

なお、今回は単純化して類型化しているため、一部例外が存在しうる点を、ご了承いただきたい。

以降、3つの志向を詳述する。

開発志向

ものを作っていくプロセスに明るく、開発のプロセスに意識が向きやすい状態を指す。

特徴

元エンジニア、元Webディレクターといったバックグランドを持っている場合が多い。 テーブル構成やスキーマAPIのレスポンス、などの具体的なイメージを持つことができ、提案することがある。

活きるフェーズ、欠けやすい視点

「解法の選択」や「製品の実装」のフェーズが、その特徴を一番活かせるフェーズである。 また、「価値の検証」のフェーズでも自身で分析を進める力があるケースが多い。

一方、この志向単体だと、どこが課題でなにを解くべきかを決める「課題の選定」や、それをどう伝えていくかを扱う「製品の伝達」の視点が欠けやすい。

欠けやすい視点をフォローするには

データアナリストの協力を仰ぎ、「解くべき課題」を見つける部分を支援してもらうと良い。

データアナリストが存在しないチームの場合は「課題の選定」に強いPMに協力を仰いぐのもよい。

こちらの記事で取り上げたように、「課題の選定」はPMが担保しなければならない要素の中でも、最も重要なもののひとつである。

kyosu-ke.hatenadiary.jp

体験志向

ユーザーがどういった体験を得るかにフォーカスしやすい状態を指す。

特徴

ユーザーがなにに課題を感じていて、それをどう解決するか、ということが意識の中心にある。

ユーザーがその機能を必要とする背景から、その機能を触れるまでの流れ、および触れたあとの行動・感情の変化までの一連のストーリーを考える視点を持つ。

デザイナーとしてのバックグラウンドや、スタートアップのCEOなどプロダクトオーナーの役割を持っている場合が多い。

活きるフェーズ、欠けやすい視点

「課題の選定」および「解法の選択」に強く、企画の上流工程が、最もその特徴を活かせる。

一方で、この志向単体では、どう作っていくかという視点や、KPIと施策のひも付きを精緻に詰める視点を欠きやすい。

欠けやすい視点をフォローするには

Tech Leadの役割を担ってもらえる開発パートナーを見つけることが最も良いと考える。

Tech Leadというポジションやロールが正式に存在する組織であれば、Tech Leadを頼ると良い。

Tech Leadという役割が存在しない組織であれば、そのプロダクトに詳しく、自領域だけに閉じない視野の広さと、総合的に課題解決にあたれる視座の高さを持つ、開発者を頼るのが良い。

マーケティング志向

どうやってユーザーを動かすのか、ということに意識が向きやすい状態を指す。

特徴

マーケティング業務のバックグラウンドを持っている場合が多い。

ユーザーがなにを欲しているかを把握し、どういった魅せ方伝え方をすることで、ユーザーに行動を起こしてもらうのか、ということに意識が向いている。

活きるフェーズ、欠けやすい視点

その特徴から、「課題の選定」と「製品の伝達」のフェーズが、この志向が最も活きてくるフェーズである。

一方、この志向単体では、体験志向と同じく、どう作っていくかという視点に欠けることが多い。

また、「解法の選択」の面でも、なにを作るかの視点が弱くてインプットが少ない場合がある。

欠けやすい視点をフォローするには

体験志向と同じく、Tech Leadの役割を担ってもらえるパートナーを見つけることである。

また、なにを作るかの視点については、日々のインプットを増やすという中長期的な努力は重ねつつ、短期としては、引き出しの豊富な他のPMにアイデア出しに協力してもらうといった方法でフォローができる。

今後の見通し

組織の規模・状態やチームの体制によってことなるが、個人的には、今後は体験志向がより重要になると考えている。

ユーザーの体験が重視され、Tech Leadという役割の浸透を背景として、PMが解くべき課題を明確に定め、

  • なぜ必要か(why)
  • なにを作るか(what)
  • いつリリースするか(when)

という3点の精度をあげることに集中し、どう作るか(how)については信頼できるパートナーに任せる、という流れが強まるからである。

まとめ

PMの3つの志向について述べてきた。

それぞれの志向において、良い点や欠けがちな視点が存在するが、最終的に重要なのは、チームとして期限内に高いクオリティでアウトプットを上げることなので、周囲に協力を仰ぎ、最終アウトプットを高めれば良い。

また、これらは生まれ持った性質ではないので、意識的に志向を変えて新しい強みを習得することができる。 欠けがちな視点があったとしても、重心の置き方次第で、その視点を身につけることが可能である。

自分の志向を認識し、潮流に合わせてその志向を変えながら、足りない部分は補い合いながら、チームとしてのアウトプットを最大化することが重要である。

企画分析の4象限とPMに必要な分析力

これはなにか

企画にまつわる分析、およびその中でPMに必要な分析の種類についての、私見をまとめたものである。

前回、『「価値の検証」を構成する4つのステップ』で、企画のリリース後の分析についてまとめた。 上記の記事では、事後の分析のみにフォーカスしていたが、この記事にも書いたように、企画の前半のフェーズでも、分析を行うことが多いため、今回は企画のフェーズを横断して、「PMが担う分析」について書く。

kyosu-ke.hatenadiary.jp

また実際に、分析はどこまでやればよいか?どこまでの能力が必要なのか?どの程度のスキルがないといけないのか?といった質問を受けることも多く、その際によく話すことをまとめている。

なお、本記事で想定しているのは、分析担当のメンバーがいるチームを想定している。 よって、分析専任官などいないスタートアップであれば、CEOでもPMでもエンジニアでも強い人を中心に一丸となってやるしかないし、場合によっては分析に時間をかけること自体がが正しくないケースもあるため、本記事はあまり参考にならない。

企画にまつわる分析の4象限

企画にまつわる分析を、「施策実行の前後」、「分析の複雑さ」の2軸で分類する。 2つの軸の判断基準は下記とする。

  • 施策実行の前後:
    • 前=「課題の選択」や「解法の選択」フェーズ
    • 後=「価値の検証」フェーズ
  • 分析の複雑さ:
    • データ抽出の難易度、分析軸の多さ、統計学的知識の必要有無など

「施策実行の前後」を縦軸に、「分析の複雑さ」を横軸に取ると下記の図のようになる。

f:id:kyosu-ke:20180806024631j:plain

  1. 第一象限: 施策前に行う複雑な分析
  2. 第二象限: 施策前に行うシンプルな分析
  3. 第三象限: 施策後に行うシンプルな分析
  4. 第四象限: 施策後に行う複雑な分析

以降、第一象限〜第四象限について、詳述する。

1. 第一象限: 施策前に行う複雑な分析

プロダクト全体の成長戦略を描くような分析や、「nカ年計画」のような、個々の施策を束ねる根幹の戦略を作るための分析がこれにあたる。

f:id:kyosu-ke:20180806030039j:plain

また、そこまで規模の大きくないものとして、相関分析やヘルスチェック分析などもこの象限に含まれる。

どちらにせよ、分析を生業に生きてきたプロフェッショナルにお願いするのがベストである。 バックグラウンドが元データアナリストなPMで無い限り、この象限に着手するのは避けたい。

2. 第二象限: 施策前に行うシンプルな分析

簡単なファネル分析や、影響範囲の調査、対象者数の確認など「課題の選択」や「解法の選択」のフェーズで必要なデータの収集が該当する。

f:id:kyosu-ke:20180806030109j:plain

例えば、ECサイトで特定の導線の削減を検討している場合に、対象となる導線経由で発生している購入の件数および金額を調べるケースなどである。

また、別の例を上げると、チュートリアルやオンボーディングのフロー改善を行う場合に、各ステップでの離脱率を調べるケースなども該当する。

これらを抽象化すると、企画のおおまかなポテンシャルや、施策の仕様決定を行うためのデータなど、粗くても良いからクイックにデータが必要なケースで行う分析がこの象限にあたる。

そういったケースの場合は、PM自身がクエリを書いたり、BIツールなどを利用して分析ができると良い。 粗くともスピーディーにデータが必要な場面では他者と連携するよりも、さっと自分でデータを出せるほうが早くアウトプットにつながるためである。

3. 第三象限: 施策後に行うシンプルな分析

施策がリリースされてから数時間後、翌日レベルでの速報分析がこの象限に該当する。

f:id:kyosu-ke:20180806030124j:plain

リリース直後は、深い洞察や分析でなくともよく、多少粗くともスピードを優先してチームに共有を行うことが大切である。

なぜならば、チームは貴重な時間というリソースを使い、PMの立てた企画を実行に移しており、その結果がポジティブなのかネガティブなのか、またはジャッジにはもう少し時間経過が必要なのかなども含めて、知る権利があるからだ。

この場合も第二象限と同じで、粗くともクイックな分析が求められる。 よって他者に依頼するよりも、PM自身でクイックに分析できたほうが良い。

新しく追加した機能の分析を行う場合など、既存の分析ダッシュボードには当該機能の分析項目が乗っていないことも多くあるため、最低限のクエリやBIツールを駆使する技術を身に着けておくと良い。

4. 第四象限: 施策後に行う複雑な分析

施策をリリースしたあとに、その施策が良かったか、悪かったのかを評価するための本格的な分析である。

f:id:kyosu-ke:20180806030136j:plain

具体的には、リフト分析やABテストの分析などがあり、統計的な有意性のジャッジを求められるケースがあり、専門性の強い象限となる。

施策後にその結果の良し悪しを判断するという状況においては、スピードよりも、結論の確からしさや、メッセージの明瞭さが重視されるため、拙速な分析ではいけない。

この領域も分析専門のメンバーにお任せするほうがベターである。

まとめ

PMが関わる範囲での分析について「施策実行の前後」と「分析の複雑さ」という2軸で、4つの象限に分けた。

その中でも、精度以上にスピードが重視される、第二、第三象限のシンプルな分析をPMは扱う必要があり、その程度に合わせて、最低限の分析の技術を身につけておく必要があるだろう。