これらのツールと手法を使用してデータ チームを早期に確立する

データチームへの投資は早すぎることはできません。それは、小さいながらも成長しているチームとして私たちが学んだことです。初期段階でデータ チームに投資したことで、製品の使用傾向を確立し、ビジネス インサイトを作成し、製品を改善する領域を特定することができました。

初期段階のスタートアップの場合は、できるだけ早くデータ戦略チームとアーキテクチャの構築を開始してください。大きくなる必要はありません。1 人のデータ チームは、成長するにつれて成功に大きな違いをもたらすことができます。

まずゼネラリストを雇う

データチームを立ち上げることになると、可能な限り最大のブランド名から専門家を雇いたくなるかもしれません.私たちのアドバイス: 初期段階のスタートアップの経験があり、大規模なデータにも取り組んでいる人を見つけてください。

大規模なエンタープライズ データ チームには頭脳明晰な素晴らしい人々が働いていますが、これらの大規模なチームには、データ プラットフォームの特定の部分を専門とする従業員がいることがよくあります。チームに 10 人のデータ エンジニアがいる場合、または価格設定アルゴリズムに取り組んでいる機械学習データ サイエンティストの大規模なチームがある場合、これは理にかなっています。しかし、組織全体でデータの役割が 1 つしかない場合は、すべてのことを少しだけこなせる人が必要です。

最初に、データの洞察を作成し、ビジネスの仮説を立て、スケーラブルなデータ アーキテクチャをゼロから作成できるオールラウンダーを雇うことが重要です。データチームをゼロから構築し始める準備ができている人、できれば準備ができたら残りのチームを雇ってくれる人が必要です。

この最初の採用者は、初期段階のスタートアップでデータチームを構築した (または少なくともそれに取り組んだ) 経験がある人でなければなりません。彼らは迅速に価値を生み出し、適切な質問をするビジネス感覚を持っている必要があります。彼らは、あなたが抱えている最も困難な問題に飛び込むのではなく、80/20 の方法でデータにアプローチして、すぐに結果を出すことができる必要があります。

データ エンジニアリング側では、アーキテクチャのセットアップを支援するためにコンサルタントまたは請負業者を雇うのが一般的です。最初の雇用をコンサルタントで補完することにしました。このようにして、パートタイムのデータ エンジニアリングの専門家と、日常的にデータ アーキテクチャを維持できるゼネラリストという、両方の長所を活用できます。私たちは強力な基盤を構築し、知識を社内に保持しました。

小さなデータチームが大きな質問に答えることができます

長期的にデータ チームに必要なすべての役割をすぐに採用できなくても、適切な人材を 1 人か 2 人雇うだけで多くのことができます。重要なのは、スケーラビリティと効率の観点から考えることです。データ チームがより少ないリソースでより多くのことを行うのに役立つものは何ですか?チームが大きくなった場合、これはどのように機能しますか?

小規模なデータ チームでは、スケーラブルな分析が非常に重要です。チームの成長に合わせてプロセスとワークフローがどのように機能するかを事前に検討することで、時間を節約し、従業員にとって最も時間のかかる問題のいくつかに対して価値のあるソリューションを作成できます。

たとえば、営業チームは見込み顧客の製品の使用状況を把握できておらず、頻繁に発生することにすぐに気付きました。そこで、営業担当者が自分でデータを取得できるようにワークスペース ダッシュを作成しました。当社のデータ チームの仕事は、データ主導の意思決定を可能にすることです。販売側で何百時間もの節約につながる可能性のある 1 回限りのデータ投資の機会を見つけたとき、私たちはそれに対応しました。

小規模なデータ チームは、将来の問題の防止にも注力する必要があります。現時点で 1 人のデータ チームの人員しかいない場合は、彼らを最大の問題に集中させながら、データ アーキテクチャを維持およびスケーリングして技術的負債を削減するための時間も確保してください。

データチームが使用するツール

当初から、私たちの目標は、すべての決定について前向きに考えることでした。

すべてのスタートアップと同様に、私たちはすぐに ROI を生み出したいと考えていました。私たちは、信頼できる唯一の情報源である集中型データ ウェアハウスを使用しています。断片化されたデータや信頼できないデータを持つことほど、データ チームを傷つけるものはありません。自動化と統合のおかげで、データを統合することができます。

これにより、低リフトで会社全体に貴重な洞察を提供できます。

セグメント (データ収集ツールでもある)、Fivetran、Snowflake 外部ステージなどの ELT ツールを使用して、すべてのデータをパイプします。

を使用しておりますdbtすべての生データをより使いやすい形式にクリーンアップします。たとえば、dim_user テーブルには内部で機能する最大 20 個のテーブルがあり、顧客が送信する通知の数や使用しているプランの種類など、顧客に関する多くの重要な情報が含まれています。これをすぐに利用できるようにすることで、技術者以外のユーザーがビジネスの洞察をすばやく引き出すことができます。大量の通知を送信している無料またはセルフサービスの顧客をすばやく調べて、ビジネス契約の見通しを特定できます。当社のカスタマー サクセス チームは、ビジネス契約のお客様の健全性を確認するためのレポートも作成しました。また、dbt を使用して機密情報のデータをクリーンアップします。

Census を使用して、倉庫データを HubSpot や Courier などの場所に送り返します。これにより、営業およびマーケティング チームは、日常的に使用しているプラットフォームでこの情報にアクセスできます。

Metabase は BI ツールです。ダッシュボードを作成し、SQL クエリを記述し、技術者以外のユーザーにセルフサービス形式を提供することができます。このようなセルフサービスのデータ ダッシュボードを作成すると、ユーザーは多くの質問に答えることができることがわかりました。 Looker や Tableau を使用するチームのように、事前に多額の投資をしなくてもすぐに立ち上げられます。

たとえば、会社全体の上位指標を示す KPI ダッシュがあります。また、個々のワークスペースのパフォーマンスを追跡し、営業チームのターゲットにできるワークスペースを特定することもできます.また、お客様の製品使用状況を深く掘り下げることで、データ駆動型の意思決定を製品開発にもたらしました。一例として、多くのユーザーが同僚の既存の Courier インスタンスに参加するのではなく、独自の Courier インスタンスを作成していることがわかりました。この洞察を使用して、製品チームは設計図に戻り、同じビジネス メール ドメインによって作成された Courier ワークスペースを表示するページを作成して、アクセスを簡単に要求できるようにしました。

また、Propel を使用してアプリ内分析を強化し、エンド ユーザーに可視性を提供しています。 Propel を使用する 1 つの方法は、ビジネス層の顧客にテンプレート分析を提供することです。 Propel を使用すると、エンジニアはウェアハウスのメトリクスの上に GraphQL ビジュアライゼーションを簡単に配置できます。

私たちのデータチームは再び進化しています

今、私たちは成長期に入っているので、当然のことながら、データへのアプローチを再び進化させています。現在の目標は、一元化されたデータ標準を維持しながら、データ サイエンティストが対象分野の専門知識を構築できるようにすることです。

現在の構造は一元化されており、上級分析エンジニアがデータ責任者に報告しています。まだデータ チームを構築する初期段階にあるため、現在は機能しています。しかし、チームが拡大すると、ハイブリッド モデルに移行します。

データ サイエンティストは特定のビジネス分野 (製品チームなど) を担当しますが、それでもデータ責任者の直属となります。これにより、データ サイエンティストは、成長を続ける中、一元化されたデータ標準を維持しながら、対象分野の専門知識を構築できます。データ チームは組織の他のメンバーと共に常に変化し、成長するため、ビジネスに合わせて拡張できる標準が必要です。

データの標準化への取り組みについて詳しく知りたい場合は、次のブログ投稿をご覧ください。 Courier が HIPAA 準拠になった経緯.