アジャイル
アジャイルとは何か
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回のスプリントで取り組む作業項目をプロダクトバックログから選び出したリストです。開発者がスプリントの開始時に「今回のスプリントではここまでやる」と決めた作業の一覧になります。
試験で出るポイント
ふりかえり（レトロスペクティブ）
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 “アジャイルとウォーターフォールの比較”アジャイルの特徴をより理解するために、ウォーターフォールモデルと比較してみましょう。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 開発の進め方 | 工程を順番に進める | 短いサイクル（イテレーション）を反復 |
| 要件の変更 | 変更しにくい | 変更を歓迎する |
| 成果物の確認 | 開発の後半で確認 | スプリントごとに動くソフトウェアを確認 |
| ドキュメント | 各工程で詳細な文書を作成 | 動くソフトウェアを重視 |
| 向いているプロジェクト | 要件が明確で変更が少ないもの | 要件が変化しやすいもの |
試験で出るポイント