検索
連載

「データサイエンス部隊が内製で切磋琢磨」から方針転換――機械学習/AIプロジェクトが守るべき4つの骨子リクルートジョブズ事例に見るAIプロジェクトの勘所(1)

リクルートジョブズが機械学習/AIをサービスに活用するプロジェクトで得た知見を紹介する連載。初回は、リクルートジョブズでデータサイエンス部隊が立ち上がった頃に起こった問題について。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

 本連載「リクルートジョブズ事例に見るAIプロジェクトの勘所」では、リクルートジョブズが機械学習/AIをサービスに活用するプロジェクトで得た知見を、主にエンジニアリングとデータサイエンスの両方に関わる業務を担当している方に向けてお伝えします。機械学習/AIを導入した結果分かった、組織の在り方などを参考にしていただければと思います。

そもそも、リクルートジョブズとは

 リクルートジョブズは、『タウンワーク』『フロム・エーナビ』『はたらいく』『とらばーゆ』『リクナビ派遣』といった求人メディアと、『ジョブオプ』『ジョブオプLite』『シフオプ』といった、仕事に関わる業務支援サービスを運営しています。

 リクルートジョブズにおける「データ活用」プロジェクトは、「Apache Hadoop」が日本でも活用事例が散見され始めた頃に、組織を立ち上げました。データサイエンティストを採用し、「データサイエンティストを中心とした組織」となってから本格的にデータ活用を実施するようになりました。

 幸い、フリーペーパー配送の最適化や、広告出稿の自動化など幾つかの取り組みで成果を上げることができました。この結果、求人メディア事業のコアである「検索」に対しても、データサイエンスを活用した取り組みの検討を開始することになったのです。

データサイエンス部隊が内製で切磋琢磨(せっさたくま)することを選択

 あらためて言うまでもないかもしれませんが、「検索技術はデータサイエンスの塊」といっても過言ではありません。検索技術を活用した例として分かりやすいところでは「レコメンド」(情報推薦)があります。ユーザーが入力した検索クエリに該当するアイテムは何なのか、それをどの順番で出すのが適切なのか、といったところで検索結果を表出することにデータサイエンスはふんだんに用いられています。

 われわれデータサイエンス部隊が検索技術について検討する以前は、サイト開発組織つまりエンジニアリング部隊が中心となって、前述のメディアの検索部分を構築したり、磨き込んだりしている状況でした。

 ここでわれわれデータサイエンス部隊は既存のエンジニアリング部隊との協業ではなく、内製で切磋琢磨することを選択しました。

 事業のコア技術については、内製でデータサイエンス関連を開発できるようにし、ナレッジを蓄積して継続的に改善できる状態を作ることが狙いとしてありました。

 前述の通り、レコメンドはデータサイエンスにおける「花形」といえるもので、立ち上げて数年のデータサイエンス部隊としては非常にチャレンジングな取り組みです。若い組織であることもあり、非常に高いモチベーションで取り組み、開発スキルも日々向上していきました。

立ちはだかる高い品質目標

 分かっていたことではありますが、検索に対してデータサイエンスを活用しようとすると、開発しなければいけないパーツが多岐にわたります。

 ユーザーの行動や検索クエリを受け取り、行動などに基づいた検索ロジックを回し、その結果を、安定したレスポンスタイムで返す必要があります。これにはアルゴリズムを作成するだけではなく、データベースやデータパイプラインを構築したり、データを加工したり、APIを作り込んだりする必要がありました。

 例えば『タウンワーク』では、90万件以上という数の原稿を、企業から掲載いただいています。これらの原稿に対して、仕事探しをしている多数のユーザーにメディアを訪問いただいています。このため、非常に多くの検索トラフィックを処理し、早く、適切な検索結果をユーザーに届ける必要があり、当然ながら、その品質目標は高いものに設定しています。

 前述の通り、メンバーは高いモチベーションを持って、この品質目標をクリアできるプロダクトを製造したり、テストしたりするなどの経験を重ねていき、その過程でエンジニアリングスキルが向上していきました。それも一つの成果ではありましたが、リリースのたびに品質目標もクリアせねばならず、元来エンジニアリングに長けた組織に比べれば実力値は低いため、結果として1回のリリースまでにかかる時間が長期化。開発のイテレーションがなかなか回っていかなくなります。

方針の転換――機械学習/AIプロジェクトが守るべき4つの骨子

 こうした状況の中、方針を転換しました。

 データサイエンティストとして本来取り組むべきアルゴリズムの開発、改善、研究に極力注力できることを狙いとしています。以下4つを骨子としました。

  • APIなどのアルゴリズム以外のパーツは協働する
  • フェイルセーフ機構を設ける
  • データサイエンス部隊のプロダクトは「フィジビリティスタディー」(研究)を目的と定義する
  • 研究で良い結果が得られた場合は、再製造して品質を高める

 まず、従来ソートを担当していたエンジニアリング部隊と協働することを基本としました。APIなど、よりエンジニアリング力が求められる部分はデータサイエンス部隊では担当しません。

 また、原則的にはエラーが起こるなどした場合にも、従来のアルゴリズムに切り替わる、いわゆるフェイルセーフ機構を設けました。これにより、「サイトを利用するユーザーに対して機能を提供できない」事態が起こらないことを保証しています。

 加えて、データサイエンス部隊が作るプロダクトは「研究」を主たる目的とすることにしました。研究で良い結果が得られた場合には、エンジニアリング部隊で高い品質のものに再構築することとしています。実験を繰り返す中で製造されたプロダクトは効率や保守性が高いものにはなっていないものです。また、本番環境としてのプロダクトにはドキュメンテーションなども必要となってきます。

 再製造するプロセスを後工程に構えることで、実験のイテレーションを高速化できると考えました。

次回は、データサイエンティスト組織とエンジニア組織の関係性

 こうした方針転換の結果、データサイエンティスト組織はアルゴリズムに集中できるようになり、イテレーションを回せる状況を作ることができました。

 一方で、協業が前提となった場合に、他組織との「考え方の違い」に苦しむことになります。これについては、次回お伝えします。

筆者紹介

木田茂穂

大学卒業後、電機メーカー系のシステム開発会社に入社。

その後リクルートに転職、分社化に伴いリクルートジョブズに転籍。

クライアント向けシステムに関連する複数のプロジェクトを経て、2012年からHadoop担当となったことを契機にデータサイエンスの領域に入る。2013年からデータ活用チームのリーダー。

以降、フリーペーパー配送最適化、原稿内容チェック、Indeed入札自動化など複数のプロジェクトにマネジャーとして携わる。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る