エクストリーム プログラミングとは? 5つの価値やプラクティスを解説

エクストリームプログラミングという用語をIT関係の記事でよく目にする方も多いでしょう。ただし直訳すると極端なプログラミングとなり、どのような開発手法なのか想像がつかないはずです。そこで本記事は、エクストリームプログラミングについて説明します。さらに、エクストリームプログラミングを用いて、ソフトウェア開発を進めるうえで、重要な鍵を握る価値とプラクティスについても解説するので参考にしてください。

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

エクストリームプログラミング（XP）とは、コンサルタントでありプログラマとしても活躍していたケント・ベック氏とその仲間が提唱した、アジャイル開発型のソフトウェア開発手法のことです。ケント・ベック氏が、1999年に『Extreme Programming Explained （邦題「XPエクストリーム・プログラミング入門」）』を著した当時としては、非常に斬新な手法だったので、人々に衝撃を与えました。

エクストリームプログラミングはソフトウェアを開発するうえで、経験上うまくいくことをパターンとして集めて、パターン化した経験則について徹底的な(extreme)実践を行うという意味で、エクストリームという単語を使用しています。エクストリームプログラミングの最終的な目的は、ソフトウェア開発を通じて、新しい社会構造を作り上げるという壮大なものです。
エクストリームプログラミングは、昔ながらのウォーターフォール型開発とは一線を画す、アジャイル型開発に分類されます。

続いてエクストリームプログラミングへの理解を深めるために、アジャイル型開発とウォーターフォール型開発について、それぞれ解説します。

アジャイル型開発

アジャイル(agile)は、「俊敏な」という意味を持つ形容詞です。つまりアジャイル型開発とは、文字通り、俊敏にソフトウェアを開発する手法のことです。ソフトウェアを素早く顧客に提供するだけでなく、変化に対応する臨機応変な柔軟性も併せ持っています。

アジャイル型開発では、ソフトウェアの仕様や設計が途中で変更されるのは当たり前なので、最初から厳密に仕様を決めることはしません。その代わりに、おおまかな仕様を決めて、一定の短い反復期間の小さな単位で、設計・実装・テストというイテレーション（反復）開発を繰り返しながら少しずつ開発を進めていきます。アジャイル型開発では、ひとつのプロジェクトを細かく区切って、要件定義からテストまでを反復するので、後戻りが起きたとしても戻る工数が少なくて済みます。そして、反復するたびに機能や改善が加えられ、ソフトウェアの精度が徐々に上がっていきます。

ウォーターフォール型開発

ウォーターフォール型開発とは、滝の上から水が流れ落ちるように開発を進めていく手法のことです。つまり、進行中の工程が100%完了するのを待って次の工程に着手するように、前の工程に戻って逆流することなく、あらかじめ決められた工程順に開発を進めていきます。例えば、ウォーターフォール型開発では、1番目が企画、2番目が要件定義、3番目が設計、4番目がプログラム開発、5番目がテストというように、決められたそれぞれの開発工程について抜けや漏れがないかどうかを厳重にチェックし管理しながら開発を進めていきます。

ウォーターフォール型開発は、工程の後戻りが起きないプロジェクトに向いており、顧客からの急な要望など何らかの理由で開発中に工程の後戻りが起きることが予想されるプロジェクトには向きません。そのようなプロジェクトには、アジャイル型開発の手法を用いた方がよいでしょう。

エクストリーム プログラミングの5つの価値

エクストリームプログラミングでは、ソフトウェア開発を進めていく際に重要となるポイントを「価値」と名付けて定めています。ここでは、その5つの価値について説明します。

コミュニケーション

1つ目の価値はコミュニケーションです。コミュニケーションの不足は、ソフトウェア開発を失敗へと導く大きな要因となります。コミュニケーションはチームのメンバー間だけでなく、顧客とも徹底的に取り続けましょう。

また、エクストリームプログラミングの開発プラクティスには、ペアプログラミングがあります。プログラミングは必ずペアを組み、プログラムを書くドライバー役とドライバーに指示を出してチェックするナビゲーター役に分かれて、2人1組でコミュニケーションを取り続ける手法です。もしチーム全体で、ペアとして組む相手を入れ替え続けるシステムがあれば、特定のペア間だけでなく、チーム内のコミュニケーションも同時に取り続けられるでしょう。

シンプル

2つ目の価値はシンプルです。エクストリームプログラミングの特徴である素早い開発の進行と柔軟性が保てるように、すべての工程がシンプルになるよう心がけることが重要です。特に最初の設計は、徹底的にシンプルにします。顧客の強い要望など、必要に迫られた時点ではじめて設計に変更を加えるように、極力複雑化を防ぐようにしましょう。

フィードバック

3つ目の価値はフィードバックです。ソフトウェアの品質を高めるために、常時コミュニケーションを取りながら顧客からのフィードバックを受けて適宜修正することで、それを反映します。また、開発者間でできるフィードバックの方法としては、コードを書いた本人とは別の人がフィードバックを与えるコードレビューという方法があります。

勇気

4つ目の価値は勇気です。エクストリームプログラミングには、最初に綿密な計画を立てずに開発をスタートする特性があるので、途中で大胆な計画変更の決断に迫られる場面が出てきます。大きな決断をするためには、強い意志と勇気を持たなければなりません。開発者が勇気を持って行動することで、事態を打開する解決策が得られ、開発者間や顧客との間の信頼強化につながるでしょう。

尊重

5つ目の価値は尊重です。チームで共に開発を進めていくならば、他のメンバーを徹底的に尊重することが重要です。他のメンバーについて、プログラムを書くうえで大事にしていること、得意なことや苦手なこと、実際に書かれたプログラムなど、それらすべてを尊重したときこそソフトウェア開発はうまくいくでしょう。

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

エクストリームプログラミングでは、開発者が実践する内容や慣習をプラクティスとして定めています。エクストリームプログラミングのプラクティスは、「共同」「開発」「管理者」「顧客」という4つの対象に着目して分類できます。

共同プラクティス

共同プラクティスは開発チームだけでなく顧客まで含めて、エクストリームプログラミングに関わるすべての人を対象とします。具体的なプラクティスとしては、反復、共通の用語、開けた作業空間、回顧の4つがあります。

開発プラクティス

開発プラクティスは、プログラマなどの開発チームを対象とします。その代表的なプラクティスとしては19に分けられて、テスト駆動開発、ペアプログラミング、リファクタリング、YAGNIの4つに大きく分けられます。

管理者プラクティス

管理者プラクティスは、プロジェクトの管理者を対象とします。具体的なプラクティスとしては、責任の受け入れ、援護、四半期ごとの見直し、ミラー、最適なペースの仕事があります。管理者プラクティスでは開発が適切に進むように、開発の進行具合を把握してチーム全員で情報を共有することが大事です。また、チームの仕事量が増えすぎないように、適宜調整することも重要です。

顧客プラクティス

顧客プラクティスは、顧客が対象です。具体的なプラクティスとしては、ストーリーの作成、リリース計画、受け入れテスト、短期リリースがあります。エクストリームプログラミングにおいては、顧客もチームメンバーとして開発に参加して、どの機能を優先して開発するかを決める重要な役割を果たします。具体的には、欲しい機能のコンセプトをできるだけ短い文章にまとめてストーリーを作成する、リリース計画の立案、機能がきちんと実装されているかどうかを確認することがあげられます。

まとめ

エクストリームプログラミングは、アジャイル型ソフトウェア開発手法の一種で、俊敏さと柔軟性を兼ね備えた手法です。うまくいく経験則を徹底的に実践するエクストリームプログラミングには、ソフトウェア開発を進める際に重要な5つの価値が定められています。Cloud Native Dojoは、エクストリームプログラミングを含むアジャイル型開発について指南するとともに、Microsoft Azure のクラウド ネイティブ サービスの活用についてもサポートし、企業向けに開発者の育成を支援するサービスです。