リリースから10年目を迎えても、やりたいことはまだまだある　iOS／AndroidのLINEアプリを開発するエンジニアの働き方

ミッションはLINEアプリのモバイルエクスペリエンス向上

岡本雄三氏：LINE新卒採用エンジニア座談会ということで、私から、iOS／Androidクライアントエンジニアの業務内容や仕事の環境について説明していきたいと思います。

はじめに、自己紹介いたします。私はLINE Platform Development Center2 モバイルエクスペリエンス開発室副室長の岡本といいます。よろしくお願いします。

当時はまだネイバージャパン株式会社でしたが、私はその頃に、Androidエンジニアとして入社して、リリース直後だったLINEアプリの開発チームに参加しました。

その後、チーム規模の拡大に伴ってマネージャーに就任し、2021年のはじめにあった、組織改編に伴ってモバイルエクスペリエンス開発室副室長に就任しました。現在は、LINEアプリのモバイルエクスペリエンス向上をミッションとした室の運用をしています。

本日は、次のように進行していきたいと思います。

まずは私たちのチームで担当しているサービスについて簡単に紹介して、次に、そのサービスをどのような開発体制で開発しているかを説明します。続いて、クライアントエンジニアがどのような職種の人たちとどのように仕事を進めているかや、1日の仕事の様子などを簡単に紹介していきます。

そのあとに、最近の新人が開発にかかわったタスクの事例を紹介します。サービスの今後の課題や展望を紹介し、最後に、クライアントエンジニアの仕事の環境や開発環境を紹介していきたいと思います。

「LINEアプリ」「LINE公式アカウントアプリ」の開発を担当

ではまず、私たちのチームで担当しているサービスについて紹介したいと思います。

私たちのチームでは、以下の2つのアプリケーションの開発を担当しています。1つ目は、利用してくれている方も多いと思いますが、「LINEアプリ」です。

LINEアプリには、ご存じのように多くの機能があるのですが、私たちのチームでは、主にLINEのコア機能であるメッセージングやソーシャルグラフ、友だちやグループの管理、登録フローやアカウントの管理機能、そしてメッセージング以外の各種機能と連携するホーム／ウォレットタブ。また、LINE内で起動するアプリの開発者向けプラットフォームなどの開発を担当しています。

もう1つ担当しているアプリケーションは、「LINE公式アカウントアプリ」です。LINE内で公式アカウントを友だち追加すると、いろいろな情報やクーポンをもらえると思いますが、LINE公式アカウントアプリは、それらの公式アカウントを運営する側で利用するアプリです。

基本英語が使われるグローバルな開発体制

続いて、これらのアプリの開発体制を紹介していきたいと思います。

LINE株式会社には、いくつかの開発組織があります。LINEアプリのサービス開発は、サーバーサイドの開発を担当するLINE Platform Development Center 1と、クライアントサイドを担当するLINE Platform Development Center 2で、主に担当しています。

それら以外にも、開発3センター、開発4センター、フロントエンド開発センターなどの開発組織があります。開発3センターは、私たちがLINEファミリーサービスと呼んでいる「LINE LIVE」や「LINEマンガ」などのLINE関連アプリを担当しており、こちらにもクライアントエンジニアが所属しています。

また、LINEには東京以外にもLINE Fukuoka株式会社という関連会社があって、そちらにも開発組織が存在しています。国外では、台湾、韓国、タイ、インドネシア、ベトナムなどにも関連会社があって、そちらにも開発組織が存在しています。

そして実際LINEアプリの開発には、東京、福岡、韓国、台湾、ベトナムのクライアントエンジニアが参加しているという、グローバルな開発体制を取っています。

そのため、ソースコードのコメントやドキュメント、チャットでのやり取りでは基本英語が使われています。LINEには通訳者が所属しているので、リモートでの会議では同時通訳を通じてやったり、直接英語でやり取りしたりというケースがあります。

4つの開発室に分かれるLINE Platform Development Center 2

では続いて、私のいる東京側の開発組織について紹介していきたいと思います。LINE Platform Development Center 2には、およそ50名ほどのiOS、Android、QAエンジニアが所属しています。次の4つの開発室に分かれていて、それぞれの室にエンジニアが所属しています。

LINEコミュニケーションプラットフォーム開発室では、LINEのコア機能であるメッセージング機能やコミュニケーション基盤の開発を担当しています。

次に、LINEコンテンツ&サービスプラットフォーム開発室では、ホームやウォレットタブ、LINEアプリ内で実行する各種アプリの実行プラットフォームの開発を担当しています。

モバイルエクスペリエンス開発室では、複数のプラットフォーム、iPhone、iPad、Android、Androidタブレットなどに向けた最適化や、新しいOSの機能への対応などを担当しています。

最後の、LINEサービス開発室は、LINE公式アカウントアプリの開発を担当していて、LINEアプリのQAを担当しているエンジニアが所属しています。

現在、私たちのチームにはさまざまな国の出身のエンジニアが所属しています。ご覧のように、アジア圏が多いのですが、それ以外でも、フランスやオーストラリア、あとはアメリカの出身もいて、チーム内でのコミュニケーションは基本、英語です。

ただ、日本語が得意な方も多いので、そのような方とは日本語でコミュニケーションを取っている状況になっています。

機能を実装するまでのクライアントエンジニアの仕事の進め方

続いては、クライアントエンジニアの仕事の進め方について紹介していきたいと思います。

ここでは、クライアントエンジニアがどのような職種の方と、どのようにコミュニケーションを取って、アプリに新しい機能を実装してリリースするまでを進行させていくかを簡単に紹介していきたいと思います。

開発機能やプロジェクトによって、もちろん異なりますが、クライアントエンジニアは主に、企画者、サーバーサイド開発者、フロントエンド開発者、QAエンジニアやデザイナーといった職種の方々とコミュニケーションを取って仕事を進めていくことになります。

まず、キックオフ／仕様の検討段階では、企画者から開発関連者に、どういった機能を作りたいのか、どういった画面フローで作りたいのかという仕様の説明・共有を行います。エンジニアは、それぞれの立場からさまざまなフィードバックを行い、仕様をブラッシュアップしていきます。

プロジェクトの規模によっては、このような開発関係者とのミーティングを定期的に行って、仕様の策定や開発を進めています。

おおよその仕様が決まってきたら、スライドの右側にあるとおり、開発者内での実装方法の検討に進みます。クライアントエンジニア、サーバーエンジニアの間で、クライアントサーバー間でどのようなインターフェイスのAPIを定義するか、APIの呼び出しフローはどうするか、などをコミュニケーションを取りながら検討していきます。

同様に、クライアントエンジニア、フロントエンド開発者の間で、クライアントとWebアプリ間のインターフェイスやコールフローといったものを策定していきます。

利用するインターフェイスが決まってきたら、クライアントエンジニア内で、どのように実装するか、クラスの構成やアーキテクチャーなどについて議論を行って実装方法の検討を進めていきます。

実装方法が決まると、実際にコーディング作業が始まります。クライアントエンジニアは、他のメンバーに実装したコードのプルリクエストを送って、コードレビューを依頼します。

レビューでは、ここの実装が違うんじゃないかとか、ここの実装をこう変えたほうが読みやすいよみたいなコメントが付くので、それに応じてコードの修正を行って、再度レビューの依頼をします。これを繰り返して、実装を進めていきます。

また、UIの実装は、デザイナーからデザインのガイドをもらって実装を進めます。場合によっては、ガイドに対してクライアントエンジニアからフィードバックを行って、デザインの修正をしてもらいます。

ほかには、開発中に見つかったサーバーサイドやフロントエンド側のバグ報告をしたり、場合によっては仕様の変更をしてもらいます。逆にサーバーサイドからクライアント側の仕様を変更してもらうこともあって、その都度コミュニケーションを取って実装を進めていきます。

開発中に仕様の不明点や、仕様を変更してもらいたい部分が出た場合には、企画者と相談して、仕様の変更や不明点の確認を行って、実装を進めていきます。

リリースからリリース後のクライアントエンジニアの仕事の進め方

実装が完了すると、QA、テストの段階に移ります。仕様どおりクライアントが動作しているか、QAエンジニアが確認をして、バグが見つかった場合は、クライアントエンジニアに報告して、クライアントエンジニアがコードの修正をします。

クライアントエンジニアはコードの修正が完了したら、他のメンバーにプルリクエストを送ってレビューをしてもらい、修正後のアプリを再度QAエンジニアに確認してもらいます。

同様に、UIをデザイナーが確認した時に修正ポイントがあれば、クライアントエンジニアに報告が来るので、これも同様に修正して、プルリクエスト、レビューを受けて修正を行います。

QA期間中はこのようにして、バグやUI、UXの不具合を修正して、アプリの品質を高めていくことを繰り返し行っていきます。

QAが完了するとリリースとなるのですが、リリースしたらそこで終了というわけではありません。リリース後にモニタリングツールなどを利用して、新しいバージョンのアプリでクラッシュが発生していないかモニタリングを行います。

リリース後、QAやサーバーサイドのエンジニアや企画者から不具合報告が来たり、CSを経由して直接ユーザーから不具合の報告が来るケースもあるので、その場合には原因を調査して、影響範囲が大きい部分に関しては迅速に修正バージョンを出しています。

これがおおよその開発の流れになりますが、これまでのフローは、企画者主導の開発です。これ以外にもリファクタリングや、OSの新しい機能への対応、あとLabs機能といって、実験的な機能を追加したり、という開発者主導のケースがありますが、おおよそ流れは同じです。

LINEアプリのケースになりますが、LINEアプリは2週間ごとに新しいバージョンをリリースしています。なのでだいたい、2週間で開発を行って、2週間でQAして、その後リリースします。2週間の開発が終わったら、次のバージョンの開発をすぐに始める、という感じでリリースをしています。

クライアントエンジニアの1日の流れ

続いて、クライアントエンジニアの1日の作業の流れを、LINEアプリ開発者を例に挙げて簡単に紹介していきたいと思います。

LINEの就業時間ですが、開発者は基本、10時から18時半までです。開発職の新卒入社の方は、最初は基本フレックスタイム制になると思います。

入社して半年ないしは1年後ぐらいで、完全裁量労働制になることが多く、仕事を始める時間や終わる時間も、1日に働く時間も個人の裁量に任せられる労働体系になります。

下がクライアントエンジニアが1日、どういう作業をやっているかというイメージです。説明していきたいと思います。

今はほとんどフルリモートで作業しているので、オフィスではなくて自宅で作業をしていますが、仕事を開始したら、だいたいみんな、メールやメッセージを確認します。その後例えば、前日に同僚から来たプルリクエストのレビューを行います。

お昼になると、朝会です。お昼から始めているのに朝会と呼んでいますが、毎日メンバーと15分ぐらいの簡単なミーティングをします。そこでマネージャーが各種の共有事項を共有したり、メンバー内で昨日何やったか、今日は何をやるか、どういった問題に今悩んでいるかみたいな話をして、みんなの状況を共有します。そのまま実装の相談を引き続きしたいという場合は、会議を延長するケースもあります。

LINEでは、1時から2時にお昼休憩をとる人が多いですが、現在は在宅勤務でリモートワークしている人がほとんどなので、あまりみんなとランチに行くことはありません。コロナ禍前であれば、チームメンバーとオフィスの外に食事に行ったり、会社のカフェでお弁当が売られているので、お弁当を買って一緒に食べていました。

昼食後は勉強会です。メンバー内で持ち回りでアプリ開発関連など技術的な話題をみんなで共有し合う勉強会をしています。こちらは、メンバー内でやっている勉強会ですが、別途で開発組織全体向けの勉強会も月1回とかであるので、それに参加するような場合もあります。

その後は、開発に必要なドキュメントを作成したり、今参加しているプロジェクトの定例会議に参加したり、マネージャーとの1on1をしたりします。

マネージャーと週1回とか2週間に1回とか、定期的にやっているミーティングですが、メンバーからは現在の悩みごと、困りごとなどの共有をしたり、マネージャーからは今のタスクの進行方法を確認したり、仕事ぶりに対するフィードバックをしたりなど、成長支援が目的です。

1on1のあとは、今担当しているタスクのコーディングを行って、切りのよいところでプルリクエストを作って、他のメンバーにレビュー依頼を行って、1日の作業が終わります。

これはイメージなので、もちろん日や人、今入っているプロジェクトによって、1日にやる仕事はさまざまです。極端な例で言うと、朝から晩までずっとコーディングしているケースもあると思います。

新人が担当した開発事例

続いては、実際に新卒入社1、2年目ぐらいの方が最近担当したタスクの事例について紹介していきたいと思います。

まず、左側ですがリアクション機能ですね。使っている方もいるかもしれませんが、これはメッセージに対してアイコンでリアクションを設定できる機能です。

機能自体はとてもシンプルですが、実際にリリースするまでには社内テストしたり、リリースするうえでも、この機能を使えるユーザーと使えないユーザーでケースを分けて、どういった反応があるかというA/Bテストをしたり、そういったことを進めながら実装した機能です。

スライド右側は、iOS側のウィジェットの機能です。ホームの画面にトークルームにすぐに移動できるウィジェットがあります。このほかにもニュースとかKeepのウィジェットがありますが、このトークルームウィジェットに関しては、私たち東京側の新人エンジニアが担当しました。

続いて、スライド左側です。これもAndroid側だけですね。edge-to-edge screenの適用といったものです。これは実際に今進行中で、2021年に入ったばかりの方に担当してもらっています。

Androidアプリを開くと、アプリの下の画面、ナビゲーションバーの領域がちょっと黒い背景になっている部分があります。これは実際には右側のように、アプリの描画領域を拡張して、そこの部分をアプリの領域として見せることが可能で、こういったUIの改善を今は行っています。

最後に右側ですが、これはまさに最近入った機能で、iOS15で入った機能をLINEアプリに適用したものです。通知の部分に友だちのアイコンを表示する部分ですね。こういった部分を新人の方が実際に担当しました。

リリースから10年目　LINEアプリの今後の課題と展望

続けて、LINEアプリの今後の課題や展望について共有したいと思います。LINEアプリはリリースしてからもう10年になるのですが、10年とはいえ、まだまだやりたいこと、やるべきことはいっぱいあります。

例えば、LINEのメッセージを「iCloud」や「Googleドライブ」にバックアップして新しい端末でリストアできるのですが、異なるプラットフォーム間、つまりiOSからAndroid、AndroidからiOSにデバイスを変えた場合に、メッセージをリストアすることは今できないので、そういった機能の実装を検討しています。

あとは、セカンダリクライアントといって、iPhoneの場合だったらiPadとか、Apple Watchとかをスマホ端末と同時に使えるのですが、Android側はその機能がないので、Android側のセカンダリクライアント対応や、あとはiPad、Apple Watchに関しても機能の改善をしたいと考えています。

ほかにもいろいろあります。Google AssistantやSiriと連携して、LINEのメッセージを送信をしたり、機能を利用するなどです。あとは、新しい機能の追加だけではなくて、アプリのサイズをもっと小さくしたり、パフォーマンスをもっと上げたりという基本機能の改善ですね。

現在、LINEアプリをビルドするのにけっこう時間がかかるのですが、その時間をもっと少なくするために、内部のモジュール化の構成を進めてビルド速度を改善するという課題があります。

みなさんが入社される時には、こういった多くの課題は改善できているかもしれませんが、新たな課題や、やりたいことがどんどんでてくるとは思うので、ぜひLINEに入社してもらって、これらの課題とか、改善を一緒に進められるといいなと思っています。

業務環境と開発環境の紹介

最後に、仕事をするうえでの環境や、開発環境について紹介していきたいと思います。

現在、LINEの開発者の多くは、在宅勤務でフルリモートの環境で作業をしているのがほとんどです。最初に話があったように、LINEは、「LINE Hybrid Working Style」という制度を設け、コロナの終息後も、リモートワークの体制を維持することになっています。

組織ごとに出社ルールを作っていて、私たちクライアントチームは、現在やっている在宅勤務と、オフィスでの勤務、基本的に希望する人はどちらでも仕事をしてもいいという体制を維持する予定です。

そういう状況なので、現在オフィスはフリーアドレス制となっていて、決められた固定席がありません。出社して空いている席、好きな場所を使えばいいという感じになっています。

開発PCは、基本macOSのiMacやMacBook Proです。場合によっては両方支給して利用してもらっています。コミュニケーションツールは、「Wiki」や「Jira」。チャットツールは、LINEはもちろんのこと、「Slack」なども利用しています。

開発環境ですが、コードレポジトリとしては「GitHub Enterprise」を、CI/CD環境としては「Jenkins」を利用しています。Androidについては、メインの言語はKotlinですが、もちろん古いコードでは一部Javaも使っています。IDEは標準ですが、「Android Studio」を使って、Gradleビルドによってビルド環境を構築しています。

iOS側のメインはSwiftです。こちらも同じく、古いコードにはまだObjective-Cが残っている状況です。「Xcode」や「Bazel」を利用したビルド環境を構築しています。