データサイエンティストのプロジェクトにおける潜在的課題を発見する仕組み

こんにちは！Wantedly の Visit の推薦基盤チームでインターンをしている山村です。インターンとしてデータサイエンティストの生産性を向上するための課題を取り組みました。

今回はそれに関して書いていきます。

背景・課題

現在所属している Matching Squard では Github の Issue でプロジェクトの情報を管理していて、

データサイエンティストが、ある推薦アルゴリズムを改良してからユーザの元へリリースすること（以下、これをプロジェクトと呼びます）を行っています。プロジェクトの開始には、大本となる Issue を作成し、その Issue の子 Issue としてプロジェクトの各工程（事前分析、課題定義、実装方針、モデリング、オフライン評価、オンライン評価、リリース etc）の Issue を作成していきます。

ただ、現在のプロジェクトの運用方法では機械的に処理できる形ではないため、データサイエンティストが自身のプロジェクトの詳細を分析・調査するのが困難だという課題があります。具体的には、以下のような課題があります。

プロジェクトが終了してから見返す際に、プロジェクトの各工程にどれくらいの時間がかかっているのか詳細がわからないため、データサイエンティストがプロジェクトを進める上で潜在的な課題（ボトルネック）を洗い出せない
プロジェクトによってラベルの命名が異なるため、過去のプロジェクトの Issue を参考にする（大本 Issue だけを集める etc）のが困難

アプローチ

課題解決のためのアプローチとして、Issue ドリブンに BigQuery にボトルネックを発見する上で必要となるデータを保存して解析が行えるようにしました。また、Issue ドリブンで行う際に Issue に命名規則のあるラベルを付けることでプロジェクトによってラベルの命名が異なる課題を解決しました。

Issueのリレーション

Wantedly の Matching Squard ではプロジェクト開始時に Github の Issue で大本となるプロジェクト Issue を作成してから、その子 Issue を作成して、プロジェクトの各工程などを管理しています。親子というのは何かしらの参照関係でリンクされています。

但し、Wantedly の Matching Squard で発生する Issue の参照パターンとしては、以下のようなパターンがあります。

単純参照
1. ミーティング Issue などから Issue が参照されるパターン
2. 同一プロジェクトの別 Issue を参照する・されるパターン（兄弟関係）
3. 別プロジェクトの Issue を参照する・されるパターン
親子参照
1. 親→子：ある Issue からその詳細となる Issue を作成した時に、元となる Issue から詳細となる Issue を参照するパターン
2. 子→親：ある Issue からその詳細となる Issue を作成した時に、詳細となる Issue から元となる Issue を参照するパターン

過去のプロジェクトを分析すると、上記のようなパターンがあり、単純参照の Issue なのか親子参照の Issue なのかを分離するのが困難でした。また、プロジェクト毎に親子関係の参照の向きが異なるので、Issue の参照関係から親子関係を取得し、親子関係を保存する方針はボツとなりました。。。。

実装

実装概要

Wantedly の Matching Squard では Github の Issue でプロジェクトの情報を管理していて、本来の Github のラベルを付けるや、IssueやPRを開閉するなどの使い方が、データ収集に向いているので、今回はプロジェクトの大本となる Issue が閉じられたのをトリガーとして、必要なデータを Github Graphql API から取得して、BigQuery に保存します。BigQuery を使用する主な理由としては、Wantedly の Matching Squard では、分析するには BigQuery を用いることが多いからです。

使用手順

project-ranking-01 のようなプロジェクトの開始が決定
wantedly/visit リポジトリ（データサイエンティストのプロジェクト以外にも様々な Issue が作成されるリポジトリ）に大本となるプロジェクト Issue を作成
1. 大本となるプロジェクト Issue の識別方法として、大本となるプロジェクト Issue に root ラベルを付ける。
2. プロジェクトの識別方法として、関連するリポジトリに project 文字が含まれるラベルを作成する。今回の場合であれば、wantedly/visit リポジトリと wantedly/project-ranking-01 リポジトリに project ranking 01 ラベルを作成する。また、従来通り大本 Issue から派生する子 Issue は wantedly/project-ranking-01 リポジトリに作成する。その後、作成した大本となるプロジェクト Issue や関連する Issue や PR には作成したラベルを付ける。
3. 工程（事前分析、課題定義、実装方針、モデリング、オフライン評価、オンライン評価、リリース）識別方法としては、Issue や PR を作成する時に、次のいずれかのラベルを付ける。pre-analysis step 、　problem definition step、implementation policy step、modeling step、offline evaluation step、online evaluation step、release step
プロジェクトが終了するタイミングで大本となるプロジェクトIssueをクローズ

wantedly/visit リポジトリ Issue一覧

wantedly/project-ranking-01リポジトリ Issue一覧

処理手順

Github Actions で大本の Issue がクローズされたのなら、Github Actions の Event から大本 Issue に付けられているプロジェクトラベルを取得し、Github Graphql API から同様のラベルが付けられている Issue を全て取得する。
BigQuery に project_label、step_label、repository、number、type、is_project_issue、title、created_at、closed_at、url、author を保存する。
GithubActionsでガントチャート風に可視化したものをストレージ系サービスに保存し、大本となるプロジェクト Issue のコメントに記述する（本来であればDataStudioのガントチャートプラグインを使用したかったが、プラグイン側のエラーが出ているため断念。。。。Pythonで可視化）。

問題点

ある程度大きいプロジェクトの場合、大本となるプロジェクト Issue から、いくつかの大本となるプロジェクト Issue と同様の役割を持つサブプロジェクト Issue が作成される場合（右図）があります。

この場合上記のアプローチだと、ガントチャートなどで可視化すると図のようにサブプロジェクトの存在などは自明であるが、BigQueryなどのテーブルデータだけで分析する際に、同じプロジェクトラベルが付けられていて、工程ラベルも同じものが付けられている場合、工程の開始と終了から工程の時間を取ると、長時間各工程を行っていると扱われてしまう問題があります（下図で言えば、 pre-analysis step が1月中頃から2月中頃まで行われたとされる）。