エンジニアのわたしが初めて新規事業でプロダクトマネージャーもやってみて学んだ 3つのこと

プロダクトマネージャーカンファレンス2022の非公式な非採択セッションイベント

Transcript

1. 『エンジニアのわたしが 初めて新規事業でプロダクトマネージャーも やってみて学んだ 3つのこと』 プロダクトマネージャーカンファレンス2022 の非公式な非採択セッションイベント
2. 自己紹介 あっきー @akkiihs 小寺 暁久 CARTA HOLDINGS (旧VOYAGE GROUP) DIGITALIO リテールDX事業 エンジニア
3. 個人のスタンス 「自分はプロダクトマネージャーだ」と思ってやっていない あくまで主軸はエンジニアで、 事業やプロダクトが成長すると思う方向に動いているだけ。
4. フルサイクルエンジニア “「ビジネスアイディアからお客さんに届くまで」 を1つのサイクルとみて、それを すべて一人の技術者でもやれるようにしよう”
5. 話さないこと - お金・評価の話 - 目標・進捗管理の話 プロダクト開発にフォーカスした内容です
6. 話すこと 『エンジニアのわたしが 　初めて新規事業でプロダクトマネージャーも 　やってみて学んだ 3つのこと』 1. プロダクト開発をする上での意識: 『?』 2. 複数案件並行からの学び: 『?』 3. 複数開発体制からの学び: 『?』
7. 本題にはいる前に
8. 新規事業にジョイン 全社的にも未開拓だった「リテール領域」の新規事業に、 業界知識ゼロで1人目のエンジニアとしてジョイン 業態を絞らないからこそ、 でてくる多種多様な課題と、 求められる要件
9. 当時の状況 「まずは業界理解しよう！」選り好みせず、 クライアントの要望にそったプロダクト開発をしよう（個別開発） 「これは売れる！」という確信を持てず、手探り 「作って終わり」ではなく、クライアントの要望に応えつつ、 カスタマーサクセスに繋げたい でも、各案件に開発工数はかけたくない
10. 新規事業で事業成長の障壁となるものは何か 『プロダクト開発』 1のアイディアを実現するためには、 10, 100, それ以上の開発工数がかかる いろいろ模索して何が当たるかわからない中で、 自分がどうやって向き合っていたのかを話します。
11. プロダクト開発する上で意識していること
12. プロダクト開発する上で意識していること 『資産化すること』 自分たちのプロダクトで、自分たちがコントロールしていく 1. 選択と集中: あれもこれもやろうとしない 2. 小さく試す: 最初から完璧なもの作ろうとしない 3. 汎用化: 他案件への横展を意識する
13. 捨てる覚悟も必要だが.. - 資産として残していきたい - コードや、その過程での設計や概念としての考え方を指す - 次の検証への投資だと思うようにする - 仮説検証をまわして学習していく - 捨てやすい（disposable）なアーキテクチャにしておく - マイクロサービスやモジュール単位で切り出す - IaC インフラ管理して案件単位で切り出す
14. ドメイン知識を身につける リテール領域は、身の回りに溢れている 「現地での体験をしてくること」が業界理解の第一歩 エンジニア観点だと、既存アプリを触ってみてどういう仕組みに なっているのか想像して、それもセットでチームへ共有する
15. 個別開発に振り回されないために 個別開発の課題 - 都度発生する開発工数（スケールしづらい） - 自社プロダクトの成長につながりにくい - 増殖するドメイン知識、高まる認知負荷 - 「A社のこの機能は◦◦という仕様で、 　B社のこの機能は××という仕様で...」 - 「A社の仕様は△△さんに聞いて、 　B社の仕様は□□さんに聞いて...」
16. セミオーダー戦略 - 機能単位で共通化させ、別案件への横展を想定する - 長期的にみても、メンテナンスしやすい - デザインは、クライアントの要望にそったものを提供可能 - あくまで共通化させるのは、内部の機能単位であるため、 インタフェースは自由に提供可能 個別開発にように見えて、内部で自社プロダクトを育てる
17. 複数案件並行からの学び
18. 複数案件並行からの学び セミオーダー戦略によって、2, 3つ目の案件の工数を 確実に削減してリリースしていった。 …が、実態として、何が売れるのかわからず、 様々な機能を並行して開発を進めていた。
19. A案件 B案件 C案件 抽選機能がほしい クーポン機能がほしい 来店予約機能がほしい ｾﾞｪｾﾞｪ..
20. 「作って終わり」ではなく、クライアントの要望に耳を傾け、 カスタマーサクセスに繋げたいのであれば、 どの業態にどの機能に注力していくのか定めることが必要 『確実に1つ1つ検証すること』
21. 複数開発体制からの学び
22. 複数開発体制からの学び 自分一人では手が回らなくなってきた 人を増やせば工数が削減できるわけではない。これは自明。 かといって、現状から何も変わらないわけにはいかない 業務委託・複数開発パートナーとともに開発を進めることに ※ 内製じゃないとダメという話ではありません。
23. A案件 B案件 C案件 業務 委託 メンバー 開発 パートナー X社 開発 パートナー Y社 レビューまだです? この仕様、具体的にください。 思ってたんと違う..
24. 自分自身がボトルネックになっていた 自社での “よしな” なやり方を、そのままやってしまっていた 組織や文化が異なるので、スタンスや考え方が異なるのは当然。 これまでエンジニアとしてのキャリアを歩んできた分、 自分が手を動かせばものづくりができるというのが仇となる 『信頼し、責務を切り分け任せきること』
25. まとめ
26. 『エンジニアのわたしが 　初めて新規事業でプロダクトマネージャーも 　やってみて学んだ 3つのこと』 1. プロダクト開発をする上での意識: 『資産化すること』 2. 複数案件並行からの学び: 『確実に1つ1つ検証すること』 3. 複数開発体制からの学び: 『信頼し、責務を切り分け任せきること』 まとめ