【アジャイル開発】XP（エクストリーム・プログラミング）の反復開発プロセス！「XPの流れ」

アジャイル開発の代表的手法である「XP（eXtreme Programming）」において、顧客と開発チームが協調して短いサイクルで開発を進める基本フロー（計画ゲーム ➔ イテレーション計画 ➔ イテレーション）のまとめカードです。

1. XPの開発プロセス（3つのステップ）

(1) 計画ゲーム（Planning Game）
・顧客：実装したい要求（ユースケース）を「ストーリーカード」に書き出す。
・開発者：各ストーリーの「優先順位付け」と「コスト（見積もり・工数）評価」を行う。

(2) イテレーション計画（Iteration Planning）
・選定されたストーリーを「具体的な開発作業（タスク）」に細分化・分割する。
・分割したタスクを担当メンバー（人）に割り当てる。

(3) イテレーション（Iteration：イテレーションの実行）
・開発サイクルの中で「テストケースの作成（TDD）」と「コードの作成（ペアプログラミング等）」を行う。
・完成したストーリー全体を検証・テストし、実際に動くソフトウェアとしてリリース（成果物の確認）する。

2. 各フェーズの役割とポイント

ステップ	主な作業内容	XPのプラクティスとの関連
(1) 計画ゲーム	顧客が「何を作るか（要求）」を決め、開発者が「コスト・工数」を見積もるコラボレーション。	オンサイト顧客（顧客の常駐・協調）、ユーザーストーリーの作成
(2) イテレーション計画	1〜2週間程度の短い反復単位で消化するタスクに分解し、各自に割り当てる。	小さなリリース（Small Releases）、作業のタスク化・可視化
(3) イテレーション	実際に設計・開発・テスト・検証・納品を行う開発サイクル。	テスト駆動開発（TDD）、ペアプログラミング、継続的インテグレーション（CI）

---

3. まとめ

XPでは、「計画ゲーム」で顧客と一緒にストーリー（要求）とコストを明確化し、「イテレーション計画」でタスクに分解、「イテレーション」でテストと実装を繰り返して迅速にリリースするというサイクルを回します。開発途中の要求変更にも柔軟に対応できるのが最大の特徴です！

【ソフトウェア開発】短サイクルで回せ！「テスト駆動開発（TDD）」のプロセス｜情報処理問題1000本ノック

システム開発において、プログラムを書く「前」にテストを作成する手法をテスト駆動開発（TDD：Test-Driven Development）と呼びます。TDDは一度に大きく作るのではなく、数分〜数十分単位の小さなサイクル（イテレーション）を何度も反復しながら高品質なコードを作り上げていくのが大きな特徴です。前後の工程も含めた基本的なプロセスを攻略しましょう。

■ テスト駆動開発（TDD）のサイクル：4つの基本ステップ

「まず不合格（Red）を確かめてから合格（Green）させ、美しく磨く（Refactor）」という視点で、それぞれの特徴を整理します。

ステップ	作業内容と目的	通称（状態）
1. テストコードを書く	実装したい機能の仕様（要件）に基づいて、先に自動テストコードを作成する。この時点では処理本体のプログラムは存在しない。	準備段階
2. テストの実施・失敗確認	テストを実行し、意図通り「不合格（失敗）」になることを確認する。テスト自体が正しく動作していること（誤検知しないこと）を確かめる重要プロセス。	Red（レッド）
3. コード実装・テスト合格	テストを合格させるためだけに最小限のコードを書く。綺麗さよりも、とにかくテストを通す（合格させる）ことを最優先する。	Green（グリーン）
4. リファクタリング	テストが合格した状態（動く保証がある状態）を維持しながら、コードの重複を排除し、構造を綺麗に整理する。	Refactor（リファクタ）

試験対策の重要キーワード＆前後の工程

• 前工程（要件の分解）：いきなりコードを書くのではなく、実装したい機能を「1つの小さな動作単位（数分〜数十分で終わるレベル）」に細かく分解してからステップ1に入ります。
• イテレーション（反復開発）：ステップ1〜4の1サイクルを「数分〜数十分」という超短時間で何度もグルグル回します。1つの機能ができたら、次の小さな機能のテスト作成へ進みます。
• リファクタリング（Refactoring）：外部から見たプログラムの動作（挙動）を変えずに、内部構造（読みにくさや重複）だけを改善する作業のことです。テストがあるおかげで壊す恐怖なく整理できます。
• 回帰テスト（レグレッションテスト）：後から機能を追加・リファクタリングした際、過去に作ったテストを一斉実行して「既存機能が壊れていないこと」をいつでも即座に検証できます。

※TDDは「プラモデルの説明書（テスト）を先に作ってから、パーツ（コード）を組み立て、最後にバリ取り（リファクタ）をして次のパーツに移る」というミニサイクルをひたすら繰り返すイメージを持つと分かりやすくなります。

【知識】顧客の「本当の欲しい」を引き出す！「要求獲得」の全貌｜情報処理問題1000本ノック（解説編）

システム開発の最上流工程であり、プロジェクトの成否を握る最重要局面「要求獲得（要求エライシテーション）」。単に言われたことをメモするのではない、本質的な知識を整理しましょう。

1. 要求獲得で「絶対に聞き出すべき」4つの本質

ステークホルダー（利害関係者）に対してヒアリングを行う際は、表面的な機能の要望（「画面にボタンが欲しい」など）ではなく、以下の根本的な問いをぶつけ、合意形成を行う必要があります。

・システムの目的は？（Why：なぜこのシステムを作るのか）
・何を達成したいの？（Goal：最終的なゴール、経営目標は何か）
・どんなビジネスニーズに対応するの？（Need：市場や業務のどんな課題を解決したいのか）
・システムがビジネスで、どう使われていくの？（Operation：現場でどのような業務フローになるのか）

---

2. 要求獲得が「極めて難しい」3つの理由

要求獲得は、システム開発の中で最も人間臭く、トラブルが起きやすい工程です。それには以下の3つの大きな原因が存在します。

1. スコープの問題
システム化の「境界線（どこまでやるか）」の設定が甘いと、「あれもやりたい、これもやりたい」とスコープが無限に広がっていき、予算と納期が崩壊します。

2. 要求や問題自体の問題
・利用者が、問題自体を正しく認識していない（何に困っているか、何が欲しいのかを自分たちで言語化できない）。
・立場（経営層、現場のリーダー、一般社員など）によって、問題のとらえ方が全く異なる。

3. 時間による変化の問題
ビジネス環境の変化、法改正、あるいは開発が進んで画面が見えてくることによって、要求は時間とともに必ず変化・追加される性質を持っています。

---

3. 要求獲得プロセスの「7つの実践ステップ」

要求を獲得し、仕様として確立するまでには、以下の一連のエンジニアリング作業を順番に進めていきます。

ステップ	作業内容
ステップ 1	ビジネスや技術の面から実現可能性を検討（フィージビリティスタディ）
ステップ 2	要求の定義および組織での役割の特定（誰がどの要求を出しているかの明確化）
ステップ 3	技術環境（アーキテクチャ等）の定義（システムを動かす土台の策定）
ステップ 4	ドメインの制約定義（業界ルールや法規制などの縛りの定義）
ステップ 5	要求獲得の技法の定義（インタビュー、ミーティング、観察など手法の決定）
ステップ 6	要求獲得、プロトタイプでの確認（試作品を見せて認識ズレを早期に解消する）
ステップ 7	ユースケースシナリオの定義（実際の利用シーンに沿った具体的な動きの落とし込み）

1. 理解のコツ: 顧客は「ドリル（機能）」が欲しいのではなく「穴（ビジネスの成果）」が欲しいのだ、という格言があります。要求獲得の難しさを突破するには、ステップ6にあるプロトタイプ（試作品）を素早く見せ、「欲しかったのはこれじゃない」を先に言わせることが最大の防御になります。
2. 試験対策の視点: 応用情報以上の高度試験（システムアーキテクトなど）では、「利用者は要件を正しく認識していない」という前提をもとに、それを解決するための「プロトタイプ」「ユースケース記述」「JAD（共同アプリケーション開発）」などの技法と絡めて、午後問題の記述や論文のテーマとして非常によく狙われます。

---

4. まとめ

「ステークホルダーの潜在的なニーズを引き出し、実現可能性や制約を考慮しながら、具体的な利用シナリオに落とし込んでいく一連のプロセス」。それが要求獲得です。ここでの妥協や認識ズレは、後々の工程（設計・テスト）で何十倍もの手戻りコストとなって跳ね返ってくるため、7つのステップを堅実に回していく管理能力が求められます。

【知識】プロジェクトの成功を導く！「開発手法」の全容｜情報処理問題1000本ノック

開発手法は、時代やプロジェクトの性質に合わせて進化してきました。大きく分けて「伝統的な手法」「アジャイル系」「品質・設計重視型」の視点で整理しましょう。

開発手法	一言説明（特徴・目的）
ウォーターフォール	要件定義から順に、上流から下流へ滝のように戻ることなく進める最も標準的な手法。
Vモデル開発	開発工程（左側）とテスト工程（右側）を対応させ、検証（検収）作業を明確にしたモデル。
スパイラル開発	設計と試作（プロトタイプ）を繰り返し、徐々にリスクを排除しながら螺旋状に規模を拡大する。
反復開発	システムを小さな単位に分割し、短期間のサイクル（イテレーション）を繰り返して完成させる手法の総称。
アジャイル開発	柔軟な計画と短期間の反復を重視し、顧客との対話を通じて動くソフトウェアを迅速に提供する手法。
XP (エクストリーム・プログラミング)	ペアプログラミングやテスト駆動開発など、技術的実践を通じて変化への対応力を高める。
クリスタル開発	プロジェクトの規模や重要度（色）に応じて、手法の厳密さを柔軟に使い分ける手法。
DSDM	時間の制約（タイムボックス）を優先し、ビジネス価値を迅速に届けるための英国発祥のアジャイル手法。
リーン	トヨタ生産方式を源流とし、徹底的に「ムダ」を省いて価値提供の効率を最大化する考え方。
構造化開発	機能を段階的に詳細化（トップダウン）し、プログラムを単純な構造の組み合わせで構築する手法。
オブジェクト指向開発	データと手続きを「オブジェクト」としてまとめ、再利用性や保守性を高める設計手法。
データ中心設計 (DOA)	機能よりも先に、変化しにくい「データの構造」に着目してシステムを設計する手法。
パターンベース開発	過去の成功例である「デザインパターン」などを再利用して、効率的に設計・開発を行う。
クリーンルーム開発	数学的検証に基づき、バグの混入を未然に防いで「無欠陥」のソフトウェアを目指す高品質重視の手法。
RAD (Rapid Application Development)	CASEツールやプロトタイプを用い、少人数で短期間にシステムを完成させることを目指す。
RUP (Rational Unified Process)	オブジェクト指向を基盤とし、ユースケース駆動・リスク中心で進める反復型の開発フレームワーク。
JAD (Joint Application Development)	ユーザーと開発者が一堂に会して集中討議を行い、合意形成を加速させる要件定義の手法。
PSP / TSP	個人のスキル向上（PSP）とチームのプロセス管理（TSP）を通じて、予測通りの納期と品質を達成する。

※これらの手法は独立しているわけではなく、たとえば「アジャイルという大きな枠組みの中にXPやリーンがある」といった関係性や、「オブジェクト指向という設計思想をウォーターフォールで使う」といった組み合わせが実際の現場ではよく見られます。

【知識】リズムと透明性でつくる！「スクラム」の重要用語｜情報処理問題1000本ノック

スクラムは、変化の激しい現代の開発において、短期間で成果を積み上げ、改善を繰り返すための強力なフレームワークです。各用語の意味を正確に理解し、開発の流れを攻略しましょう。

■ スクラムを構成する主要な要素

開発の単位、管理リスト、そして情報共有のためのイベントを整理します。

スプリント (Sprint)

アジャイル開発における反復（イテレーション）の単位です。通常「1〜4週間」の固定期間で実施され、その期間内で設計・開発・テストを行い、動くソフトウェア（インクリメント）を完成させます。

バックログ (Backlog)

顧客にとってビジネス価値がある開発機能の一覧です。主に以下の2段階で管理されます。

• プロダクトバックログ：製品全体の「やりたいこと（フィーチャー/ストーリー）」を優先順位付けしたリスト。
• スプリントバックログ：そのスプリント内で完了させるために、プロダクトバックログから抜き出し、具体的なタスクに分解した作業一覧。

タイムボックス (Timebox)

スプリントの期間を厳守する考え方です。スプリント期間中に対応するバックログの内容は、原則として変更されません。 これにより、チームは目の前の作業に集中し、確実に成果物を出し切ることができます。

デイリースクラム（スクラムミーティング）

毎日決まった時間に短時間（15分程度）で行う進捗確認です。以下の3点を中心に共有します。

1. 昨日（前回）は何をしたか？
2. 今日（次回まで）は何をするか？
3. 現在、直面している障害や困りごとはあるか？

試験対策の重要ポイント：3つの役割

スクラムには重要な3つのロールがあります。
★ プロダクトオーナー：製品価値の最大化とバックログの優先順位決定に責任を持つ。
★ スクラムマスター：スクラムの理解を助け、チーム内の障害を取り除く支援者。
★ 開発者（開発チーム）：実際に作業を行い、スプリント終了時にインクリメントを生み出す人々。

※プロダクトバックログは「夢や希望が詰まった大きなリスト」、スプリントバックログは「今週、確実に終わらせる戦術リスト」というイメージで使い分けを理解しましょう。