初期段階のスタートアップ企業におけるデータの考慮事項

※この投稿は米国時間 2022 年 1 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

私のチームは、Google Cloud の分析および AI ソリューションを担当して、Google Cloud を基盤とするスタートアップ企業を支援しています。そのため、初期段階のスタートアップ企業による投資（初期投資も含む）がどのように成否を分けているかについて、創業者やエンジニアから学ぶ機会に恵まれています。この投稿では、Google Cloud を基盤とするスタートアップ企業が覚えておくべきベスト プラクティスをいくつか共有したいと思います。

技術スタックに取り掛かる前に、価値提案を理解する

クラウドを利用して起業しているスタートアップ企業であれば、おそらくすでに技術スタックについて検討しているはずですが、それはひとまず置いておき、顧客に提案する主要な価値について慎重に考えることが重要です。この価値提案こそが、どのようなテクノロジーを選ぶべきかを根本的に決める鍵となります。

たとえば、システムではリアルタイムの処理が必要ですか？それともバッチモードで処理できますか？1 日 1 回の分析情報で足りますか？それともイベントが発生するたびに分析情報を取得すべきですか？

また、顧客が直面するレイテンシはどの程度のものですか？価値提案の内容は、レイテンシの程度によって大きく変わってきます。Google は発展の早い段階で、ウェブページに結果が表示されるまで数百ミリ秒以上待つ人などいないことに気づきました。そしてこの認識が、Google を自宅ガレージのスタートアップ企業から 1 兆ドル規模の企業へと成長させた技術的判断の原動力となりました。スタートアップ企業は、自分たちのニーズに合った技術スタックを構築する前に、顧客に提案する価値を具体的に定義する必要があります。

顧客とのインタラクションにフォーカスする

こうした中、価値提案を再形成する大きな IT の軌道修正を見事にやってのけた企業がいくつかあります。たとえば Netflix は、主に DVD を郵送するビジネスから、ストリーミング サービスとコンテンツ制作の大企業へと転身しました。基本的な価値提案（つまり、顧客にコンテンツを提供すること）はほぼ変わっていませんが、ユーザー エクスペリエンスとそれをサポートするために必要な技術スタックには大きな変化がありました。ただし、これが例外的な事例であるというのも事実です。この規模の変更を選択肢として計画している場合は、ユーザーに価値を提案することにフォーカスするよりも、価値提案の内容を明確にすることがおそらく必要です。

具体的には、顧客が自分のビジネスにどのようにアクセスし、インタラクションするかについての明確なビジョンが必要です。通常、顧客とのインタラクションはウェブサイトやモバイルアプリで行われますが、それでも考慮すべき事項は山ほどあります。

顧客はドキュメントを送信しますか？その場合はどの形式で送信しますか？手書きはサポートされていますか？それとも入力はタイピングに限定されていますか？光学式文字認識に画像を使用できますか？主にフォームを使用しますか？データは構造化データですか？それとも非構造化データですか？質問攻めで困っているという方もご心配なく。この記事を読み終わる頃には、これらの質問に簡単に答えられるようになっているはずです。ただし、申し上げておきますが、考慮すべき事項はまだ他にもたくさんあります。

ほとんどの顧客が音声でビジネスにアクセスする場合は、会話型ワークフローを優先する必要があります。これを出発点として、さらに深く掘り下げていきましょう。Dialogflow（仮想エージェントを構築してデプロイできる Google Cloud の会話型 AI プラットフォーム）を使用している場合でも、提案できる価値はまだ見えてきません。顧客との一般的なインタラクションの開始から解決までを、どのように進めるべきでしょうか？たとえば、どのぐらいの数のインタラクションを低帯域幅の接続で円滑に進める必要がありますか？ユーザーとのインタラクションに関しては、エンドツーエンドのユースケースを確認することが重要です。

別の例として、小売ウェブサイトを構築しているスタートアップ企業に、特定の商品の在庫があるかどうかを顧客から尋ねられるというエンドツーエンドのユースケースがあるとします。顧客が要求している商品の量（1 ユニットまたは数十～数百ユニット）に応じて、その商品の在庫が十分にない場合は、在庫のある他の同様の商品をアプリに提案させる必要があります。選ぼうとしている技術スタックは、このユースケースをサポートできますか？

これらを考慮することを早計な最適化として片付けるべきではありません。迅速に対応し、実用最小限の製品をユーザーに提供して、それから改善を重ねることには価値があります。とはいえ、起業初期の段階では、良いスタートを切るチャンスは 1 回しか巡ってきません。そのチャンスにうまく乗じられるかどうかで、その後に必要となる費用と労力が大きく変わります。技術スタックの設計を開始する前に、単にアイデアを思い描くだけではなく、ビジネス ユースケースを確立しておく必要があります。  

正しい心構えを得る方法は次のとおりです。3 つのユースケース（基本的なものが 2 つ、技術的に複雑なものが 1 つ）を選択して、提案する技術スタックが 3 つのユースケースすべてを完全にサポートできることを確認します。

より高いレベルの抽象化を目指す

正しい心構えが得られたところで、技術スタックについてより直接的に考えていきましょう。

スタートアップ企業はリソースを節約して使う必要があります。そのためには、価値提案のために可能な限り高いレベルの抽象化を構築する必要があります。たとえば、クラスタの設定に人員の時間や労力を費やしたり、フルマネージド サービスを利用できるのに構成作業を行ったりする事態は避けるべきです。つまり、インフラストラクチャの管理ではなくプロトタイプの構築に人員を専念させる必要があります。

このことは、Google Cloud でのプロダクトの設計に明確な影響を与えており、Google Cloud の正規データスタック（Pub/Sub、Dataflow、BigQuery、Vertex AI）は自動スケーリングのサーバーレス プロダクトで構成されています。

ただし、シンプルな方が望ましいという原理を適用すべき状況は、インフラストラクチャの管理だけではありません。

アーキテクチャに関しては、ローコードよりもノーコードを、カスタムコードの記述よりもローコードを選択すべきです。たとえば、必要なデータを変換するための ETL パイプラインを作成してから、データを BigQuery に配置するのではなく、構築済みのコネクタを使用して、元データを BigQuery に直接配置することができます。つまりコードが不要になります。その後、データ ウェアハウスで直接 SQL ビューを使用して、必要な形式にデータを変換します。これは ELT と呼ばれるローコードのアプローチです。ELT アプローチは、ETL アプローチと比べてはるかにアジャイルです。

シンプルな方が望ましいもう一つの状況は、ML モデリング フレームワークを選択するときです。カスタムの TensorFlow モデルから始めるのではなく、コード不要の AutoML から始めるべきです。AutoML は BigQuery から直接呼び出すことができるため、複雑なデータおよび ML パイプラインを構築する必要がありません。また、TensorFlow Hub や HuggingFace などの構築済みモデル、つまりローコード アプローチに必要に応じて移行することもできます。独自のカスタム ML モデルを構築するのは、最後の手段にしてください。

テクノロジーに関する過剰な情報に振り回されず、ビジョンを市場に打ち出すことにフォーカスする  

目標は、ビジョンを市場に投入し、顧客に価値をもたらして、リソースを節約し、成長のための柔軟性を維持するための適切な技術スタックを選択することです。初期の IT 投資は、通常、標準プロトコルやオープン API に基づいて構築されたマネージド サービスなど、柔軟性を維持するテクノロジーに充てるべきであり、派手に騒ぎ立てられているテクノロジーを急いで選択する必要はありません。たとえば、ML が必ずしも答えであるとは限りません。ヒューリスティックから始めて、十分なデータを収集した後で ML に移行できる道筋を整えておくこともできます。インテリジェンス レイヤに十分な抽象化を確保できるよう、最初はシンプルなルールでマークアップできるようにして、後でより堅牢なシステムに置き換えるのが賢明です。

原則に基づいてリリースとイテレーションを迅速に行う

ここまで説明したとおり、組織にとって最も貴重なリソースである人員にプロトタイプの構築に専念させること、つまり、実用最小限の製品や本番環境アプリの構築に専念させることが重要です。そのためには、リリースとイテレーションを迅速に行う必要があり、それを可能にする唯一の方法が差別化要因にフォーカスすることです。

どのテクノロジーを使用する場合も、次の 4 つの原則に従うべきです。

• 自社の主要な価値提案を理解し、それを中心に技術スタックを設計します。

• ユーザーとのインタラクションに十分な注意を払います。ユーザー エクスペリエンスは非常に重要です。顧客から期待されているエクスペリエンスを確実に実現する必要があります。

• 構築の際は、可能な限り高いレベルの抽象化を選択します。つまり、必要な機能を備えたフルマネージド ツールとノーコード / ローコード フレームワークを選択すべきです。

• 新しいテクノロジーや派手に騒ぎ立てられているテクノロジーを選択するのではなく、「そこそこのレベル」の実用最小限の製品を迅速に構築してから、後で改善を重ねられないかどうかを検討します。

スタートアップ企業が Google Cloud を選択すべき理由の詳細については、こちらをクリックしてください。