BASEでData Strategyチームのマネージャーをしている鈴木僚です。
Data Strategyチームのミッションは、データを使ってプロダクトを成長させ、戦略的に事業を推進させることです。
EC事業では、オーナーズ（ショップオーナー）・購入者・社内メンバーの3者からなる膨大なデータが日々蓄積されています。Data Strategyチーム（以下、DSチーム）では、その3者に対して、より良い意思決定ができるよう機械学習を活用したソリューションを提供しています。例えば、直近ではオーナーズがより簡単にショップ運営ができたり、ショップと購入者のマッチングをより適切なものにしていくことに取り組んでおります。また、安心して購入者の方々にショッピングを楽しんでいただけるように商品の品質の自動チェックも始めております。
中長期的には、プロダクトだけでなく経営戦略、事業戦略など会社全体でデータを使った意思決定ができるようにすることを目指しています。
チーム設立から1年が過ぎ、組織としてのアウトプットも安定してきたため、今回はチームビルディングをどう進めてきたか、時系列順に共有したいと思います。
目次：
- Phase 0 チームを作る前にすべき事
- Phase 1 チーム発足、ミニマムスタートを最速で
- Phase 2 レコメンドモデル（ショップ教えるくん）リリース
- Phase 3 学習モデル作成とパーソナライズ
- Phase 4 マイクロサービスアーキテクチャと本格稼働
- Phase 5 属性情報を取得
- Phase 6 BASE BANK
Phase 0：チームを作る前にすべき事
まだ、自分一人しかいない状態。
周りのチームはもりもりビジネスを進めているので、焦りを感じます。この焦りをうち消すためにも、事業のゴールに対して現状・課題・理想をなるべく早く掌握する事がキーとなります。*1 *2
このフェーズで実施したのは以下の通りです。事業規模にもよりますが、心理的に2週間位で終わらせたいです。
このフェーズでやるべきこと：
- 現状のシステムを把握する（何がどこにあって、何をしている？）
- 組織のビジョンと、ゆるいロードマップを作る
- ビジョンに賛同してくれる人材の募集
チームメンバーの募集
チーム方針を決定したら、その方針に賛同してもらえそうなエンジニアを社内外から集めることになるかと思います。 データ戦略を司るチームを立ち上げるポイントとしては、以下の経験者がなるべく初期の段階で揃うことかと思ってます。
- ビジネスプランナー
- 機械学習エンジニア
- データアナリスト
また、マネージャーに求められる役割としては、このあたりが重要かと考えてます。
- ビジネスモデルとコストマネジメントはマネージャーが受け持つ
- 集中出来る環境：外部からの突発タスクはなるべくマネージャーが拾う
- 相談を自由にできる雰囲気づくり（メンバーからの相談を求めるだけではなく、相談しやすいチームメンバーの環境構築にもマネージャーの力量がかかってます。）
- 良い道具、良い開発環境、実力の発揮できる時間の提供
- 前処理がされた、質の良いデータの準備
- 得意なことは得意な人に任せる、任せられる雰囲気づくり
- 成長の機会の提供：論文・資料・勉強会・学会、input出来る機会は全力で応援する・すべき
Phase 1 : DSチーム発足、速度優先でミニマムスタート
社内のBI環境を構築したメンバーが加わり、過去の施策内容にグッと迫る事ができるようになりました。
準備運動なしに全力疾走すると足がつるのと同じように、ビジネス案件を実施する前に、必要最低限の環境を揃えます。とはいえ、組織として社内的信用は無なので、組織イメージが社内で固まる前にアピアランスを上げる努力が必要となります。すなわち、本番にデプロイできる何かを作る。どのような業務であっても過去に頓挫したタスクが存在するので、これらの中から優先して探します。なぜなら、以下のような事が事前に分かっているからです。
- 既にニーズの検証は行なっている
- 期待される効果もわかる
- なぜ止まったかもわかる
検討した結果、DSチームの最初のタスクは、アプリ内におけるおすすめショップのリコメンドに決定しました。前提の共有ですが、アプリとは、ネットショップ作成サービス「BASE」で開設された70万のショップがすべて集まるショッピングアプリです。それまでアプリ内の「おすすめショップ」は、ショップのキュレーションを担当する社内のメンバーがマンパワーでピックアップしていました。
ニーズ
- キュレーターによるレコメンドはキュレーターのセンスに左右される
- 担当キュレーターが休むと、レコメンドが止まる
期待される効果
- CTRが上がる→CVRも上がる→GMVに繋がる
なぜ止まったか
- 分析まで行ったが、実装する機械学習エンジニアがいなかった
このフェーズでやるべきこと：
- ミニマムスタート
- 必須の環境作り
- 前処理とログ取得がきちんとできる環境を作る
- 効果測定ができる環境を構築する
- 基本的な開発環境が整う
- チームのアピアランスを上げる
- 本番にデプロイできる何かを復活させる
これで、アウトプットを生み出す状況が整いました。
Phase 2：レコメンドモデル（ショップ教えるくん）リリース
既存の仕組みが存在する場合、担当チームとの意識合わせと共感が成功に結びつきます。 キュレーターが所属しているチームとレコメンドの目的や背景、そしてチームが持つ価値観の共有と共感した上で、既存のオペレーション内容と効果測定基準をヒアリングし、数値目標を定義しました。
この段階から徐々にキュレーターの業務内容に影響してきます。具体的には、冒頭に触れた3者向けのコンテンツ育成やブランディング等、より人と人とのコミュニケーションが重要となる業務が中心となっていき、全体を俯瞰する業務になってきます。一方、機械学習が活躍する分野の一つとしてパーソナライズがあり、その部分についてはDSチームが担当することとなりました。言うなればセンスと数字の分業と考えています。
実際、今後このような形で人間と機械（ロジック）がそれぞれ得意なタスクに分かれて業務が進行していくかと思います。とはいえ、一方で今まで人が担当していた部分なのでロジックを擬人化してみました。
その時の紹介文がこちら：
ショッピングアプリBASEのおすすめのショップ枠で修行させていただくことになった、『ショップ教えるくん』です！全アプリユーザーのお気に入り、フォロー、購入データから、あなたが好きそうなショップを考えて選びます！ まだ選んだショップをフォローしてくれて嬉しい！というポジティブな感情しかないので、選んだのに無視された、、などのネガティブな感情には対応できてませんし、24時間に1回しか勤務できませんが頑張るのでこれからよろしくお願いします。
結局、ショップおすすめ君とかおすすめショップ君とか名前をちゃんと覚えてもらえませんでしたが、ひとまず社内で何をやっているのかは周知できました。
このフェーズでやるべきこと：
- 本番環境の環境構築
- 最初は計算結果をバッチでDBに格納する
- DB・サーバーサイド・アプリケーションチームとの連携をしっかりと取る
- 実装と効果検証
導入した結果、タップ率は従来に比べ4倍以上に向上しました。
Phase 3：学習モデル作成とパーソナライズ
成功事案ができると、チーム的には、組織の仕組み チョットワカル の段階に入ったともいえます。ですが、急に前が開ける段階が来るまでは、類似手法で改善できる箇所を探しつつ、バッチ処理とサバイバルコードからの脱却を目指します。
また、それまでサービスドメインに適応した基礎データ、例えば単語辞書を作成していなかったので、このタイミングで整備するようにしました。
伸ばすとどこか歪むので見つける、治す
この頃からBatch処理におけるデータ転送量やDBへの負荷が高すぎて本番系に悪影響が出始めるようになってしまいました。また、似たような処理を行うインスタンスも増えてきました。
ここでメンバーが増えたので、バッチ処理を学習済モデルを用いてAPIで必要な時に都度計算する方式に置き換えてDBへの負荷を減らし、あわせておすすめ商品、関連商品など、複数のサジェストの実施できる環境を構築し始めました。
パーソナライズの開始
学習モデルの特性として、よりセグメント化されたデータの方が精度が良くなります。セグメントも含めて最初から推定する方法もありますがあまり精度は良くありません。それよりは一人一人におすすめ出来るパーソナライズという目的があるのであれば、各ユーザー様に直接確認するのが一番早い、ということで、アプリユーザーに対してチュートリアルの際に性別と興味のあるジャンルを伺うように変更しました。ありがたいことに、相当数の方に答えていただいているため、パーソナライズの基礎を構築することができました。
このフェーズでやるべき事：
- コードが本番に出た時に、問題が起こりそう、もしくは発生している時に、成果物自体が何を目指していたかを復習する
- 成果物は会社の利益になるか、数字で説明しようと思ったらできるようにしておく。即座に数字にする必要はない。逆に数字目標だけおうと、必ずサバイバルコードができて、後で倍苦労する
- サバイバルコードを廃止し、学習済モデルを使用する形に変更する
- レコメンドのロジック改善（学習モデルもパーソナライズ化）
- 効果測定結果の理論的な説明
このあたりで改めて機械学習チームにおける環境構築の経験と測定結果の正当性がきちんと把握できるメンバーが不足している事が改めて感じられたので、募集内容の変更を行いました。このように特にチームの規模が小さい段階ではチームの状況に応じて募集要項をこまめに変更することは重要だと考えていますし、実際に募集要項をこまめに変更している会社も多いように感じます。
Phase 4：マイクロサービスアーキテクチャ化と安定稼働
さらに新しいメンバーが増え、AWSのサーバレス環境へ完全移行しました。
また、Terraformを用いてインフラの構築、変更管理を安全にかつ効率的に行える仕組みを導入しました。Terraformは比較的最近リリースされたAWSコンポーネントにも対応しているため、新しい機能を追加する際もほぼほぼ問題ない状態です。*3
また完全移行したことによって、DS AWSと呼んでいる独自環境が誕生し、本番系環境とは基本APIを介してデータをやりとりするようになりました。このあたりはチームメンバーの氏原の記事が詳しいです。
それに伴い、データ周りも分析やモデル作成用途のものはDS AWSに保管するように変更し、大量データがあっても自分たちで負荷コントロールできるようになりました。 そこで、本番系では躊躇していた画像データの分析を開始し、関連商品のサジェストに画像とテキストの組み合わせたモデルを使用するようになりました。こちらによる回遊性は非常に効果が高かったです。
自分たちの責任で環境を何度も再構成できるということの恩恵に、発表されたばかりの論文やロジックの検証も手軽にできるようになりました。実際の例として、こちらの記事にあるようなモジュールをいち早く本番運用に適用することができました。
このフェーズでやる事：
- サーバレスへの完全移行
- インフラの整備
- 本番環境と分離I
- αやβのモジュールを採用する勇気
Phase 5：テキストや画像の属性の取得
パーソナライズが進んでくると、改めてクラスタリングを行いたくなってきます。そのためには属性情報が重要になってくるため、再び社内外からヒアリングを行います。
そして、いくつか肝となる属性が見えてきました。ハンドメイドと量産品の違い、商品の品質など、従来の画像やテキスト分析だけでは難しい属性です。そう行った情報を元に、ロードマップの先を伸ばす施策を考えるようになりました。企画と未来は尽きてしまってからでは事業的にもモチベーション的にもリカバリーが難しいので、随時更新・修正するフェーズを設けることによってハンドリングしています。
このフェーズでやる事：
- 属性用の学習モデルの作成
- 信用モデルに必要なパラメータの収集開始
- 企画と未来は尽きる前に補充する
Phase 6：BASE BANKと機械学習
属性情報を作成している段階で、ショップ単位で、月次決算を試算したいという話が出てきました。また、このタイミングで、データ分析を得意とするメンバーがチームに加わり、それにあわせて100%子会社のBASE BANK株式会社が本格的にサービスを立ち上げるという話が進行し、即効薬を求められるようになりました。
例えば定番？のDCF法（割引キャッシュフロー法）などを試してみました。
他にも試した手法の一つをチームメンバーの岡が記事にしています。
ここで作られたロジックは、BASE BANKが提供している、即時に資金調達ができる金融サービス「YELL BANK（エールバンク）」の調達可能金額の算出に現在用いています。
まとめ
今回は、駆け足でDSチームの１年間を振り返ってみました。チームが大きくなるにつれ、より多くのメンバーやビジネスシーンが関わり、スケール感が増してくるのを感じることができました。今現在も新たなPhaseが進行中です。
BASEでは一緒にネットショップ作成サービスを開発・改善するエンジニアを募集してます。 機械学習チームでは、様々なデータや技術を使ってECならではの開発を続けています。 ご興味のある方はぜひ遊びにきてください！！
