スタートアップが事業を成長させるデータ分析の考え方とその手法

みなさま、こんにちは。スタートアップソリューションアーキテクトの岸田です。
このブログ記事では、主に自社プロダクトを開発するスタートアップ向けにデータ分析の重要性を紐解き、フェーズごとのアーキテクチャ例を解説していきたいと思います。

スタートアップがデータ分析を必要とする理由

一部のスタートアップの中には、「データ分析が重要なことはわかっているものの、何を分析するべきか分からない」と分析を行わないスタートアップも多くいらっしゃると思います。ですが、データ分析が必要となるタイミングは突然訪れます。このパートでは、データ分析を備えておくべき理由を解説します。

ビジネスの進捗をデータを用いて評価するため

スタートアップにとって重要な活動の一つに、「資金調達」というものがあります。
この依頼先はベンチャーキャピタルであり、ビジネスが将来的な視点も含めて順調であることを、具体的なデータを用いて伝えなければいけません。特に調達フェーズがより次のフェーズに進むと、ベンチャーキャピタルは「ビジネスに再現性があるかどうか」を主軸に判断することが多く、この再現性を評価するためにはデータが必要になります。

そのためには以下のような質問に定量的な指標を用いて回答する必要があります。

「そのプロダクトは今後提案しても契約に結びつく可能性があるのか？」
「その人達はそのプロダクトを継続して利用してくれるのか？」
「これからも同様の営業活動を行わないと、導入件数および収益は伸ばせないのか？」
「今後ビジネスはどこまで成長する見込みはあるのか、上場見込みはあるのか」
「どのKPIを伸ばせば、売上が増えるのか？」

この質問にいつでも回答できるように、常にデータを確認できる状態にすることをおすすめします。

プロダクト自身をデータを用いて評価するため

自社プロダクトでビジネスを展開するスタートアップにとって、プロダクト自身の状況を知ることはとても重要です。プロダクトの状況を把握せず、経営層や開発者の思いつきでプロダクトの方向性を決めたり、なんとなくで機能開発の優先度を決めていると思わぬところでユーザーが離れてしまいます。

ユーザーが離れるきっかけは以下の通りです。

プロダクトを導入してみたが、あまりエンドユーザーには定着しなかった
提供される機能が思ったような機能ではなかった
プロダクトが不安定でユーザビリティが低く使えなかった

この状態を未然に防ぐためには、プロダクトの指標をベースに評価し「プロダクトがユーザーにとって絶対に必要なプロダクトになっている」状態であることを確認しながら、開発を進める必要があります。

エンドユーザーにデータを提供するため

カスタマーのデータを取り扱うプロダクトの場合は、カスタマー側でデータを把握したいというニーズがでてきます。例えば使用状況のレポート機能は、こういった背景を理由にリリースされます。

初期の場合は、カスタマーからの問い合わせの都度、エンジニアがデータをエクスポートすることで運用できるかもしれません。ですが問い合わせが急激に増えた場合は、この体制は崩壊してしまいます。SQLを書けない社内メンバーやカスタマーに向けて、エンドユーザーの利用状況を可視化したり、レポートを出力する機能を備えることで、迅速にビジネスをスケールすることができます。

具体的に分析する KPI の例

それではどのようなデータを集めて、どのような KPI を評価すると良いのでしょうか。これは会社のビジネス特性やプロダクトによって全く異なりますが、一部を例として解説したいと思います。

ビジネスの進捗を見たいときの例

以下の前提でビジネスモデルを構築したことにします。

ビジネスモデル
- B to B の企業向けサービスを展開
- 月額使用料が発生するサブスクリプションモデル
- ただし最初の一ヶ月は無償期間を設ける
提供方法
- マルチテナントでの提供。企業が申込みページで申請すると、企業専用のページが立ち上がり、すぐ利用することができる

この場合、以下の指標が例としてあります。（※出典元はこちら）

サブスクリプションのビジネスモデルということもあり、メニューごとの金額が決まればテナント情報、契約日時、解約日時を記録しておくだけで上記の KPI が計算できます。また手動でスプレッドシートに記録するだけでなく、テナント情報が保存されているデータベースにこの２つを記録し、ダッシュボードで可視化することで社内全員が KPI を確認できます。このような数値をデータベースに持たせておくことは今後ビジネスを評価する上で重要になります。

プロダクトがユーザーにとって必要不可欠になっているか確認する例

はじめに以下の指標を分析してみましょう。（※出典元はこちら）

定期的なアンケート
- この営業支援ツールがなくなったらどれだけこまるか、5段階評価をもらう
- アンケートポップアップをプロダクトに表示させ、結果をログとして収集する
問い合わせ内容（チャット・メールなど）
- エンドユーザーからの質問がプロダクトをより良くするネタになることが多いので、テキストデータとして保存する
ユーザーの解約率
- 各テナントの利用登録日時と退会日時を記録する
ユーザーの利用回数・利用時間
- テナントごとのユーザー利用人数、利用時間、対象の利用機能を測定する
パフォーマンス状況
障害発生数や障害発生率

指標を分析するためには、ユーザーの利用ログをデータベースに蓄積しておき、テナントやユーザーに紐づけて記録しておくと良いです。自身で利用ログをためておくと、自社のビジネスに沿った KPI に基づいた必要なデータを用意しやすくなるので、利用ログとして自身のデータベースにためておくことをおすすめします。

スタートアップにおすすめのデータ分析のはじめかた

ここまでデータ分析が必要となる理由と、具体的な分析対象を解説しました。それでは、AWS でデータ分析を始めるとなると、どのサービスを利用すれば良いのでしょうか。AWS にはデータ分析を支援するためのサービスが揃っています。

Amazon QuickSight：インタラクティブなダッシュボードやレポートを作成できる BI (Business Intelligence) ツール
Amazon Redshift：クラウド内でのフルマネージド型、ペタバイト規模のデータウェアハウスサービス
Amazon Athena：標準的な SQL を使用して S3 内のデータを直接分析できるサーバレスなクエリサービス
AWS Glue ：抽出、変換、ロード (ETL) プロセスの検出、準備、統合、近代化を容易にするサーバーレスデータ統合サービス

ですがスタートアップにとって、分析のユースケースが決まらないまま本格的なデータ分析基盤を導入することは大きな手戻りリスクが起きます。そのため初期では手軽な方法でデータ分析基盤を導入し、本来時間をかけるべきデータの分析や機能開発に注力する必要があります。そこでこのセクションでは、スタートアップにおける分析フェーズを整理した上で、どのサービスを利用してフェーズごとに適した基盤を作るかを解説します。

Phase1: 社内全体の意識をデータ分析に向ける

データ分析を始めるフェーズでは、CTO やフルスタックのエンジニアがデータ分析を担当することがあります。しかしデータ分析業務が特定の人に集中すると、ユーザーが増えて来た時にスケールできずビジネスが成長する機会を失うかもしれません。ビジネスチームにもうまくスケールしながらデータ分析を手軽に構えるためにはどうすればいいでしょうか。

初期からデータ分析基盤を導入する必要はなく、初期段階は Amazon RDS などの OLTP のデータベースを構えて置くだけで最低限の分析をすることが可能です。ビジネス向けにデータを分析するためには、一般的に可視化ツールを検討しますが、この場合では Amazon RDS との親和性の高さで Amazon QuickSight がおすすめです。

他にもポイントが2点あります。

Amazon QuickSight には SPICE というインメモリエンジンが備わっています。Amazon RDS から SPICE にデータを一時的に取り入れることで、同じクエリを頻繁に行っても RDS 側に負荷をかけることはありません。
Amazon QuickSight では Amazon RDS とのコネクターがサポートされており、UI 上で Amazon RDS との接続設定をするすることができます。（ Amazon QuickSight には、Amazon RDS 以外にも様々なコネクターがサポートされています）

非常にコンパクトなアーキテクチャですが、分析ユースケースが決まってない段階のスタートアップにはおすすめのアーキテクチャです。

Phase2：社内でデータ分析が活発になり負荷がかかり始める

Amazon QuickSight の導入によりビジネス側の分析も活発になり、扱うデータも増えてくると、既存の Amazon RDS に Read の負荷がかかり、既存のアプリケーションに影響がでてきます。加えて、データ量が増えてきた関係から Amazon QuickSight での表示負荷がかかり、表示に時間がかかってしまうケースが発生してしまいます。

その場合は Amazon Redshift を利用することをおすすめします。特に Amazon Redshift Serverless を利用することで、データクエリ負荷に応じて自動的にスケーリングするため、運用コストを抑えることができます。料金に関しても利用した分だけ課金されるので、データ分析における処理が安定しない場合にコストを最適化することができます。

一般的にデータウェアハウスを導入する際に課題となるのが、データの連携部分です。データ連携を実現するために、データを差分で抽出、データの加工、保存先への保存を一通り実装・運用する必要があります。Amazon Redshift では、Amazon Aurora との Zero-ETL 統合機能がリリースされており、こちらを利用することでAmazon Aurora のデータとニアリアルタイムに同期できます。

Amazon RedshiftとのAmazon Aurora ゼロETL統合

ですが、このブログの執筆時点ではリリースされているサービスが Amazon Aurora MySQL のみで、Amazon Aurora PostgreSQL や Amazon Aurora 以外の Amazon RDS の Zero-ETL 統合機能は Public Preview のみのため本番環境での利用は非推奨です。Zero-ETL 統合機能以外の方法としてはフェデレーテッドクエリを行うことで、データを直接取得することが可能です。

データ連携以外の観点だと、分析を行う際データの加工も必要になってきます。例えば、細かいデータを特定の時間範囲ごとに平均化して粒度を荒くしたり、複数のテーブルを一つにマージして分析したり、データマスキングなどです。その場合は、一度生データを Amazon Redshift に取り込み、変換処理を SQL で実装し、変換後のデータを中間テーブルとして保持することで Amazon Redshift 上で完結します。このようにデータウェアハウス内でSQLを利用した変換処理を定義する場合は、昨今コミュニティーが活発なdbtを利用することで、SQL 自体のテストやドキュメント化、GitHubとの連携により開発効率を改善することができます。dbt と Amazon Redshift の組み合わせ方については、以下のブログをご参考ください。

Manage data transformations with dbt in Amazon Redshift

また、データウェアハウス自体も Amazon Redshift だけではなく Snowflake を採用するパターンもあります。開発者の開発スキルや要件に応じてツールを使い分け、最適なアーキテクチャを検討しましょう。

Phase3: 対象のデータソースを広げる

よりデータ分析が活発になってくると、データソースを増やしたい要望が出てくることがあります。例えば、エンドユーザーからのメールの問い合わせ内容を分析したいケースを考えてみましょう。この場合、問い合わせデータは Salesforce などの SaaS を利用していることが多く、SaaS に溜まっているデータも分析の対象に含めたくなります。アプリケーションのトランザクションデータだけではなく、SaaS も合わせて分析するケースは、スタートアップにとっても必ず必要となるケースです。

このケースでは、Amazon Appflow を利用することで AWS 外の SaaS のデータを取り込むことができます。

Amazon Appflow を利用して取り込んだデータは一度 Amazon S3 に保存し、COPY コマンドで Amazon Redshift に取り込むことで、料金がかかることなくデータを同期することが可能です。COPY コマンドは、Amazon Redshift のクエリスケジュール機能を利用することで定期的な同期処理を行うことができます。

まとめ

本稿では、スタートアップがデータ分析を必要とする理由と、それを実現するためのアーキテクチャ例を解説いたしました。データ分析の理由を整理しフェーズごとに How を検討することで、ビジネスを成長する体制を整えることができます。まだデータ分析を始めるか悩んでいる方がいたら、まずは Amazon QuickSight をデータベースに繋ぐところから始めてみましょう。みなさまが手軽にデータ分析をはじめ、事業への成長にフォーカスする際にご参考になれば幸いです。

参考文献

著者について

岸田晃季 (Kouki Kishida)
スタートアップソリューションアーキテクト

スタートアップにて機械学習エンジニア、プロダクトマネージャーを経験後、より多くのスタートアップと関わりたいと思い現職にジョイン。スタートアップのために何ができるか日々模索中。

AWS Startup ブログ