エクストリームプログラミング(XP)とは？アジャイル開発との違いやメリット、デメリットについて解説！

エクストリームプログラミング（XP）という開発手法についてご存知でしょうか？単語は聞いたことがあっても「エクストリームプログラミングって何？」「アジャイル開発と何が違うの？」といった疑問を持つ人も少なくないでしょう。

本記事ではエクストリームプログラミングとは何かを解説し、アジャイル開発との違いについても解説していきます。

アジャイル開発って何？

アジャイル開発とは、「素早い」「機敏な」といった意味のアジャイル（Agile）という単語が名前の由来となっている、システム開発の手法の一つです。「仕様変更に強く」「開発速度が速い」のが特徴です。

従来の開発手法ではシステム全体の要件定義を行なった後、システム全体の設計を行い、設計された情報を基に実装を行い、全ての開発が終わってからテストを行なっていました。このような開発を「ウォーターフォール開発」と呼びます。

「ウォーターフォール開発」については以下の記事で詳しく解説しています。
ウォーターフォール開発の特徴とは？メリット・デメリットもわかりやすく解説！

アジャイル開発の特徴

アジャイル開発の特徴は「仕様変更に強く」「開発速度が速い」ことです。

アジャイル開発では従来の開発手法とは違い、システム全体ではなく「機能単位」で「計画→設計→実装→テスト」の工程を繰り返して開発を行います。反復 (イテレーション) と呼ばれる一週間から一ヶ月ほどの短い開発期間単位の中で、どの機能を開発するかを決定し、開発する機能の要件をまとめて開発を行い、実装した機能の検証を行います。テスト後、実装に問題がなければ新たな機能へ、要望や仕様変更があれば新しい反復の中で更なる機能追加を行う、というように柔軟に開発を行うことができます。

エクストリームプログラミング(XP)って何？

エクストリームプログラミング（XPともいいます）とは、アジャイル開発手法の1つで、変化に対応しやすい柔軟な開発手法です。

プログラム開発では、開発している最中に仕様変更が起こったり、思うようにタスクが消化できずにスケジュール修正が起こる場合が多々あります。エクストリームプログラミングではそういった変化が起こることを前提とし、後述する「5つの価値基準」と「19のプラクティス」と呼ばれるものを実践することで、変化に対応します。

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

エクストリームプログラミングでは「変化」が起こることを前提とし、柔軟に対応することができる開発手法です。柔軟に対応するために、エクストリームプログラミングでは「5つの価値基準」と「19のプラクティス」と呼ばれるものを重視します。

開発で重視すべき「5つの価値基準」とは？

コミュニケーション

エクストリームプログラミングでは、プロジェクトが失敗する原因の一つとして、コミュニケーションが不足することをあげています。システム開発者と顧客の間でシステムに対する認識が間違っていれば作り直しが発生したり、完成したものが満足度の低いものになることもあります。また、開発者同士でのコミュニケーションが不足すると、必要な情報が連携されず、重大な問題になってしまうこともあります。そのため、エクストリームプログラミングではコミュニケーションを積極的に取ることで、より良い開発ができると考えます。

シンプル

仕様変更が発生しがちなシステム開発において、シンプルな仕組みでシステムを開発することに重きを置きます。考えられる仕組みを考慮し、最初の開発でその全てを実装するよりも、必要最低限なシステムを作成し、仕様変更があった場合に追加で手を加える方が負担が少ないと考えます。そのため、エクストリームプログラミングではシンプルな実装に価値を置いています。

フィードバック

開発したシステムのフィードバックをもらうことで、必要な機能を明確にすることができ、無駄な機能開発が少なく済みます。シンプルな機能のみを実装したものに対して必要なフィードバックをもらい、フィードバックに合った機能を実装する、この工程を繰り返すことで、開発したシステムが無駄のないシンプルなシステムになります。

勇気

エクストリーム開発では、従来のウォーターフォール開発と違い綿密な計画を立てません。そのため、開発中に大きな仕様変更が起こることもあり、既に作成した機能を大幅に変えなければいけない時がくるかもしれません。そういった場合、既に作ったものを作り直すために勇気が必要になります。

尊重

コミュニケーションを積極的に行う上で、開発者同士や顧客でお互いの意見や姿勢を尊重する必要があります。異なる意見を交える時、相手を尊重する気持ちがないと自分の意見のみを押し通そうとしてしまい、関係が不和になってしまったりすると、コミュニケーションも発生しづらくなってしまいます。そのため、相手のことを尊重し信頼することが必要です。

エクストリームプログラミングを実践するための19の「プラクティス」とは？

エクストリーム開発では、「プラクティス」と呼ばれる習慣や実践内容が存在し、これらを行うことでエクストリームプログラミングを行なった、と言えるようになります。

プロジェクトに関わる関係者を3つに大別し、「開発のプラクティス」「管理者のプラクティス」「顧客のプラクティス」に分け、またその全てにかかる「共同のプラクティス」という4つのプラクティスに分類されます。更にそれぞれのプラクティスの中に4〜6つの実践内容があり、それらを合計した19の実践内容が「プラクティス」となります。

19のプラクティス

対象者	主な内容	実践内容（プラクティス）
開発のプラクティス	開発に関する実践内容	テスト駆動開発 ペアプログラミング リファクタリング ソースコードの共同所有 継続的インテグレーション YAGNI
管理者のプラクティス	短期間で開発を行うため、チームの負荷が適切か、また開発そのものを適切に管理するための実践内容	責任の受け入れ 援護 四半期ごとの見直し ミラー 最適なペースの仕事
顧客のプラクティス	ビジネス的視点から必要な機能を考え、開発の優先順位をつけるための実践内容	ストーリーの作成 リリース計画 受け入れテスト 短期リリース
共同のプラクティス	関係者全員に関わる実践内容	反復 共通の用語 開けた作業空間 回顧

 

今回は特徴的なプラクティスを5点紹介します。

テスト駆動開発（開発のプラクティス）

テスト駆動開発とは、テストを先に作成することで必要な機能を明確にし、そのテストに合格するようなシンプルなシステムを開発する手法のことです。テストに合格するようにシステムを作成し、作成した後にリファクタリングという作業を行い、無駄なコードを削ることでシンプルな実装を行うことができます。

ペアプログラミング（開発のプラクティス）

ペアプログラミングとは二人一組でプログラミングを行うことです。一人がコードを書き、もう一人がコードのレビューを行なったり、仕様書を基にどういった開発を行うかといったナビゲーターの役割を担います。コードレビューが即時行われるため、エラーの早期発見などにもつながり、またコード全体の質も良くなります。

YAGNI（開発のプラクティス）

YAGINIとは「You Aren’t Going to Need It」を略したもので、「今必要なことだけを行う」という考え方です。「5つの価値基準」の「シンプル」に関連します。エクストリームプログラミングでは「必要そうな機能」を作成するより「最低限の機能」を実装した後、必要があれば手を加えて機能を追加していくことを是としています。

最適なペースの仕事（管理者のプラクティス）

エクストリームプログラミングでは短期間に開発を行います。そのため、チーム関係者への負荷が適切か、詰め込みすぎた開発となっていないかを判断します。短期開発を行う際、開発の期間が短いため負荷がかかりがちになってしまい、関係者のパフォーマンスが十二分に発揮できない可能性があります。そういった問題に陥らないために管理者は最適なペースで仕事をできているかを管理する必要があります。

ストーリーの作成（顧客のプラクティス）

エクストリームプログラミングでは顧客も関係者の一人として扱い、本当に必要な機能を作成するためにストーリーを作成します。ストーリーを作成することで開発者、顧客共にどのような機能が必要なのかが明確になります。そのため、ストーリーに合致したシンプルな実装が可能になり、機能を追加する際にも不要な機能を盛り込む可能性が少なくなります。

アジャイル開発との違い

エクストリームプログラミングはアジャイル開発の一種になります。アジャイル開発には、エクストリームプログラミングの他にも「スクラム開発」「ユーザー機能駆動開発（FDD）」などの開発手法があります。

エクストリームプログラミングはアジャイル開発を行うためのフレームワークであり、数あるアジャイル開発手法のうちの一つがエクストリームプログラミングなのです。

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

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

「柔軟性」のある開発が可能

エクストリームプログラミングのメリットは「柔軟性」のある開発ができることです。システム開発では開発の過程で仕様が変更されたり、フィードバックを受けて開発したものを修正、変更することは多々あります。エクストリームプログラミングではシンプルな実装が前提となっているため機能追加が行いやすく、柔軟な開発が可能です。

エラーの早期発見が可能で、実装がシンプルになる

ペアプログラミングを行うことで、エラーの早期発見が可能です。また、テスト駆動開発を行うため実装内容がシンプルになりやすく、エラーの原因となる機能が少なくなりやすいです。

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

作業全体が把握しづらい

エクストリームプログラミングは迅速な開発が行える一方で、「全体の作業が把握しづらい」というデメリットがあります。変化を前提とするため、システムの最終目標が決まっていても機能ごとにどういった仕様にする、というのが明確になっていないこともあります。そのため、エクストリームプログラミングでは全体の作業を把握するのは難しいです。

開発者の技術的水準が高い

ペアプログラミングを行う性質上、開発者にはある程度の技術力が求められます。コードを書く技術もそうですが、コードレビューを行うための知識や、システムの仕様を俯瞰的に把握し、問題点を見つけるための力が必要です。

変更が前提となるシステム開発において有用な開発手法

エクストリームプログラミングは「計画→設計→実装→テスト」を短期間で行うアジャイル開発手法の一つで、従来のウォーターフォール開発と異なり、変更を前提とした開発手法であることを解説してきました。

仕様変更などに柔軟に対応ができる反面、作業全体が把握しづらく、また関係者に求められる技術水準も高くなってしまうデメリットもあります。しかし、迅速に開発を行いリリースを行いたい、いち早く開発を行いたいといったプロジェクトでは有用な開発手法と言えるでしょう。

開発したいプロジェクトの性質を踏まえ、エクストリームプログラミングを行うのか、別の開発手法を選択することでよりよい開発が行えるでしょう。