050896 ランダム
 HOME | DIARY | PROFILE 【ログイン】

Rakuten Tech Blog

全47件 (47件中 1-10件目)

1 2 3 4 5 >

2016/12/24
XML
カテゴリ:Advent Calendar
kawagutiです。
手探りではじめました楽天エンジニアアドベントカレンダー、おかげさまで多くの社員に書いてもらうことができました。皆様、お読みいただき、ありがとうございました。

12/2 : kawaguti 「DevOps とリーンスタートアップ時代のプロダクトオーナーシップ」
12/5 : hyoshiok「海外の技術カンファレンスに行こう
12/6 : Yukarin : 「楽天アジャイル就活〜1日で内定!採用イベント 
12/7 : tkak「PackerでRIaaSのテンプレートイメージを管理する (VMware vSphereとOpenStackの事例紹介)
12/8 : Hangai :「仙台でハッカソンやったら店舗さんを泣かせちゃった話 (1)
12/9 : Satoryu : 「ひとりじゃできない!始めようOSS開発!

12/10 : kawaguti : 「Qiitaでも更新しています。
12/12 : Mio :「みんなで作る!社内ポータル
12/13 : Ono : 「分散処理のススメ
12/14 : Ayana : 「Englishnization:TECH Communityのいまと研修企画
12/15 : Taichi「Front End GroupなのにFront Endしてない人の話
12/16 : Reina : 「Rakuten way!プロダクトの作り方
12/17 : mecab「Zshでプロンプトのホスト名をホスト名によって異なり、かつ読みやすい色にした。
12/18 : yokopy : 「楽天サービス運用の現場より -札幌支社の取り組み-
12/19 : Shino : 「JIRAのWorklogをごにょごにょしてメトリクスとして活用する事例
12/20 : Egi : 「プログラミング言語研究の楽しみ
12/21 : umeda : 「機械学習によるコンテンツの人気予測 in Wuaki.tv
12/22 : TAKAKING22 : 「カンバンの基本のキ
12/23 : 森正弥 : 「AIの前に、機械学習のECへの応用について無茶をしながらざっと書いてみよう

現時点での閲覧数最多はhangaiさんの「仙台でハッカソンやったら店舗さんを泣かせちゃった話 (1)」でした。エンジニアの枠を越え、楽天ならではの地域貢献活動が共感を呼んだのではないかと推察いたします。

利用させてもらっている楽天ブログのサービスも進化を重ねており、期間中の19日に「予約投稿(未来日記)」がリリースされ、このおかげで週末の更新が容易になりました。

Rakuten Tech Blog を今後もよろしくお願いいたします。







Last updated  2016/12/24 06:53:39 PM
コメント(0) | コメントを書く
2016/12/23
カテゴリ:Advent Calendar
こんにちは。楽天技術研究所の森正弥です。


アドベントカレンダーに書いてくださいよ~、と頼まれまして、それも、kawaguti さんに頼まれまして、これは書かねばならんと思いました。ですが、何を書いたものかと頭を悩ましました。今月頭にインドのIIT HyderabadやIIT Bombay に行きまして(写真はIIT Hyderabad の遠景)、インドの学生の方々のレベルの高さやIITのカリキュラムの凄さに触れ衝撃を受け、「もう日本の大学は一切勝てないな」と煽り抜きで感じてしまったのでその話を書こうかとも思ったのですが、なんとなく、技術的なことがムラムラと書きたくなって、ただ、突如としてマニアックなことを書いても、みんなに引かれるだけなので、引かれそうな引かれなさそうなところのラインを狙いながらも、知っている人にも知らない人にも、うむうむ、と思っていただけるような内容について考えまして、やはりここは来年の2017年以降数年を睨んだときに社会そのものを大きく変革することは間違いないAIに連なる内容として、初歩としての機械学習についてちょっと書こうかなと思ったのです。機械学習って例えば楽天のEC(楽天市場)での現場ではどういう風に使われるのか、ということについて、あまり知られていないこともありますし、教科書的な感じにその活用について整理してみます。

(長文になりました。みなさん、すみません。)


■ AI技術としての機械学習の重要性

人工知能(AI)とは、今日、曖昧な使われ方をする言葉ですが、初出は1956年 “The Dartmouth Summer Research Project on Artificial Intelligence (人工知能に関するダートマスの夏期研究会)”いわゆる「ダートマス会議」でジョン・マッカーシーが名付けたの最初だと言われています。概念的なことやその議論の変遷は色々と難しいんですけど、広く通じるような捉え方としては、AIとは「人間の脳が行う知的作業をコンピューターで実現することを目指したソフトウェアやシステムのことであり、具体的には、環境や物体の認識、人の使う自然言語の理解や論理的な推論、経験からの学習を行うプログラム」のことを指します。AI を実現するための基盤となる技術というのは多岐に渡ります。ほぼコンピューターサイエンスの歴史そのものといってもいいので。自然言語処理、パターン認識、画像処理、音声認識、機械学習、ロボティクス、あげればいくらでもあるわけですが、近年のビッグデータの潮流の中、人や企業の多くの活動がデジタル化され、取得可能なデータが増え、活用機会が拡大したことに伴い、それを有効活用するための各種AI技術も注目されています。

AI技術(バラク・オバマ大統領が先日、「専用AI」という言い方をしていましたが、これは非常に適切な言い方ですね。 http://wired.jp/special/2016/barack-obama/ )は医療から交通、電力供給まで生活のあらゆる面に関わる形で本当に幅広く使われています。対して、EC(E-Commerce)ではあまり使われていないだろうというような意見も時々伺うときがあるのですが、実際はECでも様々な利用が見られます。そもそもECでは、人手を介してセールスマンが直に顧客に接してその要望を把握しより付加価値の高いサービスを提供していくということが難しいです。といいますか、そういうミドル・マンを排除することにビジネス上の意義があるわけです。人手を介していないので、顧客への提供価値を高めていくためには、データ活用の知識・技術を用い、顧客の要望を理解してあるいは推測して商品やサービスを提案するレコメンドや、顧客に応じた情報やサービスの提供を実現するパーソナライズ機能を備えていくことは必須事項と言えます。

それだけでなく、商品検索の精度向上のため、自然言語処理による商品データも用いた詳細な解析や、商品の評判情報を分析する評判解析、レビュー・アナリシス、センチメント・アナリシス等が行われます。また、昨今のマルチメディアデータの普及に伴い、画像認識技術を用いた商品画像・動画の検索機能や、音楽認識機能を用いた音楽・映像コンテンツの検索・レコメンド機能、音声認識技術を用いた対話型のUI機能等、多様な活用が広がっています。

10年近く進行してきたビッグデータというトレンドにより、保有データは大量かつ多様となり、人力で取り扱うことが難しい種類や量になってしまいました。このようなデータ増を背景に、AI技術の中でも特に、前述したレコメンド、自然言語処理、画像処理など各適用領域のどれにも横断的に存在する機械学習の重要性がましているわけです。みなさん、機械学習をやりましょう。

例えばレコメンドでは、顧客の購買情報だけではなく、顧客の属性情報や商品の閲覧履歴などを組み合わせることで、推薦された商品のCVRを高めることができます。これを推し進めて効果を最大限まで高めるために、組み合わせる情報をできるだけ増やしていきたいと考えるのですが、組み合わせるデータの種類が増えていくと、データ間の効果的な組み合わせを行うモデルを人が定めていくことは困難になっていきます。(直接関係ないですが、組合せ爆発の動画は面白いです。 https://youtu.be/Q4gTV4r0zRs )実際のビジネスではなんだかんだ使える時間も予算も限られていますので、その容赦ない制約によって人が業務内で考えることが可能なデータの組み合わせ数の限界に容易に到達します。ゆえに、機械学習手法を効果的に用いて手作業を減らし、扱えるデータ量も増やしてくということは今日のビジネスにおける現場業務の肝となっていくわけです。

■ 教師あり学習

ECへの機械学習の適用は、もう、ものすごーく幅広いわけですが、その手法としてまず知る必要があるのは、「教師あり学習」と「教師なし学習」という代表的な分類です。教師あり学習とは、事前に与えられたサンプルとなるデータをいわば「教師からの例題(教師情報)」とみなして、それを参考にデータの識別や法則性の導出を行う手法になります。

例えば、(いきなり最初から「それ機械学習じゃないだろ」論争を呼びそうなところから始めますが)回帰分析は教師あり学習の最たる典型手法であり、統計手法として広く知られているため、ECではトレンドの予測、例えば、商品の売れ行きの予測等で使われるケースがあります。楽天ではビッグデータを扱う部署が5年ぐらい前からありまして、そこで商品販売量を予測するシステムを構築しており、季節性・イベントを加味した非線形回帰モデルによる予測を行っています。このシステムは、販売量を被説明変数に、日時、月末、連休、販促活動(セールやキャンペーンなどですね)、天気、温度などの情報を説明変数として学習させることで関係性・法則性を導き、各商品の売上を推定します。説明変数に天気が入っているところがポイントなのですが、一般的に大雨が降ったり、大雪が降ったりするとECの売上はあがります。そこは面白いところです。マイナーな商品の販売量も高精度で予測ができ、時々びっくりします。人力での予測ですともちろん精度は荒くなりますし、楽天では2億点近いアイテムを扱っていてロングテールの量が半端なく全てをカバーできることはないわけなので、このようなプラットフォームが必要になります。人手ではないため誤発注による大幅なロスを抑えることもでき、リスクをコントロール可能なレベルにもっていくこともできます。

予測の話に偏ってしまいましたが、他にも教師あり学習では、判別分析である、サポートベクターマシーン(SVM)というバイナリー分類のパターン認識モデルが超有名で、一般的にデータや文書の分類などに広く使われます。ECでも、商品やユーザーの分類に使うこともありますね。また、セキュリティで使われることもあり、例えば、数多あるユーザーアクセスの中から、不正なアクセスを検知するために、過去の不正事例から、IPアドレス、ロケーション、アクセスパターン、検索語のパターン等を素性(機械学習の入力)としてモデルに学習させて判別器を作成する等もあります。SVMを前述の回帰分析に用いたサポートベクターリグレッション(SVR)というのもあります。

判別分析では、集団学習という単純な判別器(弱学習器)を組み合わせて精度を高めていく方法が特に最近人気があるような気がします。例えば、各種Boostingの手法(AdaBoost、XGBoost)やRandomForest等です。例えば、楽天では、過去に商品画像の中で特にきれいな画像を選り分けるためにAdaboostを使って抽出したり、またXGBoostを、商品データの分類・整理の精度向上目的で大規模に適用していたりします。

ところで、RandomForest はあまりドメイン知識がなくても高い精度を出すことができるので結構面白い利用例があります。楽天には70近い多様な事業があり、様々なデータが存在しているのですが、その中で競馬事業という事業があり、地方競馬の馬券購入サービスを提供しています。去年、競馬事業にて若い方々、学生やエンジニアの方々と一緒にハッカソンを行いまして、地方競馬を盛り上げるサービスやアプリを考えましょうということをしました。そこで、あるチームが勝ち馬を予測するモデルを構築しまして、実際に大井競馬場での順位の予想を行い、脅威の的中率を見せました。彼らは全く競馬の知識がなかったのですが、様々な方法を試してRandomForest が一番良さそうだと選び、その場にいた競馬予想のプロの方々もびっくりさせるシステムを作ったわけです。(参考: http://logmi.jp/170135 )ドメイン知識が不要でも成果を生むという話は本稿でもこの後も出るのですが、なかなか真剣に考える必要があるテーマです。

教師あり学習では、サンプルとなる教師情報に対する学習の結果、過剰にサンプルデータに適応してしまい、実データや未知のデータを用いた判別や予測の精度が下がる、いわゆる「過学習(Over Fitting)」なる問題があります。これは本当に根深い問題で、実際にアプローチによってはどうしてもサンプルデータが少なくなるケースや、モデルに組み込んでいないモデルの外の環境の要因を過小評価してしまっていて、外部環境変化に対応できないケース等があって避けがたい。例えば金融商品の値段を予測していくモデルを作ってもサンプルとなるデータが、物体認識での画像データ等とくらべて圧倒的に少ないですし、例えば災害や政治動向などの影響を実際は大きく受けるので、どうしてもバックテストは完璧なのに実際の予測では思うようにいかないみたいなことがあります。そのため、教師あり学習の適用時には、モデルの自由度や複雑さ、また学習結果を点検しつつ、過学習をできるかぎり防いでいく心構えが必要です。

■ 教師なし学習

教師あり学習に対し、教師なし学習とは、事前にサンプルとなるデータがない状態で、実データ自体を解析することで、データに存在する本質的な構造や特徴を抽出する手法です。

「ちょっとこれ、分析しておいて。え、例えばどうやればいいかって? そんなのいいから、とにかくデータ分類しておけばいいんだよ。あとは自分で考えな」こうですか!? わかりません。><

というのはおいておきまして、例えばECにおける代表的な機能であるレコメンデーションでは、推薦を行う顧客や商品を分類するために教師なし学習手法であるデータクラスタリング手法がとても多く使われています。また教師ありと同じくセキュリティでも使われることがあり、ログインアタック検知の際に、どのようなアタックパターンがあるのかを知るためにクラスタリングをしていくことがあります。

さて、そんな教師なし学習の手法ですが代表的なのは、みなさんご存知のk平均法(K-Means)やテキストマイニングの潜在意味インデックス(LSI)、トピックモデル手法(LDA)等です。k平均法(K-Means)とは代表的なクラスタリング手法の一つで、計算を反復的に行ないつつ、データを与えられたクラスタ数k個に分類します。単純なアルゴリズムで誰もが通る道でもありますので、応用もとてつもなく多いわけです。とりあえずユーザーを3タイプに分けようぜ、みたいなときにさくっと便利ですね。だからこそ何の観点で分けるのかという軸が大事になるともいえますが。

潜在的意味インデックス(LSI – Latent Semantic Index)は類似した文書やデータをまとめていって、その共通性(トピック)を見つけていくのに役立つ手法で、トピックモデルと言われますが、その敷衍として、類似した顧客や商品、あるいは類似したレビュー等をまとめていくことに応用ができます。テクニカルに話すと、文書類似度を比較する最初の第一歩であるTF/IDFに次元圧縮を加えて効率を高めたものともいえます。文書やデータ内の違う単語や値でも、近い意味を持つ等の類犠牲を考慮することができ、またそこから多義性の問題をもある程度解消できて、データの意味を考えつつ分類することを可能にさせてくれます。そのため、違う表現だが似たような商品等の類犠牲を反映していく形で、商品検索やレコメンドの拡張等にももってこいではあります。もちろん人手で作った辞書、シソーラスを利用することもできますが、あらゆる言葉を網羅するのは大変なので、時に重宝します。

LDA(Latent Dirichlet Allocation)もLSIと同じくトピックモデルと言われる手法の一つで、文書やデータに用いられる語や値がそもそもどういう意味を持っているのかを推定します。次元をトピック単位に圧縮するという観点ではLSIに近いです。が、LSIはそもそも偶然対象としたデータの中に存在しなかった類犠牲のある語について考慮することができません。そこで語の確率分布を意識しながらデータ分類を行うことできるようにした、pLSI (Probabilistic LSI)という拡張があり、更に文書で表現されているトピック、つまりまとめられた文書の共通性をも揺らぎを持って扱うことができるようしたものがLDAです。やばい説明が難しい。説明よりコードを見せた方が早いみたいな話でしょうか。つまり、言葉の多義性について文書内の語でも文書のまとめ方でももっと包含できるようにしたのがLDAということで、ざっくり「LSIの確率的拡張版」というような理解でいいでしょう。完全にイメージの話ですが、LDAを使う人はなんとなくイケてる感じがします。リア充でパーティーピーポーみたいな。言い過ぎですかね。LDAは後ほどまた出てきます。

LSIやLDAはテキストマイニングの代表的手法、自然言語処理の文書分類の技法と紹介されることが普通で、そのため、ECでの用途はあまりないのではないかというイメージをもたれることも多いです。なのですが、レコメンドだけでなく商品データや評判情報の解析でも、多くは自然言語処理の文書分類タスクとみなすことができるため(教師あり学習の判別分析が使われることも当然多いが)、教師なし学習はよく使われます。もうちょっと言ってしまいますと、トピックモデルというと、語、文書、そして文書の共通性「トピック」という関係になるわけですね。語と文書から、共通のトピックをもった文書を分類していく。ここで、語を例えば商品に置き換え、そして語によって形成されている文書を、商品群を買ったり、閲覧したり、検索したりしているユーザーの情報の総体に置き換えると、文書のトピックは、そのユーザー・消費者の持つある種の潜在的「目的」や「嗜好性」「スタイル」、言ってしまうとまだ表現されきっていない「隠れたニーズ」に置き換えることができます。そういうメタファーを働かすと、文書分類はマーケティングにとてつもなく応用できるわけです。(これ以上書くと、寝た子を起こすな、と皆様からお怒りがありそうなのではありますが。)

そもそもですね、教師なし、というのはサンプルデータを必要とする技法ではない、ということになるわけですが、ビジネスにおける問題解決のための態度としての意味は、ビジネス上の暗黙の前提や先入観から離れることができる、ということです。例えば、どのEC、どの小売ビジネスでも、顧客をリピート率や購入額でグレード付をするロイヤリティプログラムを導入していて、それに基づいて様々な施策を使い分けていると思います。ですが、教師なしで、ピュアに施策に対する有効性が最大化するような形でグループ分けをしてみると、ロイヤリティプログラムのグレード分けとは全く関係のないセグメンテーションの軸が抽出され、実は、特定のジャンルにおいてはグレード別の施策って本質的に意味がないんじゃない?なんてことが判明したりすることもあるのです。教師なしは、そういう意味で、適切にビジネス知識・ドメイン知識との距離を保ちながらも、時に大胆に活用していけば従来のマーケティングの常識を覆していくポテンシャルがそもそもにあって、トピックモデルの応用等はとてもエキサイティングな領域だろうと言えます。特にここ10年はインターネットの発展、モバイルの普及、ソーシャルサービスの進展によって消費者の技術環境は大きく変化し、その購買行動も劇的に変容してしまいました。それゆえに今までのビジネス上の暗黙の前提が実はもう崩れていることも多く、ビジネス知識・ドメイン知識をあえて無視することは極めて大事な試みです。(これ以上書くと、簀巻にされて浮きそうなので、ここで止めてみます。)

■ 半教師あり学習

半熟みたいな響きがあります。半教師あり学習です。

楽天では多様な店舗の各商品の解説文やデータから、マスターとなる汎用カタログを構築するというテーマも文書分類の問題として捉え、各種自然言語処理手法の適用を進めています。しかし、取り扱っている商品は2億アイテム。食品から飲料品、衣服、電化製品、デジタルコンテンツ、スポーツ用品、自動車、家とか甲冑(!)とか仏壇とか船とかヘリコプターとかに至るまで多彩でして、ここで教師あり学習の適用を考えた場合、商品の全種類に対応した教師情報を与えることは困難です。そもそも甲冑のサンプルデータってなんですかね。過学習しまくりな気がします。そこで教師あり学習だけを用いず、ブートストラップ法的なリサンプリングを繰り返すアプローチを採用したりしています。(参考文献がないんですけど、このスライドのページに言及があります。 http://www.slideshare.net/rakutentech/ecommerce-15078624/31

半教師あり学習とは例えば、少数のサンプルデータ(教師情報)を用いてまずは学習を行ない、その後、ある程度の実データを分類して、その結果のうち確度の高いものをサンプルデータと捉え直して再度学習をします。それを繰り返すことで、教師情報を多く与えることが困難でも、教師あり学習で期待できるような効果を得ることができる。半教師あり学習は、楽天のような大量かつ多様な商品データに対しては有効に作用する面があるアプローチであり、なかなか技巧的な手法です。

■ 構造学習

文書分類問題として捉えるという話を前述しましたが、他にも文書分類問題としてではなく、違う自然言語処理の問題として捉えることで、様々な手法が適用できます。例えばマスターとなるカタログデータ構築のための商品解説文からの属性値抽出を、系列ラベリング問題と捉え、それに有効なテクニックを活用することで、商品データの解析を高度化しています。系列ラベリングというのは、入力としてデータの列を与えて、出力として個々のデータにラベルを付与するというものですが、具体例を挙げると、文章をインプットとして与えて、文章の各単語がそれぞれ何の品詞かを推定し、品詞ラベルを付与したアウトプットを得る、というような問題があります。個々の単語ごとにバラバラに品詞を推定するよりも、文章にあるそれぞれの語の品詞を、文章全体の構成を意識しながら一緒に考えていき、一括出力した方がいいケースがあるわけです。そういうときに使うのが構造学習です。

楽天では構造学習手法の一つである構造化SVMや、条件付き確率場(CRF)を用いています。構造学習は教師ありが基本ですが、教師なし・半教師の手法もあります。更にCRFでは、データを推定して分類するだけでなく、あるラベルに分類されるかどうかの確率値も算出し、より高度な推定を可能にします。それもあってか、CRFは形態素解析や固有表現抽出によく使われますね。実際の楽天での使用例としては、商品解説文やレビュー文から商品の属性やその値、レビューにおける評価観点やその評価(良いのか悪いのか)を抽出するために、LDAにCRFを組み合わせて適用したりしています。(参考 http://www.aclweb.org/anthology/I13-1190

■ オンライン学習

機械学習の勉強をしていたりすると、時々オンライン学習なる言葉に出会うことがあります。これは決して人がオンラインで(インターネットサービス等で)勉強するという意味ではないところが曲者です。

例えばSVM等の教師あり学習では、与えられた全てのサンプルデータをまずは学習、訓練します。しかし、サンプルデータの量によっては、または、アプリケーションによっては全てのデータについて一度に学習を行うのがあまり適していない時があります。はじめの方で書きましたように全てのビジネスは時間的制約があるわけですし、またコンピューターの処理能力・メモリの容量など、扱えるデータ量の制約というシステム的な問題もあります。そもそも、サンプルデータが常に逐次やってくるみたいなケースもあります。そのようなケースにおいては、データが与えられるごとにパラメーターを最適化し直して学習すると便利で、そのような手法をオンライン学習と呼びます。逐次学習と呼び替えるとおさまりがいい感じです。代表的な手法としては、パーセプトロン、CW、AROW、SCW 等があります。日本語の文献は比較的少ないのですが、前述したRandomForestをオンライン学習でできるようにした Streaming RandomForest なる手法もあります。(今、現在、社内某プロジェクトで試験中。)

楽天では、今まで見た例からも自然言語処理における機械学習の重要性を色々鑑みまして、RakutenMAという学習器つきの形態素解析器を開発し、OSSとして公開しました。(参考 https://github.com/rakuten-nlp/rakutenma )形態素解析部分は、文字単位の系列ラベリングモデルを用い、学習の部分はオンライン学習であるSCW( Exact Soft Confidence-Weight Learning )を利用しています。SCWはCW(Confidence-Weight)という、学習データそれぞれの出現頻度による違いを考慮したアルゴリズムを更にノイズに強くしたもので、ソフトマージンの最適化をしている・損失上限の証明がなされている等かなりメリットの多い技術です。Javascript で手軽に動きますのでぜひご活用ください。

■ 強化学習

AI技術の中でロボットの開発に関係のある強化学習も、ECでの適用は進んでいます。強化学習とは、教師あり学習とは異なり、教師情報は存在しないのですが、その代わりに学習した後から報酬というフィードバック情報を得ることで、更なる学習の手がかりとする手法です。強化学習では不確実性のある環境を想定しており、報酬は、その性質として教師情報と異なりノイズや渡されるタイミングの遅延があるものだと考えます。そのため、利用者の反応を取り込みつつ、システムやサービスを徐々に最適化させていく場合に適しています。

レコメンドや商品検索でも顧客の反応、つまりどれにクリックしたのかとか、すぐにクリックしたのかとか、を取り入れて推薦や検索の結果を改善していくのに強化学習が使われます。他には広告のパーソナライズやABテストの中で、多腕バンディットアルゴリズムが用いられることがあります。多腕バンディットアルゴリズムとは、限られたリソースの中で、報酬(ここでは利用者の好反応)がどれぐらい得られるか過去に経験した手段の「活用(exploitation)」と、報酬を更に得られるかもしれない未知の手段の「探索(exploration)」という二種類の行動を使い分けることで、報酬を最大化する手法です。つまり、決まった試行回数の中で、やったことがあるのでわかっていることと、やってみてないのでやってみて確認したいことを組み合わせながら、最も良い選択を追求します。代表的なものとして、epsilon-greedy、UCB、Thompson sampling 等があります。

例えば、広告のクリエイティブを2案(A案・B案)作り、それぞれ50%のユーザーに表示するABテストを考えてみます。KPIはインプレッションに対するクリックの割合と単純に考えます。この際、A案・B案どちらのクリック数もそこそこ同じ感じであればいいのですが、もしB案のクリック数が絶望的に少なかったら、ABテスト期間中とはいえ、本番サービスなわけですから、B案を50%のユーザーに表示させている分はまるまる機会損失になっているとも考えられます。そこで、多腕バンディットアルゴリズムを用い、B案のパフォーマンスが悪いと思ったら、B案の表示割合を減らして、A案の表示割合を増やしていく等して、KPIを極大化し、損失もなるべく減らしていくという手がありえます。2案だったら人手でもできますが、例えばこれがクリエイティブを60案作るとか、ユーザーのセグメントに合わせてもっと多様に作るとかになったら、人手ではそれぞれのインプレッションを調整して全体としてKPIを高めていく等は到底不可能であり、強化学習の手法を適用して自動化していくメリットがあります。

強化学習は人手よりは機会損失を減らせる、とはいえ、経験の活用と更なる報酬の探求の間にはトレードオフの関係が成立するために常にどうやれば、どこまでやれば逸失利益を最小化できるのかという課題があります。そのために何を選択するかは過去のデータ及び不完全な推定に基づかざるを得ません。多腕バンディットアルゴリズムの一つであるUCBアルゴリズムは、損失上限量の範囲内でこの課題に答えを出すことができ、広く使われていますが、経験的にはThompson Samplingの方が高性能であることも知られており、楽天ではThompson Sampling を活用しています。(参考 http://blog.marketing.rakuten.com/2014/04/tech-talk-testing-with-bandits

■ 深層学習

お待たせしました。いわゆるDeep Learning、深層学習です。

これまた「それ深層学習じゃないだろ」というところからスタートしますが、Googleが開発した2層のニューラルネットからなるWord2Vec はかなり革命的でした。文章を入力すると、出力としてベクトルのセット、つまり文章にある単語の特徴量ベクトル(feature vector)を得ます。それをグループ化したり、ベクトル合成することで、類似性を判定したり、意味の推論を行ったりすることができます。数値形式なのでパラレルにも処理できるスケーラビリティも大きな魅力です。Word2Vecの適用できる分野は文章の解析だけでなく、ありとあらゆるデータに及び、楽天ではEC向けに拡張したCategory2Vecを開発、OSSとして公開しています。(参考 https://github.com/rakuten-nlp/category2vec )ECの様々なデータを学習させて応用を探っていますが、レコメンド、商品やユーザーの解析や分類、また欠損情報の推定(これは詳しくは書けないのですが、ビジネスのコンテキストでは、素晴らしいといいますか、マーケットを破壊する恐ろしい可能性があります)等、広範囲に応用できる可能性が見えています。Word2Vecは、直接は深層学習ではないわけですが、Deep Neural Network でも使える数値形式であるというところから意識しておいた方がいい技術でしょう。

さて深層学習とは、人の脳の構造をソフトウェア的に仮置きしたニューラルネットワークという手法を多層化し、高度化を図ったものです。代表的なものとしては、CNN、RNN、発展版のLSTM等があります。ニューラルネットワーク自体は教師あり学習や教師なし学習のどちらにも使われますが、深層学習は多層化されたニューラルネットワークという特徴を活かし、具象から抽象まで幅広い概念を獲得する形でデータを学習します。様々なやり方が存在しており、(AutoEncorder等で)教師なしとしてプレトレーニングして過学習を防ぐ手立てをしながら、教師ありとしてファインチューニングする等のやり方もあれば、CNNでかつプレトレーニングは一切不要というようなアプローチもあります。

プレトレーニングという言葉を出しましたが、キーとなるのは、素性をどうするかという問題です。素性とは機械学習の入力に使う変数であり、学習したい対象の特徴を表す特徴量です。例えば、文字認識・画像認識では、広く用いられるSIFT特徴量(輝度変化の勾配方向)、SURF特徴量等もあわせて素性として入れると精度が高まることがわかっています。この場合、インプットとしての特徴量を事前にデータの前処理として作る必要がでてくるわけです。データを前処理して精度があがる手立てを仕込んでおくという広い意味で理解すると、これは機械学習以前に、様々なデータ活用の手法として長らく(50年以上)コンピューターの歴史の中で常識だったわけです

ですが、深層学習の一部はその多層構造の中で特徴量を自動的に獲得することを可能にしています。これにより、画像認識や物体認識分野での著しい精度向上を実現し、人の持つ複雑な脳の処理により迫ってきたとされています。

2012年でのILSVRC2012(大規模画像認識チャレンジ)におけるプレトレーニングなしでのCNNの圧勝という華々しいニュースによって広く注目されるようになった深層学習ですが、それもあって一般的に深層学習は画像認識分野での適用事例が多いわけです。楽天でも代表的アルゴリズムであるCNNやRNNをフランスのグループ会社 PriceMinisterのC2CアプリケーションであるQuickSell に実装。ユーザーが売りたい商品の画像を自動で認識し、その商品のジャンルを推定することでユーザーが売るための作業を大幅に軽減する機能を提供しています。(参考 http://rakuten.today/blog/image-recognition-making-e-commerce-easier.html ) また同様の技術を日本でも今年、C2Cアプリ「ラクマ」の「もしコレ!」機能としてリリースしています。(参考 http://corp.rakuten.co.jp/news/update/2016/0829_01.html )「もしコレ!」の画像識別精度は、個人的にも驚いていまして、充電ケーブルとイヤフォン、のような従来の手法では区別することが困難だったものも、適切に分類することができます。(参考 Rakuma Magazine https://goo.gl/RV51xI



また、同じく画像認識での適用例として、高速にじゃんけんの手を判別して絶対に負けないじゃんけんAI が搭載されたデジタルサイネージサービスというのを試作しました。写真がそれになります。これも、代表的なCNNをベースにしています。思ったよりも反響がすごく、テレビ東京の「トレンドたまご」に出演したり、TBSの池上彰さんの特番に出演したりしております。(参考 http://rakuten.today/blog/cassis-rakutens-unbeatable-rock-paper-scissors-ai.html

以上のように楽天内の事例としても画像への適用が多いのですが、詳しくは現段階では書けませんが、マーケティングでの活用も着々と進めています。今後はそちらのご報告もできればと思っております。

■ 研究者の皆様へのデータ提供

最後に、データについての話を。ビッグデータという潮流や、多様なロングテールの発展によって、データの増加・多様化が進んでいます。それがECにおけるAI 技術活用を後押ししているのも確かなのですが、それでもデータの種類が多すぎてしまい、一企業では所有データを到底活用しきれていないのが実情です。

データ活用には各種観点での分析やモデル構築を行うことが重要で、その為には広く知見を集める必要があると考えています。アカデミアで様々な大学や研究機関、学会から研究目的で提供されているデータセットや、または政府や地方自治体から公共サービスの拡充やビジネスでの利用も想定され公開されている公共データの様に、所謂オープンデータの概念は企業においても有用でありますね。もちろんユーザの個人情報やプライバシーに重々に配慮し、データの著作権・肖像権等の諸権利をクリアした公開可能なデータを、研究目的として大学や研究者に提供する。そうして広く研究者に自社のデータを活用してもらうことで、アカデミックへの貢献もさることながら、企業単独では持てないような着想に触れ、実施できないような分析手法を知り、その結果共有を受けることで更なるデータ活用、AI技術適用、その先のイノベーション創出を推し進めることができるようになります。

楽天は研究目的で研究者の皆様が利用できるように自社のデータを提供しています。(参考 http://www.nii.ac.jp/dsc/idr/rakuten/rakuten.html ) 特にビジネスに直接結びつくEC関連の商品データ(約1億5600万)・レビューデータ(約6千400万)を筆頭に、ホテル・旅館の施設データ・レビューデータ、ゴルフ場の施設データ・レビューデータ、料理レシピのデータ・画像データ、楽天Vikiのビデオ属性情報・ユーザ行動評価情報、等を提供しています。アノテーション付きデータも公開しており、筑波大学よりご提供いただいた楽天トラベルのレビューデータに対して,文単位で評価極性情報を付与したコーパス、画像に関しては画像認識の研究にも寄与できる、商品画像のカテゴリラベル付きアノテーションデータ、文字領域アノテーションデータも提供しております。

これら研究目的での公開データは既に70以上の大学・研究機関の研究室にて活用頂いておりまして、加えて去年は、楽天技術研究所シンガポールにて、世界中から研究者・データサイエンティストを集めて、データ解析コンテストを開催しており(参考 http://global.rakuten.com/corp/news/rnn/20151221_01.html )、今年はフランスで同様のコンペティションを開催しています。(イベントサイト https://challengedata.ens.fr/en/challenge/26/prediction_of_products_reviews_interests.html )今現在、私は日本データベース学会の理事を拝命し、産学連携のお手伝いをしているのですが、日本データベース学会と一緒に来年は、研究目的でのデータ提供を拡大していくことを睨みながら、データコンペティションを開催していくことを企画中です。

■ おわりに

長文になりました。読んでいただきまして大変ありがとうございます。書き始めたら、あれも書こうか、これも書こうかとなりまして、それでも詳しい方には、「何であれが書いてないんだ」というようなことになっているとは思いますが、ざっと、AIに連なる内容としての機械学習について、ECでの活用を中心に整理させていただきました。ありがとうございました。次機会がありましたら、楽天におけるAR/VR の歴史について書きたいと思います。あまりこれまた知られていませんが、楽天は様々なAR/VRアプリを開発しているのです。そんな多様でディープな楽天の技術のご愛顧を、今後もよろしくお願いいたします。






Last updated  2016/12/23 10:00:03 AM
コメント(0) | コメントを書く
2016/12/22
カテゴリ:Advent Calendar
この記事は Rakuten Advent Calendar 2016 の記事です。
こんにちは、アジャイルモンスターこと及部敬雄(@TAKAKING22)です。
現在は最近できたスタートアップの部署に所属しており、エンタープライズスタートアップの成功例をつくるべく、チームづくりからプロダクトマネジメントから越えられる壁はすべて越えるつもりで日々奮闘しております。
今日はカンバンについて取り上げてみます。
  • ペンと付箋があれば始められる
  • オンラインサービスも数多く存在する
  • アジャイル開発を取り入れているか否かに関わらずエッセンスを取り入れることが可能である
など導入のしやすさから、今ではメジャーなソフトウェア開発手法の1つになっています。実際に皆さんの現場でもカンバンを運用している、あるいはまわりで運用しているチームがいる方も多くいらっしゃるのではないでしょうか?
楽天でも、私がカンバンを始めた頃(2011年頃)は導入しているチームはほとんど存在しませんでしたが、今では壁不足・ホワイトボード不足が発生するくらいには多くのチームが自主的に導入をしています。
そんな簡単にはじめられるカンバンですが、「ToDo」「Doing」「Done」の付箋を移動するだけの死んだカンバンも多く存在する一方で、チームの基地(ベース)として常に改善されている生きたカンバンも存在します。せっかくやるなら後者を目指したいものですよね、ということでこれまでたくさんのカンバンの導入と運用を見てきた自分が考えるカンバンを有効活用するポイントについてまとめてみようと思います。

続きはこちら >>>






Last updated  2016/12/22 10:43:42 AM
コメント(1) | コメントを書く
2016/12/21
カテゴリ:Advent Calendar

こんにちは 。楽天技術研究所のumeda です。

普段は、機械学習・統計学を、実際のビジネスに応用する業務に従事しています。

今回は、その中の1例として、

Wuaki.tvでのコンテンツ人気予測について、紹介させていただきます。



1. Wuaki.tvとは??

ところで、Wuaki.tvって、みなさんご存知ですか?

Wuaki.tvは、スペインのバルセロナに本社を置く、動画配信サービス事業者です。

設立は2009年で、2012年に楽天が買収致しました

現在は、本社があるスペインの他にも、イギリス・ドイツ・フランス・オーストリア・

アイルランド等、欧州各地でサービスを展開しています。

# 残念ながら、日本ではサービス展開していません ><

 (http://rakuten.today/blog/what-next-entrepreneur.htmlより引用)

動画配信サービスには、大きく分けて、以下の2種類の形態があります。

  • TVOD: ユーザは、見たいコンテンツを、都度、購入。
  • SVOD: ユーザは、毎月一定額を支払い、好きなコンテンツを視聴。

Wuaki.tvは、TVOD・SVOD両方のサービスを展開していますが、

今回は、TVODでスペイン国内に配信されている映画のみに限定した話になります。




2. コンテンツ買付けでの問題点

Wuaki.tvは、コンテンツプロバイダ(例: Universal Studios, HBO,..)から放映権を購入する際、最初に、お金を支払う必要があります。

ここ、重要なので、もう一度繰り返します。


何人のユーザが、そのコンテンツを購入してくれるか分かりませんが、
Wuaki.tvは、そのコンテンツを配信する前に、
コンテンツプロバイダに、お金を支払う必要があります。



このような仕組みだと、例えば、以下のようなことも、起こりえます。

  • コンテンツプロバイダに、高い金額を、最初に支払った。
  • そのコンテンツをWuaki.tvで配信したら、購入ユーザ数が、極端に少なかった。
  • 結果、「コンテンツプロバイダに最初に支払った金額 >> ユーザからの収入」となってしまった。

このようなことを防ぐために、Wuaki.tv側からすれば、
以下のような事項を事前に把握しておきたい・・・という課題がありました。

  • 配信しようとしているコンテンツが、配信後、何人のユーザから購入されるか?
  • 最初にコンテンツプロバイダに支払う金額は、幾らぐらいが、適切か?

を事前に把握しておきたい・・・という課題がありました。

というわけで、
「配信前のコンテンツについて、配信後、購入ユーザ数がどれぐらいになるか、予測する」
ということに、チャレンジしてみました。


3. 予測方法

過去にWuaki.tvで配信されたコンテンツについては、属性データや、購入ユーザ数のデータが存在します。そこで、これらのデータを教師データにして、予測モデルの構築を行いました。
具体的には、以下のように、コンテンツの属性データから、購入ユーザ数を予測するモデルを構築します。ただし、購入ユーザ数を、ぴったり当てるのは難しいので、「購入ユーザ数を5つのレンジに分けて、各コンテンツが、どのレンジに該当するかを予測する」ことにします。


幾つかの入力変数について、少し解説します。
  • コンテンツプロバイダ、出演者、監督
一定数以上のコンテンツに関連しているコンテンツプロバイダ・出演者・監督のみを、入力変数として、加えています。
  • 初期の興行収入
映画の場合、インターネット上で配信可能になるのは、映画館で公開された後です。ですので、Wuaki.tvが配信したいコンテンツを選ぶ段階では、映画館での興行収入のデータが使えることになります。
  • 興行開始時期
映画館での興行開始時期を表しています。

モデルに関しては、今回は、ランダムフォレストというモデルを用いています。
木の深さ・木の数等のパラメータについては、クロスバリデーションで最適な値を選択しています。



4. 予測結果

モデル構築に利用したコンテンツとは別に、評価用のコンテンツを用意しておき、モデルの評価を行った結果が、下記の表になります。

Accuracyは、約81%です。つまり、約8割のコンテンツについては、将来の購入ユーザ数が正確に予測できたことになります。


ところで、予測によく効いていた変数は、何でしょうか?
ちょっと、考えてみてください。
(下のほうにスクロールいただくと、答えを確認いただくことができます。)










































以下が、予測に特に効いていた変数TOP3になります。
No.1は、興行開始時期です。
言われてみれば当たり前・・かもしれませんが、「新しいコンテンツほど、購入ユーザ数が多い」ということになります。

5. 現状と今後の課題

現在、この予測モデルは、Web tool化され、Wuaki.tvでのコンテンツ買付け時に、利用されています。さらに、今後の課題となるのは、以下2点です。
  • 予測モデルのAccuracy向上: まだまだ予測がはずれているコンテンツも、全体の約20%存在しています。これらについて、例えば、楽天グループ内にあるEコマースのデータ等を用いて、さらにAccuracyを向上させることができるかもしれません。
  • 予測モデルの他国・他社への拡張: 今回は、Wuaki.tvの中でも、特に、スペイン国内向けに配信されているコンテンツだけを対象としていました。しかし、Wuaki.tvは、スペイン以外の国でも、サービスを展開しています。また、楽天グループ内には、Viki, 楽天Show Time等、コンテンツ配信を行っている会社が複数あります。予測モデルをさらに拡張させて、複数の国や会社に対応させることで、より汎用性が高いモデルを作ることができるかもしれません。





最後に、ちょっと宣伝になりますが、楽天技術研究所では、Wuaki.tvでのコンテンツ人気予測のみならず、機械学習・統計学の実際のビジネスへの応用を進めています。
興味がある方は、是非、以下のページから、ご応募ください!
皆様からのご応募、お待ちしております!!






Last updated  2016/12/21 10:00:11 AM
コメント(0) | コメントを書く
2016/12/20
カテゴリ:Advent Calendar
楽天技術研究所でオリジナルのプログラミング言語Egisonを開発している江木です。

今日は、プログラミング言語を設計しているときに考えていることと、その結果として作ったプログラミング言語のオリジナルの構文について書いてみたいと思います。

既存のプログラミング言語では,我々の頭の中のイメージをそのまま表現できないことがあります.
 
このようなとき,我々は,頭の中のイメージを言語で表現するために,それを一度紐解いてプログラムとして記述せねばならず,結果できあがったプログラムは頭の中にあったイメージより煩雑になります.

このような不都合は,我々が頭の中で行っている抽象化を,プログラミング言語による表現では抽象化できないときに生じます.


我々が頭の中で行っているにも関わらず,プログラミング言語による表現ではできなかった抽象化が,新しい構文をプログラミングに導入することによってできるようになることがあります.

プログラミング言語を研究していると,このような新たな構文を発見できることがあります.

そのような発見は,プログラミング言語を研究する上での大きな楽しみのひとつです.


私は上記のような発見を目指してプログラミング言語の研究を楽天技術研究所で行っています.

同時に,今までに自身で発見した新しい構文を実装したオリジナルのプログラミング言語であるEgisonの開発も行っております.


本記事では,私が新しくプログラミング言語に導入した2つの構文を簡単に説明したいと思います.


1つ目はパターンマッチについての構文です.


パターンマッチはプログラミングにおいて重要な機能です。

パターンマッチにより、データの分解やデータの中身による分岐処理は、簡潔なマッチ式を1つで表現できます。


しかし、従来のパターンマッチには、特定のデータ型のデータしか直接的な記述で操作できないという問題がありました。

例えば、既存の言語のパターンマッチは、リストに対するパターンマッチはある程度得意ですが、要素の順序構造を無視する集合や多重集合に対するパターンマッチは難しいです。

そのため、簡潔に記述することができない冗長なデータ操作がまだあります。

Egisonは、この問題を解決するために作られたプログラミング言語です。

Egisonは、パターンの表現力を強力にしてかつ、プログラマが集合や多重集合を含む一般的なデータ型それぞれに対しパターンマッチの方法を記述できるようにすることにより、アルゴリズムのより直接的な表現を実現しました。


以下の例は、与えられたコレクションの要素のうち、2回以上現れる要素を列挙するプログラムを記述したものです。

パターンマッチを用いなければ、2重ループを記述する必要があるところを、簡潔なパターンマッチ1つにより記述できます。


2つ目は,テンソル解析を簡潔に記述するための構文です.

例えば,テンソル解析には,以下のような有名な数式があります.


これを,現在最も広く使われている数式処理システムであるWolfram言語(Mathematica)で記述すると以下のようになります.



これを,Egisonで記述すると以下のようになります.




この2つプログラムの間の本質的な違いは,Wolfram言語はTable式によるループ構造を数式の記述に用いるのに対し,Egisonは添字記法を用いることにより,数式を直接記述できているところにあります.

Wolfram言語による記述では,Table式とSum式による二重ループがプログラム中に現れてしまっているところを,アインシュタインの縮約記法という数学記法もサポートするEgisonによる記述では,数式と同様にフラットにこの式を記述できています.

テンソル解析は,応用の範囲がとても広い理論であり,それゆえに,テンソルの計算を簡潔に記述できると,多くの分野の専門的なプログラミングが簡潔になります.
例えば,ここ数年,流行しているディープラーニングについて,いくつもの独立したフレームワークがオープンソースとしてもリリースされていますが,それらのフレームワークの中には行列やテンソルをプログラマが簡単に操作するための機構を提供しているものもあります.

上記のような,我々の頭の中のイメージをより直接表現する新しい構文が,世の中に浸透させて,一般的なプログラミング言語にも導入されるようにすれば,現在のプログラミングの難しさ,プログラミングにかかる手間をもっと小さくできると期待して,研究を続けています.

Egisonについては,多くの情報をウェブサイトのほうにもまとめておりますので,ぜひ試してみてください.

Egisonの公式ウェブサイト






Last updated  2016/12/20 01:12:37 PM
コメント(2) | コメントを書く
2016/12/19
カテゴリ:Advent Calendar
この記事は、Rakuten Advent Calendar 2016 の19日目の記事です。


こんにちは、楽天トラベルでDevOpsを担当しているShinoです。

DevOpsと一口に言っても色々ありますが、端的に言うとオペレーション・ゼロを目指して、運用やCI/CD周りの自動化、プラットフォーム開発に励んでいます。


今日は、DevOps的なサムシングということで、アジャイルメトリクスについてお話ししたいと思います。

2日目のkawaguti氏の記事「(12月2日) DevOps とリーンスタートアップ時代のプロダクトオーナーシップ」にもありましたが、メトリクスの共有 は、重要なアジャイルプラクティスの1つだと言われています。

スクラムやリーンをやっているチームは何かしらの指標を持ってると思いますが、メトリクスはチームによって多種多様で、多くのセオリーやアンチパターンなどがあります。その中で、ウォーターロイス氏がこちらの記事で提言している、

  • 進捗のメトリクス
  • 品質のメトリクス

の2つについて私達の事例を紹介します。



品質のメトリクス

私達の部署の役割の一つとして、サーバ構築やOS、ミドルウェア設定などのオペレーションがあります。
Orchestartion ToolであるChefを使って設定のコード管理とオペレーションを行っていますが、これらが実際のサーバに正しく設定されているか、また果たして設定変更が期待通り反映されうるかを確認する必要があり、ソースコードの変更をウォッチして継続的にテストをしています。

所謂アプリケーションのUTやITとは異なりますが、私たちにとっては、コードの品質および実サーバの状態を確認する上で大切な指標です。

Chefのコードのテストのためにはテスト用のVMが必要になりますが、(一般的にも)これらは稼働数や時間に応じて課金されてしまうので、開発環境、ステージング環境では、仮想VM(仮想の仮想、、)としてDockerを使い、MinimalOSおよび中間のDisk imageから、Chefでプロビジョニングして、Serverspecで設定反映後のテストをするということをやっています。また、本番環境を含め実際稼働しているサーバの状態をチェックするために、同じServespecのテストケースを用いて、1日数回結果をレポートしています。 



各ホストごとのテスト用Jobと結果の一覧(ステージング環境の例)



はじめはエラーがありましたが徐々に改善
たまに外部要因でエラーが起きることもあります :P



結果を各環境まとめてHipChatにレポート


計測し始めた当時は同じクックブックのテストでも、このサーバでは通るけどこのサーバでは上手くいかないなど、もぐらたたきでした。割れ窓理論でなかなか修正が進まなかった現実も、、
現在は、本番環境では、約45万、DEV/STGではそれぞれおよそ10万件くらいのテストが走り、テストがこけてもすぐに気づいて対応できる体制になりました。



進捗のメトリクス

楽天グループでは、開発プロジェクトの進捗管理にAtlassian社のJIRAというツールを使っています。

このツールは非常に強力で、KANBANを用いてタスク管理をしたり、WEB上で承認ワークフローを回したり、バーンダウンチャートで進捗を確認したりと、アジャイル開発をする上で必要になる機能が詰まっています。ただ、個人的にはレポーティングは少し痒いところに手が届かなかったりするので、JIRA Restful APIやHTMLパースによって追加で情報を取得し加工しています。

メトリクスは少ない方がいいというセオリーは全くその通りだと思いますし、強いチームなら、デイリーハドル、KANBAN、バーンダウンチャートくらいがあれば事足りるでしょう。実際に下記に推奨されるメトリクスを用いていましたが、私達のチームではそれだけでは上手く行きませんでした。
https://ja.atlassian.com/agile/metrics


理想ラインに漸近するも交わらない

バーンダウンが落ちない。まさにウォーターフォールのごとく後半に急激に落ちる。似たようなことは別のチームにいた際もよく起きていましたがまたしても。。

これらはストーリーポイントやIssueの数をベースにした指標ですが、そもそもIssueをクローズできなかったり想定より時間がかかっていました。チケットの分割し、タスクを細分化していきましたが、そうすると数値を管理するのが難しくなります。

時間見積もりや評価は、時にアンチパターンとされることもありますが、何にどれくらい時間を使っているかをまず見える化し、改善する方が自分たちのスタイルにあっていると考え、いくつかメトリクスを追加、視覚化して改善を図ってきました。

そのベースになるのが、チケットごとにどれくらい時間を使ったかを記録するWorklogです。



こんな感じでキリのいいところでログります



スキマ時間もありますが、サマるとこんな感じで見られます


表形式だとどのIssueにどれだけ時間を使ってるかがよく分かる

細々とした物含め、全ての仕事に対して、ログをつけるのはストレスになることもありますが、ルールをきちんと決め習慣化することでストレスを軽減し、結果的にチケットドリブンになるという効果もありました。

上記は個人の例ですが、チームとしてサマるとこんな感じになります。



タスクの種類ごとにレポートを出して、ものによっては閾値を決めています。

最初はWeelyで評価していましたが、2週間のスプリントにおいて1週間単位ではちょっとフィードバックとしては遅すぎます。そこで、Dailyかつ個人ベースで取得するようにしました。


チーム全体の残見積もり時間(縦軸が時間、横軸が日付)


個人別のものはタスクごとにわかれています(縦軸が時間、横軸が日付)


(縦軸が使った時間、横軸が最初の見積もり時間、色は個人毎、円の大きさがストーリーポイント)


下のバブルチャートは、見積もり時間に対する実測値です。
直線より上に行っているタスクは危険な証拠なのですが、真ん中のオレンジのものは見積もり6Hに対し実測19Hと何か問題を抱えていそうです。

これらを細かく分析するのではなく、コミュニケーションのきっかけくらいの役割ですが、これにより早く問題に気づき、また上手くいっているところも分かりやすくなったので、タスクの再アサインや他のメンバーのサポートがしやすくなりました。それぞれの見積もりや進め方の癖みたいなのも筒抜けですw

まとめ

上記は、厳密にはロイス氏の言う進捗や品質とは違いますし、メトリクスというのはあくまで指標であり、成果ではありません。

これらを日毎、週毎、2週間のSprint毎に確認し、傾向を掴み対策を行っていますが、チームの成果としては、上記とは別にKGI(Key Goal Indicator)を定義して月毎に評価をしています。

当然サービス品質や可用性を担保した上で、実際にオペレーションの数が減っているか、サーバ構築のリードタイムが減っているか などがそれに当たります。

私達が各種メトリクスを採用する上で大切なことは、まず「チームの変化に気づけること」。良いことは褒めあい高め合う、悪いことはサポートしあい早く改善する。また、それらが、「チームに合っているか」。これは重要な原則の一つですが、チーム全員が納得できるか、また有効であるかどうかを常に議論し改善する必要があります。私たちも今のスタイルに落ち着くまで1年くらいかかりましたし、更に新しいものを追加しようと考えている自分もいますw

それと、このメトリクスは今使っているツールでは取れないから計測しない。ではなく、有用だと思う指標があれば、取得方法を考えて計測してみる。というのが大事ですね!視覚化ももちろん大事です。

再三同じことを言ってますが、メトリクスの使い方は十人十色だと思います。うちではこうだけど、そっちはそうなのかーと参考になれば幸いです。

長くなりましたが、メトリクスおじさんからは以上です。







Last updated  2016/12/19 09:13:05 AM
コメント(0) | コメントを書く
カテゴリ:Advent Calendar
Hello everyone! 楽天札幌支社のyokopyです
北海道札幌市に楽天の開発拠点があることはあまり知られておらず、札幌の勉強会などで自己紹介すると驚かれることが多いです。
今回は、そんな札幌支社で日々私が行なっている業務内容について紹介します。

業務の紹介

私が所属するグループの役割は、楽天内で開発されるWebサービスの運用です。

開発には様々なフェーズがあり、企画、仕様決定、開発、テスト、リリース、運用というサイクルが回っています。初期段階のサービスでは、開発~テストまでのサイクルが多く回りますが、サービスが成熟すると、運用フェーズの役割が大きくなります。
その頃になると、多くのユーザの皆様に利用されるサービスになっていますし、社内でもそのサービスの利用が当たり前になっているからです。
私たちのチームではその運用フェーズのサービスを中心に担当し、いかに少ない運用工数で安定的なサービスを数多く提供できるか、日々考え、運用しています。
楽天にはたくさんの開発チームがありますが、中でも私たちのチームが最も多くのサービスを担当しているチームだと思います。

SRE? DevOps? 今運用が注目されている!?

以前、母親に普段どんな仕事をしているか聞かれてことがあり、楽天のサービスの運用だよと答えると「運用ってなんだか地味ね」なんて言われたことがありました(苦笑
確かに、新規サービスの開発に比べると、既存サービスの運用や保守というのは地味に聞こえてしまいます。
しかし、ここ数年DevOpsやSREといったキーワードと共に運用についての注目が高くなっているように感じます。それはなぜでしょうか?
そこにはいくつかの理由があると思いますが、私個人としては、新規サービスを開発したエンジニアが運用まで一貫して行った場合、更なる機能の開発に掛ける時間が取れないこと、また運用自体に集中できない結果、バグ修正やオプティマイズがおろそかになってしまうと、サービスレベルが落ちてしまうからだと思っています。
スピーディーに機能を開発していくチーム、運用に専門家するチームが協働することで、サービスレベルも高いものになっていくのではないでしょうか。

運用が発生する例

この業界は、日々新しいベストプラクティスが共有され便利なツール、フレームワークが生まれていきます。
しかし、それを上回る勢いでWebサービスは多様化、複雑化し、求められるリリーススピードも短くなっています。
その結果、
  • ひとまず、リリースすることが第一目標
  • コードレビューも最低限バグ探し優先、適切にログを出しているかなどまで目が届かない
  • テストコードは書くけど、最初はアクセスも少なそうだし負荷試験は後回し
  • 管理画面はリリース後に頑張ります
なんてことを、経験する人も少なくないのではないでしょうか?
書いていて自分も耳が痛い話です。
開発したサービスが一旦世の中に出てしまうと、そこには責任がついて回ります。
  • リリース後に見つかったバグがあれば、最優先で修正するのはしょうがありません
  • しかし、管理画面がないせいで、ビジネスサイドから毎日のようにデータ登録依頼がきたり、経営層に報告するために、PVやUUの提出を求められたり、
  • ユーザサポートから登録したデータが登録されていないとクレームが来たのでログ調査をお願いされたり
  • 上司から急なイベントで高負荷が予想されるけど、どれくらいまで耐えられる?と質問されたり
「リリースするまでが忙しいと思って頑張ったのに、リリースした後の方が忙しいじゃねーか!?」
という状況になってしまいます。
このような状況では新機能の開発なんてできません。
そこで我々の出番です。

運用改善例

成熟し、開発が少なくなったサービスを積極的に私たちのチームに移管し、
我々は、標準化と自動化によって、開発担当チームが2日掛けて行っていた運用作業を

数時間に短縮し最終的には0にしていきます。

それによって、少ない人数でより多くのサービス運用を実現しています。
この結果、開発グループは煩わしい運用作業から開放され新規機能開発に集中できるようになります。

具体的な事例

ここまで技術的なTopicが少なかったので、具体的な事例を幾つか紹介します。
1. レガシーコードの刷新
  ruby1.8.7/rails 2.3テストコードなしのサービスを、ruby2.3/rails 4.2にver upしテストコードの整備を行う。
2.リリース改善
  手動リリースをDockerを使ったBlue Green 自動デプロイに改善
3. キャパシティ確認、障害時の挙動確認
  負荷試験を実施し、システムがどれくらいのアクセスまで耐えられるか確認。
  また、高負荷状態でDB,Cacheサーバがダウンしたらどうなるか確認。
4. 監視システム開発
  外部Cloudから、自サービスへ定期アクセスを行うことで、サーバダウンだけでなく、SLB/ネットワークダウンの検知も行う監視システムをELK スタックを使って開発。
5. 管理画面、ツールの整備、パフォーマンス改善
  管理画面やツールの整備を行うことで、エンジニアの作業を減らす。
  DBのインデックス追加などのチューニングだけで、4時間掛かっていたデータ抽出を3分に短縮。

最後にリクルーティング

北海道札幌市にいながら日本有数のトラフィックを誇る楽天のサービスに直に触れる機会があり、レガシーコードのver upやDockerを使ったデプロイ改善、様々な自動化などエンジニアのキャリア的にも恵まれた環境だと思います。
現在は、Rubyのサービスが多いですが、PHPのサービス、JSゴリゴリのサービスもあります。
早く帰れる日は、仕事帰りにみんなでボードに行ったり、休日に集まって登山に行くなんていうアクティブなこともしています。(釣りスピリッツ大会も開催しています)
みなさんからのご応募をお待ちしております
また、勉強会も行う予定ですので、そちらもお楽しみに!






Last updated  2016/12/19 09:09:19 AM
コメント(0) | コメントを書く
2016/12/17
カテゴリ:Advent Calendar

この記事は、Rakuten Advent Calendar 2016の17日目の記事です。



楽天のR&D部門である楽天技術研究所でヒューマン=コンピューター・インタラクション関連の研究をしているmecabです。あだ名に英語のようなそれっぽいスペルを充てたら偶然かぶってしまっただけで、形態素解析ツールとは関係ありません。年末の大掃除として、ターミナルとシェルの環境を整えました。以下の通り、そこそこ実用的かつ、カラフルで楽しい感じになりました。



「とりあえずemoji入れとけば良いと思うなよ💢💢💢」と怒られそうですが、プロンプトのホスト名の色つけだけはちょっと真面目に設定したので、これについて書きます。



続きを読む...







Last updated  2016/12/17 12:01:47 AM
コメント(0) | コメントを書く
2016/12/16
カテゴリ:Advent Calendar
こんにちは。
EngineerのReinaです。
(最近、Product Ownerはじめました)


新卒で入社して7年目。
Engineer歴も7年目。
今年は、2つのプロダクトの0からの立ち上げを行っております。
1つは、Engineer Leader(エンジニアメンバーのリーダー)として。
2つ目は、Product Ownerな役割も。



0からのプロダクトの立ち上げというRakuten内でも貴重な経験をしているので、
今回は、今年を振り返りながら、Rakutenでの0からのプロダクト開発について紹介します。



まずは、今年前半のエンジニアリーダーとしてのプロダクト立ち上げ。



開発プロセスの改善を進めているチームではじまったプロダクト立ち上げProject。
もともと問題を抱えていたチームだったが、

- Morning Stand Up MTG
- Kanban
- KPT


を継続的に行い、改善しはじめた時期でのProjectだった。
もともと"agileってなにそれ?!"なチームが、
このProjectで、Scrumに挑戦し、
ローンチまで進めることができた。


その開発チームの改善プロセスの詳細はこちらに
↓↓↓↓↓↓



今回のProjectで開発チームの改善に大きな手応えを得ることができ、
わたしとしても、自信につなげることができた。
2つ目の立ち上げについて。
前のプロダクトのローンチから1ヶ月も立たずに異動の命を受け、
別な0からのプロダクト立ち上げProjectへ。
しかも、チーム作りも0からスタート。


事業を司る事業部メンバー、UXチームメンバー、開発メンバーあわせて6人で、
"はじめまして"から始まったこのProject。


前回の立ち上げProjectにおいて、
開発チームのチーム改善に手応えを得られたが、
事業部、デザイナーチームと、
チーム間に越えられない壁を感じ、
壁を壊せなかったことが心に残っていたわたしは、
各チームの垣根を越えたProject実施を決意。


6人でLean Canvas作りからスタートし、
カスタマージャーニーマップ、
要件定義、
仕様策定、
とProjectが進むにつれ、
人数も増え、
ぎこちなかったProjectメンバーもチームの垣根を越えて、いつしか一致団結に。


StoryのPriority決めも、
事業部、UXチーム、開発チームメンバーが集まり、




それぞれの知見を持ち寄り、
Projectとしての方向性をメンバーで合意。





あらぬところに壁あり、横槍ありと、
一筋縄ではいかないプロダクト立ち上げですが、
2つ目のプロダクトは、もう少しでローンチになるので、
とても楽しみな今日このごろ。


来年は、いまのチームで、改善を重ねて、
プロダクトをどんどん成長させていくぞ!


それぞれのProject、それぞれのチームメンバー、それぞれのプロダクトにおいて、
自分がベストと思う仕事を自ら行う。
自分の裁量で動けて、自ら動かないと進まない。
こんなRakuten wayのプロダクトの作り方を思う存分味わった一年でした。


そんな残りわずかな今年も、そして来年も
がんばるぞ!!






Last updated  2016/12/16 09:15:49 AM
コメント(0) | コメントを書く
2016/12/15
カテゴリ:Advent Calendar
皆さんこんにちは。12月15日を担当させていただきますTaichiです。
楽天トラベルサービスを開発している部門の、Front End Developmentグループという部署に所属しています。

…というと、Javascriptなどを使ってバリバリ「フロントエンド」を開発していそうなのですが、フロントに関わる仕事はせいぜい2-3割程度。
肩書に偽り有りです。

実は、私の主務は、フロントエンドエンジニアの皆さんがフロントをバリバリ開発できるよう、「フロントエンドとサーバサイドのビジネスロジックの分離」を進めること。
本日はこれについて紹介させてください。


分割の始まり


楽天トラベルでこのような動きが始まったのは、2010年頃だったと記憶しています。

現在の楽天トラベルは、1996年、「ホテルの窓口」というサービスとして始まりました。
2010年当時、創業当時のプログラムがそのまま稼働している… ということは流石になかったものの、急成長を遂げながらツギハギで作られてきたシステムは複雑に絡み合い、重複コードも多く、「ちょっとした修正が全然関係なさそうなところに影響を及ぼす」ようなトラブルが頻繁に起こっていたような状況でした。
このような状況を打開するために、「同じ処理はAPIとして一箇所にまとめる」「フロントとロジックは分離して疎結合にする」という、大きなシステム再構築が始まりました。

初めにターゲットになったのはホテルの予約やキャンセル関連の処理。
こちらで実績ができた後、楽天トラベルに参画してくださっているホテルや旅館の方が使う、「施設管理画面」がリファクタリングの対象となり、私自身も当時、メンバーの一人としてこの案件に参加しました。


絵に描いたようなスパゲッティ


この施設管理画面。
使われているプログラミング言語からして古かったり、コピペで作られたようなプログラムが多かったり… と、当時は「ちょっとした修正が全然関係なさそうなところに…」の代表格のような存在でした。

しかし、機能ごとに再構築された後は、新機能開発にあたっての影響調査が大変楽になったことを覚えています。

また、今年2016年に、長年使われてきたUIが刷新され、とっても見やすく・使いやすくなった「新管理画面」がリリースされました。
こういったことが可能だったのは、まさに、フロントエンドとサーバサイドが適切に分離されていた結果だと思います。


「楽パック」の挑戦


さて、私が現在担当しているのは、楽パックというサービスです。
航空券や宿泊などの商品を自由に組み合わせて予約することができるので、飛行機を利用したご旅行の際は是非!
…という便利なサービスなのですが、反面、システムの面から見ると、多数の外部・内部のAPIの呼び出しや複雑な料金計算ロジックが実装されており、「なかなか手が出せない」「レガシーなモノリス」として、我々エンジニアの前に長年そびえ立ってきました。

このシステムに対し、「より速く」「より安全に」改善のサイクルを回せるようにするため、適切なサイズに解体し、再構築することが現在の私のミッションです。

今は、検索機能のAPI化を進めているのですが、

「そもそも検索って何?」「パッケージ商品の検索って何?」
を再検討するところから始まり、

「検索」といいつつ
「商品を組み合わせる」ロジックや「デフォルトの商品を暗黙的に選ぶ」ロジックが必要であることに気づいたり

はたまた
現在の作りが非常にステートフルで、ユーザビリティもメンテナビリティもよろしくないので
いっそこのタイミングで、ステートレスに作り変えよう!
と挑戦してみたり

…と、次から次へと課題が出てきて、飽きない日々を送っております。


元が複雑なだけにチャレンジが多いのですが、この案件が完了した暁には、これまでの倍どころかそれ以上の開発速度が出ると信じて、日々頑張っております!






Last updated  2016/12/15 08:32:13 AM
コメント(0) | コメントを書く

全47件 (47件中 1-10件目)

1 2 3 4 5 >

PR

Calendar

Category

Powered By 楽天ブログは国内最大級の無料ブログサービスです。楽天・Infoseekと連動した豊富なコンテンツや簡単アフィリエイト機能、フォトアルバムも使えます。デザインも豊富・簡単カスタマイズが可能!

Copyright (c) 1997-2017 Rakuten, Inc. All Rights Reserved.