前回（VS CodeでGitを使いこなす マージ・コンフリクト・便利機能）では、VS Codeを使った開発の進め方を解説しました。
第5回となる今回は、コードを書く前の「何を作るか？（タスク管理）」に焦点を当てます。
コードとタスクを別々のツールで管理していませんか？
GitHubの Issue（イシュー） と Projects（プロジェクト） を使ってこれらを統合管理することで、開発の文脈（Context）が失われず、チームの開発生産性が劇的に向上します。
GitHub入門シリーズ 全10回
本記事は「GitHub入門」全10回のNo.5です。
- No.1：Git/GitHubの基本概念とGitHub導入による投資対効果(ROI)
- No.2：リポジトリとREADMEから始める
- No.3：変更を確定！コミット実行とコミットメッセージの書き方
- No.4：VS CodeでGitを使いこなす マージ・コンフリクト・便利機能
- No.5：Issue（イシュー）でタスク管理
- No.6：Pull Request（PR）とコードレビュー
- No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow
- No.8：GitHub Actions CI/CDで自動化
- No.9：Code Scanning・Dependabot セキュリティの自動化
- No.10：なぜGitHubが高パフォーマンスチームを作るのか
今回のゴール
- GitHub Issueでタスクを作成・管理するメリットを知る
- そのまま使えるテンプレートを活用して、抜け漏れなくタスクを定義する
- 「Epic > Story > Task」の3階層でタスクを適切に分解する
- GitHub Projects（カンバン）でチームの進捗を可視化する
なぜIssueで管理するのか？
GitHub Issueを使う最大のメリットは、「コード」と「タスク」が相互にリンクすることです。
これにより、単にタスクが見やすくなるだけでなく、情報がGitHubに一元管理され、「チームのナレッジ資産」として蓄積されていきます。
-
文脈の追跡:
コードの変更履歴から「なぜこの変更をしたのか（Issue）」へ1クリックで辿れます。「なぜこういう実装にしたんだっけ？」という疑問も、Issueに残された議論を見れば即座に解消します -
属人化の解消と育成スピード向上:
チャットツールで流れてしまう情報や、個人のメモ帳にある情報は他人には見えません。
すべての経緯をIssueに残すことは、第1回で解説した「ナレッジ共有：属人化の解消と育成スピード」に直結します。新しく入ったメンバーも、過去のIssueを検索するだけで仕様や決定プロセスを学べるため、古参メンバーへの質問コストが下がり、自走できるまでの期間が短縮されます
実践：テンプレートを活用してIssueを作ろう
GitHubには、用途に合わせてIssueのテンプレートを用意する機能があります。
「何を書けばいいかわからない」を防ぐため、以下の3パターンを用意しておくと便利です。
以下の内容をコピーし、リポジトリの .github/ISSUE_TEMPLATE/ フォルダ内に保存するだけで、Issue作成時に選択できるようになります。
また、自動的に適切なラベルが付与される設定も含まれています。
機能開発（Feature）テンプレート
実装する機能のゴールを明確にするためのテンプレートです。
ファイル名: .github/ISSUE_TEMPLATE/feature_request.md
---
name: 機能リクエスト (Feature Request)
about: 新機能の追加や改善を提案します
title: "[Feature] "
labels: ["enhancement"]
assignees: ''
---
## 目的
## 内容
## 完了条件
- [ ]
- [ ]
バグ報告（Bug）テンプレート
不具合報告に必要な情報を網羅し、手戻りを防ぎます。
ファイル名: .github/ISSUE_TEMPLATE/bug_report.md
---
name: バグ報告 (Bug Report)
about: 不具合を報告し改善を促します
title: "[Bug] "
labels: ["bug"]
assignees: ''
---
## 概要
## 再現手順
1.
2.
3.
## 期待する挙動
## 実際の挙動
## 環境
- OS:
- Browser:
調査・質問（Investigation）テンプレート
実装可否の調査や、技術選定など、コードを書く前のタスク用です。
ファイル名: .github/ISSUE_TEMPLATE/investigation.md
---
name: 調査・質問 (Investigation)
about: 実装前の調査や技術的な質問を行います
title: "[Investigate] "
labels: ["investigation"]
assignees: ''
---
## 調査したいこと
## 調査の背景
## ゴール（Output）
- [ ]
- [ ]
「Epic > Story > Task」でタスク分解する
大きな機能を開発する場合、いきなりコードを書き始めるのではなく、「タスク分解」を行うことが成功の鍵です。
GitHubの Sub-issues（サブイシュー） 機能や Labels（ラベル） を活用し、以下の3階層で整理することをお勧めします。
-
Epic（エピック）: 大きな機能単位
- ラベル例:
Epic - 例：「ログイン・認証機能」
- ラベル例:
-
Story（ストーリー）: ユーザー視点の価値
- ラベル例:
Story - 例：「ユーザーはメールアドレスでログインできる」
- ラベル例:
-
Task（タスク）: 具体的な実装作業（数時間〜1日）
- ラベル例:
Task - 例：「□□APIのフィルターを実装」「DBスキーマの変更」「◯◯画面の△△ボタンを実装」
- ラベル例:
タスク分解のメリット
このように階層化してタスクを分解することには、大きなメリットがあります。
-
進捗の見える化:
漠然と「進捗80%」と言うのではなく、「5つのTaskのうち4つ完了した」とTask単位で進捗が見える化されるため、遅延やブロッカーに早期に気付けます -
見積もり精度の向上:
「DB設計」「API実装」のようにTaskレベルまで分解すると、作業時間が具体的にイメージできるため、見積もりの精度が格段に上がります -
抜け漏れの防止:
実装前にタスクを洗い出すことで、「あ、バリデーションのエラー表示忘れてた」といった考慮漏れに事前に気づくことができます
【コツ】Taskは「細かければ細かいほど良い」
Task分解のコツは、「1つのTaskに複数の観点を混ぜない」ことです。
- ❌ 悪い例：「検索フィルターとソート条件を実装」
- 1つのタスクの中で「検索フィルター」のタスクと「ソート条件」のタスクが混じってしまい、両方が完了しないとタスクが完了になりません。2つのことを同時に考える必要があり、認知負荷が高まります
- ⭕ 良い例：「検索フィルター実装」「ソート条件実装」
- 観点ごとに分けることで、やるべきことが明確になり、達成感も得やすくなります
GitHub Projectsで進捗を「見える化」する
分解したタスクの進捗状況をチームで共有するために、GitHub Projects を使います。
これはホワイトボードに付箋を貼るような「カンバン方式」で管理できる機能です。
プロジェクトボードの作成と活用
- リポジトリ上部の「Projects」タブから「New project」を選択し、「Board」テンプレートで作成します
- 作成したIssueを追加し、「Todo」「In Progress」「Done」のカラムで管理します
おすすめ機能：担当者ごとのグルーピング
Projectsには強力なグルーピング機能があります。
ビューの設定で「Group by: Assignees」を選択してみてください。
すると、カンバンボードが担当者ごとのスイムレーンに切り替わります。
「Aさんはタスクを抱えすぎているな」「Bさんは手が空いていそうだな」といった負荷状況が一目でわかり、チームの助け合いが加速します。
【導入効果】
朝会や定例MTGでこのボードを画面共有するだけで、「誰が何に着手しているか」が一目瞭然になります。
「進捗どうですか？」と一人ずつ聞くだけの時間が削減され、困っていることの相談に時間を使えるようになります。
まとめ
今回は、チーム開発の要となるIssue管理とタスク分解について解説しました。
- Issue管理: ナレッジを蓄積し、属人化を解消する
- テンプレート: 機能・バグ・調査など用途に合わせて項目とラベルを自動定義する
- タスク分解: Epic > Story > Taskの階層で整理し、進捗を見える化する
- Projects: 担当者ごとの状況を可視化し、チームの連携を強化する
タスクが明確になったら、次はいよいよコードを書いてチームに共有・承認をもらうフェーズです。
次回は、GitHub開発サイクルの花形である 「Pull Request（プルリクエスト）」 と 「コードレビュー」 について解説します。