はじめに

ソフトウェア開発において、コードを書くだけでなく「何を作るか」「誰が担当するか」「いつまでに完成させるか」を管理することは非常に重要です。GitHub IssuesとProjectsは、これらのタスク管理とプロジェクト運営を効率化するための強力な機能を提供しています。

本記事では、GitHub Issuesの作成と管理方法、ラベルやマイルストーンを使った分類と進捗管理、GitHub Projectsでのカンバン管理、そしてIssueとPull Requestを連携させて自動的にタスクをクローズする方法までを体系的に解説します。この記事を読み終えると、以下のことができるようになります。

  • GitHub Issueを作成し、適切に管理できる
  • ラベルを活用してIssueを分類・整理できる
  • マイルストーンでリリース計画と進捗を管理できる
  • GitHub Projectsでカンバンボードを使ったタスク管理ができる
  • Pull RequestとIssueを連携させ、マージ時に自動クローズできる

実行環境と前提条件

本記事の内容は、以下の環境で動作確認を行っています。

項目 要件
Git 2.40以上
OS Windows 10/11、macOS 12以上、Ubuntu 22.04以上
ターミナル コマンドプロンプト、PowerShell、Terminal.app、bash等
エディタ VS Code推奨

前提条件として、以下の知識があることを想定しています。

  • コマンドライン操作の基礎知識(cdls/dirmkdir等)
  • テキストエディタの基本操作
  • GitHubアカウントの作成とリポジトリの基本操作
  • Pull Requestの基本的な理解

Gitのバージョンは以下のコマンドで確認できます。

1
git --version

GitHub Issuesとは

Issueの基本概念

GitHub Issueは、プロジェクトにおけるタスク、バグ報告、機能要望、質問などを追跡・管理するための機能です。単なるタスクリストではなく、議論の場としても活用でき、チームメンバー間のコミュニケーションを促進します。

Issueの主な用途は以下のとおりです。

  • バグ報告: 発見したバグの詳細を記録し、修正を追跡する
  • 機能要望: 新機能のアイデアを提案し、実装の可否を議論する
  • タスク管理: 作業項目を細分化し、担当者や期限を設定する
  • 質問・議論: 技術的な質問や設計方針についてチーム内で議論する
  • ドキュメント改善: ドキュメントの不備や改善点を報告する

Issueの構成要素

Issueは以下の要素で構成されています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
┌─────────────────────────────────────────────────────────────┐
│  Issue #42: ログイン画面のバリデーション追加                    │
├─────────────────────────────────────────────────────────────┤
│  Title(タイトル): 簡潔で内容がわかるタイトル                   │
│  Description(本文): 詳細な説明、再現手順、期待される動作        │
├─────────────────────────────────────────────────────────────┤
│  サイドバー                                                   │
│  ├─ Assignees: 担当者                                        │
│  ├─ Labels: ラベル(bug, enhancement等)                     │
│  ├─ Projects: 関連するProject                                │
│  ├─ Milestone: マイルストーン                                 │
│  └─ Development: 関連するPR/ブランチ                          │
├─────────────────────────────────────────────────────────────┤
│  Comments: チームメンバーからのコメント・議論                   │
└─────────────────────────────────────────────────────────────┘

Issueの作成と管理

Issueの作成手順

Issueを作成するには、リポジトリの「Issues」タブから「New issue」をクリックします。効果的なIssueを作成するポイントは以下のとおりです。

  1. 明確なタイトル: 何についてのIssueか一目でわかるタイトルをつける
  2. 詳細な説明: 背景、現状、期待される結果を記述する
  3. 再現手順(バグの場合): 問題を再現するための具体的な手順を記載する
  4. 環境情報: OS、ブラウザ、バージョン等の情報を含める

効果的なIssue記述のテンプレート

バグ報告用のIssueテンプレートの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
## バグの概要
ログインフォームで空のパスワードを送信できてしまう

## 再現手順
1. ログイン画面にアクセスする
2. メールアドレスを入力する
3. パスワード欄を空のままにする
4. 「ログイン」ボタンをクリックする

## 期待される動作
パスワードが空の場合、エラーメッセージが表示され送信がブロックされる

## 実際の動作
パスワードが空でもリクエストが送信され、サーバーエラーが発生する

## 環境
- OS: Windows 11
- ブラウザ: Chrome 120
- アプリバージョン: v1.2.3

機能要望用のIssueテンプレートの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
## 機能の概要
ダークモードの実装

## 背景・動機
夜間にアプリを使用する際、画面が眩しく目が疲れるというフィードバックが複数寄せられている

## 提案する解決策
- システム設定に連動するダークモード切り替え機能
- 手動でのテーマ切り替えオプション
- 設定の永続化

## 代替案
- ブラウザ拡張機能での対応(ただし一貫性に欠ける)

## 追加情報
参考デザイン: [リンク]

Issueの状態管理

Issueには「Open」と「Closed」の2つの状態があります。

状態 説明
Open 作業中または未着手のIssue
Closed 完了または対応不要となったIssue

Issueをクローズする方法は以下のとおりです。

  • Issue画面下部の「Close issue」ボタンをクリック
  • 「Close as completed」: 作業完了
  • 「Close as not planned」: 対応しないことを決定

また、後述するPull Requestとの連携により、自動的にクローズすることも可能です。

ラベルによるIssueの分類

ラベルの基本

ラベルは、Issueを分類・整理するための色付きタグです。適切にラベルを活用することで、Issueの検索性が向上し、プロジェクトの状況を一目で把握できるようになります。

デフォルトラベル

GitHubは新しいリポジトリに以下のデフォルトラベルを提供しています。

ラベル 説明
bug 予期しない動作やバグを示す
documentation ドキュメントの改善や追加が必要
duplicate 類似のIssueが既に存在する
enhancement 新機能の要望
good first issue 初めてのコントリビューターに適したIssue
help wanted メンテナーが助けを求めている
invalid 無効または関連性がなくなった
question 追加情報や説明が必要
wontfix 対応しないことを決定した

カスタムラベルの作成

プロジェクトに合わせてカスタムラベルを作成できます。「Issues」タブから「Labels」をクリックし、「New label」で新しいラベルを作成します。

推奨されるカスタムラベルの例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
カテゴリ別ラベル:
├─ type: bug        (赤系)   バグ報告
├─ type: feature    (緑系)   新機能
├─ type: refactor   (青系)   リファクタリング
├─ type: docs       (黄系)   ドキュメント
└─ type: test       (紫系)   テスト関連

優先度ラベル:
├─ priority: high   (赤)     高優先度
├─ priority: medium (橙)     中優先度
└─ priority: low    (灰)     低優先度

ステータスラベル:
├─ status: blocked      ブロック中
├─ status: in-progress  作業中
├─ status: review       レビュー待ち
└─ status: ready        着手可能

対象コンポーネント:
├─ area: frontend   フロントエンド
├─ area: backend    バックエンド
├─ area: database   データベース
└─ area: infra      インフラ

ラベルの適用とフィルタリング

Issueにラベルを適用するには、Issue画面右側のサイドバーで「Labels」をクリックし、該当するラベルを選択します。

ラベルでIssueをフィルタリングするには、以下の方法があります。

  1. Issues一覧のフィルター: 「Labels」ドロップダウンからラベルを選択
  2. 検索クエリ: label:buglabel:"good first issue" を使用

複数ラベルの組み合わせ検索も可能です。

1
2
3
4
5
label:bug label:"priority: high"
# バグかつ高優先度のIssueを検索

label:enhancement -label:wontfix
# 新機能要望で対応予定のあるものを検索

マイルストーンによる進捗管理

マイルストーンとは

マイルストーンは、関連するIssueやPull Requestをグループ化し、リリースやスプリントの進捗を追跡するための機能です。期日を設定することで、プロジェクトのスケジュール管理にも活用できます。

マイルストーンの活用例を示します。

  • バージョンリリース: v1.0.0、v1.1.0、v2.0.0
  • スプリント: Sprint 1、Sprint 2、Sprint 3
  • フェーズ: MVP、Beta、GA(General Availability)
  • 四半期目標: 2026 Q1、2026 Q2

マイルストーンの作成

マイルストーンを作成する手順は以下のとおりです。

  1. リポジトリの「Issues」タブを開く
  2. 「Milestones」をクリック
  3. 「New milestone」をクリック
  4. 以下の情報を入力
    • Title: マイルストーン名(例: v1.0.0)
    • Due date: 期日(オプション)
    • Description: 概要や目標

Issueへのマイルストーン設定

Issueにマイルストーンを設定するには、Issue画面右側のサイドバーで「Milestone」をクリックし、該当するマイルストーンを選択します。

進捗の確認

マイルストーンページでは、以下の情報を確認できます。

  • 完了率(プログレスバーで視覚的に表示)
  • Open/ClosedのIssue数
  • 期日までの残り日数
  • 関連するIssueとPull Requestの一覧
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
┌─────────────────────────────────────────────────────────────┐
│  Milestone: v1.0.0                                          │
│  Due: 2026-01-31                                            │
├─────────────────────────────────────────────────────────────┤
│  Progress: ████████████░░░░░░░░ 60%                         │
│                                                             │
│  Open: 4 issues    Closed: 6 issues                         │
├─────────────────────────────────────────────────────────────┤
│  Open Issues:                                               │
│  ├─ #42 ログイン画面のバリデーション追加                       │
│  ├─ #45 パスワードリセット機能                                │
│  ├─ #48 エラーハンドリングの改善                              │
│  └─ #50 ユニットテストの追加                                  │
└─────────────────────────────────────────────────────────────┘

GitHub Projectsによるカンバン管理

GitHub Projectsとは

GitHub Projectsは、IssueやPull Requestを視覚的に管理するためのプロジェクト管理ツールです。テーブルビュー、カンバンボード、ロードマップなど複数のビューを切り替えながら、柔軟にタスクを管理できます。

Projectの作成

新しいProjectを作成する手順は以下のとおりです。

  1. リポジトリまたは Organization のページを開く
  2. 「Projects」タブをクリック
  3. 「New project」をクリック
  4. テンプレートを選択(または空白から開始)
    • Table: スプレッドシート形式
    • Board: カンバンボード形式
    • Roadmap: タイムライン形式
  5. プロジェクト名を入力して作成

カンバンボードの活用

カンバンボードは、タスクの状態を列(カラム)で表現し、カードを移動させることで進捗を管理する手法です。

一般的なカンバンボードの構成を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
┌─────────────────────────────────────────────────────────────────────┐
│                    Project: Sprint 2026-01                          │
├─────────────────┬─────────────────┬─────────────────┬───────────────┤
│   Backlog (5)   │  In Progress (2)│   Review (1)    │   Done (8)    │
├─────────────────┼─────────────────┼─────────────────┼───────────────┤
│ ┌─────────────┐ │ ┌─────────────┐ │ ┌─────────────┐ │ ┌───────────┐ │
│ │ #55 検索機能│ │ │ #42 バリデ  │ │ │ #38 API修正 │ │ │ #30 完了  │ │
│ │ enhancement │ │ │ ーション    │ │ │ @alice      │ │ │           │ │
│ └─────────────┘ │ │ @bob        │ │ └─────────────┘ │ ├───────────┤ │
│ ┌─────────────┐ │ └─────────────┘ │                 │ │ #31 完了  │ │
│ │ #56 通知機能│ │ ┌─────────────┐ │                 │ │           │ │
│ │ enhancement │ │ │ #45 リセット│ │                 │ └───────────┘ │
│ └─────────────┘ │ │ @carol      │ │                 │      ...      │
│      ...        │ └─────────────┘ │                 │               │
└─────────────────┴─────────────────┴─────────────────┴───────────────┘

ビューのカスタマイズ

GitHub Projectsでは、目的に応じて複数のビューを作成できます。

テーブルビュー スプレッドシート形式で、カスタムフィールドを追加してデータを管理できます。

1
2
3
4
5
| Title              | Status      | Priority | Assignee | Due Date   |
|--------------------|-------------|----------|----------|------------|
| #42 バリデーション  | In Progress | High     | bob      | 2026-01-15 |
| #45 リセット機能    | In Progress | Medium   | carol    | 2026-01-20 |
| #55 検索機能        | Backlog     | Low      | -        | -          |

ボードビュー カンバン形式で、ステータス列ごとにカードを配置します。

ロードマップビュー タイムライン形式で、イテレーションや日付フィールドに基づいてアイテムを配置します。

カスタムフィールドの追加

Projectsでは、標準フィールド以外にカスタムフィールドを追加できます。

フィールドタイプ 用途例
Text メモ、リンク
Number 見積もり工数、ストーリーポイント
Date 開始日、終了日
Single select 優先度、カテゴリ
Iteration スプリント、イテレーション

フィールドを追加するには、テーブルビューの右端にある「+」をクリックし、「New field」を選択します。

自動化(Workflows)

GitHub Projectsには、ビルトインの自動化機能があります。「Settings」から以下のワークフローを有効化できます。

ワークフロー 動作
Item added to project アイテム追加時にステータスを設定
Item reopened 再オープン時にステータスを変更
Item closed クローズ時にステータスを「Done」に変更
Pull request merged PRマージ時にステータスを「Done」に変更
Auto-add to project 特定条件のIssue/PRを自動追加

IssueとPull Requestの連携

キーワードによる自動クローズ

Pull RequestとIssueを連携させる最も便利な機能が、キーワードによる自動クローズです。PRの説明文やコミットメッセージに特定のキーワードとIssue番号を記述することで、PRがマージされた際にIssueを自動的にクローズできます。

使用可能なキーワードは以下のとおりです。

キーワード バリエーション
close close, closes, closed
fix fix, fixes, fixed
resolve resolve, resolves, resolved

同一リポジトリ内のIssue連携

同じリポジトリ内のIssueを参照する場合の記述例を示します。

1
2
3
4
5
## 変更内容
ログインフォームにバリデーションを追加しました。

## 関連Issue
Closes #42

複数のIssueをクローズする場合は以下のように記述します。

1
2
3
4
5
## 変更内容
認証機能の改善を行いました。

## 関連Issue
Closes #42, closes #45, closes #48

異なるリポジトリのIssue連携

異なるリポジトリのIssueを参照する場合は、完全な参照形式を使用します。

1
Fixes owner/repository#123

コミットメッセージでの連携

PRの説明文だけでなく、コミットメッセージでもIssueを参照できます。

1
2
3
git commit -m "Add password validation

Closes #42"

ただし、コミットメッセージで参照した場合、Issueはクローズされますが、PRとIssueのリンクは表示されません。PRの説明文での参照を推奨します。

手動でのリンク

キーワードを使わずにIssueに言及するだけの場合は、#42のように番号のみを記述します。この場合、自動クローズは行われませんが、IssueとPRが相互にリンクされます。

1
2
3
## 変更内容
#42 に関連するリファクタリングを行いました。
(このPRでは完全には解決しません)

Development セクションの活用

Issue画面右側の「Development」セクションでは、以下の操作が可能です。

  1. ブランチの作成: Issueから直接作業用ブランチを作成
  2. PRのリンク: 関連するPRを手動でリンク
  3. ステータス確認: リンクされたPR/ブランチの状態を確認

Issueからブランチを作成すると、ブランチ名が自動的に42-login-validationのような形式で生成され、IssueとPRの追跡が容易になります。

実践的なワークフロー例

個人プロジェクトでのタスク管理

個人プロジェクトでは、シンプルなワークフローを推奨します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
1. 機能やバグを Issue として登録
   ├─ ラベル: type: feature / type: bug
   └─ 優先度を設定(任意)

2. Project のカンバンで管理
   ├─ Backlog → In Progress → Done
   └─ 着手時に自分をアサイン

3. ブランチ作成とPR
   ├─ Issue から「Create a branch」
   ├─ 作業完了後に PR 作成
   └─ 説明文に「Closes #番号」

4. マージで自動クローズ

チーム開発でのワークフロー

チーム開発では、より構造化されたワークフローを採用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Sprint Planning:
├─ バックログからSprintに含めるIssueを選定
├─ マイルストーンを設定(例: Sprint 2026-01)
├─ 担当者をアサイン
└─ 見積もり(ストーリーポイント)を設定

Daily Work:
├─ Projectボードで自分のタスクを確認
├─ ステータスを「In Progress」に変更
├─ Issueからブランチを作成
├─ 実装・テスト
├─ PR作成(Closes #番号 を記載)
└─ レビュー後にマージ

Sprint Review:
├─ マイルストーンの進捗を確認
├─ 完了率、残タスクの確認
└─ 振り返りと次Sprintの計画

Issue テンプレートの設定

チームで一貫したIssue運用を行うために、テンプレートを設定することを推奨します。リポジトリに.github/ISSUE_TEMPLATE/ディレクトリを作成し、テンプレートファイルを配置します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# .github/ISSUE_TEMPLATE/bug_report.yml
name: Bug Report
description: バグの報告
labels: ["type: bug"]
body:
  - type: textarea
    id: description
    attributes:
      label: バグの概要
      description: 発生している問題を簡潔に説明してください
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: 再現手順
      description: バグを再現するための手順
      placeholder: |
        1. '...'に移動する
        2. '...'をクリックする
        3. エラーが発生する
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 期待される動作
    validations:
      required: true
  - type: textarea
    id: environment
    attributes:
      label: 環境情報
      placeholder: |
        - OS: Windows 11
        - ブラウザ: Chrome 120

注意点とベストプラクティス

Issue運用の注意点

注意点 説明
1 Issue 1 タスク 複数のタスクを1つのIssueにまとめない
適切な粒度 大きすぎるIssueは分割する
定期的な棚卸し 古いIssueは定期的にレビューしてクローズまたは更新
重複確認 新しいIssue作成前に類似のIssueがないか確認

ラベル運用のベストプラクティス

ベストプラクティス 説明
命名規則の統一 プレフィックス(type:、priority:等)で分類
色の一貫性 同じカテゴリのラベルは同系色に
説明の追加 ラベルの用途を説明文に記載
定期的な見直し 使われないラベルは削除または統合

Project運用のベストプラクティス

ベストプラクティス 説明
適切なビュー選択 目的に応じてBoard/Table/Roadmapを使い分け
WIP制限の意識 In Progressのアイテム数を制限する
フィルターの活用 担当者別、ラベル別のビューを作成
自動化の活用 ビルトインワークフローを有効化

PR連携の注意点

キーワードによる自動クローズは、デフォルトブランチへのマージ時のみ動作します。feature ブランチへのマージでは、キーワードがあってもIssueはクローズされません。

1
2
main ← feature-a : Closes #42 → Issueがクローズされる
develop ← feature-a : Closes #42 → Issueはクローズされない(developがデフォルトでない場合)

まとめ

本記事では、GitHub IssuesとProjectsを活用したタスク管理とプロジェクト運営について解説しました。

学んだ内容を振り返ります。

  1. GitHub Issues: タスク、バグ、機能要望を追跡・管理
  2. ラベル: Issueを分類・整理し、検索性を向上
  3. マイルストーン: リリース計画と進捗の可視化
  4. GitHub Projects: カンバンボードによる視覚的なタスク管理
  5. PR連携: Closes #番号でマージ時に自動クローズ

これらの機能を組み合わせることで、個人プロジェクトからチーム開発まで、効率的なプロジェクト運営が実現できます。まずは小規模なプロジェクトで試してみて、徐々にチームの運用に合わせてカスタマイズしていくことをお勧めします。

参考リンク