老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた

新型コロナウイルスの影響下で、食の宅配などO2O（Online to Offline）サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31％増、売上高も前期比で54.6％増となりました（ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています）。

この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。

ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを参画させ、技術力の向上やシステムの強化を図っています。なにしろ2000年にサービスインした出前館には、長きにわたる開発による技術的負債や、レガシーなアーキテクチャが数多く存在しています。

レガシーな老舗ITサービスをいかにモダナイズするか？ 出前館の技術基盤を改善するLINEの4人のエンジニアに、その先にある大きな可能性と興味深い取り組みの詳細を伺いました。ゲストは前回に引き続き、テスト駆動開発の第一人者でありITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。

※ この記事は、LINE株式会社によるSponsoredContentです。

和田 卓人（WADA Takuto、写真上段左） @t_wada twada

タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。翻訳や監修を担った書籍に『テスト駆動開発』『SQLアンチパターン 』『プログラマが知るべき97のこと』『Engineers in VOYAGE』など多数。t-wadaのブログ

山口 淳史（YAMAGUCHI Atsushi、写真上段中央）

LINE サービス開発2室 開発G2チーム
ゲーム開発のクライアントエンジニアを経て、2015年より現職。現在は出前館で、フロントのAPIサーバーの開発を主に担当。

関藤 寛喜（SEKITO Hiroki、写真上段右） @relaxteatime relaxteatime

LINE サービス開発2室 開発G1チーム
通信、金融、ECなどのシステム構築を経て、2019年より現職。現在は出前館にてオンプレミスのシステム管理を行いつつ、システムのクラウド移行や出前館社内のVPNなどの改善検討を行っている。

吉川 英興（YOSHIKAWA Hideoki​、写真下段左） @hideoki hideoki

LINE サービス開発2室 室長
UGCサービスの開発やインフラの構築などを経験し、2010年ライブドアに入社。LINE株式会社に社名変更後は、さまざまなLINEファミリーサービスの開発を担当し、2020年より出前館の開発を統括している。

田中 優之（TANAKA Masayuki、写真下段右） @masayuki5160 masayuki5160

LINE 京都開発室 クライアント開発チーム マネージャー
ネットワークエンジニアとしてキャリアをスタートし、ゲームアプリやカーナビアプリの開発を経て、2020年より現職。現在は出前館で主に法人向けアプリの開発業務を行いつつ、アプリ開発業務全般の改善および検討を行っている。

※新型コロナウィルス感染拡大防止の観点から、インタビューはリモートで行いました。

オンラインを前提に開発拠点を組み合わせてチームを構築

── LINEで出前館の開発を統括している吉川さんにまずお聞きします。今回の提携は、エンジニアリングの面でどういった意味を持つのでしょうか？

吉川　ひとつには、LINEのエンジニアが出前館の開発に参加できることです。LINEには専門性の高いエンジニアがたくさん所属していますから、その力でシステムや開発体制を改善していくことができます。

またLINEには、システム基盤の資産も多数あります。プライベートクラウドの「Verda」とか、データプラットフォーム「Information Universe」などを活用できれば、出前館の事業にもプラスになると考えています。

── 提携が発表されてまだ1年足らずですから実現できていることもそれほど多くないと思いますが、チームに参画して最初に取り組んだのはどういったことでしょう？

吉川　最初はシステムの全体像を把握することから始めて、それに2〜3カ月かかりましたが、その後はまず開発のスピード感を高めるためにチーム編成を検討する必要があると考えました。

出前館は非常に大きなシステムで、エンジニアもプロパーのスタッフに加えて、LINEからも複数名が参画しています。しかし、各人の担当すべき役割が明確でなく、全員でフィールド全体を守備してるような状態だったのです。この体制ではとてもプロジェクトをうまく進められません。

全エンジニアの作業状況を私がひとつひとつチェックするのも不可能ですし、基本的にはひとつのチームがひとつのプロダクトを担当するよう、適切なチーム分けを進めました。

── 現状ではリモート前提のチーム編成にならざるを得ないと思いますが、その状況下で別の組織で働いていたエンジニアが同じプロジェクトで関係を構築するのはハードルがかなり高そうですね。チーム分けの際に工夫したことはありますか？

吉川　出前館には、東京と大阪という2つの開発拠点があります。このうち東京オフィスは移転してLINEのエンジニアと同じ拠点にまとまったのですが、大阪のスタッフは東京にいるLINEのメンバーとなかなかコミュニケーションが取れない。そういう課題を抱えていると、プロジェクトの初期から感じていました。

LINEはもともと対面でのコミュニケーションを重視する文化だったのですが、コロナ禍の影響で在宅勤務になったことから、オンラインのコミュニケーション体制が整っています。また出前館でも、両拠点間ではZoomなどのツールで情報を伝える文化がありました。

こうした前提を踏まえて、LINEと出前館とのコミュニケーションを最適化するためにも、物理的な制約をなくして開発リソースを適切に割り振るためにも、あえて複数のロケーションのメンバーを組み合わせるようにしました。オンラインを前提とした体制を構築するには、ひとつの拠点でまとまらない方がよいと考えたのです。

和田　純粋にエンジニアそれぞれの特性から判断し、ロケーションを気にしないでチームを組成しているということですね。オンラインでのコミュニケーション環境が整備されてきたからこそ、できるようになったことでしょう。

出前館を開発するエンジニアの多くが勤務する南新宿オフィス（イメージ写真はすべて同様）

運用の属人性をなくしてインフラを民主化する

── チームが編成されたということで技術領域ごとの課題をお聞きします。まず20年にわたって運用されてきたインフラはどういう状態だったのでしょうか？

吉川　出前館のシステムの大部分は、オンプレミスのサーバー上で動いていました。しかし、データセンター自体が古く、使用可能なネットワーク帯域やサーバーの設置スペースなどが上限に達しており、これ以上はスケールさせるのが難しいという状況に陥っていました。データベースサーバーの負荷も高く、何らかの改善が必要でした。

── システム改善のプロジェクトに具体的に取り組んできたのは関藤さんですね。データベースの負荷の話は後でお聞きするとして、インフラ全体としてどのような改善を実施したのか教えてもらえますか。

関藤　LINEのエンジニアで、インフラ担当者として最初に配属されたのが私でした。出前館にもインフラ担当チームは存在していたのですが、そもそも運用がメンバーに属人化しているところに課題がありました。障害が発生した際にどのようなオペレーションを行うべきか？ システムのどこに影響があるのか？ 担当チームの限られたメンバーしか分かっていなかったのです。

── つまりシステムの刷新であるとか移行といった前に、運用を標準化することが必要だったということですね。

関藤　先ほど吉川が、始めの数カ月でシステムの全体像を把握していたと言っていましたが、私も同様です。運用の実態を調査したり、業務の作業内容を聞き取ったりしていました。障害が発生したときにも、どのようなオペレーションを実施したかを文章に残すようにしていっています。

和田　エンジニアの持つ暗黙知を可視化して属人性を解消していくことは、こういった改善プロジェクトで重要になりますね。聞き取りと文章化はその有効な手段で、基本に忠実なやり方だと感じました。歴史が長くて規模も大きなプロジェクトに参加したときに、全体像が把握できなくて途方に暮れるエンジニアも多いですから、とても参考になるエピソードだと思います。

── 運用のドキュメンテーションとともに、システムそのものにはどういった改善を実施していますか？

関藤　開発効率を向上させるために、新しくAWSにシステム基盤を構築しています。あわせてTerraformやPacker、Ansibleといったツールを用いて、IaC（Infrastructure as Code）化も推進しているところです。IaC系のツールを使い慣れていない方もいますから、導入のサポートも行っています。

── オンプレミスからクラウドへの移行ということですね。先ほどスケールが頭打ちになっていたというお話もありましたから、その解消が期待されます。

関藤　開発者にとっては本番環境でのサーバー構築や、AWS Lambdaの利用といった権限を付与できることも改善になります。これまで出前館の開発者には、本番環境へのアクセス権限がありませんでしたから。今後はプロジェクト単位でAWSのアカウントを発行し、AWS Organizationsで管理していくような体制を目指しています。

和田　これは本当に大事なことです。オンプレミスのシステムをクラウド化するモチベーションとしてよく挙げられるのが、権限管理やインフラ環境構築の体制改善です。開発者が各環境を利用しやすい状況を整えていく、いわばインフラの民主化ですね。

出前館の改善をともに進めてくれるエンジニアを募集中

• â–¶ シニアサーバーサイドエンジニア / 出前館
• â–¶ クライアント開発エンジニア / iOS / Android / 出前館

まず監視して見つかった課題にリードレプリカと参照APIで対策

── 先ほど吉川さんから話が出たデータベースサーバーの負荷については、どのような対策を実施されたのでしょう。

関藤　データベースサーバーはかなり高負荷になっていて、何かしらアーキテクチャの改善が必要な状態でした。しかし、どんなリクエストで応答遅延が発生しているのかすら把握できていませんでしたから、必要な情報を可視化することが重要だと考えました。

Webサーバーのログを収集するところからスタートしたわけですが、ログ基盤を構築しようにも、先ほど話があったようにデータセンターの設置スペースがいっぱいで、オンプレミスのサーバーを増やす余裕はありません。

── やはり環境の整備が重要になりますね。こちらもクラウドで構築することになったのでしょうか。

関藤　そうですね。Apacheのログを定期的にAmazon S3に格納して、Athenaで解析できるようにしました。

また、リソースの状況をZabbixで監視していたのですが、アカウントを持っているのは運用グループのメンバーだけという状況でしたので、全エンジニアにアカウントを発行し、全員で監視できる体制を整えていきました。

── ログやリソースが監視できるようになると、高負荷の原因も分かってきますね。

関藤　データベースの負担になっているリクエストがいくつか特定できたので、サーバーサイドのAPI開発チームとも連携して、アーキテクチャを変更していきました。このプロジェクトには山口が携わっています。

── それでは山口さんにお聞きしたいのですが、データベースの負荷はどのように軽減していったのでしょうか？

山口　オンプレミスではOracleが稼働しているのですが、参照系のクエリをリードレプリカに投げるような設計に変更しました。PostgreSQLをAWS上に立ち上げて、データをレプリケーションしています。

このアーキテクチャ変更に合わせて参照用のAPIも開発し、フロントエンドからはこのAPIにアクセスさせるようにしました。

── AWS上のデータベースとしてPostgreSQLを選定した理由は何でしょうか？

関藤　当然ですが、MySQLも候補として挙がりました。ただ、システム要件としてテーブル構成を変更できない以上、機能面でよりOracleに近いPostgreSQLを選ぶべきだろうと判断しました。

また、出前館の既存システムには、数百行にもなる長大なSQLがあります。それはそれで改善が必要ですが、現状の業務で求められる性能から判断すると、MySQLは複雑なテーブル結合などでパフォーマンスが劣化する傾向にあるようですから。

── アーキテクチャ構築において苦労されたことはありますか？

山口　テーブルのスキーマ変更に大きな制約があることです。レプリケーションの元になるOracleのテーブルは他のプロダクトでも使用していて影響範囲が大きいため、定義情報を変えることが難しい。そうした制約がある以上は、現在のテーブル構造のままでいかにしてパフォーマンス改善できるかを考えるのが、難しくもありつつ面白いところですね。

── 参照用のAPIを開発されたとのことですが、サーバーサイドではプログラミング言語やフレームワークに何が採用されているのでしょう？

山口　かなり歴史の長いシステムのため、レガシーな技術が残っているところがあります。例えばサーバーサイドは大部分がJavaで書かれていますが、コアのロジックはSeasar2で実装されていました。ご存じのようにSeasar2はすでにサポートが切れていますから、セキュリティ上の問題があります。そのため外部と接している部分にはSpringによるラッパーが実装されています。

LINE・出前館ではサーバーサイドエンジニアを募集中

• â–¶ シニアサーバーサイドエンジニア / 出前館
• â–¶ サーバーサイドエンジニア / LINEファミリーサービス

パートナー企業の開発者ともプルリクエストでコードレビューを

── 続いてアプリケーション開発についてお聞きします。田中さんがプロジェクトに参加されたときにも、やはり状況をヒアリングするところから入ったのでしょうか。

田中　出前館のアプリケーション開発は、パートナー企業や業務委託のエンジニアにアウトソースされていました。そのためアプリケーションエンジニアが出前館社内にはいないので、アプリの仕様についてヒアリングするのも難しい状態だったのです。どのようなアプリが存在しているのかということすら、初期にはなかなか把握できませんでした。

── 開発体制における課題が大きかったのですね。

田中　とくに課題に感じたことは、ソースコード管理です。実装を委託されたエンジニアがバージョン管理ツールに直接コミットするのではなく、いったん出前館の担当者にZipファイルで納品し、担当者がZipを展開してそのまま「何月何日納品分」としてコミットするような運用でした。そのためコミット履歴から変更の意図や、ソースコード修正の途中経過を読み取ることが難しかったですね。

── 開発体制の改善はどのように進めたのでしょう。

田中　課題は明らかですから、むしろ手を付けるべきタスクも分かりやすい。要はシステムの全体像を把握し、Zipファイルで納品されているソースコードを、プルリクエストベースでレビューできる体制に持っていければよいわけです。そこは前向きな気持ちで取り組めました。

── 具体的にはどこから取り掛かりましたか？

田中　まず、レビューする我々の手元でもアプリをビルドできる状態にしたいと考えました。ビルドを担当していたパートナー企業と情報の連携を進め、定例ミーティングに参加したり、Zoomで画面共有してもらいながらビルドの方法を教わったりして、理解した内容をドキュメントに落とし込んでいきました。

── ここでもやはりドキュメンテーションが重要になってくるわけですね。

田中　それから、パートナー企業の開発タスクを部分的に巻き取りつつ、プログラムの内容を把握していきました。そうした地道な活動を続けた結果、開発体制は徐々に改善しています。

直近でリリースしたアプリでは、パートナー企業のエンジニアとプルリクエストをベースにレビューを進めることができました。これは本当に良かった。ひとまず畑を耕すことはできたという感覚になりましたね。

▲プルリクエストに対するレビューの様子

和田　この取り組みも非常に重要ですね。ソースコードのバージョン管理、ビルドの再現性の確立などのソフトウェア構成管理（SCM）はシステム開発における基本です。課題を認識し、タスクを巻き取り、ドキュメントの整備とプルリクエストの導入まで来ることができたのは大きな改善だと思いました。

田中さんも勤務するLINE京都開発室ではエンジニアを募集中

• â–¶ サーバーサイドエンジニア / 京都開発室
• â–¶ iOS・Androidエンジニア / 京都開発室

ニーズが大きな事業を支えるエンジニアリングの醍醐味

── ここまでさまざまな改善についてお聞きしましたが、このプロジェクトなりの前向きな醍醐味（だいごみ）もあるのではないかと思います。それぞれ教えてもらえますか。

関藤　インフラ担当者としては、普通のWebサービスと比べてピーク時とそうでないときのアクセス数が全く違うのが面白いですね。昼食前と夕食前に大きなアクセスの波があり、それ以外の時間帯はすごくアクセスが少ない。珍しいトラフィック特性だと思います。

しかし現在は、こうした特性をインフラ構築において考慮できておらず、サーバーコストの無駄が生じている状態です。今後はコンテナやKubernetesの導入も検討しながら、システム要件に沿ったスケーラビリティを確保したいと考えています。

もちろん実現までには時間がかかるでしょうが、インフラ担当者としては腕の見せ所でもあります。サーバーリソースを最適化し、システムの信頼性を向上させつつ、事業としての利益も最大化させていくのは、技術的に面白いチャレンジですね。

▲出前館の1日のトラフィック推移。時間帯によって大きな変動があることが分かる。
なお、吉川さんによるとフードデリバリーサービスは「晴れの日と比べて、雨の日のアクセス数がすごく多い」そうで、天候によって利用数が大きく左右されるという。ただし降ればいいというものでもなく、暴風雨のときは「宅配が停止になるので、むしろ減る」。

── アプリ開発に携わる田中さんはいかがでしょう？

田中　技術的な面で自分が面白いと感じているのは、地図と位置情報を扱えることです。自動運転などが好例ですが、近年ではユーザーの位置情報や3D地図とアプリのデータなどを組み合わせることで、新しいサービスを創出するケースが増えています。実際に我々も地図＋位置情報＋アプリという技術スタックが重要な要素ですし、そういった技術を扱えるのはエンジニアとして意義があると感じますね。

アプリの開発に関しては、少し余談めいた話になりますが、私はtoBなアプリ開発に携わることが初めてだったこともあり、最初は利用者（この場合では飲食店や配達員）の気持ちを理解することが難しいと感じていました。そこで試しに、自分が配達員になって料理をデリバリーしてみました。

── それは面白い体験ですね。ある意味でドッグフーディングと言えるでしょうか。

田中　アプリがどのように使われているかを学ぶことができ、改善点も見えてきましたから、今後の開発に生かせると思います。

▲関連記事：田中さんがLINE Engineering Blogに書いた2020年7月の記事では、出前館でReact Nativeによるクロスプラットフォーム開発を行った知見が紹介されています。

── 山口さんはいかがでしょう？

山口　出前館では扱っている技術スタックが非常に幅広く、多種多様な技術に触れたいエンジニアにとっては面白い環境だと思います。私も現在はサーバーサイド開発に携わっていますが、機会があれば他の技術領域の開発もしてみたいですし、おそらくそういうチャンスがあると考えています。

吉川　山口も言っているように、このプロジェクトでは幅広い技術領域を学ぶことができます。フロントエンドもサーバーサイドもあり、スマートフォンアプリではtoB向けもtoC向けもある。さらに田中が言うように、位置情報も活用しています。

今回のインタビューではレガシーな技術が残っているという話をしましたが、技術的負債の解消や継続的なアーキテクチャ改善によって足回りが少しずつ整い、さまざまな施策を実現できる体制になってきました。今後は、よりスピード感のある開発により、サービスを自分たちの力で成長させていきたいと思います。

和田　LINEが培ってきた技術的な知見を導入すれば、CI/CDやDevOps、アジャイル的な開発スタイルなどを浸透させて、これからより洗練された開発体制になっていくでしょう。今はまさに開発体制を強化しながら、準備運動をしているフェーズだと感じました。

大規模サービスで開発体制やアーキテクチャを改善するプロジェクトにおいては、どうしても序盤にこういった時期が必要になりますね。おそらく1年後の開発スピードは、現在より桁違いに高速化しているのではないでしょうか。

── みなさんの今後の活躍が楽しみです。

吉川　コロナ禍の影響もあり、フードデリバリー事業全体に追い風が吹いています。このサービスをさらに改善して、宅配を利用する方にも、また飲食店の方々にも喜んでもらいたい。世の中のニーズがこれだけ大きな事業をエンジニアリングの力で支えていくことには、それだけ大きなやりがいがあると感じているところです。

▲関連記事：2020年9月のLINE DAY 2020における藤井英雄さん（株式会社出前館 代表取締役社長 CEO）のセッションでは、世界的なフードデリバリーの可能性や、今後のO2O事業として出前館の展開について語られています。

LINEのO2O事業で募集中のエンジニアポジションはこちら

• â–¶ シニアサーバーサイドエンジニア / 出前館
• â–¶ サーバーサイドエンジニア / LINEファミリーサービス
• â–¶ クライアント開発エンジニア / iOS / Android / 出前館
• â–¶ サーバーサイドエンジニア / 京都開発室
• â–¶ iOS・Androidエンジニア / 京都開発室

ご応募お待ちしております！

【関連記事】LINEのFintech事業から「LINE証券」を支える技術▼

Fintechサービスをスピーディーに立ち上げる技術スタック LINEエンジニアに和田卓人さんが聞く TypeScriptとマイクロサービス基盤 - はてなニュース

[SponsoredContent] 企画・制作：はてな
取材・構成：中薗 昴