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

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

プロダクトマネジメントのコミュニティ/イベント/メディアまとめ

これは何か

プロダクトマネジメントについて、どこで情報収集してるの?」と聞かれることが多いので、自分が日常的にチェックし参加しているものをここにまとめておきます。

今後も新たに見つけたら都度更新していきます。記載されているもの以外でオススメがあれば教えてください。

 

コミュニティ・イベント

国内

Product Manager Conference

(恐らく)国内最大のプロダクトマネージャーのイベントです。毎年豪華な登壇者が学びになるセッションをしてくれます。

そして実は自分はこちらの運営メンバーをやらせてもらってます。今年は初のオンライン開催となるのでお楽しみに!

 
POStudy結構な頻度で「PO祭り」というセッション大会&ワークショップが行われています。(個人的な印象ですが)より現場のリアルな話が聞けて面白いです。

 

Product Managers Japan

Slackチャンネルでのコミュニケーションがメインですが、たまにオフ会でLT大会が行われます。

 

Product Management Night Tokyo

最近始まったイベントで、海外のProduct Management Festivalの日本支部的な位置付けだそうです。初回イベントに参加させてもらったんですが、かなりクオリティが高く今後に期待です。

続きを読む

プロジェクトスコープを決める際に考える2つのこと

f:id:swnws322:20200726124744p:plain

はじめに

プロダクトマネージャーの仕事のうち、最も実力が試されるイベントの一つとして、「プロジェクトの計画」が挙げられます。ここで言う「プロジェクト」とは、日々数字を見て改善するグロース的なプロダクト開発とは違い、ある程度大きな投資(Investment)をしてある程度大きな成果(Return)を得ようとする、中長期に渡って進めるプロダクト開発のことを言います。アジャイルとかウォータフォールとかの開発手法の違いではありません。

 

プロジェクト計画の中で重要なことの1つが、プロジェクトスコープの策定です。この決め方次第でプロジェクトの成否は決まってしまうと言っても過言ではないと思います。というわけでスコープの決め方についてのポイントをまとめていきます。

 

余談

いきなり余談ですが、こちらの記事にもあるようにプロダクトマネージャーとプロジェクトマネージャーは担うべき役割が違います。

f:id:swnws322:20200725203633j:plain

https://aboutproduct.jp/media/career/86/より引用

 

もし組織が充実していて、プロダクトマネージャーとプロジェクトマネージャーを担う人が完全に分かれているのであれば、上記の図にように役割分担しても問題ないでしょう。実際に自分はリクルート時代にプロジェクトマネージャーとして大きなプロジェクトをリードしていたことがありましたが、その際は別のプロダクトマネージャーが方針を決めて結果に責任を持っていました。

しかし、きれいに分担できるほど恵まれた組織は多くはありませんし、完全に分担してしまうと目的が異なる2人のコミュニケーションコストがそれなりに高くなるデメリットもあります。つまりプロダクトマネージャーがプロジェクトマネージャーの責務も担うケースは多々あるのです。こちらの記事にもあるように、プロジェクトマネジメントはプロダクトマネージャーにとっても必要なスキルの一つと言えます。

時々「プロダクトマネジメントとプロジェクトマネジメントは完全に異なるものだ」のように二項対立的な主張を見かけるので、必ずしもそうではないよということを余談として書かせていただきました。

 

続きを読む

プロダクトマネージャーの転職活動記

  • はじめに
  • 前提:経歴
  • 前提:転職活動を始めた経緯
  • 準備:企業選びの軸を言語化する
  • 準備:自分のスキルや成果を言語化する
  • 実施:転職サービスを選ぶ
  • 躓き:面接が通らない…!
  • 問題:Why/WhatとHowに一貫性がない
  • 問題:プロセスのアピールになりがち
  • 再開:内定3社
  • おまけ:よく聞かれた質問

はじめに

2020年6月に株式会社CAMPIFREを退職し、株式会社グロービスに転職しました。

今回が3回目の転職なのですが、組織によって役割が異なるプロダクトマネージャーとしての転職には独特な難しさがありました。

そんな中、こちらの記事が非常に参考になりました。

note.com

というわけで、自分の経験も誰かの役に立てばいいなと思い、転職活動記を残します。

 

前提:経歴

自分の過去の経歴はざっくりこんな感じです。

  • Javaエンジニア(4年)
  • インフラエンジニア(3年)
  • プロジェクトマネージャー(4年)
  • エンジニアリングマネージャー(3年)
  • プロダクトマネージャー(2.5年)

過去3社(出向先を含めると4社)に在籍し、製造業企業の社内SE・大規模toCサービスのPjM・ベンチャー企業の新規事業のPdMなど、それなりに幅広く経験してきました。

 

続きを読む

安定してパフォーマンスを出せている組織は危険と思え

f:id:swnws322:20200602220240p:plain

組織改革・組織成長はマネージャーや経営者にとって常に向き合うべき永遠のテーマです。しかし実際に取り組んでみると非常に難しいものです。業種や組織規模によってアプローチもゴールも異なるため、「これをやればOK」という銀の弾丸は存在せず、組織の問題と向き合って必死に闘うことが求められるためです。

 

では、組織改革のゴールはどのように定義すればいいのでしょうか?

 

組織の課題として、

  • 組織内コミニュケーションが円滑に進まない
  • 生産性が上がらずパフォーマンスが上がらない

といったものがよく挙げられますが、組織内で円滑なコミニュケーションが可能になり、安定したパフォーマンスが出るようになれば「組織改革は成功した」と言えるのでしょうか?

 

組織の問題を過去の歴史から学ぶことができる2冊の書籍を引用しながら考察していきます。

 

日本軍とソニーの失敗から学ぶ「適応の弊害」

書籍「失敗の本質」では、第二次世界大戦前後の戦いにおける日本の敗戦の原因を、日本軍の組織的欠陥の側面から分析しています。

日本軍の組織の特徴として「過度な精神主義」「合理的判断よりも情緒・人情重視」「意思決定・情報伝達の仕組みの不備」など様々な要因が挙げられており、ザ・ダメな組織の典型例として学ぶことができます。その中に「特定の状況に適応しすぎて不測の事態に迅速に適応できない」という弱点が強調されています。

問題は、そうした概念を十分に咀嚼し、自らのものとするように努めなかったことであり、さらにそのなかから新しい概念の創造へ向かう方向性が欠けていた点にある。したがって、日本軍エリートの学習は、現場体験による積み上げ以外になかったし、指揮官・参謀・兵ともに既存の戦略の枠組のなかでは力を発揮するが、その前提が崩れるとコンティンジェンシー・プランがないばかりか、まったく異なる戦略を策定する能力がなかったのである。

失敗した戦法、戦術、戦略を分析し、その改善策を探求し、それを組織の他の部分へも伝播していくということは驚くほど実行されなかった。これは物事を科学的、客観的に見るという基本姿勢が決定的に欠けていたことを意味する。

これらの失敗の原因をつなぎ合わせて、その最も本質的な点をつきつめていくと、まことに逆説的ではあるが、「日本軍は環境に適応しすぎて失敗した」といえるのではないか。

陸軍は西南戦争日清戦争、長いソ連との戦いを通じて、歩兵の近接格闘と精神力が勝利のカギだと信じていました。また海軍は艦隊決戦主義という思想を持ち、艦隊の戦闘スペック(大砲の火力や数など)が勝利のカギだと信じていました。この強い信念・思想のおかげで太平洋戦争までは「強い軍隊」として実績を積んでいました。故に太平洋戦争もこの信念・思想で勝てると信じて疑わなかったのです。

しかし太平洋戦争の相手である米軍は技術力をフルに活用して量産型戦闘機やレーダーを開発し、既存の枠組み捉われない新しい戦術を駆使してきました。技術力の前に精神力など無力に等しいのです。また米軍は太平洋諸島の中での戦いに合わせた戦術を準備してきましたが、日本軍は仮想敵をソ連としていたため、陸上戦の戦術しか持ち合わせていませんでした。その結果、日本軍が想定していない状況が多発し、気づいた時には圧倒的に劣勢になり、結果的に敗戦に繋がってしまいました。

 

 

続きを読む

行動経済学から学ぶプロダクトマネジメントに潜むバイアスたち

f:id:swnws322:20200506173822p:plain

これは何か

行動経済学プロダクトマネジメントに活かすために、人の様々な行動パターンやバイアス、そしてその活用方法を自分なりに整理したものです。

※記事の最後に参考にした文献を記載しています。
※とてつもなく長いのでブックマークして必要な時に参照するのがオススメです。
※今後も日々更新・追記していく予定です。

 

インデックス

  • 更新履歴
  • 行動経済学とは何か
  • プロダクトマネジメントとどう関係するのか
  • 前提:システム1とシステム2
  • 人は選択の機会を欲しながら意思決定を避ける
  • 人は集団に左右される
  • 人はすぐに思いつくものに左右される
  • 人はイメージに左右される
  • 人は感情に左右される
  • 人は損をすることを嫌う
  • 人は所有物を過大評価する
  • 人は後から辻褄を合わせる
  • 人はピークを評価する
  • 人は状況を評価しない
  • 人は相対的にしか評価できない
  • 人は全体を無視し一貫性を追い求める
  • 人は難しい問題を回避したがる
  • 人はお金が絡む世界と絡まない世界で性格が変わる
  • 人は見かけの労力にこだわる
  • 人は根拠のない自信を持っている
  • 人は希少なものを探索したがる
  • 人は予測できないものを探索したがる
  • 最後に
  • 文献

 

更新履歴

  • 2020/05/07 初版
  • 2020/05/10 「人は状況を評価しない(対応バイアス)」追記、文献2件追加
  • 2020/05/16 「人は集団に左右される」「人は状況を評価しない」一部追記、文献1件追加
  • 2020/06/07 Social Proofについて追記、文献1件追加

 

行動経済学とは何か

行動経済学(こうどうけいざいがく、英: behavioral economics)とは、経済学の数学モデルに心理学的に観察された事実を取り入れていく研究手法である(Wikipediaより)

自分なりにまとめると、「人間は合理的な判断をする」(=エコノ)という前提で成り立っていた既存の経済学に対し、「人間は必ずしも合理的な判断をしない」(=ヒューマン)という前提で人々の経済活動を分析する学問です。より簡単に言えば「経済学×心理学」です。

例えば、エコノは情報を分析して自分の利益を最大化する合理的な選択を必ずします。しかし周りにそんな人はどれくらい存在するでしょうか。誘惑に負けて不要なものを買ってしまったり、期待値が圧倒的に低い宝くじに手を出してしまったりと、世の中には全く合理的でない判断に溢れています。この非合理を紐解く学問が行動経済学です。

 

続きを読む

PMは自分を組織に食べさせることを考える

酔った勢いで買ったのか全く記憶にないが、自分のKindleにこの本が入っていた。

 

 その中のハサミムシの章にこんな記述があった。

 ハサミムシは肉食で、小さな昆虫などを餌にしている。しかし、孵化したばかりの小さな幼虫は獲物を獲ることができない。幼虫たちは、空腹に耐えながら、甘えてすがりつくかのように母親の体に集まっていく。これが最初の儀式である。(中略)あろうことか、子どもたちは自分の母親の体を食べ始める。そして、子どもたちに襲われた母親は逃げるそぶりも見せない。むしろ子どもたちを慈しむかのように、腹のやわらかい部分を差し出すのだ。

これを読んで衝撃を受ける共に、ふと「プロダクトマネージャーもこうあるべきなのかなあ…」という物思いにふけてしまったので、その内容をつらつらと書いてみる。

 

「自分をクビにする」という考え方

EMFMのep15にてカオスエンジニアリングとVPoEの権限委譲の話題があり、その中で以下のような話があった。

・2年か3年で自分をクビにするのが自分の仕事
・その期間にスキームや仕組みを作れないなら自分は無能だ
・自分の仕事をなくすことをしなければ次のフェーズには進めない

組織が個人のスキルに依存してしまうと、その個人のポテンシャル以上の成長は見込めないし、その個人がいなくなったときに組織が崩壊してしまう。ただ依存される個人の立場になってみると、その依存されている状態が心地よくなってしまい、その状況を変えようとしなくなるリスクがある。

特にプロダクトマネージャーやエンジニアリングマネージャーは、どうしても多くのスキルを求められるため依存度が高くなってしまう。しかし彼らのミッションは「プロダクトの成長を最大化すること」「エンジニア組織のパフォーマンスを最大化すること」であって、「自分が組織において重要な位置にいること」ではないはず。

常に長期的かつ客観的な視点からミッション遂行のために何をすべきかを考えると、「自分をクビにする」という考え方は大切なことだなあと思った。

続きを読む

RSGT2020に行ってないけどレポートをする

2020年1月8日から3日間、Regional Scrum Gathering Tokyo 2020が開催されました。

2020.scrumgatheringtokyo.org

 

 

もちろん…

 

 

行ってません(`・ω・´)キリッ

 

 

去年初めてこのイベントの存在を知り、タイムラインに流れてくるスライドが学びになるものばかりだったので、行ってないけどレポート記事を書いてみました。

今年は行こうと思ってたんですが、完全に申込を忘れてしまっていたので、今年も「行ってないけどレポート」になります。

 

 

プロダクトバックログでアイテムを管理しているとき、どうしても視線の先にOutput(=成果物)を置いてしまいがちだけど、Outcome(=価値)にフォーカスを当てることで良いプロダクト開発が実現できる、という内容。事例の「ダイヤ」のようにOutcomeの期待値を可視化して共有することで、POだけでなく全員が「何を作るべきか」を強く意識でき、強い組織が生まれる。

ただスライドにもあるように、これを徹底するためにはしっかりOutcomeの計測ルールを決めること、そしてしっかり労力をかけずに計測できる基盤を用意することが重要だと思う。なんとなくでOutcomeを評価してしまったり、毎回一から計測していると、すぐに陳腐化してしまいそう。

 

POとしてまずはOutcomeの言語化のパターン化をして、プロダクトバックログアイテムに記載することから始めてみよう。

 

続きを読む

【スポンサーリンク】