.jpg)
始まりはいつもハッカソンから
昨年12月の社内ハッカソンで、私はますます時間を奪うようになっていた問題に取り組むことにしました。それは、複数のアプリケーションをまたいでデータを探し回る作業です。基本的な分析の問いに答えるためだけに、実験プラットフォーム、アプリケーションログ、CRMなどのシステムを行き来することが頻繁にありました。さらに厄介なのは、どのアプリケーションのUIも平均的なユーザーには使いやすい一方で、私の具体的なユースケースには合わないことが多かった点です。
私の目標は、こうしたバラバラのプラットフォームから安全なAPI経由でデータを取り込み、自分のワークフローに本当に役立つ形で表示するアプリをLovableで作ることでした。
まずは、データをシンプルに表示する画面から作り始めました。既存のSaaSツールではサポートされていない機能がいくつか欲しかったので、ダッシュボードツールにずっと求めていた機能を自分で作ってしまおうと考えたのです。エージェントは、ほんの数回のプロンプトでコア機能を作り上げました。APIの構造を理解し、必要な情報をまさにそのとおりに表示する、すっきりとしたインターフェースを生成してくれました。
この最初の成功の後、私はLovableを限界まで試してやろうと意気込みましたが、ほとんどの場合、Lovableは問題なく動き続けました。A/Bテスト、セマンティックデータレイヤー、メトリクスダッシュボード、ファネル、データカタログまで、数回のプロンプトで実装できたのです。こうして生まれたのが、私が「Lovsight」と呼び始めたツールのMVPです。ユーザーは1つのアプリケーションから離れることなく、指標を照会し、実験を調べ、Lovableのパフォーマンスを把握できるようになりました。私はこれを、特に大々的に告知することもなく社内のベータテスターに公開しました。
MVPからプラットフォームへ
そこからは、予想以上の速さで物事が進みました。数週間のうちに、社員の約半数がLovsightを日常的に使うようになったのです。プロダクトマネージャーは新機能のリフト分析を行い、営業チームは利用データをもとに商談規模を見積もり、セキュリティアナリストは不正検知に活用し始め、カスタマーサポートはエンジニアリングにチケットを起票しなくても、ユーザーの詳しいコンテキストを引き出して問題をデバッグできるようになりました。自分の時間を節約するために作ったツールが、会社の重要なインフラになりつつあったのです。また、Lovsightはロールに応じて動作するため、カスタマーサクセスのユーザーは業務に関係する顧客データを表示できる一方、人事チームのメンバーには、その立場に適した情報だけが表示されます。さまざまな部門に利用が広がるなかで、ロールベースのアクセス制御を整えていたことで、機密データが適切な人の範囲内にとどまるようになっていました。
そして利用が広がるにつれ、お決まりの事態もやってきました。フィードバック、機能リクエスト、そしてシステムへの負荷です。上司はLovsightの可能性を認め、さらに力を注ぐよう後押ししてくれました。Lovsightに割く時間は、おそらく20%ほどから40%近くにまで増えました。かなりの割合ですが、計算は合っていました。会社のインテリジェンスへのアクセスを効果的にスケールできるプラットフォームを作れれば、どれだけ多くのカスタムダッシュボードを作るよりも大きな見返りがあるからです。
Lovsightは、わずか数週間でハッカソンのプロトタイプからLovable社員のおよそ90%が使うツールへと成長し、コードを1行も書くことなくMVPから重要なインフラへと進化しました。付け加えておくと、私は社員として高度な機能を利用できる立場にありましたが、これらはすべて標準のLovable、つまりユーザーの皆さんが使えるのと同じ機能だけで実現しています。この頃には、データウェアハウスへのクエリの半数以上がLovsightから発行されるようになっていました。
あらゆる場所で使える、完全にエージェント型のLovsight
この時点で、Lovsightはユーザーが関心を持つ多くの事柄について、整理されたタイムリーなレポートを提供していました。しかし、まだ閉じたシステムのままでした。たとえば誰かがセッション時間を分析したいと思ったら、私にセッション時間のモジュールを作るよう依頼し、私がLovableにプロンプトを送ってデータを取得し、ウィジェットやダッシュボードを作る、という流れです。これでも機能はしましたが、最初に抱えていたスケーリングの問題が、一段上に移っただけでした。私が一度に作れる新しいモジュールの数には限りがあります。
本当のブレイクスルーは、データアプリをさらに増やすことではありませんでした。データアプリを作るエージェントを提供することだったのです。私はすでに、BigQuery、Confidence、RudderStack、Posthogなどとの基盤となるデータ連携を、すべてLovable上で構築していました。ユーザーが普段の言葉で話しかけられる専用のLovsightエージェントがあれば、必要なことを説明するだけで、エージェントがアクセスできるデータをもとに推論し、同僚たちが新しい問いを思いつくのと同じ速さで、レポートやダッシュボード、インサイトを生成してくれます。
メインのインターフェースが対話型になったことで、Slackへの展開は自然な次のステップでした。ユーザーは、普段から使っているツールを離れることなくLovsightエージェントに質問できるようになりました。
誰かがLovsightのメモリに、私を「ボス」と呼ぶよう追加したようです。ええ、そうなんです….
学んだこと
Lovsightは今やLovable社内のいたるところで使われており、豊富な業務データを継続的に分析し、アプリやSlackで質問に答え、社内のさまざまなチームが頼りにしている定期レポートを届けています。これを構築し、スケールさせていく過程で、ここで働くことが実際にどういうことなのか、いくつかのことを学びました。
- 1つ目に、本来なら2人のデータチームで150人を十分に支えることはできないはずです。従来であれば、人員を増やし、6か月かけて採用活動を行うのが答えだったでしょう。しかしLovableでは、まず自分で作るという発想が当たり前で、ツールがその発想を現実的なものにしてくれます。そもそもLovsightが生まれたのも、そのためです。
- 2つ目に、そうしたビルダーとしての発想は、問題の解決方法について本当の意味での裁量があってこそ活きるということです。誰かが仕様書を渡してくれたわけでも、どのダッシュボードを作るべきか指示されたわけでもありません。私は課題に気づき、APIを通じて自分が管理できる場所にデータを取り込み、チームが本当に必要としているものに合わせて形にしていきました。大きなオーナーシップが、大きなインパクトにつながります。
- 3つ目に、壮大な計画はまったく必要なかったということです。Lovsightは、ハッカソンで作った1つの実験ビューから始まりました。現在の機能はすべて、実際の利用と実際のフィードバックから生まれたものです。この会社のカルチャーは十分にスピーディーなので、小さなものをリリースし、そこから学び、許可や四半期ごとのロードマップを待たずに広げていくことができます。
最後に、AIツールで何ができるかについて、先入観をいったん脇に置いてみることをおすすめします。このプロセスの中で何度も、プロダクトは私の期待を上回り、専任のエンジニアリングチームなしで作れるものについての考え方を変えてくれました。
今後について
LovableやLovsightのようなツールにできることは、まだ始まったばかりです。私は毎日Lovsightを改善していくことにワクワクしていますが、それ以上に、小さなチームがAIを活用して実力以上の成果を出せるようになるという、より大きな変化に期待しています。こうした仕事に興味をお持ちでしたら、ぜひデータサイエンティストのポジションにご応募いただくか、その他の募集中のポジションをご覧ください。
