開発手法とバージョン管理
概要
- 日程: Day 3 / セッション 10
- 時間: [15:20-15:50]
- 形式: 座学+ディスカッション
- ゴール: ウォーターフォール／アジャイル（XP・Scrum）の違いを3観点で説明でき、Gitの基本フロー（branch→commit→pull request→merge）を図示できる
- 学習形式: AIディスカッション
導入（5分）
ここまで「何を作るか」「どう作るか」を学んできました。最後のテーマは「どんなプロセスで作るか」、つまり「開発手法」です。
Day 2のセッション06で「ウォーターフォール／アジャイル」という言葉に触れました。今日はそれをより深く、特にアジャイル系の代表（XP、Scrum）と、現代の開発に欠かせないGitの使い方を整理します。
なぜ手法が複数あるのか？ それは、UNIX哲学や設計アプローチと同じで「プロジェクトの性質によって最適解が違うから」です。
本編（20分）
1. ウォーターフォールとアジャイル
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程ごとに完了→次へ | 小さく繰り返す |
| 計画 | 最初に全体計画 | スプリント単位で計画 |
| 変更対応 | 高コスト | 前提として歓迎 |
| ドキュメント | 大量 | 必要最低限 |
| 向くプロジェクト | 要件が固定・規模大 | 要件が変動・素早く価値提供 |
| 例 | 銀行・公共系基幹 | Webサービス・スタートアップ |
コラム
「ウォーターフォール」という言葉は、1970年のWinston Royceの論文に登場します。実はRoyce自身は「これじゃダメだ、繰り返さないと」と批判する文脈で図を描いたのに、後の人がその図だけを切り取って「Royceがウォーターフォールを提唱した」と誤解して広めてしまいました。歴史の皮肉です。
2. XP（eXtreme Programming）
ケント・ベックが1999年に提唱。「良いプラクティスを極端（extreme）にやる」がモットー。
代表的なプラクティス：
- ペアプログラミング: 2人で1台のPCに向かって書く
- テスト駆動開発（TDD）: テストを先に書いてから実装
- 継続的インテグレーション（CI）: 頻繁にコードを統合してテスト
- リファクタリング: コードを書き直して綺麗にし続ける
- 小さなリリース: 動くものをこまめに出す
- シンプル設計: YAGNIの徹底
ここがポイント
XPは「プラクティス集」。チームの状況に合わせて取捨選択して導入できます。
3. Scrum（スクラム）
ジェフ・サザーランドとケン・シュエーバーが1990年代に体系化。XPがプラクティス集なのに対し、Scrumは「役割・イベント・成果物」を定義した「プロセスフレームワーク」。
(毎朝15分)"] DS --> SB SB --> SR["スプリントレビュー
(動くものをデモ)"] SR --> RE["スプリントレトロスペクティブ
(振り返り)"] RE --> SP
| 要素 | 内容 |
|---|---|
| 役割 | プロダクトオーナー、スクラムマスター、開発チーム |
| イベント | スプリントプランニング、デイリースクラム、スプリントレビュー、レトロスペクティブ |
| 成果物 | プロダクトバックログ、スプリントバックログ、インクリメント（動くソフト） |
| スプリント期間 | 通常 1〜4週間 |
ここがポイント
Scrumの本質は「短いサイクルで作って、見せて、振り返る」こと。研修の4日間も、ある意味4スプリントです。
4. Git の基本フロー
現代の開発でバージョン管理は必須。デファクトはGit（とGitHub/GitLab）。
コード例・実例
# 1. 最新を取得
git pull origin main
# 2. 機能ブランチ作成
git checkout -b feature/add-user-api
# 3. 編集してコミット
git add .
git commit -m "feat: ユーザー登録APIを追加"
# 4. リモートにpush
git push origin feature/add-user-api
# 5. GitHubでPull Request作成
# 6. レビュー後、mainにmerge
Git-flowブランチ戦略
代表的なブランチ戦略「Git-flow」では以下のブランチが登場します。
| ブランチ | 役割 |
|---|---|
| main / master | リリース可能な状態 |
| develop | 開発統合用 |
| feature/xxx | 機能開発用 |
| release/xxx | リリース準備用 |
| hotfix/xxx | 本番緊急修正用 |
ただし最近はシンプルな「GitHub Flow」（mainとfeatureだけ）も人気です。
5. WIP（Work in Progress）プルリクエスト
完成前でもPRを作って「進行中」を共有する文化。タイトルに [WIP] や Draft を付ける。
- メリット: 早期レビュー、認識合わせ、相談がしやすい
- 例: タイトル「[WIP] ユーザー登録API（DB設計の相談あり）」
6. なぜ開発手法が複数あるのか
設計思想と同じく、プロジェクトの性質によって最適解が変わるからです。
| プロジェクトの特徴 | おすすめ |
|---|---|
| 要件が固まっている、規制が厳しい（医療・金融基幹） | ウォーターフォール |
| 不確実性が高い、要件が変わる（新規Webサービス） | Scrum / XP |
| 小規模、少人数 | XP（プラクティス選定） |
| 大規模アジャイル | LeSS、SAFe など |
コラム
日本の野中郁次郎教授の論文「The New New Product Development Game」（1986）は、富士ゼロックスやホンダなどの開発現場を観察し、「ラグビーのスクラムのように、一体となって進める」開発スタイルを提唱しました。これがJeff Sutherlandに影響を与え、Scrumの名前の由来になりました。アジャイル開発の起源は実は日本の製造業にあるのです。
💬 AIに聞いてみよう
ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：
- 「自分たちの4日間研修にScrumを当てはめると、どんな進め方になる？」
- 「Git-flowとGitHub Flowは何が違うの？ どっち選べばいい？」
- 「TDDってどんな順番で書くの？ 簡単な例を見せて」
ディスカッション（5分）
課題
チームで以下を5分で議論：
- 自チームの4日間開発（特に明日のDay 4実装）に、どんな開発手法・Gitフローを採用するか
- デイリースクラム的な「短い同期ミーティング」をいつ・どう実施するか
- 役割分担（誰が何を担当するか）
成果物
- 採用する手法（Scrum風、XP風、軽量どちらかなど）
- Gitブランチ戦略（GitHub Flowなど）の選択メモ
- 役割分担表
ヒント
- 4日間という短期間ではフル装備のScrumは過剰。「デイリーで15分同期」「mainとfeatureだけのシンプルGit」程度で十分
まとめ（5分）
開発手法はプロジェクトの性質で選びます。短期で不確実性が高ければアジャイル、長期で要件固定ならウォーターフォール。Gitは現代の開発に必須で、main→feature→PR→mergeの基本フローを押さえれば十分スタートできます。
次のセッション（Day 3最後）では、今日学んだすべて（設計アプローチ・永続化・通信・実行方式・開発手法）の意思決定を整理し、Day 4実装への準備を整えます。
🔄 振り返りチェック
- ウォーターフォールとアジャイルの違いを3観点以上で説明できますか？
- XPの代表プラクティスを3つ挙げられますか？
- Gitの基本フロー（branch→commit→PR→merge）を図示できますか？
補足資料
- 参考リンク: ケント・ベック『XPエクストリーム・プログラミング入門』、Jeff Sutherland『スクラム』、Pro Git book（無料） https://git-scm.com/book/
- 発展課題: GitHubで適当なOSSのプルリクエストを3つ読み、「良いPRの書き方」を分析する
学習ガイド
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| アジャイルとScrumの違いは？ | アジャイル=思想（アジャイルマニフェスト2001）、Scrum=その実装の1つ |
| カンバンとScrumはどっちがいい？ | カンバンは「流量管理」、Scrumは「期間管理」。チームのリズム次第 |
| TDDは難しくない？ | 学習コストはあるが、慣れると「テストがあるから安心して直せる」状態になる |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| Gitのコマンドが多すぎて覚えられない | まず pull / checkout -b / add / commit / push の5つだけ |
| merge conflictが怖い | 練習で意図的にconflictを起こしてみると怖さがなくなる。VSCodeのGUIマージが便利 |
| アジャイルが「計画なし」と誤解される | 違う。「変化に強い計画の立て方」がアジャイル。計画は必要 |