ダイソーが6年でIT内製化、マイクロサービス化、サーバレスに成功した理由：105億レコードの処理が課題（1/2 ページ）

アイティメディアが開催した「ITmedia DX Summit 2019年秋・ITインフラ編」の特別講演にダイソーの丸本健二郎氏が登壇。内製化によって、データ管理基盤の最適化、高度化を図ったいきさつと結果について講演した。

[廣瀬治郎，＠IT]

大創産業 情報システム部 課長 丸本健二郎氏

　大創産業は1972年、家庭用品を販売する商店として創業された。今やよく知られた『100円SHOPダイソー』を運営する事業者である。ダイソーの展開に着手したのは1987年。2019年には国内3367店舗を数え、海外ではアジア、北米を中心に28の国、地域で2175店舗を構えるほどのグローバル展開を果たしている。

　キッチン用品や文具、衣服やコスメ、食品やガーデン用品など、幅広い商品展開もダイソーの魅力の一つだ。商品数は7万点を超え、売れ筋の電池は1秒間に5本、ネクタイも15秒に1本、“つけまつげ”は1.3秒に1つ売れる勢いとのことだ。

　取り扱う商品が多く、また尋常ではない速度で売れていくことは、それだけデータ管理の難しさが増すということでもある。アイティメディアが2019年9月17日に開催した「ITmedia DX Summit 2019年秋・ITインフラ編」に登壇した大創産業 情報システム部 課長の丸本健二郎氏は、「Amazon Web Services」（AWS）を活用してデータ管理基盤の最適化、高度化を図ったいきさつと結果について講演した。

ベンダー丸投げ状態からの出発

　丸本氏が入社した2013年ごろ、ダイソーのシステムはベンダーに任せっきりの状態であったという。プログラマーやSEなどのエキスパート出身の丸本氏は、ダイソーという著名な企業で全体最適をつかさどるジェネラリストになることを目指してきた。

I型人材からT型人材への転進（丸本氏の講演資料から引用）

　改修コストの見積もりも、SIer出身の丸本氏にとってはあり得ない高額が提示された。丸本氏がベンダーへ教示するシーンも多々あり、何かを頼もうとすれば“契約外”として断られる。RFP（提案依頼書）を準備すれば、営業担当者は数字を上げるために余計な機能を追加しようとする。「こんな中で良いものが創れますか？」と、丸本氏は苛立ったそうだ。

　何とか関係者を通じてシステム一覧を作成してみたが、大型パッケージもマクロも一緒くたになった700システムのリストが提出され、丸本氏は頭を抱えた。ユーザーに多重入力を強いる非効率なインタフェースデザイン、メール配信システムはなぜか4つ、OSやプログラム言語の保守も切れているという状況だった。

内製化を目指して、自ら突破口を開く

　丸本氏が目指したのは、ベンダー依存から脱却し、内製化を進めることだった。同氏は例として、発注業務の社内システムについて取り上げた。

　もともとダイソーの各店舗では、確保している在庫が減少したら担当者が本部へ発注をかける方式を採っていた。商品数や新商品情報、季節の移り変わりや販売促進施策などを鑑みなければならず、難しい業務の一つだった。もし流行の商品を多く仕入れて多く販売したいとしても、対処が遅れがちになってしまう。

（昔）発注業務の課題（丸本氏の講演資料から引用）

　この解決策として有効なのは、「自動発注システム」だ。データを解析して需要を予測し、供給を自動的に調整する仕組みがあれば、担当者の負荷も軽減できる。しかし、世界5000店舗超、7万商品、30日間ぶんの需要予測を行うには、単純計算で105億レコードを管理しなければならない。

　新しいシステムについてベンダーに相談しても、「既存店は難しい」「パッケージなら1億円」「PoC（概念実証）にはデータが足りない」「新店舗でも難しい」と堂々巡りで話にならない。

　「ベンダーは、現在の強みを採用してくれるユーザーを求め、合格点ぴったりのサービスを提供したいのです。しかし私たちは、ビジネスとシステムを全体最適化するにはどうすればよいか、時間経過による変化へどう対処すべきかを考えています。そもそも両者の視点が違うのです。しかし、このままではビジネスが停滞してしまいます。自ら突破口を開く必要がありました」（丸本氏）

RDBMSでは105億レコードは処理し切れない

　丸本氏は、「PoCを実施して試してみることがポイントです」と指摘する。まずオンプレミスで小規模なシステムを構築し、一部の店舗のデータを活用してテストを始めた。しばらく運用してみると、欠品率が減少し、売り上げが上がることがはっきりした。

　「効果は明らかで、さあ全店導入！　というところで課題に直面しました。テストしたのは200店舗、国内のたった7％にすぎません。閉店時間の夜間にデータを処理していたのですが、既存のオンプレミスシステムではこれが限界でした。急激に成長、変化してきた当社のビジネスを支えるには、必要なリソースを必要なときに調達でき、利用した分だけ課金されるクラウドの方が適していました」（丸本氏）

　「ただし、既存技術のままクラウドへリフトしても、意味はない」と丸本氏は判断した。クラウドならではの新しい技術、サービスを活用してこそ、大きな成果を上げられる。その一つとして注目したのがデータベース技術である。

　既存のRDBMSでは数万〜数百万件ほどのデータであれば高い性能を示すが、100億を超えるようなデータだと性能が劣化してしまう。そこで列指向の「Amazon Redshift」をテストすると、1億を超える辺りからRDBMSの速度を超え、ダイソーの持つ105億レコードの処理において、はるかに高い性能を示したという。

パフォーマンス検証（丸本氏の講演資料から引用）

　PoCのときは既存のRDBMSだったため、パフォーマンスが追い付かなかった。しかし、Redshiftであれば全店舗のデータ処理もまかなえる。自動発注システムで十分に処理できることが分かったことは大きな前進だった。

【訂正:2019年11月28日12:15】Amazon Redshiftについての記述で誤りがありましたので表現を見直しました。

理想のマイクロサービス化は組織変革と、CI/CDによる自動化から始まる

　ところが、自動発注システムの内製化に当たり、丸本氏は2つ目の壁に直面した。もともと同氏は、システムはマイクロサービス化すべきだと考えていた。1つのシステムに統合してしまうと、一部の障害が全体に影響してしまうためだ。システムを複数のサブシステムに分離し、それらの疎結合によって全体を構成すれば、障害の影響を最小限にとどめることができる。

　ところが出来上がったのは、マイクロサービスとは程遠い、モノリシックなシステムだった。丸本氏は、この原因を組織的な問題だったと結論付けた。マイクロサービスを目指しながら、開発組織は1つだったのだ。そのため自然とモノリシック構造に近づいてしまった。

なぜこうなったのか（丸本氏の講演資料から引用）

　自動発注システムでの反省を生かし、ダイソーでは、2〜3人のごく小さなチームで、「データの受け取り」「チェック」「保存」「参照（送付側）」「参照（受け取り側）」という5つのマイクロサービスを開発し、「POSデータ保持システム」を構築した。「POSデータ分析システム」「インタフェース統合システム」も同様に、3〜5つのサービスで構成されている。

　「よく、理想のチーム人数を“2枚のピザ”で表現しますが、私はそれでも多いと考えています」（丸本氏）

　こうした開発体制の改革に加えて、ダイソーではCI/CD（継続的インテグレーション／継続的デリバリー）の開発手法も採用している。自動発注システムは店舗運営に関わるため、トラブルの影響は非常に大きい。十分に検証し、リリース手順書にのっとって公開したつもりが、ミスで大惨事を招く寸前までいったこともあったのが、CI/CDの採用理由だ。

　「CDを活用して障害の多くを占める人的ミスをなくせば、トラブルは大幅に軽減できます。また、開発段階で大きな時間を取ってしまうテストも、CIによって自動化すれば大幅な時間短縮と負荷軽減に寄与します」（丸本氏）

　自動発注システムでは、「修正が頻繁なところ」「安定性が求められるところ」「当たり前のように実施すべき王道テスト」「最終結果の突合」といった適材適所でCIを導入し、全てのリリースをCDで自動化した。

CI/CDを入れたところ（丸本氏の講演資料から引用）