Skip to main content

Issueとチーム開発実践

この章で得られるスキル：

  • ✅ GitHub Issueの作成方法と活用方法を説明できる
  • ✅ Issue駆動開発の流れを説明できる
  • ✅ Closes #番号 でPRとIssueを紐づけられる
  • ✅ GitHub Flowの全体像を説明できる
  • ✅ ペアでIssue → ブランチ → PR → レビュー → マージの一連の流れを実践できる

Step 0: まず体験してみよう​

シナリオ：チームで「何をやるか」がわからない​

チーム開発が始まった。メンバーは3人いるが、以下の問題が起きている。

  • Aさん：「何から手を付ければいいんだろう？」
  • Bさん：「この機能、もう誰かやってるのかな？」
  • Cさん：「バグを見つけたけど、どこに報告すればいいんだろう？」

→ 各自がバラバラに作業していて、 誰が何をしているかわからない 状態である。

重要

チーム開発の失敗原因の多くは、技術的な問題ではなく 「コミュニケーション」と「タスク管理」の不備 である。 「誰が何をいつまでにやるか」を明確にする仕組みが必要である。

→ GitHub Issue を使えば、タスクの管理・分担・進捗の可視化ができる。 この章では、Issueを中心としたチーム開発の進め方を学ぶ。

Step 1: GitHub Issue とは​

Issueの役割​

Issue（イシュー） とは、GitHub上でタスク・バグ・機能要望などを管理する仕組みである。

「チームの TODO リスト」と考えるとわかりやすい。

Issueの用途例
機能追加「割り算メソッドを追加する」
バグ報告「0で割ったときにエラーが出る」
改善提案「READMEに使い方を追記する」
質問・議論「メソッド名はどちらがよいか？」

Issueの作成手順​

  1. GitHubのリポジトリページで「Issues」タブを開く
  2. 「New issue」ボタンをクリック
  3. 以下の情報を入力する
項目説明例
Title何をするかを簡潔に「割り算メソッドを追加する」
Description詳細や背景「四則演算の機能を完成させるため、divideメソッドを追加する。ゼロ除算のチェックも含める」
Assignees担当者Aさん
Labels分類ラベルenhancement（機能追加）
  1. 「Submit new issue」をクリック

作成すると、Issueに 番号（例：#1, #2） が自動的に割り振られる。 この番号は後でPRと紐づける際に使用する。

ポイント

Issueのタイトルは「何をするか」を動詞で始めると明確になる。

  • ✅ 良い例：「割り算メソッドを追加する」「ゼロ除算のバグを修正する」
  • ❌ 悪い例：「割り算」「バグ」

Step 2: Issue駆動開発の流れ​

Issue駆動開発とは​

Issue駆動開発 とは、すべての作業を Issueから始める 開発スタイルである。 コードを書き始める前に、まずIssueを作成し、何をするかを明確にする。

基本の流れ​

やってみよう（Issue → ブランチ → PR）​

以下の手順を実際に行ってみよう。

1. Issueを作成する

  • タイトル：「割り算メソッドを追加する」
  • 説明：「Calculatorクラスにdivideメソッドを追加する。ゼロ除算のチェックを含める」
  • 自分をAssigneesに設定する
  • Issueの番号を確認する（例：#3）

2. ブランチを作成する

# Issue番号をブランチ名に含めると、関連が明確になる
git switch -c feature/#3-divide

3. 開発してコミットする

# Calculator.java に割り算メソッドを追加
git add Calculator.java
git commit -m "feat: 割り算メソッドを追加 #3"

4. pushしてPRを作成する

git push -u origin feature/#3-divide

Step 3: PRとIssueの紐づけ（Closes キーワード）​

Closes キーワードとは​

PRの説明文に Closes #番号 と書くと、そのPRがマージされたときに 対応するIssueが自動的にクローズ される。

## 何を変更したか
- Calculator クラスに割り算メソッド（divide）を追加した
- ゼロで割った場合は -1 を返すようにした

## なぜ変更したか
- 四則演算の機能を完成させるため

Closes #3

使えるキーワード​

以下のキーワードはすべて同じ動作をする。

  • Closes #番号
  • Fixes #番号
  • Resolves #番号

どれを使ってもよいが、このブートキャンプでは Closes に統一する。

なぜ紐づけが重要か

IssueとPRを紐づけると、以下のメリットがある。

  • Issueの画面から「どのPRで解決されたか」がわかる
  • PRの画面から「どのIssueに対応しているか」がわかる
  • マージ時にIssueが自動クローズされるため、閉じ忘れがない

コミットメッセージにも書ける​

git commit -m "feat: 割り算メソッドを追加 #3"

コミットメッセージに #番号 を含めると、GitHubのコミット履歴からIssueへのリンクが生成される。 ただし、コミットメッセージの #番号 ではIssueは自動クローズされない。自動クローズにはPRの説明文に Closes を書く必要がある。

Step 4: GitHub Flowのまとめ​

ここまで学んだ内容を整理すると、 GitHub Flow と呼ばれるワークフローになる。

GitHub Flowの全体像​

日常の開発サイクル​

チーム開発では、このサイクルを毎日繰り返す。

朝のルーティン:

git switch main
git pull
# Issueを確認し、担当するタスクを選ぶ
git switch -c feature/#番号-タスク名

開発中:

# こまめにコミット
git add .
git commit -m "feat: ○○機能を追加 #番号"

作業完了時:

git push -u origin feature/#番号-タスク名
# GitHubでPRを作成（Closes #番号を含める）

レビュー・マージ後:

git switch main
git pull
git branch -d feature/#番号-タスク名
ポイント

この流れを体に覚えさせよう。最初は手順が多く感じるが、毎日繰り返すうちに自然にできるようになる。

Step 5: コミットメッセージの規約​

チーム開発では、コミットメッセージに プレフィクス（接頭辞） を付けると、変更の種類がひと目でわかる。

よく使うプレフィクス​

プレフィクス用途例
feat:新機能の追加feat: 割り算メソッドを追加
fix:バグ修正fix: ゼロ除算のエラーを修正
docs:ドキュメントdocs: READMEに使い方を追記
refactor:リファクタリングrefactor: Calculatorのメソッド名を変更
test:テストtest: 割り算のテストを追加

やってみよう​

次のコミットから、プレフィクスを付けてコミットメッセージを書いてみよう。

# 機能追加の場合
git commit -m "feat: 掛け算メソッドを追加 #5"

# バグ修正の場合
git commit -m "fix: ゼロ除算時のエラーハンドリングを追加 #7"
補足

プレフィクスのルール（ Conventional Commits と呼ばれる）は、チームによって異なる場合がある。 ここで紹介したのは最も一般的なルールである。チームで統一されたルールがあれば、それに従おう。

Step 6: ペアワーク実践課題​

ここからは、2人1組のペアワークで実践する。 以下の手順で、Issue駆動開発の一連の流れを体験しよう。

準備​

  1. ペアで共有リポジトリを1つ用意する（片方が作成し、もう一方をCollaboratorとして招待する）
  2. 両方が git clone でリポジトリをローカルにコピーする
  3. Calculator.java を作成し、add メソッドだけ実装した状態でmainにpushする

実践1：機能追加（各自で担当）​

Aさんの作業:

  1. Issue「引き算メソッドを追加する」を作成し、自分をアサインする（例：#1）
  2. feature/#1-subtract ブランチを作成する
  3. Calculator.java に引き算メソッドを追加してコミットする
  4. pushしてPRを作成する（説明文に Closes #1 を含める）
  5. Bさんのレビューを待つ

Bさんの作業:

  1. Issue「掛け算メソッドを追加する」を作成し、自分をアサインする（例：#2）
  2. feature/#2-multiply ブランチを作成する
  3. Calculator.java に掛け算メソッドを追加してコミットする
  4. pushしてPRを作成する（説明文に Closes #2 を含める）
  5. Aさんのレビューを待つ

実践2：コードレビュー​

  1. お互いのPRを確認し、コードレビューを行う
  2. 少なくとも1つコメントを書く（良い点でも改善点でもよい）
  3. 問題がなければApproveする
  4. 修正が必要な場合はRequest Changesし、修正後に再度レビューする

実践3：マージとローカル同期​

  1. ApproveされたPRをマージする
  2. GitHub上でブランチを削除する
  3. ローカルで git switch main → git pull → git branch -d ブランチ名 を実行する
  4. Calculator.java に両方のメソッドが追加されていることを確認する

実践4：コンフリクトの体験​

  1. Issue「READMEを更新する」を 両方 が作成する（#3, #4）
  2. 両方が同時に README.md の同じ行を変更する
  3. 先にマージした方は成功する
  4. 後からマージしようとする方はコンフリクトが発生する
  5. コンフリクトを解決し、マージを完了する
重要

実践4で意図的にコンフリクトを体験しよう。 研修中に安全な環境でコンフリクトを経験しておくと、実務で遭遇しても焦らずに対応できる。

Step 7: チーム開発のベストプラクティス​

作業の進め方​

ルール理由
作業前にIssueを作成する何をするか明確にし、重複作業を防ぐ
こまめにコミットする変更を小さな単位で記録し、問題の特定を容易にする
1つのPRは1つの機能に絞るレビューしやすく、問題があった場合のrevertも簡単
毎朝 git pull するmainの最新を取り込み、コンフリクトを減らす

レビューの心構え​

ルール理由
コードを批判しても人を批判しないチームの信頼関係を守る
良いところは積極的に褒めるモチベーションを高め、学習を促進する
曖昧な指摘は避け、具体的に提案する修正方法が明確になり、スムーズに進む
レビューは24時間以内に行う開発のスピードを落とさない

まとめ​

この章では、 Issueとチーム開発実践 について学んだ。

🎯 達成できたこと​

  • ✅ GitHub Issueの作成と活用方法を説明できるようになった
  • ✅ Issue駆動開発の流れを説明できるようになった
  • ✅ Closes #番号 でPRとIssueを紐づけられるようになった
  • ✅ GitHub Flowの全体像を説明できるようになった
  • ✅ ペアでIssue → ブランチ → PR → レビュー → マージの流れを実践できるようになった

📚 学んだ内容​

  • Issueはチームのタスク管理ツールである
  • Issue駆動開発では、すべての作業をIssueから始める
  • PRの説明文に Closes #番号 を書くと、マージ時にIssueが自動クローズされる
  • GitHub Flowは Issue → Branch → PR → Review → Merge のサイクルである
  • コミットメッセージにプレフィクス（feat:, fix: 等）を付けると見やすい
  • コードレビューでは具体的で建設的なコメントを書く

🚀 次のステップ​

Git教材はこの章で完了である。 ここで学んだGitHub Flowの知識は、チーム開発の演習で実際に活用する。 最初は手順を確認しながら進め、徐々に体に覚えさせていこう。

💡 よくある質問​

Q1: Issueは誰が作成するのか？​

A: チームの誰でも作成できる。機能追加であればリーダーやプロダクトオーナーが、バグ報告であれば発見した人が作成するのが一般的である。このブートキャンプでは、各自が自分のタスクのIssueを作成する。

Q2: Issueに書く情報はどれくらい詳しくすべきか？​

A: 第三者が読んでも「何をすればよいか」がわかる程度に書くのが理想的である。最低限、「何をするか」「なぜ必要か」「完了条件は何か」を含めよう。

Q3: Closes キーワードを書き忘れた場合はどうなるか？​

A: Issueは自動クローズされないだけで、マージ自体は正常に行われる。手動でIssueを「Close」すればよい。次回以降は忘れないようにしよう。

Q4: 1つのPRで複数のIssueを閉じることはできるか？​

A: できる。Closes #1, Closes #2 のように書けば、マージ時に両方のIssueがクローズされる。ただし、1つのPRが複数のIssueにまたがる場合は、PRの粒度が大きすぎる可能性がある。

Q5: GitHub以外でもIssue駆動開発はできるか？​

A: できる。GitLabやBitbucketにも同様のIssue機能がある。また、JiraやTrelloなどのプロジェクト管理ツールとGitHubを連携させることもできる。基本的な考え方（タスクを明確にし、PRと紐づける）はどのツールでも同じである。

練習問題​

この章の内容を理解できたか確認しよう。

GitHub Issueを作成する正しい方法を選べ。

正解

B. Issuesタブから「New issue」でタイトルと説明を入力して作成する

解説

GitHub Issueの作成手順：

  1. リポジトリの「Issues」タブをクリック
  2. 「New issue」ボタンをクリック
  3. タイトル: 「何の問題か」を簡潔に（例：「ログイン時にNullPointerExceptionが発生する」）
  4. 説明文: 詳細情報を記入する
    • バグの場合: 再現手順・期待する動作・実際の動作・環境情報
    • 機能要望の場合: なぜ必要か・どう動作してほしいか
  5. 「Submit new issue」をクリック

Issueの活用方法：

  • Assignees: 担当者を設定する
  • Labels: バグ・機能追加・質問などのラベルで分類する
  • Milestone: リリースバージョンと紐づける
  • PRとの紐づけ: PRの説明文に Closes #番号 と書くとマージ時にIssueが自動クローズされる

Issueはタスク管理ツールとして機能し、「何を」「なぜ」「誰が」対応するかを可視化できる。

Issue駆動開発の正しいフローを選べ。

正解

A. Issue作成 → ブランチ作成 → 開発・コミット → PR作成 → レビュー → マージ → Issueクローズ

解説

Issue駆動開発（Issue-driven development）は、全ての作業をIssueで管理してから開発を進めるアプローチである。

フロー全体：

1. Issue作成（何をするかを明確にする）
2. ブランチ作成（issue/#番号-機能名）
3. 開発・コミット
4. PR作成（Closes #番号 を説明文に含める）
5. コードレビュー → Approve
6. mainにマージ
7. Issueが自動クローズ（Closes #番号 の効果）

Issue駆動開発のメリット：

  • 作業の可視化: チーム全員が「誰が何をやっているか」を把握できる
  • なぜを残す: コードの変更理由がIssueとPRに記録される
  • 優先度管理: LabelやMilestoneでタスクの重要度を管理できる
  • レビューの基準: Issueの要件を満たしているかでレビューの判断基準ができる

ブランチ名の命名例：

  • Issue #5 の場合: feature/5-login-function
  • Issue #12 の場合: fix/12-null-pointer-error

PRの説明文に以下のように記載することで、Issue #5 とこのPRを紐づけ、マージ時に自動クローズされるようにせよ。空欄を埋めよ。

解答例
Closes #5
解説

PRの説明文に Closes #番号 と書くと、そのPRが main にマージされた瞬間に、指定したIssueが自動的にクローズされる。

## 変更内容
ログイン機能を実装しました。

Closes #5

使えるキーワード（大文字・小文字不問）：

  • Closes #番号
  • Fixes #番号
  • Resolves #番号

紐づけの効果：

  1. PRページにIssueへのリンクが表示される
  2. PRがマージされるとIssueが自動クローズされる
  3. 「この変更はIssue #5に対応した作業だ」という履歴が残る

複数のIssueを紐づける場合：

Closes #5, Closes #8

GitHub Flowの説明として最も適切なものを選べ。

正解

B. mainは常にデプロイ可能な状態を保ち、作業はfeatureブランチで行い、PRでレビューしてマージする

解説

GitHub Flow は、GitHubが推奨するシンプルなブランチ戦略である。

6つのルール：

  1. mainブランチは常にデプロイ可能な状態にする
  2. 新しい作業は説明的な名前のブランチを作成して行う
  3. 定期的にリモートにpushする（バックアップ・共有目的）
  4. PRを作成してレビューを依頼する
  5. レビューが通ったらmainにマージする
  6. mainにマージしたら即デプロイ（またはデプロイ可能状態にする）

Git FlowとGitHub Flowの比較：

GitHub FlowGit Flow
ブランチ数少ない（main + feature）多い（main, develop, feature, release, hotfix）
リリース頻度高い（継続的デプロイ）定期リリース向け
複雑さシンプル複雑

初学者やスタートアップには GitHub Flow が適している。

コミットメッセージとして最も適切なものを選べ。

正解

A. feat: ログイン機能を追加

解説

コミットメッセージの規約として広く使われているのが Conventional Commits である。

フォーマット：

種別: 変更内容の概要

主な種別（prefix）：

種別説明
feat新機能の追加
fixバグ修正
docsドキュメントのみの変更
refactorリファクタリング（動作変更なし）
testテストの追加・修正
choreビルドプロセスや補助ツールの変更

良いメッセージの例：

  • feat: ユーザー登録機能を追加
  • fix: ログイン時のNullPointerExceptionを修正
  • docs: READMEにセットアップ手順を追加

悪いメッセージの例（なぜ悪いか）：

  • 修正しました → 何を修正したか不明
  • update → 英語1単語では情報が少なすぎる
  • コードを変更した → 何のコードをなぜ変更したか不明

コミットメッセージは「未来の自分やチームへのメモ」である。後から変更理由を追えるよう具体的に書く。

ペアで以下の手順を分担して実施し、全フローを通して記述せよ。

  1. Aさん: GitHubにIssueを作成する（例：「Greeter.javaにあいさつメソッドを追加する」）
  2. Aさん: Issue番号を含むブランチ名（例：feature/1-add-greeter）でブランチを作成する
  3. Aさん: Greeter.java を実装し、Conventional Commitsの規約に従ってコミットする
  4. Aさん: GitHubにpushしてPRを作成する（説明文に Closes #番号 を含める）
  5. Bさん: PRのコードをレビューし、コメントまたはApproveする
  6. Aさん: PRをマージし、Issueが自動クローズされることを確認する
  7. 両者: ローカルの main を git pull で同期し、featureブランチを削除する
  8. 役割を交代して、別の機能（例：「Calculator.javaに引き算メソッドを追加」）で同じフローを繰り返す

各手順で実行したコマンドとGitHub上での操作を、時系列でまとめて記述せよ。

解答例
# ペアで実施した手順（Aさん視点） ## 1. Issue作成（GitHubのWebUI） タイトル: "Greeter.javaにあいさつメソッドを追加する" 説明: "Greeter.javaを作成し、名前を受け取ってあいさつ文を返すgreet()メソッドを実装する" Assignees: Aさん ## 2. ブランチ作成 git switch -c feature/3-add-greeter # Issue番号 #3 をブランチ名に含めた ## 3. 実装・コミット # Greeter.java を作成 git add Greeter.java git commit -m "feat: Greeter.javaにgreet()メソッドを追加" ## 4. GitHubにpush git push origin feature/3-add-greeter ## 5. PR作成（GitHubのWebUI） タイトル: "Greeter.javaを追加" 説明: ## 変更内容 - Greeter.javaを新規作成 - greet(String name)メソッドを実装 Closes #3 ## 6. レビュー（Bさんの操作） Files changedでコードを確認 → コメント追加 → Approve ## 7. マージ（Aさんの操作） Merge pull request をクリック → Issue #3 が自動クローズされることを確認 ## 8. ローカル同期 git switch main git pull origin main git branch -d feature/3-add-greeter
解説

Issue駆動開発 + PRベース開発の組み合わせは、チーム開発の標準的なフローである。

フロー全体の確認：

Issue作成 → ブランチ作成 → 実装 → push → PR作成
  → レビュー → マージ → Issue自動クローズ → ローカル同期

この演習で習得すること：

  1. Issueで作業のスコープを明確にする習慣
  2. ブランチ名にIssue番号を含めて追跡しやすくする
  3. PRでコードレビューの体験をする
  4. Closes #番号 でIssueとPRを紐づける

役割交代の重要性：

  • AさんがPR作成者・Bさんがレビュワーでやったら、次はBさんがPR作成者・Aさんがレビュワーで行う
  • 両方の立場を体験することで、レビューの視点が身につく

振り返り観点：

  • コミットメッセージは変更内容を正確に表しているか
  • PRの説明文でレビュワーが変更内容を理解できるか
  • IssueとPRが正しく紐づいているか