開発モデルと工程

• 日程: Day 2 / セッション 06
• 時間: 13:00-13:30
• 形式: 座学
• ゴール: 代表的な7つの開発モデル（ウォーターフォール／V字／アジャイル／スパイラル／RAD／インクリメンタル／プロトタイピング）の特徴を1文ずつ説明でき、要件→仕様→設計→実装→テストの5工程と、機能要件・非機能要件の違いを述べられる
• 学習形式: AI協働型（自チームに最適な開発モデルをAIと相談する）

午前中は「何を作るか（情報モデルと機能・画面）」を固めました。午後は「どう作るか（システム設計の準備）」に視点を移します。

「どう作るか」の最初の選択は**開発モデル（どんな進め方をするか）**です。「とりあえずコードを書き始める」では事故ります。プロジェクトの性質に合わせて進め方を選ぶ必要があります。

このセッションでは代表的な7つの開発モデルと、共通の5つの工程、そして「機能要件と非機能要件の違い」を学びます。次のセッションでは、自チームの非機能要件を実際に書き出す実習に入ります。

どの開発モデルでも、基本的な活動は同じ5つです。順番や繰り返し方が違うだけです。

• 要件：誰のために何を実現したいか（ペルソナとゴール）
• 仕様：要件を満たすために、何を提供するか（機能・画面・データ）
• 設計：仕様をどう作るか（アーキテクチャ・技術選定）
• 実装：実際にコードを書く
• テスト：要件・仕様を満たしているか確認する

「要件」と「仕様」の違いがあいまいだと炎上します。要件は「何のために」、仕様は「何を」。例えば「家計簿を見える化したい」が要件、「月別の支出グラフ機能」が仕様。

1960年代、ソフトウェア開発の遅延と失敗が世界中で頻発し「ソフトウェア危機」と呼ばれました。NATOの国際会議（1968年）で「ソフトウェアエンジニアリング」という言葉が初めて使われ、製造業から学んだ「工程を分けて管理する」発想が導入されました。「要件→設計→実装→テスト」の流れは、この危機への処方箋として生まれたのです。

「正しいモデル」は存在しません。プロジェクトの「規模・不確実性・チーム成熟度・納期」で最適解が変わります。研修テーマは「小規模・新規・チーム未熟・短納期」なので、アジャイル + プロトタイピングのハイブリッドが現実的です。

発明者と言われるWinston Royceの1970年論文「Managing the Development of Large Software Systems」は、実は「上から下に一直線で進むのは危険だ」と警告している論文でした。論文には反復のアイデアも書かれていました。なのに後世の人々は「上から下に進める綺麗な図」だけを取り出して、ウォーターフォールとして広めてしまったのです。論文を読まずに引用する怖さを示す名作です。

要件は大きく2種類に分かれます。

非機能要件の代表カテゴリ

• 性能：応答時間、同時利用数
• 可用性：稼働率、障害復旧時間
• 運用性：監視、ログ、デプロイ容易性
• 保守性：コード可読性、ドキュメント
• セキュリティ：認証、暗号化、ログ
• 移行性：データ移行、互換性

非機能要件は、機能要件よりも後で気付くと致命的です。「動くものは出来たが10秒待たないと表示されない」では使われません。次のセッションで自チームの非機能要件を書き出します。

日本のIPA（情報処理推進機構）が、非機能要件を整理した「非機能要求グレード」という無料ガイドを公開しています。可用性、性能、運用、移行、セキュリティなど6カテゴリで200項目超のチェックリストになっています。最初に見ると圧倒されますが、業界標準として非常に参考になります。次のセッションで活用します。

• 「私のチームの開発テーマ『○○』に最適な開発モデルは？理由つきで提案して」
• 「ウォーターフォールとアジャイルを併用する事例はある？」
• 「機能要件と非機能要件で『迷う』例を教えて」

開発モデルの選択肢が頭に入り、要件には機能要件と非機能要件があると分かりました。

次のセッション（Session07）は40分の実習。自チームの非機能要件を10項目以上書き出します。AIをフル活用しないと10項目は意外と出ません。

• 7つの開発モデルを、1文ずつで言えますか？
• 5つの工程を順番に言えますか？
• 機能要件と非機能要件の例を、自分のテーマで1つずつ挙げられますか？

• 参考リンク：IPA 非機能要求グレード、Winston Royce 1970年論文
• 発展課題：自宅で使っているアプリ（LINE/Instagram/銀行アプリ）の開発モデルを推定する