プロダクト負債に立ち向かう

Transcript

1. プロダクト負債 に立ち向かう 2025/11/21 株式会社CastingONE 上田裕耀 Product Manager Conference 2025 〜負債と向き合い続け、成長できるプロダクトへ〜
2. 「プロダクト負債」 みなさんどのように向き合っていますか？ はじめに 2
3. 負債は放置すると将来的な成長を阻害する だからこそ向き合い続ける必要がある はじめに 3
4. 本セッションのテーマ プロダクト負債 に立ち向かう そもそもプロダクト負債とは何か？ どのように立ち向かうのか？ 4
5. hiroaki_u329 自己紹介 上田裕耀 / Hiroaki Ueda 冷食メーカー　リサーチャー ベンチャー　　バックエンドエンジニア CastingONE　 バックエンドエンジニア 株式会社CastingONE CastingONE　 プロダクトマネージャー Background 5
6. プロダクト紹介 6 非正規雇用労働者の採用を行うすべての採用担当者が 「効率的に良い人材の採用が行えている」と実感している世界を実現する Product Vision
7. プロダクト負債とは何か？ 01 Content プロダクトの診断 02 負債対応の指針 03 負債の解消 04 7
8. プロダクト負債とは何か？ 01 Content プロダクトの診断 02 負債対応の指針 03 負債の解消 04 8
9. プロダクト負債とは何か？ 価値を生まず事業やプロダクトに 負を与え続ける機能や体験 プロダクト負債 ＝ 9
10. プロダクト負債とは何か？ CastingONEでも多くの負債を抱えていました 全く使われない機能 ビジョンに合わない機能 顧客の運用に乗らない体験の機能 仕様が複雑過ぎて不具合が生まれやすい機能 データ構造から体験や世界観に負を与えている機能 etc. 10
11. プロダクト負債とは何か？ 開発負債 体験負債 コンセプト負債 開発の進行に負の影響を与える機能 UXが悪く、顧客が価値に到達しづらい 機能 中長期でのプロダクト価値がぼやける 開発速度低下 / 不具合リスク増加 離脱率増加 / 顧客不満 意味 影響 意味 影響 意味 影響 世界観・ビジョンから逸脱した機能 顧客カスタマイズしすぎた機能 分岐が多く複雑化しすぎている機能 全く使われていない機能 例 本来の工程以上に、余計な手順を踏ま ないといけない機能 例 例 11
12. プロダクト負債とは何か？ なぜプロダクト負債は生まれるのか？ 12
13. プロダクト負債とは何か？ （繰り返し） 負債創出理由は大きく3つに分類 顧客の声をそのまま作ってしまう 「刺さるはず」の思い込みで作る ビルドトラップ 部分最適の判断 既存機能に引っ張られて、 　 該当機能の理想体験の再設計をしない 「CSがカバーするから大丈夫」と、 　 体験課題を先送りにしてしまう 安易な体験設計 事業方向性の変化 市況変化で想定していたValueがズレる 事業や市況の変化 Discover Define Develop Deliver Reference: Design Council “The Double Diamond” 13
14. ビルドトラップや安易な体験設計は避けたとしても、 事業や市況の変化により全ての機能は負債になるリスクがある プロダクト負債とは何か？ 14
15. プロダクト負債に立ち向かうには？ ” 良い戦略は、十分な根拠に立脚したしっかりとした基本構造を持って おり、一貫した行動に直結する。 （中略） 戦略の核は状況の診断、診断で明らかになった課題に取り組む基本方 針、基本方針に基づく一貫した行動である。 引用： 『良い戦略、悪い戦略』 リチャード・P・ルメルト（著） 、村井章子（訳） 、日本経済新聞出版、2012 15
16. プロダクトを診断して、いつどのように解消するのか指針を立てる プロダクトの成長のために顧客への説明責任を果たし負債を解消する プロダクト負債に立ち向かうには？ 16
17. プロダクト負債とは何か？ 01 Content プロダクトの診断 02 負債対応の指針 03 負債の解消 04 17
18. プロダクトの診断 負債を負債であると認識する 機能利用を観察する 定量指標で実際の利用状況を見る 1 ドッグフーディングする 自分たちで触って数値では見えない体験の歪みを拾う 2 3 顧客の声や現場に目を向ける 顧客インタビューや現場観察などの1次情報から価値のズレを確認する 18
19. 実施事項 利用率を定期的にモニタリング。リリースした機能やコアな機能を重点的に観察 観点・判断 利用率が極端に低い機能は負債リスクが高い。背景をさらに診断する プロダクトの診断 機能の利用状況を観察し、 「価値が届いていない箇所」を見つける 期待 現実 80% 5% 19
20. プロダクトの診断 ドッグフーディングにより、体験の歪みを発見する 実施事項 顧客のユースケースに合わせて実際に操作する リリース直後やコア機能を中心に導線全体を見る 観点・判断 一連の操作が自然に流れるか 単体では良くても通して触ると違和感がないか 文言・操作が顧客の頭のモデルと一致しているか 20
21. ただ、顧客の文脈で体験するのは難しい どうしても開発の机上の空論になりがち プロダクトの診断 21
22. プロダクトの診断 顧客の業務を代行し、顧客に成り切ってドッグフーディングする 実際の顧客データでプロダクトを操作することで、顧客の痛みをリアルに把握できる。 CastingONEでも業務を代行し、体験負債を特定して改善。 その結果、対象機能の利用率が15％向上した。 ※顧客とは事前に打ち合わせして、どのような体制で実施するか合意しています 22
23. プロダクトの診断 顧客がどんな状況で、どんな声を挙げているのかを知る 実施事項 CS経由でリクエストやVoCを定期的に収集 顧客定例への参加やインタビューの実施により、実際の声を把握 現場に足を運び、顧客の実態や業務プロセスへの理解を深める 観点・判断 顧客が抱える課題の構造や制約を高い解像度で把握する 数値では見えにくい文脈を捉えてプロダクトを見直す 23
24. 定期検診のように、普段からプロダクトを診断する 持続可能な診断の仕組みも整える プロダクトの診断 24
25. プロダクト負債とは何か？ 01 Content プロダクトの診断 02 負債対応の指針 03 負債の解消 04 25
26. 負債対応の指針 Impact Effort いつ対応するのか検討する 速攻対応する 対応しない or 条件付きで対応 対応しない まずはimpactとEffortの2軸でシンプルに考える 26
27. どのように負債のインパクトを考えるのか？ 全て定量化するのは難しい 負債対応の指針 27
28. 負債対応の指針 3つの問いを考える プロダクトビジョンや世界観にあっているのか？ →コンセプト負債 1 顧客体験にどのくらいの負があるのか？ →体験負債 2 3 今後の開発に対してどのくらいの負があるのか？ →開発負債 28
29. 負債対応の指針 プロダクトビジョンや世界観にあっているのか？ → Noであれば、コンセプト負債。 コアな機能なのか？ プロダクトのコアなら、中長期のインパクトが大きい。 1 機能そのものか、それとも機能の一部か？ 機能そのものであれば、その機能に価値を感じていた顧客の離反を招く可能性がある。 2 3 顧客にどれくらい浸透しているのか？ 広く使われているほど影響範囲が大きい。 29
30. 魅力的品質 当たり前品質 1次品質 対応すべき領域 無視すべき領域 負債対応の指針 顧客体験にどのくらいの負があるのか？ → 体験負債は基本的に当たり前品質の未達。 　 その負は「対応すべき領域か」 「無視すべき領域か」を見極める。 対応すべき領域 体験が顧客にとって致命的な負になっていないか？ 1 無視すべき領域 一部の顧客のこだわりになっていないか？ 「あったらいいな」くらいのレベル感か？ コアターゲットではない層の声ではないか？ 2 Reference: Kano, N., et al. (1984) 30
31. 負債対応の指針 今後の開発に対してどのくらいの負があるのか？ → 「中長期的な開発速度」と「不具合のリスク」で考える。 開発速度 不具合リスク 時間 高 低 中長期的な開発速度 今後の開発スピードにどの程度の影響を与えるのか？ 1 不具合のリスク 現在どのくらいのインシデントが発生しているのか？ 今後どの程度、再発・拡大する可能性があるか？ 2 31
32. ビジョンと事業価値を最大化するように、負債の解消タイミングを決定 負債対応の指針 プロダクトビジョン 開発負債 体験負債 コンセプト負債 事業価値 ロードマップ 32
33. プロダクト負債とは何か？ 01 Content プロダクトの診断 02 負債対応の指針 03 負債の解消 04 33
34. 負債の解消 世界観・使い方の転換が必要 ハレーションリスクが大きく、説明責任が大きい 顧客体験はほぼ変わらない 機能削除する際は、一部の顧客には影響が出る可能性あり 開発負債 体験負債 コンセプト負債 Bizと共同して顧客への影響を適切に把握し、顧客への説明責任を果たす。 顧客への影響小 顧客への影響大 解消されると顧客にとって嬉しい ハレーションもほぼない 34
35. 負債の解消 CastingONEでの解消の例 35
36. 負債の解消 Case1. 機能利用率2%、世界観の異なる機能の削除 応募後のプロセスを楽にするために、面談設定の機能を搭載。 ただ、すでに顧客はATSでこの業務を実施。そのため機能利用率も2%と低かった。 改めてプロダクトの価値や世界観を見直し、そこからはズレている機能であると判断した。 解消プロセス 背景 機能利用率観測 顧客への説明 機能削除を実行 リリース時から機能利用を観測。 最終的に2%の利用に留まった。 削除の背景を説明。 代替手段も併せて提示。 機能を完全に削除。 顧客からは大きなハレーションを 生むことなく解消を実行できた。 36
37. 負債の解消 Case2. 世界観とはズレたコアなデータ構造を整備 「応募があるたびに、新しい求職者レコードができる」というデータ構造になっていた。 データを活かした採用マーケティングのシステムを目指す上で、この構造がネックに。 応募データと求職者データを分離し、求職者を一意に扱えるデータ構造へと再設計した。 解消プロセス 背景 負債解消方針検討 顧客への説明 データ構造の変更 ・ドメインモデリングで構造決定 ・体験変更点は顧客ヒアリングで調整 ・動画/ドキュメント作成 ・1〜2ヶ月前から全顧客に説明 ・CSからも直接説明 ・プロダクト価値をより尖らせられた ・多くの顧客から喜びの声 ただし、2%の顧客で大きなハレーション発生 37
38. ビジョン実現には、大きな負債解消が必要になる時がある 説明責任と最大限の配慮を尽くした上で解消を進める 負債の解消 38
39. まとめ 39
40. プロダクト負債とは何か？ 開発負債 体験負債 コンセプト負債 開発の進行に負の影響を与える機能 UXが悪く、顧客が価値に到達しづらい 機能 中長期でのプロダクト価値がぼやける 開発速度低下 / 不具合リスク増加 離脱率増加 / 顧客不満 意味 影響 意味 影響 意味 影響 世界観・ビジョンから逸脱した機能 顧客カスタマイズしすぎた機能 分岐が多く複雑化しすぎている機能 全く使われていない機能 例 本来の工程以上に、余計な手順を踏ま ないといけない機能 例 例 40
41. プロダクトを診断して、いつどのように解消するのか指針を立てる プロダクトの成長のために顧客への説明責任を果たし負債を解消する プロダクト負債に立ち向かうには？ 41
42. ご清聴ありがとうございました 負債に向き合い続けて、 成長できるプロダクトにしていきましょう！ 42