もくもくプロダクトマネジメント( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについて黙々と

プロダクトマネージャーは「組織の視力」を把握しよう

久津(@Nunerm)です。リクルートでPM/EMをやってます。

 

この記事は、Product Manager Advent Calendar 2018の23日目のエントリーです。

 

今回は「プロダクトマネージャーは『組織の視力』を把握するべきだ」という考えを書きます。

 

今いる環境でPMに何が求められるのか?

 

「プロダクトマネージャーの役割とは何か?」

これはPM界隈では常に問われる疑問です。

 

PMに求められるスキルや考え方は多岐に渡っていて、実際に活躍されているPMの方々が持っている武器も様々です。(エンジニア出身の人、マーケター出身の人、デザイナー出身の人…)

 

また組織やマーケットによっても求められる動きや成果は変わります。

プロダクトマネージャーカンファレンス2018で登壇されたのBaiduのPMのChenさんという方のプレゼンでも「アメリカと中国で求められるPMのスキルが違う」というお話がありました。アメリカはニーズがある程度一様化しているため、そのニーズを技術力で解決できるPMが求められる。中国ではニーズが極端に多様化しているため、解決されていない新たなニーズを探すことができるPMが求められるとのことでした。


つまり。

「プロダクトマネージャーの役割とは何か?」

に対する答えは、いくらでもあると思うのです。

 

大事なのは、自分の武器を認識し、かつ今いる組織でPMに何が求められるのかを理解した上で、目指すべきPMの姿をしっかり定義することです。

 

 

では「今いる組織でPMに何が求められるのか?」はどうやって知ることができるのでしょうか?

 

私は「組織の視力」を把握することでヒントを得られると思っています。

 

続きを読む

ボロボロのチームを立て直したエンジニアリングマネージャーのお話

久津(@Nunerm)です。リクルートでPM/EMをやってます。

 

この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。

 

普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。

 

 

さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど…

 

今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。

 

※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。

 

  • 序章:ボロボロのチームにジョイン
  • 第一章:外部環境を整える
    • 1-1.改革の宣言・ブランディング
    • 1-2.意思決定プロセスの整備
    • 1-3.技術的負債の可視化と解消によるメリットの説明
  • 第二章:内部環境を整える
    • 2-1.メンバーへの信頼を示す
    • 2-2.チームビジョンの再定義
    • 2-3.多様な内発的動機と向き合ってくすぐる
    • 2-4.心理的安全性の担保
  • 第三章:自ら成長できるチームへの変貌
    • 3-1.チームのカオスエンジニアリング
    • 3-2.階段を刻み、踊り場で遊ばせる
  • 終章:1年後…

 

続きを読む

CSPO研修(認定スクラムプロダクトオーナー研修)で学んだ「ROIを考え抜く姿勢」

今回はCSPO研修での学びをまとめます。

 

CSPO研修とは?

CSPOとは"Certified Scrum Product Owner"の略で認定スクラムプロダクトオーナーという意味です。認定スクラムトレーナー(CST)によって開催される Scrum Alliance 認定のCSPO研修を受けることで認定されます。

training.odd-e.jp

 

つまりこの研修を受けて認定されたら「あなたをスクラム開発のプロダクトオーナーとして認めます」となるわけです。

 

プロダクトオーナーとプロダクトマネージャーの違いは?

このブログは「プロダクトマネージャー」について書いていますが、プロダクトマネージャとプロダクトオーナーは違います。

 

まずプロダクトオーナーはスクラム開発の役割の一つです。よってスクラム開発をしていない組織ではプロダクトオーナーは存在しません。

 

続きを読む

プロダクトマネージャー・カンファレンス(pmconf)2018 2日目まとめ

前日に引き続きもちろん参加!

 

2018.pmconf.jp

 

今回も全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。

 

 

1.愛をお金に変えよう

2018.pmconf.jp

 

マネーフォーワード今井さん。

所用で席を外してたので全部聞けてはいないんですが、最後のまとめて「愛をお金に変えよう」と仰っていたところが「確かに大事なことだ」と思いました。

 

今回のカンファレンスのテーマは「愛されるプロダクトを創ろう」。

ただいわゆる「無償の愛」ではダメで、企業はそのプロダクトを継続的に成長させる責任がある。そのためにはやはりお金を稼ぐこと、カスタマーやクライアントからお金を頂くことは必要なのです。

 

よって重要な観点は「プロダクトで得た愛をいかに効率よくお金に変えるか」で、マネーフォーワードで言えばより上位のプランにシフトしてもらうためにどのような価値を提供するか。

Appleはいい例で、ユーザーからの猛烈な愛をうまくお金に変えられる仕組み(例:高単価なiPhoneやその付属品、値引きしないスタンス)を作っている。要はユーザーがお金を出すことに対する納得感を醸成できるかが鍵。

これは完全にPMの腕の見せ所で、ブランディングやPR、CSなども合わせて戦略を立てないといけない。

 

愛とお金を稼ごう。

 

続きを読む

プロダクトマネージャー・カンファレンス(pmconf)2018 1日目まとめ

今年もプロダクトマネージャー・カンファレンスに行ってまいりました!

昨年に続き多くの学びと刺激をもらいに来ました。

 

1日目のまとめを書きます。

2018.pmconf.jp

 

全網羅的ではなく、個人的に刺さった言葉をピックアップして解説します。

 

1.Cut featureとWon't fixはPMだけが言えること

2018.pmconf.jp

楽天トラベルの熊谷さん。

楽天トラベルは国内でのシェアは強いものの、旅行市場においては国内旅行者の減少と海外サイト(Booking.comなど)の参入もあって、世界に出て行く決断をしたそうです。

 

世界で愛されるプロダクトになるために3つのポイントを挙げていただきました。

  1. Generalize
  2. Communication
  3. Decision Making

 

※ちなみにこの3つの定義はpmconf2017でも楽天トラベルの齊藤さんが提言されていました楽天に根付く考え方なんですね。

 

Generalizeは最初に機能のRequirementを定義するときにGeneralize、つまり何か特定のセグメントやドメインに特化せずに一般化することが大事ということ。

海外進出する際のハードルとなるのが、タイムゾーンや法律、個人情報の扱い(最近GDPRが話題です)など。これを考慮して一般化して設計することで、スピーディーに海外展開できる。

 

次の2つは海外に限った話ではなく、PMとして持っておくべき考え方です。

Communicationは"Positive"(問題は必ず解けるというスタンス)と"Open Communication"(しっかり議論して問題の本質を紐解く)という姿勢を持つべきとのこと。

 

そして最後のDecision Making

f:id:swnws322:20181106232550j:plain

バグトリアージのルールはこんな感じらしい。

ただ実際このHighとLowって定量的に仕分けるのってすごく難しく、各ステークホルダーの視点によっても変わってくる。例えばCSにとってはユーザーが最優先だけど、営業にとってはクライアントが最優先。

 

ここで重要な考え方がこちら。

 

Cut feature & Won't fix はPMだけが決められること

 

これはPMにとって本当に重要な役割。

「何がプロダクトの成長に繋がるのか」を一番知っているPMが「削る」と「やらない」をDecision Makingしないといけない。そしてその決定がプロダクトにとって最適でないといけない。

 

さらにはその決定をステークホルダに納得してもらうためには、普段からしっかりとCommunicationをして信頼を勝ち得ないといけない。

 

これ簡単に言うけどめちゃくちゃ難しいことです。個人的にはPMとして1人前かどうかはこれができているかどうかで評価できると思ってます。

 

PMとしての「あるべき姿」を再認識することができました。

唯一「やらないことを決められる」という責任感を持って生きていきます。

 

続きを読む

心理的安全性を0から80ぐらいに上げた話

心理的安全性について話したLTのスライドがバズった…!

www.slideshare.net

 

Roppongi Product Manager Meetup #6のLT枠で発表したこのスライドがはてブTwitterでちょっとバズったので補足記事を書きます。

スライドだけでは伝えられない部分も多くあるので。

 

b.hatena.ne.jp

 

続きを読む

心理的安全性の高いチームの作り方と落とし穴

プロダクトマネジメントを進めるにあたって、チーム作りは非常に重要な要素です。

 

私は以前崩壊寸前のアプリ開発チームの立て直しを命じられ、プロダクトマネージャー兼開発ディレクターとしてジョインしました。

前任のマネージャーが「支配型」のタイプで、細かいところまで指示をしミスをしたら叱責をする。反発しようもんならさらに叱責をする。そういう状況で開発を続けてきた結果、エンジニアメンバーのモチベーションがどんどん下り、さらにどんどん辞めていき、プロダクトの品質も悪化の一途を辿っていました。

私は1年弱試行錯誤して何とかようやくチームらしいチームにすることができました。その立て直しの際に重要視したのが「心理的安全性」ですので、簡単に紹介したいと思います。

 

 

心理的安全性とは?

 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。

(引用元:re:Work - ガイド: 「効果的なチームとは何か」を知る)

つまり、チーム内で安心して発言や行動できる心理状態をメンバーが持てていることを示します。「意見を言っても大丈夫」「質問しても大丈夫」とメンバー全員が思える状態です。

 

続きを読む

【スポンサーリンク】