チーム開発での Github 貢献度を可視化する


Loading...

はじめに

KADOKAWA Connected KCS 部の nokamoto です。 KCS 部では KADOKAWA グループ向けプライベートクラウドを提供しており、プライベートクラウド上の各サービス開発は Github Enterprise を利用しています。 今回はチーム開発において Github 上での貢献度を可視化し、チーム開発を加速するための取り組みについて投稿します。

背景

チームとして開発を加速するには、下記の 2 つが必要です。

  1. 自身がサービスの開発に貢献する。
  2. チームメンバーがサービスの開発に貢献する。

この 2 つを定量的に測定して改善していくためには、前者は自身が発揮しているパフォーマンスを集計する必要があります。 また、後者はチームメンバーなどへのメンタリングによって、メンタリングを受けたメンバーのサービスに対する習熟や、メンタリングを通じた教育・知識の伝達の効果を集計する必要があります。

定量的な効果として Github 上での貢献度を可視化することで、チームのパフォーマンス変化を理解しやすいものにしたいと考えました。

Github 貢献度

私が所属するチームではプルリクエストを行い、他のメンバーからのコメントを集め反映し、レビュアーから Approve を受けた後にマージする、といった一連の流れで開発が行われています。

この開発の流れから三つの項目について考えます。

  1. プルリクエストを出した数
  2. プルリクエストにコメントした数
  3. プルリクエストを Approve した数

プルリクエストを出した数は、サービスの開発に対する直接的な貢献の指標の一つとして考えます。 機能追加やリファクタリングなど、リポジトリに対して誰がどのくらいの数の変更を送ったのかを可視化します。 私のチームではプルリクエストの粒度は小さくする1ことを基本方針としているため、プルリクエストを細かく分けることでプルリクエスト数のカウントが増えることも意に沿うものとなっています。

ただし、プルリクエスト数はコードのコミットに対する貢献の全てを測るものではないことに注意が必要です。 プルリクエストを細かくして数が増えることが基本方針だったとしても、プルリクエスト数だけを貢献と考えると成果のためだけに過度にプルリクエストを分ける状況も可能性としては考えられます。 そのため、コードのコミットに対しては Github が提供するコード変更行数など別の指標を示すことも別途行なっています。

プルリクエストにコメントした数は、サービスの開発に対する間接的な貢献の指標の一つとして考えられます。 コードレビューはコードやサービスの品質を担保したり、新しく入ったチームメンバーへのメンタリングの場として利用される開発において重要な要素の一つです。 積極的な質問や提案など、リポジトリに対して誰がどのくらいの数のコメントを送ったのかを可視化します。

プルリクエストを Approve した数も、間接的な貢献の指標の一つとして考えられます。 プルリクエストで提案された内容をリポジトリに入れても良いと自信を持って判断するためには、関連する技術への理解やサービスに対する知識が要求されることが多いです。 また、コードレビューでは素早さも重要です2。 プルリクエストは最終的には Approve を受けて完了する必要があるため、Approve を行い開発を次に進めることにも価値があります。

可視化

Github から必要な情報を取得するために作成したアプリケーション例は以下のリポジトリにあります。

nokamoto/print-github-contrib

このアプリケーションでは Github Organization を指定して以下の処理を行なっています。

  1. リポジトリを取得します。
  2. リポジトリに対して期間内に作成されたプルリクエストの一覧を取得します。
  3. プルリクエストに対してレビュー3とコメント4の一覧を取得します。
  4. 得られたデータから CSV 形式で三つの項目を出力します。

例えばあるリポジトリに対して以下の CSV 出力が得られた時に、

$ print-github-contrib print ORG --repositories REPO --start 2019-04-01 --end 2020-07-01 --enterprise-url https://***/api/v3 --sleep 1s
created_at,owner,repository,pull_request,approve,comment,Naofumi-Okamoto.pull_request,Naofumi-Okamoto.approve,Naofumi-Okamoto.comment,A.pull_request,A.approve,A.comment,B.pull_request,B.approve,B.comment,C.pull_request,C.approve,C.comment,D.pull_request,D.approve,D.comment,E.pull_request,E.approve,E.comment,F.pull_request,F.approve,F.comment
2019-06,ORG,REPO,60,33,93,46,14,66,,,,,,,0,1,2,0,2,3,14,16,22,,,
2019-07,ORG,REPO,103,131,585,65,28,306,,,,,,,7,15,63,17,63,138,14,25,78,,,
2019-08,ORG,REPO,122,101,509,73,33,241,,,,,,,15,9,79,16,47,118,18,12,71,,,
2019-09,ORG,REPO,58,52,248,36,17,113,,,,,,,4,0,22,1,22,40,17,13,73,,,
2019-10,ORG,REPO,15,17,49,10,4,20,,,,,,,1,2,5,2,8,11,2,3,13,,,
2019-11,ORG,REPO,16,12,77,10,4,27,,,,,,,0,4,13,0,1,10,6,3,27,,,
2019-12,ORG,REPO,16,16,86,7,0,15,,,,,,,2,4,31,0,9,4,7,3,36,,,
2020-01,ORG,REPO,27,28,182,9,2,38,,,,,,,3,12,30,4,12,35,11,2,79,,,
2020-02,ORG,REPO,51,47,270,8,13,69,11,7,47,0,2,0,14,7,61,6,9,41,7,9,43,5,0,9
2020-03,ORG,REPO,25,24,165,1,9,23,14,4,66,,,,2,6,29,1,0,17,5,5,27,2,0,3
2020-04,ORG,REPO,25,21,199,0,3,11,17,1,64,,,,2,7,57,3,8,59,0,2,1,3,0,7
2020-05,ORG,REPO,11,11,69,1,0,4,0,1,7,,,,1,4,12,4,3,18,2,3,15,3,0,13
2020-06,ORG,REPO,23,21,212,0,0,26,0,0,1,,,,6,11,66,3,6,68,4,4,19,10,0,32

以下のようなグラフを Google スプレッドシートを利用して作成できます。

f:id:kdx_writer:20200707135504p:plain

f:id:kdx_writer:20200707135433p:plain

f:id:kdx_writer:20200707135527p:plain

利用例

利用例. 「自身がサービスの開発に貢献する」指標を示す

2019 年 6 月から 12 月までは新規開発をキックオフして進めている時期でした。 この時期に私が立てた目標は新規サービス開発に貢献するというものです。

f:id:kdx_writer:20200722133057p:plain

f:id:kdx_writer:20200722133425p:plain

それを定量的に示すために、リポジトリに対するプルリクエスト数と Approve 数を可視化しました。 一ヶ月の 50 % 程度の開発にコミットし、25 % 程度5はチームメンバーへのレビューを行ったというような貢献度が可視化されました。

利用例. 「チームメンバーがサービスの開発に貢献する」指標を示す

2019 年 9 月前後からはチームメンバーの教育という目標を立てた時期でした。 この時期は、私は設計を中心に行うアーキテクトロールとしてサービス開発に参加していたにも関わらず、開発を行うエンジニアロールとしてのコーディングに関与しすぎているという課題がありました。 サービスを開発する上ではエンジニアロールのチームメンバーが開発を主導でき、アーキテクトロールはコーディング以外の設計にも十分に時間を割くことが出来る状態が望ましいです。

この課題に対して、新しく入ったチームメンバー ( E さん ) にメンターとして教育を行い、私が行なっていたエンジニアロールのタスクのオフロードを進めること目標としました。 具体的には、「サービスや技術への理解が不足していることからレビューにあまり自信を持って参加できていない」というフィードバックを受けて、ペアでレビューを実施することで疑問点を解消しレビューへの貢献を増やす、という目標を設定しました。

f:id:kdx_writer:20200722134125p:plain

それを定量的に示すためにコメント数を提示できます。 ペアレビューの取り組みを行った 9 月前後から徐々にレビューのコメントで質問や提案が増えていることを視覚的に確認できました。

f:id:kdx_writer:20200722135017p:plain

その後の推移としてもチームメンバーの増加やチーム編成の変化を経て、アーキテクトが過度にやりすぎない状態が維持されています。

制約

今回行ったアプリケーションの実装は Github API の レート制限 の影響を受けます。 Github Enterprise では制限が緩いのに対して Github の制限は厳しいため、Github に対して実施する場合は認証による制限の緩和やエラーハンドリングなどの実装を適切に行う必要があります。

まとめ

今回の投稿では Github 上でのチーム開発で貢献度を可視化する方法を説明しました。

チーム開発のパフォーマンスに対して定量的な指標を導入することで、自身の状況をより正確に把握することに役立てられます。 またチーム開発への貢献度が可視化されることで、チームに新しくジョインしたメンバーが開発者として成果を出し、チームに貢献できるようになるまでサポートする道筋を作ることもできます。可視化されることで、ペアレビューやペアプロによる効果を実感でき、それが自信に変わり、モチベーションとなる良い流れが生まれました。

さて、最後に私が所属している KCS 部では以下のようなエンジニアを募集しています。

今回ご紹介したような Github 上でのチーム開発やプライベートクラウドの開発に興味がある方はぜひご応募ください。


  1. https://google.github.io/eng-practices/review/developer/small-cls.html

  2. https://google.github.io/eng-practices/review/reviewer/speed.html

  3. reviews

  4. review commentsissue comments の合計

  5. 基本的に自身のプルリクエストは Approve しないため、プルリクエストの割合が増えると Approve の割合は減ります。