企業が情報システムを活用する際、開発ベンダーとどうかかわっていくかは大きな課題だ。100円ショップ最大手のダイソーは、5,300店舗、7万アイテムもの商品点数があり、巨大なデータ量を取り扱う小売業だが、それまで外部ベンダーに外注していた社内システム構築を、2014年頃から内製に切り替えることに成功した。現在はAWSを活用し、商品管理システムをはじめとする情報システムの自社開発を行っている。同社情報システム部課長の丸本健二郎氏に、内製に至る経緯と同社が目指す次の一手を聞いた。（取材：MD NEXT編集長／鹿野恵子）
157億件のデータをどう処理するか
ダイソーは、売上高4,548億円、店舗数5,270店、7万アイテムの商品を取り扱い、26カ国の国と地域に展開する国内最大手の100円ショップだ（2018年3月末）。同社が内製＆AWS活用に舵を切ったきっかけは、2014年に開始した自動発注システムの開発にあった。
売れ筋商品の適切な発注と在庫の維持は店舗の最重要業務の一つだが、様々な影響を加味して高度な判断の上に行う必要がある。人材不足の昨今、店舗業務の負担を軽減するために、ダイソーでは自動発注システムの導入を検討することになった。
そこで、50店舗ほどでAIを活用した自動発注システムの実験を行ったところ、欠品率の減少と反比例して、売上が上がる効果を実証することができた。しかし、いざ全店導入のために試算したところ、現状のシステム構成では全体の1割にも満たない200店舗分の処理で限界がくることが分かったのだ。自動発注システムが取り扱うデータ量は、157億件（店舗数5,000店×商品数7万点×30日間分の需要予測×150%の拡張余地 ※開発当時）にものぼる。
もともと大手外資データベース企業にいた丸本さんは、それまでも相当なデータ量を扱うシステムに携わっているという自負があったが、既存のデータベースでは全く歯が立たないデータ量だったという。さらに、ダイソーの店舗は全世界に展開されているため、日本の夜間にあたる時間帯にデータ処理をまとめて行うこともできない。
そこで丸本さんたちは採用技術から変更を検討することにした。おりしもAWSが提供するデータウェアハウス「Amazon Redshift」がアメリカで発表されたばかりの時期だったため、このサービスの検証を実施。想定以上のハイパフォーマンスな処理を実現することができたため、Redshiftの採用を決断した。
ダイソー 情報システム部 システム開発1課 課長 丸本健二郎さん 今後も同社は店舗数を拡大する見込みで、当然取り扱うデータ量も増加することが予測される。拡張性が重視される状況のなか、サーバのCPUやメモリなどハードウェアを高性能にして処理性能を上げる「スケールアップ型」ではなく、サーバの数を増やして性能を上げる「スケールアウト型」のサービスとしてもAWSは最適だった。
自動発注システム開発の反省がきっかけで内製化目指す
ただ、この自動発注システム開発には大きな反省もあった。開発の当初は変化に強いシステムを志向し「マイクロサービス（※１）」を目指していたのだが、外部のベンダーに依頼して開発し、出来上がったものがいわゆる「大きなシステム」で、当初のコンセプトとは違った完成型になってしまったのだ。
（※１：マイクロサービス…従来のシステムがある目的に対して「大きな一つのシステム」で設計されているのに対し、たくさんの小さなシステムを連携させて一つの目的を実現するというもの。従来型のシステム設計は、開発の規模が大きくなりがちで、さらに1か所を修正すると全体を修正しなければならなくなる。一方、このマイクロサービス型の設計であれば開発も変更も、比較的容易になる）
「そこで反省して、外注するより自分たちで作ろうと方針を転換しました」（丸本さん）同社は、変化に強いシステムを構築するために、内製に挑戦することにした。
真っ先に着手した「社内システムの棚卸」
丸本さんはもともと外資系のデータベース企業の出身だ。内製化に向けて動くことができたのは、彼の技術者という出自も関係している。さらに外部の開発ベンダーからユーザー企業側に転職したことで、いくつもの課題に気が付いたという。
ダイソーの店頭では膨大な商品が取り扱われている（写真はイメージです） 「ユーザーの側に立ってみて、はじめてベンダーの力の強さに気が付きました。ユーザー側の企業の情報システム担当も、技術のことや業務ロジックのことがよくわからないまま発注をしていることが少なくありません。ベンダー側も利益を取りに来ているので、ユーザー企業側が裏の構造まで理解していないと、いいように作られてしまうこともあります。このままでは将来的に行き詰ると感じていました」
転職した際、そんな風に感じた丸本さんが2012年にダイソーで真っ先に着手したのが、会社のシステムの棚卸だった。それまでは社内にシステム一覧も存在せず、誰に何を聞いたらよいのかわからない状態。システム社内一覧を作成して、システムの棚卸を行うとともに、関係性を見えるようにするため全体構成図を作成。全システムをレビューした。
このような作業を行うことで、それまでベンダーに丸投げしていた情報システムのなかで雑に作られている部分や、似通った機能が重複して作られている部分も見えてきたという。サーバーが壊れたときのデータ担保の仕組みができていないようなシステムも発見した。情報システム部の担当者は納品されたものをチェックしたつもりになっていたものの、トラブル時の対応の評価まではできていなかったのだ。これはシステム品質の定義が十分になされていないことが原因であると判断し、ダイソーのシステム品質の定義を再構築した。
「kintone」で商品管理システムを開発。統制が効く運用へ
次に着手したのが商品管理システムの開発である。繰り返しになるが、同社の取扱商品は約7万アイテム。新商品は毎月約800アイテムにのぼる。同社はその大量のアイテムや商談の仕組みをエクセルで管理、運用していたのだが、単一エクセルでは集計ができず、誰がどの商談をしているのか把握できなかったため、商品計画が煩雑な状態だった。
そこで同社は、商品管理システムをサイボウズが提供するデータベース型ビジネスアプリ作成ツール「kintone」を使って新規構築することにした。商品の状況や、作業の優先順位などが一目瞭然になり、承認フローなども構築。業務の見える化が進み、膨大なアイテム数を取り扱いつつも、統制が取れるようになったという。しかし、商品管理システムの構築後には開発前から想定していた課題が表面化した。
「狙ったことはできるようになったのですが、kintoneというプラットフォームでもともと我々の膨大なデータ量をレスポンスよく捌くのは難しいと考えていました。実際、業務の流れはシステム化できたのですが、レスポンスが悪く、業務メンバーからは不満の声が大きくなってきました。そこで、商品管理の仕組みを運用に載せることに成功したあと、商品計画を含めたトータルシステムの構築に着手することになりました」（丸本さん）。
このことからも学びがあったと丸本さんは言う。
「小売業界は、他業界に比べてまだまだシステム化されていない業務が多く、ゼロからシステムを作りあげる必要があります。ただ、はじめからフルスクラッチ（※２）で内製をしてしまうと、コストも手間も想像以上にかかるものです。プロトタイプを作り、それをたたき台にしてシステムを作れば想定外の工数増加を防ぐことができます
（※2：情報システム開発時に、既存のプログラムを使わず新しく作成することをスクラッチ開発というが、そのなかでも既存のものをまったく使っていないことを強調するときはフルスクラッチ開発という）
次の一手はAI活用による「店内作業の効率化」
今後丸本さんがダイソーで挑戦したいと考えているのはAIの活用だ。
活用分野としては(1)棚卸、(2)店舗従業員の教育・サポート、(3)万引き検知、(4)顧客分析、(5)在庫最適化の5つを検討している。
まず小売業の作業のなかで大きな工数を割かざるを得ない「棚卸」業務の自動化だ。小売業界のなかではRFIDの活用研究も進んでいるが、100円ショップの収益構造ではコストが1枚当たり1円以下にならないと活用は難しい。カメラなどで入力した画像をAIで分析して、棚卸作業の負担を軽減できないかと考えている。
店舗従業員の教育やサポートにもAIの導入を検討している。例えばダイソーでは業務上の不明点に回答するコールセンターを設置しているが、このコールセンター業務をスマートスピーカーのような音声認識AIで代替することはできないかと考えている。顧客分析AIは、既に製品として販売されているものもあるが、顧客の買い回り状況などを分析することで、次の打ち手を戦略的に検討することが可能になるだろう。在庫最適化AIではチャンスロスの発見や過剰在庫の検出・対応、滞留在庫の廃止などを目標とする。
なお、販促や売り方に関わる部分など、100円均一という業態の営業施策に関わる分野へのAI導入はまだ検討していない。まずは店舗作業の効率化などの分野でAIを導入していきたい考えだ。
長期的な視点で全体最適を目指せる情報システム部の役割
丸本さんがダイソーへの転職を決めたのは、地元企業であったこともさることながら、長期的な視点でシステムに関わりたいと考えたのがきっかけだった。前職ではプロジェクトが終われば数カ月程度でお客様との関係も終わってしまう。ユーザー企業に入って、もっと長くシステムに関わり、本質的な部分に踏み込みたいとという思いが芽生えた。
「ユーザー企業の情報システム部は、自社のことをとことん考えて、長期的な視点に立ってシステムをつくるのが役割です。
内製化を目指したことで、同社の情報システム部はその仕事が大きく変わった。それまでは、ベンダーにざっくりと「こんなシステムを作りたい」と伝え、提案に対し見積もりを依頼するのが仕事だった。短期的な視野で、いろいろな開発ベンダーに依頼するので、どうしてもシステムがつぎはぎになってしまう。しかし今は自分たちも業務部門と一緒に要件定義をして、ときにプログラムを書く。常に考えているのは「作ったシステムを業務部門にどれだけ使ってもらうことができるか」。会社の業務の全体を見て、全体最適を目指してシステムをつくる。大きな変化である。
一方、業務部門にシステムについての興味を持ってもらうのはとても難しいことだとも丸本さんは感じている。興味がない人は情報システム部に相談しようともせず「いい感じにしておいて」でコミュニケーションが終わってしまうことも少なくない。
だが、規模が拡大したチェーンストアが、新しいビジネスを展開しようとしたり、生産性向上に取り組もうとするとき、情報システムの支え無しにそれを実現することは不可能だ。イニシアティブをもって事業を展開するためには、業務部門と情報システム部がお互いに理解しあおうとする企業文化の醸成が必須なのかもしれない。
また、内製チームを運営するためには、技術のバックグラウンドを持つ開発者の確保が最大の課題だ。丸本さんは、現在AWSユーザーとして、自社のシステム開発への取り組みをさまざまなセミナーなどで発表している。広島という地方で開発者を集めるのがその目的の一つだ。その活動が功を奏し、同社には開発者が集まりつつあるという。現在は約20名ほどの規模で内製チームを運営している。最先端の開発をしているダイソーという企業が広島にあることをアピールし続け、優秀な人材を獲得していきたいと丸本さんは考えている。
