（演習）なぜ開発手法が複数あるのか考察する

• 日程: Day 3 / セッション10
• 時間: [15:40-16:20]
• 形式: 演習
• ゴール: 開発テーマの特性（不確実性・チーム規模・納期）を踏まえ、適した開発手法を1つ選び理由を説明できる
• 学習形式: AIディスカッション

🗣️ 要約

• 開発手法が複数存在するのは、それぞれに得意な状況があるから
• 開発手法の選択に唯一の正解はなく、状況に応じて選ぶものである

前のセッションでは、UIと機能の通信方式（REST/SOAP）、実行方式（ネイティブ／Web／クラウド）、そして開発手法（ウォーターフォール、反復型、アジャイルなど）を駆け足で見てきました。ここで少し考えてみてください。開発手法だけでもこれだけの種類があるのは、なぜだと思いますか？

もし「これが正解」という開発手法が1つだけあるなら、他の手法はとっくに淘汰されているはずです。それでも複数の手法が今も併存しているということは、それぞれに得意な状況があるということです。

このセッションでは、皆さんの開発テーマに立ち返り、「自分たちに合う開発手法はどれか」を理由つきで選びます。正解を当てる問題ではありません。状況に応じて選べるようになることが、このセッションのゴールです。

🗣️ 要約

• 開発手法を選ぶための3つの物差しは不確実性・チーム規模・納期
• 開発手法に優劣はなく、状況への適合度で選ぶ

🗣️ 要約

• 不確実性・チーム規模・納期という3つの物差しで開発手法の向き不向きが変わる
• 仕様が固定的で不確実性が低い開発はウォーターフォールと相性が良く、仕様を探りながら作る場合はアジャイルと相性が良い
• 開発手法の選択は「好み」ではなく「状況とのマッチング」

開発手法の向き不向きは、次の3つの物差しで大きく変わります。

• 不確実性：作るものの仕様が最初からはっきり決まっているか、作りながら分かっていくものか
• チーム規模：数人の小さなチームか、多くの人が関わる大きなチームか
• 納期：短いスパンで区切って進められるか、まとまった期間が必要か

たとえば、法律で仕様がほぼ固定されている行政システムの刷新であれば、不確実性は低く、ウォーターフォールのように最初に全部を設計し切るやり方と相性が良いといえます。一方で、皆さんが今取り組んでいる開発テーマのように「ペルソナが本当に欲しいものは何か」を探りながら作る場合は、不確実性が高く、アジャイルのように短いサイクルで作って確かめる方法と相性が良くなります。

ここまでで、開発手法の選択が「好み」ではなく「状況とのマッチング」であることをイメージできましたか？

🗣️ 要約

• ゼロから作る新規開発（家計簿システムなど）は不確実性が高くアジャイル的な反復開発が向く
• 稼働中システムの保守開発（バグ修正など）は不確実性が低くウォーターフォール的な進め方が向く
• 同じ「開発」でも状況によって適した手法は変わる

たとえば、皆さんの開発テーマ（家計簿システムやレシピ類推サービスなど、ゼロから作る新規開発）は、要件が研修の中で変わっていく可能性が高いので、アジャイル的な反復開発が該当します。しかし、すでに動いている量産システムに対して「バグを1件直す」だけの保守開発は、影響範囲が明確で不確実性が低いため、ここで言う「アジャイル向き」には該当しません。むしろ小さな変更を1つずつ確実に確認するウォーターフォール的な進め方の方が向いています。同じ「開発」という言葉でも、状況によって適した手法は変わるのです。

特に注意してほしいのは、「アジャイルが新しくて優れている」「ウォーターフォールは古くて劣っている」という決めつけです。よくある誤解として、開発手法に優劣をつけてしまうことがありますが、正しくは「状況に対する適合度」で選ぶものです。Day1で学んだ「情報の価値はペルソナの視点で決まる」のと同じ構造で、「開発手法の良し悪しは状況で決まる」と捉えると理解しやすくなります。

ウォーターフォールモデルは、もともと1970年に発表された論文で紹介された図が元になっていますが、実はその論文の著者自身が「この図の通りに一直線に進めるやり方はうまくいかない」と、同じ論文の中で指摘していたという逸話があります。つまり「後戻りしない一直線の開発」という誤解は、後の人たちが図の前半部分だけを切り取って広めてしまったものだったのです。元の論文をよく読むと、著者はむしろ「試作と反復を繰り返すべきだ」と書いており、現代のアジャイル的な考え方に近いことを既に述べていました。名前だけが独り歩きしてしまう、という情報の多義性の一例ともいえます。

🗣️ 要約

• アジャイルとウォーターフォールの組み合わせ、自分たちのチームに合う開発手法、スパイラルとインクリメンタルの違いをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「アジャイルとウォーターフォールを組み合わせることはできる？」
• 「自分たちのチーム（4〜5名、研修期間中）にはどの開発手法が合う？」
• 「スパイラルモデルとインクリメンタルモデルの違いをもう一度教えて」

🗣️ 要約

• 開発テーマを3つの物差しで整理し、開発手法を1つ選んで理由を説明する演習

🗣️ 要約

• 開発テーマを不確実性・チーム規模・納期の3つの物差しで整理する
• 7つの開発手法の中から最も適したものを1つ選ぶ
• 選んだ理由を3つの物差しに基づいてチームで説明できるようにする
• バージョン管理（WIP PR、Git-flow等）の使い方も簡単に話し合う

1. 自分たちの開発テーマについて、「不確実性」「チーム規模」「納期」の3つの物差しでチームの状況を整理する
2. ウォーターフォール、V字、アジャイル（XP/Scrum）、スパイラル、RAD、インクリメンタル、プロトタイピングの中から、最も適していると思う開発手法を1つ選ぶ
3. なぜその手法を選んだのか、3つの物差しに基づいて理由をチームで説明できるようにする
4. 選んだ開発手法の中で、バージョン管理（WIP PR、Git-flow等）をどう使うかも簡単に話し合う

🗣️ 要約

• 開発手法の選択とその理由をまとめたメモ（Day4の実装で使用する）

• 開発手法の選択とその理由をまとめたメモ（Day4の実装で実際にこの進め方を使います）

🗣️ 要約

• 1つに決まらない場合は、設計はウォーターフォール的に、実装は反復型・インクリメンタル的に、というハイブリッドな結論でもよい
• 意見がまとまらないときは、開発テーマの特徴を伝えてAIにアドバイスをもらうと進みやすい

• どうしても1つに決まらない場合は「Day4の実装では反復型・インクリメンタルの考え方を基本にしつつ、最初の設計はウォーターフォール的に固めておく」のように、ハイブリッドな答えでも構いません
• 意見がまとまらない場合は、AIに「この開発テーマの特徴を伝えるので、開発手法の選び方についてアドバイスして」と相談してみましょう

🗣️ 要約

• 開発手法に優劣はなく、状況に合わせて選ぶものである
• 次回（Day3まとめ）は、設計思想・アーキテクチャ・開発手法を振り返り、開発テーマに使うものを整理する

今回学んだことを一言でまとめると、「開発手法に優劣はなく、状況に合わせて選ぶものだ」ということです。次回（Day3まとめ）は、今日1日で学んだ設計思想・アーキテクチャ・開発手法を振り返り、皆さんの開発テーマに使うものを整理します。今回選んだ開発手法の知識が、そのまま土台になります。

🗣️ 要約

• 開発手法を選ぶときの3つの物差し（不確実性・チーム規模・納期）を説明できるか
• 自分たちの開発テーマに合う開発手法を、理由つきで1つ選べるか

以下の問いに答えられるか確認してみましょう：

• 開発手法を選ぶときの3つの物差し（不確実性・チーム規模・納期）を説明できますか？
• 自分たちの開発テーマに合う開発手法を、理由つきで1つ選べますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考リンクは特になく、社内の開発標準や過去プロジェクト事例があれば参照するとよい
• 発展課題は、アジャイルのXPとScrumの違いを調べ、自分たちのチーム運営に近い方を考えること

• 参考リンク: なし（社内の開発標準やチームの過去プロジェクト事例があれば参照するとよい）
• 発展課題: アジャイルの中でもXPとScrumの違いを調べ、どちらが自分たちのチーム運営に近いか考えてみる

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• 複数の開発手法は実務では併用が一般的（全体はウォーターフォール的、詳細実装はアジャイル的、など）
• アジャイルを選べば必ずうまくいくわけではなく、不確実性が低い現場ではむしろ混乱を招くこともある
• バージョン管理は開発手法という「進め方」を、コードの変更履歴として支える仕組み

🗣️ 要約

• 開発手法に「正解」を求めてしまい議論が止まりやすい
• 手法名の暗記に意識が向き、3つの物差しでの理由づけがおろそかになりやすい
• チーム内で意見が割れて時間内にまとまらないことがある