開発モデル — 家を建てるか、試食を重ねるか
家を建てるとき、基礎を打った後で「やっぱり間取りを変えたい」は大事故です——だから設計を固めてから一方向に進む。一方、新メニューの開発なら試食を繰り返して味を調整する方が確実です——完成形が最初は誰にも分からないから。
システム開発の2大モデルは、ちょうどこの対比です。どちらが優れているかではなく、仕事の性質に合うのはどちらかが問われます。
ウォーターフォールとアジャイル（スクラム）は、それぞれどんな進め方と役割分担をするのでしょうか。
一方向に固めて進むか、短い周期で回すかです
ウォーターフォールは要件定義→システム設計→プログラム設計→実装→テスト→運用保守と、上流から下流へ一方向に進みます。長所は計画と分担が明確なこと、短所は手戻りが困難なこと——滝は逆流しません。
アジャイルの代表スクラムは、スプリント（1〜4週間の固定周期）で「動くもの」を作っては見せるのを繰り返します。要求はプロダクトバックログに優先順位付きで積み、スプリントごとにスプリントバックログへ取り出す。毎日のデイリースクラム、成果を確かめるスプリントレビュー、進め方をふりかえるレトロスペクティブで回します。
スクラムの3つの役割——決める人・支える人・作る人です
スクラムの役割は3つで固定です。プロダクトオーナー（PO）＝何を作るかを決める——バックログの内容と優先順位に責任を持つ。スクラムマスター（SM）＝チームがうまく回るよう支援する——障害を取り除き、スクラムの進め方を守る（指示命令する管理職ではない）。開発チーム＝実際に作る。この3者の職務の入れ替えが試験の的です。
周辺語も1セットで——DevOps＝開発（Dev）と運用（Ops）が一体で回る体制、CI/CD＝継続的インテグレーション／継続的デリバリー（変更を自動でテスト・配備し、小さく頻繁に出す）。アジャイルの思想をリリース工程まで延長した道具立てです。
POとSMの職務の入れ替えが、ほぼ毎回の的です
定番の誤り肢は「スクラムマスターがバックログの優先順位を決める」——優先順位はプロダクトオーナーの専権です。逆に「POがチームの障害を取り除きプロセスを支援する」もSMの職務とのすり替え。決める人（PO）・支える人（SM）・作る人（チーム）で固定してください。
「アジャイルでは計画を立てない」も誤り——スプリントごとに計画し、短い周期で計画し直すのがアジャイルです。「ウォーターフォールは各工程を並行して進める」も逆——一方向・直列が特徴です。
顧問先がシステムを外注するとき、モデル選びは契約の形まで決めます——要件が固まっている基幹系の刷新はウォーターフォール＋請負契約（完成責任）が素直で、要件が動く新サービスはアジャイル＋準委任契約（伴走型）が馴染む。「アジャイルでお願いしたのに完成保証がない」というトラブルは、この対応を知らないまま契約した典型例——診断士が入口で防げる事故です。
冒頭の問いに答えます。ウォーターフォールは要件定義から運用保守まで一方向に進み、計画は明確だが手戻りが困難。スクラムはスプリント（1〜4週間）で反復し、PO＝何を作るかを決める・SM＝進め方を支援する・開発チーム＝作る、の3役で回します（DevOps・CI/CDはその延長）。次は、作ったものをどう確かめるか——テストへ。