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