目に見える部分だけではなく目に見えない部分も担当　チャットコミュニケーション全般を担うコミュニケーションプラットフォーム開発室

自己紹介と本日のアジェンダ

堀屋敷勉氏（以下、堀屋敷）：それでは私から「LINEコミュニケーションプラットフォーム開発室の紹介」をいたします。

まず、自己紹介をします。私はLINEコミュニケーションプラットフォーム開発室室長の堀屋敷勉と申します。2009年に入社をして、当時はまだLINEという社名ではありませんでしたが、検索サービスサーバーサイドを担当していました。

LINEの立ち上げに伴い、LINEアプリのAndroid担当になり、その後、LINEアプリ開発チームの1チームのマネージャーを経て、現在はLINEコミュニケーションプラットフォーム開発室の室長をやっています。よろしくお願いします。

こちらが本日お話しする内容です。まずは、チーム構成とチームのミッションを話しながら、LINEコミュニケーションプラットフォーム開発室がどのようなチームなのかを紹介いたします。ただ、これだけだと具体的なイメージはしづらいと思うので、過去、実際に行ってきた活動と、これから私たちのチームが何をしていきたいのかという未来の話を紹介いたします。

最後に、今回の紹介から見えてくるチームの特徴についてお話ししようと思っています。

LINEコミュニケーションプラットフォーム開発室を構成する2つのチームとそのミッション

まずはチームの構成とミッションです。こちらは先ほども説明があった、クライアント開発組織の組織図です。今紹介しているのは、一番左側のLINEコミュニケーションプラットフォーム開発室です。LINEコミュニケーションプラットフォーム開発室は、コミュニケーション基盤開発チーム、コミュニケーションサービス開発チームの2つのチームに分かれています。

開発室のミッションと、配下にある2つのチームの役割について説明をしていきたいと思います。LINEコミュニケーションプラットフォーム開発室のミッションは「チャットコミュニケーションの活性化及び維持」です。

LINEの基本機能であるチャットを使いやすくしたり、コミュニケーションを便利にする新機能を追加したりすることで、コミュニケーションの活性化を図ります。また、使いにくさからのユーザー離れを阻止するために、ユーザーのペインポイントを解消したり、機能改善を素早く行うための環境を整えていったりなど、チャットコミュニケーション全般を担当する開発室です。

LINEコミュニケーションプラットフォーム開発室の配下にある2つのチームですが、基盤開発チームはコミュニケーション機能を提供するための基盤になる部分を担当していて、サービス開発チームは、その基盤を使ったサービスの提供が主な担当になっています。

もう少し具体的な話をすると、基盤開発チームはデータ管理ロジックや、サーバーとの通信部分を担当していて、サービス開発チームは、UI/UXを担当することが多いです。この2つのチームの関係性は非常に強く、頻繁にコミュニケーションを取りながら開発をしています。

組織上チームは分かれていますが、この2つのチームの垣根は高くないと思っています。実際、メンバーの空き状態次第では、チーム間でタスクのやり取りをするなどのコミュニケーションが頻繁に行われています。以上がチーム構成とミッションについての説明でした。

「リアクション機能」「Flex Message」を開発・改善

これだけでは具体的なイメージがしづらいと思うので、次は過去に行ってきた活動内容を紹介します。

私たちが行っていることで一番わかりやすいのは、新しい機能の追加やUI/UXの改善です。チャット画面のほとんどの機能やUIは私たちが担当していて、今までも多くの改善を行ってきました。その中のいくつかを紹介したいと思います。

1つ目は、比較的最近リリースした「リアクション機能」です。受信したメッセージに対してリアクションできる機能で、メッセージを受け取った時に「読んだよ」「いいね」といったことをカジュアルに伝えられる便利な機能になっています。

またこれは、主にLINE公式アカウントが利用しているメッセージタイプの「Flex Message」です。LINE公式アカウントでは、その用途や目的によって、独自の形式のメッセージを送りたいという要望があります。その要望を叶えるための機能で、LINE公式アカウント側でメッセージの形式を決めて送ることができます。

Flex Message以外にも、LINEには画像、音声、ファイル、位置情報、連絡先など本当にさまざまな形式のメッセージがあります。これらの改善も私たちが担当しています。

データ同期基盤と通信基盤も担当している

ここまでは目に見える部分の事例を紹介しました。目に見える部分だけではなく、私たちは目に見えない部分に対しても多くのことを行っています。次は、この目に見えない部分の事例を紹介します。まずはその前に、LINEで扱っているデータがどのように管理されているのかを簡単に説明します。

（スライドの）一番上の部分はLINEのアプリで保存しているデータです。LINEには非常に多くの種類のデータが存在しています。基本的には、データの種類ごとに担当チームが決まっていて、担当チームでデータを管理しています。私たちのチームでは、友だち、グループ情報、トーク設定、メッセージなど、主にコミュニケーションに必要なデータを扱っています。

クライアントで管理しているデータは、ほとんどサーバーデータのコピーになっています。マスターデータはサーバーにあり、クライアントは常にサーバーとデータを同期して、データを最新の状態に保っています。この同期を行うための共通の仕組みがあって、それがこの図のデータ同期基盤という部分です。

先ほど、サーバーとのデータ同期が必要だと説明しました。そのサーバーと通信するための処理にも共通の仕組みがあって、それがこの図の通信基盤の部分に当たります。Apache thriftや、Googleのプロトコルバッファなどのデータシリアライゼーションや、ネットワーク通信などが実装されている部分だと思ってもらえるとイメージがしやすいかなと思います。

このデータ同期基盤と、通信基盤の部分も私たちが担当しています。次は、LINEでどのようにサーバーとデータを同期しているのかを簡単に説明したあとに、実際に私たちが行っている事例を紹介したいと思います。

まずは図の説明ですが、（スライドの）左側がクライアントで、右側がサーバーで持っているデータです。例えば他のユーザーが自分の名前を変更すると、サーバー上にあるフレームデータが変更されます。この変更がクライアントに同期される流れについて、簡単に説明したいと思います。

まずデータに変更があると、その変更がクライアントに通知されます。友だち情報が変更されたことを知ったクライアントは、サーバーに最新情報をリクエストします。サーバーは最新情報を返却し、クライアントは受け取った最新情報をもとにクライアントのローカルデータベースを更新します。

こうすることでクライアントのデータとサーバーのデータが同期されました。

一見よくある手順に見えますが、これを完全に実装するのは非常に難しいです。なぜかというと、さまざまな場所で問題が起こるからです。

例えばクライアント側にバグがあって、変更イベントを受け取ったにも関わらずデータベースを更新しなかったり、OSのバグでデータベースを更新しなかったり、またはアプリの強制終了やストレージのキャパシティオーバーなどで予期していなかった問題が起きて、データベースを更新できなくなる可能性もあります。また、同じような内部エラーがサーバーサイドで発生するかもしれません。

実際の件数は少ないのですが、原因不明のデータ不整合は起きています。こういったデータ不整合をなるべく小さくするために、私たちはいろいろな取り組みをしています。

例えばクライアント側から定期的にデータを同期する処理を実装したり、サーバーからクライアントに対してデータ同期リクエストを送れるようにしたり、最終手段として、ユーザー自身がデータ同期を実行できるようにする、など、日々、データ同期処理の改善を行なっています。以上がデータ同期基盤の事例でした。

続いて、通信基盤部分の事例を紹介いたします。LINEクライアントとサーバーの通信には、SPDYと呼ばれるプロトコルをパフォーマンス最適化のために、独自のカスタマイズを加えて利用していました。そのため、最新のオープンソースライブラリを利用できないなど、いろいろな問題があって、HTTP2プロトコルに変更をしています。

これだけだとプロトコルを変えただけで簡単そうと思うかもしれませんが、実際はすごく大変な作業でした。「LINE DEVELOPER DAY 2021」で詳しく話をしているので、ここでは詳細な話は割愛します。アーカイブ動画もあるので、もし興味があれば、そちらを見てもらえればと思います。

このとおり、私たちのチームはコミュニケーションに関係するUI/UXの部分から、データの同期や通信基盤などの低レイヤーまで、かなり広い範囲を担当しています。

チームとしてこれから挑戦したいこと

では続いて未来の話として、私たちのチームでこれから何をしていきたいと思っているのかを紹介します。機能追加や改善はもちろん今までどおり行っていく予定ですが、先ほどお話ししたデータ同期や、通信の話のような開発主導だからこそできることも継続してやっていきたいと思っています。

具体例の1つ目は、「LINEでのユーザー体験をLINE外にも提供する」ということです。日本では多くの人がLINEを利用しており、LINEでのチャットコミュニケーションは多くの人にとって馴染みがあるものだと思っています。このユーザー体験を、そのまま他のアプリに提供できれば、おもしろいことができるのではないかなと思っています。

例えばゲームアプリで一緒にプレイしている人たちとのチャットをLINEのUIでやったり、メディアアプリのコンテンツに対するコメントをLINEのUIを利用してコメントしたりなど、いろいろなことができると思っています。

ほかにも、コア機能のマルチプラットフォーム化もやりたいなと思っています。

この図のとおり、現在はプラットフォームごとにいろいろな処理が実装されています。ですが、データを処理している部分や通信部分は、プラットフォームに依存しないコードが多いです。なので、この図のようにプラットフォームに依存しない部分に関しては、Kotlin Multiplatform Mobile などを使ってコードを一つにまとめて、プラットフォーム依存が強いUI/UX部分だけに集中して開発できる環境を作りたいなと思っています。

ただ現実はそんなに甘くはありません。なぜなら私たちのコードベースは複雑になっているからです。LINEアプリのリリースから数年間は、スピードを重視した開発だったため、多くの技術的負債が作られています。その負債がある状態で、10年間同じコードベースを使ってメンテナンスし続けています。

LINEのユーザー体験を外部に提供するとか、コア機能のマルチプラットフォーム化をするとか、お話ししましたが、それを実現するためには、技術的負債をある程度返済することが先決です。このためにこの先も、比較的多くの時間をクラス構成の再構成、リファクタリング、モジュール化などの技術的負債の返済に使っていきたいなと思っています。以上がこれまでの活動と、これからやっていきたいことの紹介でした。

自分の体験をもとに機能を開発・改善できる

最後にここまでの紹介のまとめとして、チームの特徴について話していきたいと思います。まずはなんと言っても、よく利用する機能に対して、機能追加や改善ができるというのが大きな特徴だと思っています。実際にLINEでチャットしたことがある人は本当に多いと思います。その自分の体験をもとにさらなる改善をしたり、自分が利用する可能性の高い新機能を開発できたりと、モチベーションを高く保ちながら開発ができるのではないかなと思っています。

また私たちのチームでは、活発に設計レビューやディスカッションをしています。すでに説明したとおり、チャットコミュニケーションに関係するコードは長く生きているコードで、複雑になってしまったものが本当に多くあります。なので、設計変更やリファクタリングをする機会が多く、そのために私たちはよく設計レビューやディスカッションをしています。

スライドの右側のドキュメントが設計のドキュメントなのですが、こういったドキュメントをもとに頻繁にディスカッションを行っています。私たちが扱っているチャットはLINEの基本機能であるため、万が一問題が発生した時のユーザーへの影響は非常に大きいです。

そのため、すごく慎重なリリースが必要になってくるのですが、こういった状況下で数多くのリリースを経験している経験豊富なメンバーもいて、そういった人からレビューを受けたり、一緒にディスカッションができたりというのは、良い特徴かなと思っています。

クラス設計が好きだったり、長くコードと付き合っていく方法を見つけたいという方には適した環境なのではないかなと思っています。実際にそういうことが好きなメンバーは、私の視点ではありますが楽しくやっているように見えます。

以上がコミュニケーションプラットフォーム開発室の紹介でした。