エムスリーの機械学習チームのチームビルディング　“強い仲間”をいかにして集めるか？

機械学習チームビルディングの考え方

西場正浩氏（以下、西場）：エムスリーの西場です。よろしくお願いします。

今日は何話すかという話ですが、これは僕個人の考え方なので、明日には変わっているかもしれませんが、その辺は許してね。

はじめに、エムスリーのAIチームはML Engのチームでは無くて、Data EngとかSoftware Eng、プロダクトマネージャーや、エンジニアリングマネージャー、ML Engが所属しているチームです。明確な役割分担でやっているわけではなく、濃淡が違うだけで、Data EngをやりながらML Engやっていたり、Software Engの人がアルゴリズムを作っていたりします。

とは言っても、「ML Engの仕事ってどういうことやっているの？」ということで、こういうことを挙げています。

MLをやっているだけではなく、エンジニアがベースです。チームビルディングの話なので、チームの方向性の話をします。うちで目指しているのは「強い仲間を集めて価値の大きいプロダクト」を作りたいと。「年間数十億円規模の利益貢献を目指す」というのがチームのミッションになっているので、そもそもアウトプットありきの開発しか正直やりません。

僕は、そちらのほうが向いているんですが、「これは何に使えるの？」みたいな議論はあまりなく、そもそも最初からそのプロダクトを使うのが前提なので、「このサービスを改善しよう」、「そこでMLで、できるんじゃない？」みたいな話からスタートすることが多いです。

今日話すことなんですが、チームの初期における戦略について話したいと思います。軸としては、「強い仲間」というところと、「価値の大きいプロダクト」という2軸で話したいと思います。

「強い仲間」とは何か？

まず「強い仲間」です。強い仲間と言ったときには全方向の人たちを集めたいです。「強いって何？」ってところなんですけど、高い専門性や広い周辺知識、あとはエンジニアリング力ですね。実現力やオーナーシップ、みたいなことを高いレベルでやってくれる人がいいなぁ、と思っております。

そこに笹川というチームメンバーがいるんですが、彼はベンチプレスをやっていて、けっこう強いです。

（会場笑）

まずは、強い仲間を集めるというところです。僕は1人目だったんですが、3人、5人と集めていく上での戦略というか、考えていたことです。僕はML Engなんですが、立ち上げと同時というかそれより先ぐらいに「必要なのはデータエンジニアですよね」ということを社内で話していました。

チームの立ち上げと同時に探し始めて、運よく笹川が入ってくれたのでよかったです。

強い人が無名のチームに入ることって、普通はあんまりないと思うんですよね。だから「ちゃんと戦略考えてやっていきましょう！」という部分を意識しています。「強い人に入ってほしい」と言ったときに、まずは、強い人が働きたい環境ってどんなところなのかを考えました。

それを踏まえると、先ほどのクックパッドの原島さんの話がおもしろかったです。

「論文書けないんでしょ？」って言われても「書きました！」「もう書いてます！」みたいなところが「やっぱり自分が強くなる必要があるんだね」みたいな。強い人が働きたい環境を作るには、自分が強くなるのが大事だと思っています。

自分も強くなる必要があるので、仕事で結果を出すのは当然なんですが、外部への情報発信をよくやっています。僕、けっこう登壇をしたり、Twitterで発信したりしているのも強いアピールではないんですが、自分が間違ったことを言う可能性があるので、何か外に対してアウトプットを出すというのは、すごく責任のいる作業です。やはり自分へのプレッシャーにもなるし、登壇ドリブンで資料も作るので、基本的には同じネタを繰り返したくなくて、新しい論文のネタをどんどん発表できるようにがんばっています。

あとは、最近OSS化をやろうと思っていて、自分が今まで作ってきたものを、外に出していくことを考えてます。その結果、みなさんTwitterとかやっている人とかは知っていると思うんですけど、ばんくしさん。……言っちゃった。

（会場笑）

このアカウントの人がチームに入ります。本当にすごいうれしくて、すごい優秀な人なので勉強会とか企画していたら登壇依頼してあげてください。彼が年間12回発表するらしいので。

（会場笑）

3回分は、もう予約したらしい。laprasさんのマークがついているのはそういうことなんで、みなさんlapras使いましょう！

（会場笑）

マジでいいですよ！　……はい。

（会場笑）

さらに強い仲間を集めるには

次に、強い仲間を集めるということで、5人から15人ですね。

強い仲間を集めていくときに、強い人の密度を高めたり、チームとして強くする。先ほどReproさんの発表でも、「スクラムやって」とか、「チームとしての完成度」ということがありましたが、そういうところを目指さないといけません。

やっぱり価値を増やそうかなって思ったら、「強い人がいるから入りたい」というよりは、「強い人とおもしろいプロダクトを作りたい！」というところまでちゃんと持っていかなきゃいけないので、プロダクトをちゃんと真剣に考えています。

あと、もうすこし人数が多い場合はどんな状況なんだろうなと考えると、一人ひとりが独立にプロダクトを作るんですが、そのプロダクトが相互に依存するようなことを考えてやっています。

「価値の大きいプロダクト」とは何か？

「価値が大きなプロダクトってどういうことなんだろうね」と考えると、企画して開発して育てるしかないと思っています。

ですが、この普通のことって案外難しいですよね。実行できない理由はいろいろありますが、その辺をクリアしていって、ちゃんとこういうことを考えなければいけません。

最初のプロジェクトの選び方なんですが、小さく始めたり、成功させることがすごく大事です。

最初のプロジェクトの選び方は、うちは「振り返ってみたらうまくいった」って感じですね。どういうことをプロジェクトに選んだかは、「僕、センスがよかったな」ってだけなんですけど。

（会場笑）

データがあって、そこからルールベースのアルゴリズムがあって、それをDBに入れて、DBのデータをサービスが使ってます。これをここだけ置き換えてみました。「ルールベース……。勝てるでしょう」みたいな。普通だったら勝てる。でもルールベースでうまくいくということは、データから優位な結果を導くことは証明されます。そうしないとルールベースでうまくいかないから、それを最新のMLの技術を使ってやれば勝てるんじゃない？　みたいな。

これはすごい楽で、開発の幅がすごい狭いんですよね。たとえば、最初はデータエンジニアはいないんですが、いなくても作れます。なぜなら、アルゴリズムのコードを書き換えるだけだから。既存のサービスのやつを書き換えるだけなので、サービスに出るのは決定しています。すぐにABテストができます。ABテストがすぐにできて、ベンチマークがある状況でやると、そのままで始められます。

他社でうまくいっている例、僕はニュースのレコメンデーションを2年ぐらい前に作り始めたんですが、そのころってみんなやってますよね。みんなやっていてうまくいくことはわかっているので、成功確率は高いです。既存のフレームワークに乗っかるだけなので、工数も少ない。

2つ目以降のプロジェクトの選び方

1つ目のプロジェクトの選び方なんですが、僕がすごく意識しているのが、1をやったら、次は2をやって、3やって、4やって、5やって、みたいなことをすごい意識してやっています。

1をやった後に、1’みたいなことはやりません。これは何を表しているかというと、相互に依存させたり、疑似的に横のつながりがあったり、お互い相互依存して高まるとか、そういうことをすごく意識しています。

まず、小さく始めるってどういうことかというと、今は自動診断とかいろいろ流行っていますよね。たとえば「チャットやりながら自動で診断ついたらいいよね」みたいなことをAIでやりたいみたいな。そんなことがあった時に、「じゃあこれ作ろう！」ってなったらめっちゃリスク高いと思うんですよね。僕はたぶんやりません。

「やろう！」って、いきなりやるんじゃなくて、いかにリスクを小さくやって作っていくかが大事です。小さく始める例なんですが、たとえば自動診断がやりたければ、どういう技術が必要か。どういう機械学習の知見が必要かということを考えて、それをもっと小さいレベルで落とし込みます。

落とし込んだものを他のサービスで実際にプロダクトとして使います。それをやっていかないと、方向性は自動診断なんだけど、まずやることは自動診断をやるためにQ&Aサイトの改善をします。なぜQ&Aサイトなのかというと、自動診断ってQ&Aですよね。クエスチョンを投げて、アンサーが返ってくるだけだから。それの改善方法で、技術的なつながりは絶対です。

それをどんどん高めていくと、最終的にうまくいくんじゃないかと思います。相乗効果があるようなプロジェクトを順々にやっていくと、成功確率もあがるし、ROIも下がっていく。工数も下がっていくので利益も……。

将来的には、これだけでなく、いろいろなシステムを作っていて、それが相互に依存したり他のプロダクトの改善するようなものをうまく設計しています。

チームビルディングに必要な要素

ちょっとコラムだけで紹介したいと思います。

チームビルディングを今後みなさんがやっていこうと思ったときに、最初に必要なのが人事担当者です。人事担当者と仲良くなってください。というか優秀な人事がいる会社でやったほうがいいです。今日も、人事の友永さんが来てくれているんですが、僕がこの会社に入ったのは、友永さんが人事として素敵だったからです。一緒に協力してやってくれて、一緒にチームビルディングやってくれています。エンジニアだけだと人集めるのすごい大変なので……。lapraとか使ったらうまくいくかもしれないんですけど。

（会場笑）

やっぱりそれだけじゃ厳しいので、素敵な人事を探しましょう。他にもコラムをいろいろ書きました。

「不満は？」みたいなことは1on1で聞きません、みたいな。これはある方と、この前飲み会のときに話題になったので追記します。

では、駆け足になりましたがこれで終わりたいと思います。ありがとうございました。

（会場拍手）