Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－

Struggling with BIGDATA
-リクルートおけるデータサイエンス/エンジニアリング-
株式会社リクルートテクノロジーズ
ITソリューション統括部ビッグデータ部

2Copyright © Recruit Technologies Co., Ltd. All Rights Reserved.
趣味etc
学歴
略歴
所属
氏名
RTC ITソリューション統括部
ビッグデータ部 IT-EXE
西郷彰
大阪大学工学部
筑波大学大学院ビジネス科学研究科（MBA)
2009年リクルート中途入社。
じゃらん、ポンパレなどのCRMやレコメンドのプ
ロジェクトを推進。BD専門組織の立上げを経て、
現在、BD部IDP領域Gのマネージャー兼RHD_IDP
戦略企画統括データ解析Gを担当。
スノーボード（インストラクター資格有）
-子育てが忙しくめっきり行けなくなりました
自己紹介

1
2 ビッグデータ部とビッグデータを取り巻く環境
3
4
5
データ活用事例紹介
新技術検証 R＆D
全社データ基盤
アジェンダ
仕事内容のイメージ
6
リクルートグループについて
まとめと今後7

リクルートグループについて

リクルートのビジネスモデル
さまざまなドメインでマッチングモデルに基づいたビジネスを展開。
Matching
Business
HR
Bridal
Group
Buying
Used
Cars
Travel
Real
Estate
Beauty Gourmet
Social Games
E-Commerce
Ad Network
New Business
Consumers Enterprise

リクルートの事業領域
「選択」をサポートするような情報サービスを展開
Life event area Lifestyle Area
Travel
IT/ TrendLifestyle
Health & Beauty
Job Hunt
Marriage
Job Change
Home Purchase
Car Purchase
Child Birth
Education

ビッグデータ部と
ビッグデータを取り巻く環境

Infrastructure
/Security
Project
Management
UXD/SEO
Internet Marketing
Big Data Solutions
Technology R&D
Systems
Development
リクルートテクノロジーズの立ち位置
リクルートホールディングスは7つの主要事業会社と３つの機能会社から成り立っている。
Recruit
Holdings
Recruit Career
Recruit Sumai Company
Recruit Lifestyle
Recruit Jobs
Recruit Staffing
Recruit Marketing Partners
Staff service Holdings
Recruit Technologies
Recruit Administration
Recruit Communications
Business/
Service
Function/
Support

数値で見るデータ解析案件状況
約200 データ解析案件数（年間）
ビッグデータ部の案件従事人数約250

ビッグデータ部で扱うデータ
事業のトランザクションや
マスタデータを用いた解析
※ 主にオンプレ
非構造データを用いた
Deep Learningなどの解析
※ 主にパブリッククラウド

ビッグデータ解析部門の組織体制
ITソリューション統括部
ビッグデータビジネス
コンサルティング
グループ
ビッグデータ人材領域
グループ
ビッグデータ販促・
バイト領域グループ
ソリューションを
軸とした予測、BI、
競合分析
人材領域を軸とした
各種レコメンド等の
開発・分析
販促・バイトを軸と
した各種レコメンド
等の開発・分析
ビッグデータＩＤ・
ポイント領域グループ
IDポイントを軸とし
た各種レコメンドの
開発・分析
ビッグデータプロダ
クト開発グループ
ビッグデータインフ
ラグループ
ＩＤポイントビッグ
データシステムグ
ループ
ソリューションを
軸とした各種&D系
プロダクトの開発
ビックデータ基盤
の構築・運用
ビックデータ部
IDポイントPRJの
基盤の構築・運用
・・・

仕事内容のイメージ

事業の参謀としての役割
・MP
・事業企画
・営業
・BDGメンバー
提案
相談
事業のみなさんと協働しデータ解析を行う。
こちらから技術ベースの提案を行ったり、相談を受けたりする。

リクルートにおけるR&Dの考え方
R-Stage Dev-Stage β-Stage 運用-Stage
技術要素調査
技術の実態を
把握する
効果的な仕組み
としてプレ実装
活用方法をさらに
開拓
正式にフィジビ
リティスタディと
して推進～展
開をする
実運用へ
Gate Review

データ利活用案件紹介

紹介案件
画像解析クロスユース施策
 ネイルデザイン判定 アイテムレコメンド
転職支援
 マッチング&AI

2016年6月7日日経産業新聞
リクルートの主力領域で人工知能が求職をサポート

サイト間クロスユースレコメンド
 リクルートポイントからホットペッパーグルメのほか、じゃらん、ホットペッパービューティ、カーセン
サーなどからポンパレモールへのクロスユースレコメンドを展開。
 リクルート全社でのクロスユースレコメンドを推進している。

ホットペッパービューティネイル判別実装
似ているデザインから探す
カラーから探す
39色から選択可能
似ている画像を表示
New①
New②
New① New②

新技術検証 R&D

ビッグデータの概念
Volume
データ量
データの多様性
Variety
Velocity
データの発生頻度
ビッグデータの定義で示されるデータの多様性に注目。

非構造データに注目
情報誌やフリーペーパーといった紙媒体が多く存在していたという経緯もあって、いまだ内部に画
像、テキスト、動画などのさまざまな非構造データが存在する。
テキスト画像

多様化するデータ解析
利益貢献コスト削減
レコメンデーション帳票レポート
指標・目的
 CVR最大化
 CPA最適化
指標・目的
 最適化
 次期戦略策定
指標・目的
 無駄の排除
 工数削減
 人はよりクリエイティブに
作業代替・支援
（AI領域）
非構造データは、機械的解釈のむずかしさから人の手でその解釈が行われてきた。
テキストや画像などから特徴抽出をするための手法が数多く、オープンソース化され
機械で扱えるようになってきた昨今、レコメンド、帳票以外に「人の作業代替」という新たなジャン
ルのデータ解析ソリューションが増えつつある。

API化による効率化
リクルート内多様なサービス
モデル化
API
API
API
モデル・技術共有
コール
再学習

R&D取組紹介
A3RTシリーズ

A3RTサービスリスト（一部）
レコメンド
バナー
ターゲティング
OCR
画像解析
原稿サジェスト
文章校閲
文章要約
文章分類
音声テキスト化
屋内位置測位

背景
 リクルートにおいて広告主であるクライアント原稿の品質担保は大事な要素である
 現在、多くの人件費をかけて「人手で」校閲作業を行っている。
 一方で、校閲作業は人のナレッジや感覚に左右され、品質が一定ではないばかりか、すべての
原稿を人手でチェックすることは労力的には難しい状況である。
この校閲作業を機械で一部代替できないかという取組を開始している。

プロダクト開発状況
 一部の事業と協力して検証を開始している。
 はじめはルールベースのものから実装し、機械学習による分類やDeep Learningを用いた誤
字脱字チェックなど実装難易度をあげていくという進め方。
 100％人の代替は不能ということをきちんと事業と認識しながら進めている。要はその人の作
業をリプレイスする意味合いであり、その人自身の作業も100％の精度ではできていないこと
を自覚する必要がある。

DeepLearningによる誤字脱字チェック
 原稿データを学習させたモデルに文章を読み込ませ、その系列のなかで特定の単語が出現す
る確率を算出。確率が閾値より低い場合はアラートをあげ、代わりに確率の高い単語をサ
ジェストする機能を開発。

ArGonのデモ

A3RTサービスリスト（一部）
レコメンド
バナー
ターゲティング
OCR
画像解析
原稿サジェスト
文章校閲
文章要約
文章分類
音声テキスト化
屋内位置測位

車種判別機能：背景
近年？？若者が車に詳しくない！！
かっちょえええええ
かわええええええ
名前わかんね
凄く大きな機会損失

車種判別機能とは
カーセンサーのアプリの機能で、
車の写真を撮ってアップすると、似た車種名と一致率のTOP5が分かる。
そして、そのままその車種の検索結果一覧へと遷移できる。

車種判別フロー概要
…
…
…
CNNで作成した
車種判別モデル
車の写真
2674車種
・オデッセイ
・エスティマ
・CRV
・MPV
・
・
・
・
・
・フェラーリ
車種精度
68.2%

学習データの作成に工夫
外装
ラベル名画像例
内装
トランク
ダッシュ
ボード
その他
学習枚数
約3500枚
約2000枚
約1000枚
約1000枚
約2500枚
カーセンサーの物件画像を
内装/外装/トランク/ダッシュボード
/その他に分類するモデルを作成。
これにカーセンサーの約37万物件
の画像を全て投入
外装と判別された約80万枚を
そのまま学習に利用
結果、2674車種という、
これまでにない多種な分類でも
70%弱の精度を叩き出せた

学習データの作成に工夫
ただし「流通量が多い車種=学習画像が多い車種=精度が高い車種」
となり、掲載数の多い上位500車種では平均92.4%の精度を出すが
掲載数の少ない下位の車種では、精度が一桁を切ることもある状態。
そこで利用者に正解しているかを
フードバックしてもらう機能を実装。
これで「正しい」を選んでくれたら、
その画像を追加で学習すれば良い！
# 現在は、本機能が本当に正しい時に押
されるかなどを検証中。

Twitterでバズりました！
プレスリリースを10/26に実施。
10/26中にTwitterで「#カーセンサーチャレンジ」
というハッシュタグが作成され、最高風速で
分間4ツイートくらいされてました。（肌感）
一時、appleのトレンド検索に「ポケモンgoマップ」などと並
んで「カーセンサー」が！！！
ありがたいことにたくさんの人に利用してもらえました！

２ヶ月前
モデル作成
3週間
２年前
モデル作成
３ヶ月
紹介した案件はモデル作成時間が大きく違う
２年という歳月におけるノウハウの蓄積の差もあるものの
CNNでのモデル構築を効率的にする周辺技術の存在が大きい
ネイルでの学びから、周辺技術を作成していきました。

ネイル時に立ちふさがった大きな壁
①判別モデルを作りたいけど都合良く
学習データがない・・・
②学習始めたけどパラメータが
多すぎて最適解がわからん・・・

困難① 学習データがない
爪デザイン当て初めはクライアントが入稿するときに付与するタグを利用。
例えば、左の例では、「ドット（水玉）」が付与。
これを学習用のデータとして使用した結果、
驚愕の精度18%！？(ランダムでも5%の精度)
そもそも、リボンも映っているし、ワンカラー(何も柄なし)も映っている。
これが「ドット」で良いのか？？
人によってデザインとして付与するタグが異なるのでは・・・・
なら、誰もが同じタグになるようにしてあげれば良い！
CNN使えないじゃないか・・・
発想を変える。

ただし、僕らの部署はIT系の業務をやる部署。
ネイルなんて分からない男性が多い中、必死にネイルの知識を付ける。
：マーブル
：ピーコック
：プッチ
副産物として
合コンで相手の手を見て、「ダブルフレンチ
か・・・」と呟く、気持ち悪い男性（私）の
出来上がり。
せんせー
ピーコックとマーブルとプッチの
違いがわかりませーん！
このようなやりとりを通し、まず主要メンバがネイル
判別のセミプロになり、徐々に作業メンバもセミプ
ロになってしまった。
約20人で合計4万枚もの爪画像に、正解タグを
振る。
結果、ある程度誰が見ても納得できる正解データ
が作成できた。
困難① 学習データがない

VATを用いた半教師有り学習
• VATを用いた半教師有り学習
• 半教師有り学習：少量の教師付きデータと大量の教師なしデータを用い
て、比較的高精度のモデル作成する手法。
• ICLR2016の採択論文の手法を試す。
mnist[0~9の手書きデータ]を利用し、
以下を検証。
教師有りを600枚使っただけで、
60000枚全て利用した時とほぼ同等の
精度が得られた。
学習利用枚数
誤
差
率
(%)
＝大量の画像全てに正解ラベルを付与しなくても良い。
→学習データの収集コストが大幅に下がることが期待できる。
・60000万枚の画像を学習に使った精度
・各枚数を学習に利用した時の精度
・各枚数を教師有り、残りを教師なしと
して学習した精度

全社データ基盤

リクルートID

サービスA
事業DB
アクセス
ログ
サービスB
事業DB
アクセス
ログ
サービスC
事業DB
アクセス
ログ
データソースデータ格納演算処理・活用利用者
Hadoop
エコシステム全社DWH
中央Hadoop
• モニタリング
• レポート
• モデル作成
• データ収集
• 整形・加工
• データストレージ
• 高速分析処理
サービスA
担当
サービスB
担当
リクルートID
担当
サービスC
担当
リクルート統合データ分析基盤
クエリ発行/月
• 膨大なデータを使ったデータ活用業務全般
• レポート/モニタリング、レコメンド、DMP、etc

最初に苦労したこと、「データ理解」
データ意味情報（メタデータ）の問い合わせに忙殺される。
会員情報はどこにある！？
XXの意味を教えてください！
利用者
テーブル定義書（ファイル）
DWH
Select * from XX limit 100
Select * from YY limit 100
Select * from ZZ limit 100
・・・
開発者
システム管理者
分からないです…
“平均的なビジネスマンは、探し物のためだけに、1年間で約150時間を費やしている”
利用者がわかる形で回答
×
データの質・量の増加
利用者の増加

メタデータ管理Web
データ意味情報（メタデータ）を機械化するためのシステムを作成

意味検索によるユーザビリティ改善
Library
A → Z
Discovery
Search Engine

設計情報→Knowledge共有＋SQL_Analysis
ER図表示
analysis
SQLを解析し、設計情報に出てこないDB
を跨いだテーブル間の関係性も可視化
関連の強い順に表示

ココに来れば必要な情報があるという状態を作り出し、分析担当者のデータ
特定に至る時間やシステム担当者の負担を軽減させる。
 探す手間が省ける
 ナレッジが共有される
利用者
テーブル定義書（ファイル）
探す
メタデータ管理Web
DWH
 問合せが減る！
 潜在的なニーズを拾える！
 問合せが減る！
 自分のDBの最新情報が把握できる！
開発者
自動
自動
自動
年間75人月超の工数削減効果
（20分/セッションの工数削減効果）
＋
問合せを受けるシステム管理者の工数削減
メタデータ管理Webで実現した世界

横断データ活用：フェーズにおける課題
• ID基盤が整いデータが増加し、我々は成長期の真っ只中
• 爆発的な成長を目指すが・・・技術的負債が顕在化
51
黎明期成長期

黎明期：
• 各サービスから各種データを収集、DWH/Datalakeに蓄積し活用
• サイト毎の仕様差異の吸収個人情報のマスキング重複や欠損のクリーニング…
• 横断データ活用への最初の要求は、経営陣からの「経営指標」の集計
• 日次/月次実行する”資産”となり、加速度的に増加
• DMTを機械学習の学習データとして転用
• 次々と機械学習アルゴリズムを変えるため、データ間の依存度が加速
• システムが一旦出来上がるが・・・
DWH
横断データ
活用施策

黎明期：システム運用
DWH MLlibDWH
0001
0002
0003
0004
Change
prediction
corrupt
Change Change
more
users
Bigger
DMT
more
data
source
We changed
log spec!
bug
Mis
match
Mis
match
rerun!
more
work

考察：なぜ仕事が増えるのか
最初はシンプルな業務フローを考えるが、業務は複雑化して増えていくもの
DWH DMT APP
開発業務の増加
・クエリ複雑化
・依存性複雑化
・再発明
・リカバリ
・仕様変更対応
運用業務の増加
・Hadoop等バグ調査
・繁忙期データ負荷対応
・リソース不足
・データ転送
待ちの増加
・機械学習用DMT開発
における低再利用性
・DMT処理時間待ち
・アルゴリズム変更に伴う
入力仕様変更

技術的負債の溜まり場
黎明期に描かれた古典モデルの破綻
昔から言われていることでも有る、データマネジメント業務の不・課題
DWH
DMT APP
どうしてもココに課題が貯
まっちゃうんですよね・・・

フレームワークプロジェクト(var/log)
• 技術的負債を徹底的に排除するためのコードベース(jar)
Integrate
software
resources &
unlock
their full
potential
“Absolute DRY”
common process
auto generated
DSL for
processing
typically
structured
data of Recruit
Codebas
e

DRY(Don’t repeat yourself)
もっとも大切な要素として、コードの再利用
コンポーネント + コード生成
補完前
Loading
Mahout
Saving
xml 補完後
Recommend
User (Int)
Item (Int)
Dictionary
UserId (Int)
User (String)
Dictionary
ItemId(Int)
Item(String)
Input
UserId (Int)
ItemId(Int)
Loading
Mahout
Saving
Indexing
Format

Simple
• DASE ”MVC for Data Science”
• それ以外は極力隠蔽 <data/> <algorithm/> <serving/> <evaluation/>
xml .Jar
Loading
Query
Query
RDD
+Scala
Jar内部で判定
• 次のAlgorithmは何？
• データ量はどのくらい？
• 過去の判定結果は？
MR
Parallel
Query
Hdfs+
External

プロジェクト完了!?
• 半年後、var/logは完成し、最初のvar/logジョブがリリース！
• その後、新規ジョブはvar/log上に実装されるようになった。
• 半年後var/logは完成し、運用に乗ったが、２通りの社内顧客
が見えてきた。
Business Engineer
Scientist Engineer
1.[High-end Customers]
ニーズ : 速度・定常運用・生産性
2.[Early Adopters]
ニーズ : 最新論文・実験・Lean
コードは使い捨て
データがあり
動けばいい

Move onto Agility
DWH DMT APP
DWH DMT Produ
ction
pub
sub
Sand
box
Business
Engineer
Scientist
Everyone
黎明期
成長期

Early Adopter向け機能とは何か
ニーズ：さあ、実験をしよう。
秒単位の応答性能
その場の思いつきを実データに適用
新しいライブラリ・・・
新しい特徴量・・・
新しい数式・・・
新しい自作関数・・・
そして、、、そのままリリース
→ jar + xml configuration ではない

import varlog.jar on Zeppelin
.Jar
その場で作った
自作関数(動作確認後varlog.jarにコミット)
データ抜きだし・加工

Workflow Change : Happy Analytics
• Before：
• After：
.Jar
Scientist
Scientist
HBase Hive Oracle
sqoop
“accessible data”
• 実験
• 生産性
• 共同作業
• 即時性/インタラクティブ性
Java
・・・

我々が今目指している環境について
Analysis Ops
Engineering
Study
Idea
try
Scientist

DevOps for BIGDATA全体像
バージョン管理
チケット管理メトリクス可視化
開発環境
Biz
必要に応じて相互に
開発協力。
Ops
Dev
本番環境構成管理
CI / CD
サンドボックス環境

DevOps for BD 独自の取組紹介
• ベンダー製ジョブ管理ツールの可視化
ジョブ可視化ツールデータフロー可視化ツール
ジョブおよびデータフローがリアルタイムに可視化されたことで、
障害検知および対応が高速化に寄与
内製開発ツール

文化面での取組
• カイゼントレーニング
• 組織メンバー全員参加での集合研修
• 目的
• 自分たちの提供しているサービスの価値をあげるために、
• 改善のやり方を学ぶ
• コミュニケーションの仕方を学ぶ
• 実際にいまのプロセスを見える化し、全員で現状の共通認識や
課題を明らかにする
バリューストリームマップを作成し、業務にお
けるボトルネックを全員で切り分けている様子

文化面での取組
• Mob Programming
• チーム全体が同じことを、同じ時に、同じ場所で、同じコンピュータ上
で作業するソフトウェア開発アプローチ
• 目的
• 全員が同一作業を行うことによるコンフリクトの解消と、黒魔術
的な個人ナレッジの共有を図る。
毎週金曜に2時間、全員で同一作業を行う時間
を設定し、ワイガヤをあえて演出

まとめ

データ活用における大きな変化と今後
？
？分析→CV改善施策
ディスプレイ
API
レコメンド API
アドホックな分析

Web企業におけるデータ活用の本命は？
No single standard
それくらい多様化、常に進化。
より新しいことをフロンティアしていかないといけない、自ら。
クライアント
BtoB 分析
OtoO
リアル情報解析
超大規模データ
活用
非構造
/Deeplearning

ご静聴ありがとうございました
リクルートテクノロジーズ
Now, We Are Hiring!
自ら高い山を設定し、ビジネス活用にコミットし
た分析・エンジニアリングにチャレンジできる方。
ぜひご連絡ください。

Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－

Similaire à Struggling with BIGDATA　－リクルートおけるデータサイエンス/エンジニアリング－ (20)

Dernier

Dernier (8)