プロダクトマネージャー・カンファレンス（pmconf）2018 1日目まとめ
今年もプロダクトマネージャー・カンファレンスに行ってまいりました！
昨年に続き多くの学びと刺激をもらいに来ました。
１日目のまとめを書きます。
全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。
1.Cut featureとWon't fixはPMだけが言えること
楽天トラベルの熊谷さん。
楽天トラベルは国内でのシェアは強いものの、旅行市場においては国内旅行者の減少と海外サイト（Booking.comなど）の参入もあって、世界に出て行く決断をしたそうです。
世界で愛されるプロダクトになるために３つのポイントを挙げていただきました。
- Generalize
- Communication
- Decision Making
※ちなみにこの３つの定義はpmconf2017でも楽天トラベルの齊藤さんが提言されていました。楽天に根付く考え方なんですね。
Generalizeは最初に機能のRequirementを定義するときにGeneralize、つまり何か特定のセグメントやドメインに特化せずに一般化することが大事ということ。
海外進出する際のハードルとなるのが、タイムゾーンや法律、個人情報の扱い（最近GDPRが話題です）など。これを考慮して一般化して設計することで、スピーディーに海外展開できる。
次の２つは海外に限った話ではなく、PMとして持っておくべき考え方です。
Communicationは"Positive"（問題は必ず解けるというスタンス）と"Open Communication"（しっかり議論して問題の本質を紐解く）という姿勢を持つべきとのこと。
そして最後のDecision Making。
バグトリアージのルールはこんな感じらしい。
ただ実際このHighとLowって定量的に仕分けるのってすごく難しく、各ステークホルダーの視点によっても変わってくる。例えばCSにとってはユーザーが最優先だけど、営業にとってはクライアントが最優先。
ここで重要な考え方がこちら。
Cut feature & Won't fix はPMだけが決められること
これはPMにとって本当に重要な役割。
「何がプロダクトの成長に繋がるのか」を一番知っているPMが「削る」と「やらない」をDecision Makingしないといけない。そしてその決定がプロダクトにとって最適でないといけない。
さらにはその決定をステークホルダに納得してもらうためには、普段からしっかりとCommunicationをして信頼を勝ち得ないといけない。
これ簡単に言うけどめちゃくちゃ難しいことです。個人的にはPMとして１人前かどうかはこれができているかどうかで評価できると思ってます。
PMとしての「あるべき姿」を再認識することができました。
唯一「やらないことを決められる」という責任感を持って生きていきます。
2.リズム・ステータス・KPIを共有することでチームは自律的に動ける
グロース・アーキテクチャ＆チームス株式会社の鈴木さん。
PMのよくある悩みとして、ステークホルダとのコミュニケーションロスや認識齟齬があります。これを組織としてどう防ぎに行くか、というお話。
シンプルにまとめていただきました。
- リズムの共有（リードタイム、リリースサイクル、プロセス・・・）
- ステータスの共有（アイデア、検討中、実装可能・・・）
- KPIの共有（アテンション、売上、コスト、フィードバック・・・）
つまり各案件やスプリントにおいて、
「いつやるのか」「いつ決まるのか」
「今どう言うステータスなのか」「着手してよいのか」
「案件の目的は何か」「リリース後何を測定するのか」
を可視化して共有することでチームを自律させることができる。
これは間違いなく重要で、メンバーの当事者意識や心理的安全性を高めるためにも必要なことだと思います。各情報が不明確だと何言っていいかもわからないので、自然と受け身の姿勢に入ってしまいます。今の自分のチームはリズムの共有が不足してるかも…
スライドはこちら
3.便利なことが明白な機能の実装をあえて行わずに、ブランディングを優先する
サイバーエージェントの長瀬さんです。
AbemaTVが開局して２年の変遷をお話いただきました。
AbemaTVのブランディングは「インターネットテレビ局」。
NetflixやHuluのような「オンデマンド×有料」ではなく、「リニア×無料」を目指したとのこと。つまり「点けたらやってる」という元来のテレビと同じUXを目指したそうです。
このブランディングが徹底されていた…！
簡単な例でいうと、番組表機能はあえて新聞っぽい番組表のUIにしたそうです。もっと見やすいUIはあるにもかかわらず。
そして一番衝撃だったのが「縦画面対応、オンデマンド機能の先送り」。
この２つって、現代においては絶対に求められる機能ですよね。IGTVとか縦型動画に特化しているし、若者は見たいときに見れないのが我慢できない時代。
それをわかっていながら開局時には実装しなかった。
なぜか。
「インターネットテレビ局」だから。
まずは横画面とリニアにこだわって、テレビらしさを全面に出したのです。
そうやって１年かけてブランドを構築した後、この２つの機能は実装されます。
いやーこの決断はすごい。
必ずしも便利な機能を実装することと、ブランドを確立することは別の話なので、フェーズごとにどちらを重視するのかをしっかり見極めて実装方針を決めて行く必要がある。
またAbemaTVは後から実装する際も大量のモックを作ってUI/UXを検討し、さらに市場から忘れられることを防ぐために話題性のあるネタを絶やさないようにリリースのバランスを取って行く…
めちゃめちゃ戦略的ですなー！
これはよい学びだ…！
4.新規参画者には花を持たす
今年発足したZOZOテクノロジーズの「PMチーム」の立ち上げのお話。
新規参画したPMのパフォーマンスを最初からどう最大化するか。
リクルーティング → オンボーディング →グロース
面白かったのは採用後の3から6ヶ月くらいまでのオンボーディングの話。
ポイントは「花を持たす」こと。
- 3ヶ月以内に達成する成果を明確に
- トップが成果にコミット
- 成果を大きくアナウンス
これは超大事！PMは信頼されてナンボの役割だから、最初にこれによって成果が出るとその後のグロースの幅は大きく変わるはず。
PMって何かを目に見えるモノを作り出すわけではないので、ともすれば成果が見えづらいポジション。成果が出ないうちはなかなかエンジニアやステークホルダから信頼されないが、最初に成果をアピールできると仕事がやりやすくなるはず。
またこれはPMに限らず、エンジニアや他の役割の新規参画者に対しても、モチベーションを上げるために、定着させるために重要なことだと思う。
チームビルディングの勉強になった。
スライドはこちら。
5.仮説が正しいことを証明することを仕事にするのではなく、仮説が正しいかどうかを検証し学ぶことを仕事にする
ラクスル 泉さん。
このプレゼンは名言が多すぎた！
ラクスル泉さん
— 久津佑介(HisatsuYusuke)@プロダクトマネージャー (@Nunerm) November 6, 2018
名言の数々…！
・「何を開発するのか」＝投資判断
・「失敗をデザインする」
・安い失敗を重ねることで投資対効果を最大化する
・仮説が正しいことを証明することを仕事にするのではなく、仮説が正しいかどうかを検証し学ぶことを仕事にする
#pmconfjp pic.twitter.com/AyOsTjJ4Li
その中でも
「仮説が正しいことを証明することを仕事にするのではなく、仮説が正しいかどうかを検証し学ぶことを仕事にする」
はグサッと刺さりました。
PMに限らずある程度同じ事業やプロダクトを担当していると、「自分の仮説＝正解」みたいに考えがちで、いかにその正解に向かって組織を動かすかに注力してしまう。
で、リリースしてから失敗に気づく。
泉さんは何度も何度も「リリースしてから失敗に気づいても遅い」と仰ってました。
開発するということは投資することと同じなので、リリースしてから失敗するとただの無駄な投資になってしまいます。誰も幸せにならない開発です。
なのでリリースする前に何度も仮説が正しいかどうかを検証し、そこから学びを得てリリースをすることで、投資を無駄にすることなく成功に導く可能性が上がるというわけです。そしてその仮説検証ではプロトタイピングツールなどを使って高速に効率的にサイクルを回すことで、費用対効果を最大化することができる。
このことを「失敗をデザインする」と表現されていました。
これは素晴らしい内容でした。
リリースを急ぐあまりに仮説＝正解というスタンスになってはいけない。
あくまで「仮説が正しいか」をしっかり検証してからリリースしないといけない。
恐らく一度成功体験を積んだPMは自信が過信になってしまい、仮説を正解と扱ってしまいがちだと思います。その時はこの内容を思い出して欲しいです。
---------------------------
他にもたくさんの気づきはあったものの書ききれないので、こちらをご参照ください。
では２日目に行ってまいります。
