GitHub Foundations #7 Domain 5: プロジェクト管理 — Projects・自動化・インサイト

Domain 4でActions、Codespaces、Copilotといった開発ツールを整理したのに対し、Domain 5はその開発を計画して追跡するツールを問います。試験全体に占める割合は大きくありませんが、問われる内容が明確なので、準備した分がそのまま得点につながる領域です。軸は2本です。IssueとPRを計画の単位にまとめるGitHub Projects、そしてリポジトリの活動を読むInsightsです。

GitHub Projects — IssueとPRを計画にまとめるツール #

Issueはタスク1件を、PRは変更1件を担います。ところが実際の業務は「この四半期にどの機能をどの順で終わらせるか」のような、より大きな単位で動きます。GitHub Projectsは、複数のリポジトリに散らばったIssueとPRをひとつの計画画面に集め、ステータスと優先度を付けて進行を追跡するツールです。

試験でまず区別すべきは世代です。現行のProjectsはOrganizationや個人アカウントの下に作られ、複数のリポジトリを横断して項目を集められ、スプレッドシートのような柔軟なフィールドをサポートします。かつてのProjects（classic）はリポジトリに従属した単純なカンバンボードで、すでに廃止の流れにあるため、試験の解答基準は常に現行のProjectsです。

3つのビュー — テーブル・ボード・ロードマップ #

同じ項目の集合を3つの形で表示できます。各ビューの用途をマッチングさせる問題が定番です。

ビューは保存された画面構成にすぎないので、ひとつのプロジェクトに複数のビューを並べて作っておけます。チームミーティング用のBoardビューと四半期計画用のRoadmapビューが、同じデータを別の角度から見せるという使い方です。

カスタムフィールド — ステータス・優先度・iteration #

Projectsの項目には基本情報のほかにフィールドを自由に追加できます。

• Single select — Status（Todo、In Progress、Done）や優先度（P0、P1、P2）のように、決められた値からひとつを選ぶフィールドです。
• Iteration — 2週間スプリントのような繰り返しの期間単位を作り、項目を割り当てるフィールドです。試験で「スプリント単位の割り当てに使うフィールド」を問われたら、答えはiterationです。
• テキスト・数値・日付 — 見積もり時間や締め切りのような自由入力フィールドです。

フィルタとグループ化はこれらのフィールドを基準に動きます。status:"In Progress"のようなフィルタ構文でビューを絞り、担当者や優先度でまとめて見ます。

Issue・PRの連結 — 計画と実行をつなぐ輪 #

Projectsに入る項目の源はIssueとPRです。両者をつなぐ連結ルールは、Domain 3で扱った内容がそのまま続きます。

• PR本文にCloses #12のようにキーワードを書くと、マージ時点で該当Issueが自動的に閉じられます。
• マイルストーンはIssueとPRをリリース単位でまとめるリポジトリレベルのグループで、Projectsはその上でリポジトリを横断する計画レイヤーです。

マイルストーンとProjectsの層の区別を問われたら、マイルストーンはリポジトリ内のリリースのまとまり、Projectsはアカウント・組織レベルの計画ツールと答えれば正解です。

項目の追加とプロジェクトの権限 #

項目をプロジェクトに入れる経路は3つです。プロジェクト画面下部の入力行で#リポジトリ名から検索して追加するか、Issue・PRページのサイドバーのProjects欄で指定するか、後述のauto-addワークフローに自動収集させるかです。まだIssueにしていないメモをdraft itemとして先に書いておき、後からIssueに変換する流れもサポートされます。計画段階のアイデアをdraftとして積み、確定したらリポジトリのIssueに昇格させる使い方が典型です。

プロジェクト自体の公開範囲と権限は、リポジトリとは別に管理されます。privateプロジェクトは招待された人だけが見られ、publicプロジェクトでも、項目として連結されたprivateリポジトリの内容までは公開されません。プロジェクトへの書き込み権限とリポジトリへの書き込み権限が互いに独立だという点が、境界問題として出ることがあります。

組み込みの自動化ワークフロー #

Projectsには、ステータスを手で動かす手間を減らす自動化が組み込まれています。プロジェクト設定のWorkflowsでオン・オフします。

• Auto-add — 指定したリポジトリで条件に合うIssue・PRが生まれたら、プロジェクトに自動で追加します。
• Item added to project — 項目が追加されたらStatusをTodoに設定するといった初期値の指定です。
• Item closed / PR merged — Issueが閉じられたりPRがマージされたりしたら、StatusをDoneに動かします。
• Auto-archive — 完了してから時間が経った項目を自動でアーカイブします。

組み込みワークフローで足りない条件はGitHub Actionsで拡張できます。試験レベルでは「基本の自動化はProjects組み込みワークフロー、複雑な自動化はActions連携」という役割分担だけ押さえておけば十分です。

チャート — プロジェクトのInsights #

プロジェクト画面のInsightsでは、項目データをチャートに描きます。現在のステータス分布を見るチャートと、時間に沿った変化（バーンダウン形式）を見るチャートを作れるので、スプリントのふりかえりに活用されます。リポジトリのInsightsタブと名前が同じで混同しやすいのですが、プロジェクトのInsightsは計画項目のチャート、リポジトリのInsightsはリポジトリ活動の統計です。

リポジトリのInsightsタブ #

リポジトリのInsightsタブは、リポジトリがどう動いているかを見せる統計の集まりです。各項目の用途を1行ずつマッチングできるようにしておきます。

Trafficはpush権限のある人しか見られないという点、Community StandardsはDomain 7で扱うコミュニティファイルとつながるという点を、表とあわせて覚えておくとよいです。

まとめ #

この記事の要点は3つです。

• GitHub Projectsは複数リポジトリのIssue・PRを集めて計画するツールで、Table、Board、Roadmapの3ビューが同じデータを別の角度から見せます。
• ステータスの初期化や完了処理のような繰り返し作業は組み込みの自動化ワークフローが担い、それ以上はActionsで拡張します。
• リポジトリのInsightsはPulse、Contributors、Traffic、Community Standardsでリポジトリの活動と健全性を読む統計の集まりです。

次回の「GitHub Foundations #8 Domain 6: プライバシー・セキュリティ・管理 — 権限・2FA・Dependabot」では、試験で境界の区別問題が最も多く出る領域、すなわち権限モデルとセキュリティ機能の地図を整理します。