25年続くシステムの変革を目指して

皆さんこんにちは。本日は「出前館アプリ進化論 〜アーキテクチャと組織のリアルな変革の舞台裏〜」と題して、変革が必要だった背景をご紹介したあと、どのように変革したのかを2つのフェーズに分けてお話しします。

本題に入る前に、自己紹介をさせてください。植松 啓誠と申します。LINEヤフー株式会社の京都開発室に所属しており、2021年より出向という形で出前館に関わっております。出前館では、プロダクト本部のコンシューマー部 アプリ開発グループでテックリードを務めています。2021年まではWebフロントエンドエンジニアとして、ReactやVue、BFFなどを書いていました。出前館に参画してからは、React NativeやFlutterでモバイルアプリの開発をしています。

出前館はアプリやWebから注文できる国内最大級のデリバリーサービスで、47都道府県で展開しています。「ミッション：テクノロジーで時間価値を高める」「ビジョン：地域の人々の幸せをつなぐライフインフラ」「バリュー：ホスピタリティ、チャレンジ、クリエイティビティ」を大切にしながら、日々プロダクトの改善に取り組んでいます。

こちらは出前館のサービスの全体像です。ユーザーがアプリやWebから商品を選んで注文すると、注文情報が出前館のシステムを経由して加盟店へ送られると同時に、効率よく配送ができる配達員を探します。その後、配達員が注文商品をユーザーまで届けてくれます。

システムのアーキテクチャは大きく3つに分かれていて、それらが連携してサービスが動いています。

1つ目は、ユーザーが注文を行うコンシューマー領域です。ユーザーが出前館を開いて注文するお店を決めて食べたい商品を選んだあと、注文処理や注文がいつ届くかなどの情報を伝達しています。

2つ目の加盟店領域は、ユーザーからのオーダーを提供するお店側のシステムです。営業時間や商品の管理のほか、配達員とのコミュニケーション、ユーザーからの注文をお店に伝える領域です。

3つ目は配達員の領域です。稼働している配達員を管理し、温かくて美味しいご飯を早く届けるために、効率良く配送できる配達員を見つけ、ユーザーに配達時間の予想を伝える領域です。

これらのシステムが連携しながら、出前館のサービスは稼働しています。どれか一つでもシステムが止まると出前館全体のサービスがストップしてしまうため、全て重要な領域です。本日は、主にこのコンシューマー領域のアプリ目線で、変革の歴史を共有します。

出前館は1999年に会社設立され、2000年にサービスを開始しました。つまり、25年続くサービスであるとともに、25年続くシステムが裏側に存在します。25年もサービスが続くのはすごいことですが、歴史的な背景やシステム設計など、積み重なった課題がたくさんあるのも予想できると思います。

そんな中、変革の契機が訪れます。2020年、出前館は当時のLINE株式会社と資本業務提携を締結しました。この資本業務提携を契機に、LINEのエンジニアが出前館の開発に参画し、これが大きな変革のスタートにつながります。

ここからは、20年運用が続く巨大なサービスをこの5年間でどのように変革したのか、についてお話しします。きれいなアーキテクチャというよりも、地道で泥臭いアーキテクチャ移行についてのお話です。

変革フェーズ1「各コンポーネントでの課題把握と改善」

2020年に何があったか覚えているでしょうか？世の中は新型コロナウイルスの流行で、いわゆるパンデミック状態でした。外出規制などがされる中、出前館の取扱高は前年同月比400%という急成長を遂げました。事業としては、またとないチャンスです。しかしシステム的には、準備期間が少ない中で突然サービスの負荷だけが4倍になる状況でもありました。

20年積み重なった課題がある中で、いかに事業成長を止めずに技術的な課題を解決していくかが我々のミッションでした。そこでまず取り組んだのは、各コンポーネントで、それぞれの課題に向き合うことです。

～インフラの課題～

インフラが抱えていた課題として、出前館は20年近くオンプレミスサーバー上で稼働していましたが、既に需要の高まりに対応することが難しい状況に陥っていました。具体的には、サーバーの設置スペースがなく、ネットワークの帯域が上限に達しているなど、これ以上物理的にスケールが困難な状況でした。

また出前館では、昼食・夕食の前にアクセスのピークが発生し、それ以外の時間帯はアクセスが少ない特性があります。従来のオンプレミスの構成ではピーク時に合わせたリソースを常に用意する必要があり、結果としてサーバーコストに無駄が生じていました。

加えて、長年の運用の中で、インフラに関する知識やオペレーションが特定のメンバーに依存する属人化の課題もありました。

これらの課題に対しては、オンプレミスからクラウドに移行して、柔軟なインフラ環境を整えることで解決に向かいました。

～バックエンドの課題～

バックエンドについては、サポートが終了した技術が使われており、セキュリティとメンテナンス面で重大な課題を抱えていました。また、アプリから参照されるAPIサーバーはモノリシックな構造で、店舗や注文、クーポンなど、さまざまな機能ドメインが絡み合い、結合度が非常に高い実装になっていました。

一番の大きな問題は「1つのでっかい共有データベース（以下：DB）が」存在したことです。アーキテクチャの中心に巨大な共有DBが存在したため、拡張性、安定性、データ整合性の観点から深刻な問題を抱えていました。このDBには、800を超えるテーブルが存在し、同じテーブルに対して複数箇所からCRUD操作を行うユースケースが多数存在していました。DBが単一障害点となってしまい、実際にDB起因の障害によってサービス停止まで発展したことが過去に何度もありました。

ここでは、最終的にマイクロサービス化することで責務を切り分け、モノリシックなサーバーと巨大な共有DBを解体する改善が行われました。詳しくは、変革フェーズ2でお話しします。

～Webフロントエンドの課題～

出前館ではアプリとほぼ同等の機能をWebでも提供しています。ここでも保守性、開発効率の面で多くの課題を抱えていました。1つ目はコントローラーの肥大化です。当時、WebはCodeIgniterというフレームワークで開発されていました。このコードベースではコントローラーが非常に肥大化していて、1つのファイルに7,000行ほどのロジックが集約されていました。

また、多くのデッドコードがあり、コードの可読性が低いために仕様を把握するのが非常に難しい状態でした。

アプリにも関連することですが、本来サーバー側で処理されるべきロジックがクライアント側に寄せられていて、システムの責務に混在が生じるという課題もありました。

さらに、既存技術であるPHPに関する知識リソース不足が、開発の停滞や技術のモダン化を非常に難しくしていました。LINEから参画したエンジニアはSPAの開発を経験してきたメンバーが圧倒的に多く、技術のミスマッチも一つの課題でした 。

そこでWebチームでは、Webサーバー全体をフルリプレースする方針で課題解決を試みました。こちらも詳細は変革フェーズ2でお話しします。

～アプリの課題～

アプリ開発に関しては大きく分けて2つの課題がありました。1つ目は、開発体制・プロセスの課題です。アウトソース中心の開発が行われており、社内に技術的な知見がほぼありませんでした。コード管理に関しても以前はzipファイルで納品されたものをコミットするような管理がされており、改修の経緯や仕様を追うことが非常に困難でした。リリースフローなどアプリのビルドはローカルのPCで行われているなど、属人化されていてチームでの開発体制も取りづらい状況でした。

2つ目はコード品質の課題です。Webフロントエンドでお話ししたことに加えて、テストが書かれていなかったため、何が正しいかを仕様レベルからその都度確認する必要がありました。

そこでアプリチームとしては、仕様や技術に関するドキュメントを整備して現状把握を進めつつ、クリアになった箇所からコツコツとリファクタリングやテストコードを追加しました。当時はReact Nativeでアプリが作られていたため「anyを撲滅する委員会」などの委員会を結成し、チームの共通認識を形成しながら改善を行いました。

コツコツと改善を進めてきたフェーズ1

変革フェーズ1のまとめとしては、まずは自分たちの「こうした方がいい」という考えを持ちつつ、現状のサービス、業務、システム全体の理解をするところから始まりました。

そして、属人化したプロセスを改善して仕様設計をコツコツとドキュメント化し、課題を把握して仕様や実装を愚直に整理していきました。フェーズ1は、次の段階で行われるリアーキテクチャをする際の想定外のリスクや仕様を把握するために、とても大事な時間だったと思います。

各コンポーネントでの課題と取り組みについては、詳細を紹介している記事があります。また、アプリチームの体制変化時の取り組みに関しては、LINE Developer Day 2021でお話ししているため、ぜひそちらもご覧ください。

■各コンポーネントの課題
・老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた
・出前館Webリプレイスで直面した技術的課題と解決

■アプリチームの体制変化時の取り組み
出前館アプリ開発における体制変化に伴う取り組み　React Nativeを活用した継続開発のためのルール作成

変革フェーズ2「リアーキテクチャ」

変革については、明確にフェーズを切っていたわけではなく、同時進行で改善が進められていきました。

こちらは2021年ごろのアプリ目線の超概略アーキテクチャです。

アプリから見ると、でっかいAPIサーバーを経由して、でっかいDBに対して情報を取得・書き込みをしていました。これが、変革フェーズ1でもお話ししたモノリシックな構造のAPIサーバとテーブルが800ある共有DBです。加えて、アプリとWebでキャッシュを共有するために、Webサーバー経由で情報を取得することもありました。

本来は、でっかいAPIサーバー上でキャッシュ戦略を考えても良さそうなのですが、当時の組織体制として、サーバー側のアウトソースに頼る開発を行っていました。アプリ・Webの開発に関してもアウトソース主体だったものの、アウトソース先が異なる会社で、よりリソースに柔軟性のあったクライアント側でこのような対応がされている状況でした。あるべき実装というより、要望を最速で達成する実装になっていたわけです。

アプリ目線では、複数サーバーへの通信を管理する必要があるため運用が複雑になります。仕様変更などがある際は、Webサーバーが挟まっていることで、ステークホルダーの整理を含めてコミュニケーションパスに課題がありました。また、でっかいAPIサーバー側にもキャッシュの機構があるAPIがあり、複数箇所で情報がいつ最新のものになるかよくわからない、といった課題もありました。

サービス目線では、インターネットの入り口が複数あることで、一貫したログ分析ができず、セキュリティリスクもありました。でっかいDBに依存していることで、DBが高負荷になるとサービス全体に影響が出ていました。でっかいDBは様々な場所からリードライトされているため、障害発生時の原因を特定するのも大変でした。

これは、現在（未来も含む）の超概略アーキテクチャです。それぞれのクライアントに分散していたビジネスロジックなどはBFFに集約され、アプリとWebの入口もBFFに統一されました。BFFは各マイクロサービスからのオーケストレーション層として機能しており、GraphQLを採用することで、オーバーフェッチやアンダーフェッチが解消され、最適なデータ取得ができるようになりました。

サービス目線でも入り口が一つになったことでログの一元性が保たれて、認証認可に関してもBFFに集約され運用負荷も軽減されました。マイクロサービス化で責務が明確になり、各サービスを柔軟にスケールできるようになりました。

2021年から現在のアーキテクチャに移行するまでには、5年という月日がかかっています。上図で（未来を含む）と書いているのは、現段階で移行が完全に終わっていないからです。

5年の間、サービスとして進化しながら、どうやってアーキテクチャを徐々に変えていったのか。ここからは、それぞれのコンポーネントベースで紹介します。

～Webのリアーキテクチャ～

Webについては、段階的に構成が変わりました。初期はCodeIgniterで開発されていましたが、Next.jsを使ったSPAとなり、最終的にはBFFとWebが切り離され、それぞれ独立したコンポーネントとして稼働しています。

1つずつご紹介します。Next.jsへの移行では、技術としてはPHPからTypeScriptになりました。PHPのサーバーサイドでレンダリングしたHTMLを返す方式から、SPAのアプリケーションになっています。主な目的としては、リプレイスによるメンテナンス性の向上やエンジニアリソースの最適化、アプリと共通の課題だったビジネスロジックのBFF移行です。

100以上の画面をユーザーフローごとに段階的に移行し、ユーザー体験を損なうことを最小限に抑えました。具体的には、商品選択や購入の導線でPHPとNext.jsが混在すると、SPAを何度もロードするなど画面遷移においてユーザー体験を損なう可能性があるため、それらを最小限にするためにユーザーフローごとに切り替えました。ビジネスロジックもBFFに移して、PHPから移行が完了した画面に関しては、アプリからもBFFを呼ぶようにしています。

次の段階では、WebサーバーとBFFサーバーを分割しました。BFFとWebのコードの混在や、それぞれで台数調整などが柔軟にできないこと、デプロイ・ロールバックを同時にしかできなかったプロセス上の問題を解決するためです。

リアーキテクチャを経て、BFFの責務が大きく変わりました。組織にも変化があり、もともとWebチームが保守運用をしていましたが、 現在は新たに生まれたBFFチームが各マイクロサービスとクライアントをつなぐ役目を担っています。出前館のWebのリアーキテクチャの詳細に関しては、ぜひ「出前館Webリプレイスで直面した技術的課題と解決」をご覧ください。

～バックエンドのリアーキテクチャ～

次はバックエンドのリアーキテクチャです。バックエンドでは、モノリシックな構成からマイクロサービスへと移行しています。大きく2段階に分けて、マイクロサービスへと徐々に移行しました。

フェーズ1は「データとロジックのオーナーシップの確立」です。クーポンを例にお話しすると、でっかいDBにある800を超えるテーブルのうち、どのデータをどのサービスが所有するかの整理を行いました。

そして、でっかいAPIサーバーからマイクロサービスとして機能が切り出され、他のドメインからのデータアクセスはマイクロサービスを経由するように切り替えました。それまでJOINなどで取ってこれたデータがAPI経由になるため、他のサービスに関しても修正が多く必要でした。

フェーズ2は「独自DBへの移行」です。でっかいDBからクーポン関連のDBが切り離されました。マイクロサービス内で独自のDBを構築することによって、サービス間の結合を物理的に切ることができます。でっかいDBでは負荷の問題がありましたが、各マイクロサービスで柔軟にスケールをすることで、より最適な構成で運用が可能となりました。

とても簡潔にお話ししましたが、これらの手順を各マイクロサービスごとに時間をかけてロジックとDBを整理し、当初存在したでっかいAPIサーバーとでっかいDBはマイクロサービスに分割され、それぞれの整理された責務の中で改修や新機能の実装が進められています。バックエンドのアーキテクチャ変更に関して、詳細が気になる方は「大規模レガシーシステムのマイクロサービス化における0→1ではない-1→1の新規開発」をご覧ください。

～リアーキテクチャに伴うアプリ開発目線の変化～

最後にアプリ開発目線で、それぞれのリアーキテクチャがどのような影響を与えていたかをお話しします。

こちらは 2020年頃のアーキテクチャです。DBに関しては、基本的にアプリ開発という目線では見えない部分であるため、図からは省略しています。

まず、アプリから呼び出すAPIは全部で約80個も乱立していました。多くのオーバーフェッチやアンダーフェッチが行われており、Webアプリに分散しているビジネスロジックもあり、改修する際のコストが非常に高くなっていました。

次に、Webのリアーキテクチャが進行し、 BFFから一部の情報が取得できるようになりました。アプリは徐々にBFFへ移行していきますが、約80個あるAPIの移行を考えると、気を長く持つ必要があります。そして、その裏ではでっかいAPI サーバーのマイクロサービス化が進んでいます。

マイクロサービスとして切り出されたコンポーネントでは、基本的にBFF内部で後方互換性を担保する設計にしました。BFF側で呼び先を制御することで、クライアント側の改修やリリースを伴わない切り替えを実現できるように心がけました。

しかし、負債を断ち切ることもマイクロサービス化の目的でもあります。一部のマイクロサービス化において、責務の整理やあるべき姿を検討した結果、インターフェースを大きく変更する必要があると判断しました。それらに関しては、V2、V3、V4とバージョニングを行い、順次移行を進めました。

その結果、インターフェースを変えずにBFFの裏側で移行が完了したものがある一方で、互換性を保てないためにバージョニングされたリゾルバも増えていきます。そのため、BFFチームとコミュニケーションを取りながら「移行できているもの」と「できていないもの」を管理するのに苦労しました。

そんな苦労もありつつ、全体のアーキテクチャはとてもシンプルになりました。

また、リアーキテクチャによってステークホルダーが明確になり、コミュニケーションの速度・精度が向上しました。以前に比べて、組織としてはより早いスピード感で新しい価値をデリバリーできるようになったと思います。

徐々に移行し、変化に強いアーキテクチャに進化したフェーズ2

変革フェーズ2のまとめです。まずはプロダクトとしてマイクロサービス化やBFFの導入を進め、より変更に強い構造になったと思います。それぞれの責務が明確になり、それぞれの責務内で改善を高速で行えるようになりました。組織からしても、新機能の影響範囲や改修範囲が明確になり、意思決定と開発速度が向上しました。

リアーキテクチャを経て、継続的な改善が可能なサービスに進化し、変化し続けられる組織的な体質に変わったと思っています。

余談ですが、アプリ単体でもReact NativeからFlutterへフレームワークレベルの大きなリアーキテクチャをしています。こちらもサービス運用をしながら並行開発をして、コードフリーズ期間を1ヶ月も取らずにフレームワークを入れ替えたアプリをリリースしました。最後のReact Nativeのリリースから2週間ほどでFlutterのアプリをリリースしており、大規模に中身が変わっているのに気づいた人は少ないのではないかと思います。詳細については「出前館の大変革：React NativeからFlutterへの大胆な移行戦略」をご覧ください。

ユーザーを裏切らないために、今後も改善を続けていく

最後に、次の10年に向けて出前館が考えていることをお話しします。

まず根幹にあるのは、ミッションとビジョンの実現です。日々ユーザー目線で改善を継続するための基盤が、リアーキテクチャによって整ったと思います。

開発プロセスに関しては、ユーザーへいかに価値を素早く安定して届けられるかが重要です。リアーキテクチャで変化に強い構造にできましたし、今後はその上で「どれだけ小さく早く出せるか」を考えていきたいです。事業の成長を止めずに改善を回し続けられるプロセスを維持することも大切だと思っています。

ドキュメントと経緯を残し続けることも忘れてはいけません。フェーズ1でもお話しましたが、 20年続いたアウトソース中心のサービス開発を引き継いだ時、一番効いた負債は「なぜこうなっているのかわからない」という状態でした。未来のチームのためにも、未来の自分のためにも、仕様だけではなく、意思決定の経緯も含めて残すことを意識しています。これは組織としての透明性や見通しの良さという観点でも大事なことだと思います。

そして、ドキュメントを書くだけで終わらせず、定期的にドキュメントを見直し、ドキュメントを保守する必要もあります。ドキュメントさえあれば優秀なAIが情報を整理してくれるため、まずはドキュメントを書く習慣というのを大切にしています。

質の高いコードと技術負債との付き合い方について、ビジネスをやっている以上、意図して残す負債は必ずあるでしょう。その際「どこにどんな負債を置いているか」をわかる状態にしておくことが大事だと思います。

皆さんのプロダクトにも、日々のタスクの優先順位に負けた塩漬けのToDoというのがあると思います。残してしまった負債はどこかで解消する必要があるため、出前館では、継続的にそれらを改善するためのチームの仕組み作りを進めています。

最後に、ここまでやってきたリアーキテクチャも、次の10年のスタンスも「25年支えてくれているユーザーを裏切らない」という、一言につきます。そのために、アーキテクチャも組織も、今後改善する余地がある限りは、継続して改善していきたいと思っています。

本日ご紹介したリンクをまとめたNotebookLMも用意しておりますので、気になることがあればそちらで質問していただければと思います。

ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。