25年の歴史が生んだレガシーの再定義

本日は「25年耕した大地と向き合う：Oisixが描く、豊かな収穫のための次世代基盤」と題して、長い歴史の中でのシステムの進化についてお話ししたいと思います。

まず、サービスについて簡単にご紹介させてください。皆さんは「献立が思いつかない」「買い物に行く時間がない」「ご飯を作る時間がない」と思ったことはありませんか？　私たちは、そういった思いを抱える方向けに、食品の定期宅配ECサービス「Oisix」を提供しております。Oisixは2025年に25周年を迎えました。

サービスとしては特徴が2つあります。1つ目は「安心・安全・おいしさへのこだわり」です。毎週木曜日に商品ラインナップを入れ替え、こだわりの旬の食材はもちろん、時短が叶うオリジナルのミールキットを扱っています。2つ目は便利さです。モバイルアプリやブラウザからアクセス可能で、いつでもどこでも買い物ができるようにしています。

単なるECサイトではなく、支払い管理や発送管理、データ分析基盤、カスタマーサポートなど、多岐にわたるドメインで様々な機能やサービスを提供しております。

その中で、本日は上図で緑に色付けしている、お客様がお買い物をしている時に直接触るサービス部分について触れていきます。25年という長い歴史の中で生まれたレガシーに対して、私たちがどのように対応したのか、その成果と学びをお話しします。

本題に入る前に自己紹介をさせてください。私は2025年3月にオイシックス・ラ・大地株式会社に入社し、Oisixブランドのプラットフォームエンジニアとして活動しています。その前はフランスで約10年、金融業界のスタートアップでエンジニアとして活動していました。趣味はクライミングで、毎週末カラフルな壁を登っています。クライミングは「失敗して学ぶ」ということを大切にしているスポーツで、一度で登りきれる課題はほとんどありません。何回も落ちて、何が悪かったのかを考え、改善していくうちにゴールまでたどり着くことができます。このような考え方は、レガシーに向き合う時にも、同じように必要になってくるのではないかと思います。

皆さんの中には、レガシーと聞くと「古い」「メンテナンスしづらい」「もう触りたくない」といった悪いイメージを持つ方もいらっしゃるのではないでしょうか。もちろん、世の中には本当に悪いレガシーも存在するかもしれません。私の過去の経験として、同僚から「ここレガシーだからゼロから作らなきゃ」と聞いた時に「え、ちょっと待って。これ私が作ったやつじゃん」と思ったことは何度もありますし、自分が作ったものが否定されて悔しさを覚えました。

しかし、その中で気づきがありました。活動を続けている中でレガシーと呼ばれるようになったものというのは、そこまで生きてきた、もしくは成長した証だと言えるのではないでしょうか。そこから私が導き出したレガシーの定義は「レガシーとは遺産であり、プロダクトであり、愛である」です。

なお「入社してまだ1年も経っていないのに、もうレガシーのこと話すの？」と思う方もいらっしゃるかもしれませんが、決して悪い意味ではなく、過去を見てそこから学ぼうという気持ちで、本日ここに立っています。

シンプルな構成で20年の事業成長を支えた第一世代

それでは本題に入ります。ここからは、Oisixがこれまで歩んだ道のりを、第1世代（Oisixの最初の姿）、第2世代（移行で得た成功と失敗と学び）、第3世代（次世代基盤）の3つに分けてお話しします。

皆さんは2000年代を覚えていますか？　Oisixが誕生した2000年といえば、私は中学生で携帯電話を初めて持った頃でした。

当時のOisixのUIはこのような感じだったようです。Internet Explorerで表示されていて、時代を感じますね。

アーキテクチャはこのような形で、全てがオンプレミスで、静的ファイル、JSP、Javaに分かれていました。JSPとはHTMLの中でコードが書けるファイルのようなもので、Javaのコードを実行できるファイルです。お客様のリクエストがCDNとロードバランサーを通じ、30台あるサーバーの1つに振り分けられます。そこからNGINXでリバースプロキシなどを設定し、画像や動画はファイルシステムから取得。HTMLなどを取得しに行く場合はJettyサーバー上のJSPで作って返すようになっていました。そして、その裏に1つだけデータベース（以下、DB）が存在していました。

第1世代の良かったところは、アーキテクチャを大きく変えずに20年の開発と事業の成長を支えてきたという点です。また、アプリケーションとコンテンツが分離しており、毎週変わるコンテンツの差し替えが容易にできて便利でした。このようなシンプルな構成で、かつCI/CDが存在していなかった時期でもデプロイができていたのもすごいと思います。

しかし、時間が経つにつれて問題点も現れてきました。

1つ目は「コンテキストロス」が増えること。25年も経つとメンバーの転職・退職があり、記憶が薄れていきます。2つ目は「オンプレミスによる運用の難しさ」で、3つ目は「設計による結合度の問題」です。4つ目は「アンチパターン」が広がってくるというものでした。

これらの問題解決を目指し、移行がスタートしました。

「守り」の方針で、成功も失敗も経験した第2世代

第2世代がスタートしたのは2017年です。ここでは第1世代の全ての問題を一気に解こうとしていました。

コンテキストロスに対しては、移行する時にコードを読んで理解して情報を整理しました。運用が難しいという点については、バッチを分離したり、DBを守るためにキャッシュを入れたり、オンプレミスからクラウドへ移行するアプローチを取りました。

結合度の問題については、フロントエンドとDBを切り離しました。それまでステートフルになっていたため、ステートレスAPIを作成することも決めました。アンチパターンについては、コンテキストロスと同じく、移行をする際にコード自体を整理し直しました。

当時の移行の方針は「守り」です。どういうことかというと、人気が高くユーザーに影響がある部分ではなく、エラーが出ても影響がでないところから移行をするというものでした。ここでの目標は、新システムを導入しながら運用の経験を積み、新世代を育てた上で、他の領域にも段々と広げていくことです。

そういったアプローチと方針により、アーキテクチャは上図のように変わりました。Azureのクラウド上でKubernetesを使い、その中にAPIを作っていました。イメージとしては、コアECというAPIを作り、そのAPIがDBに接続する。これは、JSPからDBに直接アクセスするのではなく、APIを叩いてアクセスさせることが目的でした。それにより、Redisのキャッシュを入れてDBの負担も抑えられました。同時にバッチ処理もちゃんと分離しました。

第2世代の結果として主な成功だと言えるものの1つは、毎週木曜日の商品入れ替えの重要なバッチです。定期受注作成のバッチと呼ばれているバッチが走っており、そのバッチが2時間45分以上かかると売り場がオープンできず、お客様に影響を及ぼしてしまいます。定期受注作成のバッチにかかる時間を半分に短縮できたのはいいことでした。

新機能が生まれたのも成功だと言えると思います。第1世代ではなかった商品のレビュー機能が、ようやくOisixに追加されました。また、DBへの負担をキャッシュでカバーできるようになりました。

成功の影で直面した3つの誤算

とはいえ、2024年に第3世代が始まった理由は、第2世代の課題が残っていたからです。なぜ課題が残っていたのか、その理由を3つ紹介します。

理由その1は「同時に導入する技術が多すぎて開発が複雑になったのではないか」です。言語はJavaからKotlin、インフラはオンプレミスからAzure、フレームワークは何もなかったところからSpringを使うなど、たくさんのものを同時に更新しました。そのため学習コストがかかった上に、プロジェクト自体が長引きました。また、刷新を担当したチーム以外の開発者は新しい基盤で開発するのが難しくなりました。

理由その2は「移行済・未移行の機能が混在し新機能開発コストが増えた」です。移行されていない部分があると、その機能の改善・追加時に、移行を含めた予算を立てる必要があります。その結果、社内では「新基盤は時間がかかるな」というマイナスのイメージがついてしまいました。

理由その3は理由その3は「人間も水も抵抗の少ない方へ流れる」という点です。
当時は、第2世代の新基盤ではなく、第1世代の基盤上で開発が進められていました。移行と並行して新機能開発も進めていましたが、移行の進捗が追いつかず、完了時期も見通せない状態でした。
その結果、開発者はより扱いやすく慣れている旧プラットフォームを選択し続ける傾向がありました。

ここから分かったのは、新プラットフォームを使うという意思をチーム全体で明確に共有しなければ、自然と旧環境に流れてしまうということです。

コロナ禍をきっかけにクラウドへ移行

第3世代に入る前に、成功例としてクラウド移行についてお話しします。私たちは、第2世代の途中で一旦ストップし、クラウドに移行しました。それはなぜかというと、優先したいものがあったからです。

もちろん、売上貢献インパクトの優先度を上げたいという気持ちもありましたが、2020年にはより重要な問題がありました。囲碁で例えると「大場より急場」。具体的には、重大リスクにつながる箇所から優先度を取るべきというお話です。

ちなみに、2020年の問題というのは、コロナ禍による影響です。当時は外食が制限され、Oisixのユーザーが増加した時期でした。それと同時に、オンプレミスで管理していたDBに障害が発生しており、第1世代の問題でもあった「オンプレミスによる運用の難しさ」に対応する必要がありました。そこで、オンプレミスからクラウドに移行することにしました。

～Before～

～After～

移行後は、オンプレミスを廃止して完全にAWS上で稼働する構成となっています。ポイントは、アプリケーション自体をクラウドネイティブ化したわけではなく、既存サーバーの構成を維持したままインスタンスを作成して移行したことです。

一方で、インフラについては変更した部分もあります。DBはオンプレミスの自社管理から、RDSの運用に切り替え、APIゲートウェイやロードバランサーなど、AWSのマネージドサービスを活用して移行を進めました。

そして、AWS移行の結果としてコストが増加したものの、生産性や可用性、採用力が向上しました。ちなみに、インスタンスの整理やDB構成の最適化に取り組んだことで、コスト増加の問題はかなり改善されてきています。

「攻め」の方針でビジネス価値最大化を目指す第3世代

私たちの未来でもある第3世代についてもお話しします。第3世代は、クラウド移行後に残っていた第2世代の問題を解決するためにスタートしたプロジェクトです。

第3世代でのアプローチとして、以前はバックエンドだけだったところを、フロントエンドも含めて同時に開発することにしました。また、当たり前かもしれませんが、できるだけ「小さく早く」リリースすることを目標にしました。

一番大切なのは、第3世代のシステムが独立して動くようにすることです。以前までは第1世代を経由する構成でしたが、第3世代が直接クライアントのリクエストに答えられるようにしたいと考えています。

加えて、第2世代で新しい技術を取り入れて学習コストがかかってしまった失敗を繰り返さないように、チームがすでに知っている技術を活用することにしました。

方針も180度転換しました。第2世代では「守り」でしたが、第3世代は「攻め」です。具体的には、多くのお客様が利用し、更新頻度が多い箇所から移行することに決めました。加えて、移行をする際はページ全体を新しい仕組みに置き換える方針を採用。売上貢献ドメインを移行し、新基盤上で新機能開発を進められる状態を実現することが目標です。

今回のアプローチと方針に基づき、上図のようなアーキテクチャを目指しています。

技術面は大きく変更せず、バックエンドはKubernetes上でAPIを構成するシンプルな設計です。唯一の変更点はフロントエンドで、これまでのJSPからNext.jsへのリプレイスを進めています。移行期間中はCDNでルーティングを行い、移行していないものは前世代のシステムで処理し、移行後のページは、Next.js側でSSRを使ってAPIでデータを取得するという流れです。

過去から学び、失敗を恐れずトライし続ける

各世代での学びについてまとめます。第1世代の学びは「シンプルさの価値」です。複雑なものを作るのではなく「シンプルでいいのではないか」という気持ちを持つことが大事であると学びました。また、アプリとコンテンツを分離することで毎週の更新が非常に楽になったというのも、大きなポイントでした。

第2世代でわかったのは「理想と現実のギャップ」です。全てを同時に解決しようとすると、混乱して失敗する可能性が高い。同時に導入する際は技術の数にも気をつけるべきだと学びました。あとはビジネスへの影響が高いところを優先するというのも重要です。影響度が低いところから移行しても、上手くいかない可能性があるとわかりました。

学んだことについて、もう一度お話しします。まず「レガシーは悪いものではなく、向き合って学ぶもの」だということ。新基盤の開発は簡単ではありませんし、旧基盤での開発を継続するのも向き合い方の1つです。

次は「事情に合わせて計画を変えること」。やりたいことよりも、やらなければならないことを考え、実行していくことが重要だと考えています。

「失敗を恐れずトライし続けること」も大切です。クライミングの日本代表選手が「クライミングで大事なのは、落ちるのを恐れない心です」と話していました。メンタルにつながる話ですが、トライをやめてしまうと成功は得られません。

また、今回の発表のように「過去から学んで未来に活かす」ことも大切にしていきたいと考えています。

以上で、私の発表を終わります。ご清聴ありがとうございました。

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

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

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

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