臼井です。
他の皆がリアルタイムに 10月の re:Invent の報告をしている中、
なんと9月中旬から下旬にかけて行われた Amazon Machine Learning ハッカソン/Meet-up について報告します！
今回はADSJ様(Amazon Data Service Japan)による主催・運営と、
ハンズラボによるデータ提供とサポートによる共催でした。
以下、このハッカソンについてお知らせしていたページを記します。
Amazon Machine Learning ハッカソン/Meetupを開催します｜ニュース｜ハンズラボ株式会社
Amazon Machine Learning ハッカソン with ハンズラボ 2015年9月12日【Amazon ML ハッカソン】
Amazon Machine Learning Meet-up with ハンズラボ 2015年9月29日【Amazon ML Meet-up】

どのようなハッカソンだったか

概要

今回ハッカソンという名称で開催しましたが、1,2日こもってアイデア出しから始めてアプリケーションを作る！
というよく聞く感じのものとは少し違います。
イベントタイトルにもあるように、今年ローンチされた、
Amazon Machine Learning(以下、AWS ML と表記)を使用して、
素材データからお題に対する解を得てスマートアプリケーションを作る、
という、ややデータハッカソン要素のあるものです。
AWS ML については、以下のADSJ様の記事をご覧下さい。
Amazon Web Services ブログ: 【AWS発表】Amazon Machine Learning – Data-Driven Decision at Scale
データハッカソンについては、有名どころで言うと、Kaggleが主催のものが挙げられます。
Competitions | Kaggle
常時、企業や組織の実データに基づく課題を受け付け、
一般のデータサイエンティストらが、それらに対してよりよいモデルを作成しようとし、結果を出そうと常に競っています。
モデルの買取があるし実データいじるのが楽しいしで、皆必死ですｗ
今回のAWS ML ハッカソンは、以下の様な特徴が有ります。

• 必ずAWS ML を使用して、予測モデルの生成に使用するというレギュレーションの存在。
• 参加者はデータサイエンティストだけではなく、アプリケーションエンジニアも想定する。

非データサイエンティストでも、データサイエンスの果実を自ら手を動かして一定の程度得ることが、
手を出しやすい分析サービスの存在により既に容易に可能となっている、ということを、
実データと最新のサービスを用いて実感してもらう、という想いで、
ADSJ様と二人三脚で進めて参りました。
スケジュールは、
2015/09/12 ハッカソン初日開催。
~2015/09/28 ハッカソン初日開催日から引き続きHacking.
参加者の皆様とはSlackでコミュニケーションをとりつつ、ADSJ様と共にサポート。
2015/09/28 Meet-up にて成果発表！
という流れでした。

使用データとテーマ

テーマはずばり、以下です。
2015/09/14(月)~ 2015/09/20(日)の 東急ハンズの店舗毎の売上予測をして下さい！
であれば、上記を行う為に必要なデータは……？
2010年9月から現在(2015/09 上旬)までの、 東急ハンズ全店のPOS取引データ！
ということでした。
今回公開したPOS取引データというのが、多少の加工をしていますが、
テキストファイルにして80GB程度と、たまたまですが絶妙な量で、
みんな大好きMacBook Pro程度のローカルPCのスペックやストレージサイズで、
全体を一度にストレス無くETL(Extract, Transform, Load)をするにはギリギリ、程度のサイズでした。
他細かい実施要項については、スライドを公開してますので、そちらを見て下さい。

Meet-up

9/12 の20名を超えるハッカソン参加者のみなさまのうち、結果を提出して頂いた6組7名様の成果を、
9/29 のMeet-upにて披露して頂きました。
ハンズラボ賞と、オーディエンス賞(ハッカソンに参加してなくてもMeet-upに出席頂いた人の投票)の2つの賞を用意しておりました。
それぞれ、以下の様に評価し、決定しました。

• ハンズラボ賞 : 売上予測が、店舗×日付それぞれについて、売上実績値を真値とした相対誤差20%以内であった割合にて、50点満点の評価。他、ハンズラボメンバーによるプレゼン、アイデアの評価でさらに5,60点程度。
• オーディエンス賞 : 各チームの発表について、会場にいるみなさまに各自5段階評価してもらい、その合計値。ハンズラボ賞とは完全に別個に評価。

売上予測の正解を相対誤差20%以内としたのは、
1桁%ではつらいが50%を超えていると正解とは直観的に言い難い、
誤差20%とかなら、現実の小売を考えて、ぶれたとしても上下のぶれを考えたらそこそこ相殺されて、
会社はすぐには潰れないだろう、程度の後付けの根拠となっていますｗ

売上予測結果

なんと最も正解率が高かった方は、正解率50%をたたき出しました。
参加者の中では、10%正解するのも難しい中、これは驚異的でした。
また、MLのモデル作成は出来たが、締切までに予測実施が間に合わず途中提出の方がいたのですが、
提出分だけの1店舗で見ると7日中6日正解、つまり正解率85.7%の方がいて、ざわざわしましたｗ
ちなみに東急ハンズは、店舗にいる管理や庶務会計系の社員が毎月翌月の売上予算を日別に計算し、本部に提出しているのですが、
今回の売上予測の正解基準である相対誤差20%以内でジャッジにかけると、正解率はなんと8割に迫る勢いで、
現場感覚すげーな、負けてらんないな、と思った次第です。

売上予測の実施手法

では、参加者がどのような手法で上記の予測をしたのか、紹介していきます。

ETL

参加者みなさんそんなに大きな差は無く、

• S3->Redshift->ML
• S3->EMR(Hive)->S3->ML

という感じでした。
MLのデータソースはS3上のCSVかRedShiftであることが必要だったので、
このようなパターンに収束したと思われます。
EMR(Hive)は、S3上のCSVに対してSQL叩けるらしいです。知らなかった。
また、8月のハンズメッセや、12月のクリスマス商戦など、売上が際立っている期間は、
チームによっては異常値として除外している所が多かったです。
異常値として処理せず、時間軸の自明な周期成分を除去することで処理したチームもありました。
フーリエ変換とかラプラス変換とかデジタル信号処理とかいう単語が浮かびますね。

説明変数の決定

お渡ししたデータのカラム数はさほど多くなかったこともあるのと、
Meet-up当日までのやりとりでも変数が多すぎてもつらいという空気が出来ていた認識です。
参加者が使用してプレゼンで紹介していた変数の和集合をとると、以下の様な感じになりました。

• 店舗コード
• 売上
• 過去数日分売上のウィンドウ集計
• 年
• 月
• 日
• 曜日
• 祝祭日か
• 休日かどうか
• ハンズメッセ期間内かどうか
• 天気
• 降水量
• 店舗最寄り駅の乗車人数
• 温度
• 不快指数

思いついたけど使用できなかったと発表があった変数や要素としては、

• 競合他店データ
• 床面積
• 在庫高。震災時の在庫高による売上キャップチェック

というのが出ました。
先の結果と合わせて考えると、
数百以上も説明変数を使用する必要は必ずしもないのではないか？という印象を受けます。
そもそもの原点に立って考えると、東急ハンズの各店舗の売上を予測する、ということなので、

• 総売上はひとりひとりのお客さんが買ってくれた金額の合計である
• その日にお客さんが何人来たか
• 来たお客さんのうち何割くらいが買ってくれたか。入店カウントは結構しているので、来店した人とレジを通った人の比率は概数値で既知である
• 客単価の平均や分布がどんな感じか
• etc…

という、小売業界の社員、特に管理職とかだったらそういうこと考えなきゃモグリでしょ？(個人の感想です)
レベルの発想から変数を洗い出し、ブレークダウンして考えていけば、
いたずらに変数を増やしすぎず、でも人間がやるには大変だ、
という程度の数の説明変数に自然となるのではないでしょうか。
例えば、その日にお客さんが何人、というのは、
お客さんの来店理由には、商品指名買い、たまたま来た、などの種類があり、
それぞれのクラスタに対して異なった購買に至る確率があると思います。
指名買いの場合は購買確率が高く、たまたま来た人は普通ですよね。
そして、たまたま来た、という人の人数は、
ハンズがある街を歩いてる人の人数を従属変数に持っていると考えられます。
街を歩く人の内一定の割合の人が東急ハンズという魔窟に吸い込まれ、
さらにそのうち一定の割合の人がうっかりお買い上げになってしまう、という美しい流れです。
これはさらに、日付・曜日や店舗の所在地、
天候や最寄り交通機関の運行状況などを従属変数に持っていると考えられます。
と、こんな風に、誰が考えてもわかりやすい要因を挙げ、それらがどのような変数の関数であるか、
という考えを再帰的に突き詰めていけば、
どのような説明変数を使うべきか、ということが考えられると思います。
実際には上記の様に綺麗に考えることは難しいと思うので、
これも変数じゃね？あーこれは別のあの変数の従属変数だな、のように、
発見的になることもありそうです。
また、天候や最寄り交通機関の運行状況などは重要でありながら、
せいぜい確率的にしかわからないはずなので、
こういった変数をどのように活かすか、あるいは使用しないか、という判断も必要になると思います。

MLのモデルの作成

チームによって若干の違いがあり、大きく以下のように手法が分かれました。

• 全店共通の1モデル。店舗コードを説明変数に持つ。
• 1店舗毎の約50モデル
• 東急ハンズ業態の店舗と、ハンズビー業態の店舗の2モデル(売上規模によって2分)

売上予測の結果は、
店舗毎モデル>業態別モデル>全店共通モデル
の順に正解率が良いチームがはっきりと分布していました。
なので、今回は店舗コードをカテゴリカルな従属変数にするよりも、
店舗毎の隠れた変数を、店舗毎のモデル生成に繰り込んでしまうのが正解だった、
と言えそうです。

可視化

特徴的だった方は、

• ML->S3->Lambda->Kibana
• Tableau
• Elastic Beanstalk + DynamoDB WebApp

でした。
Kibanaやっぱりかっこいいなー、という小学生並みの感想。
また、前述の様に天気は本来確率的にしか予測できないので、その矛盾を解消するために、
天気ごとの予測売上を出すアプリケーションを作った方がいました。

まとめ

データ分析におけるETLにかかる時間の割合は非常に大きく、もちろん今回のハッカソンでもそれは例外ではないようでした。
元データを取り回してMLに投げられるデータを作るに至るまでの苦労が、ほとんどの参加者の発表から伺えました。
普通の統計解析だろうが、機械学習だろうが、避けて通れない道なのだなというのを改めて感じました。
また、機械学習だから大量の説明変数を使えるからといって、対象によっては、無理に増やさなくてもそれなりのモデルは作成可能なのではないか、という印象も受けました。
それはそれで、得られる結果が古来よりある多変量解析と何が違うんだという気もしますが……
また、ハンズの店舗の管理系社員が作成した予算の精度、本当にすごいなというのが、
ハンズラボメンバーの感想です。
在庫高、仕入れや販売の流量などが肌感覚でも帳簿の上でも詳細にわかっているからというのもあるかもしれませんが、
それにしても8割方誤差20%以内の日であるというのはすごいものだなと思います。
ハッカソン、Meet-up 共に、参加者の皆様には楽しんで頂けたようで、
おかげさまで開催してよかったと思えるイベントとなりました。
以下の様に、まとめと感想も書いて頂いております。
Amazon Machine Learning ハッカソン with ハンズラボに参加しました – Qiita
今後も、また何か一般公開のハッカソンをやるかも……？
AWS QuickSight を使ってやるとかも良さそうかなと。早く使えるようになるのを待ってます。
Amazon Web Services ブログ: 【AWS発表】 Amazon QuickSight – 高速で簡単に利用できるビッグデータ用BI（Business Intelligence）, 従来型ソリューションの1/10のコストで実現
最後に、今回のハッカソンを共に推進してくれたハンズラボメンバー、
ADSJの皆様、そしてハッカソン参加者の皆様、本当にありがとうございました！