Railwayが登録ユーザーの利用履歴から営業対象を選別した方法

はじめに

最近、サイドプロジェクトで金融商品分析サイトを制作するにあたり、クラウドデプロイプラットフォームのRailwayを初めて利用してみました。それまではVercelとSupabaseで十分だと考えていましたし、エラー追跡ツールのSentryも本当に必要なのか悩んでいたところでした。コスト面からRailwayを試してみたところ、技術面だけでなく顧客を獲得しサポートする手法に関しても参考にすべき点が数多くありました。折しも、Railwayが2026年5月6日に公開した『Kill your onboarding』という記事を目にしました。新規登録者に画一的な営業メールを送るのを改めた経験を綴った記事です。

当時、Railwayには1日1万件以上の新規登録があり、2026年4月以前の累計登録者数は約290万人に達していたといいます。**営業チームが求める顧客条件であるICP¹に合致するアカウントを約2万1000件特定していたものの、実際にアプローチできていた割合は1%未満にとどまっていました。**企業に所属するユーザーであっても、個人プロジェクトを進めているのか、チームの実環境を構築しているのかによって必要な支援は異なるにもかかわらず、一律の案内メールを送り続けていたのです。この記事は売上不振の原因を追究したり、売上の改善を実証したりした報告書ではなく、営業対象を見つけ出してアプローチする手法を見直した初期の事例です。

利用履歴を営業チームが活用できるようにする

製品の利用体験を通じて顧客を獲得するPLG²においては、登録手続きを簡素化することが極めて重要です。ただし、会社名やチームの規模を尋ねない場合、営業チームは別のデータから利用目的を把握しなければなりません。

私のように個人プロジェクトを作る人もいれば、会社の業務で使うチームもあるはずです。RailwayではGitHubアカウントやメールアドレスで登録すればすぐにデプロイできるようにし、企業名やエンジニア数を尋ねるアンケートは意図的に設けなかったといいます。まずは製品を使ってもらうことを優先し、エンタープライズ顧客を発掘するプロセスは別途用意する必要がありました。

当時の営業チームは、AE（アカウントエグゼクティブ）1名とSE（ソリューションエンジニア）2名という構成でした。この小さなチームが、2万1000件もの潜在的な企業アカウントの中から、どこに優先してアプローチすべきかを判断できるよう支援する仕組みが求められていました。

創業者のクーパーも、すでに獲得した見込み顧客と利用履歴を営業活動に十分活用できていないと指摘していました。

RailwayはPostHogを用いて、製品の利用イベントを長期にわたり収集していました。内部システムであるbackboardにも、プロジェクトのサービス構成、インスタンスサイズ、データベース接続、デプロイ結果などが記録されていました。分析に必要なデータは揃っていたものの、そのデータから営業チームがアプローチすべきアカウントを抽出するプロセスが抜け落ちていたのです。

マッキンゼーによるPLG研究でも、製品の利用体験と企業情報を併せて分析し、適切なタイミングで営業チームが介入する手法が解説されています。利用行動に基づいて購買の可能性を評価した見込み顧客をPQL³と呼びます。単に登録者数を増やすだけでなく、どのユーザーにどのようなサポートが必要かを見極める取り組みです。