ソフトウェア開発・アルゴリズム・アーキテクチャ 重要度:★★出題: AM・PM
アジャイル開発とスクラム
あじゃいるかいはつとすくらむ / Agile Software Development & Scrum
短いイテレーション（スプリント）を反復しながら動くソフトウェアを段階的にリリースし、変化に柔軟に適応する開発手法。
3行速習ポイント
- 3つのロール（プロダクトオーナー、スクラムマスター、開発チーム）で自己組織化チームを編成
- プロダクトバックログ（要求一覧）からスプリントバックログ（次期作業）を切り出し1〜4週間で開発
- スプリント計画、デイリースクラム、スプリントレビュー、レトロスペクティブ（振り返り）の定例イベント
図解
図スクラム（Scrum）におけるスプリント反復サイクルと3大ロール連携循環・改善サイクル
プランニング ➔ デイリースクラム ➔ スプリントレビュー ➔ レトロスペクティブ（1〜4週間周期）🔄 継続的フィードバック＆改善サイクル（Phase進行 ➔ 次サイクルへ還流）
11. スプリントプランニング（計画）
Plan: 計画策定➔ Step 2
POが優先順位付けしたPBLから今スプリントの目標と開発項目を選択
プロダクトオーナー（PO）が提示するプロダクトバックログ（PBL）の上位項目から、開発者がベロシティに基づき達成可能な量を選択し、具体的な実現タスク（スプリントバックログ）へ分解する。
22. 開発作業 ＆ デイリースクラム（日次同期）
Do: 日次検査と実装➔ Step 3
毎日15分の短時間ミーティングで進捗・今日やる作業・障害物を共有
開発者が毎日同じ時刻に15分間でスプリントゴールに向けた進捗を検査し、1日の計画を調整する。バーンダウンチャートで残工数を可視化し、スクラムマスターがチームの障害物を除去する。
33. スプリントレビュー（成果物検査）
Check: プロダクト検査➔ Step 4
完成した「動くインクリメント」をステークホルダへ実演しフィードバック収集
スプリント終盤に「完了の定義（DoD）」を満たした動作するソフトウェアを顧客や関係者にデモンストレーションし、市場環境や利用者の反応を踏まえてプロダクトバックログを適応・更新する。
44. スプリントレトロスペクティブ（振り返り）
Act: プロセス改善↩ Step 1へ
チームの働き方・開発プロセス・ツールを検査し次スプリントの改善策を決定
成果物ではなく「チームの進め方・人間関係・品質プラクティス」を振り返り（KPT等）、次のスプリントで生産性と品質をさらに高めるための具体的な改善アクションを合意する。
💡 ロールの責任分担は超頻出：「プロダクトバックログの優先順位付け＝プロダクトオーナー（PO）」、「スクラムのルール定着と障害除去＝スクラムマスター（SM）」、「作業見積りと実装＝開発者」。
概要と本質
仕様変更が頻繁に発生する現代のWebサービスやDX領域で標準的に採用されるフレームワークです。ウォーターフォールのように初期に全要件を固めるのではなく、優先度の高い機能から順次設計・実装・テストを行い、顧客フィードバックを迅速に取り込みます。
重要ポイント・コア概念
- プロダクトオーナー（PO）：価値の最大化とバックログの優先順位決定に責任を持つ
- スクラムマスター（SM）：プロセスの円滑化と障害の除去を支援するサーントリーダー
- スプリントの成果物：完了の定義を満たした出荷可能なインクリメント（Increment）
- バーンダウンチャート：スプリント内の残作業工数を日次で可視化するグラフ
応用情報（午前択一・午後長文記述）での出題・得点戦略
午前問題でロールの責任範囲（POとSMの役割分担）やイベントの名称が頻出。午後開発技術問題では「バーンダウンチャートの傾きから遅延を読み取る」「受け入れ基準の策定」が出題されます。
