読者です 読者をやめる 読者になる 読者になる

Japan Product Manager Conference 2016に参加してきた。〜アウトラインメモ〜

event

Japan Product Manager Conference 2016に参加してきました。

家庭の都合上、最後まで参加できなかったのですが当日とったアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい

アウトラインメモ

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

  • グーグル株式会社 徳生 裕人

政府そして製造技術開発会社を経て2005年にGoogleにプロダクトマネージャーとして転職した経緯等を通して、日本のインターネットビジネスを担うPMの皆様にメッセージを送れればと思っています。

内容

  • スタートアップでも大きな企業でもPMの役割は以下となる
    • User Problem
    • Technology Product Opportunities
    • Resource
    • Deliver
  • 8年間Product ManagerやったけどいまだにPMが何なのか分からない。 by SlackのPM
  • ベストプラクティスはないので色々なPMの意見を聞いて自分たちのチームにあったやり方を考えていくのが大事
  • 以下GoogleのPM達にインタビューして出てきた意見
    • オーナーであれ。"The buck stops here."
    • チームのシナプスであれ
    • 自分の計画、考えをきちんと周りに伝える、聞かれたらきちんと答える
    • ステークホルダーとの調整も大事。大きな会社だとより重要になってくる
  • 長い期間での成功をきちんと考える

ゼロから始めるPM生活

本セッションでは、ゼロからプロダクトを作り始める場合のプロダクトマネジメントについて、スタートアップやアカデミアで得られている知見を紹介します。

内容

  • 資料:ゼロからはじめるプロダクトマネージャー生活
  • PM = mini-CEO
  • Y Combinatorの知見を活かす
  • よく見えるアイデアだけでは急成長できない
  • 誰しもが狙うので他社とかぶることが多い
  • 悪いように見えて実はよいものを探すのが大事
    • 悪く見えるアイデアのほとんどは本当に単に悪い
    • 見極めるのが難しい
  • 難しい課題のほうが実は簡単
    • 採用が増えたり応援してくる人が増える
    • 誰も挑戦しない苦行なので競合がいなくなる
  • 今はまだ小さいけれど自分たちで独占できそうなマーケットを狙う
  • プロダクトの成功を考える=プロダクトでやらなくてもよいことを考える
  • 一部の人が愛してくれるようなサービスを作るとよい
  • 後々口コミ等でスケールする可能性がある
  • 最初にリリースするものがひどいものでもよい。とにかく早くローンチした方がよい
    • 最初にローンチしたものがひどいものではないのならそのリリースは遅すぎる
  • スタートアップはモメンタム(勢い)を死守するべき
    • モメンタムが落ちてきたと感じたらもう遅い
    • 価値は実行から生まれる
  • PMはいろいろやらないといけない
    • チームのボトルネックになりがち
    • Slack(ゆとり)を作ることが非常に大事
    • Noと言わないといけないことが多いので多少嫌われる
    • メンタルを維持するために精神論ではなく運動するべき
  • 量は質を生む
    • あきらめずに数をこなすことが重量
  • PMに必要はスキルセットはACT SOLID
  • Analytics, Communications, Trust/safety, Support, Ops, Legal, International, Design
  • 力を付けるためにサイドプロジェクトを起こしてそこで学ぶというのも1つの手

Product Team Management

  • Increments株式会社 海野 弘成

この発表ではProduct Managerとしてチームをどう作り、改善していくべきかをテーマに、Qiita:Team開発のために行ってきた様々なチームの分析や研究ノウハウを紹介し、また弊社でそれらをどう実践してきたかについてお話します。

内容

  • 資料:Product Team Management // Speaker Deck
  • よいチームとは
    • 成果が出せることが大前提
    • 自律的なチーム
      • メンバーの裁量
      • チームの後期
      • 情報共有
  • Googleの研究から心理的安全が大事だと言われている
    • 考えの表明ではなく、具体的な行動が必要
      • 分からないことがあればいつでも聞いてといいながら目を見て話していないとかダメ
    • 思いを流さず伝える場所が必要
  • 情報共有はHowよりもWhat、Whyが重要
  • OKRで目標管理

マイクロソフトによる「見える化」の民主化(Power BI 活用術)

本セッションでは、Power BI を使った現実的な利用シーンを想定し、その可能性を紹介していきます。 もちろん、マイクロソフトのプロダクトマネージャーが、日々の業務の中でどのように Power BI を利用しており、なぜ今回皆様に紹介しようと思い至ったのかも簡単に紹介いたします。

内容

  • マイクロソフトのPMにあたると思われるロール
    • Business Group
      • Product Marketing Manager
      • Technical Product Manager
    • Engineering Group
      • Program Manager
  • 何をやるにも客観的なデータの提示が必要
    • 売り上げ状況の説明、ステークホルダーへの説明などデータを提示することが重要
    • そこでPowerBI
    • PMはレポート作成をPower BIに任せて他の業務に集中しよう

大規模システム開発におけるプロダクトマネージメントについて

過去多数のプラットフォームを開発指揮してきた経験から、組織・チームを破綻させること無くプラットフォーム開発を成し遂げられたヒントとその中で感じた課題をお話します。

内容

  • プラットフォーム開発の特徴
    • エンドユーザーが直接利用することが少ない
    • サービス開発と違いユーザーの利便性などが直接分かるわけではないのでマーケティングしにくい
  • プラットフォーム開発でのPMの役割
    • バラバラの機能がどこの何に活きてきているのかをきちんと伝える
    • その機能が事業にどのように貢献しているかをきちんと伝える
    • 各チームがそれぞれ意味があるということをしっかりと周りに伝えることが大事
      • 特にマイクロサービス毎にチームを分けている場合は
  • 事業をなぜやっているかという疑問が生じたら徹底的に説明する
    • なぜ、何のためにやるのか、ミッションは何なのか
    • チームで目指しているものを一致させる
    • 思いを言語化して相手に伝えないとほとんど伝わらない
    • 迷いがなくなると人は強くなれる

絶対失敗すると言われたプロダクトを成功させること

  • freee株式会社 佐々木 大輔

内容

  • freeeで最初苦労したこと
    • 新しい会計ソフトとか覚えたくない
    • クラウドである必要を感じない
    • 自動で入力するとかいらない。早く入力できるようにしてほしい
  • 強みをつくる
    • 機械学習による勘定科目の自動振り分け (特許取得済み)
  • キャズムを作る
    • 狙っているセグメントの人にどんどん使ってもらう
    • 夕刊紙に「freeeの登場により日本から税理士が消える」という記事がのる
      • これで一気に問い合わせがきた
  • ユーザーが増えてくると全部の要望を聞き入れることが難しくなってくる
    • 最初の内は一般的な要望が多いがそうではなくなってくる
    • なぜその要望が必要なのかを徹底的に掘り下げていく必要がある

現役23名のPM:タイプ別マネジメントパターン

社内では現役23名もの開発責任者(プロダクトマネージャー)が切磋琢磨しつつ、さまざまな課題に立ち向かっています。23人23色のやり方の中から見えてきた、タイプ別マネジメントパターンをいくつか紹介します。

内容


毎日の料理のためのプロダクト開発

日々変わり続けるクックパッドのプロダクト開発。今、私たちが食や料理というジャンルの中でユーザーにどのような価値を提供しようと考え、それをどう開発で実践しようとしているか。PCからスマートフォン、ウェブとアプリの役割などプラットフォームの考え方、エンジニアやデザイナー、ディレクターなど各職種のスタッフがどう関わり意思決定しているかなど含め、これまでの変遷や具体的な開発の事例を交えて話します。

内容

  • デザイナーを全社横断組織にしたり、ひとつの組織にしたりいろいろ試している
  • 今はiOSAndroidのアプリで主要機能を分けるという試みをしている
    • iOSはレシピの投稿機能が強い
    • Androidはレシピの閲覧に強い
  • 使っている思考のためのフレームワーク
    • EOGS
    • サービス企画シート
    • リーンキャンバス
  • エンジニアと非エンジニアがお互いを補完できるような体制
    • エンジニアのオーナーと非エンジニアのオーナーを作る
    • サブチームにはディレクターを置いてその下にエンジニアやデザイナーが入る
    • 各オーナーはディレクターと連携を密に、さらに全エンジニア、デザイナーもフォロー
  • 課題と仮説をきちんと言語化する
    • SlackのTopicに書いておいて常に目がつくようにしている
    • 議論が必要なものはGitHubでissueたてて行っている
  • 目標とKPI定義
    • 部目標とチーム目標、メンバー目標がサービスのKPIとずれないようにする
    • 個人の目標は業務目標とスキル目標の2つ
    • 月1の1on1
  • 価値観の共有を大切にする
    • プロトタイピング合宿
    • イデアを出しやすいようにする
  • 世界観や方向感はオーナーが責任を持つ
    • 具体的な計画は開発者に任せている
    • オーナーは問題が出た際に正しい判断をする
  • 年に1回は全員外に情報発信してもらっている
    • 会社ブログの更新
    • イベントへの登壇

Product Manager という仕事

  • 楽天株式会社 齊藤 満

日本の会社である楽天トラベルに、PM というシステムの導入を取り組んできて、感じたこと、学んだこと、面白いと思う事、これからのチャレンジなんかをお話しします。

内容

  • Product Managerのマネージャーをやっている
  • PMはCenter of Communications
  • PMはそれぞれの組織で違うので分かりにくい
  • どんなに小さいプロジェクトでも、みんなで共有できるドキュメントを書く
    • なぜこのプロジェクトをやるのか、なんのためにやるのかを明確に
    • チーム内の意思を統一する
    • 楽天トラベルではこれをすることで5年間でエンジニアの数は変わっていないのに生み出すサービスが5倍近く増えた
  • まずは一番高い理想を目指す
    • 最初から現実的なところを目指してしまいがち
      • PMなら工数とかリリース期間等を考えて妥協するのではなくまずは自分の考える最高のものを提示するべき
    • 一番高いところを目指して足りない部分を落としていくという考えを持つ
  • 世界をもっと考える
  • 日本だけで考えるのは視野を狭めてしまう
  • アメリカが強いのは世界中から人が集まっているから
  • 違う文化の人の考えを取り入れるように意識する

プロセスからプロダクトへ

  • David Hussman

内容

  • devjam studoisというのをやっている
  • プロダクトチームの3つパターン
    • 1プロダクト1チーム
    • 1プロダクト複数チーム
    • 複数プロダクト複数チーム
      • 大きな会社だとプロダクトとは言わず、システムと言うことが多い
  • プロダクトコミュニティを作るようにする
    • ディスカバリーとデリバリーを混ぜる
    • 開発者もペルソナ作成、カスタマーインタビューを行う
    • ソフトウエアエンジニアという名前をプロダクト開発者に変えてみた
  • インパクト駆動開発
    • コードの量産よりもプロダクトの検証
    • 開発を始める前に作るものがどう顧客にインパクトを与えるかを考える
  • プロセスよりもプロダクトを大切にする
    • プロセスをおろそかにするわけではない。プロセスはきちんと回しつつプロダクトのことをきちんと考える
  • この本を出すので読んでほしい

エンジニアがプロダクトマネージャーに進化すると何が起きるのか

サイバーエージェントのアドテクスタジオにおいて実際にプロダクトマネージャーとして働いている具体的な業務内容と求められている成果、もしくは狙いたい成果をお話します。 同時に現場におけるプロダクトマネージャー業務と自分自身が思うギャップやジレンマについてもお話します。

内容

  • チームマネジメントも技術
  • チームフォーメーションを強く意識している
    • 戦略的に配置換えなどを行っている
  • 依存関係を構造化し、優先度が高くクリティカルなものから取り組む
    • 作らなければいけないもの、作らなくてもよいもの
    • 社内、社外と交渉が必要なもの
  • 事業運営にも技術を
    • 報告用レポート生成を自動化
    • 事業報告(売り上げとか、ユーザー数の報告)もbotで行う

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

  • Niantic, Inc 河合 敬一
  • Increments株式会社 及川 卓也

パネルディスカッション形式でNianticプロダクトマネジメントにせまる

内容

  • Nianticの開発体制
    • 今は約70名、エンジニアがほとんど
    • 開発拠点はGoogle時代を引き継いで結構分散している
    • Googleの社内インフラは一切つかってない。顧客としてGCP使っている
  • Pokemon GOを支えるPM
    • 共通の価値観をチーム内でどう持つかが大事
    • 会社を作った人の想いをきちんと引き継いでメンバーに伝えていくのが大事
    • 発見は日常にたくさん埋まっていて、それをテクノロジの力で見つけられるようにしたい
    • Googleの時は、大きい組織/事業なので考えることが多かった、Nianticは目の前のプロダクトに集中できるのでPMはやりやすい
  • PMが業務を回していくコツは?
    • 仕組みを作るのが大事
    • 今のクオーターと次のクオーターで同じ事をやっていたら負け
    • 変化の仕掛けを作るのが大事
    • PMが定常的な仕事をしていたら負け
    • 他のメンバーで回るようになったら次に行く
  • Pokemon Goはテスト時のネガティブな状態からどうたち直したのか?
    • フィールドテストの評価はひどいものだった
    • でも出して試してもらわないといけないので出した
    • 叩かれても貴重な意見に変わりない。エンジニアにどう伝えるかは考える必要がある。ただの文句なのか、大事な意見なのかはPMが切り分けて伝えている
  • PMの立ち回り
    • 技術の会話が出来てエンジニアからもリスペクトされた方がよい
    • 知ったかぶりを貫き通すのも技術。もちろん基本的な知識は身につける必要がある
    • メンバーの好みを知る。モチベーションを上げる方法を知っているか
    • 焼き肉に行く
  • PMとエンジニアの関係性
    • ボトムアップでエンジニアがオーナーシップを持っているのが理想
    • エンジニアが作業に意味を見いだせないといけない、自ら問題提起ができないといけない
    • どうしてもエンジニアが決定できないことがあるときはPMが入って決める。No Dicisionは本当にダメ
    • ジョブズみたいな独裁的なパターンが出来る人はごく少数
  • PMとしての能力開発
    • チームの信用を得ることが大事
    • きちんと製品、サービスを世に出すというのが実績/評価につながる
    • 力を付けるのは自分でやってみるしかない、OSSでも小さな社内プロジェクトでもなんでもよい。座学だけでは力はつかない

メルカリ流グローバルなプロダクトマネジメント

  • 株式会社メルカリ 伊豫 健夫

JP/US/UKと三カ国にサービスを展開するメルカリの、グローバルなモノづくりの実態について公開。プロダクトマネジャーの役割は?多国間のコミュニケーションと意思決定は?メルカリ流の創意工夫についてのお話です。

内容

  • 今はプロダクトチーム全体の90%をUSに割いている
    • 大量の機能追加、改修案件が可能
    • 組織として、個々人の行動レベルにおいても迷いがなくなりUSに集中できる
  • 達成目標にはOKRを採用
    • シンプルに目標を立てるようにする
    • チーム全員が全社で目指しているものを同じ言葉で話せることが大事
    • PMがチームメンバーのKRに対しての全責任を負う
  • メルカリのPM
    • リーダー的なこともやるし、自分で手を動かすこともある
  • 課題は全てRedmineで管理
    • チケットがないとリリースできない
  • リリース後の分析
    • 自分でSQL叩くことが前提
    • Chartio使っている
  • チームをコーディネートする時のポイント
    • オープンコミュニケーションを心がける
      • メルカリではSlackのPrivateチャンネル禁止にしている
    • 必要な情報は自分から取りに行く
    • 自発性を重視
      • それぞれの得意分野を知り任せる
  • メルカリで活躍するPMの特徴
    • ものづくりへの理解
    • ユーザ理解と多くに引き出し(アンテナが高い)
    • 自走力(課題発見から解決まで自らの手を動かせる)
    • いくら優秀なPMがそろっていても、組織そのものがプロダクト中心の思考になっていないと意味がない
  • 阻害要因への対応方法
    • 余計な説得をなくす
      • 承認会議をなくす。打ち合わせは週に1.5時間程度。この中で意思決定を行う。
      • 全社マネージャー会議も無くした。現場のマネージャーに権限委譲
        • 社長には議事録をSlackで送るだけ  
    • 余計なツッコミをなくす
      • 他のチームが口を挟んできても担当チームの意見を優先
      • とはいえ、PMは状況をみて調整する必要がある

自分が見てきた Product Manager

  • クービック株式会社 倉岡 寛

Google -> GREE -> Coubic と、Product Manager としてのキャリアを通じて、プロダクトの企画・開発・マーケティング・営業・PR 等と横断的にプロダクトに携わってきている中、いかにユーザーに愛されるプロダクトを作ることができるのか、いかに周りを巻き込みながら進めることができるのか等など、日々感じていることを経験交えながらお話できればと思います。

内容

  • PMは権限はないけど責任はある
    • 権限があったとしてもそれを振りかざすことをしてはいけない
  • 顧客と話せ
    • 自分のやりたいことと顧客のやりたいことのバランスを考える
    • ただ聞くだけではなく顧客の痛みをちゃんと理解する
  • とりあえず行動する
    • 行動しないと何も起きないし、スケールしない

“Team in Center”のプロダクト開発

端末メーカーであるソニーバイルのXperiaにプリインされ、数多くのお客様に使っていただいているアプリケーション(プロダクト)の開発をご紹介させていただきます。 どのようにユーザに愛されるアプリを開発しているか、またその開発チームを、どのようにチームビルディングしているのか。プロダクトオーナーとしての工夫はなにか。いくつかのポイントや学びを共有させていただきます。

内容

  • Team in Center
    • 企画と設計が離れているのはよくない
    • プロダクトに皆が責任を持つようにと設置された
  • Movie Createrの事例
    • Xperia Z3からプリインされている
    • チーム全員(dev含む)でユーザーストーリーを考えた
      • 他アプリを使い倒したり、普段動画撮らない人も動画を撮ってユーザー視点になる
      • 使用するユーザーがどんな人かを常に意識する
    • イデアを出してみんなで投票
      • 全員が意思決定しているという雰囲気作り
    • プロトタイピングして社内ヒアリングして精度を高める
    • チームが主体的に動くようになっていることが大事
  • Albumの事例
    • Xperiaにプリインされている写真閲覧アプリ
    • チームビルディングで山登りした
      • 性格が把握できる(先に行っちゃう人とか)
    • チームビルディングで原宿へ
      • 若者の文化を知る
    • ワークショップしてメンバーの想いを一つにする

感想

最近何かと話題になるプロダクトマネージャーについていろいろと知ることができました。一般的な話から、登壇者の方々が実際にどのような取り組みをしているかを知ることができ自分の幅をかなり広げることができそうです。

今の会社でプロダクトマネージャーという職種になれるかというとそういうわけにはいかないので、自分の持っているいくつかの小さなプロジェクトに今回学んだノウハウをいくつか取り入れて実践していきたいですね。

プロダクトマネージャーを担当する上でのベストプラクティスはないので自分のチームにあった方法を模索していくしかないという大前提があるのですが、登壇者の方々の話を聞いているとプロダクトマネージャーとして大事なポイントはだいたい以下に集約されると感じました。

  • メンバーそれぞれが自走できるようにする
    • なぜそれをするのか?何のためにするのか?をきちんとメンバーが考え続けることができるように
    • チームの想いを統一する
    • 会社の目標、チームの目標、個人の目標をきちんと結びつける
  • 言語化
    • 考えていることはきちんと文字にしてメンバーに共有する
    • できる限りオープンにして議論する
  • ユーザーのことをきちんと理解する
    • 開発者もペルソナ作成、カスタマーインタビューを行うなど
    • 自分もユーザー視点になる 
  • 信頼を得る
    • 最低限の実績は必要
    • 小さいプロジェクトでもよいので経験を重ねていく
    • 焼き肉行く
  • 担当プロダクトへのアツい情熱

全体的に最高なイベントでした。普段なかなか時間をとってこのような内容を考える機会がないので本当にいい刺激になりました。

運営の皆様ありがとうございました!

12/15 追記

公式ページに資料まとめページができています。

公開資料まとめ | プロダクトマネージャ―カンファレンス 2016