Web サイトを顧客開発しながら 3回ピボット（大きな方向転換）させた。それができた理由

こんにちは、はじめまして。覆面少女のプロダクトマネージャーです。先日 "風俗求人の健全化" を目指して「覆面少女」というサイトのランディングページを公開しました。

風俗求人はウソばかり、という時代をそろそろ終わらせませんか - 覆面少女

本体の Web サイトのほうは今年の夏リリースに向けて鋭意開発中ですが、わたしはこのプロトタイプ作成を担当していました。

このプロトタイプ完成までに、顧客開発しながら 3回のピボット（大きな方向転換）を乗り越えたよ、わたしがんばったよ、という話をしたいと思います。

そしてこのピボットについて振り返ったとき、ピボットの内容そのものよりも、どうしてピボットできたのかという要因について思うところがあるので、そこに言及したいと思います。

顧客開発モデルとは？

最近は日本でもプロダクトマネジメントが盛り上がっているので、ご存知の方も多数いらっしゃると思いますが、顧客開発モデルとは、スタートアップのためのマネジメント手法で、スティーブン・ブランク氏の書籍『アントレプレナーの教科書』『スタートアップ・マニュアル』の中核になっているものです。

「売れると思って作ったものが結局想定していたほどニーズがなかった」という失敗パターンからの教訓をもとに作られたモデルで、ひとことで表すと、「多くのヒト・モノ・カネを投入する前に、ターゲットのインタビューを行うこと」 ということです。書籍の中にも

オフィスから飛び出せ！

というフレーズが何度も登場します。

どうしてこれまで顧客開発できなかったのか？

しかし、しかしですよ、これだけ盛り上がっているにもかかわらず、あまり「オフィスから飛び出している」人を見たことがない。観測範囲が狭いだけなのかもしれませんが、少なくともこれまでに経験したウェブ企業はそうでした。みんな「そうねー。ユーザーの声を直に聞いたりしないとねー」と、その重要性は認識しつつも、実際には行動に移せていなかった（わたしもその一人でした）

なぜか。

理由はいくつかあると思うのですが、自分のことを振り返ってみると、下記の要因があったと思います。

(1) 面倒。アポを取ったり、実際に出かけて行ったり、結果を分析したりするのはたしかに手間がかかる
(2) 心理的な抵抗。まだやったことがないので、実行に移すまでに心理的な障壁がある
(3) 周囲の理解が十分でない。仕様を決めるのにいつまで時間かかってるんだ、と怒られそう
(4) 仕組み化されていない。仕様策定プロセスの中に「顧客インタビュー」が組み込まれていない

どうして今回は顧客開発できたのか？

では、どうして今回、顧客開発ができたのか？それはひとえに 「仕様策定プロセスの中に顧客インタビューが組み込まれていたから」 だと思います。スケジュールに入っているんだから、それが終わらないと仕事が終わらないのだから、やるしかない。

そして、仕様策定プロセスの中に顧客インタビューを組み込むことができた要因は 「周囲の人の、顧客開発モデルへの理解」 があったからだと思います。周りの人が、代表が、エンジニアが、デザイナーが、皆がプロダクトマネジメントや顧客開発モデルに関する書籍（本文下の参考書籍）を読んだりして、ひととおり理解してくれていた。薦めたのは自分ですが、本当に読んできてくれるなんて感動モノでした。

なので、「え。インタビューやるんでしょ？」という空気ができていました（本当にありがとうございました）

スケジュールに入ってさえすれば、あとは実行あるのみ。前述の心理的抵抗なんて、カマトトぶってんじゃねえよ、という話ですし、面倒なんて言ってられない。

どうしてピボットできたのか？

しかし、ピボットについては少し話が異なります。ピボットの何が大変って、それは（方向転換の振り幅にもよると思いますが）それまでに積み上げてきたものをすべて投げ捨てて、イチからやり直し、となる場合もしばしばだからです。今回もエンジニアやデザイナーに、その時点までにいろいろな作業をやってもらっていたので、それが無になると思うと、「あーあ、またイチから...」という空気が流れるのではないかと若干不安でした。

にもかかわらず、3回もやった、やりました。できた。

なぜできたのか。

一番大きな要因は、それを 「代表が自ら決断したから」 だと思います。顧客インタビューには必ず代表も参加するようセットしました。顧客の声を直に聞くようにしました。ピボットは最終的にはエイヤッでやるものなので、その権限を持つ人が直接情報を得て、その人が決断しないとうまく進まないと思います。

以下、『スタートアップ・マニュアル』からの長めの引用です。

顧客発見を完了したアントレプレナーはほっとしてしまい、往々にして顧客実証の現場作業を部下に任せてしまいがちだが、これはよくない。顧客実証をきちんと実行するためには、型にはまらない探索を行い、転向を恐れない柔軟性が必要だが、中堅や若手にはこうした裁量がないので不向きなのだ。

創業者自身が率先して顧客実証を行う必要があるのは、ピボットという大きな決断ができるのは創業者だけだからだ。そうした重大な決断を下すためには、創業者自身が自分の目と耳で製品やビジネスモデルの欠陥について顧客からじかに聞く必要がある。創業者（= 最終責任者）でない人間が製品やビジネスプランの欠陥について情報収集しても、所詮ピボットの権限がなく、そうした悪い情報を創業者（最終責任者）に報告するのは難しい。

学習意欲の高い仲間がいれば何もこわくない

そしてもうひとつ、ピボットができたというか、ピボットしてもチームのモチベーションが落ちずに、スピードも落ちなかった理由。それは 「チームの仲間の学習意欲が高かった」 ということ。

プロダクトマネージャーであるわたしがそんなに言葉を費やさずとも、みな自分で勉強して、「いま我々がどういう状況にあって何をしているのか」を理解してくれていた。ピボットという言葉を使わずとも、「いま、これが、ピボットなのだ」ということを理解してくれていた。ピボット直後に、エンジニアのひとりが 「今回も命拾いしましたね」 という発言をしたとき、「そう！そう！そうなのよ！」とちょっと興奮して泣きそうになってしまいました。

チーム内で共通の知識・理解（今回はプロダクトマネジメントについての知識・理解）があると、やはり物事がスムーズに進むように思います。チーム内で課題図書あるいは推薦書籍などを指定したり、読書会などをするのもひとつの手かもしれないですね。