機械学習でプロダクト成長させる技術と組織を3社のMLエンジニアが語る - note/コネヒト/Wantedly
MLエンジニアがプロダクトをグロースさせるためには、機械学習の知識はもちろんのこと、その他にも考えなければならないことが多々あります。アーキテクチャの刷新や組織での立ち回り、採用の強化など各方面の働きかけが必要になるでしょう。
各社でどんなアーキテクチャなのか？
短期で価値をデリバリーするための工夫は？
採用はどうしてる？MLエンジニアは市場にいる？
MLエンジニアに求められる能力は？
これらの悩みに対して、note・コネヒト・Wantedlyの3社のMLエンジニアが現場での工夫や苦労について語りました。
※ 本記事はオフラインイベント「機械学習×プロダクト成長 - 3社が語る技術と組織 ~ note/コネヒト/wantedly」の文字起こしです
3社のMLアーキテクチャのメリット、デメリット
新卒でデータサイエンティストとして入社し、PoCを中心にレコメンド、Bandit、因果推論などに取り組む。同社でPdMを経験し、noteではML/検索周辺機能のプロダクトマネージメントを担当。Kaggle Expert。
— 本日は会場に来ていただきありがとうございます。note株式会社 PMの小沼です。司会を担当させていただきます。
ではまず初めに各社のアーキテクチャを紹介をしていきましょう。まずはnote社からお願いします。
安井 (note)
noteの機械学習チームでMLエンジニアをしている安井です。note社は「誰もが創作をはじめ、続けられるようにする」をミッションに掲げ、メディアプラットフォームnoteと法人向けのnote proを展開しています。
私は2019年にnoteに入社し、クリエイターの創作物を適切なユーザーに届ける仕組みづくりを機械学習を用いて行ってきました。
安井 (note)
アーキテクチャの説明の前に、noteで機械学習を利用している一例として『こちらもおすすめ』について紹介します。記事下にでてくる関連記事ですね。
noteでは「記事を探す」という能動的な行動よりも、「記事と出会う」という受動的な体験を重視しています。ユーザーが適切な記事と出会うためのレコメンデーション開発を続けているんです。
私が書いた「noteの機械学習フローを共通化してレコメンデーションで成果をあげた話」の記事下を見ると（画像右）、文章に近い内容のものが表示されているのがわかるかと思います。関連記事とユーザーが最近見ていた記事を合わせて推薦しています。
安井 (note)
では、続いてアーキテクチャについてです。機械学習を使ったレコメンデーションでは、基本的にバッチ推論を使っています。AWS Glueでデータをフェッチして前処理をし、Amazon SageMaker（以下、SageMaker）のトレーニングジョブを使ってモデル学習をしています。
学習したモデルをSageMaker Batch Transformを使って推論して結果をSQSに入れて、最終的にDynamoDBで保持しています。機械学習を利用しないレコメンデーションのデータはRDBに入れている状態です。
SageMakerの部分はPythonで書かれているんですけど、一部のAPIは昔の名残でRuby / Railsで書かれていますね。ここは改善していきたい点です。
— サービスごとのつなぎとしてはDynamoDBを見にいく仕組みですか？
安井 (note)
そうです。APIなどで連携しているわけではなく、DynamoDBを見てくださいって感じで今は提供しています。
野澤(コネヒト)
LambdaとLambdaの間にSQSを挟んでいるのはなんででしょう？
安井 (note)
昔の名残ですね。私が入社する前から存在しているアーキテクチャなので、SQSが入っていたりするんですよね。
野澤(コネヒト)
なるほど、歴史が詰まったアーキテクチャって感じですね（笑）
2019年7月にnote株式会社に入社。クリエイターがアップロードした記事、創作物を自動的に適切なユーザに届ける仕組みづくりを機械学習を用いて行っている。Kaggle Expert。
— では続けてコネヒトさんのアーキテクチャ紹介をお願いします
野澤(コネヒト)
こんばんは、コネヒト株式会社でMLエンジニアをしている野澤です。最近ではPdM的な動きもしていて、機械学習のサービス導入なども行っています。
本題に入る前に会場のみなさまにお聞きしたいのですが、『コネヒト』って聞いたことある方っていますか？
〜〜手が挙がる〜〜
ありがとうございます、会場の3〜4割くらいでしょうか。予想通りです（笑）
登壇している2社と比較するとまだ知名度は高くはないので、今日の反応を見てより頑張ろうと思いました。
野澤(コネヒト)
そんなコネヒトではビジョンとして「あなたの家族像が実現できる社会をつくる」を掲げています。妊活や妊娠、子育てなどの疑問や悩みを解決するQ＆Aサービス『ママリ』など、家族にまつわるサービスをいくつか展開しています。
弊社でのML活用は大きく分けて『コミュニティ検閲』『カテゴリ類推』『レコメンデーション』の3つに分類されます。
野澤(コネヒト)
では、まずコミュニティ検閲について説明します。
Q＆Aサービスであるママリは月間130万件ほど投稿があり、誰かが投稿を四六時中している状態です。
ガイドライン違反がないか投稿を目視で確認していたのですが、人間の目だけでは運用コストが高くなってしまいます。そのため、事前に機械学習の検閲モデルを挟むようにしました。現在では機械学習で不適切と判断された投稿のみを人間がチェックする体制になっています。
野澤(コネヒト)
次はカテゴリ類推です。
ママリでは質問を投稿するときに「妊娠」「お金」などのカテゴリを手動で選んでもらっていたのですが、その選択部分で一定の人が離脱していることがデータからわかりました。そこで、このカテゴリをユーザーの入力文章から類推する機械学習モデルを用いたところ、かなりの離脱を防ぐことができるようになりました。
このようなユーザーのinputから何かをサジェストするといった機械学習モデルは、多くの企業でも行っていることだとは思うのですが、コネヒトにおいても投稿の離脱率を下げる大事な施策となりました。
— 会場から質問が来ています。「カテゴリ類推の施策において、MLエンジニアはどのタイミングから関わっていたのでしょうか？」
野澤(コネヒト)
タイミングなどはなく、最初から関わっていました。投稿のデータを見ていたときに、カテゴリ選択で離脱率が高いことに気づいたのですぐにPMに提案しました。そのあとにモデルを構築して、Androidエンジニアに爆速でモックを作ってもらって進めていった形ですね。
この施策に取り組んだ際は、まだ社内で機械学習を用いたソリューションがほぼない状況でした。そのため、「成功角度が高そう」かつ「サービスにとって影響が大きい」の掛け算で優先度を決めたときに、ここはすぐにやるべきだなと。
— MLエンジニアが素早くプロダクトアウトまで持っていくことができるの素晴らしいですね
野澤(コネヒト)
全部の施策が素早くできているわけではないですが（笑）
組織に対してMLエンジニアの人数が少ないことも多いですし、1人でリリースまで持っていける力は重要かなと思っています。
野澤(コネヒト)
最後はレコメンデーションですね。ユーザーのログや属性情報を使って、ユーザーが興味ありそうなアイテムを推薦します。ママリでは質問や記事のレコメンドに活用しています。
野澤(コネヒト)
アーキテクチャはnoteさんと似ている箇所が多いかもしれません。弊社でもSageMakerやDynamoDBを利用しています。
機械学習ジョブの実行体としてはSageMakerのProcessingジョブを使っています。
また、データの抽出からモデル構築までをスクリプトに落とし込んで、AWS Step Functionsでパイプラインを構築しています。レコメンデーションにおいてはバッチ推論を行い、最終的にはDynamoDBにアイテムを入れ、そこのデータをAPI経由でユーザーに推薦する形ですね。
— ローカルとインスタンスで行う分析だと差分が起きませんか？
野澤(コネヒト)
分析する際のnotebook環境もコンテナ化しており、ローカルとクラウド上（SageMaker）で環境差分が生まれない様な工夫もしています。
ML Engineer, ML PdMとして、機械学習のサービス導入を軸に、機械学習基盤や機械学習モデル、APIの開発を行う。
— では、最後にWantedlyさんのアーキテクチャ紹介をお願いします。
合田 (Wantedly)
Wantedlyでデータサイエンス領域のテックリードを担当している合田です。Wantedlyには3年前に入社して、そこからWantedly Visitというプロダクトの推薦システムの開発に携わっています。
合田 (Wantedly)
私たちWantedlyは「シゴトでココロオドル人をふやす」をミッションとして活動しています。人によって受け取り方が変わる言葉に見えますが、漠然とした感情論ではありません。会社や企業の中で没頭して成果をだすことで、成長実感が得られるようなサイクルがココロオドル状態だと定義しています。
ミッションを達成するために提供しているのがWantedly Visitです。ローンチから10年ほど経っており、カジュアル面談という文化を形成してきたプロダクトと言えます。
Wantedlyは企業とユーザーのマッチングサービスなので、ユーザーがココロオドルことができる会社に出会えるようマッチングの体験を磨き上げる必要があります。ですので、弊社では推薦システムの開発に力を入れています。
「なぜ我々が推薦システムに力を入れているか？」をブログに書いて言語化したので、よかったらご覧いただけるとありがたいです。
合田 (Wantedly)
仕事を探すときの嗜好というのは複雑でありユーザー自身も正確に把握するのが難しいものだと我々は考えています。機械学習を使って、ユーザーの行動やプロフィールなどの多種多様なデータをもとにユーザーの嗜好を捉えて、ユーザーが魅力的に感じるであろう会社・仕事を推薦できるようにしています。
ここ最近は、ユーザー側の嗜好を捉えるだけではなく、企業側の嗜好も取り入れることで人と会社の両想いを実現する仕組みを作ることにフォーカスしています。これはReciprocal Recommender Systems（相互推薦システム）と言われている分野であり、ユーザーにとって魅力的で、かつ会社側もユーザーのことが魅力的に思っているような募集が推薦されることを理想形として、その実現に向けて頑張っています。
合田 (Wantedly)
アーキテクチャは2社とかなり違っていて特殊です。データはBigQueryで管理しているのですが、EKSをベースとして推薦システムの開発を始めたので、基本的にはEKS上でなにもかもやる形になります。学習推論のバッチ処理や開発時では、EKSでPodを立ててその中で機械学習モデルを動かしています。
— なるほど、たしかに2社とは違いますね
合田 (Wantedly)
Podでの開発は良い面もあり悪い面もあります。本番環境と開発環境を一致させることが容易である一方で、開発効率が下がるケースもあります。例えばPodが消えて開発時の出力結果が消えてしまったり、結果を再現するにもPodを立ち上げ直さないといけなかったりするので大変です。
もちろん現状の形で満足しているわけではなく、SageMakerといったマネージドサービスの検討など、より良い開発者体験を模索していたりします。
ウォンテッドリー株式会社にて、データサイエンス領域のテックリードを担当。会社訪問サービス Wantedly Visit のマッチング部分を担う推薦システムの開発を推進。Kaggle Master。
短期でリリースするための工夫と仕組み化
— ML関連の機能リリースは様々な人が関わるので時間がかかりがちかなと考えています。短期間でデリバリーを届けるための工夫は各社されているのでしょうか？
合田 (Wantedly)
デプロイが早くできる工夫をしていますね。yamlに記述するだけで推薦APIの挙動が変更できるようになっていて、データサイエンティストだけで簡単かつ高速にデプロイ作業ができるようになっています。Recommendation schemaと呼んでいる弊社の機能で、ランキングリリース用のインターフェースとして開発されました。
合田 (Wantedly)
「どのユーザーに、どの条件で、どういうランキングを出す」みたいな条件分岐をyamlで書くことができて、ABテストやインターリービングといったオンラインテスト形式も簡単に実行することができます。
野澤(コネヒト)
Recommendation schemaのことについてちょっと聞いてみたいんですけど、(画像右の)nameにモデル名を入れてABテストするかどうかを決めるイメージでしょうか？
合田 (Wantedly)
そうです。ランキングって様々な条件分岐を組み合わせたツリー構造のようになっていて、その子ノードの中の条件を書き換えるようなイメージです。
野澤(コネヒト)
なるほど、便利ですね。
— テスト手法のシステム化などは、サボりがちになりそうな部分ですよね
合田 (Wantedly)
弊社の場合はRecommendation schemaが開発される前は、バックエンドエンジニアとデータサイエンティストで相互にコミュニケーションをとる必要があったため、デプロイに1〜2日かかるときもありました。お互いに同じ言葉を言っているけど実はそれぞれ違う意味で使っているみたいなミスコミュニケーションが起きる場面もあったり。
コミュニケーションを密にとらなくても、データサイエンティストが思い浮かべている構成をちゃんとデプロイできるように自動生成ツールを作ったというのが経緯です。Recommendation schemaのおかげで、デプロイは15〜30分ほどでできるようになりました。
安井 (note)
たしかにMLエンジニアとバックエンドエンジニアで前提知識が違って、ズレがでてしまうときはありますね。noteだとMLエンジニアがバックエンド開発もパワーでやってしまうことがあるので、仕組みで解決できるのはいいなと思いました。
野澤(コネヒト)
Wantedlyさんと若干似たような点でいうと、項目を埋めていくとABテストができるテンプレを弊社も用意しています。メトリクスを決めてネクストアクションを指定するみたいな形で。テンプレを利用することでPDCAのサイクルを早めています。
— noteでは短期でデリバリーするための工夫はなにかしていますか？
安井 (note)
共通化はかなり工夫した部分です。技術スタックをできるだけ薄くして、可能な限りシンプルな構成を目指しています。SageMakerのようにマネージドサービスに任せられる部分はどんどん取り入れていますね。
私が入社した当時は、SQSでデータをRails側に渡してRDSに保存するようなアーキテクチャで、ML開発をするためにバックエンドも開発しなければいけないみたいな状態でした。このあたりもここ数年でかなり改善して、ML側のみで開発ができるようになりつつあります。
野澤(コネヒト)
マネージドサービスを使って運用コストを極力減らすのは大事ですよね。自分たちで運用しようとすると時間を取られてしまうので、我々も使えるものは極力使っていく方針です。
合田 (Wantedly)
開発の効率化は、いかに試行錯誤を重ねられるかがモチベーションとなっているのかと思っています。1回出したら終わりではなく、何回か出して調べながら改善を重ねていくのが大事かなと。「僕たちの中に答えはない」という言葉が好きなんですよね。自分たちで長時間議論していても答えが出ることはなくて、ユーザーへの問い合わせから一歩ずつ答えに進めていかないとうまくいかないかなって。
— 大事なマインドですね。答えがないのに議論を重ねてしまうことも多いですからね。早く試そうと思ってもなかなか動けなかったり。
安井 (note)
あとは、機械学習で本当に開発する必要があるかどうかは議論したい部分ですね。私が入社した当時にはすでにレコメンデーションの仕組みがあったのですが、中身を見てみると機械学習以外の部分で改善できそうな部分が多々ありましたね。
合田 (Wantedly)
大事な観点ですね。Wantedlyでは推薦改善を得意としているチームとUI/UX改善を得意としているチームがあって、それぞれで課題を見つけた後「それはUI改善でやった方がいい」「それは推薦でやった方がいい」といったソリューションの検討や課題の対応依頼などを行ったりします。自分たちで不得意なことをできるチームがそばにいてくれるおかげで、自信を持って幅広い選択肢から適切なアプローチを選ぶことができるようになっていると思います。
採用は疲弊する。内部のコミュニケーション強化も大事
— コネヒトさんは「MLエンジニアの人数が少ない」という話を途中でしていましたが、チーム人数は増えているんですか？
野澤(コネヒト)
増えてはいないですね、今はMLエンジニアは2名います。人を増やして責務を狭くしていきたいという意志はないのですが、器用貧乏になってしまいがちな部分はありますね。なので尖った専門性のある人が来てくれるとうれしいなって気持ちはあります。
安井 (note)
器用貧乏はわかりますね。去年はインフラの定義とかAWS CDKにめちゃくちゃ詳しくなりました。
— 1人MLエンジニアの状況って他社でも多そうですね。MLエンジニアの採用って難しいと思うのですが、各社なにか工夫はされていますか？
野澤(コネヒト)
採用はどこも苦戦していそうですよね。そもそも今の採用市場自体が辛い戦いだなとは思っています。言葉を選ばずに言えば、採用をがんばった人が疲弊していく状況だなと。アウトプットを続けて企業の認知が取れていったとしても、それが採用につながらないことは全然あるんですよね。頑張っても成果にならない。
合田 (Wantedly)
僕は採用に割と時間を使っているんですが、時間をかけて採用活動をやっていく覚悟は必要かなと思っています。スカウトだけでなく、ブログ記事を書いたり登壇したり、社外にWantedlyの機械学習活用について知ってもらえるような活動をしてたりします。
野澤(コネヒト)
弊社も継続的なアウトプットは意識的にやっていて、興味を持って来てくれる人はいるのですが、やっぱり面接から採用まで持っていくのはかなり難しいなと感じていますね。
安井 (note)
noteの今のフェーズでは、外部から人を入れるよりも社内で仲間を増やしていくみたいな方向性が合っているのかなと思っています。コンテンツを運営しているチームとデータ集めをしたり、機械学習で検知すべきものとそうではない定義を一緒につくったり、一緒にML開発をやっていくのが大事かなと。機械学習だとできるアプローチを知ってもらうために長く連携をとっていきたいと思っています。
合田 (Wantedly)
そうですね、社内のメンバーのデータサイエンス力を高めていき、チームのパフォーマンスを上げていくことは非常に大事ですね。そうした中でやっぱりプロダクトに関わるドメイン知識が重要だと考えます。
いかに早く施策をイテレイティブに回せているか、そして施策をやったままで閉じず丁寧な考察や振り返りを施策毎に実施することによって、メンバーのプロダクトについて考える力を培っていけるし、チームが持つ知見もどんどん増やしていけると考えています。このようなことを意識してチームを引っ張っていくことで、チームもプロダクトも成長していけるかなと思っています。
MLエンジニアに求められるスキルとは？
— 最後になりますが、会場から質問が来ています。「3社ともバックエンドの開発なども行っており、知識が幅広く求められるように感じました。MLエンジニアのスキルとして何が重要だと思いますか？」とのことです。どうでしょうか？
合田 (Wantedly)
うーん、難しいですね。個人的には「機械学習のスキル」は、勿論一定のラインが求められるものだと思いますが、最重要とは思っていません。仕事を達成するのに必要なものってコミュニケーション能力だったり、論理的思考力だったり、仮説検証をこなせる力だったり、そういった点の方が重要なのかなって。
野澤(コネヒト)
分かります。やっぱりコミュニケーションをとれることは大事かなと。
弊社だとPdMやBizチームとコミュニケーションをとる必要がありますし、バックエンドエンジニアと連携して調整する必要もあります。調整は時間がかかる仕事なので、一歩ずつでもいいから前に進めていけるマインドを持っている人は活躍できると思います。なにくそ魂みたいな気持ちですね（笑）
安井 (note)
私自身のスキルとして機械学習モデルを作ったり、課題解決に取り組んだり、バックエンド開発をやったりと現在はしていますが、最初から全部できていたわけではありません。仕事を進めていく上で、「自分に何が足りないのか」を考えつつ、そのタイミングで学べたことが大きかったかと思います。
— MLエンジニアって市場に少なくて、社内でも割合が少ないですよね。そうなるとやるべきことが多いので、必要に迫られる技術は多くなるのかなって。それに耐えられる思考を持つのが大事なのかなと3人の話を聞いていて思いました。
安井 (note)
活躍しているエンジニアを思い浮かべたときに、スキルを持っていなくてもキャッチアップして解決していく人が多いのかなと思っています。課題を見つけて考え続けるっていうのは、MLエンジニアに限らずスタンスとして重要なのかなと。
— 職種に限らず大事な考えですね。ありがとうございます。本日のイベントは以上になります。ありがとうございました。
▼note社の技術記事をさらに読みたい方はこちら
▼コネヒトの機械学習開発に興味がある方はこちら
▼Wantedlyの機械学習開発に興味がある方はこちら