プロダクトの正しい「やめ方」/ How to make decision to stop developing product

プロダクトの正しい「やめ方」~スタートアップのCTOは大きな決断にどう向き合うか？〜 にて登壇した内容です。

Transcript

1. © HataLuck and Person Inc. © HataLuck and Person Inc. プロダクトの正しい「やめ方」 2024.08.18 HataLuck and Person, Inc. Shigeru Chiba / @ohageeq
2. © HataLuck and Person Inc. 千葉　茂 ▪　Role: 執行役員 CTO 自己紹介 ▪　ID: @ohageeq ▪　Skill: Kotlin, Go, AWS ▪　Hobby: ギター Jazzmaster愛用 映画 MCUはほぼ観てる ▪　Career: 2012年 サイバーエージェント入社 2022年 HataLuck and Person業務委託入社 2023年 正社員として入社 2024年 執行役員CTO就任
3. © HataLuck and Person Inc. 事業内容 シフトワーカー個々人までデジタルで繋ぐ 業務実行スピード・品質・生産性を向上 店舗マネジメントに 必要な機能が1つに! 情報 共有 マニュアル サンクス カード 従業員向け クーポン データ 分析 シフト 管理 この領域が無 い
4. © HataLuck and Person Inc. 解決したい課題 人手不足の悪循環 離職 人 手 不 足 求人・人件費 増加 生 産 性 悪 化 店舗サービス業の人気低下。 上位下達の文化で人材の定着が 進まず、より人手不足な状態 に。 限られたスタッフでのオペレー ションは業務過多が常態化。 人材の獲得競争に伴い求人費・ 人件費も高騰。 無理な店舗運営によって、し わ寄せは現場の既存スタッフ へ集中。 教育や投資もされず、タスク だけを行う働きがいを持てな い職場へ。 求人費・人件費の増加に伴 い、店舗のPLは悪化。 コスト削減や過度な省人化施 策は、サービスの品質の低下 に繋がり、顧客の離反につな がる。 加えて、昨今の原材料費の高騰を受け、 店舗サービス業におけるこの悪循環はより深刻化している
5. © HataLuck and Person Inc. 目次 ❏ 開発していたプロダクトの概要 ❏ 問題発生！やめるに至った経緯 ❏ やめる意思決定の仕方 ❏ 問題のふりかえり ❏ まとめ
6. © HataLuck and Person Inc. 開発していたプロダクトの概要
7. © HataLuck and Person Inc. プロダクト開発歴史 開発チームを分けて 新規プロダクト PoC検証中 2024年 2019年 2021年 2022年 2023年 2020年 はたLuck リリース 機能が増える 技術課題が顕在化 基盤作り直しが検討 される 新規プロダクト 開発開始 既存プロダクト 品質改善
8. © HataLuck and Person Inc. 2021年当時の課題感 ▪ シリーズＢの調達に至ったものの、既存プロダクトでは機能が足りず事業計画の達成が難し い状況であった(と当時は思い込んでいた) ▪ 機能差分が大きく獲得できていない顧客領域が多くあった ▪ 既存プロダクトの不具合が減らないや実装の複雑度が高く、引きずられる形でインフラコス トも高騰していた 課題
9. © HataLuck and Person Inc. 新規プロダクトで解決しようとしたこと 9 経営 技術 プロダクト 大手外食、ホテル運営企業 導入のためのエンタープラ イズレベルの業務管理、セ キュリティ要件の対応 現場と本部のコミュニケー ションの溝を無くし 店長を介在せず業務を 遂行可能な機能が欲しい 小売領域も攻めたい 100万ユーザーが利用しても 安定的なパフォーマンスを 維持できる技術基盤の実現 品質高く安定的な サービス運営ができる 技術組織・基盤を 作ること アカウント・店舗管理構造 コミュニケーション機能 を全面的に見直す 経験者、情報が豊富かつ インフラの信頼性が高い AWSへ乗り換える 課 題 解 決 案
10. © HataLuck and Person Inc. ▪ 現在 - 企業配下に店舗が所属する - 企業起点で店舗が作成 ▪ 新構造 - 店舗が企業から独立 - 店舗Bが複数の企業に接続可 企業A 店舗A 店舗B ユーザーA ユーザーB アカウント 企業B 店舗B 店舗D 企業A 店舗A 店舗B ユーザー アカウント 企業B 店舗C 実現しようとした構造
11. © HataLuck and Person Inc. 当初計画 2021年9月 2021年10月 2022年1月 2022年9月 2023年1月 以降 新プロダクト 人材採用開始 技術選定、要件定義 開発開始 クローズドβ 提供 初期スコープ 開発完了 顧客提供開始 既存プロダクト 移行対応 インフラ サーバー フロント アプリ 業務委託 1名 業務委託 3名 社員 2名 社員 2名 業務委託 3名 社員 1名 業務委託 4名 PDM デザイン 社員 3名 業務委託 1名 ※ 業務委託のうち7割は60時間以下の副業 ロードマップ チーム構成 利用技術
12. © HataLuck and Person Inc. 入社経緯 新規プロダクト開発の採用一号目 ▪ 前職がサービス業向けのプロダクトを開発していた ▪ 中規模なインフラ・アプリケーションの移行を経験していた 新規プロダクトを作る際の技術選定、初期設計から関わることになる しかし、０→１の立ち上げメンバーとして入社から開発停止を決断した そして現在、既存プロダクト建て直し中
13. © HataLuck and Person Inc. ジョイン後タイムライン 2024年 1月〜 CTO 就任 2022年 1月〜 2023年 1月〜 2022年 6月〜 正社員 入社 週3 業務委託 2023年 6月 開発 完全停止 2021年 9月〜 技術選定および 満たすべき非機能要件の 整理 新プロダクト 開発開始 実機のモック 完成
14. © HataLuck and Person Inc. 問題発生！やめるに至った経緯
15. © HataLuck and Person Inc. 開発の状況 2021年9月 2021年10月 2022年1月 2022年9月 2023年1月 以降 新プロダクト 人材採用開始 技術選定、要件定義 開発開始 クローズドβ 提供 初期スコープ 開発完了 顧客提供開始 既存プロダクト 移行対応 当初計画 21年9月 21年 10月 23年1月 23年6月 22年6月 22年9月 23年4月 22年 1月 クローズドβが 間に合わないことが わかる 年内の開発完了が 難しいことが わかる ランウェイが やばいことが わかる プロダクト開発 を凍結決定 メンバーの解散 結果 開発の完全停止 遅延1回目 遅延2回目 遅延3回目
16. © HataLuck and Person Inc. 遅延した要因 ▪ 既存プロダクトの解決したい課題をすべて開発スコープに入れてしまった - 開拓目標であった領域の顧客情報が取れなかった - そもそも期待値がずれていたことを終盤で知った ▪ 要件定義を作りながら全レイヤーの開発が一気に走ったことで、設計が固ま らず変更しながらの開発となった ▪ FlutterやGO等の知見が少ない技術のベースを作るのに時間がかかった ▪ 遅延したことでさらに人材を増やした上、バラバラな稼働時間をまとめあげ るためのマネジメントができなかった
17. © HataLuck and Person Inc. やめる意思決定の仕方
18. © HataLuck and Person Inc. やめる意思決定の仕方 ▪ 投下資産の回収可能性 ▪ 会社を存続させる打ち手 ▪ ステークホルダーへの説得 - 対社外 - 対社内
19. © HataLuck and Person Inc. 投下資産の回収可能性 ▪ ソースコードは全て技術が既存プロダクトと異なるため流用はできず - 機能のモデリングは既存プロダクトで活かす可能性が見えてきた (４ヶ月ほど前) ▪ 開発外注費が一番のコストだったため業務委託メンバーを残せず サンクコストは多いが 泣く泣く捨てることを決断
20. © HataLuck and Person Inc. 会社を存続させる打ち手 ▪ アフターコロナのサービス業の需要が戻り受注率が高まった ▪ 既存プロダクトの技術基盤が思ったより悪い状態ではなかった - 当時のボードメンバーにエンジニアバックグラウンドを持つ人がおらず適 切な判断ができていなかった - 技術的に全く解決できない課題というのはなかった - この案がなかったら詰みの状況となっていた ▪ 既存プロダクトの開発へ再投資することが顧客価値を最大化すると結論付けた 既存プロダクトの課題を解決し機能追加・改善することで ROIが良くなるとわかった
21. © HataLuck and Person Inc. 既存プロダクトの技術基盤の診断 既存プロダクトの投資効率が悪いと判断 ▪ プロダクト品質やパフォーマンスが低く顧客からも指摘を受けていた ▪ 機能追加・改善に時間がかかり顧客要望が溜まっていく量が増えた ▪ 選定した技術の情報が少ないことや魅力が薄くハイレベルな人材を採用できない 新規プロダクト開発前 機能追加が優先され目の前におきている課題解決に向き合えず問題が膨らむばかり four keysを元にした開発ROI試算によりこのまま開発しても利益がマイナスになる → 仕掛りの状態を無くしていくことを優先し、機能追加を一時的に止めた ▪ 初期選定したインフラからの移行対応を終わらせる ▪ チームで課題を解決していく開発プロセスの取り入れる 再診断した結論
22. © HataLuck and Person Inc. ステークホルダーへの説得 社 外 投資家 キャッシュアウトを避けることを合意。 既存プロダクトが成長していたこともあり投資内容を変更を説明。 導入顧客 試用版と説明していたことでハレーションは少なかった。 顧客が抱えた課題解決できると期待を寄せられていたため歯痒さが残った。 プロダクトの方向性が間違っていないことは確認できた。 社 内 社員 投資対象が既存プロダクトへ戻ることで品質への不信感があった。 品質改善、成長が見込めることを質疑応答の場を設けて納得感を得た。
23. © HataLuck and Person Inc. 問題のふりかえり
24. © HataLuck and Person Inc. 経営陣でふりかえり 当初計画と前提条件が 変わっていたこと見過ごしてい た 既存プロダクトの課題を 浅く捉えていた 一次情報が足りず仮説での 要求スコープが大きく なってしまった 課題 時期毎にチェックポイントを挟み 撤退条件を定め、計画停止や 戻れる方法を盛り込む 開発課題をボード内でも理解し 対策・改善を積極的に議論する PoCとしてはシステム開発の 成果物以外でも顧客提供をし 仮説FBをもらえるようにする 対策
25. © HataLuck and Person Inc. 技術面のふりかえりと現在 技術基盤を全面に入れ替えるためには資金や開発体制が整っていることの方が重要 失敗しても引き返せる選択を ▪ とある画面の一部分をVue→Reactに置き換える ▪ Swift, Kotlinのコードベースを活かしてKMPを使う 根本の課題を読み違えないために、トップダウンな意思決定だけではなくメンバー からの意見も吸収する ▪ プロダクトビジョンを示しどこに向かって作っているのかを腹落ちさせる ▪ バックログ１つの目的を伝え解像度が上げる
26. © HataLuck and Person Inc. 新規プロダクト開発への挑戦 成長カーブを変えるために２つの新規事業を 絶賛仕込み中 • PoCではスプシやスクリプト作業、手動で人で運用の仕組み化する • 顧客のコア課題を探し、それをシステムとして最小で作り効率化する • 既存システムで流用できそうな箇所に乗っかる • 投資タイミングに合わせ、体制や共通技術基盤をどう作るかを思考中
27. © HataLuck and Person Inc. まとめと学び 新規プロダクトをやり切るには... ❏ 圧倒的な熱意を持った人が熱を伝え引っ張っていく ❏ 既存事業以上にコミットメントする ❏ 蓋然性が高まる前のフルベットは難アリ、投資可能な期間を考慮する やめる意思決定の妥当性を高めるには... ❏ 計画を立ち返り、再投資可能性や次なる打ち手を検討する ❏ 期待値を擦り合わせて各所のハレーションを少なくなるように務める ❏ 意思決定者がきちんと決めきる