めざせプロダクトマネージャー( @Nunerm )

プロダクトマネジメント・エンジニアリングマネジメントなどについてアウトプットします

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

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

2020.scrumgatheringtokyo.org

 

 

もちろん…

 

 

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

 

 

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

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

 

 

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

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

 

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

 

続きを読む

2019年の振り返りと2020年の抱負

あけおめ!(`・ω・´)

2019年の振り返りと、2020年の簡単な抱負をまとめてみます。

 

仕事

何より2019年は転職が大きなイベントでした。

大きくて優秀な組織から小さく未熟な組織に移り、裁量と責任を持ってプロダクトのグロースに全力を注ぐことを望んだ転職でした。結果としてもCAMPFIRE Ownersという新規サービスの責任者を任せてもらい、9月にローンチをすることができました。

が、振り返ると想像を遥かに超えたハードな環境でした。リクルートとのカルチャーギャップが大きかったのも一因ですが、何より人が圧倒的に足りていないので、とにかく「何でも屋」としてこの1年弱を動きまわりました。

 

予算編成、事業計画策定、組織整備、業務フロー整備、社内SE、カスタマーサポート、オウンドメディア運営、エンジニアリングマネジメント、要件定義、テスト、人事制度検討、採用活動…

 

人間頑張れば一通りのことはできます。が、せいぜいそれぞれ40点ぐらいの出来にしかなりません。サービスローンチまではそれでも良かったのですが、よりサービスを成長させていくためには40点ではダメです。

なのでここからは各分野でより優秀な人にどんどんタスクをお任せして、80点〜100点を目指していく所存です。2020年の抱負は「人を動かす」「脱・何でも屋」。 

 

副業

2019年から人生で初めて副業を始めました。目的は、自身のスキルがCAMPFIREとはまた違う環境で通用するのかを試してみたくなったから(と、2020年は出費が増える見込みなのでシンプルに稼ぎたかったから)。

まだまだ成長に貢献できるレベルには至ってないので詳細は控えますが、既に多くの学びを得られています。今ちょうど読んでいる書籍「サイロ・エフェクト」にもあるように、一つの組織に属しているとその中での基準や文化に何の疑問も持たなくなりがちです。プロダクトマネージャーたるものプロダクトや組織に対して冷静かつ客観的な視点を持つことが求められるので、週1回でも全く異なる文化の組織の中に入ることで、自組織のおかしな「暗黙の了解」に気づけます。これは非常に良い効果でした。

2020年は短時間でもしっかり成果を出して貢献していき、その経験を本業の方にも還元できるようにします。

 

登壇

プロダクトマネージャー、エンジニアリングマネージャー関連の登壇はこの1本だけでした。ちょっと少ないので今年は増やそう。

engineering-manager-meetup.connpass.com

→スライドはこちら

 

あと採用関連でこれに出ました。パネルディスカッションのみ。

mercari.connpass.com

 

あとはkiitokさんにメンター登録させていただいた関係で、キャリア関連の登壇をたくさんさせていただきました。自分のキャリアの棚卸しもできたし、主に若手エンジニアの悩みなどを知ることができたので、この機会を与えていただいたkiitokさんに感謝。

kiitok.connpass.com

→スライドはこちら

 

rtlabo.connpass.com

→イベントレポはこちら

 

kiitok.connpass.com

 

 

取材・メディア掲載

今年は取材していただく機会が多くありました。おそらく一月中にもう一本、キャリア関連の記事が出るはず…?

特にヌーラボさんの取材は、2018年の登壇用スライドを見ていただいたいて取材に繋がりました。日常的なアウトプットが機会を生み出すことをひしひしと実感しました。今後も続けていこう。

backlog.com

new-frontier.org

 

イベント運営

2019年は初めて2つの大きなイベントの運営お手伝いをさせていただきました。

1つ目がEngineering Organization Festival 2019

広木大地さんがSlackで「ボランティア募集中です」と書いていたのをみて、完全に興味本位で申し込んでみました。大規模イベントの運営は初体験だったのですが、みんな良いイベントを作ろうとめっちゃ頑張ってることがよくわかりました。

 

 

2つ目がプロダクトマネージャーカンファレンス2019

こちらはメルペイの丹野さんから「モデレーターやってみない?」とお声がけいただいたのがきっかけ。当日はめちゃ緊張しましたが、多くの優秀なPMの方とお話しできて楽しかったです。

また今回は前回から来場者数を2倍以上に引き上げ、マルチトラック、スポンサーブース設置、など新たなチャレンジが多かったのですが、こちらも「学びを持って帰ってもらいたい」という皆さんの熱量がすごく、かなり良いイベントになったと思います。今月の打ち上げが楽しみです。

 

2つとも2020年も関わらせていただきたいなーと思ってます。

  

その他

プロダクトマネジメント関連では、NewsPicksアカデミアの及川ゼミに参加したり、UX DAYS TOKYO 2019に参加したりと、自己投資額がなかなかエグいことになってると今気づきましたw

ちゃんと結果を出して取り返そう。

 

インプットとして読書量は56冊でした。ちょっと少ないのと、それに対するアウトプットも少なかったので2020年はしっかり時間作ってインプット&アウトプットしていこう。

bookmeter.com

 

あとどうでもいいですが、趣味でやっている作曲+1人演奏が全く成長できなかったので、2020年はしっかり取り組んでYouTuberになることを目標にします。

 

 

 

というわけで2019年の振り返りと2020年の簡単な抱負でした。

みなさま今年もよろしくお願いいたします。

 

エンジニアリングマネージャーの情報コントロール術

この記事はEngineering Manager Advent Calendar 2019の19日目の記事です。

 

久津(@Nunerm)です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。

 

この記事では、エンジニアとステークホルダーの間で情報のINとOUTをコントロールする際に気をつけていることをまとめます。組織によってベストプラクティスは異なると思いますが、何かの参考になれば幸いです。

 

前提:情報はオープンにするべき

「情報のコントロール」とは情報を意図的に隠すことではありません。例えばSlackでのDMやプライベートチャンネルの利用率が高いと、情報の非対称性によって属人化が進み社内政治が蔓延ります。

※ EOF2019で登壇されていた@tokorotenさんの「チャットコミュニケーションの問題と心理的安全性の課題」は必見です。

 

もちろんそういう組織を目指したいのではありません。心理的安全性のレベルを高く保つためにも、またエンジニアチームの成長のためにも情報は可能な限りオープンにするべきです。

 

とはいえ全ての情報がオープンになることで生まれる弊害もゼロではありません。整合性の取れてない一時的な情報を受け取ることによって、エンジニアが必要のない思考や作業に時間を取られてしまったり、ステークホルダーに伝えたいことが変な形で伝わってしまって誤解を解くために奔走したり…

なのでマネージャーとしてその間に入り多少の情報加工を入れることで、チームの生産性の低下を防ごうと心がけています。

 

イメージは編曲やDTMで使うイコライザー(EQ)」です。

不要な周波数の音をカットしたり、目立たせたい音の周波数を強めたりする機能です。

f:id:swnws322:20191215115356j:plain

 

続きを読む

プロダクトマネージャーの思考整理術

この記事はProduct Manager Advent Calendar 2019の15日目の記事です。

 

久津(@Nunerm)です。CAMPFIREでプロダクトマネージャーをやっていて、CAMPFIRE Ownersという融資型クラウドファンディングのサービスを担当しています。

 

今日は自分が実践してる「プロダクトマネージャーの思考整理」に関する話を書きます。日々忙しいプロダクトマネージャーの頭の中のデフラグの手助けになれば幸いです。

 

プロダクトマネージャーには考えることがたくさん

このアドベントカレンダーでも度々引用されている「INSPIRED第2版」では、プロダクトマネージャーの責任を

可能性を評価し、何を作って顧客に届けるのかを判断することだ。

(INSPIRED第2版より引用)

と定義しています。

「可能性を評価する」「何を作って届けるか判断する」と簡単に書いてありますが、実際にこれをやるためには、マーケットの状況を見極めつつプロダクト開発の方針を決め、実際に数字を見ながら細かい機能改善に関する意思決定をしていく、といったような多様な活動が求められます。つまりマーケットのことを考えたりプロダクトのことを考えたり、また抽象的なことを考えたり具体的なことを考えたりと、プロダクトマネージャーは考えて判断する「対象」と「抽象度/具体度」の種類が多種多様なのです。

 

自分は新規事業を担当しており、今年の9月にローンチしたばかりなので、まだまだ検証し切れていない仮説だらけで具体的な課題が次から次へと生まれてきます。またチームメンバーもまだ少ないので、自ら手を動かすタスクがたくさんあります。そんな状況だとどうしても目の前の課題に集中してしまい、視野が狭くなってしまうことがあります。認知やCVRを上げるための打ち手を考えるとか、新機能のPRD書くとか「具体的なタスク」で頭の大半のリソースを使ってしまいます。

そんなタイミングで経営陣から「マーケットの様子が変わってきたけどどう考えてる?」と聞かれると、「へ?」と何も答えを用意できず「あ、ああ…もちろん良い感じに考えてますよ」と上擦った声で見栄を張り、直後に慌てて考え始めてみると、今の目の前の課題がそんなに重要でないと気づく始末。これはイケてない。

 

プロダクトマネージャーたるもの、常に思考を張り巡らせておかなければなりません。

続きを読む

人は自分に必要なものが何だかわからない

iPhoneのケースが壊れたので新しいケースを買った。

 

自分に必要なケースの要件は以下2つ。ちなみに壊れたやつも同じ要件だった。

・手がそんなに大きくないのでリング必須

・片手でスッと出して使いたいので手帳型はNG

 

というわけでこれを買った。

f:id:swnws322:20191117194354j:plain

ちなみに壊れたのはこれ。ほとんど同じ。

f:id:swnws322:20191117195418j:plain

 

よっしゃー使うぜ…と思ったらなんか使いづらい。

前みたいにポケットからサッと出してスッと構えるエレガントが立ち振る舞いができず、モタモタしてしまう。

 

 

原因がわかった。

 

 

右手で持ってリングに指を入れる場合、一番ベストな角度は大体45度である。つまりリングを45度の角度に回さないといけない。

↓こんな感じ

f:id:swnws322:20191117195339p:plain

 

新しいやつは

①起こす

f:id:swnws322:20191117195454j:plain

 

②回す

f:id:swnws322:20191117195613j:plain

この順番でしか45度の角度に回せない。

これやってみるとわかるが、片手ではなかなか難しい。つまりスマホをポケットから出す度に両手を使わないといけない。

 

 

まあまあめんどくさい…(´;ω;`)

 

 

壊れたやつは起こす前に角度をつけられる仕様だった。

f:id:swnws322:20191117200858j:plain

なので動作は「起こす」だけであり、片手で十分。

 

同じ機能のケースを買ったつもりでも、この微妙な違いがかなりのユーザビリティの差を生み出していた。

 

 

 

何が言いたいかというと、

人は自分に必要なものが何だかわからない

ということ。

 

 

毎日使っているiPhoneのケースでさえ、無くなってから初めて気づく「要件」がある。頭では要件を全て抑えているつもりでも、意識していない必要な機能がある。

 

プロダクトマネジメントをする際もユーザーにアンケートやインタビューで「どんな機能が欲しいですか?」「使いづらいところはどこですか?」とか聞いてしまいがちだが、それは暗黙のうちに「ユーザーは何が必要か理解している」という前提に立ってしまっている。

 

ユーザーに聞くのではなく、ユーザーがどういう使い方をしているのか、煩わしい手順は何か、解決したい問題の手段はこれが最適なのか、などをインタビューや観察によって見極めることが求められる。特に無意識に感じていることはインタビューで顕在化しないので注意が必要だ。じっくりユーザーと向き合って見極めないといけない。

 

今回のiPhoneケースの場合も自分で選ぶのではなく、誰かに自分の使い方をじっくり観察してもらって選んでもらうのがよかったかもしれない(そんなことしてくれる人いないけど)。

 

つまり「ユーザーが求めているもの」ではなく「ユーザーが解決したいこと」にフォーカスを当てて、プロダクトに反映していくべし。

 

そうです。ジョブ理論を読みましょう。

 

こちらは以前まとめたスライド(一部レイアウト崩れてます)

www.slideshare.net

 

 

最後にフォード大先生の名言を。

f:id:swnws322:20191117202238j:plain

引用元:http://blog.etn.co.jp/english-henryford/1429.html

 

「もし人々に何がほしいかと聞いていたら、彼らはもっと速い馬がほしいと答えていただろう。」

 

 

 

以上、日々の些細な出来事からの気づきでした。

プロダクトマネージャーに必要な3つのもの 〜Produce Manager Conference 2019より〜

今年もプロダクトマネージャーの祭典"Product Manager Conference 2019"が開催されました。

 

参加者としてはほぼ皆勤賞ではあるのですが、今回は初めて運営メンバーとして関わらせていただき、こちらのセッションではモデレーターも務めさせていただきました。

2019.pmconf.jp

 諸事情によりこちらのセッションの内容はSNSシェアNGなので「めっちゃ緊張した」「登壇者のお二人の熱量が凄くて時間が足りなかった」と振り返るだけに留めて、ここからは2日間のセッションから得た学びを振り返ります。

 

全てのセッションを聞いたわけではないですが、「PMに必要なもの」に共通点があるような気がしたので、「3つのポイント」としてまとめました。

 

  • 1.突破力
  • 2.信頼
  • 3.考え抜く力
  • 余談:初めて運営側に回ってみて

 

続きを読む

不確実性の高い変数が2つ以上あったら、数字のことを考えるのをやめる

プロダクトマネージャーたるもの、プロダクトロードマップやOKR、KPIツリーなど「目指すべき数字」を定義する(または修正する)時間はそれなりに多いと思います。

  

会社によってはゴリゴリに数字を定義して一心不乱にその数字の達成を追い求めるところもあるでしょうし、ある程度定性的な目標を定めるところもあるでしょう。それはプロダクトのフェーズや市場によって変わってきます。

 

私事ですが、先日CAMPFIREに転職して半年間手がけてプロダクトがついにリリースされました。

 

つまり今新規事業のプロダクトマネージャーをやっておるのです。

この新規事業における「目指すべき数字」の定義が非常に難しい…!

なぜなら数字の根拠となるデータが少ないので。

 

もちろん他サービスやユーザーインタビューなどからデータを得ることはできます。が、それが自分のプロダクトに適用した際に同じ結果になるとは限りません。

つまりそこに不確実性が存在しています。

その高い不確実性をどう評価するか、楽観的に考えるか悲観的に考えるかで数字は大きく変わってしまいます。その不確実な要素を不確実なまま立てた数字目標は、現実的な目標ではなくただの「願望」であり、そんな状態で数字目標の妥当性を検討している時間は無駄だと思うのです。

 

 

つまり言いたいのは、

「数字目標を構成する要素に不確実性の高いものが2つ以上あったら、一旦考えるのをやめようぜ」

ということです。

 

特に2つという数字に大きな理由はないです。1つだったらその変数の楽観パターンと悲観パターンの2パターンを想定しておけばよいが、2つになったら2×2で4パターンを想定する必要あり、どんどん考えることが増えていくので、早めに考えるのをやめたいのです。

 

 

ではどうするのか?

検証をするのです。

 

 

先日参加したDevLOVEのイベントにて、書籍「カイゼンジャーニー」や「正しいものを正しくつくる」の著者の市谷さんの登壇を聞いて、非常に参考になりました。

www.slideshare.net

 

f:id:swnws322:20190915161312p:plain


 ここでは主にプロダクトの立ち上がり期に起こりがちな失敗パターンをまとめてくれています。

 

いくつか抜粋。

 

想像だけで始めてしまう

  • プロダクトを作るという意思決定が終わっているが根拠がない
  • ユーザーのことを知っているという思い込みで作り始めてしまう

 

体験の検証をやっていない

  • モックアップとかで検証をしたけどまだ実際に深く使われていない
  • 想定ユーザーの利用体験を成り立たせることができるのか、検証しないまま進めてしまう

 

チャネル検証をやっていない

  • 開発が終わってからチャネルの検討を始めがち(結局広告頼み)
  • 後になって「届けるコスト」が現実的ではないことに気づく


検証結果を都合よく解釈してしまう

  • 自分の見方にバイアスがあることに気づいていない
  • 解釈は正しいがデータが誤っている場合もある


事業を始めてしまう

  • わかりやすい動くものができると関係者の期待が高まり「どうやって売るか、どうやって売れるか」の議論と活動が始まってしまう(検証が終わってないのに)
  • モデルの検証のはずなのにビジネス自体が始まってしまう

 

世の中の理論を鵜呑みにする

  • 世の中の理論を自分の事業に適用してしまう
  • 世の中の理論が根拠としている事例や状況が当てはまるとは限らない

 

 

つまり検証を行わずに、あるいは検証結果を正しく評価せずに具体的な数字ばかり追い求めてると、高い不確実性を伴ったまま成長に挑むことになります。それはかなりのリスクです。

要は「なぜうまくいってるのか正しく理解していない」ので、いずれ「なぜかわからないがうまくいかなくなった」という事態に陥っても不思議ではありません。

 

今何の不確実性が高いのかを正しく把握し、それに向けての検証を的確に行うことで不確実性を下げるが求められるのです(不確実性をゼロにすることは不可能です)。

それまでは具体的な数字目標は一旦忘れてよいと思います。検証後に改めて考えればより良い現実的な目標が立てられるので。

 

 

というわけで、私のプロダクトもリリースしたところなので、これからバシバシ検証していきます。

【スポンサーリンク】