KPIが生むビルドトラップ

最近読んだ「プロダクトマネジメント　ビルドトラップを避け顧客に価値を届ける」という本から、ビルドトラップに思い当たる節があったので少し当時のことを思い出してみました。

ビルドトラップとは、機能を作ることばかりに集中してしまう状態のことで、本書の冒頭ではこのように説明されています。

ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。

私が人生で一番ビルドトラップの深いところにはまっていたのは、2社目に転職したばかりの頃でした。そしてその時の記憶を紐解くと、設定されていたKPIのせいでビルドトラップから逃れられなくなっていたのだと気づきました。

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

悪いKPIの王道

私の当時の担当プロダクトは、当時所属していた会社の公式アプリでした。私が入社した2013年の時点で、数百万のダウンロードがありました。

モバイルアプリの典型的な悪いKPIの代表例がダウンロード数です。よく言われることなので理由はここでは割愛します。私は当時から送客数をKPIとするべきだと主張していましたが、もっと「わかりやすい」指標が求められ、またそれまで「○○ダウンロード突破」というニュースを何度か発信してきた歴史的背景もあり、結果としてダウンロード数がKPIになりました。

当時の時代背景として、ソーシャルメディアにおける企業のプロモーション活動が活発化してきた時期であり、この会社がLINEの公式アカウントを開設したのもこの年でした。開設・維持・運用に高い費用がかかったり、取得できる顧客情報が限定的だったりする中で、自社会員基盤の強化は喫緊の課題でした。この事実もまた、ダウンロード数をKPIとすることを後押ししました。

この当時から、不適切なKPIを持っている自覚はありましたが、今思い返してみると、このKPIがビルドトラップに繋がっていたのです。

当時、私の所属部門を統括していた執行役員の主張はこんな感じでした。

2年で2000万ダウンロード（※）を達成する必要がある。
しかし、ブランディングのために値下げやクーポンによるダウンロード施策はできない。
そのため、達成するにはニュースを作り続けなければならない。
よって毎月新機能をリリースする。

※既に記憶にないので多分正確ではありませんが、これぐらい無謀な数字でした。

若い頃の私には反論するというオプションは無く、ここから長く辛い道のりが始まりました。

会話の主語が「お客様」ではなくなった

当時のロードマップには、思いつく限りの機能が1ヶ月毎に並んでいました。

開発の優先順位を決めるときには、当初こそ「お客様は何を必要としている？」という話をしたものの、次第に「1ヶ月で開発できるものは何？」に変わりました。

1ヶ月に1回のサイクルが厳しくなり、2ヶ月、3ヶ月と間があくこともありました。リリースされる新機能が少ないということは、発信できるニュースが少ないことを意味します。しかし機能をリリースしてもしなくても、ダウンロード数の増加ペースが大きく変わることはありませんでした。

たまに新機能が少しネット上で話題になるとダウンロード数が一時的に少し伸びました。こうなると、「一番ニュース性のある機能は何？」という観点が出てきました。お客様について語ることもありましたが、それは最優先事項ではなくなっていました。この頃は、私よりも開発者のほうがお客様のニーズを気にしていたのではないかとさえ思います。

一方で、現実の数字を見ると、このままのペースでダウンロード数が伸びても目標には到底届かないということは明らかでした。

私はこの状況を嘆きながらも、無力でした。

偉い人達は口を揃えて「お客様のために機能を出すんだ」と言いました。私は「欲しくもない機能を出すことのどこがお客様のためなのだろう」「お客様がスケジュール要求をしたわけでもないのに、品質を妥協してまで月1のサイクルを死守する理由は何だろう」と思っていました。そう思いながらも、他の方法をとることができる状況ではありませんでした。私のプロダクトロードマップを更新するには、偉い人の承認が必要だったからです。

数ヶ月やってみて、このままでは目標を達成できないことはわかっていました。「新機能をリリースし続ければダウンロード数は増える」という仮説が合っていなかったようなので、違う仮説を検証しなければならないということは明らかでした。

それでもKPIの変更ができる状況ではなく、使える予算も施策にも制限がある以上よい代替策も出せず、機能リリースを続けるという方針は変更されませんでした。

KPIがダウンロード数だったので誰もダウンロード後の動きには見向きもしませんでしたが、密かにアンインストール数も右肩上がりになっていました。

KPIはどのようにしてビルドトラップを生んだのか

振り返ってみると、この時のKPIは2つの意味でビルドトラップを生む要因になっていました。

1. 価値と直結しない指標を追っていた
そもそもダウンロードだけではビジネスへの直接的な貢献はありません。そしてそれは、ダウンロード数を稼ぐための施策が必ずしもプロダクトの価値に結びつかないということを意味します。

私のケースでは手段として「毎月の機能リリース」が選ばれましたが、価値に直結しない指標を達成しようとするとどうしてもこのように価値を上げる以外の行動をしがちです。価値が上がったことはアウトカムから計測可能ですが、アウトカムから成功を計測できないときに人はアウトプットを求めがちです。

2. 数値目標が高すぎた
仮に真っ当な指標がKPIになっていたとしても、目標値が非現実的なほど高いのはビルドトラップを生む要因になり得ます。なぜなら、KPIは現実の顧客が使った結果動くものであり、正しい価値を提供しても非現実的な伸びをしないからです。高すぎる目標があると、話題性を狙うなどのトリッキーな施策を打ちたい欲求が必ず出てきます。しかし本来あるべきアウトカムとは別のものを狙い始めると、アウトプットに傾倒するリスクが高まります。

後日談

私がこのビルドトラップの典型例のような環境から抜け出せたのは、担当プロダクトが変更になったからでした。新しく担当することになったプロダクトでは、比較的ましなKPIを持つことができました。

その当時はビルドトラップなんていう言葉は知りませんでしたが、担当が変わってからしばらくして振り返った時には「あの頃は何かに取り憑かれていたようだ」と思いました。

元のプロダクトのその後については、ほどなくして執行役員も変更となり、1ヶ月に1度の機能リリースもなくなりました。クーポンをドライバーとした施策が入れられるようになって急激にダウンロード数が伸びました。開発チームの体制も変わりました。しかし、その後KPIが変更になったかどうかは不明です。