ハードシングスへの突入と脱出
こんにちは、HiCustomer代表の鈴木と申します。
HiCustomerは2017年創業のSaaSスタートアップです。累計2億円強を調達しカスタマーサクセス領域のプロダクトを提供してきました。業界黎明期から続けてきた情報発信のおかげで、カスタマーサクセスに取り組む方は名前くらいは聞いたことがあるかもしれせんが、実のところ直近2年間は事業が停滞し、eNPSが下限の-100を叩き出すほど組織が壊れ、窮地に追い込まれていました。
なぜ僕たちは暗黒期に突入してしまったのか、その原因を結論から書くと、
誤った目標設計
回らないプロダクトのフィードバックサイクル
フォーカスの甘いプロダクト開発
事業ドメインと相性の悪い技術スタック
上記4つの合わせ技でモメンタムが失われ、スタートアップの魔法が切れた。
と整理しています。僕たちと同じくアーリー期で雌伏の時を過ごす周囲の起業家とこの件を話すと、皆ほとんど同じ原因で苦労していることに気づきました。「勝ちに不思議な勝ちあり、負けに不思議な負けなし」と言われますが、僕たちの経験はSaaSスタートアップにとって一定の再現性があるかもしれません。
この文章は日本から世界を代表するSaaSが生まれることを願って、同じ状況で苦しむ起業家や創業初期のSaaS関係者、エコシステムへの貢献をモチベーションとして書いています。（願わくば将来一緒に働く仲間にも届いて欲しい！）
後半ではこの状況からどのように抜け出し、高いモメンタムを取り戻したのか、そしてこの経験から何を得たのかについて説明します。
（以下常体で記載、7,000字あります🙇♂️）
創業から暗転までの道のり
日本を代表する会社に
今では当たり前になった「カスタマーサクセス」というキーワード。創業した2017年当時、国内ではまだほとんど認知されていなかった。この領域でプロダクトを作ると決め、多くのヒアリングを重ねたが、SaaSの現場ですら「ヘルススコア」という言葉を初めて聞くという人が多かった。それでも、生産労働人口が減少し既存顧客との関係性に注目が集まるのは必然であり、数年のうちに日本でも「カスタマーサクセス」という考え方が普及するだろうと考えていた。そしてなにより、この領域で日本を代表する会社を作りたいという気持ちが強かった。いつか大きなメディアに取り上げられたときに、何をやっている会社かひと目で分かるように「Customer」か「Success」を。企業とユーザーの距離を近づけ、顧客志向なサービスを増やすコミットメントとしてフランクな挨拶である「Hi」、これを繋げてHiCustomerという社名にした。
共同創業者との再会
時間を少し巻き戻して創業前。アイディアを一緒に形にできるエンジニアを探して七転八倒しているときにVCの友人から「新しい人より、今までの縁を手繰り寄せた方がよいよ」とアドバイスを貰い、久々に会ったのが共同創業者となる肥前くんだ。以前の職場で一緒に新規事業を立ち上げた経験もあり互いに人となりは理解していた。僕の話すアイディアについては正直わからん、という感じだったが、時流に乗っていそうということと、プロダクトをゼロから立ち上げることに強い興味を持ってくれていたので、週末プロジェクトから始まりそのまま一緒に会社を創業した。
コミュニティを初期ユーザーに
創業期はプロダクトの開発と並行しコミュニティへの情報発信に力を入れた。今でこそ日本語の文献が増えたが、当時、カスタマーサクセスに取り組む方々にヒアリングすると、自社の取り組みに自信を持てていなかったり、海外含む他社がどのような取り組みを行っているか、興味があるが知るすべを持たない人が多かった。なので、Facebookグループを作りそこで海外トレンドを発信したり、オフラインイベントや人を繋ぐ飲み会を開催したりした。それが功を奏し、カスタマーサクセスに詳しい人という認知が作れ、多くの人に取り組みを応援してもらえる状況になった。これが初期ユーザーの母体となる。
無用な焦りが引き起こす暗転
2018年、プロダクトの正式リリースを行う。コミュニティから転じた初期ユーザーと各種メディア掲載もあって、デモ申込み数、有償契約率に関する初速は順調だった。海外で先行するカスタマーサクセスプラットフォームはとにかく出来ることが多い。これからHiCustomerに実装するべき機能リストのことを考えると、早いタイミングで大型の調達を仕掛けたい。そして、国内におけるポジションを盤石なものにし、いつか進出してくるだろう海外勢への優位性を築きたい、その無用な焦りから後々まで尾を引く意思決定ミスを行うことになる。
永遠に訪れないPMF
MRR数百万円までは比較的順調に推移した。正式リリースから1年以上経過し、開発体制は拡充され、機能は増えている。それなのに、本来は上がるはずの受注率が横ばいからついに微減する。何かがおかしい。カスタマージャーニーを可視化し、顧客の業務フローとプロダクトの機能を重ね合わせる。業務フローを回す上で重要な機能が足りていないことは明確だったが、「プロダクトひとつ分」と言えるほど大きな機能でリリースまで半年以上時間が掛かることが分かっていた。それでもこの機能ができれば事態は好転すると信じ、モックを作り、ヒアリングを重ね、夏から開発に着手する。バグ修正やセキュリティ対応以外ほぼすべての開発リソースを投下し、リリース間近となった2020年冬、深夜。エンジニア全員から連名でSlack DMが経営陣に届く。「エンジニア一同で話し合ったが、以降の開発を続けるモチベーション維持が難しいので相談したい」とのことだった。
地獄の門をくぐる
全員ずっとモヤモヤとしたものを心に抱えていたらしい。言わずもがな、スタートアップには、成長機会やキャリア/報酬のアップサイド、世にないプロダクトを自らの手で作り出す場を求めてメンバーが集まる。プロダクトの成長性が不確かで、開発者としての手触り感が持てておらず、なおかつハードワークが続いてたとすると、その訴えはいつ起きてもおかしくないものだった。メンバーと対話を重ね、方針を決め、実行していくもエンジニアが1人ずつ退職していくことを止められない。ついに最後の1人になる。一時的に新規営業も止めた。このペースで赤字が続くとどうなるのか。スプレッドシートで簡単な数式を組み、今月のセルを掴み右にドラッグする。残された期間はあと10ヶ月しかなかった。
何を間違ったのか
なぜ僕たちはここまでモメンタムを失ってしまったのか。決定的な事件・事故がなくとも個々人の「何かがおかしい、うまく行っていない気がする」というマイナスの感情が溜まっていくと、あるとき瞬時にスタートアップの魔法が切れる。噂には聞いていたが、話半分に聞いていた。でも、実際に起きたのだ。僕たちの場合、以下1から4の複合がこの状況を招いたと整理している。
1.誤った目標設定
エクイティ・ストーリー・ドリブンな事業運営
前述の通り、「カスタマーサクセスプラットフォーム」を成立させるためには作らなければいけない機能が多い。そのため大きな資本が必要だった。機能開発の優先順位はその資本を獲得するための「足元の成長に寄与する機能」がいつも上位だった。しかも、その足元の成長寄与判断も感覚によるものだった。事業側のKPIについては毎月のNew MRRの数値に一喜一憂していた。
典型的なビルドトラップ
とにかく早く成長しなくてはならないという焦り。その結果、開発チームの目標がベロシティ一本になる。「何をなぜ、どのように作り、どんなインパクトがあったか」ではなく、「目標通りの時間でリリースできたか、ボトルネックは何だったのか」がレトロスペクティブの場で確認される。のちにこれは典型的なビルドトラップに嵌っている状態だと知った。
本来はどうすべきだったのか
スタートアップなので何を目指しどのように成長していくか、ストーリーは大切。ただし、開発の現場においては「カスタマーサクセスプラットフォーム」ではなく「カスタマーサクセスの業務に課題を抱える人向けのソフトウェア」をn=1のサクセスを確認しながら丁寧に作っていくべきだった。誰の、どんな課題を、どのように解決するのか。これを開発前に可能な限り精緻にしていき、機能のまとまりごとにその成果を測定する。本来はこれを繰り返しプロダクトを成長させるべきだったのだが、次項によりうまく機能しなかった。
2.回らないフィードバックループ
長いリードタイム
プロダクトの特性上、契約から利用可能な状態になるまで、顧客に多くの作業をお願いせざるを得ない期間が長く続いた。データ連携作業や複雑なセットアップなど、本業で忙しい顧客側のエンジニアやCSが複数人関わるプロジェクトの管理が必要だった。現在は大幅に改善されたが、リリース初期は利用開始まで半年以上掛かるするプロジェクトもあり、作ったプロダクトが狙った価値を出せているのか、それが分かるまで長い期間を要する。ある程度売れてしまっていた慢心もあり、狙ったど真ん中の価値が出せているのか、その検証が遅れた。
早すぎた権限委譲
一日でも早く権限移譲を進め、成長とともに次から次に押し寄せるであろう課題に多くの時間を使える体制を作りたかった。そのため、正式リリース後に既存顧客との接点をすべてメンバーに委譲してしまった。何を改善すべきなのか、現場の一次情報が入らなくなる。その結果、事実に基づくフィードバックループが回りにくくなる。
本来はどうすべきだったのか
少なくとも最初の顧客セグメントがPMFしたと感じるまで、開発優先順位の精度を高めるため、プロダクトオーナーである僕が契約後の工程をすべて担当すべきだった。イマイチな箇所を人的支援で解消するのではなく、プロダクトの改善で対処できるよう優先順位を組み替える。また、アジリティ高く開発が進められる機能から作っていくことができたらリズムが生まれ、停滞リスクが減ったかもと振り返っている。
3.噛み合わないバリュープロポジション
粗いセグメンテーション
僕たちのプロダクトを使ってくれるSaaSベンダーは一言でSaaSと言っても実際はプライシング、提供価値、エンドユーザーの種別、事業フェーズ等々で実現したいカスタマーサクセスのHowが全然違う。市場が黎明期だったこともあり、顧客が求めるプロダクトの形も短い期間でダイナミックに変わっていった。顧客の種別×要件を細かく絞り、リソースを一点投下していくべきだったところだが、このセグメンテーションが粗い状態で機能開発とマーケティングを行ってしまった。セグメントの切り取り方が甘いと、機能がもたらす成果もぼんやりしたものになる。これによりアンマッチな商談機会が増えるなど限られた時間を有効に活用できなかった。
アンバランスな提供価値と労力
上述の1,2そして粗いセグメンテーションにより、顧客への提供価値と開発の労力が釣り合わない機能をいくつもリリースしていた時期があったし、この価値を提供するために下準備としてあれとこれとそれが必要だ…という連鎖に囚われていた。少ないリソースにおいて戦局を左右するのは優先順位付けの精度だと痛感している。
本来はどうすべきだったのか
開発とGo to Marketはセットであり、その足並みをもっと早く揃えるべきだった。狭く作って狭く売る、この繰り返しを精度高く実行していく。誰もが認めるPMFなど存在せず、PMFのM（市場）は自分たちで可能な限り狭く定義する。売れるから、特定のARRに到達したからPMFだとは言わない。狙った市場で顧客の期待を超える成果が出せる。それを耳にした他の顧客が増える。この繰り返しでしか事業は伸びない。
4.根の深い技術的負債
事業ドメインと相性の悪い技術スタック
比較的歴史の浅いモダンな技術スタックを選定し、その上に機能を積み重ねていった。あるタイミングから表面上は小さな機能改修に見えるものでも物によっては多くの工数が掛かるようになった。根幹に据えたデータベースと他スタック、及び今後開発していきたい機能との相性がよくないことが次第に分かっていく。負債の改修に多くの時間が充てられるようになり、これもエンジニアの士気を下げる一因となる。
チームの認知負荷を超える開発環境
根の深い負債に加え、1人で1つの機能をリリースするまでにいくつもの技術的分野の横断が必要な、チームトポロジー的にいうと認知不可を超えた開発環境になってしまっていた。新しいメンバーを迎え入れても一定のまとまりのある機能が作れるまでかなりの時間を要する状態であり、開発者としての成功体験や自己効力感が得られるまでさらに多くの時間を有した。
本来はどうすべきだったのか
技術選定は開発の生産性に直結するので、作り始める前に経験者からのリファレンス含め徹底的にリサーチを行うこと。僕たちの場合、初期から「選定した技術」の専門家にご支援を頂いたのだが、全体を俯瞰してレビューをしてくれるアドバイザーを招聘すべきだったように思う。（そしてこれはプロダクトマネジメントも同じ）
しかし僕らは生き残った
そのまま空中分解してもおかしくなかったと思う。ポール・グレアムが言うように僕たちも「どこかに這い出していって、そして死ぬ」かもしれないと思った。しかし、僕たちは今も生きている。あのDMから1.5年が経った今、（信じられないかもしれないが）実は今が創業以来いちばん高いモメンタムでチーム一同仕事に打ち込めている。一時期は下限だったeNPSも＋33まで回復した。諦めず、キーを打っている最中に死ぬことはないというのは本当なのだと思った。結果的に作用したと思われる取り組みを列挙する。
失敗の原因をオープンにする
このままではマズイという状況になってから、何が問題でどのような原因・背景によってこの状況が起きたかを棚卸しした。全ての商談履歴、解約原因、機能リリースの順番、経営判断のドキュメントを洗い、そこから問題点をひとつずつ抽出し、整理し、全員に共有する。どん底の状態で連日自分の誤りを認めていく作業はなかなか来るものがあった。ただ、これを始めにやったおかげで市場のポテンシャルや顧客の課題は明確であり、課題のあるプロセスさえ軌道修正できればもっとうまくやれるはずだという合意形成がチームでできた。
会社の存在理由を言語化する
創業以来、ミッションやビジョンにあたるものは制定していなかった。創業するときよりも、モメンタムが大きく失われ、ある意味マイナスからのスタートである今こそ、この会社がなぜ存在するのか言葉にする必要があると感じていた。全員自信を失っていたのだ。僕が個人として何に喜びを感じるのか、起業家として何を成し遂げたいのか、会社として何を意思決定の礎とするのか、社会から何が求められており、何を果たしていくべきなのか。毎日何のためにデスクに向かうのか。仕事を通じて、誰を幸せにするのか。それらを会社のパーパスとして言語化した。
開発プロセス、ドキュメント体系の整理
プロダクトマネジメントの反省を活かし、顧客セグメントを細く切り、それぞれでバリュープロポジションを定義した。顧客の課題 - 対応ソリューション - 狙う定量成果を紐付けたドキュメントを作成し、可能な限り開発に着手する前に仮説検証を行うようにしている。経験上、開発の手戻りが時間と精神力を削っていくし、どのレイヤーの何の仮説が正しく、もしくは間違っていたのかを検証するためにドキュメントの体系が崩れているとかなりしんどい目に遭う。これを整理することで生産性が格段に上がった。また、負債の原因となったアーキテクチャも大幅に見直した。
小さな成功を祝いリズムを作る
修正したプロセスによってもたらされた結果は測定し、上向いていたらチームでちゃんとお祝いした。OKRの運用を再開し、チームの目標と個人の活動を紐付け、誰が何にトライしているかの透明性を高めた（Asanaで管理している）。週の最後にはWin sessionを設け、個人ごとの達成事項を共有し、ちゃんと祝う。たとえ小さくとも正しく行動すれば前進できるという成功体験を改めて共有していった。
コンサル事業の立ち上げ
以前よりプロダクトから少しはみ出た領域でコンサルティング依頼を受けることも多かったのと、ランウェイを伸ばす必要があったためこのタイミングで始めたコンサル事業だったが、カスタマーサクセスのプロセスに課題感を持つ会社は多くかなり順調に立ち上げることができた。プロダクトを通じ多くの会社を支援してきた経験が活き、プロジェクトを通じ早いうちに顧客から非常に高い評価を頂くことができたのもチームのモメンタムを復活させる大きな要因となった。
一連の危機を通じて得たもの
渦中は本当にしんどかった。自信は崩れ、無力感に支配されそうになりながらも、1日でも早く浮上しないと全てが終わってしまうのだ。同じような経験はもうしたくないが、大きな危機を乗り越える過程で得られたものは確かにある。
感謝
別々の道を歩むことになったが、思うことをぶつけ全てを改め直すきっかけをくれたメンバー。負けたまま終わるのは絶対に嫌だとみんなを鼓舞して一緒に乗り越えてくれたメンバー。リスタートの過程で助言と組織再建を支援してくれた株主。とにかく1日でも早くなんとかしようと連日深夜まで議論に付き合ってくれた共同創業者。
1人でできないことを成し遂げるのが会社なのだ。
レジリエンス
個人・チーム双方の視点で、問題/課題が顕在化したときの修正力・回復力が以前より格段に早く・強くなったように思える。一連の経験を通じて、また同じような苦境に立ったとしても、あのときは乗り越えられたじゃないか、という経験を組織で共有できるのは大きな財産になると信じている。
事業への確信
カスタマーサクセスについて考え抜き、また一連の失敗を通じて、誰に何を届ければよいのか、どのようにプロダクトへ落とし込んでいけばよいのか。自分の中で筋道がクリアになり、その確信が強くなった。無用な焦りや力みが消え、ピュアに事業に向き合えるようになったと感じる。
満を持して２打席目に立つ
そして、今、僕たちの経験を全てつぎ込んだ新しいプロダクトを準備している。同じ事業ドメインで2打席目のプロダクト開発ということもあり、プロダクトのビジョンや提供価値は早くから共感を集めることができているし、何よりβ利用のフィードバックから大きな手応えを感じている。またここから大きな勝負が始められることに心からワクワクしているし、丁寧に価値提供を積み上げて行くことで社会の大きな課題を解決していきたい。やるぞ！
最後にお知らせ
ここまで長文をお読み頂きありがとうございます🙏
2打席目のホームランを目指し一緒に顧客に愛されるプロダクトを作る仲間を探しておりまして、中長期でチャレンジできる環境を探している方、ぜひ一度お話しましょう。また、この文章が何かのヒントになれば幸いなのですが、同じような苦境にいる起業家でもし直接話してみたいということであればTwitterまたはFacebookのDMでお気軽にご連絡ください。
この記事が気に入ったらサポートをしてみませんか？