LINEには開発に専念できる環境がそろっている　機械学習・データ基盤開発・AIサービス開発部門でサーバーサイドエンジニアとして働く意義

エンジニアの1日の業務の流れ、打ち合わせの方法や頻度など

三木鉄平氏（以下、三木）：質問がたくさん届いているので、まず上からいきたいと思います。「エンジニアの1日の業務の流れ、打ち合わせの方法や頻度などを教えてください」。これは順番に3部門に答えていただきましょうか。まず機械学習の部門はどうでしょう。

大東哲平氏（以下、大東）：だいたい1日の業務の流れだと、出勤というかノートPCをつけてから、人によりますが、チームごとに会議があります。私の場合はインフラエンジニアの定例会議が週に1回か2回、さらにMachine Learning室の会議も2回ありますね。

樋村隆弘氏（以下、樋村）：DSP MLチームも業務の流れはだいたいたぶん一緒だと思います。打ち合わせについては、先ほど大東さんからあったとおり、Machine Learning室として週に2回、各自の進捗を話したり、リリース情報や障害対応などを話すミーティングがあります。

DSP MLチームとしては、週に1回定例がある他に、隔週で韓国側のチームとの協議の場があります。そちらのミーティングは、通訳の方が入っているので、特に韓国語のスキルはなくても大丈夫です。

三木：ありがとうございます。データ基盤開発はどんな業務の流れですか。

湯川航氏（以下、湯川）：そんな大きくは変わらないとは思います。打ち合わせは、けっこう人にもよっていて、コンポーネントのリーダークラスの人だと多少多めになる傾向はあります。ストリーミングのパイプライン見ているリードの人や、Hadoopのストレージを見ているリードの人などになると、やはりどうしても別チームとの調整が入るので、多少多めになります。それ以外の人なら、週1回のミーティングにはなると思いますね。

あとは必要に応じて随時、話したほうがいい場合は「Zoomで話しましょう」みたいな流れにはなりますね。

吉原忠史氏（以下、吉原）：AI開発室も、基本はチームの定例と、あとは自分が参加しているプロジェクトの定例があります。あとは、個別に確認したり、今リモートワークなので、基本的に打ち合わせをしないと仕方がないみたいなところもあります。他の人のスケジュールをちょっと覗いてみると、1日に2、3回は打ち合わせをやっていて。たぶんそのうちの半分ぐらいが、いわゆる定例とか会議ですね。その他は、個別にちょっと話したりな感じです。

募集している部門では開発領域に専念できるのか

では次の質問です。「今の会社、各部署に案件を取ってくるような営業部門がなく、開発担当者レベルで営業部門が行うような各営業、折衝を行ったりと開発以外にも作業範囲が多く、開発に専念できていない状態です。今回募集している部門では開発領域に専念できるんでしょうか」。こちらはどなたからお答えいただけますか。

大東：では私から。Machine Learning室から見ると、顧客は各サービス担当のエンジニアや企画者かなと思います。

Machine Learning室にはプランナーがいますので、そちらが導入のための話し合いなどをしますが、最終的に導入するときにはMachine Learningエンジニアも関わります。

その際に、サービスとつなぐ部分はMachine Learning Infrastructureチームがコミュニケーションに入ることが多いのですが、こちらは最終的に会議やslackだけで済むケース、Wikiに書いて「あとはお願いします」というケースもあるので、開発に専念できないということはないと思います。むしろ開発に専念していただくために、Planningチームが存在しています。

三木：はい、ありがとうございます。他の部門はいかがですか。おそらくLINEの開発組織では、開発に専念できないという部門は存在しないと思うのですが。どなたか何かご意見ありますか。

吉原：そうですね、同じことですが、ちゃんとPlanningチームや営業チームがあるので、そこでちゃんとやってくれています。AIサービスの場合は、システムを接続することもあるので、そういう場合に先方の開発者チームと私たちの開発者チームが打ち合わせをすることはあります。

質問のような、本来営業部門が行うようなものはないですね。私はSI的な仕事もやったことありますが、他の会社であればプリセールスエンジニアであったり、FAEやそういう人がやっているようなことは、だいたいPlanningチームがやっている印象ですね。

分析コンペの実績は評価されるのか

三木：では次の質問に行きたいと思います。「Kaggle、SIGNATEなど、分析コンペの実績は評価されますか」。これはおそらく機械学習部門かAI部門を想定したご質問かと思いますが、どちらかお答えいただけますか。

大東：そうですね。職務経歴だったり、あとその他のコンペや資格試験を同様に評価の1つとして、入社時の面接の評価としています。

実績というのは、例えば入社後の実務であれば、評価になることがないかもしれません。実際Kaggleで入賞された社員もいますが、Kaggleでの実績自体が評価基準にはなっていないと思います。

三木：ありがとうございます。では次の質問ですね。「データ基盤のアーキテクチャやサービス担当チームとの連携をどのようにしていますか」。

湯川：アーキテクチャは先ほど説明したと思いますが、サービス担当チームは、実際にはサービス側のエンジニアというパターンにはなります。僕のいる部門は、プラットフォーム側の人間なので、一応そのストレージであったり、共通で使えるようなツールやAPIをサービス側に提供する立ち位置になります。

なので、サービス側のエンジニアがそのツールやAPIを使って、自分たちでデータをHadoopに入れて、加工して……というのを行っていく流れになります。

もちろんコミュニケーションが必要な場合も当然あるので、一応その問い合わせ窓口みたいなものもありますし、場合によっては、先ほど紹介したソリューションエンジニアが、サービス側のエンジニアとミーティングして調整に入ることもあります。といった感じで、答えになっていますでしょうか。

データ蓄積部分とデータ加工部分の連携について

三木：続けてこれもデータ基盤開発の質問なんですが、「現在データ分析基盤構築のPoCを行っていますが、データレイク・データウェアハウス・データマートなどのデータ蓄積部分と、ETLツールのようなデータ加工部分の連携に悩んでいます。特に顧客からの基盤に対する要求がなく、まず基盤を構築して検証やデータモデルを作るチームに触ってもらうかたちとなっており、基盤を作っていくための設計方針が不明瞭です。このような場合では、御社ではどのようにプロジェクトを勧められていますか。具体的なモデルケースをついて教えてください」。

湯川：たぶん、このような場合がうちにはないような気がします。なぜなら、まず私たちのほうで基盤は作っていて、データ蓄積部分もSDKやツールを開発しているので、これらのJavaのSDKをサービス側のアプリケーションに組み込んでもらえれば、サーバー側のログは私たちのHadoopクラスタに入ってきます。

また、サービス側のMySQLデータと、Freyというツールを使えば、Sqoopを通して入ってきます。蓄積部分についてはそういう感じになっています。

その後のサービス側にとって分析しやすいようなデータマートをどう設計するかや、ETLやパイプラインをどうするかという意味であれば、それはサービス側にお任せという答えになります。

実態としては、最初から完全にデータマートを設計するのはたぶん難しいと思うので、まずはサービス側のほうでいろいろいじって、まず加工はしないでデータ蓄積したテーブルに対して、直接Prestoクエリを投げます。

なので、場合によってはwith句で、5つくらいテーブルをジョインして可視化するようなケースが、たぶん最初の一歩かなと思います。

当然、その場合だとデータ量が多くなってきた場合に、クエリがタイムアウトになったりするので、その段階で少しカチッとしたスキーマリジットなかたちでデータをETLして、テーブル設計してデータマートを作る流れになると思います。

そのスキーマレスの柔軟性と、データを加工するコストを払った上で作るデータマートには、当然トレードオフがあって、ETLせずにクエリをすぐかけることとスピードが出ないというトレーとオフがあります。なのでそこはちょっとサービス側のほうでも、試行錯誤してやっているというところかなと思います。

もちろん、随時必要なツールやコンサルタントが必要であれば、私たちがここでサポートに入るような体制で行っています。

奥田輔氏（以下、奥田）：ちょっと湯川さんの紹介になかったので付け加えます。サービスごとにデータプラットフォーム、すべてのサービスにカスタマイズで提供するのは、けっこう厳しいというのは湯川さんと同義です。

ただ一方で、そうするとサービスごとに固まっていいデータを作るというのはけっこうスピード感持ってできるんですが、サービス間の連携みたいな、いわゆる全社共通で有意なデータを作るとか「あのサービスとこのサービスのデータを連携するといいよね」とかというところが疎かになりがちです。

なので最近はそういったケースでは、全社共通のデータマートも別途で作っています。いろいろな人が触れるようなツール。それはけっこうプライオリティが重要なデータになりがちなので、どういうふうに権限を管理するか、どういうふうにデータマート作っていくかというのは、先ほど湯川さんのスライドの中であった言葉で言うと「データカタログ」ですが、そういったものを使って、この会社の中にはどういうデータがあるのか、実データ触ると問題はあるものの、どういうデータが入っているかをカタログ化すること、それ自体はなるべく広くオープンにしています。追加でした。

機械学習出身でなくても機械学習出身者と同じタスクをもっているのか

三木：では次の質問に行きたいと思います。

「機械学習出身でない者も、機械学習出身の者と同じタスクを行っているんでしょうか。それとも専門性が高いものはもうすべて機械学習出身の者だけが行うのでしょうか」。これはサーバサイドエンジニアではなく機械学習エンジニアを想定した質問のような印象を受けますが、こちらは大東さん、お答えいただけますか。

大東：実際は、今分業が進んでいますので、機械学習のインフラチームであれば、インフラを中心に行っています。

ただ、機械学習をまったく行わないと、先ほどの説明でも言ったのですが、機械学習のAPIのベースラインを実装したり、あと機械学習のライブラリの元の部分を作ったり、あと今はもう機械学習のエンジニアしか作っていませんが、そこの高速化手伝ったりなど、そういった部分で機械学習に触れるケースは非常に多いので、実際自分でモデル書いてみたりすることは可能です。ただ、業務としては分かれています。

三木：ありがとうございます。ついでに「人事評価の上で注視するポイントありますか。特にMLタスクについて」。

大東：特にこの「MLタスクについて」というただし書きがない場合とある場合で、ちょっと回答が変わってきます。MLタスクについて話すと、今回のイベントから外れてしまうような気がするので。インフラエンジニアとしてということであれば、安定して運用するであったり、課題を自分で見つけて積極的に改善していける人であったり、そういったことが非常に高評価になるんじゃないかなとは思います。

入社後のMLに関するインプット

三木：はい、ありがとうございます。では続けて、「サーバーサイドのみをやっていて、機械学習について経験がありません。適性を考えるためにあらかじめ機械学習について基礎を学びたいのですが、サーバーサイドのみの経験で入社されてきた方は入社後にまずどのようなMLに関するインプットをされますか」。こちらいかがでしょうか。

大東：インフラチームでは、機械学習の知識はまったくなくても行える業務はたくさんあります。

先ほど申し上げたとおり、ベースラインを作ったり、機械学習のライブラリを作たりする仕事があります。あとライブラリを作るのであれば、当然ライブラリを試す必要があるので、それでどういったことが行われているのか。他の機械学習エンジニアの業務を見ていれば、どういった機械学習が行われているのか。そしてどのようなツールで機械学習を行っているのか。そしてそれを改善するためには自分は何をしたらいいのかということが明確にわかってくると思いますので、そういったかたちで機械学習を知ることができます。

ただし、理論に関する研修などといったものはありません。

英語の能力はどの程度必要か

三木：では続けて、こちら共通的な質問なんですが、「海外とのエンジニアとのコミュニケーションは英語になると思うのですが、英語の能力はどの程度必須になってきますか」。データ基盤開発ではどんな感じですか。英語はけっこう使われますか。

湯川：口頭という意味だと、ほとんど使わないというか。わりと、これは日本人が甘えているところでもありますが、海外の方もだいたい日本語をしゃべれるので、会議などはほぼ日本語です。ただ、slackやドキュメンテーション、Wiki、プルリクエストなどは英語にしています、という感じですね。

奥田：最近は、開発基盤の部門でも英語のエンジニアを受け入れています。なので、一部、コラボレーションがうまくいくように、マネージメントレイヤーでもどういう組み合わせがいいかというのは検討しています。無理にという感じではないんですが、英語が話すきっかけみたいなのは、データ開発基盤ではわりと考えています。

ただ、湯川さんが言っていたとおり、重要な会議は、基本的に共通言語が日本語で通っているので、日本語で話して、ドキュメントは英語で書く、みたいな感じになっています。

三木：私から補足しますと、LINEの社内には通訳チームが存在します。日英通翻訳チーム、また日韓通翻訳チームの通訳士が常駐してまして。Zoomでオンライン会議する時は、Zoomの会議のURLを発行する際に通訳にも手配をかけて、日本語と英語等でする会議には入ってもらうように要請して、その時間帯は通訳入っていただくとか。

あとは社内のWikiも、日本語と英語と韓国語、それぞれボタン1つで翻訳するようなボタンが付いてたりですね、言語バリアを下げるための仕掛けがいろいろと用意されています。

ここはですね、日本韓国一緒にカルチャーを作ってきたというところで、いろいろな仕掛けが用意されていますので、比較的ご安心いただいてもいいのかなと思っています。

サーバー周りやインフラ関連の知識が乏しいと採用は難しいか

では次の質問に参ります。「MLモデルの開発は経験がありますが、サーバー周りの経験やインフラ関連の知識が乏しいと、SREなどの採用は難しいでしょうか」。こちらお答えいただけますでしょうか。

大東：Machine Learning室のサーバーサイドのケースだと、サーバーサイドとしてML開発経験はあるけれどもサーバーのメンテナンスはできない、APIが書けないということであれば、採用の対象とは異なります。

エンジニア個人のKPI評価方法について

三木：では次ですね。「エンジニア個人のKPI評価方法について、全社的な特徴や部門ごとの特徴があれば教えてください」。マネージャーがこの説明会に揃っているので、どなたか「うちの部署ではこうしているよ」と説明できる方はいますか。

吉原：そうですね。AIサービスならではというところだと、やはりサービスに直結しているというか、サービスを成功させることが最終目標なので、Planningチームの人やQAなど、いろいろな人が関わってきますが、そういう方と一緒にチームとしてやっていくためのコミュニケーションも必要になってくるので、そういったことをうまくチームワークを組んで成功させるというところは、KPIというか評価ポイントにはなってきますね。

技術的なところ、技術的なスキルやきちんとシステムを開発するというところは、もちろん基本になってはきますが、先ほどいったようなところも必要になってきます。

社内ユーザーへの機能提供についての数値目標はあるのか

三木：ありがとうございます。最後に「社内ユーザーへの機能提供について、数値目標などあるのでしょうか」。こちらは機械学習かデータ基盤の方、お答えいただけますでしょうか。具体的な数値目標ってありますか。

湯川：データ基盤のほうから答えると、特にはないのですが、もちろんツールを提供した場合は、一応ユーザーのどれぐらい使われているかやアクセス数など、そういったものはモニタリングしています。

奥田：湯川さんの言ったとおり、今あるのはけっこうベーシックな指標であります。ただ、やはりサービスごとにインパクトも違うので、最近は問い合わせ、さっきチラッと言いましたが、社内サービス側や、使っている社内のユーザーさんからいろいろな機能追加リクエストくるんですよね。

そういったのを統計してもうちょっと見えるように。どういうものを、どういうインパクトがある機能を改善したかは実際見える化になっていて、それをどうやって評価するかにはこれからつなげようとしています。

あとはそもそも基盤が動かないとユーザーさんもインパクト出ないので、そういった基盤としてメトリクス、シスアドがわかるような数値を出していますが、ユーザーが「データが出て来ないんだけど」「データが遅いんだけど」みたいなのをある程度わかるようにしていくような、よりわかりやすい指標で数値を出すための設計を今しているところです。それを設計した上で、どれぐらいがSLA、SLOだよねというのを定義している、まさにon goingなプロジェクトなので、紹介しました。