はじめまして。Wantedly VisitのMatching Squadの推薦基盤チームの一條です。普段はData EngineeringやMLOpsに取り組んでいます。

Wantedlyではユーザーと企業のマッチングをより良いものにするために募集やスカウトでのユーザー検索を日々改善しています。

しかし、改善が進むにつれてリリースフローのコミュニケーションコストや実装コストが目立つようになってきました。その問題についてにどういった取り組みをしたかについて書いていこうと思います。

元々のリリースフロー

基本的にWantedly Visitの募集とスカウトの検索はGoで書かれているマイクロサービス（以後visit-recommendation-XXXと表記）で行われます。Wantedlyでは基本的にRubyを使いサービスを実装していますが、ここでは複雑な検索を高速にするため並行なコードが簡単に書けるGoを使っています。

このマイクロサービスは利用するデータが巨大でかつ速度面の要求も強いことから、ソートに使うロジックへの制約として

• リクエスト時ではなく、定期実行でそれぞれのアイテムへスコア付け（=> ランキングを作成）する必要がある
• リクエスト時にはリクエストパラメータを元に特定のランキングを選択しそれでソートする、もしくはランキング同士は簡単な命令（interleaving, 連結, スコアの足し合わせ）を行いその結果でソートする、といったことのみが基本的にでき、それ以外のことをする場合は推薦基盤チームに相談してもらう

といった制約を入れています。

推薦基盤チームから見える、具体的なリリースまでのフローとしては次のようになります。

1. 改善用のスコアリングロジックを作成する
2. 作成したロジックを元にスコア付けした結果をBigQueryに保存する
3. BigQueryに保存されたデータを、visit-recommendation-XXXへ同期
4. 同期されたデータを利用する変更をデプロイ

というフローになっており、1と2はデータサイエンティストが、3と4に関しては基盤チームが行う、という形になっています。

余談ですが、ここでBigQueryにスコア付けした結果の保存とvisit-recommendation-XXXへの同期をタイミング良く行う必要があります。またスコア付に関してはPythonで書かれる機会が多いです。そのため言語を超えた依存関係の記述にArgoを利用しています。Argoについては、 同僚の@unbleeが書いた記事があるのでそちらをご覧ください。

リリースフローのボトルネック

ここでは主に次のような課題がありました。

1. チームメンバーが複数人いるが、それぞれ話す単語の意味が異なり、コミュニケーションロスが発生していた例: 「フォールバック」が通信エラーなどが発生したときなどにどうするか、という意味と単純に登録直後でパーソナライズするためのデータがないユーザーに対してどういう順序で並び替えるかという意味の2つが登場
   例: 「ランキングを混ぜる」がinterleavingを指す場合と、単にランキングAの後ろにランキングBをつけるなど
2. 境界を明確に設けていなかったため、データサイエンティストと僕がある程度お互いのコードを理解している必要があった
3. リリースにデータサイエンティストと基盤側のエンジニアの2人を確保する必要がある

これらを解決するために次を行いました。

• リリースフロー用のインターフェース作成
• インターフェースへ入力した情報からの自動生成

この2つについて説明していきます。

リリースフロー用のインターフェース作成

まず小さく改善を進めて行くために次のようなことをデータサイエンティストにお願いしました。

ここでの目的はある程度推薦基盤チームの知りたい情報を集約し、これが適切な境界かを確認していきました。
次に、これらを導入した後でも日本語での補足が多く、十分でないことがわかったため、visit-recommendation-XXXの実装内で利用されているその複雑な箇所にあたる用語をチーム内のMTGやissueなどに混ぜていき、データサイエンティストが自分から利用するかを確認していました。目的としては、データサイエンティストにとっても有益かを判断するために用いました。
その後、導入した単語を元に同じイメージを元に会話ができるよう、図などを用いて感覚をあわせていく、といったことを行いました。ここのステップは適宜フィードバックをもらい修正したり、利用頻度の低い単語をマージする、ということを行います。

インターフェースへ入力した情報からの自動生成

ある程度やり取りに必要な情報や、単語の確認、考えなどはインターフェース作成の部分でわかったので、残りは自動生成を進めていきます。
自動生成で解決したい課題としては次です。

• 自動生成することで、定義している概念外のことをコード内に埋め込んでしまわないようにする
• トイルをなくすことで、精神面の安定や他のより効果的な問題の解決を行えるようにする

ただ、ここで重要な点として全てを自動生成する、ということは行わず「8割ほどの部分をカバーする」という方針で実装していくことにしました。これは2割部分が今後も使っていくかわからず、実装コストも高く、また適宜変わる部分だと判断し、その部分に関してはインターフェースだけ提供し、自動生成は行わないようにしました。またどこが2割の部分かは意識しても仕方ないので、データサイエンティストから見ると人間が書くか、自動生成されるかは意識しなくて良い状態が実現しています。

という方針を決めると、残りは当時インターンに来てくれていた [@nosukeru](https://github.com/nosukeru) くんに任せたら爆速で1週間ほどでやってくれました。
基本的に取り組んだものとしては次です。

• 既存コードを自動生成しやすい形への分割
• 人の手が必要な箇所の未実装に気づくために、未実装箇所があった際にコンパイルエラーになる形での自動生成
• 基本的に、コードを変更していく際に現状のフローではスコアリングを組み合わせる際はDAGを形成することと同義、ということが見えたのでその形へ変更

自動生成に必要なタスクとその依存関係はこのようになっています。ここで重要なのは前ステップで定義した用語を使ってタスクを記述してます。

実際に改善した結果

次のようなyamlに今までのコミュニケーションを凝縮し記述することにしました。

- name: Ranking
  type: mix
  children:
  - RankingA
  - RankingB
  
- name: RankingA
  type: leaf
 
- name: RankingB
  type: leaf
...

- name: RankingA
  query: |
    SELECT
      [] AS keys,
      ARRAY_AGG(project_id) AS ids,
      ARRAY_AGG(score) AS scores
  table: visit.rankingA
  repository: visit-rankingA
  command: python job.py
- name: RankingB
...

上のファイルはランキングの構造をDAGで記述したもので、データサイエンティストが出してほしいやり方を書いています。下のファイルはデータ同期の方法や形式について記述しています。これらの詳細については別の記事で書こうと思います。

この改善によりデプロイするまでの時間は1時間程度まで短縮され、またチーム内でストレスのかかっていたコミュニケーションコストもyamlをPRで出すだけでほとんど完結し、コミュニケーションコストはかなり減りました。
また、過去のリリースについても、gitに全て残っているためいつでも遡れ、議論もプルリクエストベースで行うためどういう意思決定がリリースの際にあったのかも簡単に遡れるようになりました。

また、副次的な効果としては、データサイエンティストとのインターフェースが正しく切れていることにより、スケーラビリティを上げる、といったプロジェクトに関しても、データサイエンティストとのやり取りをあまり必要とせず進めることができました。

また、海外は特有の事情で日本と同じようなロジックではなく、海外チームで行っていますが、その際も基盤チームのリソースがほぼ一切かからず、独自にデプロイをする、ということができるようになりました。

まとめ

正しくインターフェースを切ることで、ここまで業務を高速化することができ、更には自動化までが行えるのは想定していた以上の絶大な効果が得られたのではないかと思います。
また、このプロジェクトは自分のサイドタスクとして進めていましたが、この絶大な効果を見るにもっと早くこのプロジェクトに取り組むべきだったな、というのが反省としてあります。効果としてはこれによりコミュニケーションや実装に割いてたコストが破壊的に減ったからです。

もし、こういったことに興味があればカジュアルに話を聞きに来てもらえると嬉しいです。