LINE × DeNA フロントエンドエンジニアたちが語る、開発現場のリアル

LINE×DeNAが語るフロントエンドチーム

k2_wanko氏（以下、k2_wanko）：パネルセッションの時間は30分なのでサクサク進めようと思いますが、まずは自己紹介から行きましょうか。

では、まず僕から軽く。コキチーズといいます。

LINEでセキュリティエンジニアをやっています。「なんでセキュリティエンジニアがここにいるんだ？」という話があるかもしれませんが、もともとWebなどいろいろやっていて、ちょうどいい感じで話せるということで白羽の矢が立って、ここにいます。今日はよろしくお願いします。

（会場拍手）

では、順番に名前と所属と今なにやっているかをお願いします。

azusa.tomita氏（以下、azusa.tomita）：富田梓と申します。

LINE所属でフロントエンド開発センターで主にマークアップをやっていて、HTMLとCSSを書いています。今はLINE NEWSを主に担当しています。よろしくお願いします。

（会場拍手）

miyoshi氏（以下、miyoshi）：miyoshiです。

先ほど登壇したAlanさんと一緒で、フロントエンド開発センター所属です。プロダクトは主にLINE NEWSに関わっていまして、JSをメインで書いています。よろしくお願いします。

takepepe氏（以下、takepepe）：takepepeといいます。本名は吉井健文といいます。

先ほども紹介したとおり、ヘルスケア事業部で「kencom」というアプリを開発しております。あとは、TypeScriptが好きで、本を書いたりしています。よろしくお願いします。

nanocloudx氏（以下、nanocloudx）：はじめまして。「なのくろ」こと小林と申します。

DeNAで横にいらっしゃる吉井と一緒に「kencom」の開発をやっております。よろしくお願いします。

デザイナーとのコミュニケーションについて

k2_wanko：では、今日は何を話すかというところなんですが、事前にアンケートを取らせていただいているので、それについてここにいるメンバーがどんなことを思っているのか、という感じで進めていければと思います。

まず、アンケートで多かったのが、「どのようにデザイナーとコミュニケーションを取っているか」です。各社どのようにコミュニケーションを取っているかをお聞きしたいと思います。具体的に、自社や自分が担当しているプロダクトではどのようにデザインを決めてデザイナーと協業してやっているのか、お答えいただきたいと思います。

azusa.tomita：LINEでは分業になっていて、フロントエンドの中も、マークアップを書く人とJSを書く人でがっつり分かれているので、デザイナーとやりとりするのは主に私のようなマークアップエンジニアがやることが多いです。

コミュニケーションは、社内なので口頭でやりとりするのですが、ツールとしてはZeplinを使用しています。SketchでデザインしてもらったものをZeplinで受けて、そこを見ながらやりとりすることが多いです。

k2_wanko：それは、デザイナーの人がSketch上でデザインを作って、そのデータをZeplinで共有して、マークアップの人が実際にマークアップしていく感じなんですかね。

azusa.tomita：はい、そうです。

k2_wanko：LINEの社内はどこもだいたいそんな感じですか？

miyoshi：LINEの場合はプロダクトや案件によってやり方の自由度が高くて、ずいぶん違っています。LINE NEWSはZeplinを使っていますが、全体としてはそれほど多くはありません。

k2_wanko：LINE NEWSはそういった新しいツールをどんどん導入している感じですかね。わかりました、ありがとうございます。では、次はDeNAさんはいかがでしょうか？

takepepe：基本的に、デザイナーがBizの人とがっつり話をしてUIに落とし込んでくれて、そこからSketchと、あとはAbstractですね。SketchのGitみたいなものを使って管理していまして、それでコミュニケーションをしています。

僕の場合はLINEさんと違っていて、マークアップから、最近ではNode.jsのサーバとかもやったりしています。隣のなのくろ君なんかは、実は毎日NodeのBFFを書いていたりします。

デザインをやる機会が最近減ってきたなとちょっと思っていて、少し前までは「ここのUI、ちょっとこれおかしいんだけど、これどういうこと？」って詰めたりしていました。昔はデザイナーをやっていたので。

なので、そういった議論ができるところが、フロントエンドをやっていて楽しい時かなと思います。

エンジニアとデザイナーで揉めることはあるか？

k2_wanko：なるほど。アンケートでなぜみんなコミュニケーションを気にしているのかというと、やっぱりコミュニケーションがうまくいってない会社が多いのではないかと予想します。LINEもDeNAも、エンジニアとデザイナーがデザインにおいてなにか揉めたりすることはあったりしますか？

azusa.tomita：それはもちろん、というかそれはどこも同じだと思いますけどね。

k2_wanko：例えばどんなことで揉めましたか？

azusa.tomita：直近であったのは、「明らかに色のコントラストが取れてないだろう」みたいなものが来て「どうするの？」という話をデザイナーとやりとりしましたね。

k2_wanko：そのとき、どういうかたちで決着をつけますか？　なにか揉めたときに何をもとにお互い納得できる落としどころを見つけるか。けっこうケースバイケースになると思いますが、パッと僕が思いつくのは「A／Bテストしてトラフィックが多いほうを採用しましょう」とかそういう感じなのかなと思うのですが、常にそれができるわけでもないと思います。いかがでしょうか？

azusa.tomita：どこで折り合いをつけるかはその時々によって変わりますが、「どうしてもこの部分は譲れない」という場合であれば、「なにか別の方法を探しましょうよ」とどちらかが折れることもあります。それには明確な基準やポイントがあるわけではなくて、本当にケースバイケースで違う感じですね。

k2_wanko：DeNAさん側ではデザイナーと揉めることってありますか？

takepepe：けっこうあるパターンで「よしなにパターン」というのがあるんですけど（笑）。デザイナーのタスクがまぁまぁな量なものなので、管理画面の部分的なところなんかはフロントエンドエンジニアが作っちゃったりとかしますね。

細かい部分の調整をどうしているか

takepepe：あとは、僕が聞きたいなと思っていたのは、ボタンのhoverの指定だったり、そのあたりの指定はどうやられているのでしょうか？　かなりガチガチなデータを寄越してくるのか、むしろ僕らのように、よしなに、「ここのhoverはこういうやつだから、それを引用して……」みたいなやりとりなのか、そこをうかがいたいなと思って。

azusa.tomita：LINEは、デザイナーのやる気がすごく満ち溢れていて、1ピクセルにこだわってつくっているような人たちなのでデータ自体はものすごく細かいものが来ます。なので、マークアップもできるだけそれを再現できるように最大限がんばっています。

なので、モジュールを作っても、画面によっては「この画面はこういうふうに見せたいし、この画面はこう見せたい」みたいなことがあるので、画面ごとに細かく細かく調整をかけています。

takepepe：実際に「1ピクセルずれてるんですけど」みたいに言われたことあります？

azusa.tomita：それはもうしょっちゅうです。

takepepe：すごいですね。

k2_wanko：そのときは「じゃあピクセルずらします」ってなるんですか？　端末によってやっぱり画面もぜんぜん違いますよね。

azusa.tomita：そうですね。基本的にiOSをベースに作業をしていって、iOSで出てくるデザインに合わせています。ただ、一応フロントエンドというかマークアップの仕事をしてお金をもらっているので、できるだけのことはがんばっています。

takepepe：もう1つお聞きしたいことがありまして、マークアップエンジニアの方とフロントエンドエンジニアの方がしっかり分業されていると伺ったのですが「それってけっこうハードじゃない？」と思っていて。「コンフリクト地獄が起きそうだな」と思ったんですが、そのあたりはいかがですか？

miyoshi：今フロントエンドと言いましたけど、たぶんJSを書く人とマークアップする人が別という話ですよね。

takepepe：そうですね。

miyoshi：簡単に説明しますと、LINEフロントエンドは、CSSとHTMLでマークアップをする人と、JSを書く人で完全に分かれているんです。ただ、僕はもともとどちらもやっていました。あとは人が少ないプロジェクトに入っていて1人でどちらもやった経験があるので、その意見もわかります。

要するにJSの都合で「このDOMを1個下に下げたい」とか「これと同じグルーピングにしたい」という調整が、違う人だと面倒くさいんじゃないかと最初は思っていました。ですが実はやってみたら楽でした。というのは、待ってたらちゃんとしたものが来るんです。それほど細かい調整がJSで必要になることは今のところあまりないので、単純に楽になったなという感想ですね。

分業を実化するフレームワーク

k2_wanko：分業するときにどんなフレームワークを使っているかとか、これを使っているから分業がうまくいっているということはありますか？

miyoshi：JSのフレームワークでいうと、LINE NEWSに関してはReactとVue.jsを使っていますがLINE全体に関してはVue.jsが多くて、昔のやつはAngularの古いやつを使っていたりするのですが、とくにどれだから楽という感じはあんまりしないです。逆に聞きたいんですが、どうですか？

azusa.tomita：どうですかね、おそらく先ほど「コンフリクト地獄が起きそうだな」と言っていたのは、同一のHTMLを作業するようなケースのことだと思うんですが、マークアップエンジニアが触っているのって、デザインが確認するための静的なHTML、外には出さないモックのHTMLまでなんですね。

実際にサーバ側に上がっているテンプレートなりJSのテンプレートなりを触るのは、完全にJSerの人にお願いしているので、本番のほうは触らないからそこで責務が分かれており、コンフリクトしないというのはありました。

takepepe：それでは、差し替えるときにズレたりということはありませんか？

azusa.tomita：それはあります。

takepepe：ありますよね。そこは分業化したときに大変そうだなと思いました。

azusa.tomita：そうですね。なので、JSerの人に渡して実装が終わったあと、上がってきたHTMLを一応こちらで確認してできているかを見ています。そこは大変といえば大変なんですが、分かれているから楽な部分もあります。

使用するツールはどう決めているか？

k2_wanko：なるほど。あと、もう1つ気になったのが、みなさんデザイナーの人がSketchなど最新のツールを使ってやりやすいものに乗り換えてくれている印象があります。

世のデザイナーはPhotoshopでデザインを渡してくることもあると思いますが、例えばデザイナーに新しいツールを導入してほしいと思ったとき、それはデザイナーが勝手にそれをやってくれるのか、それともエンジニア側から「これ使いましょう」と言うのか。どちらが多いですか？

azusa.tomita：昔はPhotoshopを使っていて、そこからSketchに移ってZeplinでもらうようになったという大きな転換はありましたが、それ以外ではとくにありませんでしたね。

k2_wanko：それはどっちが主導でやろうという話になったんですか？

azusa.tomita：それはデザイナー側の意向だったと思います。なんか「管理が楽だ」みたいな。

k2_wanko：デザイナーが自分で勉強して「これがいい」ってかたちなんですね。

azusa.tomita：そうだったと思います。こちらは来たものがなんであれ、それをもとに再現をしているので、向こうのツールがどうこうという影響はあまりありませんでしたね。

DeNAにおけるツール選定

k2_wanko：DeNAさん側はいかがでしょうか？

takepepe：うちはAbstractを導入したとき、実はずっとこれ入れたいなと思っていたのですが、なかなか言い出せませんでした。今日DJをやってくれているおさんじ君というデザイナーがいるんですが、彼がぶっこんできて「うわ、やったな」と思って。おかげさまでかなり快適な環境になったなと思っています。

なの君は前はどうしてたっけ？

nanocloudx：今いる1つ前の部署は、ペライチのJPEGでいただいて、それを再現するというところでは同じですね。

miyoshi：JPEGですか？

nanocloudx：JPEGでポンと来ました。PSDでもなんでもいいんですが、紙で印刷されたやつでも普通にありましたし、それでできるだけ同じような感じで再現してデザイナーに見てもらって「marginとか合ってますか？」「雰囲気合ってますか？」みたいなことを話しながら進めていました。

基本的には、SketchやPhotoshopといったものはだいたい揃っているので、何か来てもだいたいイイ感じにするという感じです。

takepepe：でも、うちの会社ってわりとゲーム会社というイメージが強いのかなと思っています。

僕らがいるところはWebサービスなんですが、やっぱりそういったゲーム系のUIってかなりこってりしたつくりになっていたりします。そういうときはPSDやLMPとか、そういうものが多いです。

k2_wanko：でも、デザイナー側からもっと楽なほうにいこうと思ってくれる人がいればやってくれる。エンジニア側から声かけてうまくいくことはあんまりないなというイメージでしょうか？

takepepe：でも、さすがにIllustratorが出てきたらちょっと止まっちゃうかもしれない（笑）。

k2_wanko：なるほど。そうですね、デザイナーにやる気を持ってもらえるなにかをやっていかないといけないと思っています。

takepepe：そういえば、今日デザイナーの方っています？　

k2_wanko：どのぐらいいるんですか？

（会場挙手）

takepepe：まぁまぁいる感じですね。今の話はけっこうピリつくかもしれません（笑）。

k2_wanko：そうですね、エンジニアから便利なツールをがんばって紹介して、お互い協業のしやすいソリューションを見つけていくのが大事なのかなと思っています。

azusa.tomita：そうですね。ZeplinになったときにCSSの値で数値を取れるようになったので、これすげえ楽じゃんと思ったんですが、実際にやってみるとイマイチ合わなかったりして。結局、最終的に信じられなくなって、もう画面とシミュレーターの画面を並べて合わせることをやっています。最終的に「これなんでもいいじゃん」みたいな感じになったところが、今の状況ですね。

k2_wanko：なるほど（笑）。

takepepe：最近はSketchでAttributeコピーして以上、みたいな感じです。

プロジェクトの体制について

k2_wanko：では、もう1つ多かった質問がプロジェクトの進め方についてです。「プロジェクトの体制はどうしていますか？」みたいなところで、各社がどのようにプロジェクトを進めているか。今自分が担当しているものだけでもいいので、なにか工夫していることがあれば教えて下さい。

miyoshi：僕の場合、LINE NEWSを担当プロダクトとしてやっていますが、LINE NEWSに入ったのって比較的最近なんです。といっても2〜3年経っているのですが、その前はもっと違うプロダクトをやっていました。というか、そもそもなぜLINE社に入ったのかというと、面接で「いろんなサービスに携わりたいのでLINEにしました」と話したので。

k2_wanko：なるほど。では、今はLINE NEWSでどのようにプロジェクトを進めていますか？

miyoshi：先ほども言いましたが、案件やプロジェクトによってぜんぜん内容が違って自由度が高いんです。LINE NEWSはLINEの持っているサービスの中では比較的規模が大きくて、関係者が多いというのもあるので。

k2_wanko：どのぐらいいます？

miyoshi：ディレクターというか、社内では企画と呼んでるんですけど、企画が50人ぐらいです。

k2_wanko：企画が50人。

azusa.tomita：バックエンドの開発が15〜20人ぐらいかな。

miyoshi：もうちょっといますかね。バックエンドが20人ぐらいいて、フロントが10人ぐらいですか。

azusa.tomita：フロントエンドは8人ですね。あとデザイナーが2〜3名みたいな感じです。

k2_wanko：それでどうやってプロジェクト進めていくんですか？

miyoshi：直近でやっているのは、結局何十人という単位で回すのは無理があるので、何人かずつでチームに分けて、そのチーム単位でスクラムを組んで回すことをやっています。まだはじめたばかりということもあり、具体的にどのぐらいコストが上がっているかまでは判断できていないですね。

チームの構成は？

k2_wanko：チーム体制はどんな感じですか？　フロントエンドの中にもさらにチームがあるのでしょうか？

miyoshi：バックエンドとフロントエンドとディレクターのセットというか、案件を全部を回せるセットチームになっていて、それがいくつかあってそれぞれ並列に動いている感じです。

k2_wanko：なるほど。

miyoshi：今もいろいろなところを改善しながらやっている最中なので、あまり「ここがいい」とか「これは真似したほうがいい」みたいな話は、本当はしたいんですが、あまりできなくて。基本的に、現状はあまり良くないとしても常に改善していける体制はできているので、それ自体はいいことかなと思っています。

k2_wanko：事前にちょっと聞いたんですが、改善をするメンバーがいる、その改善をしていく役割の人もいるんですよね。

miyoshi：そうですね。チーム作りやプロセス改善などに関するコーチングやサポートをしてくれる、Effective Team and Delivery室という部署がLINEにはありまして。あるチームの人が新しいやり方を試したい時に、仮にそれなりにいいものであったとしても主導的に推進してくれる人が誰かいないと、基本的に進まないんですよね。なので、その部署のがいろいろ手伝ったり推進してくれている感じです。

takepepe：普通にスプリントに入ってきたりする感じです？　そういった方が入ってきて、計画的に入れていこう、みたいな。

miyoshi：あんまり細かいことは言われないんですよね。というのは、あまり固定的なやり方を押し付けてもしょうがないので。あとはいろいろな案件があるのでその案件によっては最適なものは違います。基本的に手伝いというかアドバイスはしますが、どれを選んでどんなやり方をするのか、決定自体はそれぞれのチームで行う感じになっています。

DeNAのフロントエンドチーム

k2_wanko：では、DeNAさんはどのようにやっているのか教えてください。

nanocloudx：いま、僕と吉井が携わっているプロダクトについては、エンジニアの構成としては、フロントが3人、サーバ2人のインフラ2人で、あとはネイティブがiOS・Android数人それぞれいるというプロジェクトチームです。あとは企画の方が一緒にいて、1グループみたいな感じで動いています。

プロダクトはそれで全員なんですが、1機能ごとに企画が「こういうものを作ります」という草案を出してくれて、それに対してフロントとサーバサイドがそれぞれ1人もしくは2人入って、「こういうふうに作っていきます」ということを話しながら進めていく流れで進んでいます。

nanocloudx：スプリントの場合は一般的なスプリントを2週間でチケットを切って、一般向けのAtlassianツールをガリガリ使いながら開発を進めています。

k2_wanko：なるほど。GitHubよりはJIRAでやっていく感じですかね。

nanocloudx：そうですね。プロジェクト管理はほとんどJIRAベースです。開発陣だけのプルリクはだいたいGitHub上で完結している流れです。

k2_wanko：なるほど。今のフローで困ることはあまりなさそうですか？

nanocloudx：そうですね。プロジェクトの手戻り的なことは比較的少ないと感じています。わりと序盤でどんなものをつくるのか明確に定義されているドキュメントがあるので、それを随時更新していくかたちで進めています。認識の齟齬はできるだけ序盤でつぶしながら進めていますね。

k2_wanko：それってスプリントをはじめるタイミングでミーティングをして、「この機能はこういうふうに作っていきましょう」という意識を統一していく感じなんですかね。

nanocloudx：そうですね。キックオフのようなミーティングをまず設けてしまって、そこでこういう機能をつくって、このゴールはこういう感じで、誰がどれをやるかを細かく決めて、そこから見積もりをしてはじめています。

k2_wanko：なるほど。ベンチャー企業ではリモートワークでやっている人も多いので、オンラインで一緒に集まる機会ってなかなかない気がしています。

リモートワークの影響は？

k2_wanko：LINEもDeNAさんも大きい会社なので、リモートワークの人もいる場合はどうしていますか？

takepepe：実は今年からフルリモートもOKになったんですよ。

k2_wanko：おお。

takepepe：では、ふたを開けてみたらどうだったかというと、実はみんな会社が好きなんだなと（笑）。僕もそうなんですけどね。家とはちょっと違くて、どでかいモニターが会社にあるので、すごく静かだし、めちゃめちゃ作業しやすい場があります。

結局リモートみたいなときがあったとしても、台風のときとか、家でやるにしても子どもがいたりすると落ち着かないのでカフェに行ったりするんですが、作業環境としては会社のほうがいいので、みんな会社に行くんですよね。

ただ、制度としても認められているので、今後はリモートを活用していくような働き方ができるのかなと考えています。

k2_wanko：じゃあ、ミーティングがあったときはみんなオフラインで集まるし、仕事もわりとオフラインで進めている感じですかね？

takepepe：そうです。最近はリモートの方にもミーティングに出てきてほしいときにはビデオ会議で参加してもらったりということを進めていますね。

k2_wanko：なるほど。おそらくLINEのリモートワークに関する話は、拠点がいくつかあるというのもあると思うのですが、それについてはいかがでしょうか？

azusa.tomita：前提として、東京のオフィスと福岡のオフィスがあって、QAは福岡でやったりするので、だいたいどのミーティングもZoomというビデオチャットを使ってやりとりするのが基本になっています。ですので、オフラインで会わなくても仕事を進められるようになっています。

リモートワークもできなくはないというか、実際1人ケガで休んで会社に来れないタイミングがあった時に、家からZoomをつないでミーティングに参加してもらったりしたので、別にオフラインで必ず集まってやらなければいけない雰囲気ではありません。

k2_wanko：開発メンバーは基本みんな同じ場所に集まるって感じでしょうか？

miyoshi：案件によりますね。バックエンドを韓国で作っていて、フロントエンドを日本で作っていることもあるので。

k2_wanko：そうなるとオフラインで集まるのはコストがけっこうかかっちゃいますよね。

技術選定のポイント

k2_wanko：では、次の質問に行きたいと思います。もう1つ、アンケートで3番目ぐらいに多かったのが「各社どんな技術を使っていますか？」という話です。また、「今後新規開発をするなら、自分だったらこの技術を取り入れたい」みたいなものがあれば教えて下さい。

takepepe：（nanocloudx氏に向かって）あるでしょ？（笑）。

nanocloudx：じゃあ（笑）。実は今、我々が作っているプロダクトはまさにほぼ新規開発なんです。つい最近作り始めて公開したというサービスなので、すでにモダンなものをいろいろ採用してるんです。

我々はReactとNext.jsを使ってまして、スタイリングはstyled-componentsを使っています。言語はTypeScriptで書いていて、Next.jsとフレームワークに則って素直にビルドしている感じですね。

裏はマイクロサービス化されていて、バックエンドはGoで書かれているんですが、BFFレイヤーはNode.jsとExpressを採用してAPIを作ったりしています。Kubernetesで管理しているので、比較的モダンかなとは思っています。

ただ、やはり採用したい技術はありまして。例えばスキーマの共有をどうするのか、フロントとサーバで話したりする機会はあると思うのでそういったところですね。

今はとくにPostmanみたいなツールを作ってスキーマの共有をしていますが、できればここはもっと素直に、SwaggerやgRPC、GraphQLなどを採用していくとよりモダンになるのではないかと思っているので、今後やっていきたいと考えています。

takepepe：ほぼTS化されてやったぜと思ったら、「そこRESTかよ」みたいな（笑）。

k2_wanko：APIの部分どうしようかとか、けっこう悩みますね。LINE側ではいかがでしょうか？

miyoshi：先ほどチラっと話はしましたが、現状でLINEのWebのプロダクトで使っているものは、基本的にVue.jsと、ほぼ100パーセントSassで書いていると思います。ですが、Vuexを使っているときもあれば、LINE NEWSに関しては例外的でReactを使っているのですが、基本的に新しい案件であればVue.jsを使っていることが多いです。

なにか強い理由があるわけではないのですが、LINEはエンジニアがフレームワークを比較的自由に選べるんです。だから、来年すぐ死んでしまうようなフレームワークを選んだりすると、それは自分でなんとかカバーしなければいけません。

なので、かなり初期からVue.jsは使っていて、ReactもAngularJSも初期から使っているのですが、結果的にVue.jsが一番なにも考えないで使っていっても安全という感じなので使っています。

k2_wanko：フレームワークを更新する予定はぜんぜんない感じですね。Vue.jsを使っていく感じでしょうか？

miyoshi：案件によりけりだとは思います。

k2_wanko：そうですよね。APIの設計の部分ではそれほど困りませんか？

miyoshi：そうですね。今LINEの場合は完全に分業化しているので。

k2_wanko：サーバの人が用意したAPIを叩いて作っていこうと。

miyoshi：そうですね。

k2_wanko：もちろん案件によるとは思いますが、人が多いとレガシーというか、RESTのほうがみんな使い慣れていることもあると思います。

まぁ、いろいろ挑戦できるところが多い気持ちも、社内から見ているとたくさんありますが、開発体制のところでがんばっているということもあるので、どこからやるか、チームベースで進めるのは難しいですね。

すみません、うまくまとめられなくて申し訳ないです。時間がすこし超えてしまったので、技術に関してぜんぜん紹介できていませんが、ここで締めさせてもらいたいと思います。今日はありがとうございました。