エクストリーム・プログラミングとは？特徴やメリット・デメリットを解説

エクストリーム・プログラミングは、アジャイル開発の1つの手法でXPとも呼びます。

エクストリーム・プログラミングの特徴は、要件定義からシステムのテストの工程までをイテレーションという単位で繰り返しおこない、品質を高めるプログラミング手法である点です。

このページでは、こうしたエクストリーム・プログラミングの由来や考え方（価値基準）と手法（プラクティス）を解説します。

エクストリーム・プログラミングとは

アジャイル開発とは

エクストリーム・プログラミングは、アジャイル開発の1つです。

アジャイル開発では、要件定義からテストまではすべて「イテレーション（反復）」を繰り返してアプリ・システムを完成させていきます。

イテレーションとは？スプリントとの違いや開発プロセスについて解説

アジャイル開発の特徴は、段階的にアプリ・システムを完成させていく点にあります。

このため、要件定義とテストを常に繰り返しているので、突発的な条件変更にも対応できます。

3種類のアジャイル開発

アジャイル開発には、主に以下の3つの種類があります。

いずれのアジャイル開発の手法も、プロジェクト全体の詳細な計画は立てずに短期間ごとに開発サイクルを繰り返す点は同じです。

このため、ウォーターフォール開発とは異なり、途中でプログラムの仕様変更が発生しても臨機応変に対応できる点が、アジャイル開発のメリットです。

スクラム開発とは

アジャイル開発の中で、最もポピュラーなスクラム開発は、チームを組んで役割やタスクを分担しておこないます。

スクラム開発では、コミュニケーションを取りながら開発を行うのが特徴です。

スクラム開発とは？意味や開発の手順、メリット・デメリットをわかりやすく解説

エクストリーム・プログラミングとスクラム開発の違い

エクストリーム・プログラミングとスクラム開発との大きな違いは、イテレーションを複数並行させて進めていく点にあります。

この他、以下の細かな点で違いがあります。

スクラム開発とエクストリーム・プログラミングの違い
	エクストリーム・プログラミング	スクラム開発
イテレーション・スプリントの進め方	イテレーションは、同一のプロジェクトで複数並行して進めることもある。	スプリント（スクラム開発でのイテレーション）は、同一のプロジェクトでひとつだけ進める。
イテレーションの長さ	１～4週間	2～4週間
イテレーション中の要件の変更	比較的容易。実装までの開発時間が同じであれば、他の要件と変更可能。	スクラムマスターがチェックするため、通常は変更は許可されない。
ユーザーストーリーを実装するためのイテレーションの優先順位	厳密な優先順位に従ってユーザーストーリーの実装のための作業をする必要がある。	プロダクトオーナーによってプロダクトバックログの優先順位は決められるものの、その開発のための優先順位は開発チームが決める。

このように、エクストリーム・プログラミングとスクラム開発では、イテレーション（スクラム開発ではスプリント）の期間、イテレーション中の要件の変更、イテレーションの優先順位など、異なる点もあります。

エクストリーム・プログラミングを導入するメリット

3種類のエクストリーム・プログラミングのメリット

エクストリーム・プログラミングを導入するメリットは主に3つ挙げられます。

ひとつずつ見ていきましょう。

メリット1：開発過程における要件定義の問題点の早期発見・早期対応ができる

エクストリーム・プログラミングを導入するメリットの1つめは、開発過程において要件定義の問題点の早期発見を早期対応ができる点です。

従来のウォーターフォール開発では、開発に着手する前に要件定義を確定させたうえで、テストまで一度におこないます。

このため、開発の進め方によっては、要件定義の問題点が開発終了間際に発覚する可能性がある、というデメリットがあります。

これに対し、エクストリーム・プログラミングは、イテレーションにより、「設計→開発→テスト→改善」のサイクルを短期間で繰り返します。

このイテレーションのサイクルにより、その都度テストをおこなうため、問題点に早めに気づき、修正等の対応も早期にできる、というメリットがあります。

メリット2：開発途中の仕様変更に柔軟に対応できる

エクストリーム・プログラミングの2つめのメリットは、開発途中であっても仕様変更に柔軟に対応できる点です。

アプリ・システムの開発には、委託者から受託者に対し要望で仕様変更を求める場合があります。

この点について、すでに述べたとおり、ウォーターフォール開発では、要件定義からテストまで一気通貫で開発をおこないます。

これにより、開発途中の仕様変更は、非常に難しく、仮に仕様変更をする場合は、追加での開発費用や時間が発生する可能性が高いです。

これに対し、エクストリーム・プログラミングでは、個々のイテレーションごとにテストを繰り返すため、委託者による仕様変更についても柔軟に調整できます。

メリット3：繰り返しテストを実行するためミスを軽減できる

エクストリーム・プログラミングの3つめのメリットは、イテレーションによるテストの繰り返しによりミスを軽減できる点です。

アプリ・システムの開発には、ミスの発生はつきものです。

この点について、従来のウォーターフォール開発では、ミスをミスとして認識できないまま開発が進み、取り返しがつかない状況になってからミスが発覚することがあります。

これに対し、エクストリーム・プログラミングでは、イテレーションごとに開発の状況をテストするため、ミスが軽減できます。

エクストリーム・プログラミングを導入するデメリット

エクストリーム・プログラミングを導入するデメリットは軽微ですが、まったく無いわけではありません。

具体的には、以下の2つが、エクストリーム・プログラミングのデメリットとなります。

それぞれ見ていきましょう。

長期スケジュールを組めない

エクストリーム・プログラミングのデメリットの1つめは、長期的なスケジュールを組めない点です。

これは、アジャイル開発全般に言えることです。

すでに述べたとおり、エクストリーム・プログラミングでは、常に短期間でイテレーションを回してテストをします。

この点から、短期間の作業の繰り返しでスケジュールを積み上げていくことになり、長期的な計画を立てづらくなります。

予算が増加する場合もある

エクストリーム・プログラミングのデメリットの2つめは、予算が増加する可能性がある点です。

これも、アジャイル開発全般に言えることです。

エクストリーム・プログラミングでは、委託者のニーズに合わせて開発をすすめていくため、委託者・受託者ともに、最終的な予算を把握しづらくなります。

特に、大幅な仕様変更をする場合は、追加で開発しなければならず、予算が増加する場合もあります。

エクストリーム・プログラミングで重視する5つの価値基準

エクストリーム・プログラミングでは、柔軟に対応できるように5つの価値基準を設けています。

ひとつずつ見ていきましょう。

1．コミュニケーション

エクストリーム・プログラミングでは、コミュニケーションが重要だと考えられています。

アプリ開発・システム開発が失敗する理由のひとつは、コミュニケーション不足が原因だからです。

委託者と受託者とのコミュニケーションや、開発者同士のコミュニケーションが不足していると、予定どおりのアプリ・システムが完成しない場合もあるでしょう。

この点について、エクストリーム・プログラミングでは、イテレーションの繰り返しにより、積極的にミーティングをおこないながらコミュニケーションを重視すると、認識のズレもなく重要事項を逃さずに対応できます。

2．シンプル

アプリ開発・システム開発では、委託者の要望などにより、仕様変更が発生することがあります。

仕様変更の原因は様々ですが、最初から複雑な開発をおこなうことが、仕様変更の大きな原因となります。

このため、最初の仕組みはシンプルに開発することを心がけましょう。

エクストリーム・プログラミングでは、まずはシンプルな機能を実装して、少しずつプログラムを整えていきます。

そうすることで、仕様変更が発生しても追加で開発しなければならない状況が減少するため、開発の負担も軽減されます。

3．フィードバック

このように、エクストリーム・プログラミングによるアプリ開発・システム開発では、プログラムは初期段階ではシンプルにしておきます。

そのうえで、イテレーションでは、委託者からフィードバックが重要となります。

エクストリーム・プログラミングでは、委託者は、受託者に対しアプリ開発・システム開発を丸投げせずに、積極的に開発に関与することとなります。

特に、このイテレーションの都度おこなうフィードバックにより、委託者が求めるアプリ・システムが開発チームに理解され、無駄な開発を防止できます。

4.勇気

エクストリーム・プログラミングは、アプリ開発・システム開発の委託者も巻き込んで開発を進めます。

また、仕様変更にも柔軟に対応するために、あえて綿密な計画を立てません。

このため、すでの述べたとおり、開発途中で大幅に仕様変更が発生する場合もあり、軌道修正を余儀なくされます。

こうした軌道修正は、時として委託者・受託者の利害が対立する原因ともなります。

しかし、良いアプリ・システムを開発するためには、委託者・受託者の双方に、すでに作成しているものを作り直す勇気が求められる場面もあります。

5．尊重

エクストリーム・プログラミングは、開発チーム内だけでなく、委託者・受託者もコミュニケーションを積極的に取って開発を進めていく手法です。

このため、委託者・受託者（開発者）の垣根を超えて尊重し、意見交換を重ねて開発を進めていきます。

エクストリーム・プログラミングでは、委託者と受託者は、対等の関係であり、上限関係ではありません。

この関係性により、お互いを尊重し、信頼することが、結果として良いアプリ・システムの完成に繋がります。

エクストリーム・プログラミングのプラクティスとは？

エクストリーム・プログラミングでは、開発チームの運用、プログラミング等の開発全般に関する手法、活動等の方法のことを、「プラクティス」と表現します。

エクストリームプログラミングのプラクティスには数・分類とも様々な考え方があります。

この点について、独立行政法人情報処理推進機構が平成25年3月に実施したアジャイル型開発におけるプラクティス活用事例調査では、45ものプラクティスについて調査がおこなわれました。

この調査では、アジャイル開発において適用率が高いプラクティスとして、次の4つが挙げられています（『アジャイル型開発におけるプラクティス活用事例調査調査概要報告書』p.12）。

これらは、スクラム開発とエクストリーム・プログラミングの両者に共通するプラクティスとされています。

以下、それぞれのプラクティスについて、解説していきます。

プラクティス代表例1：日次ミーティング

日次ミーティングとは？

日次ミーティングとは、開発チームが現在の問題・課題の共有・解決をするための日次のミーティングのことです。

エクストリーム・プログラミングでは、現状の状況（問題・課題）をお互いが共有できるように短いミーティングを実行します。

プラクティス名は日次ミーティングですが、別名デイリーミーティングともいい、また、朝会や朝礼がその機能を果たしていることもありります。

また、スクラム開発の場合は、「デイリースクラム」いいます。

日次ミーティングを実施するメリット

日次ミーティングを行うと次のようなメリットがあります。

日次ミーティングを行わないとお互いの進捗を共有できる時間を取れないので、日次ミーティングは必要不可欠です。

実際にさまざまな開発案件でも日次ミーティングは実施率の高いプラクティスです。

日次ミーティングを実施しないデメリット

日次ミーティングを実施しないデメリットも紹介します。

開発を進めるうえで、途中でシステムエラーが発生することもあるでしょう。

その際、ミーティングを実施していなければ障害報告をできる機会もないため、気が付いたら深刻な状況になっている場合もあります。

日次ミーティングを実施する時間と注意点

日次ミーティングを実施するうえでは、1回あたり15分程度を目安に、全員が集まって情報を共有しましょう。

この際、15分の間に全員の情報共有が完了できるように、必要最低限の情報を絞り込む必要があります。

1週間で2時間などではなく毎日15分程度しているのは、情報共有の時間が経過すると、共有する内容が増えてしまい時間を要するからです。

朝会や朝礼と呼ばれているのは、座って行うと時間が長くなってしまうため、立ったまま行うためです。

これらの立ったままおこなうミーティングを、「スタンドアップミーティング」と呼ぶことがあります。

なお、状況を共有するためにはタスクボードやかんばんなどのある環境でミーティングを実施するのが理想的です。

プラクティス代表例2：ふりかえり

ふりかえりとは？

ふりかえりのプラクティスは、イテレーションの結果について文字どおり振り返ることで、別名レトロスペクティブやリフレクション、内省、反省会とも呼ばれます。

すでに述べたとおり、アジャイル開発では、イテレーション毎に開発工程を区切って開発を進めます。

このイテレーションが終了した段階でおこなわれるプラクティスが、ふりかえりです。

アジャイル開発に慣れていない場合や、何が適した手法なのかわからない状態であれば、まずふりかえりのプラクティスから実行していきましょう。

ふりかえりが必要な理由・目的

アジャイル開発では、要件定義からテスト、実装までの幅広い開発工程を頻繁に繰り返し何度もおこないます。

このため、一度失敗したものでも同じ工程を繰り返してしまうリスクがあります。

アジャイル開発はでは、こうしたリスクを軽減するために、常に問題点について修正しながら開発を進めなければなりません。

ふりかえりをおこなう理由・目的は、このようなすでに発生した問題点を修正するためです。

ふりかえりを実施するメリット

ふりかえりの実施には、大きなメリットがあります。

イテレーション毎にふりかえりを実施すると、チームの開発プロセスを改善できるメリットがあります。

早期の比較的小さい失敗から学ぶことができ、大きな失敗をしにくくなる点もメリットといえるでしょう。

特に、問題を小さなうちに解決しておくことで、より大きな問題になる前に対処できます。

ふりかえりを実施しないデメリット

逆に、ふりかえりを実施しないと、メリットの裏返しとして、大きな失敗や問題が発生するデメリットがあります。

特に、チームの開発プロセスが改善できない点は、非常に大きなデメリットです。

アジャイル開発において、イテレーション毎におこなう開発は成功と失敗の繰り返しであるため、開発チームとしては、最初から最適なプロセスを実践することは困難です。

にもかかわらず、ふりかえりを実施せずに開発を続けると、非効率な実態のまま開発を続けざるを得なくなります。

ふりかえりを実施する方法と注意点

エクストリーム・プログラミングでは「内省」をチームで実施するのが原則です。

これに対し、スクラム開発では、スプリントレトロスペクティブとして、各スプリントの終わりに開発プロセスを改善することをプラクティスとして定義しています（いわゆる「スプリントレビュー」とは別です）。

いずれも、呼び方が違うだけであり、内容・実態・方法等は、それほど大きな違いはありません。

ふりかえりの実施方法としては、イテレーションの最後にチーム全員が集まり期間中に発生した出来事をふりかえります。

これらの検討材料により発覚した問題については、次のイテレーションにおいて改善案を実施し、効果を評価しています。

ポイントは、問題を列挙するのではなく、具体的な改善案を出して実践していくことが重要です。

ふりかえりを実施すると、イテレーション毎にチームの開発プロセスや規律を改善できます。

イテレーション毎にふりかえりができるため、早期の小さな失敗から学ぶことが可能で、大きな失敗をしにくくなります。

プラクティス代表例3：イテレーション計画ミーティング

イテレーション計画ミーティングとは

イテレーション計画ミーティングとは、イテレーション毎のリリース計画や、アクティビティ（タスクの集合）などを計画するミーティングのことです。

イテレーション計画ミーティングでは、システムやプログラムのリリース計画や、そのリリース計画を実行するためのアクティビティを、イテレーションに落とし込みます。

イテレーション計画ミーティングは、別名、計画ゲームやスプリント計画ミーティング、反復型計画とも呼ばれています。

イテレーション計画ミーティングが必要な理由

イテレーション計画ミーティングが必要な理由は、イテレーションを効果的・効率的に実施するために必要となるからです。

イテレーションを実施するためには、そのイテレーションで達成すべきゴールや、そのゴールを実現するために必要なタスクを洗い出す必要があります。

イテレーション計画ミーティングを実施することで、こうしたゴールやタスクを洗い出し、結果として、チームが開発を進めるために必要かつ具体的な計画を立てることが可能です。

イテレーション計画ミーティングを行うメリット

イテレーション計画ミーティングのメリットは、イテレーションをおこなうごとに、達成できるユーザーストーリーと、そのために必要なタスクや作業時間を効率よく見積もることができる、という点です。

また、ミーティングはチームで実施するため、イテレーションで何をしなければならないのか、全員が共有できる点もメリットです。

イテレーション計画ミーティングを行うデメリット

イテレーション計画ミーティングのデメリットは、チームにとって達成すべきゴールが明確でなければ、イテレーションの見積りを判断しづらい、という点です。

ユーザーストーリーの詳細が決定していない場合や、開発の完了条件が明確でなければ、イテレーション計画ミーティングの時間が長時間に及んでしまう可能性があります。

このため、エクストリーム・プログラミングにおいては、いかに達成するべきゴールが明確になっているかが重要といえます。

イテレーション計画ミーティングを実施する方法と注意点

イテレーション計画ミーティングの手順

イテレーション計画を実施する手順は以下の3つです。

なお、タスクの洗い出しはチーム全員で実施することが重要です。

また、イテレーション計画ミーティングでゴールを決めるのは、開発チームとプロダクトオーナーです。

ペロシティ計測・プランニングポーカーによりタスクを見積もる

イテレーションの作業時間の見積もりの調査は、別のプラクティスであるベロシティ計測やプランニングポーカーによりおこないます。

それでも難しい場合は、ユーザーストーリー自体を分割する必要があります。

なお、イテレーション計画ミーティングの時間は、イテレーション期間の5%程度の時間と考えましょう。

プラクティス代表例4：イテレーション

イテレーションとは

すでに述べたとおり、イテレーションとは、短い期間で工程を繰り返し、完成度を高めていく開発サイクルのことです。

イテレーションは、別名、タイムボックス、スプリント（スクラム開発の場合）、反復とも呼びます。

1つのイテレーションは最長でも4週間以内にすることが重要です。

なぜならば4週間を超えてしまうと、フィードバックの遅れによりリスクが増大するためです。

イテレーションが必要な理由

アジャイル開発において、開発チームが開始の段階でプロダクト（アプリ・システム）およびプロジェクトの必要な知識をすべて獲得しているわけではありません。

このため、タイムボックスとして1つの開発期間をイテレーションとして区切り、フィードバックを重ねながら開発を少しずつ進めることで、プロダクト（アプリ・システム）およびプロジェクトの知見を深めていきます。

また、プロジェクトを開始してから起こる変化が予想できない場合、短めの期間を設定し、何度も繰り返して開発を進めるイテレーションの特徴が重要となります。

こうしたイテレーションの特徴により、予想外の変化が発生したとしても、エクストリーム・プログラミングの場合は、早期かつ柔軟に対応ができます。

イテレーションをおこなうメリット

イテレーションのメリットは、短期間で区切ったイテレーションを実行していく中で、獲得できた知識や反省点を次のイテレーションに活かして改善できるのが点です。

その結果、イテレーションをおこなうごとに達成できるユーザーストーリーと、そのために必要なタスクや作業時間を効率よく見積もることができます。

イテレーションをおこなうデメリット

イテレーションのデメリットは、ユーザーストーリーが決定していない場合や、開発条件が明確でなければ、イテレーションの見積もりが甘くなってしまう点です。

このため、エクストリーム・プログラミングにおいては、いかにユーザーストーリーや開発条件を明確にするかが重要となります。

また、それぞれのイテレーションの期間は最長でも4週間ほどと短く、全体の進捗を把握しづらい点もイテレーションのデメリットといえます。

このため、エクストリーム・プログラミングは、大規模なシステム・アプリの開発には向かない場合もあります。

イテレーションを実施するときの注意点

イテレーションを実施するときの主な注意点は、以下の2つです。

イテレーションは、決まった期間内で実施し、期間内に間に合わなかったタスクや、完了しなかったタスクがあるからといって、延長はしません。

こうした未完のタスクは、「未完であったこと」そのものがふりかえりの検討材料となり、作業の改善のキッカケになります。

また、そもそも未完のタスクは、開発チームの作業量が多いために発生するものです。

このため、イテレーション計画ミーティングにおいて、1回のイテレーションで対応できる量を正確に見積もることが重要となります。

イテレーションに関連するプラクティス

なお、この記事で紹介したプラクティスを含め、イテレーションに関連するプラクティスには、以下のものがあります。

まとめ

エクストリーム・プログラミングのプラクティスは、同じアジャイル開発の一種であるスクラム開発とミックスして利用する方法もあります。

いずれの開発手法も、短期間ごとのイテレーションやスプリントの実行により、顧客の要望に臨機応変に応えられる点が従来の開発手法と異なる点です。

エクストリーム・プログラミングもスクラム開発も、開発規模としては小規模~中規模のアプリ開発に適しています。

エクストリーム・プログラミングにはプラクティスが数多くありますが、開発規模やチーム編成により適切なプラクティスと、うまくいかないプラクティスがあります。

独立行政法人情報処理推進機構が平成25年3月19日に実施した、[アジャイル型開発におけるプラクティス活用事例調査調査報告書]には、さまざまなプラクティスが掲載されています。

これからアジャイル開発を検討している方は、ぜひ参考にしてください。

エクストリーム・プログラミングについてよくある疑問

エクストリーム・プログラミングとは何ですか？

エクストリーム・プログラミングとは、アジャイル開発の一種です。開発チームのコミュニケーションを重視し、設計は極力シンプルに、かつ顧客からのフィードバックを重視する開発手法です。最初の段階では綿密な計画を立てずに、顧客の要望にスムーズに応じられるメリットがあります。

エクストリーム・プログラミングとスクラム開発の違いは何ですか？

エクストリーム・プログラミングとスクラム開発は、それほど大きな違いがありませんが、エクストリーム・プログラミングはイテレーションを複数並行させて進めていくこともできるのに対し、スクラム開発はスプリント（スクラム開発のイテレーション）をひとつだけ進めていく点が違います。