CLOSE

PM Help Hour?(全1記事)

「何を学習したいのか」から考える仮説検証のプロセス Pivotal Labsが取り組む“PMヘルプアワー”のメリットとは

2018年7月7日、株式会社フリークアウト にて「プロダクトオーナー祭り 2018 Summer ~プロダクトマネジメントが世界をツナぐ~」が開催されました。IT関連企業に所属するソフトウェア開発のプロダクトマネージャーやプロダクトオーナーを中心に、それぞれが携わるプロダクトの価値や、マネージャーとしての体験談など、幅広い観点からライトニングトークが繰り広げられました。本記事では、Pivotalジャパン株式会社 Pivotal Labs Tokyo Product Manager 小俣剛貴氏によるLT「PM Help Hour?」の模様をお送りします。

仮説検証のサイクルは、適切に管理しなければならない

小俣剛貴氏:Pivotal Labsでプロダクトマネージャーをしています、小俣と申します。よろしくお願いします。「Pivotal Labsを知っていたよ」という方はどれくらいいらっしゃいますか? 

(会場挙手)

あっ! 3分の1……いや、半分ぐらいですね。ありがとうございます。周りに話しても知っているケースが全然ないので、クラスターの偏りを感じますね。

今日は事情あって子どもを抱えて登壇してしてますが、ご容赦ください。うちの子、さっきのツクルバさんの話あたりから、すごいテンションあがっちゃって。ずっとキャーみたいなこと言ってて。プレゼンの途中で奇声を発するかもしれませんが、ご容赦いただければなと思ってます。

僕からは、「プロダクトをやってるなら明日から使えるこんな取り組みがあるよ」ってことを一つご紹介できれば思っています。

作って検証して考えるっていうサイクルは、何年か前からよくみるなあっていう感じなんですけれども、これらをできるだけ早く回して学習したいなというのは、プロダクトマネジメントに関わる人であれば、ある程度みんなが思われているところなのかと思ってます。

ただこれ、例えば前のステップで構築したモノがちゃんとしてければ計測できないし、ちゃんと計測できてないと、学習につながりません。その前のステップの出力が次の入力になるので、どこかで設計が失敗していると「今回のサイクルって何がやりたかったんだっけ?」という話になりかねない。

なので、なにを学習したいかから逆算していって、それでどう計測できるか、じゃあこうやってつくろうかという順番でをやることがけっこう多いです。

こうした設計をちゃんとしてないと、学習サイクルを回して見たけどなにも学べてないし、つくったものも無駄になってしまった、ということになってしまいます。

「なにを学びたいか?」を明確に

変なタイミングなんですけど、ちょっとだけ自己紹介してまた戻ります。僕の前職はライフネット生命で、事業開発をしていました。そこではFULLER株式会社の立ち上げとかをやってました。

で、また戻るんですけども。「なにを学びたいか?」ということを明確にすることが、まずは大事ですよね。ただ、PMやPOの方って「日々プロダクトのなにを学ぶか?」とか、「なにをつくるか?」「どう測るか?」みたいなことばっかりを考えていればいいわけではなくて、社内のリソースの調達も含めて、いろいろしなきゃいけないことがたくさんあります。まぁ、大変ですよね。

なので、さっきのサイクルについても、いろんな方法で管理をしていく必要があるのかなと。それで、得たい成果がちゃんと得られるように、Pivotalではどんなことしてるかについて、ここに平たいことばで書いてみました。

学びたいことを整理したり、実際にやってみて学んだことを整理したり、次の仮説整理をしたり、インタビューのロールプレイしてちゃんと測れるのかを試してみたり。その中で、けっこうカジュアルにできる「PMヘルプアワー」という取り組みがあるので、今日はこの話をしたいと思ってます。

カジュアルにできるシェアの枠組み「PMヘルプアワー」

「PMヘルプアワー」とは、プロダクトマネージャーヘルプアワーの略です。これはPivotal Labsで行っている取り組みですね。といっても、なんのことはなくて。Pivotalにはプロダクトマネージャーがグローバルの各オフィスにいるんですけども、東京オフィスにいるPvotalのプロダクトマネージャー、あるいはクライアントとして来ていただいている方のプロダクトマネージャーの方が集まって、チームがその場で相談できる時間を固定し、週1で確保しています。

それのなにがいいかっていうと、相談する側のチームのメリットは「ちゃんとこれ測れるの?」「ちゃんとこれが学べるのかなあ?」という見落としの防止ができます。予想外の検証方法の提案とか、過去の失敗をシェアしてもらえるメリットがあります。

相談される側のチームとしては、単純に楽しいということがあります。自分のことだとけっこう慎重になっちゃうんですけど、人のことだと好き勝手言えるじゃないですか。いい意味で無責任にアレコレ言えるのは、けっこう楽しいです。

あと、結果をシェアしてもらえれば、自分の提案した方法で検証したことが、こうやって結果につながったんだなと、技術的にほかのチームの仮説検証の体験ができるということもあります。

運用としては、週1時間で固定し、プロダクトマネージャーの時間をあらかじめブロックします。当日に持ち込みたいものがあるかどうかを各プロジェクトに聞いて、なければスキップでOKです。このように、だれでも気軽に相談できる緩さがとても大事です。

時間がきましたので、ここで終わりにさせていただきます。最終的にはブログで紹介できればなと思ってます。ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!