目次
GitHub Issuesとは？プロジェクト管理の基本ツール
「あのバグ、誰が対応するんだっけ？」「タスクの進捗が見えない」――プロジェクトを進める中で、こうした悩みを抱えていませんか？
GitHub Issuesは、バグ報告からタスク管理、機能要望まで、チームの「やるべきこと」を一元管理できるプロジェクト管理ツールです。GitHubのリポジトリに標準で備わっており、追加料金なしで今日から使い始められます。
この記事では、GitHub Issuesの基本的な使い方から、ラベルやマイルストーンを活用した実践的な管理手法まで、中小企業の開発チームがすぐに活用できる情報を解説します。
Issueの役割と管理できる情報
Issueとは、プロジェクトで対応すべきあらゆる事項を記録する単位です。具体的には以下のような情報を管理します：
- バグ（Bug）：システムの不具合や期待通りに動作しない問題。再現手順やエラーメッセージを含めて報告します。
- タスク（Task）：機能実装やテスト作業など、明確な作業単位として定義します。
- 機能リクエスト（Enhancement）：新機能の追加や既存機能の改善提案です。
各Issueには固有の番号（#1、#2…）が自動で割り振られ、コメント機能でチームメンバーと議論できます。「Open（未対応）」「Closed（完了）」のステータス管理により、誰が何をいつまでに対応するのかが可視化されます。
GitHub Issuesを使うメリット
情報の一元管理
バグ報告がメール、タスクがExcel、議論がチャット…という情報の散在を解消できます。すべてをGitHub上で管理することで、「あの情報どこだっけ？」という時間のロスがなくなります。
属人化の防止
誰がどのタスクを担当しているか、どんな議論があったかがすべて記録されます。担当者が不在でも、Issueを見れば経緯や現状が把握できます。
コードとの連携
コミットメッセージに「#12」とIssue番号を記載すれば、どのコード変更がどの課題に対応したものか一目瞭然です。プルリクエストと連携させれば、マージ時に自動的にIssueがクローズされます。
無料で始められる
パブリック・プライベートリポジトリともに無料プランで十分な機能が使えます。すでにGitHubを使っているなら、追加投資ゼロで始められます。
Issueの作成方法｜基本操作をステップで理解する
新規作成の手順
GitHub IssuesでIssueを作成する基本的な流れは以下の通りです。
- リポジトリの「Issues」タブをクリック
- 「New issue」ボタンをクリック
- タイトルと説明を入力
- オプション設定（担当者、ラベル、マイルストーン）
- 「Submit new issue」をクリック
作成されたIssueは即座にチームメンバーに共有され、通知設定によってはメールやSlack連携で通知されます。
タイトルと説明文の書き方
Issueの品質は、タイトルと説明文の明確さで決まります。後から見返した時に、誰が読んでも内容が理解できるよう工夫しましょう。
タイトルのポイント
- 簡潔かつ具体的に（50文字以内を目安）
- 動詞を含めてアクションを明確に
良い例：「ユーザー登録時のメールアドレス検証機能を追加」
悪い例：「バグ」「確認してください」
説明文のポイント
バグの場合は以下の情報を含めます：
## 現象
ログイン画面でパスワードを入力すると、画面が真っ白になる
## 再現手順
1. ログイン画面を開く
2. メールアドレスに「test@example.com」を入力
3. パスワードに「test1234」を入力
4. ログインボタンをクリック
## 期待される動作
ダッシュボード画面に遷移する
## 実際の動作
画面が真っ白になり、エラーメッセージも表示されない
## 環境
- ブラウザ：Chrome 120
- OS：Windows 11
タスクの場合は、目的・実装内容・受け入れ条件を明記します。Markdown記法を使えば、見出しやリスト、コードブロックで読みやすく整形できます。
担当者とテンプレートの活用
担当者（Assignees）の設定
Issue作成画面の右サイドバーから担当者を選択します。担当者未設定のIssueは放置されがちなので、作成時に必ず設定しましょう。複数人アサインは責任の所在が曖昧になるため、メイン担当者を1名決めるのが基本です。
テンプレートで入力を効率化
Issueテンプレートを設定すれば、記入項目があらかじめ用意された状態でIssueを作成できます。リポジトリの「Settings」→「Features」→「Set up templates」から、バグ報告や機能リクエストなどのテンプレートを作成できます。
ラベル（Labels）でIssueを分類・整理する
Issueが増えてくると、「どれが優先度高いのか」「バグとタスクが混在して見づらい」といった課題が出てきます。そこで活用するのがラベル機能です。
ラベルの役割と基本的な使い分け
ラベルは、Issueに付ける色付きのタグです。種類、優先度、ステータスなど、さまざまな軸で分類できます。
GitHubのリポジトリには、デフォルトで以下のラベルが用意されています：
- bug（赤）：バグや不具合の報告
- enhancement（青）：新機能や機能改善の提案
- documentation（水色）：ドキュメントの追加・修正
- question（ピンク）：質問や議論が必要な事項
ラベルを付けることで、Issue一覧を見た時に視覚的に情報が整理され、必要なIssueを素早く見つけられます。
カスタムラベルの作成と運用
デフォルトのラベルだけでは不十分な場合、カスタムラベルを作成できます。リポジトリの「Issues」タブから「Labels」→「New label」で、ラベル名・説明・色を設定します。
運用例：優先度ラベル
priority: high（赤）
priority: medium（オレンジ）
priority: low（緑）
運用例：ステータスラベル
status: in progress（黄色）
status: review needed（青）
status: blocked（グレー）
ラベル設計のコツ
- 10〜15種類程度に抑える
- 「priority:」「status:」のようにプレフィックスを付けて命名規則を統一
- 色を意味と連動させる（赤=緊急、緑=低優先など）
フィルタリングで効率的に管理
ラベルの真価は、フィルタリング機能と組み合わせた時に発揮されます。Issue一覧画面の検索ボックスに以下のように入力します：
label:bug
→ bugラベルが付いたIssueのみ表示
label:bug label:"priority: high"
→ bugかつhigh priorityのIssueのみ表示
assignee:@me label:"status: review needed"
→ 自分が担当していて、レビュー待ちのIssueのみ表示
頻繁に使う検索条件は、ブラウザのブックマークに保存しておくと便利です。URLに検索条件が含まれているため、ワンクリックで目的のIssue一覧を表示できます。
マイルストーン（Milestones）で進捗を可視化する
マイルストーンは、複数のIssueをグループ化する目標単位です。プロジェクトの節目やリリースバージョンと紐付けて使います。
マイルストーンの設定方法と活用
マイルストーンの用途
- バージョンリリース（v1.0、v2.0など）
- 開発フェーズ（α版、β版、正式版）
- 期間区切り（2024年Q1、第1スプリントなど）
リポジトリの「Issues」タブから「Milestones」→「New milestone」をクリックし、タイトル・期限・説明を入力します。Issue作成時または編集時に、右サイドバーの「Milestone」から選択して紐付けます。
進捗率の自動計算
マイルストーン画面では、進捗率が自動計算されて表示されます。
表示される情報：
- Open（未完了）のIssue数
- Closed（完了）のIssue数
- 進捗率（パーセンテージ）
- 期限までの残り日数
Issueをクローズするだけで自動的に進捗率が更新されるため、リアルタイムで最新状況を反映できます。Excelやスプレッドシートと違い、更新忘れがありません。
小規模チームでの活用事例
事例1：月次リリースを行う3名の開発チーム
毎月のマイルストーンを作成し、その月に対応する機能追加やバグ修正のIssueを紐付けます。月末に進捗を確認し、未完了のIssueは翌月に繰り越すかどうかを判断します。
事例2：社内システムの段階的改善
フェーズごとにマイルストーンを設定：
- フェーズ1：基本機能の実装
- フェーズ2：ユーザビリティ改善
- フェーズ3：レポート機能追加
経営層への報告時にも、「フェーズ1は80%完了しています」と視覚的に示せます。
コミットやプルリクエストとIssueを連携させる
GitHub Issuesの真価は、コードの変更履歴とタスクを自動的に紐付けられる点にあります。
コミットメッセージでIssueを参照
コミット時にIssue番号を含めるだけで、GitHubが自動的にリンクを作成します。
git commit -m "ログイン画面のレイアウト崩れを修正 #45"
このコミットをプッシュすると、Issue #45のタイムラインに「このコミットで対応されました」という記録が自動的に追加されます。
プルリクエストで自動クローズ
プルリクエストの説明文に以下のキーワードとIssue番号を書くと、マージ時に自動的にIssueがクローズされます。
ログイン機能のバグを修正しました。
fixes #67
自動クローズのキーワード
closes #123fixes #123resolves #123
複数のIssueを一度にクローズすることも可能です。
連携のメリット
作業履歴が自動で残る
誰がどのコードでバグを修正したか一目瞭然になります。本番環境で問題が発生した場合、関連するIssueを見れば、どういう経緯で実装されたか、誰が担当したか、どのコミットで変更されたかがすべて確認できます。
属人化を防ぐ
担当者が退職や異動で不在になっても、Issue履歴を見れば過去の議論や実装理由がわかり、新しい担当者がスムーズに引き継げます。
リリースノートの作成が簡単
特定の期間にクローズされたIssueを一覧表示すれば、リリース内容をすぐに把握できます。
Issueのステータス管理とクローズのタイミング
Issueには「Open（未完了）」と「Closed（完了）」の2つのステータスがあります。適切に管理することで、チームの作業状況が常に可視化されます。
OpenとClosedの使い分け
Openにするタイミング
- 新しいバグを発見したとき
- 新機能の実装タスクを作成したとき
- 調査が必要な問題が発生したとき
Closedにするタイミング
チーム内で「完了」の定義を統一することが重要です。
- コードを書いたらクローズ？
- レビューが通ったらクローズ？
- 本番環境にデプロイしたらクローズ？
小規模チームなら「本番環境にリリースしたらクローズ」というシンプルなルールで十分です。
クローズ方法と再オープン
手動クローズ
Issue画面の下部にある「Close issue」ボタンをクリックします。クローズ時にコメントを残すことで、「なぜクローズしたのか」が記録されます。
自動クローズ
プルリクエストの説明文に「closes #123」と書くと、マージ時に自動的にクローズされます。
再オープンが必要なケース
- バグが再発した場合
- 対応が不完全だった場合
- 対応不要と判断したが、後で必要になった場合
クローズされたIssueを開き、「Reopen issue」ボタンをクリックして、再オープンの理由をコメントで追記します。
長期間Openのまま放置されるIssueへの対処
月に1回、または四半期に1回、Open Issueを見直す時間を設けましょう。
対処パターン
- 対応不要になった場合：理由をコメントしてクローズ
- 優先度が低く当面対応しない場合：
将来対応ラベルを付ける - 情報が不足している場合：
情報不足ラベルを付け、追加情報を依頼
GitHub Issuesの検索機能を使えば、長期間OpenのままのIssueを簡単に抽出できます。
is:open created:<2024-01-01
中小企業がGitHub Issuesを活用するためのヒント
GitHub Issuesは、大規模な開発プロジェクトだけのツールではありません。3名程度の小規模チームでも十分に効果を発揮します。重要なのは、「完璧な運用」を目指すのではなく、チームにとって”ちょうどいい”使い方を見つけることです。
ITに詳しくないチームでも始められる理由
必要なのは基本的なPC操作だけ
- Webブラウザが使える
- 文章を入力できる
- ボタンをクリックできる
これだけで、Issueの作成・編集・コメント・クローズといった基本操作はすべて行えます。プログラミング知識は一切不要です。
段階的に機能を増やせる
最初はIssueを作成してコメントでやり取りし、完了したらクローズするだけでOK。慣れてきたらラベルで分類、さらに活用するならマイルストーンやプロジェクトボードを追加していけば、無理なく定着します。
Excel管理からの移行ポイント
移行のステップ
- 既存のタスクをIssueとして登録：Excelに記載されている未完了のタスクを、一つずつIssueとして作成します。
- 並行運用期間を設ける：1〜2週間はExcelとGitHub Issuesを並行運用し、チームメンバーが操作に慣れる期間を確保します。
- Excelを参照用にアーカイブ：チーム全員が問題なく使えるようになったら、Excelは「過去の記録」として保存し、日常的な更新は停止します。
移行時のポイント
- 完璧を目指さない：完了済みのタスクは移行せず、未完了分だけでOK
- シンプルに始める：最初はラベルやマイルストーンを使わず、タイトルと説明文だけでもOK
- チーム全員で決める：一人が勝手に移行するのではなく、チームで合意してから進める
運用ルールをシンプルに保つコツ
最小限のルールから始める
最初に決めるべきルールは、以下の3つだけで十分です：
- どんなときにIssueを作るか（例：バグを見つけたとき、新機能を実装するとき）
- いつクローズするか（例：本番環境にリリースしたとき）
- 誰が確認するか（例：毎週月曜の朝に、チーム全員でIssue一覧を確認）
ラベルは5〜10種類まで
ラベルが多すぎると、「どれを選べばいいか」迷います。小規模チームにはバグ、機能追加、改善、質問、優先度：高の5種類程度で十分です。
定期的にルールを見直す
3ヶ月に1回、ルールを見直しましょう。使われていないラベルは削除し、形骸化したルールは廃止します。「守れるルール」だけを残すのが、長続きの秘訣です。
「ちょうどいい仕組み」を作るために
目的を明確にする
「なぜGitHub Issuesを導入するのか」をチーム全員で共有します。タスクの抜け漏れを防ぎたい、誰が何をしているか見える化したい、過去の対応履歴を残したい――目的が明確なら、どの機能を使うべきかも自然と決まります。
チーム全員で決める
ツールや運用ルールを一人で勝手に決めないことが重要です。チーム全員でツールを試し、使いやすさを話し合い、運用ルールを一緒に決めましょう。「押し付けられた」と感じると、定着しません。
小さく始めて、段階的に広げる
最初から完璧を目指さず、小さく始めて徐々に拡大します。最初は1つのプロジェクトだけで試し、うまくいったら他のプロジェクトにも展開します。失敗したら、やり方を見直せばOKです。
GitHub Issuesは、チームの「やるべきこと」を可視化し、情報の散在を防ぎ、属人化を解消する強力なツールです。無料で今日から始められるので、まずは小さく試してみることをおすすめします。
