スタートアップでデータチームを作る
(erikbern.com)-
年商100億ウォン規模のミッドステージ・スタートアップで、4人ほどの小規模なデータチームを育てるために参画した人の話
-
何度かの経験に基づく比喩的な文章であり、偏っている可能性があるので、その点を踏まえて読んでほしい
7月1日：朝
-
データチーム責任者として初出社の日
-
CMOとあいさつ
(CMOは私が来たことにとても興奮している。友人の会社がAIを使って顧客セグメンテーションをしていて、それが格好よく見えると話している)
(簡単に話した後、マーケティングチームのデータプラクティスを調査)
DATA: "顧客獲得コスト (CAC) はどうですか？"
CMO: "うーん……実際とても優秀ですよ。うちのデータサイエンティストが数値を測ってみたところ、クリック単価がどんどん下がっているんです"
DATA: (すべてのデータサイエンティストはデータチームにレポートすると聞いていたのに、他組織にデータサイエンティストがいるのか？)
CMO: "本当の問題は、Growthチームが私たちがサイトに連れてきたトラフィックを全然コンバージョンさせられていないことなんです"
DATA: "コンバージョンファネルを見られるダッシュボードはありますか？"
CMO: "リードを転換するのはGrowthチームの仕事でしょう。"
- Product Managerの1人と会話
開始ページを全面的に再設計したPMは、ユーザー登録数が14%も増えたと興奮していた
DATA: "その数字の差は統計的に有意ですか？"
PM: "それは私の仕事じゃなくて、あなたのチームの仕事でしょう"
PM: "以前に聞いたときは、データチームからデータがないと言われて、データを得るのに数か月かかると言われました"
PM: "驚くべきなのは、これをインクリメンタルに変更しなかったことです。私たちはこの変更についてA/Bテストをしないことにしました。時には極値(Local Maxima)を抜け出すには大きな賭けをしなければならないんです。"
PM: "スティーブ・ジョブズはiPhoneをローンチするときA/Bテストなんてしませんでした。うちのチームは締切の2日前にこれをローンチしたんです。それが重要なんですよ！"
DATA: (忙しそうなふりをしてノートに走り書きする)
- 新しいチームメンバーたちと会話
→ 3人チームだが、年末までに10人に増やせる予算をもらっていた
→ 私が来てチームメンバーたちは興奮しているようだ
→ 既存に作ったものを見せてもらう。かなりたくさんあり、その一部はすごい
✓ ユーザー離脱予測(Churn Prediction)のためのニューラルネットワーク
✓ 関連商品レコメンドシステムが実装されたノートブック
→ 多くのコードは、さまざまなシステムからデータを取得しなければならない非常に複雑な前処理ステップから始まる
✓ この作業の一部を実行するには、正しい順序で手動実行しなければならない複数のスクリプトがあるようだ
→ チームメンバーに、なぜプロダクションに導入していないのかと聞くと
✓ エンジニアたちは、これをプロダクションレベルにするには非常に大きなプロジェクトだと言っている
✓ Product Manager がバックログには入れたが、他の仕事が次々発生して後回しになっている
✓ そのためには経営陣の支援が必要だと言っている
7月1日：午後
- サプライチェーン責任者(Head of Supply Chain)との会話 ( CMOほどは興奮していないようだ )
"正直、データチームの助けが必要かどうかわからないんですよ"
"うちはそういう種類の問題はないんです。私たちに必要なのはビジネスアナリストです"
"私にはチーム全体がいて、彼らは非常に複雑なモデルの作業に毎日何時間も使っています"
"彼らには、私が持っている基本的な質問に答える時間さえないんです。"
"答えを知りたい質問でいっぱいのスプレッドシートがあるんですよ"
(スプレッドシートを見ると、こんなものがある)
"顧客がチケットを発行して1時間以内に解決された顧客と、1時間以降に解決された顧客のコンバージョン率を、注文金額100ドル刻みで分類して比較すること"
(モデルについて聞くと)
-
たくさんのVLOOKUPで構成されたGoogle Sheetsに、正しい形式で適切なタブへコピーしなければならないようだ
-
データは毎日更新され、モデルの出力に応じてチームのその日の優先順位が決まる
-
ベンダーに支払う費用もスプレッドシートで計算している
(家に帰ってウイスキーを一杯なみなみと注ぐ…… )
[ 何が起きていたのだろうか？ ]
-
これは基本的に、データ成熟段階の初期にある多くの会社で起こることを描いた、ややシニカルな描写である
-
データ不足と断片化したデータ
→ プロダクトが適切に計測(Instrumented)されておらず、データが最初から存在しない場合が多い
→ データが複数のシステムに分散しているデータシステムの断片化
→ データドリブンで運用はされているが、自動化がほとんど、またはまったくない脆弱なビジネスプロセス
- データチームの仕事が何かについての不明確な期待
→ R&Dを行い、AIを配備するために雇われたデータサイエンティスト - 結果として明確なビジネス目標がない
→ データチームはMLの本番導入が難しいと不満を言うが、肝心のプロダクトチームはその機能をあまり気にしていない
→ "English-to-SQL翻訳機" を必要とする人たち
- データドリブンのトレーニングを受けていないプロダクトチーム
→ プロダクトマネージャーは、データをより良い機能を構築するための道具だと考えていない
→ プロダクトチームが構築したいものと、データチームが持っているものの間にアラインメントが不足している
- 根本的にデータ中心文化と相反する文化
→ 測定可能な進歩と学習を称賛するのではなく、出荷(Shipping)を称賛する文化
→ 実際にメトリクスを使っているチームも、一貫性がなく、測定が適切に行われず、場合によっては他チームと衝突する
- データリーダーシップがない
→ さまざまなデータ人材が複数の異なる部門(機能)にレポートする、分裂したデータ組織
→ 他部門は必要な支援を受けられないため、データチームを取り囲むように多くのアナリストを雇用する
→ ツールチェーンおよびベストプラクティスの標準化不足
(うわ、これは憂うつだ。この問題を解決するには何をすべきだろうか)
7月8日
-
翌週からデータチームの新しい方向性を定め始める
-
1人がインフラの経験を持っていそうなので、彼にCentralizedデータウェアハウスの構築を任せる
-
当面は、データを1か所に集めるための最速ルートさえあればよい
-
計画としては、基本的に1時間ごとにプロダクションDBをデータウェアハウスへダンプすること
-
フロントエンドで広告追跡トラッキングに使っているフレームワークからも膨大なイベントログを送れるが、それは技術的負債としていったん保留する
-
採用チームと一緒にGeneralist Data Roleを定義
→ コアなソフトウェアスキルを重視しつつ、Generalist(何でもやる人)的な姿勢と、ビジネス要件に深く共感できる人
→ 当面は人工知能および機械学習に関する言及はすべて削除する
- データチームにレポートしていない他のデータ人材たちと時間を過ごす
→ マーケティングチームにいるというデータサイエンティストは若い人だった。"私はずっとデータサイエンティストになりたかったんです。あなたからたくさん学びたいです"
-
コーディングブートキャンプを運営している友人に、良い "SQL教育講義" があるか聞いたところ、あるとのことだったので今月末に導入することに
-
プロダクトチーム向けに、A/Bテストとは何か、どう動くのかを説明する発表資料を作成
→ 予想外の結果が出たテストの例をたくさん見せ、
→ どれが勝ったのか推測できるようインタラクティブに作成
-
CEOの秘書に会って、「毎週自動送信されるメールで報告されてほしい指標」が何かを把握する
-
Supply Chainチームのビジネスアナリストたちと話してみると、合理的な人たちではあるが、以前データチームと話した際に傷ついた経験があった
-
そのうちの1人は過去にSQLを使った経験があった。彼がコンバージョン率について質問するのを見て、データウェアハウスへのアクセス権を与えた
-
データを必要とする組織全体の人たちと、毎週の1:1ミーティングを設定
→ 要点は、データのギャップと機会を見つけてデータサイエンティストに渡すこと
→ データサイエンティストたちは研究の優先順位が後回しになるため、失望するかもしれない
→ 「できるだけ早くビジネス価値を提供することに集中」と言いつつ、「そのうち機械学習関連の作業に戻れるかもしれません。まずは様子を見ましょう」と話す
9月1日：朝
-
3か月が過ぎ、ようやく少しずつ物事が回り始めたように感じる
-
さまざまなステークホルダーと毎週1:1で会いながら、データが変化を起こせる盲点や機会を継続的に探す
-
見つけたものを、コアなプラットフォーム作業を後押しするために活用
-
「派生」データセットを作るには多くのパイプラインを構築しなければならない。初期コストは大きいが、正しいデータセットができれば後続の分析ははるかに容易になる
-
他部門にデータウェアハウスへのアクセスを開放し始める
-
自分でSQLを使って基本的な分析を始める
→ 良かった出来事：ジュニアプロダクトマネージャーが、iOS Safariのコンバージョン率が極端に悪いことを発見。local storage関連のフロントエンドのバグで、1行の修正で直った
- サプライチェーン責任者が怒りのメールを送ってくる
→ データベースが変更されて、500行のクエリが失敗するということだった
→ ぶつぶつ文句を言うデータサイエンティストに修正を任せ、別のニンジンをぶら下げる「今月末に面白い機械学習の問題を見つけてきますよ」
9月1日：午後
-
まだCheckoutチームのプロダクトマネージャーはメトリクス分析をしていない
-
マーケティングチームのデータサイエンティストがマネージャーと話し、私に直接レポートすることになる
[ 何が起きているのか？ ]
- 最も緊急なことの基本的な土台を整えている最中
→ 重要なデータを1か所でクエリ可能にする
→ SQLアクセスを開放し、他チームでも使えるようにして、多くの「SQL翻訳」作業をなくす
-
一方で、他チームはこの自由によってさらに先まで行こうとするかもしれない。データアクセスに権限を設定して防ぐことはできるが、デメリットの方が大きい
-
Checkoutチームがデータ分析をできなかったのは、誰に聞けばいいのか分からなかったからだ
-
これは主に組織の問題である
→ チームはデータチームとどう協力すればいいのか分からない
→ 気づいていないが、データチームがボトルネックになっている可能性もある
- 最も合理的なのは「レポートは中央集権化し、業務管理は分散化すること」
→ データと意思決定がより密接なフィードバックループを生み出すからだ
→ データチームのメンバーがそれぞれのチームで協業し、レポートだけ私（データチームリード）に上げられるようにするため
9月2日
- データチームは6人に増える
→ 1人はデータウェアハウス基盤担当
→ 5人はそれぞれのチームに配属：オンボーディング、サプライチェーン、Checkout、マーケティング、CEO支援および投資家・取締役会向けプレゼン資料作成
-
全社に変更を説明し、データ要件については誰と仕事をすべきかを明確にする
-
今後データ人材を採用しても、他チームに配属する計画
1月3日
-
データサイエンティストの1人が辞めることになる。彼が楽しめる仕事も多くないため、引き止めないことにする
-
チームには新しい人が多い。多少のソフトウェアエンジニアリングの知識とSQLを持ち、データの中から面白いものを見つけたい人たちだ
→ データの中から「スクープ」を見つける人たちなので、「データジャーナリスト」だと考える
- オンボーディングチームと仕事をしているメンバーの場合
→ オンボーディングフローで、顧客住所が必要なくても住所を尋ねていることを発見
→ これを削除すると、A/Bテストでコンバージョン率が21%向上
→ データをクエリしやすくするためにETL作業が必要で簡単ではなかったが、Pythonが少し助けてくれて実現できた
- CEOとの四半期報告
→ 成長イニシアチブで、PMが新たにローンチしたランディングページ再設計を紹介
→ PMは、20人のエンジニアが締め切りに間に合わせるために残業していると強調
→ CMOもこの再設計の一環としてDirect Mailに大きな期待をかけており、深く関与している
→ CEOの質問「現在の指標はどうですか？ 顧客獲得コストは下がりましたか？」
（あなたはCEOがこうした質問をすることを期待していて、その通りの質問が出たので微笑む）
→ PMは実際にA/Bテストを行ったとして、付録にある数字を見せる
→ 一部の指標は上がり、一部は下がっており、有意な結果を示すような結果はない。顧客獲得コストの数値は良くなさそうだ
→ CMOは、まだ数字は積み上げている途中であり、この種のキャンペーンは数か月かかることもあると強調
[ 何が起きているのか？ ]
-
良い知らせは、プロダクトチームがA/Bテストを始めたことだ
-
悪い知らせは、結果を無視して、プロジェクトの大半がマイルストーンと人為的な締め切りに合わせて進められていることだ
-
最も良い知らせは、CEOが各チームに対して、データが真実として使われるよう後押ししていることだ
-
組織がよりデータドリブンになるよう圧力が高まるなら、データチームが他チームと協力するやり方も加速させる必要がある
-
特に経営陣はより指標に集中するようになり、データチームにそれらの指標へ取り組ませるのがあなたの仕事になる
-
最も簡単な方法の1つは、各チームが重視する指標についてのダッシュボードがあることを確認することだ
4月1日
-
データチームが以前に行っていた機械学習の仕事は、まだそのまま残っている
-
在庫プロダクトチームで働くデータサイエンティストが、以前に作った推薦システムの仕事に関心を持っている
-
新たに採用したメンバーの1人はGeneralistで、その人が推薦システムのノートブックを小さなFlaskアプリにして社内にデプロイした
-
在庫チームのプロダクトマネージャーがそれを見て気に入る「これ、どうやってデプロイするんですか？」
-
在庫チームの主要指標の1つは「平均注文金額」で、この推薦がそれを大きく改善できると見ている
-
簡単な見積もりでも大規模にデプロイするのは難しそうだが、「顧客の1%にだけデプロイしてみたらどうでしょう？」というアイデアを出す
-
「雑ではありますが、Cron Jobで推薦商品を事前生成しておけばよくて、数日で作れそうです」
-
サプライチェーンチームと仕事をしながら、さらに多くの巨大なSQLクエリを発見
-
壊れ続けているが、データチームがこれを適切なパイプラインに変換する作業を進めている
-
サプライチェーンチームの責任者が、さらに多くのデータサイエンティストを採用してほしいと要請
[ OK、何が起きているのか？ ]
-
まず、素晴らしい機械学習の仕事への希望が生まれた
-
プロダクトチームはついに、推薦システムを小さなテストとしてローンチすることに興奮している
-
以前は、プロダクトエンジニアリングチームが作業の見積もりをしにくく、直接貢献したがらず、データチームにも本番化するスキルがなかったため、進められなかったことだ
-
この問題を解決できたのは、データチームが実際にデモを構築したからこそ可能になったことだ。こうすることで本番に近づくだけでなく、可能性を明確に示せる
-
もう1つは、サプライチェーンチームで起きていることだ
→ 独自の「ビジネスアナリスト」から始まったが、データを得るにはデータチームがクエリを実行してあげる必要があった
→ アナリストたちはデータチームの助けを受けながら、自分でクエリを実行し始めた
→ まず、データチームとの摩擦を生んでいた「シャドー技術負債」（怪物のように巨大な SQL クエリ）をなくし始める
→ データチームがサプライチェーンチームに入り込み、支援を始める
→ データチームのメンバーが埋め込まれることで、ビジネスアナリストの必要性は減り、データサイエンティストが増える
-
最初に本番 DB をデータウェアハウスへ直接ダンプし始めたとき、「技術負債」を引き受けたことを覚えておくこと
-
最初のうちは多くのものが壊れるが、安定してクエリできるようにするレイヤーを追加しなければならない。非常に大きな作業になりうる
7月1日
- 第3四半期の企画会議
→ 以前は、次の四半期に会社が何に賭けるかを議論していた
→ 今回は、あなたが会社の最上位指標を発表し、各チームがサブ指標を通じて最上位指標を細分化して発表する
- プロダクトマネジメントチームの取り組みが成果を上げた
→ PM がテストを実行しながら学んだ内容や、データから発見した内容について話し、プロジェクトへの投資を正当化する
- 大きな成果は、チェックアウトチームと働くデータサイエンティストが、ユーザーが確認ページで戻るボタンを押したときにカートオブジェクトがおかしくなることを発見したこと
→ この問題を解決すると、コンバージョン率が大きく上昇した
- もう1つのインサイトは、異なる広告キャンペーンから来たトラフィックは、非常に異なるコンバージョンプロファイルを持っているということ
→ あるキャンペーンはクリック単価が安かったがコンバージョン率がひどく、別のキャンペーンは費用が高かったもののコンバージョン率は非常に高かった
- UTM 変数を追跡してアカウント作成に結びつけることで、広告クリックから購入までのコンバージョン率を測定できるようになった
→ すべてのデータを同じデータウェアハウスに持ち込み、簡単にクエリできるよう正規化する前は不可能だった
→ マーケティングとの協力を通じて、主要 KPI はクリック単価ではなく End-to-End の顧客獲得コストである
- もう1つの面白いニュースは、1% のレコメンデーションシステムテストが異例の成功を収めたこと
→ ユーザーの 100% まで拡大するのは非常に大きなプロジェクトだが、CEO がプロジェクトを承認した
- すべての成果物がポジティブなわけではなく、多くのテストは失敗した。
→ スライドの1つは、送料を別途請求せず価格に含めたテストについての説明だった
→ CEO がこう言う。「ここから何を学びましたか？」
→ これは再び一連のフォローアップ実験を計画する会話へとつながる
（家に帰ってシャンパンを開ける）
[ 何が起きたのか？]
-
あなたはやり遂げた。
-
組織を真のデータネイティブへと変革した。
-
データチームはさまざまなステークホルダーと部門横断で働く。
-
データとインサイトが計画に使われ、データは目的の不明確な研究ではなくビジネス価値を生み出すために使われる。
-
会社は迅速なデータ駆動のフィードバックループを活用し、大規模な「ウォーターフォール」型の計画ではなく反復的な方法で働く。
-
指標は、ビジネス価値を生み出し、それに対する責任を持てる形で定義される。
-
データ文化は上から（CEO が推進し）と下から（従業員）という両方からともに主導される。
-
少なくとも何かを学んだのであれば、失敗しても構わない。
（おめでとう。あなたはシャンパンを掲げる資格がある）
7件のコメント
冒頭を読んでいて、うちの会社のことかと思いました……（泣）（もちろん、うちはデータチームすらありませんが笑）
楽しく読ませていただきました。ありがとうございます〜！
エンジニアが好んで見そうな、テック系スタートアップを題材にしたドラマのあるエピソードを見たような感じです。面白いです！ 👍
22222
人が多く見えるけど、この程度がミッドステージ向けなのか
おそらく、国内とは見ている規模が少し違うのだと思います。
Opinionated* については、すっきり訳すのが難しいのですが、私は主に「自分の意見が反映されていて偏りがある」という意味で「偏向的」と訳しています。
これについては別の方が書いた文章があるので、参考にしてください。
また、元の文章は説明的に書かれていましたが、少し読みやすいように会話調に再構成しました。