20260116_開発者にスポットライトを当てる：GitHub 貢献ダッシュボードを作った話

GitHub のパブリック活動を可視化するダッシュボードを作ってみたら、そこには「楽しいランキング」と「監視ツール」の境界がありました。
本資料では、見えづらい開発者の貢献に光を当てるという狙い、個人メトリクスを扱ううえでの注意点とガイドライン、そして .NET 8 / GitHub GraphQL API による実装の裏側を紹介します。可視化を“評価”ではなく“リスペクトと対話のきっかけ”にするための考え方を共有します。

■アジェンダ
- Introduction
- 背景
- 作ったものの紹介＆かんたんデモ
- そのとき頭をよぎった違和感：「これ、監視ツールにならないか？」
- 自分なりに決めた”線の引き方”とガイドライン
- 実装の裏側ハイライト
- まとめ＆メッセージ

Transcript

1. 開発者にスポットライトを当てる GitHub 貢献ダッシュボードを作った話 2026.1.16 Yutaka.Osada
2. Agenda • Introduction • 背景 • 作ったものの紹介＆かんたんデモ • そのとき頭をよぎった違和感：「これ、監視ツールにならない か？」 • 自分なりに決めた”線の引き方”とガイドライン • 実装の裏側ハイライト • まとめ＆メッセージ DO WHAT MATTERS 2
3. Yutaka Osada（長田 豊） • Manager (DevOps Engineering) @Avanade Japan • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise ）の導入・構築 • Azure PaaS × GitHub Enterpriseのオファリング開発 • 個人活動 • Zennでの記事投稿（IaC、CI/CD Pipelines Azure DevOps Rest API等） • 登壇（各種ユーザコミュニティ、および、DevOps Days Tokyo 2025） • 書籍執筆(AZ-400の試験対策本) • GitHub Stars (Sep 2025–) 受賞 • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me https://github.com/yutaka-art 3 DO WHAT MATTERS
4. 背景：なぜダッシュボードを作ったのか？ DO WHAT MATTERS 4 社内イベント / LT での自己紹介 • 「◯◯案件のバックエンドです」 • 「☓☓チームでインフラ担当です」 ◼ モチベーション • 同じ組織のメンバーが「外の世界」でどんな活動をしているのか知りたい • 普段スポットライトが当たりづらい人にも光を当てたい ◼ このダッシュボードで目指したこと • 人事評価ではなく、「話のネタ」「リスペクトのきっかけ」にする 見えていない活動（パブリック GitHub） • OSSコミット • いろんなRepoへの PR/PRレビュー みんなが知っている ”案件ベースの顔” ほとんど共有されていない “GitHub上の顔”
5. 作ったものの紹介＆かんたんデモ 5 ◼ 何ができるダッシュボードか？ • OrgメンバーのパブリックなGitHub活動 を集計 • Commits/PRs/Reviews/Total • ランキング表示（上位 人) • Table/Chartの切り替え • Top 5/10/20…と表示件数を変更可能 ◼ 特徴 • Org配下リポジトリに限らず、パブリッ ク活動全体が対象 • 「Total」だけではなく、レビュー貢献 （Pull Request Reviews）も重視 ◼ 利用シーンのイメージ • 社内LT/技術コミュニティで「このひと、 こんなにやってます」紹介 • 1on1や雑談の場での話のきっかけ パブリックリポジトリ：https://github.com/yutaka-art/github-contribution-rankings
6. そのとき頭をよぎった違和感：「これ監視ツールにならないか？」 DO WHAT MATTERS 6 楽しいランキング • 「おお、Aさんめっちゃ活動してる！」 • 「Cさん、レビュー多いんだね」…ワイワイ見る。 監視ツール化のリスク • 下位の人や数字が少ない人がどう感じるか？ • 調整／設計／ドキュメントなどは完全に見えない • 「コミット数が多い人が偉い」空気を助長する Manager 「この人、コミット数少ないですね」 「最近数字落ちてません？」 → ランキング＝“序列表”として扱われる DevOps / SRE 視点 • DevOps / SRE で重視されるのは… • チームのフロー（Lead time, Deployment Frequency） • アウトカム（信頼性、ビジネス価値） • 今回のダッシュボードは、 • →かなり「個人メトリクス寄り」の可視化 • →だからこそ「使い方」を間違えると危ない
7. 自分なりに決めた”線の引き方”とガイドライン 7 このダッシュボードのルール 個人メトリクスと付き合う３つの問い 正式な評価には使わない 人事評価・査定・表彰の根拠にしない 使いどころは「会話のきっかけ」に限定 社内LT / コミュニティでの紹介 1on1でのポジティブな話題づくり 「見えない貢献がある」ことをセットで伝える スライドや説明に注意書きを必ず入れる 目的 （Why?） 粒度 （Who?） コンテキスト （With What?） 個人か？チームか？ 個人→チームに寄せられないか？ 数字と一緒に何を話すか？ 将来の方向性 • 個人メトリクス → チームメトリクスへ • チーム単位の GitHub 活動（レビュー数、PR数など） • DORA (※) 指標との関係を見るなら「個人」ではなく「チーム」で ※ https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
8. 実装の裏側① 技術スタックと全体構成 DO WHAT MATTERS 8 技術スタック ◼ Language / Framework • .NET 8 • ASP.NET Core Razor Components ◼ GitHub API • GitHub GraphQL API v4 • GraphQL.Client + Newtonsoft.Json ◼ 実行・デプロイ • コンテナ前提（Docker） • Azure App Service / Azure Container Apps / AKS ◼ ログ・観測 • Application Insights Telemetry • Console / Debug Logging アプリ全体の構成
9. 実装の裏側② スケーラビリティ・レートリミット・観測性 DO WHAT MATTERS 9 大量メンバー前提のデータ取得 I. Orgメンバー一覧の取得 • GraphQL MembersWithRole(first: 100, after: $cursor) • ページングしながら全メンバーを回収 II. ContributionsCollectionの取得（段階的） • まず「誰がいるか」だけ取る • あとでバッチで各ユーザのContributionsCollection を取得 レートリミット＆パフォーマンス [バッチ取得＋フォールバック] Users[] を5件ずつに分割 → GraphQL バッチクエリ batch1: user1..user5 batch2: user6..user10 成功 → メモリに反映 • バッチ失敗時：個別取得モードにフォールバック • バッチ間で Wait (2000ms など) でレートリミットを回避 • 重い Org の場合はログで推定時間も出力 SemaphoreSlim / Cache / 観測性 [同時アクセス制御] • SemaphoreSlim(1,1) で Get/Refresh の同時実行を 1 つに制限 • 初回取得 or 明示的な Refresh 時だけ GitHub にアクセス • 以降は In-memory Cache を返却 [観測性] • 各ステップの Stopwatch 計測 • ログに "ページ数 / バッチ数 / 経過ms" を記録 • →「どこが遅いか」「どこでリトライが多いか」を後から分析可能
10. まとめ DO WHAT MATTERS 10 DevOps Transformation • 今日お話したこと • GitHub活動を可視化するダッシュボードを作った • やってみたら「楽しいランキング」と「監視ツール」の境界に気づいた • 自分なりに「どう使うか」「どこまでにするか」の線引きを考えた • 個人メトリクスと付き合うときのポイント • 個人メトリクスは「使い方」がすべて • 個人メトリクスは完全に否定すべきものではないけれど、 • 「目的」「粒度」「コンテキスト」を意識しないと、簡単に人を傷つける • メッセージ • このダッシュボードは、みなさんの活動を「点数化」するためではなく、「こん なにいろいろやっているんだね」とお互いを知り、称え合うために作りました。 • もし興味をもっていただけたら、ぜひ「こういうメトリクスをどう使うべきか」、 「どこに線を引くべきか」を一緒に考えていければうれしいです。
11. THANK YOU DO WHAT MATTERS Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art 11 ▪合格対策Microsoft認定試験AZ-400 書籍 発売中！！