LINEのフロントエンド開発を支える「UIT」
清水大輔氏：みなさん、こんにちは。LINEの清水です。少しの間ですが、私のセッションにお付き合いいただければと思います。
さて、私のセッションでは、LINEでのWebのフロントエンド開発についてお話しさせていただきます。
まずアジェンダです。本日は3つの話をさせていただきたいと考えています。まずはLINEのフロントエンド開発の組織について簡単にご紹介します。続いて、これまでLINEのフロントエンド開発の中で行ってきたサービスの開発、またそれらで得られた経験・ナレッジについてご紹介をしたいと思います。そして最後に、最近我々が始めた新しい取り組みについてご紹介いたします。
では、まず組織の紹介をしたいと思います。LINEでは、Webのフロントエンド開発をしているエンジニアが「UIT」という組織に所属しています。
「UIT」という言葉は、おそらくあまり聞き馴染みのない言葉だと思いますが、User Interface Technologyの略です。主に、HTML・JavaScript・CSSなどWebブラウザ上で動くアプリケーションの開発を専門に行う組織です。
現在は海外を含め7つの拠点があります。今年は、新しくベトナムのハノイ、また国内では京都が新しい拠点として加わりました。現在ではおよそ100名以上のエンジニアがUITに所属しています。
LINEというと、おそらくみなさんはiOS・Android向けのアプリケーションを想像するかと思います。一方で、WebアプリケーションはあまりLINEと結びつかないのではないかと考えています。ただ、これだけの規模のエンジニアがフロントエンド専門の組織に所属しています。
各拠点のエンジニアは、ふだんからGitHubやチャットなどオンラインでの交流を行っています。オフラインでの交流としても、不定期ではありますが、1つのテーマを設定してそれに取り組むといった活動を行っています。
今年は「LET’S CONTRIBUTE TO OSS！」という1つのテーマを設け、各拠点のメンバーが一堂に会し、オープンソースへのコントリビュートの活動を行いました。ふだん使っているオープンソースのライブラリへのプルリクエストを送ったり、またはドキュメントの翻訳を行ったり、大小さまざまではありますが、2日間という限られた日程でおよそ100件の貢献を行うことができました。
ふだんのサービス開発とは少し離れ、開発に集中することで、その経験がサービス開発に活かせるのではないかと考えています。
LINEのWebアプリケーション
では次に、実際にサービスとしてどのようなものを開発しているのか、ご紹介していきたいと思います。
LINEでは、非常にさまざまなアプリケーションがWebアプリケーションとして開発されています。みなさんは、どのようなアプリケーションがWebアプリケーションで提供されているか、ご存じでしょうか？
中でも多いのが、LINEの「ファミリーサービス」と呼ばれるものです。
ここに挙げているものはごく一部ではありますが、身近なところだと、LINE NEWSや、LINEスタンプや着せかえなどを購入できるLINE STOREなどがあります。
左上のアイコンは、おそらくみなさんが買い物に行ったりレストランに行った際によく見かけるのではないかと思います。こういった店舗から送られるサービスとして、LINE@というものがあります。
このLINE@を通じてみなさんに送られるクーポンやショップカードも、Webアプリケーションとして開発・提供しています。また、店舗が使うCMS・CRMなどもWebアプリケーションで提供を行っています。
ほかにも、LINE占いやLINEマンガ、LINE LIVEなどはネイティブのアプリケーションとして提供していますが、LINEの中からより手軽に・身軽に・身近に使えるように、Webアプリケーションとしても一部の機能を提供しています。
最近だと、LINEほけんやLINEキャリア、また本日のキーノートのセッションでも少し触れられましたように、ブロックチェーンに関するサービスなどもWebアプリケーションとして提供しています。
LINEは、2011年からiOS・Android向けのアプリケーションとして提供しています。我々は、その翌年の2012年から、このようなWebアプリケーションの開発を始めています。
次は、今ご紹介したようなサービスの中で、どのような経験をして、どのようなナレッジを得てきたかについて、少しお話をしたいと思います。
ここにある動画は、スタンプを購入するフローの動画です。
（動画が流れる）
みなさん、どこがWebで実装されているのかおわかりになるでしょうか？ 実際はスタンプの一覧を表示したり、検索したりといった部分がWebで実装され、それ以外の部分はネイティブとして実装されています。
このように、LINEでは多くのアプリケーションをハイブリッドアプリケーションとして実装を行ってきています。
ブラウザでも、ブラウザの進化に伴いネイティブアプリケーションに近い体験を行うようになってきましたが、実際にはネイティブアプリケーションに多くのアドバンテージがあるのが実情です。そこで、私たちはApache CordovaをベースとしたネイティブAPIの実装を行い、その上でハイブリッドアプリケーションの開発・提供をしてきています。
（動画を指して）このサンプルのアプリケーションのように、ハイブリッドアプリケーションとして実装する場合、ネイティブからWebに遷移するときに自然なUXを提供することが、よいUXの考え方の1つではないかと我々は考えています。
3つのAPIの特性を理解して設計を行う
次は、こういったハイブリッドアプリケーションを実装する中で得たいくつかの経験について、お話をしたいと思います。
（スライドを指して）この図は、Webアプリケーションから呼ばれるAPIを大きく3つに分類したものです。それぞれの特徴を見ていきたいと思います。
Browser API。これは、みなさんもご存じのとおり、ブラウザで実装されているWeb標準のAPIとなります。デバイスの情報を取得したり、最近だと、Service WorkerによってPWA（Progressive Web Apps）も実装可能になっています。
ただし、LINEでBrowser APIを使うと考えた場合、ユーザーのデバイスがさまざまあることやWebViewを使っていることなどから、いくつかのAPIが利用できなかったり、互換性という部分で大きな問題を抱えたりすることがたびたびあります。
続いて、Server APIです。Server APIも、みなさんご存じのとおり、HTTPプロトコルなどをベースとしたネットワークを返すAPIのことです。キャッシュをうまく利用できるようなAPI環境であればパフォーマンスは悪くはないのですが、それらを利用できない場合、非常にコストの高いAPIとなってしまいます。
そこで我々は、こういったAPIの欠点を補うために、Native APIの実装を行っています。例えば、LINEのアプリケーション側でキャッシュしているデータをWebから直接取得することができれば、先ほど話したようなネットワークのコストは下げることができます。また、LINE独自でAPIを実装して提供することで、我々の中で互換性もコントロールすることが可能となります。
ただ、これも銀の弾丸ではなく、欠点はもちろんあります。例えば、LINE独自で実装していることにより、LINEに新しく入社した方への学習コストがかかるという問題はあります。またもう1点、ネイティブアプリケーションにAPIを実装するため、アプリケーションを一度リリースしたあとの変更が難しくなります。そのため、APIの実装・設計にはとても注意が必要です。
私たちは、こういったAPIの特性を理解してうまく設計を行い、それぞれ使うべきシーンに合わせて利用することが、ハイブリッドアプリケーションを実装する上で大事だと考えています。
次に、少しJavaScriptのコードの話をしたいと思います。LINEで提供するアプリケーションの多くは、シングルページアプリケーションとして実装されているものが非常に多くあります。その際、JavaScriptの肥大化が問題となるケースがあります。
そうした問題を解決する方法の1つとして「Code Splitting」という技術があります。おそらくフロントエンドのエンジニアの方であればご存じだとは思うのですが、JavaScriptをCode Splittingにより小さなファイルに分割して、必要になったときにオンデマンドでロードする、といったものです。
Code Splittingのライブラリやユーティリティは、オープンソースですでに多く存在していましたが、私たちの提供するあるサービスでは、既存のCode Splittingではうまく設計にフィットしないケースがありました。
そこで、私たちは「grow-loader」という独自のCode Splittingを開発して、一部のサービスで利用しています。grow-loaderが特徴的なのは、メソッドの上に「@grow」というデコレータをつけることで、メソッド単位でのCode Splittingが可能となります。
これに関しては、弊社のエンジニアブログのほうで詳細は紹介されているので、興味のある方はそちらをご覧いただければと思います。また、すでにgrow-loaderはオープンソースとして提供されていますので、より詳細を知りたい方はそちらもご覧いただければと思います。
UXの改善事例
続いて、UXの改善について、事例を2つご紹介したいと思います。画像や動画などが多いリッチなコンテンツをWebアプリケーションとして実装する場合、どうしても初期表示に時間がかかってしまいます。
当然、なにも考えずに実装すると、ユーザーは最初の画面を見るまでに数秒、もしくは数十秒かかってしまいます。一般的にユーザーがなんらかのページを開こうとしたとき、そのページに対して関心を持っていられるのは数秒までとされています。そのため、LINEではできるだけユーザーの関心が離れないようにするために、スケルトンスクリーンの実装を一部のサービスで行っています。
おそらくスケルトンスクリーンはネイティブアプリケーションで多く実装されていると思いますが、LINEでは先ほどから紹介しているようにハイブリッドアプリケーションとして実装しています。ネイティブからの自然なUXを提供するために、こういったところにも工夫を行ってきています。
次にご紹介するのはページトランジションについてです。ネイティブと同じような自然なUXを提供するため、iOSで提供されているようなページトランジションをWebアプリケーションでも実装しています。
（ページトランジションの動画が流れる）このサンプルを見ておわかりになるように、左スワイプをするとページバックが行われ、前のページがそのままスタックされて残っているため、再ロードが走ることなく、スムーズなページ移動が実現できています。
このように、通常のWebアプリケーションでは想定されないようなUXの問題改善を我々は行ってきています。ただし、これらのUXの改善や工夫は、闇雲に行うだけでは意味がありません。実際にユーザーがどのように使い、これらの改善が数値としてどのように役に立っているのか、定量的にデータを収集して分析することが重要になってきます。
そのため、私たちは独自のWebトラッキングサービスを構築して利用しています。LINE Analyticsと呼ばれるものです。LINE Analyticsの中でとくにWebブラウザからデータを収集する部分などの基盤のことを我々は「torimochi」と呼んでいます。
LINE ANALYTICSの詳細については、昨年、弊社の川崎から紹介していますので、より詳細を知りたい方はそちらをご覧いただければと思います。
今年は1点、torimochiに関するアップデートをご紹介したいと思います。それはヒートマップツールの「yakimochi」です。
先ほどのツールの名前は「torimochi」ですが、こっちは「yakimochi」です。もちが好きですね。もう1つ、実は「mochigome」というツールもあったりします（笑）。
torimochiを使ってデータを収集したあと、それらのデータがプランナー・デザイナーに見えないと意味がありません。それをこういったヒートマップツールを使うことで、プランナー・デザイナーもしくは開発者のそれぞれが、実際にどのように使われているのかを分析して見ることができます。例えば、A／Bテストを行って、ご紹介したようなUXの改善の前後でどのような変化が現れたのかを見ることが可能となります。
フロントエンド開発で利用しているライブラリ
続いては、フロントエンド開発で利用しているライブラリやツールについて少しご紹介したいと思います。
ここまで紹介したようなハイブリッドアプリケーション以外にも、通常のChromeやSafariなどで動くアプリケーションも開発をしています。先ほど紹介したようなサービスで使われるCMSやCRMなどが多く開発されています。
そんななか、共通のUXや開発のスピード、またクオリティなどを担保するために、我々にはUIフレームワークが必要でした。そのため、Bootstrapをベースとした「koromo」と呼ばれるUIフレームワークを開発して利用しています。
また、弊社ではVue.jsと呼ばれるJavaScriptフレームワークを多く利用する機会があります。そのVue.jsとkoromoを組み合わせてコンポーネントライブラリ化した「koromo-vue」と呼ばれるものを開発して、各サービスで利用しています。
現在、koromo-vueでは約40のコンポーネントを提供しています。少しサンプルをご紹介したいと思います。このサンプルコードは、LINEのSticker一覧を表示してユーザーが選択するといったものです。
おそらくVue.jsやReactなどを書いたことある方であればとくに目新しいところはないと思うのですが、タグを書いて、JavaScriptの中でユーザーが選択したイベントに対してイベントを行う。そういったコードになっています。
このように、LINEの中ではStickerを選択するようなUIが非常に多く使われます。そういったコンポーネントを共通のコンポーネントとして開発で利用できることで、先ほど紹介したように、開発スピードを上げられ、品質という面でも非常に高めることが可能となっています。
ほかには、CSS周りの話をしますと、弊社ではSassを利用することがとても多くあります。「mixin」など共通のものをライブラリ化した「sasslai」と呼ばれるものを利用しています。
1つ例を挙げると、昨年iPhone XがAppleから発売されましたが、新しい概念として「セーフエリア」というものがありました。セーフエリアの対応のためにCSSでの対応が必要でしたが、sasslaiで対応を行うことで、各サービスに対してスムーズに対応を行うことが可能となりました。
LINEが提供するWebアプリケーションのフレームワーク「LIFF」
ここまでは、これまでLINEで提供してきたWebアプリケーションの開発とその経験についてのお話でした。次は、私たちが最近始めた取り組みについてご紹介したいと思います。
LINE Front-end Framework、略して「LIFF」と呼ばれるものを、今年の6月にリリースしました。これはLINEが外部に向けて初めて提供するWebアプリケーションのフレームワークとなります。
LINE上でユーザー同士のコミュニケーションをより豊かにするためには、LINEの開発コミュニティのみなさんによりアイデアを出していただき、開発していただくことが大事だと考えています。
これまで、Messaging APIやLogin APIなど、さまざまなAPIを提供してきていますが、UIに関する実装については限界がありました。しかし、LIFFを使うことでさまざまなUI・UXの表現が可能となります。
これはLIFFを使った簡単なサンプルアプリケーションです。
下からせり上がってくる画面がLIFFの画面となります。ユーザー同士のチャットの中にインテグレートされたかたちで表示されているのがおわかりになると思います。
簡単にフローを説明しますと、スキーマをタップするとLIFFが起動します。その起動時にネイティブアプリケーションのほうで認証が行われ、必要なトークンがWebViewに渡されます。あとは、WebViewでそのトークンを利用してユーザーのプロフィール情報を取得して、LIFFの中に表示を行っています。
そして、Sendボタンがこの中にあり、それを押すと、ユーザーのプロフィール情報を使って、Messaging APIを通してユーザーのプロフィール画像と名前がFlex Messageとして送信されています。LIFFで使えるMessaging APIは、Flex Message以外に、テキスト・画像・動画・ほかのメッセージタイプにも対応しています。
LIFFではJavaScript SDKを提供しています。非常に簡素なコードでLIFFのAPIを利用することが可能です。これは初期化とプロフィール情報を取得するサンプルコードです。
先ほどのフローでも説明したとおり、認証やそのほかトークンの受け渡しなどはLINE SDKの中で行われます。INITが完了すると、LINEのAPI・LIFFのAPIが実行可能となります。LIFFのGET PROFILE APIを実行することで、ユーザーのプロフィール情報が取得できます。
こちらはMessaging APIのサンプルです。
GET PROFILEのAPIと同様に、非常に簡素なAPIメソッドとなっています。LIFFで使えるMessaging APIがこれまで提供していたBot向けのMessaging APIと比べて特徴的なのは、ユーザーからユーザーに対してメッセージを送れるという点です。
これはテキストを送るサンプルです。先ほど言ったことの繰り返しになりますが、オブジェクトの中身を変えることでほかのメッセージタイプも送信することが可能となっています。
LIFFを使ったアプリケーションの事例
続いて、実際にこのLIFFのSDKを使って開発されている事例を1つご紹介したいと思います。「CHAT APP PLATFORM」と呼ばれるプロダクトの中の1つで、「Tenor GIFs」というアプリケーションをLINEの中で提供しています。
トークルームのプラスボタンを押していただくと、Tenor GIFsを起動することができます。Tenor GIFsを起動すると、選択したGIFアニメーションを選んで、それをトークルームに送信することが可能です。スタンプとはまた異なるコミュニケーションの手段が、このようにLIFFによって提供されています。
これはTenor社と提携して開発されたものです。Webアプリケーションをすでに開発して持っているところであれば、LIFFのSDKを組み込むことで、比較的容易にLIFFのアプリケーションを構築することが可能となっています。
LIFFでは、アプリケーションの種類により、いくつかのVIEW TYPEと呼ばれるものを提供しています。アプリケーションの特性によりVIEW TYPEを使い分けることで、さまざまなアプリケーションを構築することが可能となっています。
例えば、先ほど紹介したTenor GIFsのような「Chat App」と呼ばれるものです。Chat Appでは「compact」や「tall」を利用して、チャット画面とインテグレートされたようなかたちで表示して、ユーザーに提供することが可能です。また、より情報が必要なものやゲームなどのアプリケーションの場合は「full」タイプを利用することができます。
続いて、すでに開発コミュニティのみなさんにも、多くのLIFFを使ったアプリケーションを開発していただいているので、いくつかご紹介したいと思います。
まず、「いまどこ（IMADOKO）」というサービスです。こちらは、グループにBotを招待して、そのグループに参加しているユーザーが位置情報を共有することで、LIFFの中でリアルタイムに位置情報を共有できるというサービスです。
非常にシンプルなサービスですが、これまでLINEの中でもありそうでなかった強力なツールを提供していただけていると思います。これはLIFFで地図を使ったUIの開発が可能となったことで実現されているよい例ではないかと思います。
続いては「MY BODY BOT」というアプリです。LINEが提供しているAIプラットフォームの「Clova」のスキルとして提供されているアプリケーションです。音声を使ってClovaに体重を登録することで、LIFFアプリケーションを使ってその体重の推移を確認することが可能となっています。
このように、ClovaやBotなどとLIFFを組み合わせて利用することで、さまざまなアプリケーションの開発が可能となっています。とくにLIFFでは、ここでご紹介したような地図のUIやグラフなど、UI面での補完に非常に便利に使えるフレームワークとなっています。
時間の都合上、すべてのアプリケーションをご紹介することはできませんが、すでにコミュニティのみなさんに500以上のアクティブなLIFFのアプリケーションを提供していただいております。先日行われた「LINE BOOT AWARDS」の中でも、LIFFを使ったさまざまなアプリケーションが応募としてありました。
LIFFは、FirebaseとHerokuなど、PaaS・BaaSみたいなものを利用することでサーバレスで開発することができ、非常に開発コストが低く始められるフレームワークとなっています。
本日のセッションで少しでも興味を持った方がいらっしゃれば、ぜひLINEのデベロッパーサイトにアクセスしていただき、LIFFのアプリケーションの開発をしていただければ幸いです。
みなさんからフィードバックをいただきつつ、これからもワクワクするようなさまざまなアプリケーションの開発やAPIの提供をしていきたいと考えておりますので、ぜひご期待いただければと思います。
私のセッションは以上となります。ご清聴ありがとうございました。
