エクストリームプログラミングとは｜特徴やメリットを分かりやすく解説！

近年は、アジャイル開発が多用されるようになり、その中でも、エクストリームプログラミングと呼ばれる手法が利用されるようになりました。これは顧客の要望を取り入れつつ、要件定義からテストまでの工程を繰り返し、開発の品質を高めるものです。アジャイル開発には似たような考え方が多くあるため、他の開発手法と誤って理解している人もいるでしょう。

今回は、エクストリームプログラミングがアジャイル開発の中でもどのような手法であるのか解説します。加えて、採用するメリットなども解説するため、それぞれ順番に理解していきましょう。

エクストリームプログラミングの概要

エクストリームプログラミングは、アジャイル開発における開発手法です。省略してXPと呼ばれることもありますが、どちらも同じものを指すと理解しましょう。一般的に、アジャイル開発は最初から要件定義などを完了させることなく、流動的にかつ臨機応変に開発を進めることが特徴です。要件定義こそ完了させることはありますが、設計からテストまでを短期間で繰り返し、クライアントの要望やフィードバックをその都度反映していきます。この中で設計や実装テストまでのサイクルをiterationと呼ぶことを押さえておきましょう。

ただ、開発にあたって、とにかくクライアントの要望やフィードバックを受け入れるだけでは、いつまでも作業が完了しません。そのため、アジャイル開発ではスクラムと呼ばれる短い開発サイクルを何度も繰り返すフレームワークを採用することが一般的です。エクストリームプログラミングもスクラム開発に近いものではありますが、スクラム開発ほど短いサイクルを繰り返すものではありません。比較的長いサイクルで少しずつプログラムの完成を目指す進め方だと理解すればよいでしょう。具体的な特徴については以下でも解説します。

エクストリームプログラミングの特徴

エクストリームプログラミングを採用することで、以下の特徴が感じられると考えられています。

コミュニケーションを取りやすい

エクストリームプログラミングは、開発チームやクライアントとのコミュニケーションを重視していることが特徴です。システム開発における失敗の原因として、コミュニケーション不足は非常に大きなものと考えられます。これを解決しやすい開発手法であることが、エクストリームプログラミングの特徴です。

特に重要なのは、チーム内だけではなく、クライアントとのコミュニケーションを重視する点です。同じアジャイル開発でも、スクラム開発はチーム内のコミュニケーションに力を入れて進めていきます。そのため、クライアントと接触する機会は一部に限られてしまうというデメリットがあります。エクストリームプログラミングはスクラム開発ほど素早さはないものの、クライアントと接点を持ちやすく、コミュニケーションを取りながら進める時間的な余裕もあります。

シンプルな開発から進める

アジャイル開発全般に言えることですが、エクストリームプログラミングでは、可能な限りシンプルな開発からスタートします。仕様が複雑であればあるほど、準備に時間がかかり、失敗の可能性が高まってしまうからです。まずは可能な限りシンプルな要件に落とし込み、そこからアジャイル開発らしく、追加の機能を組み込んでいきます。必要な機能についても、最初から全ての要件を出すのではなく、優先度の高いものから順番に実装していくことが一般的です。

シンプルな設計からスタートできる理由は、上記でも触れた通り、コミュニケーションの機会が多いからとも言えます。クライアントと積極的なコミュニケーションを取る時間の余裕があるため、フィードバックや要望を受けて、開発の見直しができるのです。ウォーターフォール型開発の場合は、要件の吸い出しなどに限界がありますが、エクストリームプログラミングでは、比較的余裕があると言えます。

機能の追加や拡張に対応しやすい

クライアントからフィードバックを受ける時間的な余裕があるため、機能の追加や拡張に対応しやすいことが特徴です。要件が不確定な状態でも、実際に開発したものを確認してもらいながら、最終的な形を作り上げられます。アジャイル開発の良さを最大限引き出せる開発手法と考えてよいでしょう。

ただし注意点として、要望やフィードバックを受けすぎることで、開発期間が長引いてしまう可能性が考えられます。また、開発期間が長引いてしまうことでコストが増加することもあるでしょう。要望を反映しやすいということは、特徴であり、メリットでもありますが、同時にデメリットにもなってしまうのです。

とはいえ、不要な機能をそぎ落とし、必要な機能を実装するということは、ソフトウェア開発の基本と考えられます。これを実現できるエクストリームプログラミングは、理論としては合理的なものと考えるべきでしょう。

急激な変化が生じる可能性がある

ウォーターフォール型開発のように、事前に要件定義が完了しているものではありません。そのため、開発の過程で要件が大きく変化することがあります。例えば、一部の機能を実装した結果、要件の考慮漏れが発生していたことが判明すると、根本的な見直しが必要となるのです。ウォーターフォール型ではあり得ないようなことが起こり得るのも、エクストリームプログラミングの特徴です。

また、アジャイル開発は明確な開発期間が定められていないことがあります。これも影響し、リリースを先延ばしにして、実装を変更するという選択が取られる可能性があるのです。リリース日が決まっていればそこに合わせて開発しますが、アジャイル開発やエクストリームプログラミングの場合は、リリースを先延ばししてしまうのです。

エクストリームプログラミングにおける4つのプラクティス

続いては、エクストリームプログラミングにおけるプラクティスを解説します。プラクティスとは一般的に慣習となっている手法を指します。アジャイル開発においては、プロジェクトを実現するために必要となる手段や取り組みだと理解しましょう。エクストリームプログラミングのプラクティスは大きく四つに分かれます。

共同プラクティス

共同プラクティスは、エクストリームプログラミングに関わる全員が意識しなければいけない内容です。プロジェクトを円滑に進めるために、以下の観点を理解しておきましょう。

• 反復：1つのイテレーションを何度も繰り返しながら実施する
• 用語：用語集を作成し認識齟齬を防止する
• 作業空間の確保：開けた空間の確保によりコミュニケーションを強化する
• 回顧：定期的な振り返りによりミスの再発を防止する

開発プラクティス

開発プラクティスは、プログラマーやシステムエンジニアなど、開発に関わる人々が理解すべきプラクティスです。具体的には、以下を履行しなければなりません。

• テスト駆動開発
• ペアプログラミング
• リファクタリング
• YAGNI(You Aren’t Going to Need It)

管理者プラクティス

開発プロジェクトを取りまとめる管理者が理解すべきプラクティスです。一般的なプロジェクトにおけるプロジェクトマネージャーではなく、開発チームのリーダーのような役割を負う人に向けた内容と考えてください。重要なのは、状況を把握して適切に開発できるかどうかを見極めることです。また、責任を受け入れることが求められるため、自分の責任で開発が進められるかどうかも、常に評価しなければなりません。失敗する可能性があるならば、リスクを素早く検知してクライアントに共有するなどの対応が求められます。

顧客プラクティス

顧客が理解しておくべきプラクティスも定められています。エクストリームプログラミングでは、顧客も開発チームの一員であるため、積極的に協力しなければなりません。例えば、顧客は積極的に機能を吟味して、開発の優先順位を決定する義務があります。また「いつまでにリリースするか」「コストをいくらに抑えるか」などを決定して、開発メンバーに伝えることなども求められるのです。

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

エクストリームプログラミングには、次に挙げるようなメリットがあります。

ソフトウェア品質の向上

ペアプログラミングを活用することによって、ソースコードのリファクタリングがスムーズに実施できます。その結果、ソフトウェアの品質向上を実現できることがメリットです。2人の開発者が相互にソースコードを閲覧することになるため、プログラムに含まれているバグなどを見つけやすいことが背景にあると考えましょう。

また、テスト駆動型開発を採用しているため、事前のテストに基づいたソースコードを記述します。これにより、そもそもバグの少ないソースコードやアルゴリズムを実現できるため、なおさら品質の高い開発を実現できるのです。

開発スピードの向上

短いイテレーションで開発とリリースを繰り返すため、開発スピードの向上につなげられます。その結果、ユーザーのフィードバックを迅速に反映したり、バグを速やかに解消したりすることが可能です。どちらについても、開発スピードを向上させる取り組みと考えられます。

また、エクストリームプログラミングでは顧客も開発メンバーの一員と位置付けられています。積極的なコミュニケーションをとることが求められており、コミュニケーション不足による開発遅延が発生しないことがメリットです。

エクストリームプログラミングを採用する際の注意点

これまでエクストリームプログラミングの特徴などを解説しましたが、採用にあたっては注意点もあります。上記で部分的に触れた内容も含まれますが、改めて解説します。

スケジュールが明確になりづらい

エクストリームプログラミングはスケジュールが明確になりづらいという注意点があります。要望やフィードバックを受け入れているうちに、開発期間が長引いてしまい、当初の計画を達成できなくなるからです。そのため、最初から明確な規律を求めずにスタートすることになってしまい、リリース日なども把握できなくなってしまいます。可能な限り、小さな単位でリリースすることが心がけられますが、システム全体がリリースされるタイミングとなると話は変わってしまうのです。

今までウォーターフォール型開発しか体験していないと、エクストリームプログラミングは馴染みがないものになってしまうでしょう。素早く変化したり、短期間で納期を迎えてしまう進め方に慣れないことも考えられます。その結果として、短いサイクルでの開発すら守れなくなり、開発期間が延びてしまうこともあるのです。

予算が変動しやすい

予算が変動しやすいことも注意点です。クライアントのニーズに合わせて、システムの開発ができますが、要望やフィードバックが増えすぎるとコストが際限なく増えてしまいます。エクストリームプログラミングにおいては、事前に予算の上限を設けておき、その範囲内で対応することを心がけなければなりません。

ただ、ここで考慮しなければならないことは、予算内で求めているシステムが開発できるとは限らないことです。ウォーターフォール開発の場合は、事前に要件が定まっているため、開発されるものの結果が明確です。それに対して、エクストリームプログラミングは、どこまで開発が完了するか誰にもわかりません。そのため、予算の上限を定めてしまうと、使い物にならないシステムのまま終わってしまうこともあるのです。とはいえ、コストを際限なくかけてシステム開発することができないため、ある程度は見切りをつけておかなければなりません。

まとめ

エクストリームプログラミングはアジャイル開発の手法であり、クライアントの要望やフィードバックを受けながら開発するものです。ウォーターフォール型開発とは異なり、事前に要件などを全て決定するのではなく、開発しながら決定していきます。この点はアジャイル開発共通の観点と考えておきましょう。

アジャイル開発といえばスクラムと呼ばれる手法が採用されがちですが、こちらはスピード感を重視したものです。それに対して、エクストリームプログラミングは、コミュニケーションを重視しています。コミュニケーションの中には、クライアントも含まれるため、クライアントも協力的になり、プロジェクトを進めていかなければなりません。この点で、スクラムでの開発とは大きく異なっていることもポイントです。