創業1年半で約7億円、累計9億円のシリーズA資金調達をする段階までノーコードツールを組み合わせてプロダクトとオペレーションを磨いてきたスタートアップがあります。Coral Capitalが出資するリモートワーク支援プラットフォーム「リモートHQ」を提供するHQです。
HQは2021年3月の創業で、約1年後の2022年4月に初の外部資金として約2億円を調達しています。その後、リモートワークやハイブリッドワークの広がりを背景に、大手企業を含む導入事例と売上をぐんぐんと伸ばし、シード調達からわずか6カ月半後の2022年11月に約7億円をシリーズAラウンドで調達するほどに急成長を遂げました。
HQでノーコードを書いてきたプロダクト・マネージャーの原田光太朗さんと、そのノーコードで書かれたプロダクトを、GolangとTypeScript（React）にビッグバン移行させた同CTOの髙橋侑久さんに、実際の体験と振り返りの考察を伺いました。これから創業期にノーコードを使おうと考えている起業家の皆さんには参考になることが多いと思います（聞き手・Coral Capitalパートナー兼編集長 西村賢）
――HQ創業者でCEOの坂本祥二さんの「PMFまでの引き算の経営」と題したブログに詳しいですが、初期スタートアップで大切なのはPMFだけ、そのPMFに集中するためには、やることを徹底して絞ることが大事だというお話でした。その意味でPMFするまでノーコードでやってみる、というのは有効ということですよね。
髙橋（CTO） はい、使われないものを頑張って作ることほど無駄なことはないですからね。使われるかどうか分からないのがシード期のプロダクトなので、そのときやるべきことは、種に水かけて大きな花を咲かせるかどうかを知ること。
アイデアの検証ができるのであればノーコードツールを使う必要すらないかもしれませんよね。紙芝居とかインタビューとか、人力とかでオペレーションを頑張るとか、いろいろな方法があります。その中の1つとして、アナログな世界の次の一歩としてノーコードがあると思います。本格的プログラミング言語によるプロダクト作りに取り組む前に、アナログな手法を使うわけですが、この2つの中間地点があるのがノーコードということです。
私がHQにジョインしたのは2021年11月で、ノーコードからの移行が開始する前だったのですが、中に入ってみてソフトウェアエンジニアとして分かったのは、思っていた以上にノーコードで、いろんなことができることですね。
HQ CTOの髙橋侑久さん。Qiita ( 当時 Increments ) に最初の従業員として⼊社。CTOとして、エンジニア向け情報共有サービス「Qiita」の開発を担う。京都⼤学⼤学院情報学研究科修士修了
メインのアプリもバックエンドもBubbleで実装
――髙橋さんがCTOとしてHQにジョインする以前には、プロダクト・マネージャーとして原田さんがノーコードでゴリゴリと作っていたのですよね？ 全てをノーコードだけで作っていたのですか？
原田（PdM） メインのユーザーが使うアプリも、バックエンドもBubbleで書いていました。一部、他社の在庫情報を接続する部分はAWS上のスクリプトで書いていたくらいです。他にも、サービス利用開始時に各ユーザーの自宅環境や要望を尋ねるフォームがあるのですが、そこはTypeformも使っていました。
――Typeformはビジネスサイドが使うSaaSというイメージですが、プロダクトの一部に使っていたと。
ええ、それでTypeformに入ってきた情報はAPI接続のSaaSであるZappierでBubbleのデータベースに書き込むという流れにしていました。
HQプロダクト・マネージャーの原田光太さん。アクセンチュアでコンサルタント経験後、OYO、フライウィールなどでプロダクトマネージャーを務める。2021年5月にHQにジョイン。大阪大学法学部卒
――どのくらいのことをBubbleで実装していたのですか？
原田 この画面がBubbleで実装した機能の一覧のダッシュボードです。例えばユーザーからの注文が完了したら、在庫を1つ減らして住所や配送情報を入れて注文データを作り、もしエラーがあればメールが飛ぶ、というような処理を1つずつ書いていました。
――かなりの数ありますね……。ダイヤログに表示されているのが処理の中身を書いている部分でしょうか。これだけの量を書くのはけっこう大変だったのではないですか？
原田 いえ、書くのは難しくないですね。でも読むのは大変ですね（笑）
――ノーコードの良さと限界が分かる発言ですね。ガンガン書いて動くものは作れるけど、読むのが大変ということは、機能の追加や変更、チームで作るのには向いていないという。
原田 ノーコードのBubbleが良いのは、他のサービスの連携も簡単なことです。他のクラウドやSaaSがAPIで接続されているんですね。Bubble向けに提供しているサービスもあります。そうしたものはボタンをポチポチやるだけで使えたりするんですね。API workflowとかTriggerなどで数十種類あります。
――「データベースのここが更新されたら」という条件を設定するのがTriggerですよね。入力された郵便番号から住所の文字列に変換するAPIなんかもボタン一発。この辺は普通のプログラミング言語だとライブラリになってるところですね。
髙橋 Bubbleのダッシュボードにサードパーティーのプラグインがいろいろあって、「あ、世の中にはこんなサービスがあるんだ」と知ったりすることもあります。プログラミング言語でやるよりも、ボタン一発なのでAPIマッシュアップも簡単に試せて、自分が思っていなかった使い方もできるのはノーコードの良さですね。
原田 Bubbleでシングルサインオンの機能提供してる企業があるなど、このエコシステムで食ってる人たちがいるという世界になっていますね。
――すごい。
Bubbleのプラグイン選択画面。有償のものもあり、アプリ・ストアのようになっている
ノーコードからGoへの切り替えは段階的にやらず、一気に
――そのノーコードの実装からGoへの切り替えは、あるとき一気に切り替えたのですか？ 段階的にですか？
髙橋 一気に切り替えました。段階的な移行も考えはしたんですけどね。例えば、一部のクライアント系の部分から移行するといった形です。
でも、システムが2つあるとオペレーションも二重になるので、例えば誤配送のミスが起こり得るな、と。それで2022年8月15日を「Xデー」として、その翌日の16日からは新システムで実運用に切り替えました。
ユーザーが使わない内部向けの画面など、一部にはノーコードも残っていますが、基本的には一気に移行した形です。
原田 逆に、アナリティクス関連の数字を見て、使われていない機能を見て、そっと落としたりしました。PMF後のシステムリプレースは、ユーザーの価値ベースで判断できる良いきっかけになりました。
――切り替えはスムーズでしたか？ トラブルは？
髙橋 移行直後には、いろいろ起こるだろうと考えていて、全面的に元のシステムに巻き戻すロールバックもあり得るかと思って準備をしていました。ただ、幸いなことに大きな問題はなかったですね。慌てて直さないといけないところがなかったとは言いませんが。
――どのへんが想定外でしたか？
髙橋 これはBubbleのツラいところですが、データベースに、どういうデータが入るか、どういうデータだと形式的にNGかを判定する、いわゆるバリデーション機能が弱いんですね。例えば、Bubbleだと特定カラムに同じデータが存在してはいけないという「ユニーク制約」。そのロジックを自分たちで書くことはできるんですが、データベースレベルでは機能として提供されていないんです。
――RDBの基本機能ですが、ノーコード・プラットフォームとしては、それを入れることによる学習コストの上昇よりシンプルさを取ったんでしょうかね。でも、ユニーク制約がないと不安ですよね。
髙橋 実際、ユニーク制約がBubbleで保証できないのでアプリレベルで実装することになるんですね。そうすると、すり抜けてくるものがある。例えばメアドの重複があったりするんです。BubbleからRDBへデータを変換したんですが、対象データに想定外のものがあったのが、実際に動かしてみて分かったというのはありますね。
アプリの挙動については原田さんが詳細を把握してたのですが、データについてはエッジケース（例外的だが起こり得る条件）まで全部わかってなかったということですね。Xデー前に旧システムのデータをダンプして、新システムにロードして穴を潰して行ってはいたんですけどね。
ノーコードの方が開発が速すぎる…？
――シリーズA調達のときに弊社Coral Capitalとしてもシステム移行に懸念はないのか、事前ヒアリングさせていただきました。そのときに「ノーコード側の開発速度が速すぎて、リアルなプログラミング言語の開発が追いつかない」ということをおっしゃってましたよね。だから、ある瞬間で切り替えようにも、常に捨てるべきノーコードのシステムが一歩先に進化してしまっていて、追いつかないという……。もちろんトレードオフなのでノーコードで走り続ける選択肢はなかったわけでしょうけど、この辺り詳しく教えていただけますか？
原田 Bubbleの開発がGo＋TypeScriptの開発に比べて速すぎるというのはありました。実際の移行のXデーは8月になりましたが、実は当初2月には移行が終わると思っていたんですね。でも、1月に追加機能を作ってしまって、リプレースが遅れたというのはありました。
1月の時点でビジネス的に必要な機能があって、それをBubbleでさっと作ってしまったんですね。その追加機能のせいでノーコードからのリプレースが遅れるとしても、ビジネス上実装すべきだったので、選択としては間違っていなかったと思っています。
もう1つ別の理由として工数の見積もりでも想定外がありました。例えば、Bubbleには内蔵エディターがあって、それをユーザー向けの機能として使っていたんですね。ユーザーは、そのエディター画面からCSV形式で商品情報をアップロードできるようになっています。ところが、その内蔵エディターが果たしていた機能も、自分たちで実装する必要がありました。1つ1つの機能は複雑ではないのですが、こうしたものが少しずつ見積もりから漏れていてボディーブローのように工数が増えたんです。
内部的にリプレースの期日ついて目標は立てていましたが、後ろに押しました。最初は2月だったのが、4月、5月……、8月とずれた。思ったより時間がかかりました。
――文字通りのムービング・ターゲット感がありますね。
原田 ノーコードだと開発が速いということの裏には、そもそもリプレースされる前提で、割り切った実装ができるからということもあります。機能要件を考えるのも簡単で、来月や再来月にはもう使わないコードだと分かっていれば、「多少のエッジケースは運用でカバーすれば良い」という意思決定ができるんですね。だから、なおさら速い。
――開発が速いとはいえ、限界がやってくることもわかっている。なかなかジレンマですよね。
原田 ちょうどシリーズAのタイミングで、在宅勤務時のネット、電気代を非課税で会社負担できる新機能をリリースしています。ユーザー企業から要望の多かったものですが、こういう機能は「硬い」プログラミング言語でないと怖くて実装できませんよね。
――ノーコードでFintechは無理ですね（笑） ちなみに坂本CEOとのコミュニケーションはいかがでしたか？ スケジュールがずれ込むことで懸念されたり、説明が必要になったり？
原田 スケジュールとかスコープの調整はありましたが、ただスケジュールを遅延することはなく、未来の柔軟性担保や、眼の前のお客様を優先しノーコードで機能拡張するなどのトレードオフをCEOと常にコミュニケーションをとっていたので、遅れていたとしても、何か変なことが起こってるというふうに捉えられることはなかったですね。
シード期の創業メンバーへアドバイス
――これからスタートアップを創業するチームに対して、アドバイスはありますか？ ノーコードの使いどころのスイート・スポットや移行タイミングなど。
髙橋 Bubbleでは、どうあがいてもGitHubは作れません。Ruby on Railsを使えばGitHubは作れますよね。だから、健全なタイミングでノーコードからリアルなコードに移行しないといけません。がんばって延命しすぎるとリプレースが困難になります。
原田 ノーコードといっても、いろいいろあります。AirtableとかZappierとか。あるいはExcelやGoogle Sheetsのようなスプシもノーコードといっていいかもしれませんよね。でも、髙橋が言う通りノーコードだけで組み合わせるのは限界があると思っています。
例えば、スプシは怖いですよね。行数が増えたり、触る人数が増えると、どんなデータが入ってくるか分からない。そもそものカラムも、ユーザーが勝手に増やしたりできてしまうので、データの整合性を保てなくて限界が来ます。スプシは自由度が高すぎるんですね。だから、スプシだと怖いなとなったら、Bubbleに移行するのが良いのではないでしょうか。
スプシで8割できるものをエンジニアにコードで書いてもらうかというと、それもタイミングとしては速すぎる。そのときにBubbleが強力な手段になると思っています。CSVをデータベースに入れて、バリデートしてメール通知を飛ばすというくらいなら簡単にできて、エンジニアを雇ったり開発チームにお願いするほどではないですから。
――ノーコードの実装を、リアルな言語でリプレースするときのアドバイスはありますか？
髙橋 振り返ってみると、もっとこうしていれば良かったということとして、ちゃんとBubbleを勉強すれば良かったなと思います。
結局、Bubbleのことを最後の最後まで深く学ばなかったんですね。そのせいで、実装としてロジックがあるのに最後まで雰囲気でしか読めなかったんです。
理由は2つあって、1つは、もっと早くリプレースが終わると思っていたこと。もう1つは、そこまで複雑なことをやっていないと思っていて、もし分からないところがあっても、原田さんに聞けばいいやと思っていたからなんですね。
そこで不必要なコミュニケーションが発生したのかなと思います。HQで僕がCTOとしてやったのと同じように、すでにPdMがいて、ノーコード実装があって、それを移行するという場合、そのノーコードツールの勉強を割く時間というのは、投資する価値がある時間だということです。ノーコードは難しいわけではないわけですし。
Bubbleの実装を雰囲気で読んでいたので、私は細かいところを原田さんにSlackで聞くことになったんですね。応答が速かったので良かったんですけど、自分で探索できるようになっていたほうが良かったなと思います。
――ノーコードとはいえ、動いているコードが挙動を最も正確に記述した仕様ですもんね。
髙橋 そう、記憶や仕様が変わっていたりもするので、動くドキュメントを直接あたれるようになったほうがいいです。
――非エンジニアの創業者がノーコードでMVPを実装する例が、最近Coral Capitalでお会いする起業家にも増えています。何かアドバイスはありますか？
原田 何を作るか考える人と作る人の距離が遠くなると検証が遅くなるので、CEOがノーコードで作るのが最強だと思います。
それに、ノーコードで何かを作るとプロダクト開発の理解が進むんじゃないかと思います。全く未経験だとハードルは低くはないとは思いますが、ある程度プロダクトを作る会社でCEOをやるのであれば、ミニマムなものが作れるスキルがあるのは絶対に損はないと思います。
Partner @ Coral Capital
