基本情報のアジャイルとスクラムを解説！ウォーターフォールとの違いと覚え方

基本情報の開発手法は、アジャイル・スクラム・ウォーターフォールを同じ種類の言葉として覚えると混乱しがちです。アジャイルは変化に対応しながら価値を届ける考え方、スクラムはそれを実践する代表的な枠組み、ウォーターフォールは工程を順に進める開発モデルとして区別しましょう。

スクラムは「誰が責任を持つか」「いつ何を確認するか」「何を見て判断するか」に分けると整理できます。この記事では、基本情報の学習に必要な違いを比較し、予約アプリの例で役割・イベント・成果物を結び付けます。最後には選択肢を見分けるオリジナル確認問題も用意しました。

基本情報のアジャイルとスクラムの違い

アジャイルは考え方、スクラムは枠組み

アジャイルでは、最初の計画だけを頼りに最後まで作り切るのではなく、小さく動くものを作り、結果を確かめて次の判断へつなげます。何を価値とするか、利用者が何に困っているかを学びながら進めるため、当初の想定と違う情報が得られることも前提にします。「とにかく速くコードを書く」という意味ではありません。

スクラムは、そのような開発をチームで進めるための枠組みです。プロダクトオーナー・スクラムマスター・開発者という責任の分担、スプリントなどのイベント、バックログなどの作成物が定義されています。ただし、どの言語で実装するか、どのテストツールを使うかまで一律に指示する手順書ではありません。

したがって、アジャイルとスクラムを完全な同義語として覚えるのは避けましょう。スクラムを使わずにアジャイルを実践することもできますし、イベントだけ開いていても、得られた情報を次の判断に使わなければ変化への対応につながりません。名前よりも、短いサイクルで何を検証しているかが大切です。

用語	位置づけ	問題文で確認する特徴
アジャイル	価値観や原則に基づく開発の考え方・アプローチ	小さく提供し、対話とフィードバックで適応する
スクラム	アジャイルを実践する代表的なフレームワーク	定義された責任、イベント、作成物がある
ウォーターフォール	工程を順番に進める開発モデル	要件定義・設計・実装・テストを段階的に進める

IPAの試験要綱・シラバスの案内から参照できる基本情報技術者試験シラバスVer.9.2では、アジャイルとスクラムの特徴が開発プロセス・手法の学習項目に含まれています。本記事は用語の理解を扱い、出題数や特定問題の登場を保証するものではありません。受験制度の適用時期はIPAの最新案内で確認してください。

ウォーターフォールとの比較軸

ウォーターフォールは、要件を整理してから設計し、実装・テストへ進めるという工程の順序が基本です。各段階の成果を確認して次へ進むため、何を作るかが十分に分かっていて、承認や契約上の区切りを明確にしたい場面では計画を立てやすくなります。工程ごとの文書は、関係者の合意や後続作業の根拠にもなります。

一方、アジャイルでは、作って確かめる過程で要求の理解を深めます。たとえば「使いやすい予約画面」を作る場合、事前の説明だけでは操作上の困りごとを捉えきれないかもしれません。小さな機能を利用者に見てもらい、予約時間の選び方や入力項目を調整すれば、思い込みを早めに修正できます。

比較するときは、単に開発期間が長いか短いかではなく、要求をどの時点でどの程度固め、いつ利用者の反応を取り込むかを見ます。ウォーターフォールでも変更管理やレビューは行います。アジャイルでも全体の目標、予算、期限を考えます。「変更は絶対にできない」「計画は一切立てない」という極端な説明は正確ではありません。

比較軸	ウォーターフォールの基本	アジャイルの基本
要求の扱い	先に整理し、工程の基準にする	早めの検証で理解を深め、優先順も見直す
進め方	工程を区切り順番に進める	小さな範囲で設計・実装・検証を繰り返す
フィードバック	工程のレビューや受入れなどで確認する	短い間隔で得た反応を次の作業に使う
注意点	後工程で大きな認識違いが判明すると調整が広がる	関係者が継続的に判断・協力できる体制が必要

どちらを選ぶかは、要求の不確実さだけでなく、利用者に確認できる頻度、規制や契約、関係者の体制にも左右されます。学習上は特徴を対比しつつ、どちらなら必ず安くなる、必ず品質が上がるとは覚えないでください。手法の名前が効果を自動的に決めるわけではありません。

プロジェクト全体の進捗や費用を管理する話と、開発をどのサイクルで進めるかという話も区別できます。管理プロセスを続けて学ぶ場合は、基本情報のプロジェクトマネジメントの解説で、立ち上げ・計画・実行などの整理を確認できます。

アジャイル宣言を誤解しない

アジャイルの価値観を確認する一次情報は、アジャイルソフトウェア開発宣言です。大まかには、人同士の対話、実際に動くもの、顧客と協力すること、状況に応じた計画の見直しを重視します。ここで重要なのは、ツール・文書・契約・計画に価値がないと否定しているわけではないことです。

たとえば、予約アプリで「キャンセルは利用日の何日前まで可能か」という条件を文書に残さなければ、開発者と運営者の判断が食い違います。動く画面を早く見せることは有用ですが、その画面に反映すべき業務ルールの合意も必要です。作らない文書を増やす判断と、必要な情報を共有しない判断は別ですね。

また、変更への対応は、依頼が来るたびに作業中の内容を無制限に入れ替えることではありません。新しい要望を把握し、価値やリスク、現在の目標への影響を踏まえて扱いを決めます。目の前の要望をすべて受けると、本来届けたかった機能が完成しないこともあります。

問題文で「文書を作成しない」「顧客は完成まで関与しない」「初期の計画を変更しない」といった強い表現を見たら、アジャイルのどの特徴と食い違うかを言葉にしてみましょう。ただし、否定形というだけで機械的に誤りとせず、問われた条件や文脈まで読むことが必要です。

価値観の原文はアジャイルソフトウェア開発宣言、継続的な提供や対話などの原則はアジャイル宣言の背後にある原則で確認できます。学習では、文言を丸暗記するだけでなく、開発中の具体的な行動に置き換えると理解しやすくなります。

スプリントは工程の分割ではない

スクラムのスプリントは、決まった長さで目標に向かって作業する期間です。2020年版スクラムガイドでは1か月以内と定められています。実際の例として2週間のスプリントを考えることはできますが、必ず2週間、必ず1週間という固定の意味で覚える必要はありません。

ここでの目標は、たとえば「利用者が空き時間を選び、予約を確定できる状態にする」です。そのために必要な設計・実装・テストなどを期間内で進めます。「最初のスプリントは設計だけ、次は実装だけ、最後はテストだけ」と工程名を期間へ割り当てる説明では、使える成果を少しずつ完成させる特徴を捉えられません。

作業が多すぎるなら、予約・決済・通知・管理画面をすべて抱えるのではなく、目標に必要な範囲を考えます。予約だけでも、画面と保存処理がつながり、必要な品質を満たして初めて使える機能になります。画面の見た目だけを作って保存できない状態と、利用者が実際に予約できる状態は区別しましょう。

テストを最後へ先送りにしないことも大切です。小さい機能でも、入力の境界や不正な値、他の機能との整合性を確認します。テストの観点を詳しく知りたい場合は、基本情報のブラックボックステスト・同値分割・境界値分析の解説を合わせて確認すると、開発の流れと品質確認をつなげて学べます。

スプリント中は、スプリントゴールを危険にさらす変更を避け、品質を下げず、学んだ内容に応じて作業範囲をプロダクトオーナーと調整します。時間切れだから期間を安易に延ばす、完成扱いの基準を緩める、という理解は避けてください。区切りがあるからこそ、現状を確認する機会を定期的に持てます。

透明性・検査・適応をつなげる

スクラムの土台には、透明性・検査・適応という三つの柱があります。まず、何を目指し、何ができていて、何がまだできていないかを関係者が理解できる状態にします。見た目だけ完成している画面を「予約機能は完成」と報告すると、利用者が実際に使えるかという情報が見えなくなります。

検査は、成果や進み具合を目標と照らして確かめることです。適応は、その確認で分かったことを受けて、必要なやり方や計画を変えることです。予約画面を見た利用者が「空いている日が分かりにくい」と話したなら、意見を聞くだけで終わらず、日付表示の改善がどれほど価値を持つかを検討します。

この三つは独立した暗記語ではありません。状況が見えなければ検査が難しく、検査しても判断を変えなければ適応につながりません。スクラムのイベントは、単に会議の回数を増やすためではなく、この流れを定期的に実行するための機会として捉えると覚えやすくなります。

また、スクラムには確約・集中・公開・尊敬・勇気という五つの価値基準があります。責任を押し付け合うのではなく、目標に集中し、問題を隠さず伝え、互いの専門性を尊重する行動と結び付けて理解しましょう。三つの柱、五つの価値基準、後で扱う五つのイベントは、数が似ていても別の分類です。

用語の定義や期間は2020年版スクラムガイド日本語版に基づきます。一般的な解説の「役割」は、同ガイドでは責任として整理されています。以前の資料で「開発チーム」と書かれていても、現在のガイドではスクラムチーム内の「開発者」として確認してください。

基本情報のスクラムを用語で整理する

三つの役割は責任の対象で覚える

スクラムチームは、プロダクトオーナー・スクラムマスター・開発者で構成されます。名前に「オーナー」「マスター」と付いていても、一般的な会社の上司・部下の関係にそのまま当てはめないでください。スクラムチーム内に上下関係やサブチームを置かず、何を誰がどう行うかをチームで決める自己管理が基本です。

責任	中心となる対象	予約アプリでの行動例
プロダクトオーナー	プロダクトの価値とプロダクトバックログの管理	通知より予約確定の改善を優先する理由を明確にする
開発者	各スプリントで使える成果を作ること	作業計画を作り、実装・テストしながら毎日調整する
スクラムマスター	スクラムの確立とチームの有効性	ルールの理解を助け、作業を阻む問題の解消を促す

プロダクトオーナーは、スクラムチームが生み出すプロダクトの価値を最大化する責任を持ちます。そのため、プロダクトゴールを明確にし、バックログの項目や並び順を関係者に分かる形で管理します。複数の部署が要望を出す場合でも、委員会がプロダクトオーナーになるのではなく、責任を持つ一人として整理されます。

開発者は、使えるインクリメントを作るために必要な人たちです。ここでいう開発者は、コードを書く人だけに限定しません。成果の完成に必要なら、設計やテストなどを担う人も含めて考えます。スプリントバックログを作り、完成の定義を守り、ゴールに向けて日々の計画を適応させます。

スクラムマスターは、スクラムの理解と実践を支援し、チームの有効性に責任を持ちます。たとえば、確認が必要な相手と連絡が取れず開発が止まっているなら、その障害の解消を促します。すべての障害を一人で片付ける、各人に毎日のタスクを命令する、という役割としては覚えないでください。

学習用には「価値と順序はPO、実現と日々の計画は開発者、スクラムとチーム支援はSM」と短く整理できます。ただし、実装の話ならプロダクトオーナーが一切関わらない、支援なら開発者は関与しない、という排他的な分類ではありません。責任の中心を見分けるための覚え方です。

バックログと成果物の対応を覚える

バックログは、単に「遅れている仕事」という意味で訳して覚えると混乱します。スクラムのプロダクトバックログは、プロダクトを改善するために必要な項目を並べた、変化していく一覧です。新機能だけでなく、不具合修正や改善なども、プロダクトに必要な作業として扱えます。

作成物	何を表すか	対応するコミットメント
プロダクトバックログ	プロダクトを改善するために必要な項目の一覧	プロダクトゴール
スプリントバックログ	今回のゴール・選んだ項目・実行する計画	スプリントゴール
インクリメント	以前の成果と整合し、使える状態になった成果	完成の定義（Definition of Done）

予約アプリ全体では、「空き時間の検索」「予約の確定」「予約のキャンセル」「通知」「管理者用画面」などがプロダクトバックログの候補になります。今すぐすべてを実装するのではなく、価値や必要性を踏まえて順序を考えます。学習用の例なので、実際のサービスには認証や安全対策など、さらに必要な条件があります。

あるスプリントで「利用者が予約を確定できる」をゴールとし、空き時間の表示と予約保存に関する項目を選び、その実現方法を計画したものがスプリントバックログです。プロダクトバックログ全体をコピーしたものではなく、今回の目的と作業の見通しを示します。作業中に知ったことに応じて、開発者が更新します。

インクリメントは、計画や項目一覧ではなく、実際に使える成果です。今回完成した予約機能が以前の成果とつながり、品質条件を満たしていることが必要です。スプリントでは複数のインクリメントが作られる場合もあり、「一つのスプリントにつき必ず一つ」とは限りません。

完成の定義は、成果を完成したと判断するための共通の品質基準です。たとえば、必要なテストを通り、既存の機能と統合されているといった条件を、チームが同じ理解で持ちます。今回選んだ一つの機能の動作条件だけでなく、インクリメントの品質を共有するための基準だと捉えましょう。

完成の定義を満たしていない項目は、インクリメントの一部として扱えません。残った作業はプロダクトバックログへ戻して今後の検討対象にします。「実装した」「テストを後で行う予定」という状況と、「完成した」を混同しないことがポイントです。作業時間の消化量と価値を届けられる状態も別ですね。

バックログの項目を細かくし、内容や順序、サイズなどを明確にしていく活動がリファインメントです。必要に応じて継続的に行う活動で、スクラムガイドに定義された独立した六つ目のイベントではありません。会議を設けて行う場合と、公式のイベント分類は区別して覚えましょう。

イベントは目的と相手を区別する

スクラムのイベントは五つです。ただし、スプリントは他の四つのイベントと作業全体を包む期間なので、「五種類の会議」と数えると構造を取り違えます。スプリントの中で、計画し、日々調整し、結果を検査し、仕事の進め方を改善するという流れを押さえましょう。

イベント	主な目的	見分ける手掛かり
スプリント	一定期間で価値ある成果を作る	他のイベントを含む1か月以内の期間
スプリントプランニング	今回の価値・成果・実現方法を計画する	開始時にゴールと作業を考える
デイリースクラム	ゴールへの進み具合を検査し計画を調整する	開発者が毎日行う15分のイベント
スプリントレビュー	成果と状況を関係者と検査して今後を考える	プロダクトや次の方向を話し合う
スプリントレトロスペクティブ	品質と有効性を高める改善を計画する	チームの仕事の進め方を振り返る

開始と毎日の計画をつなぐ

スプリントプランニングでは、スクラムチームが、今回のスプリントに価値がある理由、何を完成できるか、どう実現するかを考えます。プロダクトオーナーが価値や方向性を示し、開発者が作業の見通しを踏まえて項目を選び、実行可能な計画を作ります。誰か一人が全員へ仕事を割り当てる時間、とだけ覚えるのは不十分です。

デイリースクラムでは、開発者がスプリントゴールへの進捗を確認して、必要なら計画を変えます。予約保存のテストで問題が見つかったなら、今日の作業を調整し、協力が必要な点を明らかにします。上司へ実績を報告して査定してもらう会議ではありません。

毎日15分という枠は、このイベントの時間です。詳しい設計議論や障害調査もすべて15分で済ませなければならない、という意味ではありません。必要な詳しい話し合いは別に行えます。また、毎回同じ三つの質問を必ず一人ずつ答えるという形式は、2020年版ガイドで固定されていません。目的に合う進め方を開発者が選びます。

レビューは成果から次を考える

スプリントレビューでは、スクラムチームとステークホルダーが成果を確認し、状況の変化も踏まえて次に何をするかを考えます。予約機能を見せた結果、「スマートフォンでは空き時間を選びにくい」と分かったなら、次に改善すべきことを検討できます。単なる発表会よりも、今後の判断に向けた共同作業として理解しましょう。

また、レビューはリリースの必須承認ゲートではありません。使えるインクリメントは、スプリント終了前でも提供できます。「毎回のレビューが終わるまで、完成した機能は必ず公開できない」という説明と混同しないでください。実際のリリースは、品質やサービスの事情も含めて判断します。

ふりかえりは仕事の方法を改善する

スプリントレトロスペクティブで確認する中心は、チームの仕事の進め方です。「テストに必要な条件が共有されず、確認待ちが続いた」「レビュー準備が直前に集中した」などを振り返り、次のスプリントで有効な改善を考えます。誰かを責めるための反省会ではなく、品質と有効性を高めるための時間です。

たとえば、予約機能の表示を直すことはプロダクトに関する次の作業です。一方、仕様の確認事項を早めに共有することはチームの方法の改善です。同じ不具合がきっかけでも、前者を中心に関係者と話すレビューと、後者をチームで考えるレトロスペクティブは目的が違います。

覚え方は「レビューは作ったものと次の方向、レトロスペクティブは作り方と次の改善」です。レトロスペクティブはスプリントを締めくくり、その後に次のスプリントが始まります。問題文が何を振り返っているかを確認すれば、単に「終了時に行う」という共通点だけで迷うことを減らせます。

選択肢を見分ける確認問題

ここからの問題は理解を確かめるためのオリジナル例で、IPAの実際の過去問を転載したものではありません。用語名を先に思い出そうとするより、責任の対象、イベントの目的、作成物が示す範囲の順に読んでみてください。正解以外の選択肢が合わない理由まで説明できれば、言い回しが変わっても対応しやすくなります。

責任とイベントを判断する

【問題1】予約アプリの要望を整理し、利用者への価値を踏まえてプロダクトバックログの並び順に責任を持つのは誰でしょうか。ア：プロダクトオーナー、イ：スクラムマスター、ウ：開発者。

【答え】アです。判断対象はプロダクトの価値とバックログの管理です。スクラムマスターはスクラムの実践を支援し、開発者は実現の計画や使える成果の作成を担います。「責任者」という曖昧な語だけでなく、何の責任を問われているかを確認しましょう。

【問題2】チームが、仕様確認の遅れでテストが集中した原因を話し合い、次回は確認事項を早めに共有すると決めました。中心となるイベントはどれでしょうか。ア：スプリントプランニング、イ：スプリントレビュー、ウ：スプリントレトロスペクティブ。

【答え】ウです。焦点は完成したプロダクトの次の方向ではなく、チームの仕事の方法です。アなら今回のゴールと計画、イなら成果や環境の変化を関係者と確認する場面が中心になります。「次回」という言葉だけでは決めず、改善対象を読み取りましょう。

作成物と誤解を確認する

【問題3】今回のゴールと、選んだバックログの項目、それを完成させる実行計画をまとめています。これは何でしょうか。ア：プロダクトバックログ、イ：スプリントバックログ、ウ：インクリメント。

【答え】イです。アはプロダクト全体を改善する項目の一覧で、ウは実際に使える成果です。スプリントバックログは今回の「なぜ・何を・どうやって」を含む計画なので、単なるタスク名の一覧より広い内容を示します。

【問題4】スクラムについて正しい説明はどれでしょうか。ア：アジャイルと同じ意味なので役割を区別する必要はない、イ：完成の定義を満たすインクリメントはスプリント終了前にも提供できる、ウ：リファインメントは六つ目の公式イベントである。

【答え】イです。アは考え方と枠組みを混同し、ウは継続的な活動と定義されたイベントの分類を混同しています。完成の定義を満たすことと、レビューをリリースの必須ゲートにしないことを合わせて思い出せるか確かめましょう。

間違えたときは、正解の用語だけをノートへ書くより、「価値」「今回の計画」「作ったもの」「仕事の方法」のどれを取り違えたかを一言で残すと復習しやすくなります。次に、誤った選択肢が正解になる別の場面を作ってみてください。たとえば問題2の対象をプロダクトへの意見へ変えると、レビューを考える場面になります。

基本情報のアジャイルとスクラムのまとめ

まず、アジャイルを変化に対応しながら価値を届ける考え方、スクラムをそれをチームで進める枠組みとして区別します。ウォーターフォールとの比較では、速さだけで判断せず、要求をどのように扱い、いつ結果を確かめて次の判断へ取り込むかを説明できるようにしましょう。

スクラムの復習は、三つの責任を誰が担うか、二つのバックログとインクリメントが何を表すか、五つのイベントが何を確かめる機会か、の順に進めると整理しやすくなります。名前を隠して、予約アプリの例から用語を戻せるか試してみてください。特にレビューとレトロスペクティブの違いは、対象を一言で答える練習が役立ちます。

用語の土台から確認し直したい方は、参考書の開発技術分野で全体像を読み、分からなかった箇所を公式ガイドへ戻って確認する方法が向いています。すでに違いを説明できる方は、問題を解いて条件の読み取りを練習しましょう。どちらも、答えを覚えるだけで終わらず、他の選択肢の責任や目的を説明することが次の一歩です。

今すぐ演習したい方は、基本情報の過去問アプリで学習を進められます。今回のオリジナル確認問題と実際の過去問は区別し、解説を読んでも役割やイベントで迷う場合は、該当する比較表へ戻って確認してください。