創業時はJava 1.3、JDBC、JSPで構築――ECサイト「Oisix」がマイクロサービス化を進めたワケ：特集：マイクロサービス入門（3）（1/2 ページ）

特集「マイクロサービス入門」の第3回目は、マイクロサービス化を実現したECサイト「Oisix」がどのような環境でサービスを提供していて、どういった課題を抱えた中でマイクロサービス化を選択したのか、オイシックス・ラ・大地でシステム本部シニアアーキテクトの小林弘明氏が紹介します。

[小林弘明，オイシックス・ラ・大地]

　Oisixは、毎日の食卓に並ぶ食材を定期的にお届けするサブスクリプションサービスを主力とするECサイトです。学生ベンチャーとして集まったメンバーが2000年に創業し、当時前例がないインターネットで生鮮食品を定期宅配するサービスの提供を始めました。現在は志を同じくする「大地を守る会」「らでぃっしゅぼーや」の2ブランドと合流し、「オイシックス・ラ・大地株式会社」の1ブランドとして活動しています。

　「オイシックス・ラ・大地」は、より多くの方が食生活を楽しめ、おいしい食を作る方が報われる、持続可能なサービスを構築することをミッションとしています。このミッションを達成するため、ECサイトを企画する事業部やデザイナーのチーム、システムを運用するオペレーションのチーム、物流を担う配送センターのチーム、お客さまへの窓口となるサポートセンターのチームなど、さまざまな部署のプロジェクトチームが一丸となって日々活動しています。

　そして私たちシステム本部のエンジニアは、社内のメンバーの活動を支えるため、Webサイトやスマホアプリ、社内業務システム、物流システムなど、多岐にわたる社内システムの開発、保守を行っています。

　創業時の社名は片仮名で“オイシックス”、ショップのブランドとしてはアルファベットで“Oisix”です。ややこしいので本稿ではOisixで統一します（なお、定期宅配サービスの名前は平仮名で「おいしっくすくらぶ」です）。

マイクロサービス導入前夜

ECサイトの状態

　Oisixは創業してから黒字化するまで3年かかり、問い合わせの電話がかかってくると受話器の取り合いがあったそうですが、その後19年間で順調に成長し、現在は20万人以上の会員数を持つECサイトになりました。この成長は、学生ベンチャーだったころからのスピード感、創業者由来の、全社員が問題の本質を徹底的に掘り下げるロジカルさ（Oisixではそのための講座を全社員が受けます）、問題発生時には組織の垣根を超え全社一丸となって対応する文化が支えています。

　ECサイトを成長させる努力は今も続けられています。毎週大量の生鮮食品をサイトで販売しお届けするためのオペレーションが実施される傍ら、お客さま視点でのサービスを構築するためPDCAを回して試行錯誤しています。また、全国の農家さんから生鮮食品を提供していただいているため、台風や大雪のような天災時には物流面でさまざまな問題が発生します。そういった突発的な問題にも対処しています。

　このような活動や会社の成長に伴い、システム本部のエンジニアもこれらの問題に答え、システムの安定性を高めながら、より多くのシステム開発を素早く行えるようになることが求められるようになりました。

ECサイトを支えるシステムの状態

　創業時の痕跡はECサイトのJavaコードにも残されており、「2000年6月1日」の日付が修正コメントとして残されています。現在のGitリポジトリ（以前はバージョン管理にApache Subversionを利用）で確認できる最初の日付が2008年で、それ以前の詳細は追えませんが、2000年6月の会社登記時に使われていたコードベースが、その後現在に至るまでずっと使われてきたことが分かります。

　2000年のJavaはバージョン1.3のはずで、当時最新のトレンド言語でしたが、エコシステムはまだまだ黎明（れいめい）期でした。OisixのECサイトは2000年前後に設計されており、オープンソースソフトウェア（OSS）のORM（Object-Relational Mapping）ライブラリではなくJDBC（Java Database Connectivity）をラップした独自のライブラリを使ってデータベース（DB）につないでいました。また、Apache Mavenのような構成管理ツールがないためApache Antでビルドが行われ、テストツールのJUnitも一般的ではなかったため、テストコードは書かれていませんでした。

　それから年月の経過とともに、コードのブラッシュアップやライブラリのアップデートが何度も行われてきました。現在のコードはGradleで構成管理され、JUnitのテスト結果が自動的にSlackで毎日報告されるようになっています。

　ただ、新たなサービスの開発に重きを置いて拡張してきた結果、システムのアーキテクチャやフレームワークが19年前のまま変更されてきませんでした。つまり、影響範囲が広く深い部分は古いまま残されていたわけです。

　「クラウドネイティブやリアクティブのような考えを取り入れたい」「最新のライブラリを導入したい」「コンテナ化したい」というような最近のニーズに対応するのは困難でフレームワークはテスタビリティーが考慮されていなかったため、JUnitで安定したテストを書くのにも時間がかかり、リファクタリングで古い部分を取り除くことも難しい状態でした。