アジャイル
アジャイルとは何か
Section titled “アジャイルとは何か”ソフトウェア開発の現場では、開発の途中でお客様の要望が変わることが少なくありません。従来のウォーターフォールモデルでは、最初にすべての要件を決めてから順番に工程を進めるため、途中の変更に対応しにくいという課題がありました。
こうした課題を解決するために生まれたのがアジャイル（Agile）という開発の考え方です。アジャイルでは、短い開発サイクルを何度も繰り返しながら、少しずつ動くソフトウェアを作り上げていきます。この短い開発サイクルの1回分をイテレーションと呼びます。1回のイテレーションは通常1〜4週間程度で、その中で設計・実装・テストまでを一通り行います。
試験で出るポイント
イテレーションは「短い期間の開発サイクルを反復すること」です。過去問では「短い間隔でシステムの一部を開発・リリースし、それを繰り返していく手法」のように説明されます。
アジャイルマニフェスト ── アジャイルの根本にある価値観
Section titled “アジャイルマニフェスト ── アジャイルの根本にある価値観”2001年に、アジャイル開発を実践する17名のソフトウェア開発者が集まり、アジャイルマニフェスト（アジャイルソフトウェア開発宣言）を発表しました。これはアジャイルの根本にある4つの価値観をまとめたものです。
| 重視すること | よりも |
|---|---|
| 個人と対話 | プロセスやツール |
| 動くソフトウェア | 包括的なドキュメント |
| 顧客との協調 | 契約交渉 |
| 変化への対応 | 計画に従うこと |
右側の項目にも価値はありますが、左側の項目をより重視するという宣言です。たとえば、完璧な設計書を作ることよりも、実際に動くソフトウェアを早く届けることを優先します。また、最初に決めた計画に固執するのではなく、変化する顧客の要望を素早く取り入れることを大切にします。
試験で出るポイント
「ドキュメントよりも動くソフトウェアを重視する」「変化する顧客の要望を素早く取り入れる」はアジャイルの特徴として頻出です。プロトタイピング（試作品による要件確認）とは異なる概念なので混同しないようにしましょう。
ユーザーストーリー
Section titled “ユーザーストーリー”アジャイル開発では、要件を「機能仕様書」のような形ではなく、ユーザーストーリーという形で表現します。ユーザーストーリーとは、「〜として、〜したい。なぜなら〜だから」という利用者目線の短い文で、ソフトウェアに求められる機能を記述したものです。
たとえば、ECサイトの開発であれば次のようになります。
- 「購入者として、商品をカートに入れたい。なぜなら、まとめて購入したいから」
- 「管理者として、売上レポートを見たい。なぜなら、売れ筋商品を把握したいから」
ユーザーストーリーを使うことで、開発チームと顧客が「何のために、誰のために作るのか」を共有しやすくなります。
スクラム ── アジャイルの代表的な手法
Section titled “スクラム ── アジャイルの代表的な手法”スクラムは、アジャイル開発で最も広く使われている手法（フレームワーク）です。ラグビーの「スクラム」のように、チームが一丸となって開発を進めることに由来します。
スクラムでは、開発をスプリントと呼ばれる固定の期間（通常1〜4週間）で区切り、スプリントごとに動くソフトウェアを作り上げます。スプリントはイテレーションの一種で、スクラムにおける呼び方です。
スクラムチームの3つの役割
Section titled “スクラムチームの3つの役割”スクラムでは、チーム（スクラムチーム）を構成するメンバーに3つの役割を設けています。
| 役割 | 担当する内容 |
|---|---|
| プロダクトオーナー | 「何を作るか」の優先順位を決める責任者。顧客の要望を取りまとめ、プロダクトバックログを管理する |
| スクラムマスター | チームがスクラムのルールを正しく実践できるよう支援する役割。障害の除去やチームの改善を促す |
| 開発者 | 実際にソフトウェアを設計・実装・テストするメンバー。自律的にタスクを進める |
プロダクトオーナーは「何を作るか」を決め、開発者は「どう作るか」を決めます。スクラムマスターはチームの進行を助ける「サーバントリーダー」のような存在で、上司として指示を出す役割ではありません。
プロダクトバックログとスプリントバックログ
Section titled “プロダクトバックログとスプリントバックログ”スクラムでは、作業内容を管理するために2つのリスト（バックログ）を使います。
プロダクトバックログは、製品に必要な機能や改善項目をすべてリストアップし、優先順位をつけて並べたものです。プロダクトオーナーが管理し、顧客の要望や市場の変化に応じて常に更新されます。
スプリントバックログは、1回のスプリントで取り組む作業項目をプロダクトバックログから選び出したリストです。開発者がスプリントの開始時に「今回のスプリントではここまでやる」と決めた作業の一覧になります。
graph LR PB["プロダクト<br>バックログ"]:::primary SB["スプリント<br>バックログ"]:::base S1["設計"]:::base S2["実装"]:::base S3["テスト"]:::base INC["動くソフトウェア<br>（インクリメント）"]:::primary RETRO["ふりかえり<br>（レトロスペクティブ）"]:::alert PB -->|優先順に選択| SB SB --> S1 S1 --> S2 S2 --> S3 S3 --> INC INC --> RETRO RETRO -->|"改善を反映"| PB PB -->|"次のスプリント"| SB classDef base fill:#f8fafc,stroke:#94a3b8,stroke-width:1px,color:#333; classDef primary fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e40af; classDef alert fill:#fef2f2,stroke:#dc2626,stroke-width:2px,color:#991b1b;
試験で出るポイント
スクラムの問題では、3つの役割（プロダクトオーナー・スクラムマスター・開発者）と、2つのバックログ（プロダクトバックログ・スプリントバックログ）の違いが問われます。「プロダクトバックログ＝製品全体の要件リスト」「スプリントバックログ＝1スプリント分の作業リスト」と整理しましょう。
ふりかえり（レトロスペクティブ）
Section titled “ふりかえり（レトロスペクティブ）”ふりかえり（レトロスペクティブ）は、スプリントの最後にチーム全員で行う振り返りの活動です。「今回のスプリントでうまくいったこと」「改善すべきこと」「次のスプリントで試してみること」などを話し合い、チームの働き方を継続的に改善していきます。
ふりかえりは、ソフトウェアの品質だけでなく、チームの進め方やコミュニケーションそのものを改善するための仕組みであり、アジャイル開発の重要な特徴の一つです。
XP（エクストリームプログラミング）
Section titled “XP（エクストリームプログラミング）”XP（エクストリームプログラミング）は、アジャイル開発のアプローチの一つです。スクラムがチーム運営の枠組みに重点を置くのに対し、XPは開発の「技術的なプラクティス（実践手法）」に重点を置いています。
XPでは、以下のような特徴的なプラクティスが定められています。
テスト駆動開発（TDD）
Section titled “テスト駆動開発（TDD）”通常の開発では、プログラムを書いてからテストを行います。しかしテスト駆動開発（TDD：Test-Driven Development）では、この順番を逆にします。まず「このプログラムはこう動くべきだ」というテストコードを先に書き、そのテストが通るようにプログラムを実装します。
テストを先に書くことで、開発者は「何を作るべきか」を明確にしてからコードを書くことができ、不具合の少ないソフトウェアを効率的に開発できます。
ペアプログラミング
Section titled “ペアプログラミング”ペアプログラミングは、2人の開発者が1台のコンピュータを使って共同でプログラミングを行う手法です。1人がコードを書く「ドライバー」、もう1人がコードを確認しながらアドバイスする「ナビゲーター」の役割を交互に務めます。
2人で作業するため一見非効率に思えますが、コードの誤りをその場で発見できたり、知識やスキルの共有が進むといったメリットがあります。
リファクタリング
Section titled “リファクタリング”リファクタリングとは、ソフトウェアの外から見た動作（機能や仕様）を変えずに、内部のプログラム構造を改善することです。
たとえば、同じ処理が複数の箇所にコピーされている場合、それを1つの部品（関数）にまとめるといった作業がリファクタリングにあたります。外から見た動作は変わりませんが、コードが読みやすくなり、将来の変更や修正がしやすくなります。
リファクタリングで重要なのは、「バグ修正」や「新しい機能の追加」とは異なるという点です。あくまでも既存の動作はそのままに、コードの品質（保守性・可読性）を高める作業です。
試験で出るポイント
リファクタリングは「外部から見た動作を変えずに、内部構造を改善する」が定義の核心です。「機能仕様を変えずにプログラムの内部構造を改善すること」と問われたら、答えはリファクタリングです。バグ修正や機能追加と混同しないようにしましょう。
継続的インテグレーション（CI）
Section titled “継続的インテグレーション（CI）”継続的インテグレーション（CI：Continuous Integration）とは、開発者が書いたコードを頻繁に（1日に何度も）共有のリポジトリに統合し、そのたびに自動でビルド（プログラムの組み立て）やテストを実行する仕組みです。
従来の開発では、各メンバーが別々に作業を進め、最後にまとめて統合するため、統合時に大量の不具合が見つかることがありました。CIを導入することで、問題を早期に発見し、小さいうちに修正できるようになります。
アジャイルとウォーターフォールの違い
Section titled “アジャイルとウォーターフォールの違い”アジャイルの最大の特徴は、ウォーターフォールモデルとの対比で明確になります。ウォーターフォールが「最初にすべてを計画し、一方向に進める」のに対し、アジャイルは「短いサイクルを反復しながら変化に対応する」アプローチです。各開発モデルとの詳しい比較は、主なソフトウェア開発モデルのページにまとめています。
試験で出るポイント
アジャイルの特徴は「短期サイクルの反復」「変化への柔軟な対応」「動くソフトウェアの重視」です。XPはアジャイルの「アプローチの一つ」であり、アジャイル＝XPではありません。スクラムもアジャイルのフレームワークの一つです。また、スクラムとCMMI（ソフトウェアの成熟度モデル）は全く別の概念なので混同しないようにしましょう。
過去問で実力チェック
Section titled “過去問で実力チェック”過去問に挑戦
Q. アジャイル開発の特徴として，適切なものはどれか。
- ア 各工程間の情報はドキュメントによって引き継がれるので，開発全体の進捗が把握しやすい。
- イ 各工程でプロトタイピングを実施するので，潜在している問題や要求を見つけ出すことができる。
- ウ 段階的に開発を進めるので，最後の工程で不具合が発生すると，遡って修正が発生し，手戻り作業が多くなる。
- エ ドキュメントの作成よりもソフトウェアの作成を優先し，変化する顧客の要望を素早く取り入れることができる。
解答（令和元年）
正解: エ
Q. アジャイル開発において，短い間隔による開発工程の反復や，その開発サイクルを表す用語として，最も適切なものはどれか。
- ア イテレーション
- イ スクラム
- ウ プロトタイピング
- エ ペアプログラミング
解答（令和元年）
正解: ア
Q. 既存のプログラムを，外側から見たソフトウェアの動きを変えずに内部構造を改善する活動として，最も適切なものはどれか。
- ア テスト駆動開発
- イ ペアプログラミング
- ウ リバースエンジニアリング
- エ リファクタリング
解答（令和3年）
正解: エ
Q. アジャイル開発を実施している事例として，最も適切なものはどれか。
- ア AIシステムの予測精度を検証するために，開発に着手する前にトライアルを行い，有効なアルゴリズムを選択する。
- イ IoTの様々な技術を幅広く採用したいので，技術を保有するベンダに開発を委託する。
- ウ IoTを採用した大規模システムの開発を，上流から下流までの各工程における完了の承認を行いながら順番に進める。
- エ 分析システムの開発において，分析の精度の向上を図るために，固定された短期間のサイクルを繰り返しながら分析プログラムの機能を順次追加する。
解答（令和3年）
正解: エ
Q. XP（エクストリームプログラミング）の説明として，最も適切なものはどれか。
- ア テストプログラムを先に作成し，そのテストに合格するようにコードを記述する開発手法のことである。
- イ 一つのプログラムを2人のプログラマが，1台のコンピュータに向かって共同で開発する方法のことである。
- ウ プログラムの振る舞いを変えずに，プログラムの内部構造を改善することである。
- エ 要求の変化に対応した高品質のソフトウェアを短いサイクルでリリースする，アジャイル開発のアプローチの一つである。
解答（令和4年）
正解: エ