プロダクトマネージャーカンファレンス 2019 に参加してきた
こんちは、じぬ（@reximology）です。
プロダクトマネージャーカンファレンス 2019 というイベントに参加してきました。
参加の動機
現在は少人数チームで開発を行っているため、エンジニアでもこういったプロジェクト開発を推し進める知見を持っていた方がスムーズに進めていけるのでは、というところから参加を決めました。 余談ですが、プロダクトマネージャーは PdM と略す場合が多いようです。（PM と記載してる例もありましたが
参加したセッション
day1
- 作り手の想いとユーザーをつなぐための悪戦苦闘
- ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織
- “失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
- テクニカルアドバイザー 及川卓也 × エン・ジャパン 公開トーク- PMの必須スキルと、自走する組織の裏側 -
- 企業が求めるプロダクトマネージャーとその人材戦略
- 異動、転社・転職などを活用したプロダクトマネージャーのキャリア戦略
day2
- 変化の激しいプロジェクトを成功に導くには － 会議ドリブンなプロジェクトマネジメントメソッド
- 打席に立ち続けられるプロダクトチームを作ろう
- プロダクトアウトな新規事業立ち上げのリアル
- PMはどのようにバリューを出していくのか
- プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
- シリコンバレーPMのキャリアと働き方
作り手の想いとユーザーをつなぐための悪戦苦闘
要約
- 去年はリリース前後の話をした、今年はリリース後の課題
- 市場が伸びるとともに自分たちの想像できていないユーザが現れ始めた
- 自分たちがユーザを理解できているという過信があった
- ユーザと向き合う対話を徹底した
- 各メンバーにもその視点を浸透させた
グッときたところ
- 例えばライフサイクルの異なる地方ユーザなど、具体的に開発者が想像できていなかったユーザの登場
- ユーザ属性をカテゴライズし、確実に見分ける質問を必ずアンケートで実施
- ギルドワークス社のワークショップなど、チーム全員でユーザと対話する訓練
- Monthly Release Sharing という社内知見共有の定例化、マネージャーではなく現場のメンバーが話すことを徹底
ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織
要約
- pixiv で PdM が持つべきスキルとスタンスをまとめた PM コンピテンシーを整備
- プロダクトマネジメントトライアングルを実際の PdM でどうまとめるか
- 複数の PdM を抱えるチームという事例
- 既存のエンジニア組織を参考に、PdM を組織化
- ドメイン知識を高いレベルで獲得し、メンバーお互いを尊重し合える文化
グッときたところ
- 企業によっても異なる PdM の定義を言語化した
- 参考にしたエンジニアギルドが pixiv 内で10年近く続いた組織である
- プロダクトのあるべき姿を定義、チーム力を最大化、という二つの PdM のミッション
- PdM の育成に再現性を持たせるための試行錯誤
“失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -
要約
- 相次ぐ退職、属人化によって新規プロジェクトに取り組めないなどの重い課題
- PdM を明確に定義できていない
- Inspired 読んだ、社外のスペシャリスト（及川さん）に相談した、GAFA などの事例を調査した
- PdM の役割、持つべきスキルを明確化した
グッときたところ
- 役割：製品価値を最大化し、それに向けてチームをつないでいく
- 価値とチームという2軸は上述の pixiv と近い（おそらく PdM に期待される共通項
- 期待されるスキル：創る能力、広める能力（製品のグロースや、ドメイン知識の理解など
- 能力値をレベルで表現することで各 PdM の強み弱みを明確化した
テクニカルアドバイザー 及川卓也 × エン・ジャパン 公開トーク- PMの必須スキルと、自走する組織の裏側 -
要約
- 正直各社の取り組みは似ている
- PdM トライアングルは難しい、それぞれかみ砕いていく必要がある
- その上でメンバーが自分たちの物である、という認識を持つように促していく
- PdM は全体に精通する必要がある
グッときたところ
- レベルごとの期待値をリスト化するのは大変だったが、ネット情報をはじめとして洗った上でかみ砕いていった
- 非エンジニアの PdM は SQL とかとっつきやすい、構文がわかりやすく結果も見える、そういうところから全体に精通する必要がある
- スキル表はまだ評価に組み込めてはいない、それよりもキャリア相談などに活かしている
- PdM は最終的に全てに責任がある、自分でやるのは一つの手段だが、できるメンバーに頼るのも必要なスキル
企業が求めるプロダクトマネージャーとその人材戦略
要約
- PdM 人材の需要
- オンボーディング
- 価値観醸成
グッときたところ
- PdM のタイプは様々、多様性が企業の強みになる
- 会社の文化を理解すること、創業者との信頼関係があることが求められる
- メンバーは権限では動かない、信頼関係の構築が必要になる
- 新しい PdM に丸投げは絶対ダメ
- 最初は花を持たせて成功させる、そこまでやってようやく採用が成功と言える
- 会社からの期待値をきちんと伝える
- ミニ CEO とも呼ばれる、視野視座はきちんと会社と揃えていく必要がある
- 既存の PdM と 1on1 などを通して併走させ、きちんと会社になじませる
異動、転社・転職などを活用したプロダクトマネージャーのキャリア戦略
要約
- PdM に必要なスキル
- PdM の採用
- 年収の相場
- PdM を目指した転職
グッときたところ
- PdM に必要なのは、大雑把に言えば「なんとかする力」「突破力」
- 足りない力があればそれをどうやって乗り越えるのか、を考え実行できる人
- PdM は統合スキルが求められる
- 鳴り物入りで入社した人でもダメなことはある、むしろ新卒上がりの方が強かったりする
- 中途の人にはいきなりポジションを与えず、補佐みたいなところから周りの信頼を得て成果を出せるか見る
- 期待値を下げて、きちんと動ける環境を用意してあげる
- 最初から役職にこだわる人は難しい
- News Picks だとトップクラスは年収2000万くらい
- 一つのプロダクトを完全に任せられる人材なら1000万くらい
- PdM を目指すには、とにかくユーザ満足度を考え、それを科学する（トライ＆エラー、デザイン思考
- ユーザリサーチのスキル（インタビュー力、ユーザの思いを察する力
- 業界リサーチ（ヒットの規模を見る
ネットワーキング
初日の夜はネットワーキングがありました。 自分は OKR のテーブルで話をしたのと、pixiv ブースでセッションの詳細を話してきました。
OKR
- OKR は仮説検証の手法、達成できなければ方法が悪い
- 達成しても O が満たせないなら KR が悪い、ならば何を持って成果を評価できるか再検討する
- 組織規模によっては OKR 自体を PdM が定める（組織の OKR に沿った内容を見定める
- 個人レベルの OKR まで定めても、組織のコピペになるのであまり効率が良くない、という印象がある
pixiv
- エンジニアギルドは10年以上続いた取り組みに最近名前がついた
- 組織自体に拡張性を持たせ、属人化せずに取り組みが回っていくように考えた結果いまの構造になった
- エンジニア、デザイナーとしての良い取り組みが回り回って評価にも繋がっていく
- やってダメなら見直す、というアジャイル的思考で進めた
- 仕組み化にこだわることで続いてきた
変化の激しいプロジェクトを成功に導くには － 会議ドリブンなプロジェクトマネジメントメソッド
要約
- プロジェクトマネジメントは「仕事を動かす仕事」
- 会議をどう活用できるか
- メンバー全員でアジェンダを作る（みんなで決めること決めないことを話す
- 課題を持ち帰らず必ず次のタスクを決める（みんなで納得して次に進む
グッときたところ
- 会議が悪いわけではないが、今ままでの会議形態は変化が激しい、アジャイル、などの時代に合ってはいない
- 話す内容からして全員できちんと話す、他人事にしない
- 会議で話すのは前回からの進捗、プロジェクト全体の方向性、次回までの予定
- タイマーとかアジェンダを表示する2台目のモニターがあるとはかどる
打席に立ち続けられるプロダクトチームを作ろう
要約
- MOV というサービスだけでもいろんな取り組みがある
- 変化が激しい中でも高い打率を保つ
- DeNA における PdM の役割を定義（フィロソフィー
- 専門職として評価・育成するための組織化
- 失敗できる環境の提供
グッときたところ
- PdM は作る物を決める仕事だが、UX リサーチャーやデータサイエンティストとの連携が不可欠
- プロダクト価値を明確化し、狙った市場に届けられる人材が必要
- エンジニアやデザイナーと専門用語で会話できる知識
- 社内のスペシャリストとともに働くことでいち早く PdM としての経験を積める
- 完璧な人はいない、PdM としての得意な部分を伸ばしていく
プロダクトアウトな新規事業立ち上げのリアル
要約
- PdM のやるべきことは会社のフェーズによって異なる
- CPO のポエムから生まれた機能開発
- 時期によっては属人化を許容したり、徹底的に仕組み化したり
- PdM は最も価値がある（レバレッジが効く）ことをやる
グッときたところ
- PdM の仕事は多様、ベースとなるフレームはあってもそれだけでは解決できない
- いかに多くの事例を知っているか、が強みになる
- プロダクトアウトで生まれた機能をいかにビジネスにするか、も PdM が対応した
- プロダクトで解決するのか運用で解決するのか、俯瞰的に決めていく
- ローンチ直後は強いメンバーで乗り切った、あえて属人化した
- 規模が拡大してそれではまわらなくなった時にようやく仕組み化した
- 仕組み化は得意なメンバーをアサインして徹底的に対応
- クライアントの初期導入が悪かったので、まずは Onboarding から整えた
- PdM の仕事はプロダクト開発、セールス、CS の仕組み化、チームビルディング、と多岐にわたる
- 価値の最大化のための仕事を選ぶ
- 自ら解決しつつ、別の手段も常に考えておく
PMはどのようにバリューを出していくのか
要約
- PdM が必要になるのは迷いが生まれやすい新規開発や、ビジネス要件の強いプロジェクト
- ユースケースに精通するのは CS、だからこそ開発と CS は密に連携が必要
- PdM はマーケットやクライアント課題を特に理解しておく、なるべく第一情報に触れていく
- 無理なことはできるメンバーに頼る
グッときたところ
- 開発と CS 連携の重要性
- タスクは共有や管理のためすぐに issue 化する、ただしやらないなら閉じる（必要な過大ならいずれまた上がってくる
- 深い知見を無理に追うのではなくメンバーに頼る（これは他社でも述べられている
- チームビルディングに必要なのは権限譲渡、そして長期目線を共有すること
- メンバーが給料を気にせず働けるのが理想、そのためには希望の少し上を払い続けられれば理想（まだ試行錯誤中
- 小さいチームの時は特にミッションを意識し、みんなでどこを目指しているのかを認識合わせする
プロダクトマネージャーが知っておくべき、「OKR」を通じたこれからのチームマネジメント
要約
- Google の基本はボトムアップ
- 近年：プロダクトではなくプラットフォームを作る、オープン主義、エンプロイーエクスペリエンス、走りながら考える学習主義
- OKR は途中で変えてもいい、ただし日々の観測が重要
- 組織から社員まで一貫性を持たせる
- 内容を開示し、1on1 を通して習慣化する
グッときたところ
- OKR は目標から逆算する、ストレッチな目標にすることで挑戦する文化を創る
- OKR は個人の夢でもいい、それを組織に紐付けていく
- 導入目的が曖昧、経営陣の足並みが揃ってない、マネージャーが組織 OKR を理解してない、などが失敗あるある
- OKR は最大のインパクトを与える物に絞る
- 仕事を通した自己実現を是非考えてほしい
シリコンバレーPMのキャリアと働き方
要約
- シリコンバレーの方がデータドリブンは強い
- 会社がトレーニングを提供したり、横のコミュニティも強い
- PdM から先のキャリアパスは結構なんでもある
- PdM をやるなら何が得意か、何が好きかはきちんと整理しておく
グッときたところ
- シリコンバレーだと PdM 採用で SQL 書いたりする。それくらいデータに触れるのは日常
- アルムナイ組織と呼ばれる企業の卒業生コミュニティもつながりが強い
- 改善案を効果は別にしてもたくさん思いつける能力が必要
- 自分が使うアプリの改善案を出せる、またそれの否定案も出せる能力
- 企業によって PdM の出自は違う（Airbnb だとデザイナー系が多い
- 日本だとまだまだ逆境も多いが、小さく成功して実績を作るのが良いと思う
- 常にカスタマーという存在を意識する
感想
共通内容として感じたこと、まず PdM のミッション。
- 製品価値を上げること
- それを完成させるチームを作ること
その上で、以下の特性がある。
- PdM はプロダクトの最終責任を担う
- マーケット、ドメイン知識、チームメンバーのこと、企業文化、など関わる全てを知る必要がある
- できないことはメンバーに頼ることも必要になる
- あらゆる手段を講じて課題を解決することが期待される
各社で PdM に求める役割やスキル、育成、評価、採用の方法は手探りな状態という印象だった。 それでもデータドリブンや現場の知識など、エンジニアから PdM の働きをするとっかかりが多いということを知れたのは収穫だった。
その他の発表
こちらのブログでまとめてくださっています。 takaking22.com
