概要

この勉強会とは

及川卓也さんが出された新著、「プロダクトマネジメントのすべて」について、
弊社内のメンバーが質問をもちより、直接著者である及川さんにお聞きする勉強会です。

社内勉強会として発足しましたが、 せっかくなので、外部公開いたします。

PdMのみならず、現場で活躍するエンジニアやエンジニアマネージャー、
スクラムマスターにも役立つ内容を目指します。

お気軽にぜひご視聴ください。

配信URL

イベント参加をしてくださった方へ直接URLでお送りします

開始日時以降であれば、お好きなタイミングでご視聴できます
（生配信ではなく、収録したものを限定公開します）

参加方法

視聴でのご参加の方

限定公開のYouTubeにて配信いたします。
申し込まれた方にはYouTubeのURLをお送りいたしますので、ご自宅などから、お好きなタイミングでご視聴ください。

タイムスケジュール

（生配信ではなく、収録したものを限定公開します）

登壇者

著者

名前

及川卓也 (@takoratta )

プロフィール

東京出身。早稲田大学理工学部卒。専門だった探査工学に必要だったことからコンピューターサイエンスを学ぶ。
卒業後は外資系コンピューター企業にて、研究開発業務に従事。現在で言うグループウェア製品の開発や日本語入力アーキテクチャ整備などを行う。その後、数回の転職を経験。OSの開発、ネットワークやセキュリティ技術の標準化などにも携わる。プロダクトマネジメントとエンジニアリングマネジメントという製品開発において軸となる2つの役職を経験。
2019年1月、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立。

参加者①

名前

島田寛基(@hshimada_)

プロフィール

2015年、京都大学で計算機科学の学士号を取得。人工知能を専攻。大学時代にはグーグル（日本法人）でインターンシップのほか、Incubate Fundにてさまざまなスタートアップ企業でのテック面での支援を経験。2016年、イギリスのエディンバラ大学（The University of Edinburgh）大学院で修士号「MSc in Artificial Intelligence」を取得。2016年、日本初のAIヘッドハンティングサービスを運営する株式会社scoutyを創業。後にLAPRAS株式会社に社名変更。

しようと思っているご質問（仮）

4.7.1, 4.7.2仮説検証とMVPに関しての質問

仮説検証の基準としてKPI数値をおくことが多いと思います（例：「この機能はユーザーの転職のpainを解決して面談がとれる」という仮説検証のため、このMVPで面談獲得率が15%以上なら仮説を検証とみなす 等）。 その時、最初のMVPでそこまでたどり着かなかったときに、そもそもその領域自体に筋がない（からピボットしたほうがいい）のか、それともオペレーションやプロダクトの磨き込みが足りなかったから低かったのか（だからもうちょっと頑張るべき）は、どう判断しますか？ 実際は後者の判断になりがちで、撤退基準を設定するのが非常に難しいと思えます。 仮説や検証基準の設定方法が間違っているのでしょうか？

参加者②

名前

興梠 敬典（@rocky_manobi）

プロフィール

株式会社LAPRAS執行役員CTO。 豊田高専を卒業後、ソフトウェアエンジニアとして多様な開発案件に従事。複数の新規事業立ち上げに携わる。2015年より株式会社Nextremer高知AIラボの代表として事業や組織の立ち上げを主導。地域コミュニティや行政とも協力関係を構築し、地方でも先端技術に触れられる場作りに貢献。2019年8月にLAPRASに入社。CTOとしてチームや開発のマネジメントに携わるほか、数社の開発組織づくりのサポートなどを行っている。

しようと思っているご質問（仮）

6.3.1 ペインとゲインを仮説検証するユーザインタビュー

「このようなユーザインタビューにはプロダクトチームは参加すべき」などその通りだと思うのですが、Whyを検証しているこの段階にエンジニアが絡んでいくにはどのような体制や運用を敷くと良いかをお聞きしたいです。

具体的には「エンジニアチーム/スクラムチームがHowの検討や実装にフォーカスしているときに別の機能や施策におけるWhy-Whatの検証が進められ、実装が終わった後はエンジニアチームは次のHowに再び取り組む」のような動きになりがちだと感じました。特にリリース後はシステムの運用やBugFix、問い合わせ対応などの「現在」に目線を置いたタスクが多く発生するので、この力学は大きくなるのではと思います。

分業によるコンテキストスイッチの減少などのメリットもありつつも、作り手とユーザとの距離は近い方が良いと考えており、良い塩梅はないものでしょうか。 現在は背景の共有に力を入れることや、PdMの仕事を共有して信頼関係を作る～などは取り組んでいます

※現在は 1プロダクト, 1スクラムチーム, 複数PdMという構造です。

参加者③

名前

高濱隆輔（@r_takahama）

プロフィール

LAPRAS株式会社のプロダクトマネージャー。 京都大学工学部情報学科を卒業後、京都大学大学院情報学研究科にて修士号を取得。新卒で株式会社リクルートライフスタイルにデータサイエンティストとして入社。2017年にLAPRAS株式会社（旧名・株式会社scouty）に入社。大学・大学院・LAPRASでの研究は、それぞれ機械学習や人工知能の最も権威ある国際会議である IJCAI, AAAI, ICML に採択される。現在はLAPRAS株式会社でプロダクトマネージャーとしてプロダクト開発に携わるほか、他数社で人事制度に関するコンサルティングやプロダクト開発の顧問業を行っている。

しようと思っているご質問（仮）

5.1 Product の Core について

PdM複数人体制のとき、 Core, Why, What はどのように分割すべきですか？それとも分割すべきではないですか？
1プロダクトでPdM2人とかだと分け方が難しいなと思ってます。

参加者④

名前

鈴木亮太（@nunuki_）

プロフィール

NECで機械学習・信号処理の研究を行った後、2018年に機械学習エンジニアとしてLAPRASにジョイン。主著論文がAI分野のトップ会議ICML 2019にて採択される。その後、R&Dの経験を活かしてより多くの価値をユーザーに届けるべく、プロダクトマネージャーに転向。プロダクト戦略、特許戦略、企画推進、データ分析などを中心に、プロダクト全般の統括を行っている。理学修士(物性物理学)。

しようと思っているご質問（仮）

7.4.2 プロダクトの仮説検証プロセスについて

Why, What, How は1セットでこの順番で決めていくのが理想だと思いますが、実際には状況に柔軟に対応するために次のようなことが必要になることがあると思います。

・1つのWhy に対して複数のWhat の検証を同時または立て続けに進める
・ソリューション仮説(What)の検証結果を受けて Why に変更を加える

こういった変則的な動きをしたときに、プロセスの可視化や管理、ドキュメンテーションやコミュニケーションが非常に難しくなりますが、これをうまくやる方法はありますか？ それとも、そもそもプロセスを標準化してなるべくこのようなことが起こらないようにすべきですか？

主催

エンジニアの「得意」を瞬時に分析。LAPRAS

https://lapras.com/

LAPRASは、エンジニアのブログやSNSを分析して自動でポートフォリオを生成し、 最適なキャリアの選択肢にマッチングするキャリアマッチングプラットフォームです。

LAPRASを通じて、エンジニアはSNSの活動などから算出された自分の技術力スコアを確認したり、 スカウトや求人マッチングエンジンを通じて自分に興味を持っている企業とつながったりすることができます。

LAPRASは、転職者であるエンジニアのCX（Candidate Experience）を重視した「マッチングの質」にこだわり、 全てのユーザーの長期的な幸せに貢献します。