自己紹介

岡本拓也氏（以下、岡本）：こんにちは。「すべてのLIFFアプリ開発者の開発体験を向上させるために」というタイトルで発表を始めます。「LIFF（LINE Front-end Framework）」や「LINEログイン」といったデベロッパープロダクトにおいて、テクニカルプロダクトマネージャーを担当している、岡本です。

以前は「LIFF SDK」のテックリードとしてLIFFに携わっていました。2021年から現在の担当となり、LIFFプロダクト全体の権限と責任を持ち、ユーザーへの提供価値をともに考え、サービス機能開発の内容を決定する仕事をしています。では次、上野さん。

上野康平氏（以下、上野）：LINEでフロントエンドエンジニアをしている、上野康平です。現在は「LINEバイト」と、LIFFのプロジェクトを担当しています。LIFFでは、主にデベロッパーエクスペリエンスの改善に向けたツールなどの開発に従事しています。

岡本：本日はこの2名で、LIFFチームで取り組んできた開発体験に関する考え方と、実際の取り組みについて紹介します。

LIFFについて

まずLIFFについて簡単におさらいしましょう。LINE Front-end Frameworkは、通称LIFFと呼ばれており、LINE上で動作するWebアプリケーションを開発するためのプラットフォームです。Webアプリケーションなので、当然、HTML、CSS、JavaScriptなど、Webのスタンダードの技術で開発が可能です。

さらに、LINEプラットフォーム上の情報や、LINEアプリと連携した機能を、JS SDKを通じて扱えます。

LIFFは、社内ではデベロッパープロダクトと呼んでいます。（スライドを指して）図で示しているとおり、LIFFの最初の利用者はデベロッパーです。そのデベロッパーがLINEから提供されたLIFFの機能を用いてサービスを作り、そのサービスを通じてエンドユーザーが価値を受け取ります。

つまり、デベロッパーに一貫した機能や開発環境を提供すれば、結果的にエンドユーザーにも一貫したUXを提供できます。

LIFFチームの数値目標

LIFFチームでは、事業目標とは別にプラットフォーム独自のKPIとして、Quality、Productivity、Flexibilityを数値目標にしています。デベロッパーは、LIFFに依存しながら開発を行います。LIFFがダウンすると、あらゆるサービスがダウンしてしまいます。LIFFの生き死にが、世のサービスの生き死ににかかわってくるということです。

信頼されるプラットフォームであり続けるために、LIFF自体の品質、またサポート体制を高く維持するミッションがあります。このミッションを達成するための指標が、QCDF（Quality、Cost、Delivery、Flexibility）をベースに考えた、3つのKPIです。

（スライドを指して）上から、品質、生産性、柔軟性です。品質は、変更失敗率を最小限にすること。生産性は、提供した機能の価値と提供までのスピードを上げること。柔軟性は、サービス満足度を上げることが重大になります。

LINE社内外において、LIFFの開発体験の向上はこれらKPIにもポジティブな影響を与えます。DeX改善の成果物が、ユーザーである開発者や新しい価値を提供します。

つまり、価値ある機能を素早く提供することが重要なファクターである、ProductivityのKPIに影響を与えます。あわせて、Flexibilityの要素である開発者満足度も改善されるでしょう。

また、DeX改善の成果物は、社外に対してだけでなく、社内でも適用できるようにデザインされます。LIFFチーム自身がそれら成果物を利用するため、LIFFチームが提供する今後の機能の品質も同様に改善できます。

開発体験とは何か？

そもそも開発体験とは何でしょうか？　（スライドを指して）2011年に『UX Magazine』で投稿された『Effective Developer Experience』という記事からの引用です。

上からいきます。開発者とプラットフォーム間の信頼関係が構築されているか。デベロッパーは大量の時間をかけてプラットフォーム依存の実装を進めるので、プラットフォームは信頼できるものである必要があります。

次に、学習がしやすい環境であるか。ドキュメントだけでなく、ベストプラクティスのデモやシステム連携の例を伝えることも大事です。3つ目は、開発ツールが提供されているか。社内開発者がそのツールを使ってアプリを開発しているなら、それは社外にも提供するべき。そういった考えもここで紹介されています。

そして最後に、提供機能自体の品質と使いやすさ。一貫性のある適切なエラーの返却は大事な要素です。一貫性のある仕様は、結果的にエンドユーザーにも一貫性のあるUXを提供できます。

UXとユーザーを開発者と設定することで、UX評価基準をDeXにあてはめられると考えています。これは、UXハニカムと呼ばれるUXを構成する重要な7要素を示したものです。

周囲の6要素が満たされれば、中央のValuable、ユーザーが感じる価値のある体験が創造されるという考え方です。UXを評価する際にしばしば引用されることがある図です。

LIFFのDeX問題点

（スライドを指して）上から反時計回りに、DeXの文脈に読み替えながら紹介しつつ、LIFFでのDeX問題点を紹介します。

Usefulは文字どおり、役立つかどうかです。LIFFのDeXの問題点として、SDK自体が大量のソリューションを提供しているわけではなく、かつオープンソースではないので、外部デベロッパー目線で言えば機能拡張性に不安があります。

Usableは、どのような目的の開発者にとっても簡単に使えること。役立つけれど、使えないなら意味がありません。LIFFはLINEアプリと結合していることから、ローカル環境やLINEアプリ上でのデバッグが困難といったDeXの問題点があります。

Findableは、シンプルに必要なものに案内できるかの明確さ。効率的に開発が行えるかどうかとも言えます。ドキュメントだけでは、実際に利用してみるまでAPIの意味が理解しづらい問題があります。

Credibleは、プラットフォームとの信頼関係のほかにサービスの安定性、Stabilityとも言えます。正直、LIFFの現在の状況を知ることは難しいです。障害情報が社外に告知されるまで時間の開きがあり、速報とは言いづらく、社外の開発者にとっては何が起こっているのか判断がつきにくいです。また、開発中サービスにLIFFを用いていると、品質保証、特に負荷試験が行いづらい問題があります。

Accessibleは文字どおりアクセシビリティですが、どのような技術レベルのデベロッパーにも使えるべきという意味にも捉えられます。SDKとフロントエンドフレームワークといった他ソリューションと組み合わせて使用する際に、ベストプラクティスがわからないなどの問題があります。

最後のDesirableは、開発者が使いたいと惹きつけるものであるかどうかです。ここまで紹介した問題点をそれぞれ解決してあげることで、DeXの改善につながると考えています。

（スライドを指して）さて、これらのペインポイントに対して、現在LIFFチームで進行中のそれぞれの解決方法がこちらになります。

これらはWebサイトや、ライブラリ、公開済みであったり、公開前であったりと、さまざまな形式とステータスです。上から反時計回りに、「Plugin-able Architecture」「LIFF Inspector」「LIFF Playground」「LINE API Status」「LIFF Mock」「Starter app」と呼ばれるソリューションが、今LIFFが抱えるDeXの問題点を解決してくれます。

私からの説明はここまでにして、各解決方法の詳細は上野さんにバトンタッチして説明していただきます。

LINE API StatusとLIFF Playground

上野：はじめはLINE API Statusの紹介です。LINE API Statusは、LINEが提供するAPIの稼働状況を網羅的に確認できるサイトです。

万が一、APIに障害が発生した場合は、発生時間や発生事象をいち早く確認できます。現時点では「LINE Messaging API」、「LINE Developersサイト」が対象となっています。LIFFや「LINEミニアプリ」については今後対応する予定になっています。

次は、LIFF Playgroundです。LIFF Playgroundは、LIFFのすべてのAPIの挙動を素早く確認できるLIFFアプリです。各APIをその場で実行でき、また、そのレスポンスをその場で確認することが可能です。自身でLIFFアプリを作成する必要はありません。また、各APIへのドキュメントのリンクが整備されており、仕様も確認しやすくなっています。

LIFF Starter

次は、LIFF Starterです。LIFF Starterは、LIFFアプリのサンプルが集まったリポジトリです。LIFFアプリを作成したいけれど、ドキュメントではどこから実装を始めたらいいかがわかりにくい問題を解決します。プレーンなJavaScriptによる実装から、ReactやVueといったSPAフレームワーク上でのLIFFアプリまで、さまざまなサンプルを用意しています。

これらのコードはLIFF SDK開発者によってメンテナンスされており、常にベストプラクティスに従った実装となっています。ぜひ参考にしてみてください。

そして、2020年のLINE DEVELOPER DAYでも話したとおり、LIFF SDKは現在、LIFFのコア実装とAPI実装を分離したPlugin-able Architecture化を進めています。この設計により、独自のAPIをプラグインというかたちで実装でき、それによってLIFF SDKを拡張できます。

また、プラグインというかたちで第三者へ拡張機能を公開することが可能になります。（スライドを指して）このコード例のように、LIFFプラグインはLiffPluginインターフェイスを実装したクラスとして作成します。そして、SDKはliff.use APIを用いてプラグインを読み込みます。

こうすることによって、この例ではliffオブジェクトにinitメソッドが追加され、拡張機能としてそれを利用可能になります。

LIFF Mock

LIFFプラグインの一例であるLIFF Mockを紹介します。現在LIFFプラットフォームは、サーバー負荷の観点からLIFFアプリケーションの負荷テストを許可していません。また、LIFF SDKがサーバーに強く依存しているため、単体テストが書きにくくて困った経験はないでしょうか？　そんな問題をLIFF Mockが解決します。

LIFF Mockを導入すると、SDKはMockモードと呼ばれるモードとなります。このMockモードではサーバーと完全に独立するため、負荷テストや単体テストを容易に実施できます。

このLIFF Mockは、先ほど説明したLIFFプラグインとして提供されます。（スライドを指して）このコード例のようにLiffMockPluginを有効にすると、liff.init時にmockモードを指定するオプションが追加されます。

このmockモード下ではサーバーと完全に独立し、各APIは任意のmockデータを返却する挙動となります。この例では、liff.getProfile APIをコールしています。しかしSDKはmockモードなため、実際にはサーバーと通信しておらず、デフォルトで設定されたmockデータを返却する挙動となっています。

LIFF Inspector

最後は、LIFF Inspectorです。ブラウザーに組み込まれているDevToolsは、Webアプリを開発する上で、デバッグのためになくてはならないものとなっています。しかし、LIFFブラウザーには同様のツールが存在していませんでした。そのため、LIFFアプリの実行ログやネットワークアクセスを確認することは現状不可能です。

そんな問題をLIFF Inspectorが解決します。LIFF Inspectorは、LIFFブラウザーとChrome DevToolsをリモートで接続し、ふだんのWebアプリ開発と同様のデバッグ体験を提供するデバッグツールです。LIFF Inspectorを使うと、実機上で動作しているLIFFアプリのコンソールログやネットワークログをキャプチャしたり、アプリのDOM情報をインタラクティブに取得することが可能となります。

（スライドを指して）実際にLIFF Inspectorを使ってLIFFブラウザーをデバッグしている様子をご覧ください。左側はiPhone実機、そして右側は手元のPCのChrome DevToolsです。

はじめに、ネットワークログの取得から見ていきます。見ていただいているとおり、LIFFアプリのネットワーク通信を自動でキャプチャし、その詳細な情報が表示されています。リクエスト先のURLやリクエストヘッダ、レスポンスヘッダなどを見れています。次に、コンソールログの取得です。LIFFアプリを立ち上げてから、さまざまなログが表示されています。

そして最後に、エレメントタブです。LIFFアプリのDOM情報が表示されています。このDOM情報は、実際に実機上で動作しているLIFFアプリケーションのものであることに注意してください。各エレメントにマウスオーバーすると、実機側の対応するエレメントに青いオーバーレイが表示されています。

DOM情報の表示ができたので、次にDevTools側からDOMの変更を行ってみます。今見ていただいたように、インタラクティブにDOM情報の取得、変更が可能です。

これらのデバッグは、通常のWebアプリケーション開発ではよくある、慣れ親しんだ手法です。LIFF Inspectorを使うと、その手法をLIFFブラウザーに適用することが可能になります。LIFFアプリの開発がよりWeb-Orientedなものとなりました。

そして、このLIFF InspectorもLIFFプラグインとして提供します。LIFFプラグインをインスタンス化し、WebSocketのURLを指定します。これにより、その後の実行ログなどは自動でキャプチャされ、手元のPCのChrome DevToolsへと送信されます。

LIFF Inspectorが提供するデバッグ方法としては、DOM情報の取得、変更といったDOM Inspection、コンソールログの監視、ネットワークログの監視。この3つを予定しています。

LIFF Inspectorの内部では、我々が開発したHeadless Inspectorというパッケージを利用しています。Headless Inspectorは、ヘッドレスという名のとおり、UIを持たないWeb Inspectorです。JavaScriptの各メソッドコールに応じてさまざまなイベントを発生させます。

このコード例では、コンソールログAPIを実行した際に、inspector変数がconsoleAPICalledというイベントを発生させています。そしてアプリケーション本体の挙動に影響を与えないために、APIコールのインターセプトにはJavaScriptのProxy、Reflect APIを用いています。

Headless Inspectorから発せられたイベントを、Chrome DevToolsに送信することによって、LIFF Inspectorは実現されています。headless-inspector-coreから発せられた各イベントは、真ん中の図のようにheadless-inspector-cdpパッケージによって、Chrome DevTools Protocolに変換されます。

このプロトコルのおかげでChrome DevToolsはアプリケーションの実行ログを理解し、その情報を表示することが可能になります。

これら2つのパッケージとLIFF Inspectorは、OSSとして公開を予定しています。LIFF以外にもさまざまな場面で活用できるパッケージだと思うので、みなさんぜひ利用してみてください。

ファーストリリース段階ではLIFF Inspectorは、実機と手元のPCをリモートで接続してデバッグできるツールとして提供予定です。

今後のロードマップとして、例えば実行ログをLINE Developersに送信することによってWeb上で実行ログを確認できるようにしたり、DevToolsのUIを実機内に表示するBuilt-in UIも提供予定です。今後のLIFFアプリのデバッグ体験の向上にご期待ください。

LIFFプラグインとCreate LIFF Appは2022年上旬に公開予定

最後にまとめです。（スライドを指して）はじめに紹介した3つのサイト、LINE API Status、LIFF Starter、LIFF Playgroundは、すでにスライドのURLにて利用可能となっています。また、本日紹介したこれらのサイトをまとめたものをLINE Developersのニュース記事として公開しています。ぜひそちらから各サイトへアクセスしてみてください。

そして、Plugin-able Architecture、LIFF Mock、LIFF InspectorといったLIFFプラグイン。そして1つ前のセッションで池田さんに紹介していただいた「Create LIFF App」については現在社内実験中となっています。社内でのフィードバックを反映し、2022年上旬の公開を予定しています。

このセッションの前半では、我々がいかにLIFFの開発体験を重要視しているかを説明し、その上で認識しているLIFFアプリ開発のペインポイントを紹介しました。後半では、それらのペインポイントを解決するさまざまなサイトやツールを紹介しました。

我々はこれからも、誰でも簡単にLIFFアプリを開発できるような環境を作るべく、さまざまな取り組みを行っていきます。これからもLIFFをよろしくお願いします。

以上で発表を終わりにします。ご清聴ありがとうございました。

Published at