Introduction
顧客からの要望や仕様変更などに柔軟に対応できるアジャイル開発という開発手法が、多くの開発現場でとり入れられるようになりました。そのアジャイル開発のなかに、エクストリームプログラミング(XP)という開発の試みが存在します。最初に計画は立てるものの、臨機応変に開発を進めるというもので、開発者が顧客からの要望により柔軟に対応できるのがもっとも大きなメリットです。
この記事では、エクストリームプログラミング(XP)とはどのようなものなのか、エクストリームプログラミングの5つの価値やプラクティスについて解説します。
目次
エクストリームプログラミング(XP)とは

エクストリームプログラミング(XP)とはどのようなものなのか、スクラムとの違いや、エクストリームプログラミングを採用するメリットについて解説します。
開発に柔軟性をとり入れ、より大きな価値を提供するための開発の試み
エクストリームプログラミング(XP)とは、アジャイル開発が確立していく過程で議論されたさまざまな試みの集大成です。全体の作業を細かく区切り、開発の内容が変更されることを前提として進めます。すばやいリリースが必要な小規模開発に適しており、変化に柔軟に対応できるのが大きなメリットです。
そもそもアジャイル開発とはどのような開発手法なのかについてご説明します。アジャイル開発とは、設計、製造、テストという短いサイクルを繰り返すことで、仕様変更などに柔軟に対応できる開発手法です。
従来の要件定義、設計、製造、テスト、リリースという長いスパンの開発スケジュールを最初に細かく決定し、1回のサイクルでリリースまでを行う、ウォーターフォール開発の弱点を補うために生まれました。
ウォーターフォール開発は最初にスケジュールを決めてしまうため、計画が立てやすく、大規模開発に適しているというメリットがあります。一方で、開発途中の仕様変更や顧客からの要望などに対応しにくいというデメリットがありました。そのデメリットを克服するために生まれたのが、アジャイル開発です。
エクストリームプログラミングは、スピードとシンプルさを追求するアジャイル開発が確立していく過程で行われた試みの集大成で、5つの価値観と12のプラクティスによって成り立っています。この記事では、これらの内容について詳しく解説します。
アジャイル開発についてはこちらもご覧ください。
>>アジャイル開発とは?概要や進め方、ウォーターフォール型開発との違いやスクラムについて解説のページへ
スクラムとの違い
アジャイル開発の手法のなかには、エクストリームプログラミング以外にも、スクラムという手法があります。
スクラムは、プロジェクトの管理手法やチームの自己組織化などに重点を置いた開発手法です。スプリントと呼ばれる短い開発期間を設定し、繰り返していくことで開発を進めるのが特徴です。
スクラムでは、役割・イベントなどを定義することで、チームの作業を推進することを主眼にしています。一方でエクストリームプログラミングでは、技術的なプラクティスに焦点をあて、品質を向上して開発プロセスを改善する点が異なります。
スクラムについてはこちらもご覧ください。
>>スクラムとは?特徴やメリット、開発の流れをわかりやすく解説のページへ
エクストリームプログラミングのメリット
すでにご説明したとおり、エクストリームプログラミングは、プロジェクトに変更が生じることを前提としたものです。開発中に発生した顧客からのリクエストや仕様変更などに柔軟に対応できる点が、もっとも大きなメリットといえるでしょう。そのため、顧客やユーザーとのやりとりも多く行われます。
エクストリームプログラミングの特徴としては、柔軟な仕様変更に対応するためにソースコードの保守性を高めるプラクティスを数多く導入している、という点が挙げられます。また、ペアでプログラミングを行う「ペアプログラミング」、テストプログラムを先に作成してからプログラミングに入る「テストファースト」などの手法を導入することで、問題を早期発見できることもメリットです。
小規模プロジェクト、少人数チームで迅速な開発を行いたい場合に適しています。
エクストリームプログラミングにおける「5つの価値」
エクストリームプログラミングを採用する際に、知っておくべき「5つの価値」について解説します。
コミュニケーション(Communication)
プロジェクトの失敗の多くはコミュニケーション不足が原因です。そのため開発チーム内はもちろん、顧客とのコミュニケーションを重視する必要があります。
シンプルさ(Simplicity)
設計を極力シンプルにして基本的な機能のみを搭載し、開発を進めていくなかで必要に応じて追加していきます。
フィードバック(Feedback)
顧客やユーザーからのフィードバックを受けて、必要な機能を洗い出して実装します。これにより、無駄な機能を盛り込むことがないようにします。
勇気(Courage)
最初に計画は立てるものの、変更することが多く、開発途中で大胆な変更が求められることがあります。しかし、勇気をもってこれを決断します。
尊重(Respect)
チームで開発をスムーズに進めるためには、メンバー同士が互いを尊重しなければなりません。
エクストリームプログラミングの主要プラクティス

エクストリームプログラミングの主要なプラクティスについて解説します。
なおエクストリームプログラミングのプラクティスは、書籍として出版された時点からプラクティス自体が進化したり、現場で取捨選択したりして使われています。それぞれの現場にあった形で適用するのがよいでしょう。
共同プラクティス
エクストリームプログラミングに関わる全員を対象としたプラクティスで、以下の4つのプラクティスからなります。
・イテレーション
1~4週間程度の設計、実装、テストの作業単位をイテレーションと呼びます。これを何度も繰り返して、開発を進めていきます。
・共通の用語
共通の用語集を作成することで、コミュニケーションをとりやすくします。
・開けた作業空間
開発チーム内や顧客との間でコミュニケーションをとりやすい、開けた作業空間を構築します。
・回顧
一度発生したミスが再発しないよう、ミスの状況を明らかにして今後の作業に活かします。
イテレーションについてはこちらもご覧ください。
>>イテレーションとは?意味やスプリントとの違い、開発の流れについて解説のページへ
開発プラクティス
プログラマーなどを対象にしたもので、19のプラクティスが存在し、例として以下のようなものがあります。
・テスト駆動開発(TDD)
プログラムより先にテストコードを作成することで必要な機能が洗い出されて、シンプルな設計にすることが可能です。
・ペアプログラミング
二人一組でプログラミングを行うことで、一人がプログラミングを、もう一人がレビューをするため、プログラミング完了と同時にレビュー完了となります。その場で問題を発見できるため早期解決につながる、開発初心者の育成になるなどのメリットがあります。
・リファクタリング
完成したコードをわかりやすく書き換えることでメンテナンス性が向上し、不具合の発生頻度が低下する効果があります。
・ソースコードの共同所有
すべてのソースコードをチーム全員で共同所有し、誰でもコードに手を入れられる状態にします。これによりチーム全体で開発を進められ、メンバー内で知識の共有が進み、開発の一貫性が保たれます。
・YAGNI
「You Aren’t Going to Need It」の略で「いま必要なことだけをする」という意味です。将来の機能追加に配慮するようなことは考えず、余計なコードを排除し、いま必要な機能だけをシンプルに搭載します。
・継続的インテグレーション
コードを頻繁に統合してテストを自動化することで、品質を維持しながら、すばやい開発やリリースを可能にします。
顧客プラクティス
顧客が参加するプラクティスです。必要な機能の優先順位をつける重要な役割を担う存在として、顧客を開発に関わるチームメンバーとして扱います。「ストーリーの作成」「リリース計画」「短期リリース」「受け入れテスト」などのプラクティスがあります。
管理者プラクティス
開発の管理者を対象としたプラクティスです。開発が適切に進行しているか、メンバーへの負荷が大きすぎないかなどを把握して、チーム内で共有します。「責任の受け入れ」「擁護」「ミラー」「四半期ごとの見直し」などのプラクティスがあります。
エクストリームプログラミングを導入すべきケース
エクストリームプログラミングを導入すべきなのは、どのようなケースなのかについて解説します。
開発チームが少人数で構成される場合
エクストリームプログラミングは、少人数のチームで開発を行う際に適しています。10人以下のチームならコミュニケーションがとりやすく、迅速に意思決定して、柔軟に効率よく開発を進められます。
顧客の巻き込みが前提となる場合
顧客との距離が近く、顧客から頻繁に要望や意見を受けるような開発環境の場合にも適しています。エクストリームプログラミングは、顧客からのフィードバックを頻繁に受けとりながら開発に反映させることを基本としているためです。
柔軟に対応できるチームの場合
エクストリームプログラミングは、最初にスケジュールを細かく決めず、状況に応じて変化させていく開発手法です。そのため柔軟な対応ができ、対応力が高いチームでないとむずかしいでしょう。十分に技術や経験があるメンバーがいるチームに適しており、開発初心者が多いチームにはおすすめできません。
まとめ
エクストリームプログラミング(XP)とは、アジャイル開発が確立していく過程で議論されたさまざまな試みの集大成です。全体の作業を細かく区切り、開発の内容が変更されることを前提として進める点に大きな特徴があります。変化に柔軟に対応できるのが大きなメリットです。
従来の開発手法では顧客の要望に対応しにくい、新しいことをとり入れるためにアジャイル開発を導入したいと考える方も多いでしょう。
アジャイル開発を導入して、顧客のニーズや仕様変更に柔軟に対応できる開発を行いたい場合は、SHIFTのアジャイル開発支援(SHIFT 1LINE)をご活用ください。お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。
継続的なプロダクト開発に伴走する、SHIFTのアジャイル開発支援
「顧客の要望を迅速にとり入れられるアジャイル開発の手法を導入したい」「アジャイル開発手法を導入して顧客満足度の高い製品を開発したい」「アジャイル開発を導入したいが、社内にノウハウがない」などの悩みを抱えている企業様は多いかもしれません。
アジャイル開発は、従来のウォーターフォール開発よりも比較的新しい開発手法です。短いスパンの開発を繰り返すため、機能変更や機能追加に柔軟に対応できるというメリットがあります。
しかしアジャイル開発をスムーズに進めるためには、設計、実装、テストという短いスパンを繰り返して、つねにフィードバックを繰り返す必要があります。そのため、豊富な専門知識や経験、ノウハウが必要です。アジャイル開発に関する知識やノウハウがない状態で、アジャイル開発にシフトするのはむずかしいでしょう。
そこで、SHIFTのアジャイル開発支援(SHIFT 1LINE)をご活用いただければ、お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。短期的な人材確保や長期的な人材育成など、お客様のニーズにあわせて対応し、お客様のシステム開発に柔軟性とスピードをもたらします。

監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――