この記事は 「CCoEクリスマス！クラウド技術を活用して組織をカイゼンした事例を投稿しよう！ by KINTOテクノロジーズ Advent Calendar 2023」 の７日目の記事になります
Github Projectsとは
GitHub ProjectsはGitHubのIssue管理やPull Requestなどとも透過的に管理ができるカンバン形式でのタスク管理をすることができます。
GitHub Projectsには２つのバージョンが有り、以前のバージョンのclassic と 最新のバージョンのProjectV2があります。
新しいProjectsは大幅に刷新されていて、多機能でありながら非常に使いやすくなっています。
ただ、プロジェクト管理としては互換性はないため、これから使う場合にはV2を使う方が良いでしょう。
グラフを作ったりして分析も出来るようになっていて、簡単なプロジェクト管理ツール顔負けの機能が無料で使えちゃいます。凄い！
ProjectのBoardページから、このアイコンをクリックするとInsightsのページに遷移して、グラフを色々作れます。
グラフ作れるんですが、画面の遷移の流れとか、画面の作り的には、なんとなくオプション的な立ち位置の雰囲気を感じさせます。。でも、無料で出来るだけで凄いです！
雰囲気で触ってみるだけで簡単にグラフができちゃうので、興味がある人は触ってみるといいと思います！
GitHub APIとは
ProjectV2のデータはGithub APIのv4にしか用意されていません。
RestAPIとGraphQLがありますが、このv4はGraphQLでアクセスする必要があります。
詳しく知りたい方はGitHub公式の説明ページを参照ください
なぜこんなに充実した機能があるのにわざわざRedashに？
GitHub Projectsは更にパワーアップして充実した機能を持っています。
なぜRedashを使おうとしたのかというと、以下のポイントがありました。
- ラベル設計でGitHub Projectsで集計できない観点がある
- メンバーが自由に集計と管理がしたい
- 利用費用を抑えたかった & 素早く始めたかった (GitHubとRedashは既存で使っていた)
1. ラベル設計でGitHub Projectsで集計できない観点がある
ラベルは自由につけることが出来るので、ラベルを使いながら集計はかなりのことが簡単にできるのですが、あと一歩届きません。
ざっくりした概要が見たいだけでなく、課題を深く掘り下げるためにラベルと集計の設計をして運用を検討していました。
Redashを使うことにした理由はこの原因が一番大きいです。
どんなラベルかというと
- ラベルに親子関係があるデータ
- ラベルにMECEの関係があるデータ
- ラベルに除外データが含まれるデータ
- ラベル集計データを時系列の差分を組み合わせたデータ
親子関係のラベルの関係は、大カテゴリ、中カテゴリ、小カテゴリのような関係です。
たとえば、大カテゴリで「運用」タスクのラベルをissueに付けていたとして、運用の中で「バグ」、「リファクタリング」、「(問い合わせ)調査」、などのラベルが存在した時に、「運用」ラベルを含めて横並びに集計しても意味がありません。「運用」ラベルのレベルで集計したいときと、運用の中にフォーカスしてバグ、リファクタリング、調査の比率を知りたいときは違います。
MECEのラベルの関係は分析の切り口を決めて、領域の区切ってフォーカスした時に、漏れなく集計するラベルです
大カテゴリでは、計画されたタスクと差し込みのタスク などはMECEの関係です。それ以外にも、上記の親子ラベルと同じようにカテゴリ内でのMECEなラベル設計がある場合があります。
除外データが含まれるデータの取り扱いは、定義しきれていないラベル設計のデータです
集計観点ではMECEにラベルを設計したいのですが、どうしても扱いを定義できていないラベルや親子カテゴリが明確でないラベルデータが出てきます。これらを集計に含めると、本来見たい数値が精緻に見えなくなるため、データ除外しながら集計する機能が必要でした
時系列データを組み合わせると、複雑な集計が必要なケースがあります
時系列データを積み上げで集計するだけであれば手軽に表示できるのですが、集計した結果の差分の参照や上記のパターンでのラベル集計データとの組み合わせとなると、複雑な集計が必要になり、基本機能では集計できない観点がありました。
2. メンバーが自由に集計と管理がしたい
この機能はあると便利程度ですが、クエリを個々人で作りたいというものです。
気になる観点を自分で集計して見れる & 管理出来るということで、気軽にデータに触れて理解を深めてもらえると考えました。
作られているクエリが全て一覧になってしまうと、数が多くて理解が複雑になります。
どれがチームで管理しているクエリで、どれが個人で見たかっただけのクエリか分かりません。
また、Redashではダッシュボードをつくることでチームで見るべき指標を１ページに集約できることも非常に大きいことだと思います。
3. 利用費用を抑えたかった & 素早く始めたかった (GitHubとRedashは既存で使っていた)
複雑なデータ管理、様々なレポートを考えるとJIRAの導入も検討していました。
JIRAは非常に多機能であり、個人的に活用したい計画変更を見える化するエピックバーンダウンの機能にも興味がありました。
しかし、有料のツールを導入することは費用増につながるため、健闘の時間が掛かる承認決済のフローを通す必要があります。
今すぐ課題の原因を探る必要がある中で、何ヶ月も時間を取る余裕やボトルネックをチーム外に出すことにリスクを感じました。
これらの課題があったため
チーム状況を一刻も早く見える化したい！
これらの課題を乗り越えるため、自分でやってしまえばいいじゃない！というエンジニア精神で、仕組みを作ってみました。
実際のデータの流れ
- スナップショットのGitHub Projectのカード状態を取得してDBに保存する。
- バッチを作成し、Lambdaに登録。1日1回、定期的に実行。
- GitHub APIを使って、GraphQLでデータを取得。
- 取得したデータをRedashから参照できるDBのテーブルに登録。
- 更新されたデータをRedashのダッシュボードで、状況を見れるグラフを追加。
- 全体サマリグラフ
- 通常スプリント管理グラフ
- 課題フォーカスグラフ
- など
人は時系列でのデータを比較して目に見えると、改善したい気持ちが生まれやすいと思います。
まずは見える化が非常に大事だと考えています。
そのため、情報にラベルを付けるなどの設計をすると良いと思います！
Redashで分析してよかったこと
データ構造を自由にできるのはもちろんですが、グラフも含めてかなり自由に集計して追加出来ることができるため、非常に良かったです。
あとから確認したい観点が出てきても、ラベル設計だけすれば、どんな形式にも集計出来ました。SQL最高です！
GitHub Projects標準の集計グラフでは表現できない集計をしたグラフももちろん非常に役に立ちました。
参考イメージ
ちょっと辛かったこと
内部ツールなのでで手抜きして実装している部分があり冪等性を考えずに実装したため、複数回実行するとデータが２重に登録されてしまうのはちょっとキツかったです。
また、エラーがあるとこの冪等性の問題で単純な再実行が出来ず、復旧に気を使うところがありました。
また、スナップショットデータを取得しているため、データを取り逃すと取得日のデータの欠損が起こってしまうので、なるべく早く対応する必要がありました。
とはいえ、そんなに複雑な処理ではなく、あくまで内部の参考データのため、それほど大きく困った場面はありませんでした。
まとめ
プロジェクト分析には課題に合わせたデータ収集が必要なことはもちろんですが、課題を深掘りできるような観点での集計や見える化が重要になります。グラフにして手軽にいつでも見れるようにすることで、チームでプロジェクトの課題感を共有し、自然発生的な改善活動を起こせることもあります。
少し手間は掛かるかもしれませんが、自分でプロジェクト見える化に手を付けてみては如何でしょうか？
少しでも開発チームの改善活動の参考になればと思います！