やると決めたら絶対にできる　LINEのスタンプショップをNativeからWebに変更するまでの道のり

ノルウェー出身のバイキングなエンジニア

ライテン・ヨン・エドバード氏：みなさん、こんにちは。ヨンと申します。今日はスタンプショップのリニューアルプロジェクトについてお話ししたいと思います。アニメーションや絵文字など、それぞれのスタンプショップのページをNativeからWebに移行したプロジェクトです。よろしくお願いします。その前に、このプレゼンは英語と日本語でしているので、好きなほうを選んで聞いてみてください。

では、自己紹介をしたいと思います。私はライテン・ヨン・エドバードです。32歳です。ノルウェー出身です。みなさん、バイキングを知っていますか。ノルウェーの海賊のことなのですが、私は海賊なのでモノを盗みます。8年前に日本に来て、日本の美人（な妻）を盗んでノルウェーに連れて帰りました（ジョークです。結婚しました）。

私のふるさとは、ノルウェーの西にある3,000人ぐらいの小さい町です。街のみんなが知り合いなんですよ。2020年からは福岡に住んでいます。福岡の人口とノルウェーの人口はほぼ一緒ですが、福岡のほうがコンパクトで住みやすいと思います。福岡は私のふるさととまったく違いますが、福岡での生活には慣れてきたと思います。

2020年の2月からLINE Fukuokaにフロントエンドエンジニアとして入りました。ちょうど新型コロナウイルスがはやる前に入社しました。2ヶ月ぐらいはオフィスで働いていたのですが、すぐに在宅勤務になります。

家族は妻と4歳の子どもがいます。小さな子どもがいて在宅勤務をするのは、なかなか難しいですよね。みなさんも大なり小なり、同じような経験をしたことがあると思います。

では、本題に入ります。今日のトピックは、スタンプショップのリニューアルプロジェクトについてです。すべてのスタンプと絵文字のページを、NativeからWebに変換しました。

スタンプと絵文字のページは、この10年間ほとんど変わっていませんでした。そろそろ、新しいページを作らないといけない時期でした。私たちは以前、いくつかのリストページをNativeからWebに移行しました。それが良かったので、スタンプと絵文字のページも移行しました。

NativeからWebに移行したことについて、もう少し説明しますね。最後にWebで開発しづらい点についてお話ししたいと思います。私の発表を聞いてくださるみなさんに、私たちの経験がお役に立てるとうれしいです。よろしくお願いします。

本日のアジェンダはこちらです。まず、スタンプショップを軽く紹介いたします。何が変わったか、なぜ新しいページを作ったか、メリットはあるか、Webページを作るならなんのツールがあるか。最後にいろいろなハードルについて説明し、どうやって対応していったかについてお話ししたいと思います。

NativeからWebに変わった「スタンプショップ」

スタンプショップとはなんでしょうか。恐らくLINEの使っているみなさんなら、スタンプや絵文字を友だちに送ったことがあると思います。LINEのホームタブからニコニコしている顔をクリックすると、スタンプショップが開きます。かわいいアニメーションの文字や、サウンド付きスタンプなどが見つかります。

数年前からスタンプショップが実装されました。しかし、NativeとWebが混ざっていました。もともとのスタンプのページは、開いたらNativeのページのままだったのです。今は、全部Webになりました。

いつWebになったと思いますか。けっこう最近です。今年（2021年）の8月末。気がつきました？　Nativeのときのスタンプのページは、こんな感じでした。実は入社したばっかりの時に、自分のスタンプを作ってみました。このスタンプは、息子のEdosukeと、妻と私です。ぜひ使ってみてください。

次は同じページですが、Webです。大きな変化はわからないかもしれませんが、このような改良をするのに、だいぶ複雑でした。これについては後でもうちょっとお話ししたいと思います。

違いをよく見るために、ここに2つのページを並べました。NativeとWebです。デザインが変わったのがよくわかりますね。

どうしてWebに変えたのか

最新のバージョンを一般公開するのに、ちょうど1年ぐらいが掛かりました。いったいなぜこの改良をしなければならなかったのでしょうか。一番大事な理由は2つです。メンテナンスとスピードです。

まずメンテナンスです。すべてのページをWebにすると、2つじゃなくて1つのコードベースになります。AndroidとiOSの、機能と動作は一緒になります。新しいフィーチャーを実装する時、AndroidとiOSを同時に追加できます。デザインも同じです。

さらにNativeのLINEアプリでバグが発生すれば、そのLINEバージョンでは直せません。新しいバージョンをリリースしないといけないです。そのLINEバージョンを使っているユーザーは不安ですよね。Webなら、すぐに直せます。さらにすべてのユーザーに一斉に直せるので、ユーザーも便利です。

あとスピードです。Webだといつでもどこでもリリースできます。ユーザーのニーズに応えて、新しいサービスや便利な機能などを早く作ってリリースできます。

1つのコードベースだと、通信時間、実装時間、機能とデザインのテストの時間が短くなります。UIのデザイナーはピクセルにまでこだわっている人が多いので、小さな変化だけでも、時間が掛かります。WebがNativeよりいいと言い切ることはできませんが、この2つの理由で、Webに変更しました。

ところで、ずっとWebと言っていますが、スタンプショップはアプリから開きます。それならWebではないのでは？　と思うかもしれません。確かに、スタンプショップはLINEのアプリから開けますが、アプリのWebビューを使っています。

Webビューは、ブラウザと一緒です。だからこそボーナスメリットがあります。すべてのブラウザーをサポートせず、端末のブラウザーだけサポートすればいいのは、デベロッパーにとって助かります。そうじゃないと、ちょっと大変かもしれません。

モダンWeb開発にて、JavaScriptのフロントエンドフレームワークはたくさんあります。フレームワークを使うと、開発はもっと早くなるし、丈夫だし、役に立つと思います。ただ、一番良さそうなのを選ぶのは、難しいと思います。各フレームワークに長所と短所があるからです。

例えばFlutter、Angular、React、Vue、それ以外もたくさんあります。私たちは、Reactを選びました。なぜかというと、スタンプショップはもともとReactでしたから。その時になぜReactを選んだかはまた別の話になるんですが、何を選べばいいかは、チームとプロジェクトによると思います。

Webに変える際に大変だったこと

先ほどからメリットばっかりについて話ししましたが、大変なこともありました。Webの開発も、実装しづらい短所があります。実装ができない機能もあります。できるとしても、時間的に難しい時があります。そのため、スペックの方針を変えなければならなかったり、また不安な点のそのままにしておいたり、もしくはWeb開発の限界までできるだけ実装するかもしれません。

今から大変な点についてお話ししたいと思います。一番わかりやすいハードルは、恐らく「戻る」という動作だと思います。iPhoneと違って、Androidは「戻る」というボタンがあるので、だいぶナビゲーションが複雑になります。なぜかというと、Custom history stackを操作するのが難しいからです。しないなら、ワークアラウンドを作らないといけません。

popstateのイベントを利用することで解決できるかもしれませんが、それを実装しないなら、普通のブラウザのようなWebナビゲーションにしないといけません。

次に、アプリのキーボードも操作しにくいと思います。例えばキーボードを開くためには、ユーザーはその前に絶対Webのアプリを1回は触らないと駄目です。画面をスクロールしたりタッチしたりしたら、キーボードが開くようになります。Webアプリが開く時に、一緒にキーボードが開くのは無理です。

また、キーボードを開く場合、Webページのフローが変わります。例えばfixedかstickyのCSSルールが変わります。

こちらの動画をご覧ください。ヘッダーは一番上にくっついていて、フッターは一番下にくっついていますが、アプリのキーボードが開いたら、もうくっつかないんですよ。このハードルは、開発を始めてからわかってきて、ここからスペックの方針を変えていくのは難しかったです。

iOS側を直すのは、簡単そうに見えて、わりと難しいと思います。fixedかstickyの代わりにabsoluteが使えるかもしれません。window.innerHeightのイベントを登録して、Heightの変化があったら、恐らくアプリのキーボードが開きます。そのため、ヘッダーやフッターなどの要素の位置を変えられます。

あと、Webの共有機能は、Nativeより少ないです。Web Share APIで、Nativeの共有メカニズムを一部呼び出すことはできます。ただ、現在サポートしているブラウザーは少ないです。

モバイルのブラウザーの場合、SafariとAndroid Chromeブラウザのみです。WebView Androidはサポートしていません。今私たちは、URLをコピーすることで対応しています。

スワイプの機能も、開発者は自分で実装しないといけません。もちろん、フレームワークによるかもしれませんが、Nativeはこれをすでにサポートしています。優越的にいい機能だと思います。

スライドを見てください。新しいページに移動します。次に前のページ戻すと、前のページが見えます。このようにWebで実装するのは難しいと思います。こちらは2つのページがよく見えます。

一般公開のリリースが近づいた際、とっても大変なことが発見されました。それは、端末のマナーモードでした。Webはマナーモードを呼び込めません。どうしてこれが大変だと思いますか？　気になりますか？　スタンプショップには、サウンド付きスタンプがあるからです。

サウンド付きスタンプのページを開くと、サウンドが一気に聞こえてしまいます。しかし、マナーモードに設定している人は、音を出したくないですよね。例えばバスや電車でスタンプを見ていて、突然音が鳴ると困ると思います。なので、すぐに変えました。

ここまで紹介して、問題ばっかりじゃないですか、と思われているかもしれませんね。でもReact NativeやFlutterといったフレームワークもあります。そのフレームワークは、先ほど言った問題についても対応しているかもしれません。もしみなさんが新しいプロジェクトを始めるなら、このようなフレームワークを検討してもいいかもしれません。

大きなプロジェクトをリニューアルする際の注意点

次はWebの問題ではないのですが、一般的に大きなプロジェクトをリニューアルしたら、いろいろ注意する点があると思います。どんなプロジェクトでも、今から説明する注意点について、考えたほうがいいと思います。

現在のシステムやアプリを別のところに移動すれば、すべての連携や依存関係を見つけるのは難しいと思います。例えば、ユーザーがクリックによって移動するなどの連携が抜けてしまうかもしれません。

この問題に対応するためには、リグレッションテストを行ったり、他のチームとコミュニケーションを取ったり、現在のスペックを読まなければならない。それをやるのに時間が掛かるので、チームワークは大事だと思います。

下位互換性を損なう可能性があるので、削除はしないことが大事だと思います。例えばアプリケーションを壊さないように、APIのレスポンスのAttributeは消さずに、変更しないで追加だけしたほうがいいと思います。URLも同じです。URLを変更しないで、追加だけなら安全です。URLの変更が必要であれば、ちゃんとしたリダイレクトルールを設定すれば、大丈夫かもしれません。

次はリリース方針についてです。一気に、すべてのユーザーにリリースしたほうがいいでしょうか。または、少しずつリリースしたほうがいいでしょうか。少しずつのほうがいいと思います。なぜなら、何か問題が発生しても、影響が大きくないからです。

影響が大きくなければ、サーバーのロードをちゃんとモニターできます。さらにエラーが出るユーザーが少なくて済みます。あと、前のNativeアプリと新しいWebアプリを比べることで、それぞれのユーザーの使いやすさなども比較できます。

やると決めたら絶対にできる

今までは、Web開発のメリットと大変なことについて説明しました。これが理解ができると、もっと簡単に方針を立てられると思います。特にユーザーが誰なのか知っているのなら、もっと簡単だと思います。

例えば企業のためのニッチシステムを作成して、ChromeとSafariの一番新しいバージョンだけを使っているユーザーだと、古いブラウザーのサポートはしなくても済みます。CSS FlexやCSS Gridなどを使っても平気だと思います。先ほど言ったWeb Share APIも使えるかもしれません。

もし、ユーザーが外で働いて、特別なハードウェアを使って、例えばiPadだけでレポートを作成するなら、Nativeのままのアプリを作ったほうがいいかもしれません。やはりユーザーは誰か、ユーザーのニーズは何かを知っていれば、いい選択ができると思います。そうすれば、時間もリソースも減らせます。

最後に、みなさんに伝えたいことがあります。もしみなさんが新しいプロジェクトを作ったり現在のプロジェクトを移行させる時、私たちの経験がお役に立てるとうれしいです。やると決めたら絶対にできます。応援しています。

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