ITを整える
初級開発プロセスを整える。
＝ ウォーターフォールとアジャイル/スクラムの違いを、図解で
ウォーターフォールとアジャイル、V字モデル、スクラムの流れ——「開発モデル」の用語はどれも似た響きで混同しがちです。このページでは工程の流れを図で見比べ、V字モデルはクリックで設計⇔テストの対応関係を確認でき、スクラムの1サイクルと役割、主要用語までを整理しています。入力欄はなく、図と説明を読むだけのページです（送信ゼロ）。
🔰 かんたんに言うと
ウォーターフォールとアジャイル/スクラムの違い、V字モデルを図解で。開発プロセスの用語がつかめます。
TLDR — 30秒で分かる
ウォーターフォール（一方向）とアジャイル/スクラム（反復）の流れを比較図と観点別の対比表（メリット・デメリット・向く場面）で整理。V字モデルは要件定義⇔システムテストなど設計⇔テストの対応をクリックで確認でき、スクラムの1サイクル（プロダクトバックログ→スプリントプランニング→スプリント→スプリントレビュー→レトロスペクティブ）と3つの役割、イテレーション・CI/CD・MVPなど主要用語も一覧。
主な機能
- ウォーターフォール／アジャイルの流れ比較図＋9観点の対比表
- V字モデル（要件定義⇔システムテスト等3対応）をクリックで対応表示
- スクラムの1サイクルと3つの役割（PO／スクラムマスター／開発チーム）
- イテレーション・リファクタリング・CI/CD・MVPなど主要用語10種の早見表
- 広告ゼロ・ブラウザ内処理・送信ゼロ
🌊 ウォーターフォール——滝のように、上流から下流へ一方向
- 1. 要件定義
- 2. 基本設計（外部設計）
- 3. 詳細設計（内部設計）
- 4. 実装（プログラミング）
- 5. テスト
- 6. 運用・保守
原則、後戻りしない前提で1回だけ最初から最後まで流れる。前工程の完了が次工程の開始条件。
🔁 アジャイル——短い反復（イテレーション／スプリント）をくり返す
1回のサイクルは短く（数週間程度）、毎回「動くもの」ができる。終わるたびに計画を見直せる。
| 観点 | 🌊 ウォーターフォール | 🔁 アジャイル |
|---|---|---|
| 開発の進め方 | 要件定義→設計→実装→テスト→運用の順に、後戻りしない一方向で進む（滝が流れ落ちるイメージ）。 | 短いイテレーション（スプリント）を何度も繰り返し、動くソフトウェアを少しずつ積み上げる。 |
| 要件変更への対応 | 苦手。後工程での仕様変更は手戻りコストが大きい。 | 得意。イテレーションごとに優先順位を見直し、変化を前提に計画を調整できる。 |
| 進捗の可視化 | 工程（ドキュメント）の完了で進捗を測るため、動くものが見えるのは終盤になりやすい。 | 毎スプリントで「動くソフトウェア」ができるため、早期から実物で進捗を確認できる。 |
| ドキュメント | 各工程で仕様書・設計書を詳細に作成し、後工程の根拠として重視する。 | 必要最小限。「動くソフトウェアを、包括的なドキュメントよりも」重視する（アジャイル宣言の価値観）。 |
| 顧客・ユーザーとの関わり | 要件定義時と検収時が中心。開発期間中の関与は限定的。 | スプリントレビューなどで継続的に関与し、フィードバックをそのつど反映する。 |
| 向く場面 | 要件が確定しており変更が少ない、大規模・官公庁系・ミッションクリティカルな開発。 | 要件が変わりやすく、早く価値を届けたいWebサービスや新規事業の開発。 |
| メリット | 計画・予算・工数の見積もりがしやすく、進捗管理がしやすい。 | 変化に強く、早期にフィードバックを得て軌道修正できる。 |
| デメリット | 後工程での手戻りコストが大きく、リリースまで実際の動作を確認しづらい。 | 全体の完成時期や総コストの見通しを立てにくい。 |
| リスクが見つかる時期 | テスト工程（終盤）で発覚しやすく、その時点での手戻りは高コストになりやすい。 | 毎スプリントで検証するため、問題を早期に発見・修正しやすい。 |
💡 どちらが優れているというものではなく、要件の変わりやすさ・規模・求められる確実性によって向き不向きが分かれます。両方を理解した上での使い分けが、ITパスポート・基本情報でも問われるポイントです。
ボックスをクリック（またはTabで選んでEnter）すると、対応する設計・テスト工程の説明がここに表示されます。
💡 V字モデルの考え方：「設計で決めたことを、対になるテストで確認する」。要件定義で決めた仕様は最終段階のシステムテストで、基本設計（外部設計）は結合テストで、詳細設計（内部設計）は単体テストで検証します。左腕を降りて右腕を昇る形が、アルファベットの「V」に見えることが名前の由来です。
プロダクトオーナー
Product Owner
プロダクトバックログの優先順位を決め、「何を作るか」に責任を持つ役割。ビジネス価値の最大化が使命。
スクラムマスター
Scrum Master
スクラムのルールやプロセスが正しく回るよう支援するファシリテーター役。チームの障害（阻害要因）を取り除く。
開発チーム（開発者）
Development Team
実際にプロダクトを作る自己組織的なチーム。設計・実装・テストを一体で担う機能横断型のチーム。
計画→設計→実装→テストを短い期間で繰り返す1サイクル。スクラムでは「スプリント」と呼ぶ。
スクラムにおけるイテレーションの呼び名。1〜4週間程度の固定期間（タイムボックス）で区切られる。
外部から見た動作（仕様）を変えずに、内部のコード構造を整理・改善すること。
2人1組（コードを書くドライバーと確認するナビゲーター）で1台のPCを使い、相互にレビューしながら開発する手法。
コード変更のたびに自動でビルド・テストする（CI＝継続的インテグレーション）＋リリース可能な状態まで自動で反映する（CD＝継続的デリバリー）しくみ。
顧客に価値を届けられる必要最小限の機能だけを備えた製品。早く作って学びを得るための最小構成。
スプリント期間中に残タスク（残作業量）がどう減っていくかを示すグラフ。進捗の可視化に使う。
1スプリントでチームが完了できた作業量（ストーリーポイント等）の実績値。次スプリントの見積りに使う。
「〜として、〜したい。なぜなら〜だから」という形式で書く、利用者視点の要求の単位。
会議や作業に、あらかじめ期限を区切ること。スプリントやデイリースクラムの時間制限もタイムボックスの一種。
一致する用語が見つかりません。表記を変えてお試しください。
🔒 このページに入力欄・通信を伴う機能はありません。図と説明はすべてビルド時に生成された静的なHTML／SVGで、クリック時の色分けもあなたのブラウザの中（純JavaScript）だけで完結します。何もサーバへは送信されません（送信ゼロ）。
よくある質問
Q. ウォーターフォールとは何ですか？
A. 要件定義→設計→実装→テスト→運用・保守の順に、滝が流れ落ちるように一方向で進む開発モデルです。原則として後戻りをしない前提で計画され、各工程の完了（ドキュメントの完成）が次工程に進む条件になります。
Q. アジャイルとは何ですか？
A. 計画→設計→実装→テストを短い期間（イテレーション／スプリント）で繰り返し、動くソフトウェアを少しずつ積み上げていく開発の考え方です。1回のサイクルが終わるたびに優先順位や計画を見直せるため、変化に強いのが特徴です。
Q. ウォーターフォールとアジャイル、どう使い分ければいいですか？
A. 要件が確定していて変更が少ない大規模・ミッションクリティカルな開発はウォーターフォールが、要件が変わりやすく早く価値を届けたいWebサービスや新規事業の開発はアジャイルが向きます。どちらが優れているというものではなく、要件の変わりやすさや求められる確実性で選びます。
Q. V字モデルとは何ですか？
A. ウォーターフォールの各設計工程と、対応するテスト工程を対にして示したモデルです。要件定義⇔システムテスト、基本設計（外部設計）⇔結合テスト、詳細設計（内部設計）⇔単体テストが対応し、「設計で決めたことを、対になるテストで確認する」という考え方を表します。実装（プログラミング）がV字の底辺にあたります。
Q. スクラムの主要用語にはどんなものがありますか？
A. 実現したい機能を優先順位付きで並べた「プロダクトバックログ」、次のスプリントで何を作るか決める「スプリントプランニング」、毎日の進捗共有「デイリースクラム」、成果物を見せる「スプリントレビュー」、進め方を振り返る「レトロスペクティブ」が中心です。役割はプロダクトオーナー・スクラムマスター・開発チームの3つに分かれます。
Q. イテレーションとスプリントはどう違いますか？
A. イテレーションは「計画→設計→実装→テストを短期間で繰り返す1サイクル」を指す一般的な用語で、スプリントはスクラムにおけるイテレーションの呼び名です。中身はほぼ同じで、スクラムの文脈では「スプリント」と呼ぶ、と覚えておけば十分です。
Q. このページは入力した内容をどこかに送りますか？
A. いいえ。このページに入力欄はなく、図と説明を読む・クリックして確認するだけのツールです。表示の切り替えはすべてあなたのブラウザの中（純JavaScript）で完結し、サーバへは何も送信されません（送信ゼロ）。
入力値はURLの「#」以降に入るためサーバーには送信されません。リンクを開くと同じ状態を復元します。
RELATED TOOLS
続けて整える
