開発手法 なぜ複数あるのか

• 日程: Day 3 / セッション 9
• 時間: [15:30-16:00]
• 形式: 座学＋演習
• ゴール: ウォーターフォール・反復型・インクリメンタル・アジャイル（XP、Scrum）の違いと、バージョン管理（WIP PR、Git-flow）の役割を説明できる。「なぜ開発手法が複数あるのか」への自分の答えを一文で言える
• 学習形式: 対話型解説＋AIディスカッション

Day 3 はここまで、設計アプローチを選び、永続化方式を選び、通信方式を選んできました。最後に残った問いはこれです。「で、どういう順番・進め方で開発するのか？」

Day 2 でウォーターフォールやアジャイルという開発モデルの名前は学びました。今日はもう一歩踏み込みます。ここで問いかけです。もし完璧な開発手法が1つあるなら、他の手法はとっくに消えているはずです。なのに、なぜ何種類も生き残っているのでしょうか？

この問いには模範解答を教えません。このセッションの演習で、あなた自身の答えを一文で書いてもらいます。今日学んだ設計アプローチが複数あった理由と、実は同じ構造の話です。

開発手法の違いは「工程をどう並べるか」に表れます。

• ウォーターフォール: 要件→仕様→設計→実装→テストを一直線に、後戻りせず流す。滝の水は逆流しない、が名前の由来です
• 反復型: 同じ工程の輪を何度も回し、毎回精度を上げる
• インクリメンタル: 機能を小分けにし、完成した部分から積み増して届ける
• イテレーション: 反復型・アジャイルでの「1周」を指す単位。1〜4週間が典型です

これは絵の描き方に例えると分かりやすいです。ウォーターフォールは「左上から完成品質で塗り進める」描き方。反復型は「全体を薄く下描きし、全体を何度も塗り重ねる」描き方。インクリメンタルは「顔だけ完全に仕上げて先に見せ、次に体を描く」描き方です。

どれが正しいかではなく、向き不向きがあります。たとえば「法律で仕様が固定された銀行の勘定系」はウォーターフォールが該当しますが、「ユーザの反応を見ながら育てる家計簿アプリ」は該当しません。なぜなら、後者は作る前に正解が分からず、後戻り（学び直し）が前提だからです。

ここで少し考えてみてください。あなたの4日間の研修そのものは、どの手法で進んでいるでしょうか？　毎日成果物を積み増し、PDCAを小さく回す──もう答えは見えていますね。

家計簿システムを2つの手法で作った場合の比較です。

• 手法の違いの本質は「後戻りをどれだけ前提にするか」
• Day 2 の開発モデル（V字・スパイラル・RAD・プロトタイピング等）も、この「一直線か周回か」の軸の上に並べられる
• 明日のDay 4 実装は、インクリメンタルで進める（動く状態を保ったまま機能を足す）

ウォーターフォールの原典とされるのは、ウィンストン・ロイスが1970年に書いた論文です。ところがこの論文、よく読むと衝撃的なことが書いてあります。一直線の工程図を示した直後に、ロイス自身が「この進め方はリスクが高く、失敗を招く」と警告し、反復やプロトタイプの必要性を説いているのです。つまり「ウォーターフォールの父」は、ウォーターフォールをそのまま使うなと言っていました。しかし図だけが独り歩きし、各国の調達基準にまで採用されてしまいます。「資料は図しか読まれない」という教訓としても、原典に当たることの大切さの例としても、よくできた歴史です。

2001年、軽量な開発手法の実践者たちが合流し、アジャイルソフトウェア開発宣言を発表しました。宣言の核は4つの価値です。

• プロセスやツールよりも、個人と対話を
• 包括的なドキュメントよりも、動くソフトウェアを
• 契約交渉よりも、顧客との協調を
• 計画に従うことよりも、変化への対応を

注意してほしいのは「よりも」の読み方です。左側（プロセス、ドキュメント等）にも価値がある、と宣言自身が認めています。左を捨てるのではなく、右をより重視する。「ドキュメントを書かないのがアジャイル」は誤読です。

代表的な実践形が2つあります。

• XP（エクストリーム・プログラミング）: 技術の実践に寄った手法。ペアプログラミング、テスト駆動開発、小さなリリースなど。「良い習慣を極端なまでに徹底する」から Extreme
• Scrum: チーム運営に寄った手法。スプリント（固定長のイテレーション）、毎日の短い共有会（デイリースクラム）、スプリントごとの振り返りで回す

XPは「書き方の型」、Scrumは「回し方の型」のようなものです。両方を併用するチームも多くあります。

分からない用語が出てきたら、そのままにせずAIに質問してみましょう。「スプリントとイテレーションは同じ意味？」のような素朴な質問こそ価値があります。

家計簿システムをScrumの1スプリント（1週間）で進める例です。

Day 4 の最後に行うKPTは、Scrumの振り返りの実践そのものです。

• アジャイルは「手法の名前」というより「価値観の名前」。XPやScrumがその実践形
• 4つの価値は「AよりもB」の形。Aを捨てる宣言ではないことに注意
• 短い周回＋振り返りは、この研修で毎日やっている「PDCAを小さく沢山回す」と同じ構造

アジャイル宣言が生まれたのは、2001年2月、米国ユタ州スノーバードのスキーリゾートです。XPやScrumなど、それぞれ別の軽量手法を提唱していた17人が集まり、スキーの合間に議論して共通の価値観を4行にまとめました。参加者の回想によれば、全員が合意できたことに本人たちが一番驚いたそうです。「アジャイル（機敏な）」という名前は候補の一つに過ぎず、「アダプティブ」など他の案もありました。ソフトウェア業界を20年以上動かし続ける文書が、雪山の休暇中に、たった4行で書かれた──長大な仕様書より4行の価値観が世界を変えたというのは、いかにもアジャイルらしい誕生譚です。

開発手法は、実はツールの使い方に宿ります。代表がバージョン管理システム Git です。

• Git: ソースコードの変更履歴を記録し、複数人（や過去の自分）との合流を可能にする道具。Day 4 でソースコード管理に使います
• WIP PR（Work In Progress の Pull Request）: 「まだ作業中です」と宣言した状態で、書きかけの変更を早めに公開してレビューをもらう習慣
• Git-flow: main（リリース版）、develop（開発中）、feature（機能ごと）などブランチの役割を決めた運用ルール

ここに開発手法との対応が見えます。完成してから見せるのはウォーターフォール的、書きかけを見せて早くフィードバックをもらうWIP PRはアジャイル的です。Git-flowの「featureブランチを小さく切って合流を繰り返す」は、インクリメンタルそのものです。つまりチームのGit運用を見れば、そのチームの開発手法が分かるのです。

これはこの研修のAI協働と同じ構造です。あなたは成果物を完成させてからAIに見せるのではなく、書きかけでレビューさせてきたはずです。それがWIP PRの感覚です。

Git-flowのブランチ構成の骨格です。

機能1つ＝ブランチ1本＝小さな周回1つ。インクリメンタルな考え方が、ブランチ構成として形になっています。

• バージョン管理は「保存の道具」ではなく「開発の進め方を形にする道具」
• WIP PRの本質は「早く見せて早く直す」。完璧主義の対極にある習慣
• Day 4 ではGitHub等でソースコードを管理する。ブランチ運用は簡略でよいが「小さく合流」の感覚は持ち込む

Gitを作ったのはLinuxの生みの親、リーナス・トーバルズです。2005年、Linux開発で使っていた商用ツールが使えなくなり、既存ツールに満足できなかった彼は、自分でバージョン管理システムを書き始めました。開発開始からわずか2週間ほどでGitは自分自身のソースコードを管理できるようになり、数か月後にはLinuxカーネル開発の本番に投入されます。「git」は英国の俗語で「嫌なやつ」という意味で、リーナスは「私は自分のプロジェクトに自分の名前をつける。LinuxしかりGitしかり」と冗談を言っています。世界中の開発を支える道具が、皮肉な名前とともに2週間で生まれたという話です。

• 「ウォーターフォールが今でも適している開発現場の実例を3つ挙げ、それぞれ理由を説明してください」
• 「アジャイル宣言の4つの価値のうち、1人＋AIで開発する場合に解釈を変えるべきものはありますか？」
• 「Git-flowよりシンプルなGitHub Flowという運用があると聞きました。違いと、小規模開発でどちらを選ぶべきかを教えてください」

演習1（10分）: 「なぜ開発手法が複数あるのか」を考察する

AIとディスカッションし、自分の答えを一文で書いてください。考える観点のヒント:

• 不確実性の量（要件は最初からどれだけ確定しているか）
• 変更コスト（後戻りにいくら払うか）
• チームの規模と練度
• 情報が見えるタイミング（作る前に分かるか、作ってみないと分からないか）
• 今日の午前に出会った言葉「銀の弾丸はない」との関係

ディスカッションの始め方の例（コピペで使えます）:

「なぜ開発手法は複数あるのか」を考えています。
私の仮の答えは「◯◯だから」です。
この答えに反論してください。反論に納得したら答えを直すので、
私が一文で言い切れるまで議論に付き合ってください。

演習2（10分）: Day 3全体をAIに説明する振り返り

Day 3 の流れ（設計アプローチ→多層アーキテクチャ→永続化→通信→API設計→開発手法）を、成果物を見ずに自分の言葉でAIに説明してください。手順:

1. 下のプロンプトでAIに聞き役を依頼する
2. 順番に説明する（各項目1〜3文でよい）
3. AIからの追加質問に答える。答えられなかった項目をメモする
4. メモした項目だけ教材を読み直す

私は今日、設計アプローチ（POA/DOA/SOA/ROA/OOAD）、多層アーキテクチャ
（3層/MVC/MVVM/DDD）、永続化（ACID・正規化）、UIと機能の通信（REST/JSON）、
RESTful API設計、開発手法（ウォーターフォール/アジャイル）を学びました。
これから順に自分の言葉で説明します。
説明が曖昧な点・矛盾する点があれば、遠慮なく質問で追い込んでください。
最後に、私の理解が弱い項目トップ2を指摘してください。

• 「なぜ開発手法が複数あるのか」への自分の答え（一文）
• Day 3振り返りのAI対話ログ（説明できなかった項目のメモつき）

• 演習1の答えに「状況」「不確実性」「トレードオフ」のような言葉が入ってきたら、良い線です。逆に「新しい手法ほど優れているから」で終わっていたら、AIに「では、なぜウォーターフォールは絶滅していないの？」と自分で自分に反論してみてください
• 演習2は「話す＆行う」の記憶定着法です。読めるだけの知識と話せる知識は別物。恥ずかしがらずに声に出す（または書き切る）ことが大切です

今回学んだことを一言でまとめると、**「開発手法は優劣の序列ではなく、不確実性と変更コストに応じた選択肢の品揃えである」**です。

• ウォーターフォールは一直線、反復型・インクリメンタルは周回。違いは「後戻りをどれだけ前提にするか」
• アジャイルは4つの価値の宣言であり、XP（書き方の型）とScrum（回し方の型）が実践形
• 開発手法はGitの運用（WIP PR、Git-flow）というツールの使い方に宿る

これでDay 3の「選ぶ」訓練はすべて完了です。設計方針・テーブル設計・API設計書という3つの成果物が手元にそろいました。明日Day 4は、いよいよ最終日。API設計書からモックAPIを作り、UIから呼び出し、プレゼンテーションと機能を分離したシステムを動かします。今日選んだものが、明日すべて形になります。

• ウォーターフォールとインクリメンタルの違いを「動くものが見える時期」と「変更コスト」の2観点で説明できますか？
• アジャイル宣言の「AよりもB」の4組のうち、2組以上を言えますか？
• 「なぜ開発手法が複数あるのか」へのあなたの答えを、いま一文で言えますか？

• 参考リンク: アジャイルソフトウェア開発宣言（日本語版）（https://agilemanifesto.org/iso/ja/manifesto.html）
• 参考リンク: Scrum Guide 日本語版（https://scrumguides.org/）
• 発展課題: ロイスの1970年論文 "Managing the Development of Large Software Systems" の図と本文の主張のギャップを確認し、「図だけが独り歩きした」と言われる理由を自分の言葉でまとめる