第1回 顧客開発とソフトウェア開発の両輪を突き詰められず失敗した話
事業を行う上でが組織全体で意識すべきことにはどんなことがあるでしょうか。
戦略、マーケ、製品開発、組織づくり、考え出すとキリがなく、ビジネスでは変数があまりにも多いため間違ったKPIを追ってしまったり、間違ったコンセプトに基づいて行動してしまうことも多いと思います。
事業運営する上で寄って立つ中心となるコンセプトが欲しいといつも感じて来ました。
本稿では、顧客開発とソフトウェア開発(製品開発)の両輪という考え方のモデルとtoCの事業で失敗し、SaaS事業を運営する中で、失敗した話、実際に役立てた方法を紹介します。
もっともコアな考えは、顧客開発とソフトウェア開発のどちらを優先するのか
そもそも、顧客開発(Customer Development)とは、「アントレプレナーの教科書」というSteve Blank氏の著書にかかれている言葉である。
プログラミングや製品開発はそれだけでも専門的な技能を必要とするものであり、なにか製品のアイデアを思いついた時に、作り始めるのは「製品から」となりやすい。
しかし、何度もスタートアップを経験したSteve Blank氏が書いている内容は明快だ。「常に顧客開発を優先するべき」ということだ。顧客開発は主に、「顧客インタビュー」を中心にした。顧客の発掘活動のことだ。これに類似したことは
マーケ
日本のマーケタである、谷口氏のN1分析
デザイン・企画
デザイン思考
システム開発
スクラム
ユーザーストーリ
等でも繰り返し強調されている内容である。
しかも、「顧客開発」と呼ばれているくらいなので、たまたまニーズが合って獲得してインタビューした、という類のものではなく、ナーチャリングの活動も含めているので「開発(Development)」という単語が当てられているのだ。
とくに、事業のスタート時には特にこの考え方が有効だと感じる。
アイデアに対するソリューションの実装コストよりも顧客に聞くコストの方が常に安いという事情もある。
ボトルネックが顧客開発とソフトウェア開発のどちらであるのか
やっているうちに気づくことがある。事業のタイミングや規模の変化によって顧客開発がボトルネックであるときとソフトウェア開発がボトルネックであるときが出てくるのだ。
その度に、優先度(「組織の」かもしれないし、「自分の」かもしれない)を変更して進む必要がある。
製品開発が進むと別のユーザーストーリー、ターゲット、JTBDの顧客が現れるため、直接聞きに行く必要が出てくるのだ。反対に、顧客開発が進むと、主に機能の高度化が進むため、従来の顧客ではない顧客にも対応できるようになるのだ。
例えばこういった内容のことがあり得る。
エンタープライズ向けには全く違う課題を抱えている
小規模顧客は全く違う使い方をしている
金融セグメントのユーザーにはセキュリティが重要である
KPIとして、両立するように心がけつつ、自分の割く時間はよりボトルネックになっている方に比重を置く。というのが理想だと思う。
上手く出来たことはないが。。。
BtoBの方がやりやすい気がするがN1分析と考えるとtoBでもtoCでも関係なく重要
「アントレプレナーの教科書」自体は比較的toBよりの話として書かれているため、そのままのなぞるだけというのは難しいので、「リーン顧客開発」や「N1分析」に関する本等も参考にしたほうが良い。
toCの事業をやっているときにはまったくユーザー接点を確保出来ておらず、事業がすべて仮説ベースで進んでしまっていた。
そのために、すごい機能(と仮説を立てたもの)を開発してもユーザーに全く響かなかった。いやそもそもその仮説をあてるターゲットすら明確になっていなかったため、仮説の検証すら行っていなかったのだ。
そのときは、下記のようなことでできていなかったような気がする
ユーザー接点確保は自分のメインの仕事ではないと無意識のうちに感じてしまっていた。
両立が難しいと感じてしまい手が出せなかった。
toCではマネタイズしたい層が広くなりやすく、1名1名にコストをかけるのが非効率に感じてしまっていた。
toCのIT事業ではそもそも匿名ユーザーとしてサイトにアクセスすることも多いためユーザー接点は意識的に作りに行く必要がある。
toBになってからも常に周りのメンターや仲間からはユーザーに聞きに行こう、課題を見つけよう、MTGを設定しよう、と言われていたし、自分自体も顧客接点をもつことが大事だと言い続けていた。それでも、しっかり実行が回せるようになったと感じたのは始めてから半年~1年くらいあとの話だ。今でも上手く回せているとはいいづらい
それくらい実行が難しいことでもあると思う。やらない理由・出来ない理由はいくらでも見つかるのだ。色々な意味で、「怖い」のだ。
獲得済み顧客でも話の切り出し方やメリットの説明が難しい。
獲得済みでない顧客に時間をとってもらうのは億劫。
一度聞いてしまうと二度目聞きに行きづらい気がしてしまうので、大切な顧客を選別しているうちに聞きに行かなくなってしまう。
製品の完成度に自信が持てない。
どちらも重量級の時間がかかるため、ついつい優先度を下げてしまう。
MTG設定や実施には時間がかかる。
仮説ベースで進めた方がついつい早く感じてしまう。
浅い仮説を当ててしまってバカだと思われたくない。
ただ、客観的に考えるとこれらのことは杞憂に過ぎないし、ほとんどが自分の体面を気にした行動であることが多い。
第一に、顧客の課題を解決して、世界を変えるために事業をスタートしているのにこれでは辻褄が合わない。
もちろん、顧客は忙しい方が多い、ときには、そっけない態度の方もいたりするし、直接ではないにせよ間接的には製品へのアドバイスやダメ出しもされる。そもそも顧客の方が課題自体には詳しいのだ。だからこそ聞きに行く。
そもそもユーザーインタビューを受けてもらうには色々なチャネルからアプローチしなければいけないし、信頼の獲得方法も非常に難しい。
顧客の気づいていない、課題や価値の新しい切り口を模索し、より良いソリューションを提供することは、顧客のみならず世界に影響を与える方法だ。
そもそも事業にそういう志で取り組んでいなければならないし、そういう志と感謝で顧客と向き合えば、顧客もときに想定以上の協力をしてくれる。
体感だがヒアリングにはむしろオープンな姿勢の方の方が多い。
自分自体も勉強になるため、他社からのヒアリング依頼は受けるようにしている。
勇気をもってヒアリングに取り組もう。
顧客開発には個人としての得意不得意が存在するはずだが、組織で補えるのではないか
顧客開発と製品開発を一人でやっていくのは非常に大変だ。
製品開発は技術面のトレンドもあるし、自分の理解度もやっていく中でどんどん上げていかなければいけない。
顧客開発は相手がある仕事なので非常に時間がかかる。一定程度プロセス化できるが最後は手作業であり非常にクリエイティブな負荷がかかる。
同時にやれる人はいると思うし、一人でやると両方の解像度が上がるので一番良い方法だ。ドメイン知識があって技術の知識がある。というのが常に理想だ。
ただどうしても向き不向きや専門性の高さの壁はあると思う。
役割分担をして取り組むというのは常に一つのアイデアだと思う。しかし、スクラムの考え方にも従い、基本は同席が良いだろうし、質問者が限られて多様にならない or 分散してしまい深まらないというデメリットはある。
ただ、組織が大きくなったときには確実に役割分担するときが来る。そのときに、気をつけるべきは、チーム間での役割分担をしないということだと思う。今のところ最適な方法は見つかっていないが、少人数のチームを組むということなのだと思う。
組織全体で顧客開発を意識するには
顧客開発は誰の仕事だろうか。
立ち上げ時には、CEOだったり、プロダクトマネージャーだったり、事業部が大きくなれば、カスタマーサクセスだったり、事業開発チームだったり、色々な答えがあると思うが、組織全体で行っていくのが最も理想だと思う。
そもそも常に色々なチャネルで顧客からのインプットは発生している。
それらをすべてを拾って統計的に処理しようとすれば工数がかかる割に得るものは少ないだろう。工数がでかいのでついつい効率化したくなるが、なかなか効率的になりにくい作業なのだ。
工数がでかい割に、すぐに答えが見つかるわけではないので、優先度が下がっていってしまいやすい。いわゆる緊急度が低く、重要度が高いタスクにあたる。
そんなわけで、チームメンバーが増えれば他のメンバーに委譲したくなるタスクの一番のものでもある。
とくに製品開発のチームと顧客接点のチームを分けている組織は多いので、顧客接点チームに一任したほうが効率的だ。自分達は忙しいので出来ない。という議論になりやすい。
いくつか工夫して仕組み化したものもある。
顧客要望をチャットに収集する取り組み
全メンバーが自動でランダムで顧客接点を月に1回必ず設定される
顧客質問テンプレート
モックやデザインを顧客に見せながらのユーザーインタビュー
でも、仕組み化を意識し過ぎない方が振り返ってみると良かった気がする。
フェーズ、顧客規模や組織サイズで、やり方も聞くことも変わるのだ。
残念ながら答えは見つかっていないが、一般論としてはクレイトン・クリステンセンのRPV理論を意識することだと思う。
Resource: 人、時間、お金を明示的に顧客開発に多めに配分するようにする。
Process: プロセスで、必ず顧客開発が実行されるようにする。
Value: 価値で、Visionや行動指針に顧客第一主義等、顧客優先のことを明示し、リーダーがそのように行動する必要がある。
顧客開発は、意識して進めないといけない。やらない圧力の方が大きく、時に大きく初動が遅れてしまう。
振り返ってみると出来ていないことに気づくかもしれない。
そんなときに、本来の自分達がやりたかったことを思い出して、意識して前に進む必要がある。
勇気をもってとにかく顧客に連絡しよう。
別の機会に
顧客開発で大事なのは、量なのか質なのか。
両立しなければという話が多い
N1分析としては1件をやることが大事。やらないよりやる一歩。
ユーザーヒアリングで聞くべき内容がわからない。他のメンバーにどう伝えたらよいかわからない。
JTBD or ユーザーストーリが大切。
プロセスを聞くようにする。
質問が大切。
そもそも相手の方が詳しいという前提。詳しい人に話を聞くときどう行動するだろう。
参考文献
本稿の大元になっているのはこちらの本だ。