業務の傍ら、有志でアジャイルの勉強会をしています。認定スクラムマスターという資格を取ったり、スクラムでアプリの開発を行って、体験談をまとめるというような活動をしています。
この勉強会では、タスク管理は Excel で行っていたのですが、Github 導入に伴ってタスク管理も Github に一本化することにしました。ネットにある記事をベースにしつつも自分たちで工夫したところもあるので、使い方や経験を残しておきます。スクラムでのタスク管理や Github Projects の運用などに参考になったらうれしいです。
Github Projects とは
Projects は、GitHub での作業を計画および追跡するための、適応性のある柔軟なツールです。
ざっくりいうと、Github でタスク管理ができる機能です。項目を柔軟に設定することができます。
リスペクト（運用方法を参考にした記事）
Github Projects では設定が柔軟なので、スクラムで使うにはどう使うのがいいのかわかりませんでした。そこで先人たち知恵を借りるべく、どんな使い方がよいのか調べました。
調べた中で一番ピンときた使い方がこちらの記事です。こちらの記事では、Github Projects のビューを役割ごとに 4 つに分けて、段階的に使っているのが特徴です。
選んだ理由としては 2 点あります。1 つ目はスプリントイベントの流れに沿った利用を想定していることです。スプリントプランニングから、デイリースクラム、リファインメントやレトロスペクティブまでそれぞれのシーンで無理なく運用できそうだと思いました。ビューを複数使って、段階的に管理するという運用がスクラムの流れにあっていると思いました。2 つ目は、現状の問題点を改善できそうだったからです。Excel でのタスク管理をしていた時の問題点は以下の通りです。
- 見積もりをしていない
- スプリント内での状況変化を追い切れていない
- 更新漏れが発生する
- ゴールが何なのかわかりづらい
- タスクの優先順位がつけられない
- 備考に書く内容が多すぎる
- ベロシティを計っていない
特に、Excel でタスク管理をしていたときは、見積もりやベロシティの計測を行っていなかったので、この点もこの記事のやり方でうまくいきそうと思いました。
この記事やり方をベースにして、Github Projects でタスク管理を行うようにしてました。そして、他に記事も参考にしていろいろ試してやってみたことをこの記事でまとめていきます。基本的には、4 つのビューを作成し、タスクを移動させながら、タスクの状態を段階的に管理していきます。
ちなみに、自分の方で工夫したポイントは以下の通りです。2025 年に subissue の機能が使えるようになったので導入してみたり、insigts や PR との連携を行いました。
工夫したこと
- PR と紐づけ
- sub イシューを組み込む
- insigts と連携
- イシューにメモを毎回入れる
- 複数リポジトリのときの表示
GitHub Projects を作成する
GitHub Projectsを作成しましょう。
GitHub Projects はリポジトリに紐づく形で作成しました。リポジトリ内の「Projects」タブをクリックし、"+ New project" をクリックして作成しました。
4 つのビュー構成の紹介と設定
GitHub Projects が作成できたら、GitHub Projects 内に 4 つのビューを作成していきます。タスク管理のために設定する 4 つのビューの構成と役割をまとめます。
| # | ビュー名 | スクラムの役割 | 主な表示タイプ | ビューの基本的な状態 |
|---|---|---|---|---|
| 1 | New Item | PBI（プロダクトバックログアイテム）の候補管理 | Table | リファインメント後は空が基本 |
| 2 | Product Backlog | 全 PBI の優先順位管理 | Table | 優先順位順で常に全ての未完了 PBI を表示 |
| 3 | Sprint Backlog | 現在のスプリントの進行状況管理 | Board | 現在のスプリントのタスクのみを表示 |
| 4 | Completed | 過去の完了タスクのふりかえり | Table | 完了した PBI をスプリント番号の降順で表示 |
以下で各ビューの詳細な設定を紹介します。
New Item (Table) ビューの詳細設定
New Item は、新しく登録された Issue がプロダクトバックログに入る前の一時的な待機場所です。リファインメントで確認され、サイズ（Size）や状態（Ready）が付与されたら「Product Backlog」へ移動するため、このビューは通常、空の状態を目指します。
絞り込み条件(↓意味：サイズが付与されておらず、かつ、検討の結果ドロップとされていないアイテムを表示します。)
no:size -ready:"Drop"
| # | カラム名 | タイプ | 新規作成カラム / 既存カラム | 役割と詳細 |
|---|---|---|---|---|
| 1 | Labels | Labels | 既存カラム | PBI の分類を表します。 |
| 2 | title | Text | 既存カラム | PBI 名をユーザーストーリー形式で書きます。 |
| 3 | Ready | Single Select | 新規作成カラム | PBI の状態を表します。 ・ Ready: PBI に着手できる状態 ・ NotReady: なんらかの条件があり PBI に着手できない状態 ・ Draft: PBI の本文を起票中 ・ Drop: 検討した結果、プロダクトバックログに追加しないことになったもの |
| 4 | Ready 条件/備考 | Text | 新規作成カラム |
Ready のカラムが "NotReady" の場合に、Ready になるための条件を明記します。また必要に応じて備考を記入します。 |
| 5 | Size | Single Select (Number) | 新規作成カラム | PBI のサイズをフィボナッチ数(1, 2, 3, 5, 8…)で選択します。 |
| 6 | Parent Issue | Issue | 既存カラム | 親 issue が表示されます。 |
| 7 | Sub Issue | Issue | 既存カラム | サブ issue が表示されます。 |
Product Backlog (Table) ビューの詳細設定
Product Backlog は、プロダクトの方向性を決定するマスターリストです。プロダクトオーナーが優先順位順に並び替えを行います。
絞り込み条件(↓オープンな Issue のうち、サイズが付与されており、かつ、ドロップとされていないアイテムを表示します。)
is:open -no:size -ready:"Drop"
| # | カラム名 | タイプ | 新規作成カラム / 既存カラム | 役割 |
|---|---|---|---|---|
| 1 | Labels | Labels | 既存カラム | PBI の分類を表します。 |
| 2 | title | Text | 既存カラム | PBI 名をユーザーストーリー形式で書きます。 |
| 3 | Sprint | Single Select | 新規作成カラム | どのスプリントで実施するかを表します。 |
| 4 | Size | Number | 新規作成カラム | PBI のサイズをフィボナッチ数(1, 2, 3, 5, 8…)で選択します。 |
| 5 | Assignees | Assignees | 既存カラム | 担当を入力します。 |
| 6 | Status | Single Select | 既存カラム | 状態を表します。 |
| 7 | Parent Issue | Issue | 既存カラム | 親 issue が表示されます。 |
| 8 | Sub Issue | Issue | 既存カラム | サブ issue が表示されます。 |
Sprint Backlog (Board) ビューの詳細設定
Sprint Backlog は、現在のスプリントでチームが取り組んでいる PBI の進捗を視覚化します。デイリースクラムなどで使用するのに最適です。
絞り込み条件（↓現在のスプリントに割り当てられているアイテムを表示します。）
sprint:this
| 列名 | 新規作成カラム / 既存カラム | 役割と詳細 |
|---|---|---|
| Not Started | 既存カラム | 未着手状態のタスク。 |
| In Progress | 既存カラム | 開発者が作業中のタスク。 |
| In Review | 新規作成カラム | プルリクエストが出され、レビュー待ちの状態のタスク。 |
| Done | 既存カラム | スプリント内で完了したタスク。 |
Completed (Table) ビューの詳細設定
ompleted は、過去のスプリントで「Done」になったタスクを確認したり、レトロスペクティブなどに使用します。
絞り込み条件（↓クローズされており、かつ、サイズが付与されている、ドロップではないアイテムを表示します）
is:closed -no:size -ready:"Drop"
| # | カラム名 | タイプ | 新規作成カラム / 既存カラム | 役割と詳細 |
|---|---|---|---|---|
| 1 | Labels | Labels | 既存カラム | PBI の分類を表します。 |
| 2 | title | Text | 既存カラム | PBI 名をユーザーストーリー形式で書きます。 |
| 3 | Assignees | Assignees | 既存カラム | 担当を表します。 |
| 4 | Sprint | Single Select | 新規作成カラム | どのスプリントで実施したかを表します。 |
| 5 | Size | Number | 新規作成カラム | PBI のサイズをフィボナッチ数(1, 2, 3, 5, 8…)で選択します。 |
| 6 | Status | Single Select | 既存カラム | 状態を表します。 |
| 7 | Ready | Single Select | 新規作成カラム | PBI の状態を表します。 |
| 8 | Ready 条件/備考 | Text | 新規作成カラム |
Ready のカラムが "NotReady" の場合に、Ready になるための条件を明記します。また必要に応じて備考を記入します。 |
| 9 | Parent Issue | Issue | 既存カラム | 親 issue が表示されます。 |
| 10 | Sub Issue | Issue | 既存カラム | サブ issue が表示されます。 |
Insights の詳細設定
GitHub Projects の Insights機能は、プロジェクトのデータを分析・集計し、グラフ化してくれます。スクラムのふりかえりにおいて、チームの生産性を把握するための中心的な役割を果たします。
ベロシティを正確に追跡するために、プロジェクト設定内で、以下の項目を設定する必要があります。ちなみに、ベロシティは、完了した PBI の「Size」（見積もり値）をスプリントごとに合計した数値です。Insights でこのベロシティを自動集計するには、Custom chartsとして「Velocity」という名前のチャートを作成し、以下の設定を行います。
| 設定項目 | 値 | 目的 |
|---|---|---|
| Chart name |
Velocity (任意) |
チャートの名前を設定します。 |
| Chart type | Column |
棒グラフ（カラム）を選択します。 |
| X-axis | Sprint | 横軸をスプリント期間とし、時系列で変化を追跡します。 |
| Y-axis field | Size | 縦軸を集計したい値（見積もりポイント）とし、各スプリントで完了した合計値を表示します。 |
| Group by | (Optional) | 担当者やラベルなどでグルーピングして分析したい場合に設定します。ベロシティ集計自体は不要です。 |
これらの設定を行うことで、各スプリントで完了した Issue の Size の合計が自動的に集計され、ベロシティの推移をダッシュボード上で確認できるようになります。
スプリントイベントでの GitHub Projects の使い方
ビューの設定が完了したところで、各スプリントイベントにおいて、設定した GitHub Projects の 4 つのビューをどのように活用してタスクを管理していくかを見ていきます。
スプリントプランニング
スプリントプランニングは、スプリントの開始時に行うイベントです。スプリントプランニングの目的は、スプリント内で「どんな価値を創出するのか」を決定し、それを達成するために「何を作業として行うのか」を Product Backlog から選定することです。
まず、New Item ビューを確認し、含めたい PBI 候補が残っていないかを確認します。含めたい PBI があれば、Size カラムに適切なフィボナッチ数を設定し、Product Backlog ビューに PBI を移動させます。
そして、Product Backlog ビューを開き、次の 2 つの確認を行います。1 つ目が優先順位の確認です。プロダクトオーナーが優先順位を確認し、リストの並び順を変更します。リストの上に優先順位が高い PBI がくるようにします。2 つ目が PBI の内容を確認です。 PBI（issue） の内容を改めて確認し、チーム間で共通理解を持てるようにします。
次に、Product Backlog ビュー の上から順に、スプリントで対応するアイテムを選定します。Product Backlog ビューで上から（優先順位の高いものから）、PBI の sprint のカラムにthis を設定します。この操作によって、thisがつけられた PBI は自動的に Sprint Backlog ビューに表示されます。最後に Assignees カラムにメインで動く担当者の名前を割り振ります。
デイリースクラム
デイリースクラムは、毎日チームが集まり、進捗状況の共有と問題点の特定を行うイベントです。New Item ビューで PBI があれば内容を確認し、Size カラムに適切なフィボナッチ数を設定します。そして、Product Backlog ビューでプロダクトオーナーが優先順位を確認し、優先順位に変動がないか確認します。
そして、Sprint Backlog ビューで、PBI をボード上でドラッグ＆ドロップし、Status（状態）を更新します（例: Not Started → In Progress）。議事録もかねて、PBI（issue）のコメントに進捗状況や問題点を書き込みました。これは振り返りの材料になりました。
ちなみに、PBI の起票はどのタイミングで誰がやっても行っても OK です。起票する際は、New Item ビューで PBI を登録し、Size 以外のカラム（Ready, Ready 条件/備考など）に内容を設定します。 Size が未設定のため、新規 PBI は New Item にのみ表示され、Product Backlog には表示されません。
リファインメント
リファインメントは、プロダクトバックログを詳細化し、見積もりを行い、整理する活動です。New Item ビューで PBI の複雑さや工数を検討し、Size カラムに適切なフィボナッチ数を設定します。Size が設定されると、PBI は New Item から消え、Product Backlog に表示されるようになります。デイリースクラムでも見積もりを行うこともありますが、リファインメントのタイミングで起票されることが多かったです。
時々、一つの PBI では大きいので、作業を割りたいときがあります。そのときは、subissue を使って PBI をわります。subissue を使うと、PBI（issue）に親子関係を作って管理できます。親の PBI（parent issue） のSize は 0 にして、subissue だけ 1 以上のSizeを入れました。0 をいれないと、Product Backlog ビューに移動しないので、こうした操作をしています。ここの操作や運用はまだ成熟していないので、試しながら運用の精度をあげたいところです。
サイズを見積る前に、PBI の受け入れ条件やタスク内容を具体的に記載する必要があります。人によって記載粒度が異なるので、受け入れ条件やタスク内容を指摘して、見積るのに必要な情報が並ぶようにしましょう。
次に、Product Backlog ビューにて、プロダクトオーナーが PBI を適切な優先順位の位置へ並べ替え（ドラッグ＆ドロップ）ます。繰り返しますが、優先順位が高いものが上になるように並び替えます。
スプリントレビュー
スプリントレビューは、開発チームがスプリント内で創出した価値をステークホルダーにプレゼンテーションするイベントです。主にデモンストレーションと議論に焦点を当てるため、スプリントレビュー中に GitHub Projects 上での操作はありません。
ただ、ステークホルダーからのフィードバックは、Issue として起票し New Item へ登録します。そして、ステークホルダーから PBI(チーム内のレビューが終わっていて、doneになっている) がOKと判定いただいたら、 PBI の Sprint カラムの値をthis からスプリント番号のラベルに変更します。これによって、PBI は Sprint Backlog ビューから Completed ビューに移動します。thisからスプリント番号を入れることで、スプリントごとに Insights でベロシティを集計することができます。
レトロスペクティブ
レトロスペクティブは、プロセスをより良くするために、何がうまくいったか、何が課題だったかを話し合うイベントです。Insights 機能を確認し、自動集計されたベロシティを議論の起点とします。前スプリントと比較して、ベロシティが多かったのか、少なかったのか、それはなぜかを議論します。
さらに、 Completed ビューを参照し、完了した PBI のリストを確認します。デイリースクラム時の進捗メモや課題を参考にしたり、事前にKPTで振り返りのメモをメンバーに作ってきてもらい、議論の材料にしました。
Github Projects 運用の小ネタ
便利な機能や運用を紹介します。
Git ブランチの運用
せっかくなので、Git の運用についてもメモを残しておきます。基本的に Gitflow をベースにした運用を行っていました。以下の 3 種類のブランチを主に使用していました。
| ブランチ名 | 役割 | 運用（Git Flow における位置づけ） |
|---|---|---|
main |
本番運用のためのブランチ。常にデプロイ可能な状態を維持します。 |
main ブランチに相当 |
sprint-○○ |
開発ブランチ。スプリント単位で集約を行うためのブランチ。 |
develop ブランチに相当 |
feature/○○ |
フィーチャーブランチ。個別の機能開発やタスク作業を行うためのブランチ。 |
feature ブランチに相当 |
ブランチ運用としては、以下のような流れで運用してました。
- スプリント開始時: 最新の
mainブランチから、今回のスプリント番号を付与したsprint-○○ブランチ（例:sprint-10）を切ります。 - PBI（タスク）着手時: 開発者は、
sprint-○○ブランチから個別の PBI に対応するfeature/○○ブランチを切ります。 - 開発完了時:
feature/○○ブランチでの開発が完了したら、sprint-○○ブランチに向けて Pull Request (PR) を作成し、レビュー後にマージします。 - スプリント終了時: スプリントが完了し、全ての機能が統合・テストされた後、
sprint-○○ブランチからmainブランチへ PR を作成し、本番環境へリリースします
スプリントごとに中間的な開発ブランチ（sprint-○○）を設けることで、2 つのメリットがありました。1 つ目はリリース管理の明確化です。どのコードがどのスプリントで完了したのかが明確になり、リリース対象のコードが sprint-○○ ブランチに集約されるため、リリース作業がシンプルになりました。2 つ目は、main ブランチの安全運用です。 main ブランチへのマージはスプリントの終わりに一度に集中するため、main ブランチが頻繁に更新されることによる不安定化を防ぎました。
また、コードがマージされたブランチ（feature/○○ブランチや完了したsprint-○○ブランチ）は、マージ後すぐに削除するルールを採用していました。これは、不要なブランチが残り続けることによる混乱や、ブランチリストの煩雑化を防ぐための工夫でした。
issue とPRを紐づけて、マージすると自動でDoneになるようにする
GitHub Projects でタスク（PBI）を管理する上で、その実体である Issue とPR を紐づけることは大切です。
Sprint Backlog (Board) ビューで4つのステータスを作成しました。このステータス変更をなるべく自動でできるように試行錯誤しました。結果、issueとPRが紐づいたときに「In Review」に自動でステータス変更できます。また、PRがmainブランチにマージされたときに「Done」に自動でステータス変更できます。この方法を紹介します。
まず、issueとPRが紐づいたときにステータスを「In Review」に変更するように設定します。「Workflows」を開いて、「Pull request linked to issue」から「Set value」を「In Review」に変更します。あとは、デフォルトの設定でOKです。
流れを見ていきます。まず、PBI（issue）を作成し、Sprint Backlog (Board) ビューで「In Progress」だったとします。
作業が終わったとして、sprintブランチにマージするようにPRを作成します。↓のスクショでは97ブランチに向かって作業ブランチをマージするようにPRを作成しました。
PRを作成したら、Sprint Backlog (Board) ビューからissueを開いて、PRと連携させます。右下の「Development」からPRを指定します。PRを指定すると「Development」は以下のような表示になります。
PRとひもづくと、自動で「In Review」に移動しました！
レビューがOKになったとして、PRをスプリントブランチにマージします。
スプリントが終わるタイミングで、スプリントブランチのPRを作成しmainブランチにマージします。このときに、キーワードを指定してissueをクローズします。issueがクローズされると、Sprint Backlog (Board) ビュー上でステータスが「Done」になります。
↓では、「close #101 」（101はissueの番号）を指定しました。
マージします。すると、自動で「Done」に移動しました！
運用上のメリットは 3 つあります。1 つ目は、手間とミスの削減です。開発者がコードレビュー後に手動で Issue をクローズしたり、Projects のボードを操作したりする手間がなくなります。また、手動操作によるミスの発生を防げます。2 つ目は、リアルタイムな進捗管理です。コードがマージされた時点でプロジェクトの進捗が反映されるため、Sprint Backlog のボード状態が常に最新に保たれ、デイリースクラムなどで正確な状況把握が可能になります。3 つ目は完了の定義の徹底です。「コードがマージされ、Issue がクローズされたら完了」というチームの完了の定義を、ツールを通じて自動で徹底できます。
ただ、このやり方だと、mainブランチにマージされたときにdoneになります。mainブランチにマージされたときではなく、スプリントブランチにマージしたときにdoneに名た方がいいかもしれないです。ここはまだ改善の余地があります。
issueのテンプレートを追加
PBIを作成するときに、記載内容をそろえるためにテンプレートを設定しています。
テンプレートの中身は、参照した記事（リスペクト記事）と同じです。
## 概要
<!-- このPBIにおける主要な課題や機能、及び期待される成果について簡潔に説明してください。-->
### 何をやるのか
### なぜやるのか
## 受入条件
<!-- このPBIを完了とするための条件をリスト形式で記載してください。受け入れ条件は状態として記載します。-->
- [ ] 受入条件1
- [ ] 受入条件2
## タスク
<!-- 開発者がこのPBIを達成するために必要なタスク（具体的な作業項目）をリスト形式で記載してください。-->
- [ ] タスク1
- [ ] タスク2
## その他
<!-- このPBIに関連するドキュメント、過去の類似したPBI、注記や備考などをここに記載してください。-->
運用してみての所感
GitHub Projects にはメリットを感じました。主に 4 つあります。メリットの 1 つ目は、開発ワークフローとの連携にあります。Pull Request がクローズされた瞬間、プロジェクトボード上のステータスが自動的に「完了」に更新されます。この自動化によって、「タスクの実態（コードのデプロイやマージ）」と「タスク管理表（Projects）」が一致します（以前はPRマージ時にうまくステータスが変わっていたと思うのですが。。今は上述したようなやり方が必要そうです。。。）。
メリット 2 つ目はアカウント管理コストが小さくなることです。GitHub のアカウントさえあれば、Projects 上でのタスク管理からコードレビュー、マージまで権限管理が完結します。他ツールのアカウント発行や権限設定の手間が不要となり、アカウント管理コストが削減できます。セキュリティの観点からも、一元管理は大きなメリットでした。
メリット 3 つ目はコストパフォーマンスがよいことです。GitHub Projects は、Organization）単位で利用可能でありながら、実質的に無料で提供されています。開発コストを抑えながら高水準の管理体制を構築できます。
メリットの 4 つ目は柔軟に設定項目を変更できることです。プロジェクトの要件が変わっても GitHub Projects は柔軟に対応できます。カスタムフィールドやビュー機能を作り込むことで、プロジェクト固有の値を設定できたり、タスク管理の方法を工夫することができます。
GitHub Projects のメリットがきれいにまとめられたのですが、「スクラムを運用してみての難しいところ」はダラダラ書いていきます。
New ItemビューやProduct Backlogビューでlabelというカラムがありますが、これをうまく運用できませんでした。backendとかfrontendのような技術でわけたり、機能名をつけたりして、ごちゃごちゃになりました。PBIの文脈でいえば、技術的なlabelはつけなくてもよかったかもしれません。
「見積ること」もかなり難しかったです。PBIの内容が洗い出せていなかったり、チーム内で見積る基準のようなものがなかったことが原因だと思われます。さらに、レトロスペクティブで見積もりの結果を振り返っていないことも問題点でした。フィボナッチ数列を使う意味だとか、見積もりで何をしたいのかみたいな会話がもっと必要だったのかもしれません。実績値を出してレトロスペクティブで答え合わせを行った方がよかったのでしょうか。
見積もりに関連して、PBIの概要や受け入れ条件の記載粒度が人によってまばらでした。もっとリファインメントなどで詳細を詰める必要があったのかと思います。ただ、リファインメント時点で詳細がわからないこともあり、具体的な内容を書けないこともありますバックログの不確定要素をつぶすバックログをつくるのがスクラム的には正解なのかもしれないが、個人的には議論したいポイントです。技術的な不確定要素（実現方法が不透明）をつぶすバックログと作業するバックログのセットで運用する方がよかったのでしょうか。スクラムでは、スプリント内でこのような不確定要素をつぶす過程がやや曖昧に感じます。「小さく試す」というように仮定と検証を高速で繰り返すことで不確定要素を解消しようとしていますが、スプリント内で「小さく試す」という部分が個人のスキル任せになっている印象を受けます。もちろんチームで助け合うとは思いますが。
PRとissueの連携のところもまだモヤモヤしているので、もっと簡単に運用できるようにしたいです。Insights でもっといろんなことを可視化してみたいですね。今はベロシティしかないですが、振り返りをするにあたって議論の材料となる値を工夫してみたいです。
おわりに
GitHub Projects は柔軟な設定ができる分、どう管理するか工夫のし甲斐があります。タスク管理をする上で何を管理したいのか、何を表示したいのか考えるのは難しかったですが、面白みも感じました。ビューに複数のリポジトリからissueを表示できたりしてちょっと感動しました。
まだまだ使っていない機能もありますし、改善したいところもあるので、いろいろ試してみたいです。小規模なチームであれば、GitHub Projects で管理できそうですし、Github actions で集計したりしてもっとてきることがありそうです。この記事が誰かの役に立ったら嬉しいです。
最後まで読んでいただいた方、ありがとうございました。
参考文献
- GitHub 公式サイト (公開日不明)「Projects のベスト プラクティス」
https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/best-practices-for-projects2025年12月3日アクセス. - GitHub 公式サイト (公開日不明)「Projects について」
https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects2025年12月3日アクセス. - GitHub 公式サイト (公開日不明)「Projects のクイック スタート」
https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/quickstart-for-projects2025年12月3日アクセス. - developers IO produced by Classmethod Kyoさま (2024年4月12日)「GitHub Projects を使った（プロダクト/ スプリント）バックログ管理 #スクラム」
https://dev.classmethod.jp/articles/scrum-backlog-github-projects/2025年12月3日アクセス. - Zenn Happy Elements カカリアスタジオさま (2024年12月27日)「GitHubProject を使用して便利だった設定の紹介」
https://zenn.dev/happy_elements/articles/hekk_article_2024122025年12月3日アクセス. - Qiita ysk91_engineerさま (2024年10月25日)「チケット管理を GitHub Issue と Project でおこなう方法」
https://qiita.com/ysk91_engineer/items/9873f50e0540783756172025年12月3日アクセス. - 一休.com の開発者ブログさま (2023年11月9日)「GitHub Projects を利用したタスク管理」
https://user-first.ikyu.co.jp/entry/2023/11/09/1751212025年12月3日アクセス. - Qiita bon10さま (2024年12月19日)「Github Project を使ってプロダクト全体の課題・進捗管理をやってしまおう」
https://qiita.com/bon10/items/ce77034a88c1b44c51f72025年12月3日アクセス. - KAKEHASHI Tech Blogさま (2023年2月28日)「GitHub Projects を導入した話」
https://kakehashi-dev.hatenablog.com/entry/2023/02/28/0900002025年12月3日アクセス. - Hello Scramさま (2021年8月11日)「【完全攻略】スクラム開発におけるプロダクトバックログの作り方」
https://do-scrum.com/pbl/2025年12月3日アクセス. - Qiita inabakunさま (2023年10月3日)「GitHub Projects でスクラム開発は快適だけど物足りなさもあるよ」
https://qiita.com/inabakun/items/128ccf5ef44e3b531f542025年12月3日アクセス. - GENESIS 株式会社 代表取締役のブログさま (2025年8月27日)「:Hub で Organization を新規作成する方法」
https://genesis-tech.jp/blog/create-github-organization/2025年12月3日アクセス. - いつも隣に IT のお仕事さま (2021年3月11日)「GitHub でリポジトリを組織管理するための Organization とそのつくり方」
https://tonari-it.com/github-organization/2025年12月3日アクセス.