SaaSの真骨頂「プロダクトの継続的な改善」をエンプラ市場で回す為にやってきた事
note読者の皆さん、はじめまして。
テックタッチ株式会社CTOの日比野です。
先日、シリーズBとして17.8億円の資金調達を発表させていただきました。
テックタッチは創業が2018年3月ですので、シリーズBまで4年10カ月かかったことになります。
この記事を開いていただいている方ですと、界隈の方が多いと思いますので釈迦に説法感はあるのですが、シリーズBというのは「事業を急成長させるフェーズ」になり、僕らはそのスタートラインに4年10カ月を経て立つことができました。
このタイミングでこれまでを振り返り、経営陣がそれぞれ何かしら記事を出そうとなりまして、今僕も書いております。
テックタッチの希少性は「スーパーエンタープライズ向けのSaaS製品を提供していること」にあると思います。
スーパーエンプラ向けのSaaS製品をスタートアップが開発する際に、何か特徴的なポイントがあるのか振り返って考えてみたのですが、SaaSの真骨頂でもある「プロダクトの継続的な改善」の実施に最も苦労が多かったと思いますので、ここを赤裸々に、懺悔も含め書いていこうと思います。
と書くとだいぶニッチな雰囲気が出ますが、エンタープライズ向けではなくBtoBSaaSを提供している（していく）全ての方に役に立てるように書いていきたいと思います。
鶏が先か、卵が先か - エンプラにおける「プロダクト改善サイクルを早く回してPMFへ」の難しさ
SaaSは「ペイドユーザーからのリアルな声」をもらいプロダクトを改善していける事こそが真骨頂だと個人的に思っています。このプロダクトのフィードバックループをどれだけ早期に回して、PMFに近づくかが資金力のないスタートアップでは成功のカギを握ります。
しかし、エンタープライズ企業の場合、この「フィードバックループを早く回すこと」が極端に難しくなります。多くのSaaS企業では、「β版」と銘打ったりして、無料に近い金額で、数社の顧客に利用し始めてもらうこと、など初期フェーズは実施すると思います。しかし、エンタープライズになるとここが難しい。セキュリティとリスクを重んじるので、「β版」なんて危険極まりなさそうな製品は導入してくれないし、ステークホルダーが多く、セキュリティ要件や予算時期の関係でとにかく営業のリードタイムが膨大にかかります。また、実績を重要視する傾向があり、企業の評判も導入実績もないスタートアップはさらに導入のハードルが上がります。
実績がないと導入してくれない。けれど導入してくれないと実績が作れない。「鶏が先か、卵が先か」の話に通じるものがありますが、実績はやはり導入なくては作れません。ここに「導入と実績のサイクルのジレンマ」があったように思えます。
禁じ手「顧客の個別開発」の受け入れ
私たちも最初は、複数の会社さんから少しだけお金をいただいて、プロダクトのPDCAを回そうとしました。が、いわゆるターゲットにしていた「スーパーエンプラ企業」様ではなく、遥かに規模の小さな企業が多かった。ですので、本当にこれでプロダクトの方向性が正しいのか、少し悩んでいました。
その頃に、とある「誰もがご存知の超大企業」様から、導入に前向きの話がありました。この企業さん向けの独自の機能開発を要求されましたが、そこをクリアできれば、「受注」と「事例の広報」を確約の話をいただきました。
ここは非常に悩みました。社内でも多くの議論をしました。SaaSでは、個別企業の独自の機能開発を受け付けるのは「禁じ手」とされているのはご存知の通りです。しかし、最終的にあえてこれを受けさせていただきました。全ては導入と実績のサイクルのジレンマを断ち切るためです。SMB向けのSaaSと違い、エンタープライズは社数や商談数も限られるため、この機を逃すと次のチャンスはいつになるかわかりませんでした。
個別開発の内容は、IE下位互換（IE5）への対応で比較的重めの内容ではあったのですが、開発のゴールが明確だったのと既存コードとは切り離して開発できることで、今後の開発へ悪影響を及ぼすリスクはコントロールできる、と判断しました。
結果として、エンジニア陣の奮闘もあり、無事にスケジュール通り納品する事ができ、CSの渾身のカスタマーサクセスもあり、価値のある導入実績を作ることができました。
これは、自分たちの自信にもなりましたし、この「ロゴ」（実績）のおかげで、半年でスーパーエンプラ10社近く獲得、シリーズA調達、採用拡大と繋がり、プロダクト開発への弾みがつきました。おそらく、一番最初の個別開発を受け付けなければ、同じ結果にはなっていなかった。もっと時間が遥かにかかっていたので、あの判断は今でも正しかったと思います。
狙い通り実績と導入のサイクルが回り始め、ここまでの成長を果たすことができました。SaaSでは個別企業の独自の機能開発を受け付けるのは「禁じ手」という考えにやはり原則は僕も賛成です。
ただ、どうしてもエンタープライズは「ロゴ」がものをいう世界でもあるため、初期フェーズにおいて、事業のフェーズを前に進めるためには必要な判断になることもあると思います。もちろんダウンサイドリスクの計算もお忘れなく！
「開発ロードマップの組み替え」を武器に、さらに実績を積み上げる
実績が出来上がると、商談も前に進むようになってきます。ただ、まだ製品が未熟なので、顧客の要望に応えられないケースが出てきます。例えば、「海外の従業員を対象にしたいが、多言語対応ができない」とかです。
そうすると、もちろん受注をいただくことは難しいのですが、商談時点で機能が揃っていなくてもその先の運用時点に間に合うのであれば、検討余地ありとしてもらい、進めて頂ける事があります。
エンタープライズの場合、導入プランが比較的長期で作られます。例えば、2月商談スタート、4月までに製品検証、5月に製品選定、9月まで仮運用、12月本格運用といったスケジュールが組まれるイメージです。上記例でいうと、4月製品検証～12月本格運用までの間、8か月間の製品成長が見込めます。
この8か月の間も開発ロードマップに沿って機能開発を進めるのですが、テックタッチでは、開発優先度を柔軟に組み替える（前倒しする）仕組みを運用して、機能不足における失注を防ぐことを重視してきました。これも、ターゲットとなる企業数が少ないエンプラ市場だからこそあり得る、独自性の高い意思決定だと思います。
※先ほどのIEの話とは違い、開発ロードマップに入っている開発案件のみが対象
※かなり未来的な機能は対象外としています。
この仕組みは、「ロードマップの組み替え」と「開発コミット」が発生するので、エンジニア側に負担が増えます。
ですので、以下のようなルールの元運用をしていました。
全体機能開発リソースの20%程度にとどめる（ただし時期は優先される）
開発が間に合わなかった場合、その間の売り上げをいただかないという免責を入れさせていただき、ソフトなコミット案件とする場合も多い
こちらの仕組みも、まだ製品が成熟していない時期（プレA期）で、商談のチャンスを確実にものにし、エンタープライズのお客さんを獲得していく有効な手段だと思います。
なぜコストをかけてでも、初期からエンプラ導入にこだわるのか
まずマーケット選定理由についてはこちらをご覧いただければと思いますが、当社の場合は、ターゲット市場を最初からエンタープライズに定めていました。
冒頭にもお話ししたように、プロダクト開発目線では、SaaS企業は、「実際にお金を払って使ってもらっているお客さんからのリアルな声」に対してこだわるべきだと考えています。
SaaS製品を立ち上げるとき、当然ですが、MVP（Minimum Viable Product）として最小限のプロダクトで臨みます。
MVPから始まるという事は、逆にいうと、その後はお客さんの声を参考に機能が実装されていくという事です。MVPはまさに、赤子のようなもので、どのような環境に身を置くかで、その後の製品が変わってきます。この声の主が、自分たちのターゲットでないと、違う方向に製品が開発されて行ってしまいます。
具体的にいうと、エンプラ向けのプロダクトを志向していたにもかかわらず、僕らがSMBの方に最初に展開していた場合、「コンテンツの権限管理」や「多言語対応」の要望は受けていないと思いますし、対応優先度の肌感もつかめないです。プロダクト単体だけでなく「数万人に対する展開手法」等のプロダクト外のノウハウも溜まってこないと思います。
FBループは「ただ単にユーザーの声を聞く」のではなく、「注力マーケットのユーザーの声を聞く」ことが必須要件だと考えています。
シリーズA以降（顧客数が増えた後）の動き
導入と実績のジレンマを乗り越えてからはプロダクトのフィードバックループを回せるようになります。
この領域もエンタープライズ特有の難しさが出てきます。
企業がソフトウェアを導入する場合、個人情報・機密情報の保護、法令遵守、事業継続性の観点から様々な要件が設定されており、導入時に要件が満たされているかチェックが入ります。
特にエンタープライズ企業の場合は要件が厳しく、金融業界など、多いところだと1000を超えるチェック項目への回答が求められます。
このセキュリティ要件によって、デプロイ・リリースが妨げられるものが出てきます。
継続的なリリースには積極的な投資を
企業のセキュリティ要件の中には、「自動的なアップデートを制御できる」ことを要求されるケースがあります。ソフトウェアの更新時の障害リスクをできるだけ排除する為の社内規定として、厳格に運用されている企業様もあります。導入のノックアウトファクターとなり、採用が見送られるケースもあります。
折角、頑張って顧客数を増やしリアルな声が聞こえてくるようになっても、デプロイ・リリースが順次できなければまさに片手落ちです。
プロダクトの性質によって、こういったデプロイオプションの形は変わりますが、この部分は製品のフィードバックループのスピードに直結します。競争力をつける必要があるスタートアップでは特に重要で、この問題に直面した場合、優先度高く対応することが必要だと考えます。
テックタッチは、ブラウザの拡張として機能を提供しているためChromeWebStoreのプラットフォームを通して配布しており、プラットフォームのポリシー上、一部の顧客にだけ更新を止めるという事が難しかったのですが、独自のバージョンコントロールの仕組みを構築し、顧客の要求に応えつつ、定期的に安心してリリースできる状態を維持しました。
※特許取得
複雑な仕組みになるのですが、作り上げてくれた、弊社エンジニアに本当に感謝です。
エンタープライズ向け製品で、リリースサイクルを維持するためには積極的な投資が必要になることもありますが、PMF（それ以降も）までの重要な機能と考え、実施しています。
その他にも、ノックアウトファクターとなりえる機能要件・非機能要件はあります。企業によって何を求められるかは違いますので、適宜対応していくことになるとは思いますが、機能要件であれば「EnterpriseReadyになるためのガイド」としてまとめられています。
EnterpriseReady - Build SaaS Features Enterprises Love
BtoB開発はチーム戦、なので効率よく、リズムよく
導入も進みＦＢをもらえる状態になり、安全なデプロイ・リリース基盤ができれば、あとは、いかにプロダクトの改善を丁寧に回す体制を作っていくかがポイントになってきます。
テックタッチのプロダクトは対象システムで動作させるという特殊性から、技術的なサポートが必要になる場面が多いのですが、都度エンジニアが対応するのは開発のリズムが崩れやすく、リリースに影響が出ることもあり、まずは専門のCustomer Success Engieerというチームを立ち上げました。これはサポートの質を上げることも目的としています。
詳しくは、こちらをご覧ください。
また、文中にもありますが、セキュリティ要件もかなり高い為、スタートアップとしては早いタイミングで専門性を持ったメンバーで構成されるSREチームも立ち上げました。スーパーエンプラの要求水準に応える、安定したインフラ運用とセキュリティ対策を実施してくれています。
詳しくは、こちらをご覧ください。
成果物に対しても高い品質水準を維持する必要があります。僕らの製品は動作環境が無数に存在する為、検証難易度が高いのですが、経験豊富で信頼できる一人目QAが奮闘し、今ではプロダクトチーム内で最も多くのメンバーを擁するチームとなり、検証工程を運用しています。
詳しくは、こちらをご覧ください。
このように、エンタープライズSaaSの場合、開発を取り巻く周辺の分業化が進み、各領域で専門性をもったチームの立ち上げ必要です。これらのチームの連携を高めるため、EM（Engineering Manager）が開発プロセス（スクラムマスター）、リリースプロセスの改善に日々と務めており、組織レベルのアウトプットの質と量を上げていってくれています。
※テックタッチのEMはエンジニアのマネージャーではなく、エンジニアリングのマネージャーという役割となっています。
このような体制が出来上がって、やっとプロダクトの改善を丁寧に回すことができるようになりました。
もちろんPdM、デザイナー、エンジニアの方の努力がコアにあることはお伝えさせていただきます。
まとめ
今回このnoteを書くにあたり、あらためて自分の思考や意思決定は、先人たちの残してもらっている記事（奮闘記やフレームワークの紹介）、周りにいる仲間たちのアイデアの上に成り立っているなと感じました。
「プロダクトの継続的な改善」というのがこの記事のテーマでしたので、プロダクトチーム周辺の出来事にフォーカスしてきましたが、ビジネスチーム、コーポレートチームも最高のパフォーマンスを出してくれて、ここまでやってこれたと思っています。
以下に記事をいくつかご紹介していますので、是非こちらもご覧ください。
改めまして、長文を最後までお読みいただき誠にありがとうございました！
ご紹介：当社チームの投稿もぜひご覧ください！
CEO井無田：シリーズB資金調達に寄せて：
前編：これまでのキーとなった意思決定を振り返る
後編：テックタッチの現在地と4つの新たな挑戦
CFO中出：
シリーズB資金調達の裏側： テックタッチはスタートアップ冬の時代になぜ20億円強を調達できたのか？
VPoCS垣畑：
前編：スーパーエンプラ向けSaaSのカスタマーサクセスのオペレーション、組織づくりで考えたこと
後編：これまでの歩み
この記事が気に入ったらサポートをしてみませんか？