土曜の朝、カレッジフットボールをひたすら見るだけの何にもしない一日を楽しもうとカウチに座り込むと、やると約束してから2週も先送りにしていた落ち葉の片付けがあると妻に言われた。善良な地域住民でありたいし、HOA に違反したくなかった (HOA: 住宅街の家主向けの住宅管理規約。自宅の芝刈りを怠るなど違反すると罰金を徴収される)。テキサスロングホーンの試合もなかったので、熊手を持って外へ出た。

たくさんの落ち葉があった。庭の100%が落ち葉に覆われていたと思う。落ち葉を熊手でかき集めながら、そこそこの労力で、落ち葉の90%を5つの山にまとめることができた。そして、落ち葉の山をゴミ袋に入れた。

庭はずっと見栄えがよくなったが、まだたくさんの葉が落ちている。熊手もある。袋もある。すでに外にいるし、汚れてもいる。庭全体にもう一度熊手をかけて、残りの10%の落ち葉も片付けることにした。最初の90%のときと同じくらい時間がかかったが、同じ達成感は得られなかった。落ち葉の山はさっきほど大きくなかったのに、その山の90%程度の落ち葉を袋に入れられただけだった。これで落ち葉の99％は片付けることができた。

まだ充分日は高く、もう少しきれいに出来ると思ったので、残りの1%の落ち葉も取ることにした。これを読んでいる皆さんがご存じかどうかわからないが、葉っぱが一枚だけの方がすべりやすく、つかみづらい。熊手でかき集められるくらいの量がないときは、2回も3回も、あるいは4回も同じ場所に熊手をかけて、葉っぱを集めることになる。庭に3回も熊手をかけるのはより時間がかかる作業だが、残り1%の落ち葉の90%を片付けることができた。つまり、庭の落ち葉の99.9%は片付けられたことになる。

庭に座り、ほぼ落ち葉がなくなった様を見てうっとりしていると、熊手で取り切れなかった葉や、木から落ちてきたばかりの葉が目に入った。数は多くはないが、そこにあった。良い仕事をしたくて、私は庭で四つんばいになり、落ち葉を1枚ずつ拾い始めた。ご想像どおり、この作業は退屈で、庭全体を見て回るには長い時間が必要だったが、残りの0.1％の90%は片付けることができた。この時点で、99.99%の落ち葉を片付けられていた。

日が沈み始め、もはや落ちているのは、ピンセットでしか拾えないような葉っぱのかけらだけだった。

家の中に入り、妻に「ピンセットはどこかな ?」と聞くと「フェンスのペンキ塗りに、どうしてピンセットがいるの ?」と聞かれた。「フェンスのペンキ?」と私は思った。そうだ、今日はフェンスのペンキ塗りもすると約束していたのだった。フェンスにはまだ何も手を付けられていないし、明日はカウボーイズの試合だからこの週末には出来ない、と私は妻に伝えた。妻は不満そうだった。

わざとらしく聞こえるかもしれませんが、この話には、Indeed がシステムの信頼性と新機能のベロシティの管理に取り入れているポイントがよく表れているのです。

私はどこで間違えたのか?

私が間違いをおかしたのは、ピンセットを持ってくることを考えた時点よりもずっと前でした。落ち葉拾いを始める際に、きれいに掃除された庭の定義を曖昧なままにしてしまっていたのです。どれくらいのパーセンテージなら、庭に落ち葉が残っていてもクライアントが掃除された庭とみなしてくれるのかを具体的に示すサービスレベル目標 (SLO) を決めていませんでした。

SLO を定義しておくべきだったのか?

SLO を前もって定義しておくことはできたでしょうが、自分が達成できる数値に基づいて決めていたかも知れません。私は、ピンセットでしか拾えないような葉っぱのかけらまで拾い、99.999%の落ち葉を片付けることができました。テキサスロングホーンの試合がある週末だったら、90％の落ち葉を拾えればよしとしていたかもしれません。

SLO は、SLO を気にしているクライアントに決めてもらうべき

先ほどの私の話では、クライアントは HOA と妻になります。予定より長い時間をかけても、庭の落ち葉の50%しか片付けられていない場合、HOA から通知が来ます。妻は、年に一度、落ち葉の99%を片付けてくれれば満足だと言っています。SLO としては、この2つの基準のより高い方が選ばれるでしょう。私は99%の落ち葉を拾えた2ラウンド目で落ち葉拾いをやめ、フェンスのペンキ塗りをする時間を確保できていたでしょう (ペンキを何層塗るかという SLO 次第ですが)。

でも、良い仕事をしましたよね?

確かに良い仕事はしましたが、定義しなかった99%という SLO を0.99ポイント上回ったにも関わらず、報われませんでした。妻は、やり過ぎた1%分をほめてくれるどころか、もう1つの頼みごとであったフェンスのペンキ塗りの時間がなくなってしまったことに腹を立ててしまったのです。

この話から、次のような教訓を得ました。

適切な SLO を定め、それを越える努力をすべきだが、やり過ぎるべきではない

SLO を「ユーザーのニーズ」だと定義した場合、Indeed では、それを上回るための努力は避けるようにしています。そして、節約した労力を、より多くの機能を迅速にデプロイ し、信頼性とベロシティのバランスを維持することにあてています。

---

投稿者の紹介

Andrew Ford は、Indeed の site reliability engineer (SRE) で、データベースの信頼性と拡張性などの問題に楽しんで取り組んでいます。カレッジフットボールのシーズンが始まり、東海岸の全試合が終わる9月から12月の間の土曜日は、ほとんどカウチにいます。

クライアントのニーズにあった SLO の定義に興味がある皆さん、Indeed の SRE の採用情報をご覧ください。

オープンソースは、Indeed の中核を成すものです。オープンソースコミュニティとの連携のおかげで、仕事探しのお手伝いをするためのソリューションを開発できています。

オープンソースコミュニティの一員として、コミュニティに貢献することが大切だと Indeed では考えており、オープンソースのエコシステムにとって意味のある貢献ができるよう努めています。

Indeed では、次の団体や組織とのスポンサー契約を更新し、支援を継続することになりました。

 

Apache ソフトウェア財団 (ASF) は、Indeed のゴールドスポンサーとしての支援の継続に感謝しています。

また、ASF インフラストラクチャチームに Indeed.com での求人掲載や広告などを活用する機会をご提供いただくなど、ご支援の幅を広げていただきました。このご支援のおかげで人員を増やすことができ、Apache のインフラストラクチャサービスを24時間、365日に近い稼働状況で提供できるようになりました。

Indeed の取り組みは、Apache コミュニティを広く支援していただけるものであり、感謝しております。

— Apache ソフトウェア財団、VP Fundraising、Daniel Ruggeri 氏

---

 

Cloud Native Computing Foundation (CNCF) のメンバーとして Indeed を迎えることができ、非常にわくわくしております。成長を続けるエンドユーザーのコミュニティにとっても、大きなプラスとなりました。活気あるこのエコシステムへの Indeed の参加で、業界全体へのクラウドネイティブコンピューティングの導入が本格化していくでしょう。Indeed と一緒に、コミュニティの育成に取り組んでいけることを楽しみにしております。

— Cloud Native Computing Foundation、Executive Director、Dan Kohn 氏

---

 

Indeed のオープンソースコミュニティでの積極的な取り組みは、オープンソースソフトウェア (OSS) が今やビジネスにとってだけでなく、開発者にとっても根底をなすものであることを表しています。

多くの企業がそうであるように、Indeed は OSS のユーザーであり、コントリビュータでもあります。Indeed が行った履歴書に関する調査によると、開発者も同様で、仕事を探すときは OSS のスキルや経験をアピールし、テック業界で人気のある求人への就職に成功しているそうです。

— OSI、General Manager、Patrick Masson 氏

---

 

Indeed がスポンサー支援を継続してくださるのをとても嬉しく思います。こうした支援のおかげで、制度上のバイアス、少数派であること、そして差別などの影響を受けている人々にも重要な機会を与え、自由度の高いオープンソースソフトウェアを知ってもらうことができるようになりました。

— Software Freedom Conservancy、Executive Director、Karen Sandler 氏

---

 

Indeed は、プログラミング言語である Python の開発とグローバルコミュニティの育成という私たちのミッションを Python ソフトウェア財団 (PSF) のスポンサー支援活動を通して支援してくれています。

Indeed のような支援は、IT 業界への参画人数が少ない、特定の人種や特性を持つ層に機会を提供し、オープンソースや Python コミュニティへの支援を表明できるプログラムに資金を提供できます。

— Python ソフトウェア財団、Betsy Waliszewski 氏

 

Indeed の取り組み

Indeed のオープンソースイニシアティブには、オープンソースプロジェクトを支援するためのパートナーシップやスポンサーシップ、メンバーシップが含まれています。社内でもオープンソースプロジェクトの推進に努めており、従業員全員の参加を促しています。オープンソースコミュニティを支援するために、Indeed では2019年に FOSS Contributor Fund を設立しました。社内の誰もが、基金の対象となるオープンソースプロジェクトを毎月推薦することができます。

Indeed は、オープンソースに力を注いでいます。Indeed の取り組みの詳細については、こちらをご覧ください。

Click here for the original English quotes.

Indeed は、求職者の仕事探しのお手伝いをする方法を探しながら成長し、さまざまな形で求職者に求人情報を提供してきました。Indeed.com での求人検索、おすすめの求人情報の送信、求人の有料掲載やターゲット広告、スカウトなどはその一例です。それぞれ求人の提供方法は少しずつ異なりますが、「求職者に最適な求人情報を届ける」という同じゴールを目指しています。

求職者の希望に沿わない求人を表示すれば、Indeed を利用してもいい仕事は見つからないと思われて、信頼を失うかもしれません。Indeed のミッションは「We help people get jobs (人々の仕事探しのお手伝い)」であり、時間を浪費させることではありません。

Indeed では、次のような求人は求職者が求めている求人ではないと考えています。

• 給与の額が希望より低い
• 求職者が持っていない資格を必要とする
• 希望する勤務地ではない
• 希望する分野と関連性はあるがミスマッチである (看護師と医師に同じ求人がオファーされる、など)

こうした問題を減らすため、求職者にとって明らかにミスマッチな仕事を除外するジョブフィルターを作成しました。Indeed では、ヒューリスティックルールと機械学習の技術を組み合わせたソリューションを使用しており、分析結果からこの手法は非常に効果的であることが分かっています。

システム構成

上の図からもお分りいただけると思いますが、ジョブフィルターは次のコンポーネントで構成されています。

1. ジョブフィルターサービス: ユーザーを ID で特定し、ユーザーごとに求人のマッチ度を評価する、高スループット、ローレイテンシーのサービスです。このサービスは、求人がユーザーIDに対して適切だと判断すれば ALLOW を、不適切だと判断すれば VETO を返します。水平スケーラビリティの高いサービスであるため、Indeed の多くのリアルタイムアプリケーションで使用されています。
2. ジョブプロフィール: 高スループット、ローレイテンシーのパフォーマンスを提供するデータストレージサービスです。給与の予測、職種、勤務地など、求人の属性を読み出します。Indeed NLP ライブラリと機械学習技術を使用して、ユーザー属性の抽出や集約を行うことができます。
3. ユーザープロフィール: ジョブプロフィールと似ていますが、求人ではなく求職者の属性を提示します。ジョブプロフィールと同様、高スループット、ローレイテンシーのパフォーマンスを実現するデータストレージサービスです。希望する給与、現在の職種、希望する勤務地など、求職者の属性を読み出します。ジョブプロフィールと同様、Indeed NLP ライブラリと機械学習技術を使用し、ユーザー属性の抽出や集約を行うことができます。
4. オフライン評価プラットフォーム: 履歴データを利用し、上流工程のアプリケーションと統合させずに、ルールの有効性を評価します。既存のルールの調整や新しいルールの特定、新しいモデルの検証にも多用されています。
5. オフラインモデルトレーニング: Indeed のオフライントレーニングアルゴリズムを構成するコンポーネントです。評価時の、ジョブフィルターのルールで使用できるモデルのトレーニングに使用します。

求人のマッチングを改善するフィルタールール

ジョブフィルターは、ルールを使用して求職者に表示される求人の質を改善しています。ルールは非常にシンプルです。「専門的な資格が必要な求人は資格を持っていない求職者に表示しない」や「大幅な減給となるような求人は表示しない」などがその一例です。一方、「求職者が興味を持たないと確信できる職種の求人は表示しない」、「複雑な予測モデルが、この求職者は興味を持たないだろうと示唆した求人は表示しない」など、複雑なルールもあります。

ルールはすべて、意思決定エンジンライブラリに蓄積されます。Indeed ではこのライブラリを、オンラインサービスとオフライン評価プラットフォームで共有しています。

ジョブフィルターのルール構築の基礎となるデータの収集は複雑かもしれませんが、大半のヒューリスティックルールの設計や実装方法はシンプルです。たとえば、ユーザーの反応予測モデルを使用して、求職者が興味を持ちそうにない仕事を除外するというルールがあります。Indeed 独自の評価指標では、求職者と表示される求人のマッチングの質を測定し、パフォーマンスを評価しています。

広告ランキングとリコメンダシステムは、通常、クリック予測やコンバージョン予測といったユーザーの反応予測モデルを基にスコアを生成し、スコアが低いものを除外するための閾値を設定します。モデルでユーザーのポジティブな反応を予測し、低いスコアでマッチングの質の低さが分かるので、求人を絞り込むことができます。

Indeed のジョブフィルターにもこのような技術を採用していましたが、機械学習に基づくルールを作成したときは、ネガティブキーワードモデルを使用しました。ユーザーからのネガティブな反応を予測するモデルを構築し、Tensorflow を使用して、ワイド＆ディープモデルを構築します。これらのモデルは、Factorization Machines やニューラルネットワークといったより複雑なモデルの今後の実験に役立ちます。Indeed で使用している機能は、主なユーザー属性や求人データを網羅しています。

パフォーマンスの良いモデルをトレーニングしてから、Tensorflow SimpleSave API を使用してエクスポートします。エクスポートしたモデルをオンラインシステムに読み込み、Tensorflow Java API を使用してリクエストに対応します。AUC、Precision、Recall といった従来の分類指標に加え、Indeed のモデルもオフライン評価プラットフォームに読み込んでパフォーマンスを評価します。

ジョブフィルターの適用例

Indeed では、ジョブフィルターを複数のアプリケーションに適用しています。その一つが Job2Job で、求職者がクリックした求人や応募した求人に基づいて、関連性の高い求人を推薦するアプリケーションです。Job2Job のサービスを使用することで、求人のマッチング率を20%以上向上させることができました。このサービスを他のアプリケーションに適用したときも、上回るとまではいかなくても同程度の改善が見られました。

ルールベースのエンジンは、滅多に発生しないケースを解決するのに役立ちますが、ルールの数が多くなりすぎると手に負えなくなってしまいます。ルールの階層構造の作成方法や機械学習技術により、こうした課題を効率よく解決し、システムの可用性を維持できています。今後は、より効果的なモデルとなるよう、さらに多くの機能を追加していこうと思っています。