SaaSなのにほぼノーコードで2億円調達した話
はじめまして！
リモートHQのプロダクト開発を担当しているkotaroです。
今回は昨日発表されたCoral Capitalさん等からの資金調達におけるプロダクト開発の裏側を書こうと思います。特にソフトウェア領域での新規サービス立ち上げや起業を検討している方に参考になれば何よりです。
本文の前提について
さて、本題に入る前に今回の調達リリース記事にまつわる事実を列挙します。
リリースの内容はこちら
2021年3月: 株式会社HQ創業
2021年5月: kotaroがプロダクトマネージャーとしてジョイン(当時ソフトウェアエンジニアは0人)
2021年9月: トライアルでサービス提供開始
2021年11月: 正式ローンチ
2021年12月: 利用ユーザー200名突破
2022年3月: 利用ユーザーが5倍(1000名)に成長
2022年3月: Coral Capital等からプレシリーズAで約2億円を調達
まだまだ(x100)なのは大前提として、創業1年経過のスタートアップとして悪くない立ち上がりではないかと思っております。もちろん、もっとすごい速度で立ち上がっているビジネスや調達額の大きい会社さんもたくさんあります。
一方、リモートHQのプロダクト開発において、ソフトウェアサービス開発を本業としている他の会社さんと異なるユニークな点があります。
それは、SaaSなのにほぼコードを書かずに初期ユーザーの獲得を実現し、約2億円を調達したということです
ソフトウェアつくってないの？ もちろん作っています(ただしノーコードで)。
エンジニアいないの？ います(現在はフルタイム3人業務委託3人)。
今回は、どのようにコードを書かずにソフトウェアサービスを実際に提供し、初期ユーザーにご満足いただき、資金調達を実現したかの裏側をお話できればと思います。
ノーコード開発の裏側
複数のノーコードツールをフル活用しました
もう少し詳しく書くと、ノーコードでウェブアプリケーションを実装し、複数のSaaSと連携することで、想定するユーザーストーリーを満たすMVPを構築しました。そして商談でデモを行いながら高速に実験を繰り返し、初期ユーザーにそのままご利用いただき、フィードバックをもとに機能追加を行い、そのまま実際のユーザーにそのアプリケーションをご利用いただいています。
なぜ今回の開発スタイルを選択したかは後述しますが、開発力不足だからではなく、最短最速のPMF検証の手段としてノーコードを選んでいます。
使ったサービスは、Bubble、Integromat、TypeFormなどなど色々ありますが、戦略の中核であるBubbleについて簡単に説明します。
Bubbleは色々デキる
Bubbleとは、ウェブサービス開発をノーコードで開発できるサービスです。
複雑なUIや機械学習ロジックを自前で作るようなことがなければ、ウェブアプリケーションならだいたい何でも作れます。個人的には初期のサービス開発であれば、Bubbleで十分なことも多いのではと思っています(未来の拡張性は置いといて)
標準でできることも充実していますが、他SaaSとの連携による応用もかなり自由度が高く、
SSOログイン
質問フォーム(TypeForm)の回答をトリガーにデータベースに回答結果を詰め込むワークフローをIntegromatで構築し、回答結果内容に併せてサイト上の案内を分岐させる機能
検索・レコメンド機能(AlgoliaというSaaSと連携)
みたいなことが割と簡単に出来ます。
あと、Bubbleを語る記事であまり言及されませんが、ワンタップでデプロイ・リバート(デプロイの巻き戻し)が可能なのは初期フェーズの検証では地味にありがたいです。
ここまでノーコードで開発したこととBubbleの簡単な説明をしましたが、ここからなぜノーコード実装を選択したのかを説明します。
一言でいうと
ノーコード開発は初期PMF検証と相性が良い
と思っています。
そして最初にまずお伝えしたいのは、ノーコードでの実装を選択したのはコードを書く労力を省けるから、ではありません。
初期のPMF達成を目指すフェーズならではのツラミを解決する手段として、ノーコードによる開発を選択しました。
(補足)初期PMF達成とは、最初の数社(数人)に熱狂されている状態、というざっくりの意味で使用しています
ぼくが考える初期PMF達成を目指すフェーズの理想的な開発体制の要素として以下のものがあると思っています。
初期PMF達成に向けた開発の理想要素(個人的意見)
要素1: 課題とシステムの一致
多くのスタートアップは新しい課題を解決します。そのソリューションも当然何かしら新しいため、情報がハイコンテキストになりがちです。更に商談で多くのフィードバック(ダメ出し)を受けることで日々情報が更新されます。
結果、顧客ドメインの知識差や開発経験の差により創業CEOとソフトウェアエンジニア間のコミュニケーションが少しずつズレることにより、課題とシステムがずれてしまうということは少なくないと思います。
そんなハイコンテキストな情報が錯綜する中で顧客課題とシステム(ソリューション)を一致させ続けることが重要になります。
少し違う論点ですが、AutifyがなぜRuby on Railsで開発したか、フロントエンドとバックエンドを分けたときに何が起こったかはとても示唆深いです。Podcastはこちら
要素2: 最小リソース
多くを語る必要はありません。PMF前はバーンレートをなるべく下げて、たくさん実験できたほうが良いです。
要素3: 高速リリース体制
今日わかった課題をすぐに修正すれば、明日の商談ですぐに検証ができます。できる限り判明した課題を潰したうえで次の検証を行うことで、検証の質が大きく変わります。
10Xのyamottyさんのブログでも、タベリー開発初期にDailyでユーザーに触ってもらう→改善案検討→実装を高速に実施した日々が綴られております。yamottyさんのblogはこちら
要素4: 短期に振り切るマインド
これは賛否ありそうですが、誰からも必要とされない可能性があるシステムの2～3年後を過度に心配する必要は無いと個人的に思っています。初期フェーズは、とにかく負債を不必要に恐れず、目の前の初期ユーザーの熱狂にフォーカスすることのほうが優先度は高いし、負債を恐れて検証の質を下げるのは本末転倒と思っています。
これら4つの要素は、特に目新しさはないと思いますが、実現が難しいのがポイントです。
例えば、こんな状態が大なり小なりあるのではと思っています。
創業者と実装者のバックグラウンドが違いすぎて、日々の会話の前提が揃わず意思疎通に苦労する。結果、実験の試行回数が減る・質が下がってしまう
コミュニケーションがずれていたことに機能リリース後に気づいた。修正してほしいが、モチベーション下がらないだろうかという迷いが生まれる
負債を気にするなとは言っても負債を気にせざるを得ないのが、ソフトウェアエンジニアの性
実際にユーザーが使い始めたら、バグの混入を恐れて、CI/CDを整備しないとリリースを気軽にできなくなる
ノーコード実装によって、↑のツラミを軽減
要素1: 課題とシステムの一致 x ノーコード
ノーコードを駆使することで開発をほぼ僕一人に集約することが出来ました。
さらに、ほぼすべての商談に参加し、コンテキストをCEOの坂本と揃えたうえでユーザーストーリー定義・デザイン(ただし50点レベル)・実装(ただしノーコード)を一人がこなすことで、コミュニケーションコストを最小化することができました。
これにより、課題とシステムがズレるミスコミュニケーションはほぼ起きませんでした。
また、自分が作ったものを壊すことと仲間が作ったものを壊すことの心理的ハードルが全く違うので、スクラップアンドビルドがしやすいのも検証の効率化に効いたと思います。
要素2: 最小リソース x ノーコード
ノーコードツールによりほぼ一人で開発できたので、最小と言えるでしょう。
要素3: 高速リリース体制 x ノーコード
上述したとおり、Bubbleの標準機能でリリースもリバートもボタン一つです。先日数えてみると、半年で150回程度リリースしていましたので、土日除いてほぼ毎日リリースできていたことになります。
要素4: 短期に振り切る x ノーコード
ノーコードで作ったアプリケーションはテストコードも書けないし、そもそも長期運用は無理です。なので負債を1mmも恐れず、割り切って実装できました。本来、抽象化すべき部分も簡単なUI側でのフラグ制御で済ましたり、ソフトウェアエンジニアとしては良くない実装も大胆にやりました。10月に一人目のソフトウェアエンジニアが入社した後は一層、負債ナニソレ状態で短期を優先しました。
加えると、今のノーコード実装のアプリケーションに対するユーザーの反応を見ながら、開発チームは新しいシステムを1から設計しているため、相当解像度が高い状態で日々実装できています。
もちろん、全ての組織やサービス領域にノーコード開発がハマるわけではないですが、リモートHQ開発においてノーコード戦略は相当機能したし、今の状態にかなり貢献したと思います。ノーコードツールがどんどん増えていく中で、ノーコード中心で初期PMFを目指す戦略がハマる組織は結構あるだろうし、今後も増えていくと思っています。
最後に
これまで説明したノーコードで構築したアプリケーションですが、間もなく天寿を全うし、絶賛開発中の新システムに置き換わります。
というのも、福利厚生の領域は奥深いです。ノーコードではカバー出来ないユーザーストーリーが大量にあります。
多様な職種やバックグラウンドの全従業員に対して、平等性を損なわず、白けさせず、施策を遂行するというミリ単位の配慮が求められるのが福利厚生の領域です。多くの従業員に対してではなく、全従業員に対してです。
ゆえに、今の仕組みが機能してなくとも、やりたい施策があっても、踏み出せない組織も多くあります。特に大きな組織ほどそのような傾向があります。
そんな難しい前提の中、リモートワークでもオフィスと同等かそれ以上の生産性を保ちつつ、それぞれのプライベートな生活も充実してほしいと願うクライアント様の支援をリモートHQを通じて行うことは本当に心から意義を感じます。
そして、個人と組織の間にはソフトウェアを活用することでもっと個人と組織が輝く余地のある領域はまだまだたくさんあります。
もし、そのような領域にご興味のある方がいればMeetyのリンクを貼っておくので、ぜひお話できればと思います。
以上、お読みいただき、ありがとうございます。
この記事が気に入ったらサポートをしてみませんか？