メルペイ、エムスリー、Preferred Networksの3社が登壇
藤倉成太氏（以下、藤倉）：藤倉：では、さっそく始めていきたいと思うのですが、パネルディスカッション、全体で時間としては30分程度を予定しています。
谷脇大輔氏（以下、谷脇）：Preferred Networksの谷脇です。よろしくお願いします。
（会場拍手）
竹原一彰氏（以下、竹原）：メルペイの竹原と申します。先ほど発表させていただきましたとおり、私はメルペイのMachine Learningチームのエンジニアリングマネージャーをやっております。会場からも質問とか受け付けるタイミングがあったら「どういうことやってるの？」など、気楽に聞いていただけるとうれしいです。よろしくお願いします。
（会場拍手）
西場正浩氏（以下、西場）：エムスリーの西場です。よろしくお願いします。ここにいるメンバーは懇親会もたぶんいるので、みんな話しかけてください。あと、先ほど求人票、各社の求人票をツイートしておいたので。
藤倉：ありがとうございます。
西場：リツイートしておきましょう。
（会場拍手）
藤倉：では、みなさんよろしくお願いします。ここからさっそくパネルディスカッションに入っていきたいと思うのですが、まずは一番最初に、ここに今お三方前に並んでいらっしゃる方々や会社さんは、機械学習系のアプローチをきちんと事業に対してかたちにできている成功パターンに近い企業だと思うんですね。
なので、まずビジネスサイドのステークホルダーがいるのかを含めて、これまでどう事業化に結び付けてきたのかという成功体験みたいなものを、少し各社さんの中でどんなふうにやっているのかを紹介いただきたいなと思っています。
マシンラーニングエンジニアから「ビジネスのコアが何か」を提案する
谷脇：Preferred Networksの場合は、まずいろんな企業の方と研究を行って、それで一定の成果が出た場合、その企業と一緒にそれをどうやって事業化していこうかというかたちで、その次のフェーズに入るかを検討していきます。
企業の方とそうやって研究成果を先に握っていることで、このあとのプロダクト開発の予算や費用のあたりを担保することができて、そのまま開発を順調に続けることができています。
藤倉：じゃあまずザザッと聞いてみていいですか？
竹原：メルペイは先ほどのプレゼンで話した内容が多かったんですけど、ちょっと違ったところをお伝えしようかなと思います。まずメルペイは幸運なことに始まったタイミングでデータプラットフォームとかデータを溜める組織が組閣されていたんですね。なのでサービス開始時からデータが溜まるようになっていて、あとは活用するシナリオがスムーズに始まりました。
気を付けていることは「ビジネスのコアって何だろう」みたいなことを見極めて提案するのはマシンラーニングエンジニアからというのをすごい意識しています。
いろいろな方から「これやりたいんだよね」という質問やお問い合わせがあるんですけど、「できそうだな」と思っても、それをそのままやることはあまりなく、マシンラーニングエンジニアが課題を咀嚼して、ソリューションのインパクトを見極めてから提案するというのを意識的にやっています。それがプロダクトにつなげるポイントかなと思っています。
西場：エムスリーでは最初からR＆Dみたいなかたちでなくてプロダクトから作るところからチームがスタートしているんですけど、やはり大事なのは僕は最初MLの素人で3年ぐらい前から始めているので、そのときにやったのがルールベースで勝てるか、分析をしっかりすることでした。
それをやると、すんなり導入に入って「じゃあアルゴリズムを見れるといいよね」という話になってそこからがんばるとか、既存のサービスでMLエンジニアとか関係なしにいろんな人がデータ分析をしてルールベースの何かが入っているんだったら、そのルールベースをさらに展開するみたいなことをしています。ニュースのレコメンドだったら、地域性や所属企業の話は絶対に興味があるとわかってるじゃないですか。
よく論文とかブログでも書かれるものを、ルールがあるんだったらそれをいかに横展開するかを必死になって考えると、すんなりとプロダクトに入っていけるかなと思います。
ビジネス課題と技術をどう融合させるか
藤倉：今お話いただいた各社さんの中で、例えば典型的なところで言うとPreferred Networksさんは研究開発が先にあって事業化をあとからアラインさせていくパターンじゃないですか。もしかしてメルペイさんはビジネスありきでそれを実現できる方法はありますか？ という発想をしているのかもしれないですけど、どちらにも一長一短あるじゃないですか。
そこでの自社としてのポリシーだったり、それはケースバイケースなのか、そういう考え方の特徴みたいなものはあるんですか？
竹原：マシンラーニングエンジニアは新しい物好きの集まりなんですよね。放っておくと勝手に出口の見いだせないR＆Dに取り組んでいて、プロダクトに活かせない……みたいなことをやっちゃうこともあるんですよね。だからいくつか縛りを、チームで話し合って決めました。1年、長くても3年以内に着手しそうな技術のみをリサーチ対象にするとか、ビジネス課題はあるけど、今の技術では解決できないものに絞るとか。
具体的には、モデルがなぜその判断をしたのかの解釈性の問題とか、そもそも使ってはいけないデータ、使えないデータはまだまだたくさんあるんですけど、プライバシーを保護した上でどういう方法であれば利用できるのかとか、そのへんの研究テーマはウォッチしたり、ちゃんとやるようにはしています。
藤倉：Preferred Networksさんは研究開発が先にあって事業化の道が「やばい、見つかんねぇ」みたいなことは起こりえるんですか？
谷脇：そもそも共同研究を始める相手が大きな企業が多いので、彼らにはやりたいことがあるんですよね。彼らのやりたいことを一緒に研究するところから始めることが多いので、闇雲にいろんなことをやっているわけではないです。
藤倉：頭の片隅には、まず事業化みたいな構想があっての話になっていると。
谷脇：そうですね。
クライアントの問題設定では解けない場合、どうしているか
竹原：Preferred Networksさんに質問します。クライアント企業から依頼を受けて研究開発をする場合に、よく聞くマシンラーニングが難しい場合として、そもそもクライアントさんが問題設定をしてしまって「こう解いてくれ」みたいな、その問題設定では解けない状態で渡されることをよく聞くんですけど、そういった場合があるのかとか、そういった場合どうしているのか、教えていただけますか？
谷脇：そうならないように我々プロダクト開発チームがわりと早い段階で入って、事業化やプロダクトとしてスケールさせるために「こういう観点を持ったほうがいいんじゃないか」というところをアドバイスしながらやっている感じですね。
藤倉：エムスリーさんも先ほどのお話で、ルールベースでも何でも使えるものがないかというアプローチだと、わりと地に足ついたというか初期のかたちはわりと固まって、あとはそれの精度なり拡張性をどうするかという議論になっていく感じなんですか？
西場：そうですね。例えば先ほど話してた大垣さんは10月入社なんですよね。それでもう1個のプロダクトに出てお客さんとやっているやつなんですけど、もう値段も付いて売れているという……。
藤倉：すごい。
西場：それってけっこう早いじゃないですか。めっちゃ地に足ついてるなと思っています。これからはちょっとしたムーンショットをしたいですね。
（会場笑）
という気持ちもあるんですけど、チームとしてまだまだ地に足ついた通りにやれることはいっぱいあって、そこに技術が溜まってきたら、さらにすごいことをやっていこうかなと思ってますけど、まずは今は目の前のできることを一個一個やっていく感じですね。
あとはチームもまだまだ若い人や最近入った人が多いので、本当にゆっくりやっていこうかなという感じですね。
藤倉：なるほど。
不測の事態にエンジニアがどこまで対処するか
藤倉：話が飛ぶんですけど、プロダクションに組み込むときには、各社機械学習のエンジニアでありソフトウェアのエンジニアであるような人たちがいそうな雰囲気だったんですけど、どこまでカバーしますか？
例えば一般的なWebアプリケーションエンジニアであれば、それこそ本番環境のCI/CDの環境を自分たちで作るとか、SREのチームがいれば、アラーティングとかはそっちが受けたりするんでしょうけど、Webアプリケーションエンジニアも真夜中に叩き起こされることだってあるわけですよ。こんなことも役目の中に含まれるんですか？
西場：うちはやらなきゃいけないですね。うちはMLエンジニアもチームの中でデータエンジニアもいて協力してやっているんですけど、土日に障害が起きたらチームで対応します。ただ、MLの特性上、いろいろと障害が起きやすい部分もあって、僕らはサクッと作って出すみたいなところをやっているのでフロント側で制御してもらっています。
なので、こっちのAPIは落ちるかもみたいな。落ちたときはこっちでがんばってカバーするけど、カバーできなかったときにそのまま障害で「ページが表示されません」じゃなくて、何かしら表示されるようにフロント側ががんばってくれてたりしますね。そうやって助けられてる部分も多いです。ただ、僕は普通に大晦日に1回出勤したことあります。
（一同笑）
運用負荷が掛からないかたちでプロダクト側とSLOを握る
竹原：メルペイもちょっと似てるかもしれないですね。マシンラーニングエンジニアの範疇はフロントエンド開発はしないですけど、バックエンドのバッチシステム、オンラインのAPIを開発して運用しています。工夫しているポイントはいくつかあるけど、一番は、SLOを高くしすぎないことですね。
なるべくオンライン処理じゃなくてバッチ処理に回すようにするなどして、もちろんオンコールというのもあるんですけど、夜間バッチをそもそもなくしたり、週次バッチにして1週間に1回動いているか見ればいいみたいな、運用負荷が掛からないかたちでプロダクト側とSLOを握るのは意識してやっています。
谷脇：弊社の場合はプロダクト開発チームが発足して間もないので、まだ24/365で対応が必要なプロダクトを展開していない状態です。でも担当範囲としては、もともとプロダクトを作るチーム、アプリケーション開発チームがなかったので、自分たちでAWS上でいろんな仕組みを整えて、CI/CDとかもやりますし、アプリケーションの監視もやっています。
将来的にそれぞれのプロダクトが軌道に乗ってきたら、もっとシビアに24/365で対応しないといけなくなるかもしれないですけど、我々の現在のミッションは運用することではなくて、その研究を自動化してそれが世の中のニーズにマッチして普及させられること、試すことをミッションとしています。なので、その運用が24/365で必要になるときには恐らく協力会社さんに外注するとか、まだわからないですけど検討すると思いますね。
藤倉：SREチームを作るとか……。
谷脇：外注じゃなくてもそうですね。別のチームを作るとか、そういったかたちで展開していくことになるとは思います。
