LINE Engineer Insights vol.3「UITエンジニアに聞く、最新のフロントエンド開発の裏側やアプローチ手法」

LINEで働くエンジニアに色々と話を聞いていく「LINE Engineer Insights」の第3弾です。当コーナーはインタビュアーにLINEで働くエンジニア @tokuhirom を迎え、エンジニア同士でざっくばらんにお話を伺っていくというものです。今回も、LINEのエンジニアは一体どんな人達なのか、その内面に迫っていきたいと思います。

第3弾は、開発1センター UIT室所属の喜多に、最新のフロントエンド開発の裏側やアプローチ手法などについて聞いてきました。あらかじめ説明しておきますと、UIT は User Interface Technology の略で、HTML/CSS/JavaScriptによる LINE のウェブフロントエンド全般の実装を担当する部署です。

LINE は思っていた通りフロントエンドの仕事が沢山あった

―― tokuhirom
今日は宜しくお願いします。最初に「UIT室って何やってるところかわからん」てのがあると思ってまして。LINE はネイティブアプリの会社だと思われることが多くて、でも実際にはWEBアプリ多いじゃないですか。UITっていつも「人が足りない!」と言ってる印象があって、今回のインタビューで何がどうなっているのか明らかにしていけたらなと思っています。
まず最初に、入社された時期っていつですか?きっかけなんかも教えていただけたら。

―― 喜多
はい、宜しくお願いします。入社は2015年の7月です。
入社したきっかけは、前職の最期の案件でフロントエンドの仕事をけっこう楽しくやっていて、次もフロントエンドの仕事をしたいと思っていたんですが「フロントエンドばかりやってるわけにもいかんな」という空気があったんですよね。その後、ちょっと家庭の事情もあって給料を上げたほうがいいだろうな、とか色々考えていたときに、以前 LINE にいた手島さんという方にイベントで出会って「どうですか」と紹介していただいたのがきっかけですね。
※編集部注 手島拓也さんは LINE にてWebフロントエンド開発を担当されていた元UIT室のエンジニア。現在は UPSTAY Pte. Ltd. の CTO

―― tokuhirom
うちだとフロントエンドだけに集中できる環境なんですね。実際に LINE に入ってみてギャップはありましたか?

―― 喜多
ギャップ…。そんなに入る前のイメージと違う部分は無かったですね。

―― tokuhirom
入社前からフロントエンドの仕事は沢山ありそうだなって印象ありましたか?

―― 喜多
そうですね、手島さんから LINEのファミリーアプリとか、色々Webの技術で作られているって話を聞いていたので沢山あるんだろうなとは思ってました。

―― tokuhirom
入ってみて仕事は沢山ありました?

―― 喜多
沢山ありましたね(笑)

―― tokuhirom
UITっていうのは HTML や JavaScript を書く人がいる部署ってことなんですよね?

―― 喜多
そうですね。

―― tokuhirom
今おもに担当している業務ってなんですか?

―― 喜多
主にJavaScriptを中心とした実装の部分を担当しているのですが、サービスでいうとLINEのスタンプやゲームのポイントを販売しているLINE STORE とか、LINE LIVEを担当しています。
LINE STORE のPC向けサイト

データ量が多い LINE LIVE での工夫

―― tokuhirom
それぞれPC版もスマホ版もあると思いますが一人で全部やっているんですか?

―― 喜多
案件によって異なるのですが、UIT は2〜3人でやっています。

―― tokuhirom
全員 JavaScript を書くかんじの人なんですか?

―― 喜多
2人が JavaScript で、1人がマークアップですね。JavaScript 担当とマークアップ担当と組んでやる仕事が多いかんじです。

―― tokuhirom
LINE STORE って結構開発が活発じゃないですか、LINE LIVE も活発に開発していると思うので両方やるのは大変だったりしないですか?

―― 喜多
そうですね、大変です(笑) そこは上長や企画担当と相談して重ならないようにしていたりします。あとは、どうしてもかぶってしまった場合には「午前中は片方をやって、午後はもう片方をやる」みたいな。

―― tokuhirom
なるほど、大変ですね。LINE LIVE は基本的にはスマホのネイティブアプリで見るってかんじですよね、PC版サイトが先ほど言っていた JavaScript 書いてるって部分ですか?色々な機能ありそうですが特徴的なところとか教えてください。

―― 喜多
動画のサービスなので、メインは動画を再生するプレイヤーだと思うんですが、ここはありものを使っています。昨年の下半期にあった脱Flashの流れで HTML5 のプレイヤーにするというところで、既にグループ会社で使っていたプレイヤーをベースにしてカスタマイズしています。

―― tokuhirom
なるほど、JavaScript だとチャットとかの部分がメインですか?けっこう流量多いですよね、WebSocket とかでやっているんですか?

―― 喜多
そうですね、LIVE配信の時は WebSocket で、アーカイブはアーカイブ用に CDN で配信されているファイルを取ってきて表示しています。

―― tokuhirom
アプリケーションサーバから出すんじゃなくて、あらかじめデータ生成してあるんですか?

―― 喜多
そうですね。

―― tokuhirom
LINE LIVE のページって人気のある配信などを見てると数字がグワーっと増えてチカチカするじゃないですか。これはどういう仕組みで数字はインクリメントされていくんですか?
LINE LIVE のPC向けサイト、視聴数やハート数などがインクリメントされる

―― 喜多
これは10秒おきに最新のデータを取るんですけど、それを分割してカウントアップしてます。

LINE の UIT は vue.js 推し?

―― tokuhirom
技術的な部分についても色々聞いていきたいと思います。LINE LIVE もマークアップ担当とペアで作業していますか?何人体制くらいかも気になります。

―― 喜多
そうですね、JavaScript とマークアップと1人ずつペアでやっていて2人でやっています。

―― tokuhirom
実際に JavaScript でコーディングする時にフレームワーク的なものって使ってますか?

―― 喜多
今は Vue.js を使ってます。

―― tokuhirom
そうなんですね、最近は社内でも Vue.js 使っている案件が多いと聞きますね。

―― 喜多
新規案件だと Vue.js が採用しているところが多いと思います。

―― tokuhirom
ちょっと前までは Angular.js が人気でしたよね。 Vue.js がメインになってきている理由ってあったりするんですか?

―― 喜多
最近だと React.js も人気があるライブラリだと思うんですけど、マークアップと JavaScript 書く人が分かれているサービスだと、一度マークアップ担当が書いた HTML を、JS担当が JSX に変換する作業が必要になって面倒というのが個人的にあります。

―― tokuhirom
ちなみに Angular.js 結構使ってましたけど Angular 2 にしようという話はなかったんですか?

―― 喜多
なかったですね。Angular 2、Angular.js とはかなり別物感があるんですよね。個人的には Angular 2 より、 Vue.js の方が Angular.js に似ているんじゃないかなぁ、という気がしています。

―― tokuhirom
Vue.js で作っていくうえでビルドシステムってどういうのを使っているんですか?

―― 喜多
案件によって違いますけど僕の場合は最近だと Webpack 使ってます。

―― tokuhirom
UITの中でも派閥は分かれているんですか?

―― 喜多
そうですね、Webpack 以外にも Browserify を使う場合もあって結構分かれてます。

―― tokuhirom
じゃあそこはこだわりがないんですね。結構リポジトリによってまちまちだから気になってたんですよね。出来る人は両方なんとなく出来ますもんね。

―― 喜多
そうですね。

―― tokuhirom
TypeScript とか CoffeeScript とかにいこうって話は出なかったですか?

―― 喜多
僕が入社する前ですけど、一時期 CoffeeScript で書いていた時期があったようです。でも ES2015 のスペックが Babel で使えるようになって、あえて CoffeeScript で書く必要もないかなという流れになったと思います。

―― tokuhirom
じゃあ今は完全に ES2015 ですか?babelify とか Babel 的なもので ES2015 で作ったものをコンパイルしてみたいな。TypeScript にいこうって話なかったですか?
―― 喜多
そうですね。TypeScript にいこうって話は無いですね、あまり人気がないです。

LINE BOT SDK のJS版を開発中、近日公開(?)

―― tokuhirom
型が欲しいとか言う人はいないですか。Haskell とか書く人は言いそうなイメージありますが。
※編集部注 UITの中に一人 Haskell 好きなフロントエンドエンジニアがいます

―― 喜多
うーん、全体としてはそんなにいないですね。ただ、最近、UITで LINE BOT SDK の Node 版を書いているんですけど、あれは TypeScript で書いてたはずです。

―― tokuhirom
そうなんですね、 LINE BOT SDK のJS版ほしいねって話はちょいちょい出ているんですけど基本的に「その言語を使ってフルタイムで書いたことがあるレベルの人に書いて欲しい」って話になっていて、そうじゃないとその言語の流儀とか作法とかわからないと思うというのがあって。UITの人が書いてくれないかなって話にはなってたんですけど、UITの人たちは言うてもフロントエンドなので頼みづらいなという話があって(笑) もしかしたら、この記事が出る頃には公開されてるかも…みたいな、かんじですかね?

―― 喜多
えーと、さっき確認したところ最後のコミットが2ヶ月前でしたが、担当者曰く「メイン案件が忙しくて手を付けられてないけど、今年の半ばくらいまでにはリリースしたい気持ち」とのことでした。

―― tokuhirom
なるほど、リリースまで期待して待っていますね(笑) 弊社では普段の業務で Node.js をサービスで使ってる人ってあんまりいないんですかねえ。

―― 喜多
そうですね。昨日、日韓共同のワークショップというイベントがあったんですが、韓国の方では Node.js を結構サービスで使っているようで LINE の Timeline とか「LINEで送る」ボタンのサーバサイドは Node で動いてるみたいです。

―― tokuhirom
たしかにそれは聞いたことあります。

開発環境と部署内のコーディング規約

―― tokuhirom
開発の環境的なところでいうと、IDEとかエディタとかって何を使っているんですか?

―― 喜多
Visual Studio Code を使ってますが、人によってバラバラですね。Vim 使っている人もいますし。

―― tokuhirom
Visual Studio Code は使いやすいですか?

―― 喜多
結構気に入ってますね、プラグインも充実してますし。一回 Atom 試したことあるんですけど重く感じたんですよね、コアの技術は同じはずなんですけど。Visual Studio Code の方がサクサク動く気がします。

―― tokuhirom
プラグインとかも結構ゴリゴリ入れているんですか?

―― 喜多
そんなに沢山は入れてなくて、 Vim、EditorConfig、ESLint のプラグインとか。そのくらいです。

―― tokuhirom
結構みんな ESLint でチェックとかはまめにしているんですか?

―― 喜多
そうですね、部署内の共通ルールがあって「新しい案件はそれをまず入れる」ってかんじです。

―― tokuhirom
UITのなかでそういうコーディング規約みたいなのはカッチリ決まっているんですか?

―― 喜多
HTML や CSS のコーディング規約はかっちり固まっているんですけど、JavaScript は特に固まってないですね。以前そういった規約を決めた形跡はあるんですけど、更新はされていないようです。

―― tokuhirom
なるほど、それはわりとよくある話ですね(笑) 聞いていると、HTML 書く人と JavaScript 書く人が完全に分かれてる場合もあるじゃないですか。喜多さんは CSS 書くことはないんですか?

―― 喜多
業務では基本しないですね。必要に応じて書きますけど。

―― tokuhirom
そこまで完璧に分業されてるっていうのも珍しいのかなという気もしますけど。

―― 喜多
そうですね。上長と話しているかんじだと、そんなに明確に分けたいわけでもないらしくて。両方書きたかったら別に両方書いてもいいとは言ってます。ちょっとしたランディングページとかキャンペーンページとかは両方できる人が一気に作っちゃったほうが早いと思うんで。

LINE のリポジトリ事情と静的ファイルの配信ツール

―― tokuhirom
前職からずっと JavaScript だけってかんじですか?

―― 喜多
前職は PHP や Rails も結構書いてて、一番最後の仕事が Angular.js を使った SPA の開発でほとんど JavaScript を書いていたので、その流れで来たかんじですね。

―― tokuhirom
じゃあ昔はサーバサイドもやっててみたいなかんじですね。LINEの開発の体制みたいなところでいうと、UITが作業しているクライアントサイドのリポジトリとサーバーサイドのリポジトリが完全に分かれてるじゃないですか。それ結構特徴的だなと思っていて。

―― 喜多
そうですね、最初見た時は面食らいました(笑)

―― tokuhirom
あれもあれで、便利っちゃ便利なんですけど、そもそもフロントエンドエンジニアが完全に別の org になっていて、サーバサイドのエンジニアと完全に別ってのは珍しいなと。
サーバサイドとフロントエンドって一緒なことが多いし、リポジトリ分かれてるのもそうですけど、頑張ってみるってかんじですか。サーバサイドの人がわかるなら JavaScript の中を見たりすることはありますけど、デプロイとかも分かれてるじゃないですか。そこが特徴的だなって。

―― 喜多
静的なファイルを配信する専用の仕組みがあるんですよね。kmb っていう配信用のツールなんですけど。それはちょっと図で書いた方がいいと思うんですけど…

kmbがやっていることを簡単に説明すると、GH:eのリポジトリの内容を静的なファイルを配信するサーバに移すだけです。コマンドがあって、そのコマンドを叩くと、API サーバとやり取りして、そのサーバがリモートのリポジトリを clone/pull して、rsync で静的サーバーに転送すると。UITではデプロイの仕組みとして全体で使っています。

―― tokuhirom
kmbってサーバサイドなにで書いているんですか?

―― 喜多
PHP ですね。

―― tokuhirom
UITは結構モックを PHP で作ったりしてますよね。

―― 喜多
はい、ちょっとモック作ったりとか、こういうちょっとした仕組みを作る時は PHP を使っている印象はあります。

―― tokuhirom
コマンドラインの方も PHP なんですか?

―― 喜多
コマンドラインの方は Node.js で書かれてます。

―― tokuhirom
へー、そうなんですね。ちなみに GH:e にあげたやつって CI とかはしているんですか?

―― 喜多
これやっている案件とやってない案件があるんですけど、例えば、LINE NEWSは CircleCI を使っていて、push した時に hook でテストを実行したり、JavaScript や CSS のビルドをおこない、kmbのコマンドを呼んで直接配信しているようです。

―― tokuhirom
そうなんですね、うちのサービスは基本全部 CDN に静的ファイルあげるみたいなカンジなんで結構いいなと思ってますけど。実際はサーバサイドで生成している HTML から参照する時は、CDNにリンクを貼って見るみたいなかんじですよね。そこらへんもなんか連携の仕組みというか、そういうのも特徴的なのかなって気はしますね。Rails で開発しているような会社さんだと Rails のアプリケーションサーバで CSS とか JS とか合成して配布したりってケースが結構多いと思うんで、昔は普通にアプリケーションサーバに Nginx が立ってて、そこから配信したりとかそういうサービスも多かったんですけど。今は基本 CDN ですね。

サーバサイドからすると、静的ファイルへのリンクはタグナンバーってやつを変えて deploy するだけなんで。なんかフロントエンドエンジニアの人がどんどん commit してきたやつと commit log が混ざらなくて意外と便利だなと思ってるんですけど。kmb で deploy したファイルは上書きするんじゃなくて、毎回タイムスタンプを含んだ別のファイルとして deploy するみたいなかんじなんですか?

―― 喜多
そこはオプションで切り替えられるんですけど、CDNで配信するのでクライアントのキャッシュ破棄の目的でタイムスタンプを付けるようにしていますね。

―― tokuhirom
サーバサイド側の設定ファイルとか新しいタイムスタンプを書いて commit して、サーバサイドは deploy するみたいなかんじで一連の流れが出来るので、切り戻しも簡単なんで便利なソフトだと思ってます。

フロントエンドエンジニアも企画に積極的に参加する文化

―― tokuhirom
仕事をしていて困っていることとかあったりしますか?

―― 喜多
正直にいうと、今ってデザインも別の部署なんですよね。一緒のプロジェクトをやっている人たちが韓国にいたりして、物理的に離れている場合もあって「どういう経緯でそういうデザインになったのか」とか「ここはこうしたほうがいいんじゃないですか」とかそういうやり取りがメールベースでやってしまうとやりづらいなというのはありますね。

―― tokuhirom
近くにいてもコミュニケーションするのって大変ですもんね。静的なサイトだったらまだいいですけど、動きとかも含まれてくると難しいですよね。ボタン押した時の挙動とか動きとかに関してはどんなかんじでコミュニケーションをとるんですか?

―― 喜多
こっちで先に作ってみて、動くもの見せて、こんなかんじでどうですか?と聞いてみて、ここはもっとこうしたい、とフィードバックをもらって、直して、を繰り返しますね。LINE LIVE とかは動きが結構あるんでデザイナのこだわりも強いですし、実現するためにコミュニケーションはよくとるようにしています。

―― tokuhirom
ではちょっと毛色の違う質問をしますね。文化的なものとか重要視しているところって会社によって違いますけど、LINE はどこらへんを重視してると感じますか?

―― 喜多
自発的な行動をすごく求められているなという気はしますね。プロジェクトを特定の誰かが強くリードするのではなく、企画担当がもってきたアイデアに対して色んな部署から人がアサインされてお互いにプロジェクト調整したりとか仕様を詰め合ったりして進めていくってカンジが僕は結構好きですね。

―― tokuhirom
フロントエンドエンジニアの立場から企画に対しても指摘ができるんですかね

―― 喜多
そうですね、前職でもそういった指摘やフィードバックは返せてたんですけど、大きい会社から転職してきた人とかとお酒を一緒に飲んでると「企画が言ってきたものを一方的に作るだけだった」と聞いたりすることもあって、そういうカンジじゃないのがいいなとは思いますね。

―― tokuhirom
うちもそこそこ大きいカンジになってきてはいるものの、意外とフランクにやりとりが出来ますよね。LINE LIVEとか LINE STORE とか作っていて、こだわって作ったところとかありますか?

―― 喜多
さっきも出ましたけど LINE LIVE のコメント欄とかは配信によって大量のデータがくるので、色々試行錯誤しました。開発初期はいったん届いたコメントをひたすら表示してたんですけど、そうすると数万のコメントがあるような配信だとレンダリングのコストが高くて固まっちゃうので、viewport に入っていない要素をレンダリングしないようにしたり、そもそも保持するデータを最大数百件にしましょうとか。

ブラウザごとの挙動の違いはどうしている?

―― tokuhirom
フロントエンドの開発をしてるとブラウザごとの挙動の違いとかもあると思いますけど、気をつけている点とかありますか?

―― 喜多
そこは過去の案件で踏んだ問題の記憶頼みな部分が結構あって「このコードだと、あのブラウザで変なことが起きるんじゃないかな」という予感がしたら、調べています。あとは企画担当から概要を聞いた段階で、そもそもプラットフォームの制約で出来る出来ないみたいな話。例えば「スマートフォンのブラウザだとタップ操作をせずに自動で音の再生は出来ない」などを早めに洗い出してフィードバックを返すようにしています。都度、 Can I Use のようなサイトで調べたり、プロトタイプを作ってみたりというところですね。

―― tokuhirom
企画の段階から技術的なアドバイスをどんどんしてるかんじですね。実際にコーディングするうえで、最初から色々なブラウザで動作確認をすることはないですか?

―― 喜多
そうですね、手元のPCにインストールされているブラウザや部署で共有の検証用の端末である程度は確認しますが、OS、ブラウザのバージョンの組み合わせ全てをカバーするのは大変なので、そこはQAの方にお任せしています。

―― tokuhirom
LINE STORE とか LINE LIVE とかはしっかりQAやるかんじですかね。

―― 喜多
そうですね。基本的なロジックの確認以外にも、色々なOS、ブラウザ、端末で調べていただいています。どっちかというと、最近は、PCよりはモバイルのほうが問題が出る傾向があります。Mobile Safari は、意外と新しいバージョンのほうが変な挙動をしたりとかありますね。最近はあまり考えなくてもよくなってきましたけど、一時期は Android の標準ブラウザが 結構 issue があがってきていました。

―― tokuhirom
ずっと関わっているプロダクトだと色々なことがあると思いますけど、印象に残っていることとか気をつけている点なんかはありますか?

―― 喜多
LINE LIVE の場合はビジネス的なピボットがけっこうあって、それを意識して、コーディングする時も必要以上に抽象化はしないようにしています。最近の JavaScript のビューライブラリはコンポーネント単位でファイルを分割するんですが、一見同じだからという理由でコンポーネント化すると後で「ここだけちょっと変えたい」とか言われる場合もあったりして。

―― tokuhirom
最近は縦動画がメインになったりしましたしね。

新たな技術に対しての取り組みと、社内での共有

―― tokuhirom
仕事をしていて普通に新しい技術を取り入れるということはあると思いますが、更に前の段階の新しいものを見てたり研究したりしていたりしますか?

―― 喜多
そうですね、最近はブラウザにパフォーマンスに関係するAPIやSpecが色々出てきている印象があるので、いくつか試しています。例えば、Resource Hints や preload のような仕様を使って初期表示の改善を試みたり、requestIdleCallback で重要でない処理を後回しにして、描画処理を先におこなわせるようにしてみたり。あとは実際のサービスには導入できていないですが、 HTTP/2 のサーバプッシュでSPAの初回表示に必要なデータを送って、初期表示を改善できないかな、と考えたりしています。

―― tokuhirom
HTTP/2 を使おうって時があったりするんですか?

―― 喜多
CDN に関しては、既に HTTP/2 対応済みで、CSS Sprite をやめたプロジェクトもあります。

―― tokuhirom
フロントエンドを実装していると配信のパフォーマンスをすごく早くしないといけないってこともありますよね。

―― 喜多
そうですね、ライブラリ選定の時のポイントにもなります。最終的に配信するファイルのサイズがどれくらいになるかを気にしていて、Webpack や Browserifyのプラグインでバンドルした結果のうち、円グラフで「このライブラリがこれだけ割合を占めてる」というのがわかるんですよ。Moment.js っていう日付操作のライブラリがあるんですが、結構サイズが大きくて。全体に占める割合が大きかったので、別のライブラリに乗り換えてかなりファイルサイズを削減できました。

―― tokuhirom
結構、配信サイズは気にしてるんですね。

―― 喜多
グローバルで展開しているサービスもありますし、例えば、インドネシアやタイは日本に比べると通信環境が良くないと思うので配信サイズは気にしています。

―― tokuhirom
海外展開多いですもんね、通信環境がよくないと気にすることって他にも増えますか?ファイルサイズ以外に。

―― 喜多
基本的にはファイルサイズだけですかね。

―― tokuhirom
周囲にもそういった技術的なアンテナが高い人はいますか?

―― 喜多
いますね。社内勉強会で発表したり、それぞれのプロジェクトの知見を共有するための GH:e のリポジトリがあって、issueで「こういうTips見つけました」と書いてくれたりしています。外部の勉強会のレポートとかもそこで書いています。


ツールの移り変わりへの対応

―― tokuhirom
フロントエンドはツールの移り変わりが激しいみたいなことがありますよね。どんどん新しいのを使っていく雰囲気はありますか?

―― 喜多
一応試してはみますけど、筋の良さや、そのツールを使うメリット、長続きしそうかどうかといったところを意識して、取り入れるかどうか判断しています。

―― tokuhirom
じゃあ担当がそれぞれ使ってみるかんじなんですね。ボスがOKって言わないと入れられないってことは?

―― 喜多
そういうのはないですね(笑)

―― tokuhirom
外部に向けての活動など、何かしてますか?

―― 喜多
Vue.js のドキュメントを翻訳したりとか、Meetupで発表したりとかしていますね。けっこう気に入っているので。

―― tokuhirom
社内の実務とは少し毛色が違う活動などは何かありますか?

―― 喜多
最近部署内であるのは、ビジネスとかドメインの知識が足りていないのを解消するものでしょうか。LINEのビジネス的なものの関係が結構複雑になってきているので、質問を集めて企画担当に教えてもらおうとしていて、いいなと思います。

Related Post