Product Manager conference 2019 その１
前回参加したのは2017年で今回2回目の参加
2017年はまだProduct Managerってなんでしょう？っていう問いをしていた気がする、今回2019年は具体的にProductMangerの役割は何だっけ、何が出来ている必要があるか、組織の中でどうProductManagerを活かすかみたいな内容だったという感想。
各セッションで書籍やツールの紹介もたくさんありたくさん勉強することがあるなあと思いました。
ORDINARY PEOPLE, EXTRAORDINARY RESULTS Marty Cagan
ebay、HP、Netscapeの元役員、プロダクトを作るサポートを色んな所でやっているひと。今はシリコンバレー中心らしい。
プロダクトは事業や顧客のために作る
Feature Team -> PJM 決められたロードマップに合わせた機能実装を目的とている
権限がない
つくるものが決まっている
Product Team -> PDM 問題に対する解決策を出し顧客に価値を提供する
権限がある
つくるものからきめる
ジョブズの名言
優秀な人を雇って作るものを指示する→NG
優秀な人を雇って作るものを定義してもらう→OK
Steve Jobs once said, “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
https://hackernoon.com/hire-smart-people-and-let-them-tell-you-what-to-do-just-like-steve-jobs-did-c38d92d11213
Feature TeamからProduct Teamにするためには
マネージャーが各チームに計測可能な目標を与える。
↑各チームがProductを通じて成果をあげるのに注力させる
何をしなさいと具体的な指示を出すのはマネージャーの仕事ではない
チームを信頼しチームに権限を与えるその代わり計測可能な目標を通じてチームが目標を達成できているか出来ていないか客観的に判断できるようにする
↑他のセッション「太平洋をまたいで手をつなごう：日本におけるグローバルプロダクト開発」で仕事において暗黙知みたいなものをつくらない具体的に役割を指示しなさいという話があった。通じるものがある。
信頼
リーダーがメンバーを信頼している、マネージャーがチームを信頼している
信頼することにより細かな指示が不要になる。
一番知っている人たちが考えて産み出すもののほうが良い物が作れる。
チームが一番プロダクトを知っていて、チームが一番良いアイディアを出すはず。
信頼できる関係を作るには双方の人間性、理解力が必要
マネージャーとリーダーの役割の違い
マネージャー（PDM,PJMとは別）
・目標設定←チームに何を求めるか 計測可能な目標
・コーチング
・採用、人の管理、育成
リーダーシップ （環境を用意する）
メンバーのやる気を起こさせる
メンバーの得意分野を伸ばす
Empowerチームとは
メンバー全員スキル・能力を持ってる
チームはベストな解決策を出し提供できる
チームは権限をもっている
権限を持たせるためにはメンバー、リーダーの素養も必要。
HireSlowFireFastがシリコンバレーではやっている。
レベル低い人を雇うと細かい指示が必要になったり信頼できなかったりする。
そういうのが変なルールを作るもとになるのでそういう人が入らないよう、入ってしまった場合は排除する必要がある
プロダクトマネージャーは
3,5年先のプラン、素晴らしさを見出す
プロダクトマネージャーが素晴らしさを見いだせてなければそのProductうまくいくことはない。
Transferwiseがどうグローバル展開したか Kaarel Kaddu
サービスについて
送金の機能提供
最初はヨーロッパ内の送金、徐々に世界に
スピード重視
チームでの意思決定、チームが失敗から学ぶ
マネージメントMTGなし
早い意思決定←チームが一番カスタマーを理解している
顧客重視
・Price 価格は妥当か
・Speed 早く提供
・Convenience 便利に使えるか
・Coverage 色んな人、場所で使えるように
ProductManagerには
・経営出来る資質がある人
企業の進みたい方向性を理解し、文化にFit出来る人が良い。
↑こういう人だと権限を渡しやすい。
ProductManagerチームは
・自治と責任がある人
自由に決めるではなくチームと話した内容を吸い上げる
・視点は顧客へ
可視化されたデータをもとに意思決定
海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ 川口 恭伸
https://speakerdeck.com/kawaguti/agile-product-management
海外カンファで得たもの
ジュネーブのDevOps Dayにいって参加者に何をしている人か聞いたら地元企業で開発職で働いているとか。数年前から病院とか銀行で企業で開発職の人を雇っているらしい。そして会社は最近アジャイルに移行したとか。別にCEOが変わったとかでなく同じ経営者でやり方を変えたらしい。海外にいくと色々な気づきがあるねという共有。
アジャイルとプロダクト開発
とある企業で開発者がリリース日を決めているという話があった。その方式にして1年半バグが発見されなかったとか。バグ対応コストを考えるとなかなかの成果だなあと思った。ビジネス都合で1日、2日短縮するためにテストを簡略化させてリリースして結果バグでて対応に工数かかり全体としては工数かかったという失敗例より開発者が十分に準備できましたっていう時にリリースしたほうが健全だよなと思った。
プロダクトディスカバリー
プロトタイプによって効果的な解決策を見つける。解決策は価値があり、使いやすく、実現可能で生き残れるもの
多くの会社はそれぞれの項目が分業制である。
価値を見つける＝事業
実現可能＝開発
使いやすく＝デザイン
それぞれの項目を同じペースで煮詰めていくことで答えを発見できる。
それぞれの役割の人を1つに集めてプロダクト開発を進めていくべきではという話。
PMの仕事は難しいものをどうかんたんにさせるか
すぐ出来るが価値が少ない仕事をやることにフォーカスしすぎてプロダクトの価値を下げがち。どう難しいが価値のあるタスクを実行可能な状態にするかがPMの仕事
アジャイルとウォーターフォールの違い
アジャイル 動くものをコンスタントに提供するのに注力
徐々にリリースに向けてプロダクトが良くなる
ウォーターフォール 仕様書を提供するのに注力 最後増員して頑張る
リリース以降徐々にプロダクトが良くなる
アジャイル タスクの管理方法
バックログにすべて入れる。優先順位はつける。
開発チームはバックログを開発に適切な形に分割する。
バックログは3スプリント先くらいまで開発着手できる粒度であればいい。
それ以降は荒い粒度でいいので入れておく
プロダクトオーナーは↑の内容でプロダクトバックログを整える責任がある
予算を確保し顧客の要望をかなえ最大のROIを目指す
ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織 佐藤 里佳
一番衝撃だったのは学生時代お世話になったノマノマイェイの作者だったこと笑
ピクシブってアニメの会社のイメージが強かったんですがいろんなプロダクトを開発している会社なんですね。
プロダクトマネージャーは 28/200 28人いるそうです。
シニア、普通、アソシエイトと3段階にレベルが分かれている
ピクシブのPMとは
プロダクトのあるべき姿を定義する スキル
多職種からなるチームのちからを最大化 スタンス
基礎スキル（仕事の仕方？）とスタンスをみにつけ
プロダクトマネジメントトライアングルにてどの専門領域を育てていくか決める
プロダクトマネジメントトライアングルとは↓
http://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja?source=post_page-----d18d1855ef65----------------------
PMコンピテンシーを作り、それぞれの強みを認識してアサインしたりPM同士が協業しやすくしている。
複数のPMがプロダクトに関わる場合はプロダクトオーナーが意思決定するようにしている。（意思決定者は一人）