契約のために作った機能がプロダクトを殺す、300店舗解約の教訓『THINK BIGGER』

「この機能があれば、全店展開の稟議を通せます！」

国内300店舗を展開する大手小売企業の会議室。担当者から言われたその一言で、私はその場でGithub Projects のバックログ（PBL）の一番上に新しいアイテム（PBI）を積みました。
同時にAIで開発規模を概算し、2週間後にデモをレビューするアポをその場で取り付けました。

あの時は、誰もが勝利を確信していました。事業立ち上げ初期からコンセプトに賛同し、トライアル店舗をいくつか選定してプロダクトを一緒に育ててきた、大切な「ティーチャーカスタマー」だったからです。
週次で機能をリリースし、VOC（顧客の声）の反映スピードも早く、担当者との信頼関係は抜群でした。

展示会で絶賛されたダッシュボード

本社の決裁者の関心を惹きつけるために作った「データ分析ダッシュボード」は、展示会でも多くの企業から絶賛されました。これが決め手となり、難関だった社内稟議も一発で通過。無事、契約書に判が押されました。

しかし、これこそがプロダクトの寿命を縮める、静かな引き金だったのです。
システムが全店舗に展開され始めると、現場からは肯定も批判もない、冷ややかな沈黙が広がりました。私が最も開発を劣後させていたのが、日々店舗で働く「現場のスタッフ」向け機能だったからです。

現場あがりの担当者の言葉は、現場の声ではなかった

実は私たちは、現場の声を一度も直接聞いた事がありませんでした。実際の店舗に足を運んだこともありませんでした。
「自分は現場からの叩き上げだ」という本社の担当者の言葉を、店舗スタッフ全員の総意だと都合よく信じ込んでいたのです。

現場のスタッフがログインしなければ、データは溜まりません。本社の決裁者がたまに開くダッシュボードに映し出されるのは、いつも虚しい「ゼロ」の数字だけ。
1年後、私たちのプロダクトは、現場スタッフ専用のスマホアプリを作り込んでいた競合にあっさりと乗り換えられました。

事業立ち上げから二人三脚で歩んできた顧客を失ったショックは、事業部全体をどん底へ叩き落とし、オフィスには敗北感が漂っていました。

商談の熱量が、思考の掛け算を狂わせる

本書を読みながら、私は当時の自分の甘さを何度も思い出しました。アイエンガー教授のメソッドに照らし合わせると、あの時の私たちは、完全に「思考の掛け算のミス」を踏みぬいていました。

• 解くべき「課題」の選択ミス
  「店舗のスタッフが、日々の忙しい業務の中で毎日触りたくなるか」というプロダクトの生命線ではなく、「どうすれば300店舗に広げる稟議を突破できるか」という営業課題を優先した。

• 「意思決定者」の要望の掛け違い
  商談窓口の担当者と抜群の信頼を築き、毎週アジャイルに要望に応えていたことで、本当に救うべき現場のスタッフの要望を完全に無視している現実に自ら目隠しをした。

• 「検証」のバイアス
  「現場のことは知り尽くしている」という本社の担当者の言葉を拠り所にしてしまい、直接現場に出向いてスタッフを取り巻く環境や仕事の流れ、顧客とのやり取りなど店舗の実態を観察することを怠った。

担当者の要望をそのままPBIに落とし込む行為は、顧客への誠実さではありません。それは、プロダクトを作る人間として、真の課題（インサイト）を見極める責任を放棄したことと同じでした。

道具の価値は使う人次第

アジャイル開発という、常に変化に適応しながら価値を届ける仕組み自体は極めて優れていました。間違っていたのは、その強力な武器の「使い道」です。
当時の私は、本社の担当者や決裁者を納得させるための「営業的な攻略」と、現場に使い続けてもらうための「プロダクトとしての攻略」を、完全に混同していました。

アジャイルであれば、常に「最もユーザー価値の高い課題」にフォーカスして開発するべきでした。にも関わらず、私は「決裁の都合を叶える優先順位」を前提に、アジャイルを高速で回転させていました。
これでは、どれだけ機能開発とレビューを重ねても、「誰にも使われない機能のゴミの山」が爆速で積み上がるだけでした。

あのどん底の絶望から、私たちはどうやって這い上がったのか。そして、二度と同じ過ちを繰り返さないために作った、防衛策とは何か。後半では、教科書的なフレームワークや綺麗事では終わらない、私が泥水をすすりながら掴み取ったリアルな生存戦略をお伝えします。

「ここから何をするかだけ話そう」

あの顧客は、二度と戻ってきませんでした。しかし、私たちは死にませんでした。
オフィスに重い静寂が広がっていた金曜の夜、私たちを救い出してくれたのは、犯人探しではなく、スクラムの「振り返り（レトロスペクティブ）」という対話の仕組みでした。誰のせいにもしない。起きた事実をただ机の上に並べ、次の週に自分たちが、具体的に何をトライするかだけを話し合いました。

その暗闇の中で、最初に動き出したのは営業チームでした。

現場で目の当たりにした不都合な真実

失意の翌週から、営業担当はスーツを脱ぎ、担当顧客の現場へ次々と飛び込んでいきました。ただ話を聞きに行くのではありません。店頭で自ら商品を並べ接客をし、バックヤードで棚卸しと在庫確認を手伝い、レジの後ろに立って、店舗とスタッフのリアルな日常を肌で感じるためでした。

そこで突きつけられたのは、あまりにも不都合な真実でした。

「やらなくても仕事は進みますし、忙しくて時間がありません」
「店頭だとお客様からスマホで遊んでいると思われそうで…」
「店長から何度もお願いされて仕方なく入力していました」

現場のスタッフが、私を呼び止めてこう言いました。
「ベンダーさんが直接お店に来てくれるなんて、初めてです。あのシステムを作った人なんですね」

店頭で接客をするスタッフにとって、最も大切なのは目の前の顧客との関わり合いです。接客の合間に、スマホの画面をポチポチといじる暇など、一秒もありませんでした。
これこそが、本書が説く、自分たちのバイアスを完全に排除した検証を、手に入れた瞬間でした。

営業が店頭に立って掴んできた生々しい実態は、日々開発チームへと共有されました。私は、ダッシュボードや本社で運用するための機能開発をすべて止め、スタッフ向けの機能だけにリソースを集中しました。

プロダクトはユーザーのために存在する

アジャイル開発が奏功するためには、前提として「誰の課題を解決するか」の優先順位が正しくセットされている必要があります。
営業的な攻略のためではなく、現場のスタッフが毎日使う道具を磨くためにアジャイルを活用する。私たちには、この割り切りが必要でした。

• 店舗スタッフの作業時間を減らせる機能を、常にPBLの一番上に置く

• 管理画面の使い易さを劣後し、最低限の操作で動くスコープに絞って開発する

• ダッシュボード系の開発を全て止め、手作業でCSVを抽出しAIで分析して担当者に送る

優先順位に対してアジャイルを重ねることで、初めてプロダクトは生きた価値を持ち始めます。

本当に必要なものを引き出す3つの問い

明日から、顧客や社内の「これがないと契約できない」「これがあれば契約できる」という声に飲み込まれそうになったとき、3つの防衛線で自分を踏みとどまらせてください。

1. その機能の開発に着手する前に、実際にツールを使うユーザーの動きを10分間観察し続けたか

2. PBIのワイヤーフレーム（WF）にあるそのボタンは、忙しいユーザーが迷わず押せるほどシンプルか

3. 何度も会っている目の前の担当者の言葉を、現場のリアルよりも優先していないか

これらに答えられない機能は、担当者からどれほど強く頼まれても、勇気を持って削り落とすべきだと思います。

現場を知らないプロダクトマネージャーがプロダクトを殺す

綺麗なオフィスの会議室で、パズルを組み合わせるような議論を重ねても、現場を知らなければ何も届きません。

机の上の整理された情報ではなく、自ら現場を見に行くこと。それだけが、生存への切符になると私は信じています。

もし、この思考の跡があなたの「武器」や「盾」の一助となったなら、「スキ」をいただけると幸いです。
画面の向こうに、同じ景色を見ている誰かがいる。それだけで、明日もまた現場に立てる気がします。