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


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

皆さんはエクストリームプログラミング(XP)をご存知でしょうか。全く知らない人が聞くとエクストリームスポーツのようにとんでもない場所でプログラミングを行う事と勘違いしそうなエクストリームプログラミングですが、割と前からあるソフトウェアの開発手法なのです。

以前はそこまでではありませんでしたが、最近ではこのエクストリームプログラミングの手法を取り入れる現場も増えてきているようです。また、応用情報技術者の問題としても出題されるようになってきています。

そこで今回は、エクストリームプログラミングとはなにか、そのメリットなどをソフトウェア開発手法にも触れながら、できるだけ分かりやすく解説します!

目次
  1. エクストリームプログラミングとは?
  2. エクストリームプログラミングのメリットとは?
  3. エクストリームプログラミングのプラクティス
  4. まとめ

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

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

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

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

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

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

image

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

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

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

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

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

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

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

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

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

共同のプラクティス 反復
共通の用語
開けた作業空間
回顧
開発のプラクティス テスト駆動開発
ペアプログラミング
リファクタリング
ソースコードの共同所有
継続的インテグレーション
YAGNI
管理者のプラクティス 責任の受け入れ
援護
四半期毎の見直し
ミラー
最適なペースの仕事
顧客のプラクティス ストーリーの作成
リリース計画
受け入れテスト
短期リリース

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

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

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

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

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

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

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

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

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

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

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

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

Webサイト担当者としてのスキルが身に付く

無料カウンセリングはこちら

まとめ

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

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


関連記事

ふろっく
この記事を書いた人
ふろっく
まずは7日間お試し!人気プログラミング講座を無料公開中
オンライン・プログラミングレッスンNo.1のCodeCamp