開発モデルとは

• 日程: Day 2 / セッション5
• 時間: 13:00-13:20
• 形式: 座学
• ゴール: ウォーターフォール・V字・アジャイル・スパイラル・RAD・インクリメンタル・プロトタイピングの違いを1つずつ挙げられる
• 学習形式: 対話型解説

🗣️ 要約

• 情報モデルは「何を作るか」、開発モデルは「どうやって作るか」を整理するもので、両者は別物
• この違いが「情報の設計とシステムの設計を分離する」という研修全体のテーマの入口になる

お昼休憩、お疲れさまでした。午前中は「情報モデル」を学び、状態遷移図を作って機能とプレゼンテーションを抽出しましたね。

ここで1つ質問です。午前中作った「情報モデル」と、これから学ぶ「開発モデル」、同じ「モデル」という言葉が付いていますが、これは同じものでしょうか、それとも別物でしょうか？

答えは「別物」です。情報モデルは「何を作るか（What）」を整理するものでした。これから学ぶ開発モデルは「どうやって作るか（How）」を整理するものです。この違いこそが、この研修全体を貫く大事なテーマ「情報の設計とシステムの設計を分離する」の入り口になります。

このセッションが終わる頃には、代表的な開発モデルの名前と特徴をいくつか挙げられるようになっています。

🗣️ 要約

• 開発とは「有用なものを生み出し、システム化すること」で、要件→仕様→設計→実装→テストという工程を経る
• 開発モデルは、この工程をどんな順番・リズムで進めるかの型で、状況によって使い分ける

🗣️ 要約

• 開発とは「有用なものを生み出し、システム化すること」
• 工程は要件（機能要件・非機能要件）→仕様→設計→実装→テストの順
• 工程は必ず一直線に進むとは限らず、要件と実装のズレが生じることもある

開発とは、一言でいえば「有用なものを生み出し、システム化すること」です。

ここで少し考えてみてください。あなたが今日の午前中に作った「情報モデル」だけでは、まだソフトウェアは動きません。情報モデルという設計図をもとに、実際に手を動かしてプログラムを組み立てていく一連の活動、それが「開発」です。

開発には工程があります。

• 要件（機能要件・非機能要件）：何を実現するかを決める
• 仕様：要件をより具体的に決める
• 設計：仕様をどう実現するか組み立てる
• 実装：実際にコードを書く
• テスト：正しく動くか確認する

たとえば料理に例えると、「要件」は「今日は家族4人分のカレーを作る」という目的、「仕様」は「甘口で、野菜多めで」という条件、「設計」はレシピを組み立てること、「実装」は実際に調理すること、「テスト」は味見にあたります。

特に注意してほしいのは、これらの工程は「必ず一直線に進む」とは限らないということです。作ってみたら要件と違った、ということはよくあります。次に紹介する「開発モデル」は、この工程をどんな順番・どんなリズムで進めるかの型（パターン）です。

🗣️ 要約

• 代表的な開発モデルはウォーターフォール、V字、アジャイル、スパイラル、RAD、インクリメンタル、プロトタイピングの7種
• 要件が確定している大規模システムはウォーターフォール向き、変化の速いアプリ開発はアジャイル向きなど、状況によって適した型が異なる
• 開発モデルに優劣はなく、状況に応じた「使い分け」の問題

開発モデルには、いくつも種類があります。ここでは代表的なものを紹介します。

• ウォーターフォール：要件→設計→実装→テストの順に、後戻りせず一方通行で進める。滝の水が下にしか流れないことから名付けられた
• V字モデル：ウォーターフォールを発展させ、各設計工程に対応するテスト工程をV字型に描いて対応づけたもの
• アジャイル：短い期間（1〜4週間程度）で「設計→実装→テスト」を繰り返し、少しずつ機能を追加していく
• スパイラル：リスク分析を挟みながら、開発工程をらせん状に何度も繰り返す
• RAD（Rapid Application Development）：プロトタイプを使いながら短期間で開発する
• インクリメンタル：システムを機能単位に分割し、少しずつ追加でリリースしていく
• プロトタイピング：本格的な実装の前に試作品を作り、要件を確認しながら進める

これは、いわば「同じ目的地（動くソフトウェア）に向かう、複数のルートの地図」のようなものです。飛行機で一直線に行く方法（ウォーターフォール）もあれば、寄り道をしながら少しずつ確認して進む方法（アジャイル）もあります。

たとえば、要件がほぼ確定していて変更が少ない官公庁の大規模システムはウォーターフォールが向いていますが、市場の反応を見ながら機能を変えていくスタートアップのアプリ開発はアジャイルが向いています。逆に、要件が全く固まっていないのにウォーターフォールで進めてしまうと、完成した頃には状況が変わってしまっている、ということが起こりえます。

ここまでで、開発モデルにはいろいろな種類があり、それぞれ得意な状況が違う、というイメージはできましたか？ なぜ複数の開発モデルが存在するのか、Day3の最後にもう一度じっくり考える演習がありますので、楽しみにしていてください。

よくある誤解として「アジャイルが最新で一番優れている」という捉え方がありますが、正しくはそうではありません。要件の確定度合い、チームの規模、納期の厳しさなど、状況に応じて向き不向きがあります。優劣ではなく「使い分け」の問題です。

「ウォーターフォール」という名前、実は開発モデルを提唱した論文の中で最初に紹介されたときには、あまり良いモデルとして紹介されていなかった、という話をご存知でしょうか。1970年にWinston Royceが発表した論文が「ウォーターフォールモデルの元祖」としてよく引用されるのですが、実はその論文自体は「本当にこのやり方だけで進めるとリスクが大きい。反復して見直す工程が必要だ」と警告する内容だったのです。ところが、後の人々が論文の前半部分（一直線の工程図）だけを取り出して広めてしまい、「ウォーターフォール＝一直線に進めるべきもの」という誤解が定着してしまいました。良いアイデアも、伝わり方次第で本来の意図と違う形で広まってしまう、というのは情報アーキテクチャ的にもとても示唆に富むエピソードです。

🗣️ 要約

• アジャイルとスパイラルの違い、自分たちの開発テーマに向くモデル、V字モデルの対応関係などをAIに質問できる

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

• 「アジャイルとスパイラルモデルの違いをもっと詳しく教えて」
• 「自分たちの開発テーマ（〇〇システム）には、どの開発モデルが向いていると思う？」
• 「V字モデルの『V』は、具体的にどういう対応関係になっているの？」

🗣️ 要約

• 開発モデルは開発工程をどんな順番・リズムで進めるかの型であり、状況によって使い分けるもの
• 次回は非機能要件の定義を行う

今回学んだことを一言でまとめると「開発モデルは、開発工程をどんな順番・リズムで進めるかの型であり、状況によって使い分けるものだ」ということです。

次回は「非機能要件の定義」の演習です。今回学んだ「要件」という工程の中でも、機能要件とは別に非機能要件というものがあることに触れました。次のセッションでは、それを実際に自分たちの開発テーマについて定義してみます。

🗣️ 要約

• 開発モデルを3つ以上挙げられるか
• ウォーターフォールとアジャイルの違いを説明できるか
• 開発の5つの工程を順番に言えるか

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

• 開発モデルを3つ以上、名前を挙げられますか？
• ウォーターフォールとアジャイルの違いを説明できますか？
• 開発の5つの工程（要件・仕様・設計・実装・テスト）を順番に言えますか？

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

🗣️ 要約

• 参考資料は各開発モデルの比較図（AIに作成を依頼してもよい）
• 発展課題は、自分たちの開発テーマをウォーターフォールとアジャイルそれぞれで進めた場合のメリット・デメリット比較

• 参考リンク: 各開発モデルの詳細比較図（社内Wiki等があれば参照。なければAIに「開発モデルの比較表を作って」と依頼してみましょう）
• 発展課題: 自分たちの開発テーマにおいて、もしウォーターフォールで進めた場合とアジャイルで進めた場合、それぞれどんなメリット・デメリットがあるか比較してみましょう

🗣️ 要約

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

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

🗣️ 要約

• ウォーターフォールとV字モデルの違いは、V字がテスト工程を明示的に対応づけている点
• インクリメンタル（段階的リリース）とアジャイル（短い反復）は近いが別概念で、組み合わせて使われることも多い
• Webサービス系ではアジャイル（特にScrum）が主流だが、業界・案件により異なる

🗣️ 要約

• 開発モデルの名前が多く覚えにくいが、「一直線型」と「反復型」の2グループに分けると整理しやすい
• 「新しい方が優れている」という誤解をしやすいが、開発モデルに優劣はなく状況に応じた向き不向きがあるだけ