業務改革を追求したら次世代のECプラットフォームができた―Hamee

「攻めのIT経営銘柄 2016」選定企業のIT戦略<3>

2016年11月8日(火)佃均（ITジャーナリスト）

リスト

攻めのIT経営銘柄2016選定企業26社のうち、Hamee（ハミィ）は"最年少”の1998年設立。だけでなく本社は小田原市と唯一の地方企業だ。スマートフォンのアクセサリーを販売する「小売業」だが、実店舗は１店もない。インターネット時代の申し子のような急成長を支えているのは独自開発のネットショップ一元管理システム「ネクストエンジン」だ。「業務改革を追求した結果です」と取締役プラットフォーム事業部長・鈴木淳也氏は言う。

年を追って純利益率が上昇

代表取締役 CEO/COOの樋口敦士氏

　ネットショップ一元管理システム「ネクストエンジン」を語ることは、Hameeの歴史を語ることになる。というのは、「ITで業務改革を積み重ねてきた、その過程で生まれたのがネクストエンジン」（代表取締役CEO/COO樋口敦士氏）だからだ。

　同社ホームページ（http://hamee.co.jp/）の〈沿革〉によると、同社の原点は1998年5月設立のマクロウィル有限会社にさかのぼる。樋口氏が大学4年生で始めたオーダーメードの天然石アクセサリーの販売会社だ。ハイビスカスをあしらった携帯電話用のストラップがヒットし、翌年8月、自作で通販サイト「携帯アクセ市場」を立ち上げ、ネット通販に集中することになった。

　2000年の1月、楽天市場に出店したのは、ネット通販が一般個人に広まった時期と重なっている。ハイビスカスのストラップがヒットしたのは、消費者の希望やトレンドを的確に把握したからこそだ。個人向けネット通販ならそれができる。

　そこで2001年3月に「携帯アクセ市場」を改造してグローバルECサイト「StrapyaWorld」をスタート、越境ECにも乗り出した。並行して同年12月に株式会社に改組、社名を「ストラップヤ .com」に変更、次いで2006年5月「StrapyaNext」、2013年5月に現社名という変遷をたどっている。Hameeの社名は「happy mobile, easy e-commerce」に由来しているという。

　業績を見ると、2009年度（2010年４月期）に22億5100万円だった売上高が2015年度（2016年4月期）は65億100万円と2.9倍に拡大、毎年2けた成長の快進撃が続いている（図１）。それだけなら、「ヒット商品が続いたのに違いない」という推測もアリなのだが、注目すべきは純利益率だ。

　2009年度の純利益率は1.7％だった。とても二重丸をつけるのは難しかった。しかし2011年度に3％台、2015年度に3.97%とあと一歩で4％台、2016年度は4.5％予想と年を追って増加している。事業規模の拡大と純利益率の増加が同期しているというのは、必ずや秘訣がある。同社にあっては、それが「ネクストエンジン」だったというわけだ。

図1　Hamee 売上高/純利益率の推移
拡大画像表示

　企画・開発を担ってきた鈴木淳也氏の話を聞こう。

ECサイトと小売業の関係

「プロトライピングとアジャイルで作ったシステムが新しいビジネスを生んでいます」と鈴木淳也氏

　「私は2005年入社でして、当社初のシステム担当員として採用されたんですね。当時はガラケーの最盛期で、当社の主力商品はガラケー用のストラップでした」鈴木氏はこう切り出した。

　「業績が急上昇していまして…。今もそうなんですが、当時は手作業が多かったもんですから、そりゃぁもう大変で」。

　え？　ECの会社って、世の中では「ネット系」とか「IT企業」って見られてますよね。

　「注文を受けるところはWebというかECサイトですけれど、内実は小売業そのものでした。注文が入ってくると手書きで伝票を印刷して、オフィスというか倉庫というか、山積みになった在庫の中から商品を探してきて、梱包して。配送伝票を印刷して、それを表に貼って出荷する。そんな作業の毎日でした」。

　鈴木氏もシステム開発に着手する前に、実務を経験している。在庫があればいいが、なければメーカーに発注をかける。商品が入荷したら出荷する。複数の商品が注文されて、１品でも揃わないと出荷できないので、棚に上がったまま忘れられてしまうこともあったという。ピッキングが人の手で、というのは分からないではないが、在庫管理や販売管理も人手だったのか。

　「いや、さすがに人手ということはなくて、私が入社するまで、外部のITベンダーに作ってもらったシステムを運用していたんです。ところが自社サイトだけじゃなく、楽天市場とかYahoo!ショッピング、アマゾンなどに出店していると、ECならではの課題がネックになってきたんです」。

　分かりやすいのはAPI（Application Programing Interface）だ。自社のサイトだけで注文を受けるならシステム上の問題は生じない。しかし商機をより広げるには複数の異なるモールに出店する（商品を載せる）ほうがいい。そのためには、それぞれのサイトのAPIに合わせなければならない。だけでなく、当然ながらフォーマットも異なる。1980年代にコンピュータとデータ通信が結びついたときに発生した、異種プロトコル・異種フォーマットの問題とよく似ている。

　「在庫数をどう表示するかという問題もありました」。

　在庫の実数が100個の時、複数のサイトに「在庫100」と表示すると、最大100×サイト数の在庫になってしまう。といって、これまでの実績をベースに在庫数を振り分けると、「在庫0」のサイトが生まれてしまう。実在庫数を複数のサイトにリアルに連動させたい。

　「そうしないと販売の機会損失が発生し、販売を最大化できません。ところが相手方が受けてくれるのがテキストデータのケースもあればCSVファイルをFTPで置くケース、ログインして書き換える方法もある。これに対応しないと、小売業は注文や取り扱い商品の点数が増えたら人手を増やすしかない」。

この記事の続きをお読みいただくには、
会員登録（無料）が必要です