「あたりまえのことを、あたりまえにやる、“あたりまえ”のレベルが高い開発組織」を目指す　LINEの開発体制・技術スタック・サーバーサイドエンジニアの業務紹介

セッションのアジェンダ

松野徳大氏（以下、松野）：みなさまよろしくお願いします。LINEの松野です。本日はLINEのB2B領域のエンジニアの働き方や働く環境などについて紹介しようと思います。よろしくお願いします。

まず簡単に私の自己紹介です。松野と申します。LINEでBusiness Platform 開発担当のフェローをしています。Official Account開発室というところで、LINE公式アカウント事業担当の開発室長と、Ad Network ＆ Performance室というところでLINEの広告ネットワーク事業担当の開発室の室長をしています。

本日のアジェンダです。会社の説明を簡単にして、そのあとに開発の体制、テクニカルスタック。あとは「こんな課題があって対応しています」という話と「こういう人を求めています」というお話をしたいと思います。

LINEのサービスと収益

まず「LINEはどんな会社？」というところです。LINEは知っている方が多いと思いますが、「LINE」というコミュニケーションアプリを開発して提供している会社です。その中で僕らの部署は、LINEのアプリケーション上で法人ユーザーがビジネスを行うためのプラットフォーム開発を中心に行っています。

LINEのアプリは日本国内で9,200万人のマンスリーアクティブユーザー（2022年6月時点）、グローバルで1億9,300万人のアクティブユーザーがいるという、非常に大きなサービスとなっています。この上でビジネスを展開するので、非常にエキサイティングな環境かなと思います。

LINEはかなりいろいろなtoBのサービスを実施していますが、その中で僕が中心的に見ているのが、LINE公式アカウントというサービスになっています。

LINEのメッセージ配信機能は、LINE公式アカウントからエンドユーザーさんに対してメッセージを配信するという、一番基本的な機能です。それ以外に、ショップカードという、お店に何回か行ったらクーポンがもらえるといったサービス、クーポンですとかチャットなども我々で実装をしてサービス提供をしています。

LINE公式アカウントをどういうユーザーさんに使ってもらっているかは、https://www.linebiz.com/ というサイトで見れます（企業事例、店舗事例）。ナショナルクライアントと言われるような、かなり大手の企業さんから店舗に至るまで、さまざまな規模の企業さんに利用いただいているサービスになっています。

LINEという会社があることはけっこう知っている方が多いと思いますが、そのLINEが何で儲けているかは、外から見るとあまりよくわからない部分かなと思います。スタンプの販売による収益はもちろんありますが、実は広告関連の事業の売上も非常に大きい会社なんです。

僕らが担当しているLINE公式アカウント事業は、LINE全体の約23パーセント程度の売り上げがある中心的な事業になっています。FY2021の実績でいうと727億円とか、そういった規模で大きい売り上げがあるサービスになっています。

LINE公式アカウント事業をいつからやっているかというと、LINEアプリがリリースされた翌年の2012年ぐらいからシステムとしては開発が始まっていて、非常に長い期間開発されている。ただ、ずっと同じシステムを使い続けているわけではなくて、システムの老朽化・技術的負債が溜まってきたので2018年に1回システムをリニューアルしようという話になって、このあたりから新しいシステムを作り始めて完全に書き直しているので、コードベースとしてはかなり新しいものになっています。

それ以外にもさまざまなサブコンポーネントがあり、ショップカードも書き替えています。それ以外にも「LINEで予約」というLINE上で飲食店の予約が完結するサービスなどもLINE公式アカウントのサブシステムとして開発・運用しています。このサービスは2年前から新規で開発して、運用を続けている感じになっています。古くなったコードは日々のリファクタリングや定期的な大幅な書き換えを実施することによって10年近く開発・運用をしているわりには、コードベースはきれいな状態を保ちながら日々開発運用している感じになっています。

開発の体制と技術スタック

次に、開発の体制と技術スタックについて紹介しようと思います。LINEのB2B関連の開発組織で、僕が所属しているのは開発4センターという部署になっていて、LINE公式アカウントの開発室がこの中に入っています。それ以外には、Developer Product室とAd Network ＆ Performance室があります。開発4センターのところにマーケティングソリューション系のサービスは集約されている感じになっています。

LINEの開発の体制みたいなところがどういう感じになっているかというと、LINE株式会社の下に開発4センターという僕らの部署があって、その中にサーバーサイドエンジニアがいます。LINE株式会社の下にオフィシャルアカウントの企画センターがあって、その中にLオフィシャルアカウントの企画室が入っているような体制になっています。

それ以外にも、フロントエンドの部分についてはフロントエンド開発センターという場所にみんな集約されていて、この下にUIT開発4室があります。（スライドを示して）これはナンバリングになっていてちょっとわかりづらいですが、ここに入っている人たちが、主に公式アカウントなどのマーケティングソリューションの担当のフロントエンドエンジニアがいる感じになっています。

LINE Platform開発センター2にネイティブのアプリのエンジニアがいるチームがあります。組織のカットとしては職能になっているのですが、それぞれの組織にLINE公式アカウント担当のチームがあって、集まって日々開発を進める。そういった体制で開発しています。

サーバーサイドエンジニアの業務

今回はサーバーサイドエンジニアのイベントなので、僕の部署にいるサーバーサイドエンジニアが、どういう仕事をしているかを紹介できればと思います。サーバーのプロビジョニングとか技術仕様の策定とか、キャパシティプランニングとか開発はもちろんやっていきます。

あとは、ユニットテストを書いたり、運用、メトリクスの設計・監視、トラブルシューティングなどの運用フェーズまで、基本的にはサーバーサイドエンジニアが1つのチームの中で運用していく体制でやっています。

キャパシティプランニングはある程度の規模以上になった場合、もちろんDBA（Database Administrator）の人やインフラの担当の方に手伝ってもらうこともあります。しかし、最終的な責任はサーバーサイドエンジニア側で持つような体制でやっています。運用フェーズまで含めて自分たちでできるので、エンジニアとしての実力が非常につきやすい環境かなと思っています。

LINE公式アカウント事業で何を作るのか

次に、LINE公式アカウント事業で具体的にどういうものを作るのかというところを紹介しようかなと思います。メッセージ配信とかがやはり主な機能なので、メッセージ配信をするための入稿画面とか、管理画面とか、そういったところはやはりかなりの開発ボリュームを占めています。

一方で、LINE公式アカウントの機能を使って社内のサービスもさまざまなサービスが運用されています。かつ、各LINEのさまざまなファミリーサービス、「LINE〇〇」というサービスがたくさんあるのですが、そのサービスそれぞれが自分たちのLINE公式アカウントを運用しているので、そのLINE公式アカウントを管理するために社内向けのAPIを用意しています。社内向けではありますが、それが80サービスほどあってそれぞれが、かなりハードにAPIをコールしてくるため、このあたりも管理が大変です。

例えば、APIのスペックをちょっと変えたい時でも、社内への連絡などがかなり大変です。

その他、エンドユーザー向けの機能として、ショップカード、クーポン。あとはOA Listという、LINE公式アカウントのランキング機能などのエンドユーザーさんが直接触れる部分の開発もあります。

それ以外に、実際にサービスを利用した上でお金をもらうための決済バッチとか、あとはメッセージ配信をするためのバッチ。そういった部分の開発とか、データを集計するためのデータのパイプラインとか。

そういったかたちでどの部分にも形の違う大量のデータが流れます。これをデータの特性に合わせてうまく保存・処理することが、LINE公式アカウントのエンジニアの仕事です。

テクニカルスタック

テクニカルスタックを紹介したいと思います。LINEの場合特徴的なのが、「Verda」というOpenStackベースのプライベートクラウドで実装しています。「プライベートクラウド」というとどういう感じかよくわからないかと思いますが、実際に使っている感じでは、そんなにパブリッククラウドと使用感は変わらないかなという感じです。

最近はIaaSではなくて、徐々に Kubernetesへの移行を推進しています。プログラミング言語は、最近はKotlinを中心にサーバーサイドでも採用しています。古いサービスはJavaで書かれることもけっこうあります。フレームワークはSpring Bootを中心に使っていて、一部、Armeriaという内製のフレームワークを利用しています。

ストレージの部分にはMySQL、HBase、Redis、Kafka、Elasticsearchとか、そういった非常にベーシックな、わりとどこでも使っているようなミドルウェアを中心に採用して開発をしています。

技術課題

今日の本題の技術課題というところなんですが、技術課題の紹介はけっこう難しいんですよね。課題は日々いろいろと出てきますが、わりとすぐに解決されてしまう問題も多いので、今回はわりと抽象度の高い話題を取り上げてみました。

1つ大きいのは、規模の拡大に伴う問題がやっぱりテーマとしては大きいと思っていて。組織が拡大しているのと、コードベースが拡大しているところがあるので、それぞれでさまざまな問題が発生していて、それに対処しながら日々開発・運用を続けています。

我々の開発組織は現在12チーム57名の組織になっていて、中途の方とかもどんどん入ってくるので、コード品質に若干ばらつきが出てくる。それをコードレビューとかでカバーするのももちろんいいですが、コードレビューの手間もなかなか大変なので、できるだけシステム化できるところはするところに力を入れて対応をしています。

具体的にはコード品質を定量分析するとか、静的解析をコード化していくみたいなところで、QodanaというJetBrains社が出しているツールとかSonarQubeを使ってみたりとか、detektとか、そういった静的解析ツールを運用する。もちろんこのあたりを導入している会社さんはけっこう多いと思いますが、かなり設定とかにもこだわって最近やっています。

それ以外だと、昔ながらのJava開発という感じで、Jenkinsを手でぽちぽち設定をしているみたいなケースも多かったですが、最近はかなり宣言的なJenkinsfileで設定を管理するスタイルに変えています。また、Kubernetesとかもそうなんですが、ファイルで管理されていて設定の変更履歴が見れるのが、やはりなんだかんだ便利だなと。「ノウハウを横展開しよう」みたいなことを考えた時に、ファイルベースになっているほうが「設定をコピペして使ってみてね」ということがやりやすいので、1つのチームで発生したカイゼンが、他のチームに伝わっていきやすくなっているのかなというところです。

あと最近力を入れている技術課題というところでいうと、コードベースはけっこう拡大してきていて。今はKotlinのコードベースがだいたい300万行ぐらい、Javaのコードベースが250万行ぐらいあり、非常に複雑になってきていて、リグレッションも発生しやすくなってきているのかなというところです。

コードが複雑化することによって発生する手動のリグレッションテストのコストがどうしても増大してくるので、そこの部分に関してはインテグレーションテストをちょっと書いて、できるだけシステムで担保するところに力を入れてやっています。

細かいユースケースごとに書いていると時間がかかってしまうので、ファーストステップとして「200 OKを返すかを確認する結合テストをいっぱい書くぞ」という運動をがんばってやっているフェーズになっています。

プラットフォームとして何をやっていきたいか

僕らが今掲げてやっているのが「あたりまえのことを、あたりまえにやる、“あたりまえ”のレベルが高い開発組織」を作ろうということをスローガンにやっています。日々開発者として、そのメンバーもリーダー陣も含めて成長していきたいと考えてやっています。

プラットフォームとして何をやっていきたいかというところでいうと、「LINEのエンドユーザーと企業のコミュニケーションのデファクトスタンダードになっていくぞ」というところを目指してやっています。利用してくれる企業さんの成長を手助けするアクセラレーターとなっていけるような存在になっていければと考えています。

求める人物像

「こんな人を求めています」というところですが、やはりLINE上でサービス提供をするので、エンドユーザーさんにとって「ウザいな」と思われてしまうようなサービスでは困ります。「エンドユーザーサイド、企業サイドの双方に対して、最高のプロダクトを提供するんだ」という熱意がある方を求めています。

あとは、大きなトラフィックや大きな事業規模に触れることができるので、そういったところを支えていきたい方。あとは、ビジネスのグロースに開発観点から関わっていきたい方。トラブルシューティングとかが得意な方は非常にありがたい。いろいろありつつも最終的には、プログラミングやシステム開発が大好きな方が一緒に働いていて気持ちいいかなと思っています。