GitHub Projectsを使ったプロジェクト管理

記事

IT・テクノロジー

Bitz 村上幸雄

2026/07/01 15:54

GitHub Projects・Issue・マイルストーンを組み合わせたプロジェクト管理の設計と運用を紹介します。

プロジェクト管理に必要なもの

ソフトウェア開発のプロジェクトでは、「何をいつまでに誰がやるか」を把握・管理するためのツールが欠かせません。必要な機能は大きく次の3つです。

課題・タスク管理：やるべきことを「Issue（課題）」や「タスク」として登録し、担当者・期限・状態を追跡します。バグ報告や新機能の要望なども、ここに集約します。

ガントチャート（線表）：タスクを時間軸上に並べ、いつ何をするかをバーの長さで表した図です。タスクの依存関係や、全体のスケジュールを一覧で把握するのに使います。

カンバンボード：タスクをカード形式で「未着手」「作業中」「完了」などの列に並べたボードです。チームの作業状況をひと目で把握でき、タスクが詰まっている場所を見つけやすくなります。

代表的なツール・サービス

これらの機能を提供するツール・サービスはさまざまあります。デスクトップアプリとして代表的なのがOmniPlan（Mac向け）です。ガントチャートの作成に特化しており、タスクの依存関係や担当者ごとのリソース管理が細かく設定できます。単独での作業や、外部に共有しにくい計画の管理に向いています。

Webサービスとしては Backlog（ヌーラボ）が国内でよく使われています。課題管理・ガントチャート・カンバンボード・Gitリポジトリをひとつのサービスで提供しており、開発チームとビジネスサイドが同じ画面で進捗を共有できます。このほかにも Jira・Asana・Linear・Notion などのサービスがあり、チームの規模や用途に応じて選択します。

GitHubで管理する利点

コードをGitHubで管理しているチームであれば、GitHub Projects を使うことでコードとプロジェクト管理を一元化できます。

・Issue（課題）がそのままタスクになる

・Pull Requestと課題が直接紐付けられる

・コードの変更とタスクの進捗が同じ場所で追える

・別サービスへのデータ転記が不要

ガントチャートに相当するロードマップビュー、カンバンボードに相当するボードビューも備えており、別途ツールを追加しなくても基本的なプロジェクト管理ができます。

開発手法とツールの使い方

プロジェクト管理のツールは、チームが採用している開発手法によって使い方が変わります。

ウォーターフォール

要件定義 → 設計 → 実装 → テスト → リリースという工程を順番に進める手法です。各工程の完了を確認してから次に進むため、スケジュールを最初に詳細に組みます。ガントチャートが中心になります。工程ごとのタスクを洗い出し、依存関係と期限を設定して線表を作ります。マイルストーンは「設計完了」「実装完了」「テスト完了」といった工程の区切りに設定します。

アジャイル・スクラム

短い期間（スプリント、通常1〜2週間）を繰り返し、機能を少しずつリリースしていく手法です。要件は最初にすべて固定せず、フィードバックを取り込みながら進めます。カンバンボードが中心になります。バックログ（やることリスト）から今回のスプリントで取り組む課題を選び、「未着手 → 作業中 → レビュー中 → 完了」の流れで管理します。

スクラムでは次の単位でIssueを整理します。

・エピック（大きな機能のまとまり） → GitHubではマイルストーンで対応

・ユーザーストーリー（機能を利用者視点で記述したもの） → Issue（storyテンプレート）で対応

・スパイク（不確実な部分の調査・設計） → Issue（spikeテンプレート）で対応

・タスク（ストーリーを実現するための作業） → Issueのチェックリストで対応

GitHub Projectsでの対応

GitHub Projectsはどちらの手法にも対応できます。

・ウォーターフォール寄りの管理：ロードマップビューで工程の期間を可視化し、マイルストーンで工程の完了を管理する

・アジャイル・スクラム寄りの管理：Iterationフィールドでスプリントを定義し、ボードビューでカンバン管理する

実際の現場では、大きな計画はウォーターフォール的に立て、日々の作業はスクラム的に管理するというハイブリッドな使い方も多くあります。

全体の設計思想

このプロジェクト管理の設計は、次の3点を基本方針としています。

・Issueの種類を明確に分ける — 機能開発・調査・バグ報告・修正方針を別テンプレートにすることで、それぞれの目的と手順を明確にする

・着手のゲートを設ける — テンプレートに着手前の確認チェックリストを入れ、準備が整う前に実装が始まらないようにする

・マイルストーンで期限を可視化する — 機能単位でマイルストーンを設定し、何をいつまでに終わらせるかをチーム全体で共有する

Issueテンプレートの設計

.github/ISSUE_TEMPLATE/ にテンプレートファイルを置くことで、Issue作成時に種類を選べるようになります。テンプレートは4種類用意しています（ユーザーストーリー・スパイク・バグ報告・改修方針）。

ユーザーストーリー

新機能や改善要求を定義するテンプレートです。タイトルの形式は「〜できる／〜をしたい」とし、What（何をするか）とWhy（なぜするか）を書きます。Howは書きません。実装者が考える余地を残すためです。主なセクションは、概要、着手前の確認、受け入れ条件、タスク、作業報告です。

スパイク（調査・設計）

技術調査や設計を行い、実装方針を確定するためのテンプレートです。スパイクは設計フェーズ専用で、このIssueがクローズされるまで関連する実装を開始しません。主なセクションは、目的、調査・設計項目、完了条件です。

バグ報告

不具合を報告するテンプレートです。このテンプレートは報告専用で、修正の実装は別のIssue（改修方針）で行います。報告者が修正を始めてしまわないよう、テンプレートの冒頭にルールを明示しています。主なセクションは、バグの概要、再現手順、影響範囲、環境情報、次のステップです。

改修方針

バグ報告を受けて、修正方針をレビュー・承認するテンプレートです。承認後にProjectsのStatusが「Ready for Dev」になった段階で、実装を開始します。主なセクションは、原因分析、修正方針、テスト計画、レビュー記録です。

テンプレートのポイント：着手前の確認

ユーザーストーリーと改修方針のテンプレートには、着手前の確認チェックリストを設けています。「スパイクIssueがある場合は、それがクローズされている」「ProjectsのStatusが Ready for Dev になっている」「担当者がアサインされている」の3点を確認してから実装を開始します。このチェックリストが「着手のゲート」として機能します。準備が整う前に実装が始まることを防ぎ、手戻りを減らします。

ラベルの設計

ラベルはIssueの種類とフェーズを表すために使います。種類ラベル（テンプレートと対応）は type: story（ユーザーストーリー）、type: spike（スパイク）、type: bug（バグ報告）、type: fix-plan（改修方針）です。フェーズラベル（作業の進行状況）は設計 / Design、実装 / Implementation、試験 / テストです。テンプレートのfrontmatterでデフォルトラベルを設定しておくと、Issue作成時に自動で付与されます。

マイルストーンによる期限管理

マイルストーンは機能単位で設定し、期限（due date）を必ず入れます。命名規則は「[機能ID]-[機能名]:[フェーズ名]」というパターンを使っています。機能IDをアルファベットと連番で体系化することで、機能の優先順位と実装順序が一覧で把握できます。フェーズを分けることで、設計と実装を別マイルストーンとして管理できます。

マイルストーンのページでは、IssueのオープンとクローズがProgress barとして表示されます。週次の定例会議で「このマイルストーンが何%完了しているか」を確認することで、進捗の遅れを早期に検知できます。

GitHub Projectsのビューとフィールド

3つのビュー

GitHub Projectsには3種類のビューがあり、用途に応じて切り替えられます。ボード（カンバン）はStatusを列にしてカード形式で並べ、作業の流れと詰まりを把握しやすい形式です。テーブルはIssueを表形式で一覧表示し、フィルタリングや並び替えで絞り込みやすい形式です。ロードマップ（タイムライン）は期間をバーで表示するガントチャート形式で、スケジュール全体を把握するのに使います。同じプロジェクトを複数のビューで見られるため、「今日の作業状況はボードで確認し、来月の見通しはロードマップで確認する」という使い分けができます。

Statusフィールドによる着手管理

GitHub Projectsでは、カスタムフィールドを追加してIssueの状態を管理します。Statusフィールドの代表的な値は、Backlog（未着手・計画段階）、Ready for Dev（着手可能）、In Progress（実装中）、In Review（レビュー中）、Done（完了）です。「Ready for Dev」が着手のゲートになっており、テンプレートの着手前チェックリストと連動しています。PMがStatusを「Ready for Dev」に変更するまで、担当者は実装を開始しません。