エクストリームプログラミングとは一体？わかりやすく解説してみた

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

そもそもエクストリームプログラミングとはどういうものなのでしょうか。

エクストリームプログラミングとはケント・ベック氏が1999年に発表したアジャイル開発の開発手法です。さすがにこれだけ聞いてもピンとこないと思います。エクストリームプログラミングを知るにはまずソフトウェア開発手法を知る必要があります。

従来のソフトウェア開発手法として一番主流だったのは「ウォーターフォールモデル」という開発手法で、これは水が高いところから低いところへ順番に流れていくように、システム開発を企画→要件定義→設計→プログラム開発→テストの開発工程に分けて、順番に進めていく開発手法です。

このモデルの特徴は基本的には前の工程には戻らないということです。そのため、確実性の高い開発現場では特に問題はありませんが、不確定要素のある現場や、上流工程がしっかりしていなかった現場などでは注意が必要となります。例えば、テストまで行って不具合が見つかり、要件定義まで戻らなければならない場合、要件定義からテストまでをもう一度行う必要があり、莫大なコストが必要になります。

このウォーターフォールモデルに対し、アジャイル開発というものがあります。ウォーターフォールでは要件定義などの工程が１００％完了すれば次の工程に移るのに対し、アジャイル開発では要件定義からテストまでをイテレーション（反復）という単位で何度も行うことで開発の精度を高めていきます。たとえば、イテレーション１で要件定義からテストまで３０％ほど完成させ、イテレーション２で６０％、イテレーション３で完成という感じです。

イテレーションで全工程をある程度進めることで見えてくる問題や、追加したい機能などを見つけることができますので、それを次のイテレーションの要件定義で検討するといった柔軟な開発が行えるようになります。また、最初から最後までユーザーが関わりますので、ユーザーと開発側の認識のずれを少なくすることができます。

システムを１枚の絵に例えると、ウォーターフォールがピースを完成させてからを組みわせるパズル、アジャイルは下書き、色付けなど全体を少しずつ完成させていく水彩画というイメージでしょうか。

さて、前置きが長くなりましたが、エクストリームプログラミングとは、「こういうことを行えばアジャイル開発ができますよ」という方法の１つで、その他のアジャイル開発の手法よりはプログラマー寄りの開発手法と言えます。

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

先述しましたが、ウォーターフォールモデルに対して、エクストリームプログラミングの最大のメリットは柔軟性です。要件定義からテストまでの流れを繰り返し、少しづつ完成度を高めていく過程でユーザーとのやり取りも多く行うため、ユーザーの要望や仕様変更に柔軟に対応できます。

また、２人１組でプログラミングを行うペアプログラミングやソースコードの共有と完成したコードの品質改善、機能の実装よりも先にテストを作成するテストファーストなどを行うため、プログラマーがプログラミングを効率的に行えるようになり、リスクの回避にもつながります。

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

エクストリームプログラミングを実践するにはプラクティスと呼ばれる習慣や、実践内容が定められています。このプラクティスを行うことでエクストリームプログラミングを実践していると言えるようになります。

エクストリームプログラミングには、プロジェクトに関わる全員のプラクティス「共同」、プログラマーなど開発者のプラクティス「開発」、プロジェクトを管理する人のプラクティス「管理者」、システムの受け入れ側であるユーザーのプラクティス「顧客」の４種類があり、さらにそこから具体的な１９のプラクティスが存在します。

特徴的なプラクティスをいくつか簡単にご紹介します。

反復：設計や開発、テストなどをイテレーション単位で行うことで柔軟なシステム開発を行う。

共通の用語：用語集を作成し、プロジェクト全員の使用する用語の不一致やミスコミュニケーションを防ぐ。

回顧：現在の状態を把握し、過去に起きたこと間違いなどを再度行さないように、迅速にフィードバックできる環境や体制を作っておくこと。

テスト駆動開発：実装を行うより先に、テストを作成することで求められる機能を明確化し、シンプルな設計ができるようになること。

ペアプログラミング：２人１組でプログラミングを行うこと。１人がプログラミングを行い、もう１人がそのチェックを行うことで問題発生のリスクを少なくする。

参考記事:ペアプログラミングとは？メリットとデメリットをまとめてみた

ソースコードの共同所有：作成したコードをチーム内の誰でも修正することを可能にする。ただし誰でも修正できるため、コード作成の責任はチーム内全員で共有することになる。

YAGNI：You Aren't Going to Need It（今必要なことだけ行う）。必要以上のこと行わないことでシンプルに物事を進める。

最適なペースの仕事：集中して作業を行えるようなペースを維持するため、計画的に開発ペースを調整すること。

ストーリーの作成：求める機能のコンセプトを文章にしたカードを作成し、そのカードをもとにチームミーティングを行い機能の詳細を決定する。

短期リリース：動作するソフトウェアを、２～３週間から２～３ヶ月というできるだけ短い時間間隔でリリースする。

まとめ

エクストリームプログラミングは従来のウォーターフォールモデルに比べ柔軟性に優れ、顧客も巻き込んだチーム全体でシステムを開発します。ウォーターフォールモデルも悪いところばかりではありませんが、これからはアジャイル開発が主流になってくるのではないでしょうか。

アジャイル開発、エクストリームプログラミングは奥が深く、ここでは全てお伝え出来ませんが、どいうものかを感じ取ってもらえたなら幸いです。