【初心者向け】Git Flow×GitHub Flow×スクラム開発の3ステップ実践ガイド

目次

1. なぜ開発フローが重要なのか
2. Git FlowとGitHub Flowの違い
3. GitHub Flowの実践手順
4. スクラム開発の基本サイクル
5. 実際の開発の流れ（1週間の例）
6. 明日から使えるチェックリスト
7. まとめ

---

なぜ開発フローが重要なのか

開発現場では「何を作るか」と同じくらい「どう作るか」が大事です。

理由は3つ：

• バグを本番環境に出さない：テストしてからリリースする仕組みが必要
• チーム全員が同じ方向を向く：誰が何をやっているか分かる状態を作る
• スピードを落とさない：ルールがあるから、迷わず進められる

ベンチャーやスタートアップでは、このバランスが命です。

---

Git FlowとGitHub Flowの違い

Git Flowとは

複数の長期ブランチで管理する方法

ブランチ構成：

• main（本番用）
• develop（開発用）
• feature/〇〇（機能追加用）
• release/〇〇（リリース準備用）
• hotfix/〇〇（緊急修正用）

メリット：大規模プロジェクトで安全
デメリット：ブランチ管理が複雑、マージが多い

GitHub Flowとは

mainブランチ1本で管理する方法

ブランチ構成：

• main（常にデプロイ可能な状態）
• feature/〇〇（作業用ブランチ）

メリット：シンプル、デプロイが速い
デメリット：テストの自動化が必須

どっちを選ぶ？

（Web系ベンチャーなら）
GitHub Flowを選ぶべき理由：

• 1日に何度もデプロイできる
• チーム全員が流れを理解しやすい
• CIツール（GitHub Actions等）と相性抜群

実例：

• ユーザーからの要望を朝に聞いて、夕方にはリリース
• バグ発見から修正完了まで30分以内
• こういうスピード感が可能になります

---

GitHub Flowの実践手順

ステップ1：ブランチを切る

# 最新のmainを取得
git checkout main
git pull origin main

# 作業用ブランチを作成
git checkout -b feature/user-profile-edit

ブランチ名のルール：

• feature/機能名：新機能
• fix/バグ内容：バグ修正
• refactor/対象：リファクタリング

例：

• feature/login-form
• fix/signup-validation-error
• refactor/user-model

ステップ2：コードを書く

小さく、頻繁にコミット：

# 変更をステージング
git add .

# コミット（何をしたか明確に）
git commit -m "Add: ユーザープロフィール編集フォーム追加"

良いコミットメッセージ：

• Add: 〇〇を追加
• Fix: 〇〇のバグ修正
• Update: 〇〇を更新
• Remove: 〇〇を削除

悪い例：

• update（何を？）
• fix bug（どこの？）
• aaa（意味不明）

ステップ3：プルリクエスト（PR）を出す

# リモートにプッシュ
git push origin feature/user-profile-edit

GitHubでPRを作成する際、以下を記載：

## 概要
ユーザーがプロフィールを編集できる機能を追加

## 変更内容
- プロフィール編集フォームのUI実装
- バリデーション追加（名前：20文字以内、自己紹介：200文字以内）
- APIエンドポイント `/api/users/:id` にPATCHメソッド追加

## テスト
- [ ] ローカル環境で動作確認
- [ ] バリデーションエラーが正しく表示されるか確認
- [ ] 更新後の情報が正しく保存されるか確認

## スクリーンショット
（画面キャプチャを貼る）

## 補足
特になし

ステップ4：レビューを受ける

レビュアーが見るポイント：

• コードが読みやすいか
• テストは十分か
• セキュリティ上の問題はないか

指摘を受けたら：

• 修正してコミット
• 再プッシュ（同じブランチでOK）
• 自動的にPRに反映される

ステップ5：マージ＆デプロイ

レビュー承認後：

1. GitHubで「Merge pull request」をクリック
2. ブランチ削除（自動または手動）
3. CI/CDが自動でテスト→デプロイ

# ローカルのブランチも削除
git checkout main
git pull origin main
git branch -d feature/user-profile-edit

---

スクラム開発の基本サイクル

スクラムとは

1〜2週間の短いサイクルで開発を回す方法

登場人物

• プロダクトオーナー（PO）：何を作るか決める人
• スクラムマスター（SM）：チームが円滑に進むようサポート
• 開発チーム：実際に作る人（あなた）

スプリント（1週間の流れ）

月曜：スプリントプランニング（計画会議）

時間：1時間

やること：

1. 今週やることを決める
2. タスクを細かく分解
3. 各自が担当を決める

例：

目標：ユーザー登録機能を完成させる

タスク：
- [ ] 登録フォームUI作成（田中・3時間）
- [ ] バリデーション実装（佐藤・2時間）
- [ ] API実装（鈴木・4時間）
- [ ] テスト作成（田中・2時間）

火〜木：デイリースタンドアップ（朝会）

時間：15分（立ったまま）

各自が話すこと：

1. 昨日やったこと
2. 今日やること
3. 困っていること

例：

田中「昨日は登録フォームのUIを完成させました。今日はテストを書きます。特に問題ありません」
佐藤「昨日はバリデーションの実装を進めましたが、メールアドレスの重複チェックで詰まっています。鈴木さん、後で相談させてください」

金曜午前：開発継続

金曜午後：スプリントレビュー＆レトロスペクティブ

レビュー（30分）：

• 今週できたものをデモ
• POやステークホルダーに見せる

レトロスペクティブ（30分）：

• 良かったこと
• 悪かったこと
• 次週改善すること

例：

良かったこと：
- PRのレビューが早かった
- 朝会で相談しやすかった

悪かったこと：
- タスクの見積もりが甘かった
- テストが不十分だった

改善すること：
- タスクを細かく分解する
- テストを先に書く

---

実際の開発の流れ（1週間の例）

月曜 9:00〜10:00：スプリントプランニング

あなたのタスク：ユーザー検索機能

タスク分解：
1. 検索フォームUI（3h）
2. 検索API実装（5h）
3. 検索結果表示（4h）
4. テスト作成（3h）
合計：15時間（1日6時間×3日で余裕を持つ）

月曜 10:00〜：開発開始

git checkout main
git pull origin main
git checkout -b feature/user-search

午前中にUIを作成：

git add .
git commit -m "Add: ユーザー検索フォームUI追加"
git push origin feature/user-search

火曜 9:00〜9:15：朝会

「昨日は検索フォームのUIを完成させました。今日はAPI実装を進めます」

火曜中：API実装

git add .
git commit -m "Add: ユーザー検索API実装"
git push origin feature/user-search

水曜：検索結果表示＆テスト

午前：

git add .
git commit -m "Add: 検索結果表示機能追加"
git push origin feature/user-search

午後：

git add .
git commit -m "Add: ユーザー検索機能のテスト追加"
git push origin feature/user-search

PRを作成してレビュー依頼

木曜：レビュー対応

指摘：「検索結果が0件のときのメッセージがない」

git add .
git commit -m "Fix: 検索結果0件時のメッセージ追加"
git push origin feature/user-search

レビュー承認→マージ

金曜：新規タスク開始＆振り返り

---

明日から使えるチェックリスト

コーディング前

• mainから最新を取得した
• 適切な名前でブランチを切った
• タスクの目的を理解した

コーディング中

• 小さく頻繁にコミットしている
• コミットメッセージが明確
• 動作確認しながら進めている

PR作成前

• ローカルで動作確認完了
• 不要なコード（console.logなど）を削除
• テストを書いた（または動かした）

PR作成時

• 概要を書いた
• 変更内容を箇条書きした
• スクリーンショットを貼った
• レビュアーをアサインした

レビュー後

• 指摘事項を修正した
• 再度動作確認した
• マージ後、ローカルのブランチを削除した

---

まとめ

GitHub Flowは3ステップ

1. ブランチを切る
2. コードを書く→コミット→プッシュ
3. PRを出す→レビュー→マージ

スクラム開発は4つの儀式

1. 月曜：計画会議（今週やることを決める）
2. 毎朝：朝会（15分で進捗共有）
3. 金曜：レビュー（できたものを見せる）
4. 金曜：振り返り（改善点を話す）

実践のコツ

• ブランチは小さく：1つのブランチで1つの機能
• コミットは頻繁に：1日5〜10回が目安
• PRは丁寧に：レビュアーが理解しやすく書く
• 朝会は短く：15分厳守、詳細は後で個別に
• 振り返りは正直に：改善のための時間

スピードを上げるために

• 朝イチでその日のゴールを決める
• 詰まったら30分で相談する
• PRは出したらSlackで通知
• レビューは当日中に返す
• 小さくリリース、早く改善

最後に

この記事の内容を実践すれば、チームの一員として貢献できます。最初は完璧じゃなくてOK。毎日少しずつ、開発フローを身につけていきましょう。