BEGIN:VCALENDAR VERSION:2.0 PRODID:-//https://techplay.jp//JP CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALDESC:及川卓也さんに「プロダクトマネジメントの すべて」について質問してみた X-WR-CALNAME:及川卓也さんに「プロダクトマネジメントの すべて」について質問してみた X-WR-TIMEZONE:Asia/Tokyo BEGIN:VTIMEZONE TZID:Asia/Tokyo BEGIN:STANDARD DTSTART:19700101T000000 TZOFFSETFROM:+0900 TZOFFSETTO:+0900 TZNAME:JST END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:813357@techplay.jp SUMMARY:及川卓也さんに「プロダクトマネジメントのすべ て」について質問してみた DTSTART;TZID=Asia/Tokyo:20210415T180000 DTEND;TZID=Asia/Tokyo:20210415T190000 DTSTAMP:20260423T212810Z CREATED:20210331T142342Z DESCRIPTION:イベント詳細はこちら\nhttps://techplay.jp/event/81335 7?utm_medium=referral&utm_source=ics&utm_campaign=ics\n\n概要\nこの 勉強会とは\n及川卓也さんが出された新著、「プロダ クトマネジメントのすべて」について、\n弊社内のメ ンバーが質問をもちより、直接著者である及川さんに お聞きする勉強会です。\n社内勉強会として発足しま したが、\nせっかくなので、外部公開いたします。\nPdM のみならず、現場で活躍するエンジニアやエンジニア マネージャー、\nスクラムマスターにも役立つ内容を 目指します。\nお気軽にぜひご視聴ください。\n配信URL \nイベント参加をしてくださった方へ直接URLでお送り します\n開始日時以降であれば、お好きなタイミング でご視聴できます\n（生配信ではなく、収録したもの を限定公開します）\n参加方法\n視聴でのご参加の方\n 限定公開のYouTubeにて配信いたします。\n申し込まれた 方にはYouTubeのURLをお送りいたしますので、ご自宅など から、お好きなタイミングでご視聴ください。\nタイ ムスケジュール\n（生配信ではなく、収録したものを 限定公開します）\n\n\n\n時間\n内容\nテーマ\n\n\n\n\n00:00\ nご挨拶\n---\n\n\n00:05\n1人めからのご質問\n仮説検証時の 基準KPIに最初のMVPで達成できなかった場合の判断につ いて\n\n\n00:20\n2人めからのご質問\n作り手とユーザを近 くするためのユーザインタビューについて\n\n\n00:35\n3 人めからのご質問\nPdM複数人体制のときのCore\, Why\, What の分割について\n\n\n00:50\n4人めからのご質問\n変則的に Why\,What\,Howが動くときの仮説検証プロセスの進め方に ついて\n\n\n01:05\nフリーディスカッション\n---\n\n\n01:20\n 終了\n---\n\n\n\n登壇者\n著者\n\n名前\n及川卓也 (@takoratta )\nプロフィール\n東京出身。早稲田大学理工学部卒。 専門だった探査工学に必要だったことからコンピュー ターサイエンスを学ぶ。\n卒業後は外資系コンピュー ター企業にて、研究開発業務に従事。現在で言うグル ープウェア製品の開発や日本語入力アーキテクチャ整 備などを行う。その後、数回の転職を経験。OSの開発 、ネットワークやセキュリティ技術の標準化などにも 携わる。プロダクトマネジメントとエンジニアリング マネジメントという製品開発において軸となる2つの役 職を経験。\n2019年1月、テクノロジーにより企業や社会 の変革を支援するTably株式会社を設立。\n参加者①\n\n 名前\n島田寛基(@hshimada_)\nプロフィール\n2015年、京都大 学で計算機科学の学士号を取得。人工知能を専攻。大 学時代にはグーグル（日本法人）でインターンシップ のほか、Incubate Fundにてさまざまなスタートアップ企業 でのテック面での支援を経験。2016年、イギリスのエデ ィンバラ大学（The University of Edinburgh）大学院で修士号 「MSc in Artificial Intelligence」を取得。2016年、日本初のAI ヘッドハンティングサービスを運営する株式会社scouty を創業。後にLAPRAS株式会社に社名変更。\nしようと思 っているご質問（仮）\n4.7.1\, 4.7.2仮説検証とMVPに関し ての質問\n仮説検証の基準としてKPI数値をおくことが 多いと思います（例：「この機能はユーザーの転職のp ainを解決して面談がとれる」という仮説検証のため、 このMVPで面談獲得率が15%以上なら仮説を検証とみなす 等）。\nその時、最初のMVPでそこまでたどり着かなか ったときに、そもそもその領域自体に筋がない（から ピボットしたほうがいい）のか、それともオペレーシ ョンやプロダクトの磨き込みが足りなかったから低か ったのか（だからもうちょっと頑張るべき）は、どう 判断しますか？\n実際は後者の判断になりがちで、撤 退基準を設定するのが非常に難しいと思えます。\n仮 説や検証基準の設定方法が間違っているのでしょうか ？\n参加者②\n\n名前\n興梠 敬典（@rocky_manobi）\nプロフ ィール\n株式会社LAPRAS執行役員CTO。\n豊田高専を卒業後 、ソフトウェアエンジニアとして多様な開発案件に従 事。複数の新規事業立ち上げに携わる。2015年より株式 会社Nextremer高知AIラボの代表として事業や組織の立ち 上げを主導。地域コミュニティや行政とも協力関係を 構築し、地方でも先端技術に触れられる場作りに貢献 。2019年8月にLAPRASに入社。CTOとしてチームや開発のマ ネジメントに携わるほか、数社の開発組織づくりのサ ポートなどを行っている。\nしようと思っているご質 問（仮）\n6.3.1 ペインとゲインを仮説検証するユーザ インタビュー\n「このようなユーザインタビューには プロダクトチームは参加すべき」などその通りだと思 うのですが、Whyを検証しているこの段階にエンジニア が絡んでいくにはどのような体制や運用を敷くと良い かをお聞きしたいです。\n具体的には「エンジニアチ ーム/スクラムチームがHowの検討や実装にフォーカスし ているときに別の機能や施策におけるWhy-Whatの検証が 進められ、実装が終わった後はエンジニアチームは次 のHowに再び取り組む」のような動きになりがちだと感 じました。特にリリース後はシステムの運用やBugFix、 問い合わせ対応などの「現在」に目線を置いたタスク が多く発生するので、この力学は大きくなるのではと 思います。\n分業によるコンテキストスイッチの減少 などのメリットもありつつも、作り手とユーザとの距 離は近い方が良いと考えており、良い塩梅はないもの でしょうか。\n現在は背景の共有に力を入れることや 、PdMの仕事を共有して信頼関係を作る～などは取り組 んでいます\n※現在は 1プロダクト\, 1スクラムチーム\, 複数PdMという構造です。\n参加者③\n\n名前\n高濱隆輔 （@r_takahama）\nプロフィール\nLAPRAS株式会社のプロダク トマネージャー。\n京都大学工学部情報学科を卒業後 、京都大学大学院情報学研究科にて修士号を取得。新 卒で株式会社リクルートライフスタイルにデータサイ エンティストとして入社。2017年にLAPRAS株式会社（旧名 ・株式会社scouty）に入社。大学・大学院・LAPRASでの研 究は、それぞれ機械学習や人工知能の最も権威ある国 際会議である IJCAI\, AAAI\, ICML に採択される。現在はLAPR AS株式会社でプロダクトマネージャーとしてプロダク ト開発に携わるほか、他数社で人事制度に関するコン サルティングやプロダクト開発の顧問業を行っている 。\nしようと思っているご質問（仮）\n5.1 Product の Core について\nPdM複数人体制のとき、 Core\, Why\, What はどの ように分割すべきですか？それとも分割すべきではな いですか？\n1プロダクトでPdM2人とかだと分け方が難し いなと思ってます。\n参加者④\n\n名前\n鈴木亮太（@nunu ki_）\nプロフィール\nNECで機械学習・信号処理の研究を 行った後、2018年に機械学習エンジニアとしてLAPRASにジ ョイン。主著論文がAI分野のトップ会議ICML 2019にて採 択される。その後、R&Dの経験を活かしてより多くの価 値をユーザーに届けるべく、プロダクトマネージャー に転向。プロダクト戦略、特許戦略、企画推進、デー タ分析などを中心に、プロダクト全般の統括を行って いる。理学修士(物性物理学)。\nしようと思っているご 質問（仮）\n7.4.2 プロダクトの仮説検証プロセスにつ いて\nWhy\, What\, How は1セットでこの順番で決めていく のが理想だと思いますが、実際には状況に柔軟に対応 するために次のようなことが必要になることがあると 思います。\n・1つのWhy に対して複数のWhat の検証を同 時または立て続けに進める\n・ソリューション仮説(What )の検証結果を受けて Why に変更を加える\nこういった 変則的な動きをしたときに、プロセスの可視化や管理 、ドキュメンテーションやコミュニケーションが非常 に難しくなりますが、これをうまくやる方法はありま すか？\nそれとも、そもそもプロセスを標準化してな るべくこのようなことが起こらないようにすべきです か？\n主催\n\n\nエンジニアの「得意」を瞬時に分析。LA PRAS\nhttps://lapras.com/\nLAPRASは、エンジニアのブログやSNS を分析して自動でポートフォリオを生成し、\n最適な キャリアの選択肢にマッチングするキャリアマッチン グプラットフォームです。\n\nLAPRASを通じて、エンジニ アはSNSの活動などから算出された自分の技術力スコア を確認したり、\nスカウトや求人マッチングエンジン を通じて自分に興味を持っている企業とつながったり することができます。\n\nLAPRASは、転職者であるエンジ ニアのCX（Candidate Experience）を重視した「マッチングの 質」にこだわり、\n全てのユーザーの長期的な幸せに 貢献します。 LOCATION:YouTube オンライン URL:https://techplay.jp/event/813357?utm_medium=referral&utm_source=ics&utm _campaign=ics END:VEVENT END:VCALENDAR