■ 1. 入社4ヶ月で行った2つの撤退判断
- 引き継いだ2つのプロダクト:
- 1つは開発期間が約1年以上に及ぶ大型の新機能
- 大型機能はPdMが3人交代しており、リリース目前の状態で引き継いだ
- もう1つは単体の作り込みは進んでいたが、顧客の本格活用はこれからという新規事業のプロダクト
- 入社4ヶ月で、この2つの撤退判断を行った
- 判断の軸:
- 自分の言葉で価値を言い切れないなら、出さない、続けない
- 大型の新機能の判断:
- リリースの直前に「この価値があるから使ってください」と言い切れるかを自分に問うた
- 言い切れなかったため、リリースを中止した
- 新規事業のプロダクトの判断:
- 提供開始後に「今あるものがお客様の価値になっている」と言い切れるかを自分に問うた
- 価値になるまでの段差が2つ以上あり、言い切れなかった
- 追加開発をやめ、提供を終えた
■ 2. 1つめの撤退: 開発1年超の大型機能
- 低かった価値の解像度:
- ターゲット（誰に向けた機能か）は決まっていた
- どのユースケースの、どのペインを、どう解決して何が得られるのかの解像度が低かった
- この定義が共有されないまま、チーム編成の変更を重ねて開発が続いた
- 目的のすり替わり:
- 当初は具体的な価値に対して価値検証をする話があった
- チームとPdMの交代を重ねるうちに「一般公開まで持っていこう」に目的がすり替わった
- すり替わりは承認や引き継ぎの過程で起きた
- 削ぎ落とされていったもの:
- 価値検証の順番とゴールへ至る道筋
- マイルストーンごとに届ける価値
- 戦略上の進め方のペース
- 難解化した仕様:
- エンジニアに何度も時間をもらい解説してもらっても理解しきれなかった
- 「なぜこの仕様になっているのか」という疑問が連続した
- なぜそう作ったのかという意図はどこにも書かれていなかった
- 管理会計が複雑な領域であることを差し引いても、立ち止まるべきサインだった
- 違和感に慣れる怖さ:
- 入社直後は「管理会計のツールはこれくらい複雑で当然かもしれない」と自分を説得していた
- 新しく入った人ほど違和感を飲み込んでしまう
- 仕様が難しすぎるプロダクトは、たいてい何かが間違っている
- 揃っていた撤退の材料:
- 価値: 「この価値があります」と自分の言葉で言い切れない
- 保守: 難解な仕様のままでは今後のエンジニアが保守に耐えられない
- 運用: CSの構築と運用の負荷が重く、デリバリーとして組織的に厳しい
- それでも「止めましょう」とはなかなか言えなかった
- 止まれなくさせた2つの重荷:
- 1年分のサンクコストにより、積み上げた分だけ「今さら引けない」気持ちが強くなる
- 入社直後で早く成果を出したいという新参者の焦りがある
- 新参者にとって「止めましょう」はいちばん言い出しにくい言葉
- この2つが重なると、プロダクトは止まれなくなる
- 判断のきっかけ:
- リリース説明会当日の午前、PdM同士の集まりで別の事業を畳んだPdMの振り返りを聞いた
- その振り返りでは、価値の言語化が難しかったと語られた
- それを機に、経営管理ツールを知る前の入社前のフラットな自分に戻って考え直した
- 最後の決め手:
- 同日午後の営業向けリリース説明会の台本読み合わせで、熱がこもらなかった
- 「こういう価値があるから使ってください」の一文がどうしても自分の言葉にならなかった
- 撤退の材料は複数あったが、最後の決め手はこれだった
- 当日中のリリース中止:
- 読み合わせ直後にマネージャーに相談し、その場で同意を得た
- 夕方にリリース中止を決定し、説明会も取りやめた
- 違和感を抱えたままにせず、すぐ相談したため、その日のうちに決められた
■ 3. 2つめの撤退: 新規事業のプロダクト
- 単体での作り込み:
- 本来かなり複雑な業務を、シンプルな操作で回せる仕様に落とし込めていた
- プロダクト単体としての作り込みには手応えがあった
- ただし、お客様の日々の業務に定着するところまでは届いていなかった
- 価値までの2つの段差:
- 段差1は、業務に乗せるための大きな機能追加
- 段差2は、本体と一体で使える形への作り直し
- どちらもプロダクト単体の努力で越えられる段差ではなかった
- 提供終了の判断:
- 2つの段差を越えるには、本体との統合まで含めた投資が要る
- 今後のロードマップと組織、事業、戦略の状況を並べ、越えるのは現実的ではないと総合的に判断した
- 「いま優先すべき投資ではない」として、追加開発をやめて提供を終えた
- プロダクト単体の完成度と、価値が届くことは別の問題
- お客様への伝え方の設計:
- 正直に、謝罪と未来をセットで伝える方針をとった
- まずこれまでの協力への感謝を伝える
- なぜ続けられないのかを事実に沿って正直に説明する
- 何をして何をしないかの方針をあいまいにしない
- お詫びすべき点は率直にお詫びし、守ることを約束する
- この先の見通しを添え、急がずに納得を待つ
- 結果として、お客様の理解を得ながら今後の期待に向けた対話を継続できた
■ 4. 撤退を組織の教訓に変える
- 入社直後の成果:
- 入社直後の成果はリリースではなく「2つの撤退」だった
- 別の事業を畳んだPdMの振り返りが、自分の撤退判断を後押しした
- 1つめはチームで振り返り、記事と勉強会で共有した
- 2つめは勉強会で共有した
- 振り返りから、立ち止まるためのチェックリストを作った
- 社内でも「失敗を活かせた」と受け止められた
- 撤退の意味:
- 撤退は敗北ではなく、組織が学習している証拠
- 判断の妥当性:
- 2つとも撤退の判断は間違っていなかった
- 大型機能をそのまま出していたら、保守にも導入と運用の支援にも大きな手間がかかった
- その場合、お客様に安定して届けられなかった
- 新規事業を続けていたら、業務に合わせた機能追加と保守に手を取られた
- その場合、優先すべき投資に集中できなかった
- 撤退後の周囲の反応:
- 様々な人から、そのまま出していたら保守もデリバリーも現実的ではなかったと言われた
- リリースを心待ちにしていたメンバーには残念な思いもさせた
- 周囲では「撤退できてよかった」という声が多かった
■ 5. 明日から使える違和感の見極め方
- 立ち止まるためのチェックリスト:
- 1つでも当てはまったら立ち止まる
- 同じ論点の議論が3回以上ループしている
- 「誰の、どんな困りごとを、どう良くするのか」にチームが即答できない
- 主要メンバーの交代なのに、引き継ぎが1週間未満
- 顧客の声を聞かないまま、開発が2ヶ月以上進んでいる
- 「とりあえず出して後から考える」が合言葉になっている
- 期日の根拠が「コミットしたから」しかない
- 最小の実装で最大のお客様の価値になっていない
- 声を上げる姿勢:
- 職種や職位を問わず「ちょっと待って」と言う
- 指摘が間違っていてもよい
■ 6. 最終テスト: 自分の言葉で価値を言い切れるか
- 判断の場面に置く問い:
- リリースの前にも、続けるかを決めるときにも、この問いを置く
- 1つめは出す前に、2つめは提供を始めたあとに、同じ問いで撤退を決めた
- 危険信号としての問い:
- 言い切れないなら、それがいちばん早い危険信号
- サンクコストに引っ張られず、違和感に従うべき
- これはAI時代でも変わらない