新しいサービス、アプリ、参加したカンファレンス、読んだ本についてなど気ままに書いていきます。

インターネット業界で働くディレクターの雑記

カンファレンス プロダクトマネージャー

プロダクトマネージャーカンファレンス2016レポート

更新日:

product-manager1

 

先日、日本初のプロダクトマネージャーの大規模カンファレンスが開催されて参加してきました。

http://pmconf.jp/

とても豪華なスピーカーと、400人という参加者ですごく盛り上がっており(テレビも入っていた模様)、各スピーカーの方のお話もそれぞれの会社のユニークなお話ばかりでした。
photo credit: Sebastiaan ter Burg Europeana Strategy meeting via photopin (license)

 

プロダクトマネージャーとはどんな仕事か?という記事を以前書きましたが、実際のところ他の企業ではプロダクトマネージャーはどのような役割なんだろう、どのように活躍しているのだろうと思っていました。

 

「プロダクトマネージャーとはなんぞや?」「プロダクトマネージャーの仕事は?役割は?」など、日本ではまだまだ曖昧な定義のプロダクトマネージャーという仕事に対して、各社で活躍されている方の考え方や行動や気を付けているところなどを聞くことができ、自分の今の仕事にも今後のキャリアにも活かせそうなお話ばかりでした。運営者のみなさまに感謝です。

時間の都合上、半分くらいのセッションしか参加できなかったのですが、その中でも特に面白かった&学びの多かった4つのセッションについて備忘録も兼ねてレポートします。

 

  1. 世界を変えるプロダクトマネージャーになるために(グーグル株式会社 製品開発本部長 徳生 裕人 氏)
  2. Product Team Management(Increments株式会社 CEO / Qiita:Team PM 海野 弘成 氏)
  3. メルカリ流グローバル開発の実態(株式会社メルカリ 執行役員 伊豫 健夫 氏)
  4. グローバル企業におけるプロダクトマネージメント(Niantic, Inc. Product Management Director 河合 敬一 氏、Increments株式会社 Qiita Product Manager 及川 卓也 氏)

 

世界を変えるプロダクトマネージャーになるために

Google株式会社 製品開発本部長 徳生 裕人 氏

サマリ

Googleの有名なプロダクトマネージャー6人に事前インタビューして、それぞれの「プロダクトマネージャーとは」のエッセンスを紹介。
プロダクトマネージャーはサービスによって役割が変わる。基本的には”その他全部"という感じだが、共通するスキルセットや求められる役割はある。
プロダクトマネージャーは、ビジネス戦略を踏まえて、何をどの順番でどうやってやるのか考え、サービスの成長に責任を持つ。
最終的にどうやってゴールにたどり着くのかを考え、ステークホルダーを巻き込みながら実行する

 

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

プロダクトマネジメントの考え方は、どのようなプロダクトでも同じ

  • User problem
  • Technology, Product opportunity
  • Resource
  • Deliver

どのプロジェクトもエンジニア1,2人からはじまり、増えていく
PMに定石はない、範囲が広くて何をやっているかわからないと言われることも
[Carsar's Basics] *Carsarはgoogleの有名なPM
Good product managers...

  • Are the domain, product and user expert
  • Grok technology
  • Craft and communicate the product

But a great product manager...Is an owner

簡単に訳すると、

良いプロダクトマネージャーは、その領域、プロダクト、ユーザーのエキスパートであり、テクノロジーを捉えて活用し、プロダクトをつくり発信する。

そしてすばらしいプロダクトマネージャーは、オーナーである。

 

Googleでは、あらゆる権限がプロダクトマネージャーにある。プロダクトマネージャーは言い訳をしてはいけないポジション。

 

著名人がよく使う引用みたい(有名なホッケー選手の言葉)

Creates clarity and has a plan.
I skate to where the puck is going to be, not where it has been -wayne gretzky

開発ロードマップを描く

  • Area1, 2, 3(領域) x 時間軸で考える
  • なぜこれをこの順番でやるのか考え書き出すことが重要(プロダクトマネージャーにしかできない仕事)

youtubeは「動画を見ている時間を増やそう」という決断をして、アルゴリズム含めてすべての意思決定の軸が決まった。

 

Use gravity for acceleration

  • 加速するために重力を使う
  • プランを作るときに、どんな外力を使って、どんなモーメントを利用して、どうたどり着くのか

youtubeは、カメラ、スマホ、SNSなど、そのときに出てきたテクノロジーを利用して、そのときにしかできないことをした
今chromeOSは、macbookよりの売れている(米国)
遠回りしてもいいから、最終的にゴールにたどり着くプランをつくる必要がある

 

Is the synapse for the team

  • 周りのアイデアを使って、つなぎ合わせることが重要

 

Is ambassador

  • 自分のプラン、プロダクトの魅力を発信し続ける
  • なぜこの機能よりもこれを先にやっているのか

 

Does whatever it takes

  • 必要であればなんでもやる

 

Manages stakeholders

  • ベンチャーでは、CEOとアラインする

 

googleでは米国で新卒毎年30-40くらいAPM(Associate PM)として育てる制度がある
→職能として明確に定義されている

 

 

Product Team Management

Increments株式会社 CEO / Qiita:Team PM 海野 弘成 氏

 

資料が公開されています。

https://speakerdeck.com/yaotti/product-team-management

 

サマリ

良いチーム=成果を出せるチームで、それは自律的なチームであるという軸の元、自律的なチームはどんなチームかという話。
製品開発は不確実生の高いイノベーション業務にあたるので、自律的なチームでないとできない。
自律的なチームに必要な要素は以下にある通り。情報共有やコミュニケーションは大事(Qiita teamおすすめ)

 

要点

良いチーム=成果を出せるチーム
→自律的なチーム(成果を出すためにはマスト条件)
不確実性の低いルーチン業務は、

  • マイクロマネジメント
  • 効率化
  • 深く掘り下げる

ことが有効
逆に、不確実性の高いイノベーションの業務は、

  • 自律的
  • 探索
  • 試行錯誤を繰り返す

ことが重要
自律的なチームとなるために必要な要素

  • メンバーの裁量(各メンバーに十分な裁量がある)
  • チームの空気(自律的に動ける雰囲気)
  • 情報共有(自律的に判断し動くために必要な情報を持っている)

 

 

グローバル企業におけるプロダクトマネージメント

Niantic, Inc. Product Management Director 河合 敬一 氏

Increments株式会社 Qiita Product Manager 及川 卓也 氏

 

サマリ

PMが活躍するには周りの環境も大事。PMの役割を知ってもらい、権限をもらわないとできない。
ミッションビジョン・戦略など大きな視点から必ず考える。
ドキュメントは大事。判断に迷うときにドキュメントがあると本質の立ち返ることができる。チームメンバー全員がいつでもみれることができ、共通の価値観を持つことが重要。チームが同じ方向を向いて進むことができるような状態を整えることは重要。

 

Nianticの開発体制

alphabetから完全に独立している
社員数70人くらい
オフィスはサンフランシスコ、東京にも小さなオフィスある
開発拠点は分散している。シアトルがメイン

 

Pokemon goを支えるPMとは

シリコンバレーのPMは、

  • モノを決める
  • なにかあったらPMに相談しようと思われる人
  • PMが良いって言いましたと言える人
  • 次のフィーチャーをどれにしようかというときにPMが判断する

ミッションビジョン、プロダクトビジョン、戦略から考える

  • ガイドラインがあると迷わず判断できる。ガイドラインとても重要(MRD->PRD)
  • 共通の価値観を持つのが大事。みんなが自立して判断できる
  • ファウンダーやCEOと握っていれば判断はぶれない、迷わない

優先度の設定、トレードオフについて

  • 次に何をやるかをずっと思考覚悟している。最後は勘
  • でているissueとの兼ね合いは難しい
  • データドリブンで考えている(グローバルチームは言葉や習慣の壁があるので特に重要)

GoogleのPMも人それぞれ(求められる役割によって変わる)

  • 事業責任者っぽい人、テクノロジーに近くて新しい技術を取り入れる人
  • 開発者がユーザのプロダクトは開発力が求められる
  • 昔Googleではビジネスプロダクトマネージャーがいた(今は無くなった)、出版社とやりとりするPMとか

Q&Aセッション

Q1:
組織が拡大する、業務が拡大する、自分ではできないことが増える。そんなときはどうするか?

A1:
仕組みを作るか、誰かにやってもらうかのどちらかしかない
PMはクオーターで続けて同じことをやっていてはダメ。仕組み化して人に渡す(PMがルーチンタスクやってたら負け)
変えられるものはどんどん変える
PMを増やす場合は、
-フロントとバックでわけるとか
-ユーザの種類で分けるか
がよくあるパターン

 

Q2:
Pokemon goは最初ゲームの展示会でネガティブな反応だったとRebuildで聞いたんですが、そこからどのようにローンチまで持っていったのか?

A2:
フィールドテストでこてんぱんにされた。
改善繰り返したが、最後はエイヤでだした
freeeも最初ユーザからのフィードバックがよくなかった(前のセッションで出た話のよう)
→開発者のモチベ管理難しい。
→まずはちゃんと聞く。エンジニアをどうやって守るか(あえてぶつける場合もある)
→PMはユーザの代弁者であるべき
→大きい声とかネガティブな声に引きづられないことは大事
→声なき声を拾う
→Googleは声を拾わずにデータを拾う(声なき声を拾う)
Google mapsのチームはすごくよかった。
PMは技術の会話ができてエンジニアからリスペクトされることが大事。

 

Q3:
プロダクトデザインの仕様をどこまで詰めるか、開発者を巻き込むことに重点を置くか?

A3:
ボトムアップであるという見かけは重要
エンジニアにオーナーシップをもってもらうことが重要
エンジニアが「これやりたかったんだよねー」と思うような持っていき方ができたら最高
河合さんは、自分のこだわりを持ちすぎないようにしている
ディシジョンメイクを早くするために入って決めることはある
プロダクトマネージャーはファシリテーション能力が必要
全員に納得感をもって進めてもらうことが重要
自分でこうしたいと思うことがあっても、相手(エンジニア)に言わせる。そうすると自分ごとになって作業する
ボトムアップを取り入れるのは重要、判断が必要なところは最終的にはPMが決めればいい
早く作って早く出してフィードバック見て、直せばいい。
→そうじゃないと直感が生かされない(すべてに置いてROIを算出したり、ロジカルに説明が必要な状況はよくない)

 

PMとしての能力開発

  • みんなに信頼されて、任されることが一番大事、評価すべき
  • 製品が出たか、出た製品がみんなに使ってもらえるか
    →PMの評価は、必然的に製品の評価と近づく
  • ただし、難しいプロダクトの場合は考慮が必要。そうしないとつらい。
  • 長期的に良い製品を出し続けられているかが重要

PMのスキルセット

  • 問題が解決できるか
  • データとロジックは理解しやすい
  • 感情でもみんなが「こいつが言うなら」と思えればいい
  • 判断させてもらえる打席にどれくらい立てるかが重要
    →基本OJTで経験を積むことが大事

プロダクトリリース前の満たすべきクライテリア

  • クラッシュ
  • セキュリティ
  • データロスト
  • 機能的に動かない

これらは拾うが、これら以外は拾わない。他にも影響が出る可能性があるため、細かなバグを許容する
→日本企業は細かなところにこだわるためここが苦手。だからOSとか大きなプロダクトは作れない。Windowsは最初はバグだらけ。
PMへのメッセージ

  • PMの役割を知ってもらう、環境づくりが重要
  • アイデアがチームメンバーから常に出続ける状態をつくるのはPMの仕事
  • あきらめたくなるとき、どうしても無理な場合は、諦めることも必要
    →自分では見えなくなっていることもあるので、他のPMに相談してみては
  • シリコンバレーのPMはPLを持たないことが多い(ads系とかエンタープライズ系はお金見るが)
    →いいもの作れば、あとからお金が付いてくるをいう考えのもと
  • どれくらい任せてくれるかは、自分がどれくらい上から信頼されているかによる
  • 説得したいことに合わせてデータを集める

 

 

メルカリ流グローバル開発の実態

株式会社メルカリ 執行役員 伊豫 健夫 氏

 

サマリ

経営陣のマインドや組織のルールが本当にプロダクト開発によっており、いかにいいプロダクトを作るかという視点で組織マネジメントが徹底している。
OKRの設定の仕方、情報共有の仕組み、会議体の仕組みなど、あらゆる仕組みができている。
各チームが明確にORKを設定し、コミットし、それをもとに四半期で評価されるので、みんながそこに向かえる。
シンプルで細かすぎず大胆になれる目標設定。全社としてそれを徹底して要求し、メンバーも高いレベルで理解しているよう。
権限移譲がちゃんとできて、現場ですぐに判断できる(プロダクトマネージャーが判断する)のでスピード感が出る。

 

メルカリについて

現在5500万DL(日本3500万DL, US2000万DL)
売れた商品の50%が24時間以内に売れる
決済はエスクローで安心
US先行機能多数、ABテスト多数
3リージョンを1ソースコードで回すつくりになっている
複雑化している
→どうやってマネジメントしているのか、今日はこのあたりのお話

 

体制と役割分担

日本国内で仕事している人86%
進行中のプロジェクトは、
USプロジェクトA、USプロジェクトB、USプロジェクトC、日本プロジェクトの4つだが、
プロダクトチームの90%はUSプロジェクトに携わっている(USメルカリの出品、タイムライン、検索、CRMなど3ヶ月ごとのOKRに合わせて編成)
US9割にするメリット

  1. フォーカスすることで物理的リソースがたくさん使える →フォーカス大事
  2. ここまで振り切ると、個人レベルでもUSにフォーカスが当たり前になり、余計な議論が減る →すごく効率よくなる

OKRを設定している
KR例:

  • USの問い合わせ数を減らそう
    • 出品者からの問い合わせをx%に
  • 売上をあげる
    • 月間売上をx%上げる

OKRをシンプルにするメリット

  1. チーム全員が、同じ言葉で話せる
  2. ゴールが大粒なので、打ち手に対する発想も大胆になれる

現地ローカルでやっていること

  • トランザクション
  • CS
  • CRM
  • 対面での調査やテストなど

日本チームでやっていること(選択と集中)

  • 利便性強化
  • USヒット機能の移植
  • 新規ユーザの獲得

 

メルカリのプロダクトマネジメント

1プロジェクト1プロダクトマンージャー(プロデューサーは別でいる、つまり企画者は複数人)
PMが各KRの達成に全責任を負う
チーム構成は例えば、PM1、P1、APIエンジニア4、フロント1(デザイナーやQAは横断)
PMの役割

  1. 企画
  2.  仕様策定・ディレクション
  3.  実装 (直接的な業務範囲ではない)
  4.  QA - リリース (直接的な業務範囲ではない)
  5.  リリース後分析

+ プロダクトの日々の活動とマネジメント
1&2. 企画ディレクション

  • チケットドリブン、すべての案件はRM化(redmine)、かなり仕様を細かく書く
  • エンジニアバックグラウンドのメンバーが多い

5. リリース後の分析

  • 自分でSQL
  • ハイレベル分析はBIチーム協業
  • ダッシュボード文化で報告を最小化(Chartioで可視化、ウェブベースで使いやすい→おすすめ)

+プロダクトの日々の活動とマネジメント
コーディネート役のポイント

  1. オープンコミュニケーション(Slack)
  2.  必要な情報は自分で取りに行く
  3.  自発性を重視(一人一人の得意分野を知り、思い切って任せる、失敗を責めない)

グローバル開発のコーディネート
対面で接さないメンバーをどうやって巻き込むか、2パターン

  1. 役割とプロセスを決めて、適任者に任せる
  2. 足繁く現地に通う

活躍しているPM

  • モノづくりへの理解(精通レベル)
  • ユーザの理解と多くの引き出し(アンテナが高い)
  • 自走力(課題発見から解決まで、自ら手を動かせる)

 

PMが活躍できる組織を作ることが重要
優秀なPMがいても、組織そのものがプロダクトオリエンディッドでなければ全くの無意味
→ここを最初に見極めることが大事
組織から受けがちな3大PM阻害要因

  1. 余計な説得(承認をとるのに時間がかかりすぎ)
  2. 余計なツッコミ(物事がひっくり返る)
  3. 余計な心配(リリースまでに時間がかかりすぎ)

↓対処法
1に対して、
承認会議をやめる、プロダクトマネージャー判断で進める

メルカリの会議体は以下のとおり最低限。

  • 企画MTG(30min/w)相談の場
  • プロジェクトオーナーMTG(1h/w)PM間の横のMTG
  • スタンドアップMTG(5min/w)

トップが阻害要因排除にコミットできるかが重要。
社内情報のgive and take化
社内wikiをCTOがリード
情報は取りに行けばそこにある
→「xx」についてレポートして、がなくなる
2に対して、

  • 担当プロジェクト優先
  • プロジェクトオーナーMTGで共有(問題解決)
  • とはいえある程度柔軟に(変更に耐えうるディレクション)

3に対して

  • とにかくABテスト(デイリーで50本同時稼働)
  • 直感を取り込めるか
    →「理論武装を文化的レベルで排除」

 

 

最後に

USではプロダクトマネージャーの定義はある程度明確であり、職能として確立しているよう。Googleでは新卒社員に対して、APM(Associate product manager)プログラムを提供しており、育成の仕組みもあるみたい。

日本ではまだまだプロダクトマネージャーの役割がそれほど認識されておらず、会社によって違ったり、人によって違ったりしていると思うので、このような場で様々な会社でうまくいっている事例や失敗した事例などを知ることができるのはとても意味があるなーと思いました。

 

これからの仕事にいかしていきたいなー。

 

Adsense

Adsense

-カンファレンス, プロダクトマネージャー

Copyright© インターネット業界で働くディレクターの雑記 , 2018 All Rights Reserved Powered by AFFINGER4.