NO.01　エムアンドシーシステム

※（株）エムアンドシーシステムは、丸井グループの情報システム会社です。
　丸井グループの情報システムは、すべて同社が構築・管理しています。

話を簡単にするため、箇条書きで説明してみます。我々が販売している流行のファッション衣料（ヤング世代を対象とした、デザイン性の高い衣料）においては、以下のような困難があります。

1. 作りきりで補充はきかない。

　　ハイファッション衣料というのは、人気商品はすぐに売れてなくなり、不振商品は大量に売れ残ると
　　いった当たりはずれの差が大きな分野です。通常の商品販売では、売り切れた商品は、すぐに補充
　　してさらに売れば 良いのですが、ハイファッション衣料の場合、シーズン前に手当した一定量しか生産
　　しない（できない）ので、 同一商品の補充が利かない場合が少なく有りません。 つまり、「売れたら売り
　　切れておしまい（それ以上の利益は上がらない）。売れなかったら在庫として 残る（それが利益を圧迫
　　する）」という、両面の難しさが有ります。

2. 前年と同じものは売らない。

　　ファッション衣料は、流行を追うべき商品なので、基本的には前年と同じものは売りません。定番性が
　　低いとも言い換えられます。

3. 130万単品を総入れ替え。

　　上記1、2の結果として、「カラーサイズを含めた商品の種類が非常に多く」、「それが毎年大半入れ
　　替わる」ことになります。情報システム流に言えば、「商品マスターの件数が膨大で、しかも毎年、
　　大半をアップデートしなければならない」ということです。

これは、確かに、困難ですね。

この業態特有の課題は、別の小売形態であるスーパーやコンビニと比べると分かりやすいと思います。これらの業態の場合、売り切れた商品は補充が可能ですし、コーラやビール等の定番商品は、前年と同じものを売ることも可能、さらに販売アイテム数もコンビニでは3,000～10,000点程度と聞きました。もちろん、コンビニやスーパーの場合、生鮮食品は腐ってダメになることがあるなど、それならではの商品管理の難しさがあるわけですが、しかし、少なくとも「商品の点数の多さ、入れ替わりの激しさ」という点では、マルイは、比較的、苦労の多い小売業だと思います。ちなみに、ハイファッション販売にはもう一つ厄介な点があります。それは「売れるのはいいが、売れすぎも要注意」ということです。

売れすぎるといけない…なぜでしょうか。

弊社の場合、先にも述べたとおり、商品が売りきれた時に、補充が利きません。ですから、商品の出足があまりにも好調ですと、「二週間後には、好調商品が底をつき、売り場が販売力を維持出来なくなる」という恐れがでてきます。衣料販売の場合、魅力の有る商品で売場のフェイスを構成できなければ見かけ上も営業成績的にも、よろしくありません。状況を早期に発見して、追加の生産や納期の早期化、代替の商品の手配などの対策を行う必要が有ります。

うーん、聞けば聞くほど、難しいですね。

「対応すべき課題の発見」という部分では、情報システムはどのように活用されるのでしょうか。

仮にある商品Aを新たに1000点商品手当てし売場に投入し、現在までに500点売れたとします。前年同シーズンの類似商品の売れ行きパターンのデータを採取して、「もし、この商品Aが、前年の類似商品の平均値と同じようなペースで売れていった場合、在庫が潤沢にあれば最終的に1500点販売できそうですが現在の在庫量は2週間後になくなる予定です。もし追加の手当が可能なら補充に必要な納期が3週間後なので不足する500点を追加するのではなく、1週間の販売機会損失を考慮して300点が推奨です」というように、「事実データ」を冷静に現場に提示します。仕入の現場では「当たった」商品についてはどうしても在庫を増やして売上を確保しようとする傾向になりますが、それを脱して我に返るには、「事実」としてのデータに基づいて適切なタイミングで情報提供することが重要です。

情報システムの主な貢献は、コスト削減、課題の発見の2点とのことですが、「売上げを上げる」という意味での貢献は難しいのでしょうか。

ヒット商品を作る（見つける）という点では、コンピュータよりも人間のカンの方が優秀です。しかし、売れ残りを防ぐ、値下げせずに普通の値段で売り切るという局面でなら、情報システムも多少は貢献できるかもしれません。

具体的にはどのような貢献でしょうか。

例えば、以下のようなケースがありうるでしょう。

1. ある商品が大ヒットしたとする。その商品は、A店、B店、C店に、S、M、Lの各サイズがそれぞれ10着
　 ずつあったとします。

2. ハイファッションの場合、いくら大ヒットしても、S、M、Lが全部売り切れることはまずありえません。Mが
　 10着全て売れたとしても、S、Lが2～3着残ったりする。このように色やサイズが歯抜けになったら、それ
　 以上はなかなか売れません。

3. このまま何の手も打たないと、残ったSサイズ、Lサイズは、期末まで残って値下げ処分の対象となり
　 利益が下がります。

4. こういう場合は、B店、C店の残品を、A店に集約して、A店においてS、M、Lをフルセットで揃えられるよう
　 にする。

5. そうすると、集約したA店では品揃えが整って、通常価格で売れ続けることになります。早期に集約を
　 かけることで、放置した場合よりも、期末処分の対象件数を減らすことができるのです。

こういう施策を実行するには、「商品仕入れを各店に任せるのではなく、中央で一括管理すること」、そして「各店の在庫状況がサイズ別に単品管理できていること。各店の在庫がリアルタイムで把握できること」が必須ですが、後者については、情報システムがいくばくかの貢献を果たせていると思います。

今までお話しいただいた「マルイにおける情報システム部門の役割」を、一言で述べると、何になるでしょうか。

コスト削減や、売れ行きコントロールを支援していることを考えると、「全体の最適化」が役割であると言えるかもしれません。「全体の最適化」というと、難しい言い方になりますが、これを平たく言えば、「商品の投入や移動をタイミング良く行って、いかに無駄なく販売するか」ということになるでしょう。もっと具体的に言うと、「売場の品揃えを維持しながら、いかに普通の値段で売り切っていくか」ということをテーマにしていると言ってもいいかもしれません。

例えば何か新規の分析帳票が必要になった時、汎用機ですと、まず目的帳票の為にデータベース（DB）を構築することから始めなければならない。データの使用目的や集める内容を定義して、それに沿ってデータを集めるわけです。ところがこの方式ですと、データが集まるまでに時間がかかるし、集まったときには古くなっていたり、あるいは売り場の方針が変わって、せっかく構築したDBが使わずじまいになってしまったり、なかなかムダが大きいわけです。

苦労してDB構築しても使われないのでは、悲しいですね。

そこで、汎用機からオープン・システムに切り替え、まずはデータ・ウエアハウスを構築しました。そうして大量のデータを、あるがままの形で保存しておいて、「こういう切り口が必要だ」というニーズが生じたら、それに呼応してレポートを提示するというスタイルのシステムを目指しました。

今回のシステム移行において、アシストはどういう役割を果たしたのでしょうか。

アシストさんの得意技であるオラクルDB 構築の設計や実装をお願いしました。単なる設計だけに留まらず、「全体を貫く標準、基準の策定」でも活躍していただきました。

「全体を貫く標準、基準の策定」といいますと。

システム構築においては、さまざまな開発会社が、入れ替わり立ち替わり関わります。ということは「迷った時に基準とする、標準の決まりごと」がないと、開発がバラバラになってしまい、収拾がつかなくなります。そういう意味では今回キーになった会社が二つあって、一つはJAVA開発におけるウルシステムズ株式会社、もう一つがデータモデリング におけるアシストだったわけです。

なるほど。

我々としてはマルイの業務ロジックは熟知しているつもりですが、いかんせん、これまで約30年、汎用機でシステムを組んできたので、この業務ロジックをオラクルDBに落とし込むということになると、やはりデータの正規化一つとっても勝手が全然違います。アシストは、データモデリングから実装までのDB構築で、多くの実績と経験を積んだスタッフがおり、大いに支援していただきました。

アシストの仕事振りへの評価はいかがでしょうか。最初の期待に比べて、期待通りだったか、期待以上だったか、それとも期待を下回ったのか。

そう聞かれると答えるのが難しいですが、例えば、データモデリングですと、一人、期待以上の「当たりのSE（Mさん）」がいましたね。

どのように「当たり」だったのでしょうか。

SEの中には、自分の守備範囲を狭く狭くする人、私に答えられるのはこれだけですという風に小さく切り分けてしまう人が多くいます。これは困ります。ですがMさんの場合は、「ここはこうすると上手く行くんじゃないでしょうか」、「ここでそういうことをすると、こういう障害が予測されるので、それを避けるためにもこんな風に作ってみました」という具合に、大変積極的でした。知識が豊富であることもさりながら、姿勢が熱かった。システム開発においては、気構え、精神論は非常に重要です。熱いSE、Mさんは、当初は商品RDBだけの参加の予定でしたが、それではもったいないので、顧客RDBプロジェクトにも参加していただきました。

しかし、熱血漢の人の場合、時として、熱くなりすぎて暴走したり、議論を紛糾させたりすることもありうる気がするのですが…。

Mさんの場合は、その辺の、逆らい方の技術、異議申し立ての技術も高かったんですね。相手の言うことを全面否定せず、言うべきは言い、通すべきは通し、しかし折れて良いところは、ちょうどよく折れるという具合でした。

アシストは、現在オラクルDB構築の他に、運用管理やセキュリティ等でもお手伝いさせていただいているようですが、アシストの印象はいかがでしょうか。

RDBや運用管理などのミドルウェアに特化し、複数の製品を扱い、各製品についてよく勉強しているという印象です。この業態は、良いですね。そういう会社は、我々ユーザ側にとっても相談しやすい。助かります。

どのような点で相談しやすいのでしょうか。

例えば、アシストから何かの提案があったとして、それが弊社の現況には少々そぐわないものであった場合、簡単に断れます。断っても、すぐに二の矢、三の矢を出してくるし、今回ダメでも他のソフトが必要になったときに、また声をかけられる。こういう会社は付き合いやすいし、気楽に相談ができます。

逆に、どんな会社だと相談しにくいのでしょうか。

一種類の製品しか扱っていない会社は相談しにくいですね。そういう会社の場合、その製品が断られたら後がないから、営業マンとしても必死になってきます。相手の方にも気の毒ですし、「いくらなら採用してくれますか？」的な商談は実りが少ないと思います。

「マルイにとっての情報活用」というと、どのようなものになるでしょうか。

なかなか答えにくい質問ですが、ハッキリしているのは、マルイにおいて、情報システムが大手柄を立てることはまずないということです。

と言いますと。

野球にたとえて言えば、情報システムが、逆転満塁ホームランを打ったり、魔球を投げたりはしないわけです。そうではなく、売り場の一人一人のプレイヤーの打率を、2割8分から、2割8分5厘に上げる手伝いをするとか、スランプに陥ったときでもできるだけ短期間で脱出できるような環境作りをするとか、その辺が役割ですね。

つまり、勝つための攻めというよりは、負けないための守り、補強、後方支援を担当しているイメージでしょうか。

そういうことですね。ちなみに、打率2割8分を2割8分5厘に上げるといった言い方をすると、あまり華々しくありませんが、実は、百貨店業界においては、このような微差の改善が非常に重要なのです。

今後もコツコツと改善を重ねていくべく、色々な面で、何かと相談すると思いますし、また無茶を言うこともあるかもしれませんが、何卒、ご対応をお願いできれば幸いです。今の相談のしやすさは、今後もキープしていただきたいと思います。また先回りした提案なども歓迎ですね。はずれの提案はどんどん却下しますが、めげずに二の矢、三の矢を出してくる、そういう勢いでお願いいたします。

※現在、ご利用いただいている製品、サービス
　　・データモデリング （論理・物理設計）
　　・リレーショナルDB（実装支援含む）：オラクルDB（Oracle）
　　・統合運用管理ツール（設計～実装支援）：JP1
　　・セキュリティツール（設計～実装支援）
　　・BIツール
　　・各種保守サポート

※(株)エムアンドシーシステムのWebサイト
※(株)丸井のWebサイト
※取材日時：2005年8月 【取材協力：（株）カスタマワイズ】