クローラーに込めた「エンドユーザーファースト」の思い

2019-12-20｜LAPRASの機能紹介

LAPRAS のプロダクトマネジメントをしています。鈴木です。
今回は、LAPRASの開発秘話として、GitHub クローラーのお話をさせていただきたいと思います。

LAPRAS の GitHub クローラーが新しくなりました。

先日、LAPRAS では GitHub の Organization に紐づくリポジトリがクロールされるようになりました。これにより、 オープンソースプロジェクトへの貢献が正しくポートフォリオやスコアに反映されるようになりました 。「何もしていないのにLAPRAS のスコアが伸びた」と驚かれている方もいらっしゃると思いますが、これまで考慮できていなかったアウトプットが正しく反映された結果ですので、ご理解いただけますと幸いです。

今回のLAPRAS NOTEでは、 LAPRAS の GitHub クローラーについて、

  • なぜこれまで Organization のリポジトリをクロールできていなかったのか
  • それがどうしてできるようになったのか

の話を通じて、LAPRAS がプロダクト開発において大事にしていることをお話させていただければと思います。

これまでの GitHub クローラー

LAPRAS のクローラーチームでは、公開Web上に散らばった個人のアウトプットを集め、ポートフォリオなど利用可能な形にしていくことで、個人のアウトプットの価値が本人に還元される世界を目指して日々開発を進めています。普段からオープンソースプロジェクトに貢献されているエンジニアの方にとって、GitHub でのアウトプット活動は大きな意味を持つものです。

しかし、GitHub は非常に大きなサービスであり、ユーザー数は3100万人、リポジトリは1億件以上 (2018年時点)となっており、その全てをクローリングにより収集することは、GitHub に多大な負荷を掛ける事になってしまうため、実質的に不可能です。

そこで、優先して取得するリポジトリを決めて、一部のみをクロールする必要があります。これまでは、LAPRAS では、次の2つの方法でクロールするリポジトリを探索していました。

  • LAPRAS のデータベースに存在するユーザーが保有しているリポジトリ
  • コントリビューター数でランキング上位にある大規模プロジェクト ( Rails や numpy など)

この方法を用いていた主な理由は、GitHub のREST API の仕様によるものでした。GitHub の REST API では、ユーザーが保有するリポジトリの一覧は取得することが出来ますが、ユーザーがコントリビュートしたリポジトリの一覧を取得することはできません。したがって、個人がコントリビュートしたリポジトリを探すためには、他のユーザーが保有するリポジトリやランキングに載っているリポジトリを辿って探索するしかありませんでした。

しかしながら、ユーザーの貢献という視点からすると、規模はそこまで大きくはなくとも、ユーザー1人1人の貢献が大きい中堅プロジェクトが大きな位置を占めているということがわかりました。このようなリポジトリの多くはユーザーではなくOrganization が保有しており、またプロジェクトの規模もランキングに載るほど大きいものではないため、上記2つの取得方法では、リーチすることができませんでした。

実際、Twitter やユーザーアンケートなどで、Organization に紐づくリポジトリに対応してほしいという意見を多数いただいていました。

GraphQL によるソリューション

このような状況を打開できないか、クローラーチームに調査プロジェクトをお願いしたところ、 GitHub のGraphQL API を使うことで、ユーザーが所有しているリポジトリだけでなく、コントリビュートしているリポジトリの一覧も取得することができることがわかりました。このAPI を使うことで、リポジトリの所有者やプロジェクトの規模に関わらず、ユーザーがコントリビュートしたかという切り口でリポジトリを探索することができることがわかりました。

しかしながら、これまで REST API を前提に設計していたクローラーをGraphQL にも対応させるのは、それなりにコストがかかる開発になります。新規のクロール先サイトを増やす開発など、様々な開発タスクを抱えるクローラーチームにとって、この GitHub クローラーの改修を「いつ実装するか」が次の問題となりました。

エンドユーザーファースト

LAPRAS では、「世の中のミスマッチをなくす」というミッションを達成するためのアクションアジェンダとして、エンドユーザーファースト という理念を掲げています。
これは、自社の短期的な利益とエンドユーザーの利益が相反したとき、常にエンドユーザーの利益を優先して考えるということです。

この四半期、クローラーチームでは、「新規クロール先サイト数」を KPI に開発を進めてきました。既存の GitHub クローラーの改修はこの KPI に直接貢献しませんから、もし仮にKPIの数字を愚直に追いかけるのであれば、今回のGitHubクローラーの改修の優先度は下がってしまったことでしょう。

しかしながら、クローラーチームでは、チームのKPIよりも上位の「エンドユーザーファースト」の理念に従い 、ユーザーに最も価値を提供できる方法をフラットに考えた結果、新規サイトのクローラー開発よりもGitHub クローラーの改修を優先することにしました。

KPI や OKR など、目標とする数字を設定することはチームの方向性を揃える上で重要ですが、これらの数字が常により上位の目的に合致しているかをチェックし、ずれてきたら KPI や OKR の設定を修正していくことはさらに重要であるということを実感しました。

さて、このようにしてGitHub クローラーの改修が先日リリースされ、LAPRAS ユーザーの皆さんのポートフォリオに順次反映することができました。大変光栄なことに、Twitter では早くも気づいてくださった方も居られ、喜びの声もいただきました。

LAPRASが大切にしていること

今回ご紹介したクローラーチームの動きもそうですが、LAPRAS プロダクトチームでは、最もエンドユーザーのためになることは何かを常に考え、日々サービス開発を進めています。これは、「世の中のミスマッチをなくす」というLAPRAS のミッションを達成するためには、エンドユーザーの皆さんが利益を享受できることが必須だからです。

LAPRAS は現在、企業向けサービス LAPRAS SCOUT の利用料をいただくことで売上を立てていますが、単に売上のためだけに、企業のみの利益になる機能ばかりを実装してエンドユーザーを蔑ろにしていては、私たちの目指す世界に近づくことはできません。
目先の利益のためではなく、エンドユーザーのためのサービスでなければ、LAPRASの目指す未来は実現できない。このような考えから、私たちは「エンドユーザーファースト」の理念を大切にしています。

この考え方は全社で徹底されており、これは開発の優先順位のみならず、プロダクトの仕様にも反映されています。例えば、LAPRAS SCOUT を利用して送信される全てのスカウトメールには クオリティ・ガイドライン を設け、利用企業に守っていただいています(基準に満たないメールはLAPRASが差し戻しています)。これにより、質の低いバラマキメールがエンドユーザーに送信されることがないようにしています。その他の例については、また機会があればご紹介させていただければと思います。

これからも、LAPRAS はエンドユーザーファーストの理念に従ってサービス改善を行っていきますので、今後の展開にぜひご期待ください！

あなたのスコアを見てみませんか？

LAPRASは、Web上のアウトプットから個人のスキルや志向性を可視化したポートフォリオを自動生成しています。
GitHub、Qiita、Twitterのアカウントがあれば本人認証後すぐにポートフォリオを確認できます。

LAPRASへのログインはこちらから。

こちらの記事も読まれています