こんにちは、かつコーチです。
チーム開発では、「誰が」「何を」「いつまでに」やるのかを見える化することがとても重要です。
その役割を担うのが、GitHubのIssueという機能です。
この記事では、Issueの基本的な使い方と、コードとの結びつけ方を解説します。
読み終える頃には、自分のプロジェクトでもIssueを使ってタスクを管理できるようになります。
Issueとは？
Issue＝共有できる付箋・To Doリスト
Issueとは、GitHub上でバグ報告や機能要望、やるべきタスクなどを1件ずつ記録しておける機能です。
たとえるなら、Issueは「共有の付箋」や「みんなで見られるTo Doリスト」のようなものだとイメージしてください。
紙の付箋であれば、自分の机にしか貼れませんが、GitHubのIssueはチーム全員が見える場所に貼り出されます。
「ログイン画面でエラーが出る」「READMEに手順を追記する」といった課題を1枚の付箋（Issue）として書き出しておけば、誰が見ても「今どんなタスクが残っているか」が一目でわかるようになります。
なぜIssueが必要なのか
口頭やチャットだけでタスクを共有していると、「言った・言わない」のすれ違いが起きたり、対応漏れが発生したりしがちです。
Issueとしてリポジトリに記録しておけば、タスクの一覧性が高まり、対応状況（未対応・対応中・完了）も管理しやすくなります。
また、後から「なぜこの実装になったのか」を振り返る際にも、Issueでのやり取りが貴重な記録として残ります。
Issueの基本的な使い方
手順1：Issueを作成する
GitHubのリポジトリ画面から「Issues」タブを開き、「New issue」ボタンを押すと作成できます。
タイトルには課題を一言で、本文には詳細な状況や再現手順を書きます。
GitHub CLI（ghコマンド）を使っている場合は、ターミナルからもIssueを作成できます。
gh issue create --title "ログイン画面でパスワードエラーが表示される" \
--body "パスワード欄に8文字未満を入力するとエラーメッセージが出ない"
手順2：ラベル・担当者を設定する
作成したIssueには、「bug」「enhancement」といったラベルや、対応する担当者を設定できます。
これは、付箋に「緊急」「あとで」といった色分けをしたり、「これは〇〇さん担当」と書き込んだりする作業に相当します。
手順3：コミットメッセージでIssueと紐づける
コミットメッセージの中で#とIssue番号を書くと、そのコミットとIssueが自動的にリンクされます。
git add .
git commit -m "パスワードのバリデーションを修正 (#12)"
git push origin main
さらに、コミットメッセージにFixes #12のように書いてPull Requestがマージされると、対応するIssue（#12）は自動的にクローズされます。
git commit -m "Fixes #12: パスワードのバリデーションを修正"
これは、付箋の課題を解決したときに、その付箋を自動的にTo Doリストから外してくれるようなイメージです。
つまずきやすい設定・注意点
Fixes #12のような自動クローズのキーワードは、Pull Requestの本文やコミットメッセージに書く必要があり、単なるコメントに書いても自動では反映されません。
自動クローズさせたい場合は、キーワード（Fixes・Closes・Resolvesなど）とIssue番号のセットを忘れずに含めましょう。
よくあるつまずきポイント・エラー対処
Issue番号を書いたのにクローズされなかった話
私が実際にチーム開発の練習中につまずいたのが、このケースでした。
❌ Before
Pull Requestの本文に「#12の対応」とだけ書いてマージしたのですが、対応していたはずのIssue #12は開いたままになっていました。
付箋を片付けたつもりが、To Doリストにはまだ残ったままの状態だったのです。
✅ After
調べてみると、GitHubがIssueを自動でクローズしてくれるのは、Fixes・Closes・Resolvesなどの決まったキーワードとIssue番号がセットになっている場合だけだとわかりました。
Fixes #12
Closes #12
Resolves #12
単に番号を書いただけでは「関連づけ」はされますが、「自動クローズ」まではされません。
改めてPull Requestの本文をFixes #12に書き直したところ、マージと同時にIssueが自動でクローズされました。
この経験から、Issueとの連携には決まったキーワードがあることを覚えておく大切さを学びました。
応用・一歩先の使い方
Projectsと組み合わせてタスクを見える化する
IssueはGitHubの「Projects」機能と組み合わせることで、カンバンボードのように「未着手」「対応中」「完了」といったステータスごとに整理できます。
付箋（Issue）をボード上で動かしながら管理できるイメージで、チーム全体の進捗が一目でわかるようになります。
テンプレートで報告の質を揃える
.github/ISSUE_TEMPLATE/にテンプレートファイルを用意しておくと、Issue作成時に決まったフォーマット（再現手順・期待する動作など）を表示させることができます。
バグ報告のたびに書く内容がバラバラにならず、チーム内での情報共有がスムーズになります。
まとめ
この記事のポイント
- Issueとは、GitHub上で共有できる「付箋・To Doリスト」のような機能
- ラベルや担当者を設定することで、タスクの状況を管理しやすくなる
- コミットメッセージに
Fixes #12のように書くと、Issueと自動的に連携できる - 自動クローズには
Fixes・Closes・Resolvesなどの決まったキーワードが必要
次に読むべき記事
Issueで課題を見える化できたら、次はその課題を解決する変更を提案する方法を学びましょう。
「Pull Requestの基本：変更を提案し取り込んでもらう流れ」で、実際の提案手順を解説しています。