スキルアップカレッジ Issue とプロジェクト管理——タスクとコードを結ぶ
レッスン6：Issue とプロジェクト管理——タスクとコードを結ぶ
このレッスンで学ぶこと
- Issue の役割と典型的な使い方を整理する
- ラベル・マイルストーン・アサインで分類する
- GitHub Projects でタスク管理を行う発想を持つ
- Issue と PR の連携の仕組みを理解する
- Issue Template（テンプレート）を使う発想を持つ
- 「タスクとコードを結ぶ」開発スタイルを把握する
前のレッスンでは、PR とコードレビューでチーム開発のリズムを掴みました。今回のレッスンでは、視点を「コード」から「タスク」に広げて、Issue と GitHub Projects を扱います。「やるべきこと」を整理し、それをコード変更とつなぐのが現代の開発スタイルです。
Issue とは何か
GitHub の「Issue」は、リポジトリに対する「やるべきこと」や「気になること」を記録する仕組みです。
Issue の典型的な用途
- バグ報告：動かない、想定と違う挙動の報告
- 機能要望：「こんな機能がほしい」
- タスク：実装すべき作業の計画
- 質問：使い方の確認
- ディスカッション：仕様の議論
- メモ：将来見直したいこと
GitHub の Web 画面の「Issues」タブで、リポジトリの Issue 一覧が表示されます。
Issue の構成要素
- タイトル：何についての Issue か
- 本文：詳細（Markdown 記法）
- コメント：誰でも追加できる返信
- Assignees：担当者
- Labels：分類用のラベル
- Milestone：マイルストーン（後述）
- Projects：関連するプロジェクト
- 状態：Open（未解決）／Closed（解決）
Issue の作成手順
- GitHub のリポジトリページ → 「Issues」タブ
- 「New issue」をクリック
- タイトルと本文を記入
- 必要に応じて Assignees・Labels などを設定
- 「Submit new issue」をクリック
💡 ポイント Issue は単なる「タスクリスト」ではなく、コードに紐づく「議論の記録」でもあります。後から見返したときに「なぜこの変更をしたか」を辿る手がかりになります。
ラベル・マイルストーン・アサイン
Issue は数が増えると、整理が必要になります。GitHub には 3 つの分類機能が用意されています。
ラベル（Labels）
Issue のカテゴリを表す色付きのタグです。リポジトリごとに自由に作成できます。
GitHub のデフォルトラベル：
| ラベル | 意味 |
|---|---|
| bug | バグ |
| documentation | ドキュメント関連 |
| duplicate | 重複 |
| enhancement | 機能追加・改善 |
| good first issue | 新規参加者向けの簡単な課題 |
| help wanted | 助けを求める |
| invalid | 不適切 |
| question | 質問 |
| wontfix | 対応しないと決定 |
組織で独自のラベル（priority-high、area-frontend、needs-review など）を追加するのも一般的です。
マイルストーン（Milestones）
複数の Issue や PR をまとめる「区切り」です。リリースバージョン、四半期目標、特定イベントなどに使います。
例：
v1.0.0 リリース2026 Q3 目標カンファレンス前リリース
マイルストーンを設定すると、進捗率（クローズ済み Issue の割合）が自動表示されます。
アサイン（Assignees）
Issue の担当者を指定します。1 つの Issue に複数人をアサインできます。
「誰がやるか」が明確になり、進捗管理しやすくなります。
📝 補足 「ラベルは分類」「マイルストーンは時期の区切り」「アサインは担当者」の役割を分けて使うのが基本です。3 つを組み合わせると、Issue が整理されます。
GitHub Projects
GitHub Projects は、リポジトリ横断・組織レベルでタスクを管理する「カンバンボード」のような機能です。2022 年に新しいバージョン（「Projects」または「Projects v2」と呼ばれる）が一般提供開始されました。
Projects の基本
- 複数のリポジトリの Issue や PR を集約
- ボード（カンバン）、テーブル、ロードマップなど複数のビューが選べる
- カスタムフィールド（優先度、見積、作業時間など）を追加できる
- 自動化（特定の Issue を自動で列に移動など）が可能
ボードビューの例
| Todo | In Progress | Review | Done |
| Issue #1: ... | Issue #5: ... | PR #12: ... | Issue #3: ... |
| Issue #2: ... | Issue #7: ... | PR #15: ... | Issue #8: ... |
| Issue #6: ... | | | |カードを左から右へドラッグして、進捗を可視化します。
Projects の使いどころ
- スプリント（短期の作業期間）の進捗管理
- 製品ロードマップ
- チーム横断のタスク管理
- 個人のタスクリストとしても
設定の手順
- GitHub の組織またはユーザーページ →「Projects」タブ
- 「New project」をクリック
- テンプレート（Board、Table、Roadmap）を選択
- リポジトリと連携、Issue・PR を追加
- カラム（列）を設定
💡 ポイント Projects は強力ですが、最初は overengineering（過剰設計）になりがちです。シンプルに「Todo / In Progress / Done」の 3 列から始めて、必要に応じて拡張するのが推奨です。
Issue と PR の連携
GitHub の強みの 1 つが、「Issue と PR の連携」です。タスク（Issue）とコード変更（PR）が自動的に結びつきます。
自動クローズの記法
PR の本文または commit メッセージに、特定のキーワード + Issue 番号を書くと、PR がマージされたときに対応する Issue が自動的にクローズされます。
| キーワード |
|---|
| close、closes、closed |
| fix、fixes、fixed |
| resolve、resolves、resolved |
例：
このプルリクエストは、お問い合わせフォームの実装を含みます。
Closes #42
Fixes #43PR がマージされると、Issue #42 と #43 が自動でクローズされます。
Issue 番号での参照
PR や Issue の本文に #42 と書くと、自動的に Issue #42 へのリンクになります。「クローズしないけど関連がある」場合に使います。
これは #42 と関連する変更です。詳細は #42 を参照してください。ブランチ名と Issue の連携
ブランチ名に Issue 番号を含めるのも、業務でよく使われるパターンです。
feature/42-add-contact-form
fix/43-button-style
issue-42ブランチ名から Issue がたどれると、レビュー時に「これは何の作業か」がすぐにわかります。
⚠️ 注意 Issue 番号でのリンクは、リポジトリ内では
#42で済みますが、別リポジトリの Issue を参照するときはowner/repo#42のように省略しない形にします。
Issue Template
リポジトリで Issue を作るたびに、毎回ゼロから本文を書くのは大変です。GitHub には「Issue Template（テンプレート）」という仕組みがあります。
テンプレートの仕組み
リポジトリの .github/ISSUE_TEMPLATE/ フォルダに、Markdown ファイルとして用意します。
例：.github/ISSUE_TEMPLATE/bug_report.md
---
name: バグ報告
about: バグを報告する
title: '[BUG] '
labels: bug
assignees: ''
---
## 何が起きたか
（詳しく）
## 期待される動作
（こうあるべき）
## 再現手順
1.
2.
3.
## 環境
- OS:
- ブラウザ:
- バージョン:リポジトリにこのファイルがあると、Issue 作成時に「バグ報告」テンプレートを選べるようになり、本文が自動的に埋まります。
典型的なテンプレート
- バグ報告：再現手順・期待動作・環境
- 機能要望：困っていること・提案・代替案
- 質問：状況・知りたいこと
PR にも Pull Request Template（.github/PULL_REQUEST_TEMPLATE.md）があり、同様にテンプレ化できます。
💡 ポイント テンプレートは「書くべきことのチェックリスト」として機能します。新人や外部の人が Issue を書くときの迷いが減り、Issue の質が安定します。
タスクとコードを結ぶ開発スタイル
ここまでの内容を踏まえて、「タスクとコードを結ぶ」現代の開発スタイルを整理します。
典型的な流れ
- Issue を作成（「何をやるか」を明示）
- Issue にラベル・マイルストーン・担当者を設定
- 担当者がブランチを作成（ブランチ名に Issue 番号を含める）
- ブランチで作業・commit
- PR を作成（本文に「Closes #N」を書く）
- レビュー → マージ
- Issue が自動クローズ
この流れにより、「いつ・誰が・何を・なぜ」がすべて GitHub 上に残ります。後から「なぜこのコードがあるか」を辿るときの強力な記録になります。
「Issue ファースト」の発想
- 思いついたタスクは、すぐに Issue にする
- 「ちょっとした修正」も Issue 経由が望ましい
- PR を作る前に Issue で議論することも
業務での開発成熟度の差は、「Issue ファースト」がどこまで浸透しているかに表れることが多いです。
個人プロジェクトでも有効
- 「あとでやる」リストとしての Issue
- 学習中の「わからない点」のメモ
- 制作物の改善アイディア
個人開発でも Issue を活用すると、頭の中のタスクが GitHub に外出しされ、忘れにくくなります。
📝 補足 「Issue を作る習慣」「PR を作る習慣」「ブランチ名に Issue 番号を含める習慣」の 3 つが揃うと、開発のリズムが大きく整います。
講師の現場メモ：「Issue 文化で議論が記録に残った組織」
私（青木）が支援している中堅 IT 企業の話です。20 人の開発チームで、議論はチャットツールで行われ、決定事項は誰も記録しないまま流れていました。3 か月後に「なぜこういう実装になっているのか」を聞くと、誰も答えられない、ということが頻発していました。
私はリーダーに「Issue を議論の場として使ってみませんか」と提案しました。リーダーは「チャットで十分」と最初は懐疑的でしたが、3 か月のトライアルに同意しました。
ルールはシンプルでした。
- 仕様変更を伴う議論は、Issue を立てて行う
- チャットでの議論も、結論を Issue にコピーする
- 決定事項は Issue にコメントとして残す
- PR と Issue を必ずリンクする
3 か月後の振り返りで、
- 「なぜこの実装か」を Issue で辿れるようになった
- 新メンバーが「過去の議論を読んで自分でキャッチアップできる」と漏らした
- チャットで結論が流れることがなくなった
- レビュー時に「この決定の背景は #42 で議論された」と参照できるように
リーダーは「Issue は単なるタスクリストではなく、組織の記憶装置だった」と振り返りました。
そのときに痛感したのは、Issue 文化は「ツール導入」ではなく「組織の知識管理」だ、ということです。チャットは流れていくが、Issue は残ります。
本コースで Issue を 1 レッスン分扱うのは、皆さんの組織にも「組織の記憶装置」としての Issue の使い方を持ち帰っていただきたいからです。
まとめ
このレッスンでは、以下のことを学びました。
- Issue はリポジトリに対する「やるべきこと」「気になること」を記録する仕組み
- 用途：バグ報告、機能要望、タスク、質問、ディスカッション、メモ
- ラベル（カテゴリ）、マイルストーン（時期の区切り）、Assignees（担当者）で分類
- GitHub Projects はカンバンボードのようなタスク管理。リポジトリ横断・組織レベルで使う
- Issue と PR の連携：「Closes #42」「Fixes #43」で自動クローズ、
#42でリンクのみ - ブランチ名に Issue 番号を含めるのが業務での定番（
feature/42-add-contact-formなど） - Issue Template（
.github/ISSUE_TEMPLATE/）でテンプレ化、品質と統一感が上がる - PR Template（
.github/PULL_REQUEST_TEMPLATE.md）でも同様 - 「Issue → ブランチ → PR → マージ → Issue 自動クローズ」が現代の開発リズム
- 「Issue ファースト」の発想：思いついたら Issue、ちょっとした修正も Issue 経由
- 個人プロジェクトでも有効：あとでやるリスト、わからない点のメモ、改善アイディア
次のレッスンでは、GitHub Actions と Pages で自動化と公開の入口に立ちます。
確認クイズ
このレッスンの理解度をチェックしましょう。