シードラウンドで約 8 億円を調達したノーコードのデータ連携ツール Cascade はなぜ歩みを止めたのか
Cascade はデータアナリスト向けのデータ連携ツールで、スプレッドシートに様々なシステムのデータを張り付けて複雑な数式で統合するより GUI で簡単かつ再利用性の高いコンポーネントの構築を可能にします。 2019 年に創業で 2021 年にシードラウンドで 530 万ドル ( 2023/9/10 現在の換算レートで約 8 億円 ) を調達しつつも、 2023 に製品開発をストップしました。創業者によるその経緯と学びをホームページ上で見ることができます。
本記事は「成功するためのチェックリスト」という形式で内容をまとめました。失敗した理由をまとめても「じゃあどうする」が曖昧なためです。原著に関心がある方は、是非下記の記事を参照してみてください。
トップ画像は andrekarl さんの崖の写真を使わせて頂きました。
誰でも再現可能な営業の段取りが作れているか
"創業者は何でも売ることができる" とは原著の言で、業務についての詳しい知識があったりプロダクトに確信を持っていると力技で売ることができてしまいますが、プロダクトの問題点を覆い隠してしまう欠点があります。
「誰でも再現可能な営業」には、明確な効用とタイミングの必然性が必要です。例えば Zapier は Salesforce からデータを抽出するのが初期の明確なユースケースでしたし、 Notion はプロダクトマネージャーが初期の明確なペルソナで複数サービスを使い分ける面倒さの解消にフォーカスしていました ( What we learned about building a "no-code" toolkit ) 。 市場や技術の動向を注視し、投入すべきタイミングにプロダクトを投入する必要があります。
Cascade.io は機能が汎用的で顧客によって刺さる機能が異なり (=再現性が低い) 、またタイミングの必然性を明確に裏付けることができなかったことを学びとして挙げています。
個人的には、プロダクトの初期フェーズでは ( ニーズが完全に適合しなくても売れるという意味で ) 営業力が強い人材がいると良くないかもしれないと感じました。その意味で、エンジニア自身が営業する (=営業経験やドメイン知識で力押しできない ) 方が当たっているか否かの判断は明確になるかもしれません。
顧客のロールとプロダクト機能にずれがないか
データアナリストは BI ツールを扱い、エンジニアが ETL ツールを扱います。Cascade.io はデータアナリストに向けて ETL のツールを売っていました ( What we learned about the data and analytics market ) 。データアナリストが中心のプロダクト開発チームであれば Cascade.io はうまく機能したかもしれませんが、プロダクト開発チームが望む ETL ツールとしての機能は必ずしもデータアナリストが要求するものと重複しません。Amplitude はデータアナリスト単独ではなくプロダクト開発チームにフォーカスしソリューションを提供することでこの問題を解決しています。職掌を超えた機能を提供してよい反応がもらえたとしても、本職の人間がいれば使われることはありません。
個人的に、ペルソナが「望むもの」と「行うこと」の間にギャップがある点は注意が必要と感じました。例えばプロトタイピングツールにコードを生成する機能があるとして、プロトタイピングツールを使うのはプロダクトマネージャーや UX デザイナーですが実装するのはエンジニアです。エンジニアが受け取れないようなコードを生成してくるツールは受け入れられないとの近しい気がしました。
プロダクト切り替えコストの負担者は明確か
新しいプロダクトは大体の場合において導入済みのプロダクトを切り替える必要があります。切り替えコストはプロダクトの対象ユーザーだけが支払うわけではありません。例えばデータ連携ツールの場合、連携機能を開発するエンジニアはもちろんジョブのステータスを監視する運用担当者や費用支払いを管理する IT 部門も含まれます。既存プロダクトはエンドユーザーだけでなくプロダクトのステークホルダーにも運用監視画面やユーザー管理画面といった機能を提供しており、リプレースを目指す場合同等機能の開発が不可欠になります。横断的なツールであるほどリプレースが難しいと言え、データ関係のツールはまさにその典型的な例と言えると思います。
おわりに
データ関連のツールはデータ基盤側と BI ツール側がそれぞれお互いのテリトリーを拡げようと鍔迫り合いしている状況ではないかと感じます。大規模データの効率的な処理では前者に分があり、ユーザーに使いやすい GUI では後者に分があります。その間に割って入るのは、それぞれの市場のメジャープレイヤーと競合することになるため非常に難しのだろうな、という感覚を持ちました。
個人的な感覚では、データウェアハウスを作るまでのプロジェクトとダッシュボードを作るプロジェクトは分断している、連動しているプロジェクトがあっても特定部門の細いユースケースで後から全社施策で消えそうなことが多い印象です。ガートナーが「2015 年までに Fortune 500企業の85％以上が、ビッグデータの活用に失敗するだろう」と話したのは 2012 年ですが、その後様々なテクノロジーの進化にも関わらず 2015 年に留まらず今でも失敗し続けている印象です。その意味で、データ活用プロジェクトの成否は技術的革新性とあまり相関がないのかもしれません。「全社的なデータ基盤としてのデータウェアハウス」は幻想で、Amplitude のように個別プロダクトごとにプロダクト改善を回すことのできる必要十分なデータを取るのが最適解なのではという気もします。
AWS ではプロダクトで機械学習を活用するためのワークショップ資料を無料で公開しています。事例に掲載しているものを含めこれまでに 6 社 16 チームへの提供実績がありますが、ワークショップ終了後から「機械学習やりましょう」となるケースよりもデータでユースケースの確実性について裏取りをしましょう、となることが多いです。
企業の中でデータはどのように保存され活用されるべきなのか、 ワークショップを牽引する AWS の機械学習領域の Developer Relations として引き続き考えていきたい所存です。ワークショップの資料だけでなく世界的なプロダクトでのデータ活用事例もまとめているので、ぜひ ★ を頂ければ嬉しいです！
この記事が気に入ったらサポートをしてみませんか？