エクストリーム・プログラミング（XP）を紐解く：価値・原則・プラクティスへのガイド（2024 Advent Calendar 10日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の10日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

エクストリーム・プログラミング（XP）の概観

本記事ではエクストリーム・プログラミング（XP）の概観を紹介します。この記事はスクラム開発を概観したアドベントカレンダー3日目の記事と同じ構成で書くため、比較するとわかりやすいと思います。

エクストリーム・プログラミング（以下、XP）はケント・ベックやロン・ジェフリーズによって提唱されたアジャイルなソフトウェア開発の手法です。クリーンアーキテクチャで有名なボブおじさんが「Clean Agile」という本の中で、「アジャイル開発宣言を作るために10名弱の開発者があるロッジに集まったところ、スクラム開発のグループとXPのグループ、その他のグループに大別できた」というようなことを述べています。しかし、現代ではスクラム開発とXPがアジャイル開発の2大潮流であると意識されることは少なくなりました。

スクラム開発はチーム開発の管理手法、XPは個人で実践できる技術プラクティス集だと思われているようです。しかもXPが提唱する技術プラクティスはペアプロやTDD、継続的インテグレーションだったりと現代の開発では当たり前に取り入れられていることです。現代の開発者はもはやXPを意識することなく、XPのプラクティスを自然に実践しているのです。

ただし、当たり前に行っていることの源流を学ぶことは意義があります。自分たちのプロジェクトではスクラム開発とXP、DevOpsを軸に開発を進めたと紹介しました。スクラム開発はスクラムマスターであるEM主導のもと、特に自分ともう一人の開発者が積極的にスクラムを学んで体現することでチームに浸透していきました。

XPは主に自分からチームに取り入れようと発信したものです。もともと自分は熱心なTDD実践者でした。ケント・ベックの本や考え方に惹かれていたことや前職でXPというものがあると教えてもらっていたことから、いつかXPを実践したいと考えていたのです。そこで「エクストリーム・プログラミング（第2版）」という書籍を読んで腰を据えてトライすることにしました。

XPは「価値・原則・プラクティス（実践）」の構成で成り立っています。これは以前の記事で紹介したようにスクラム開発と同じ構成です。

順番に見ていきましょう。

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

XPが掲げる価値は以下の6つです。どれもチーム開発をするにあたって重要な価値です。

• コミュニケーション（Communication）: チーム感覚や開発者同士の協力関係を生むためにコミュニケーションを取ろう
• シンプリシティ（Simplicity）： 「最もシンプルで、うまくいくことは何か？」と尋ねて、複雑性を排除しよう
• フィードバック（Feedback）：最初に決めた方向性で進み続けるのは危険なので、素早いフィードバックで改善を続けていこう
• 勇気（Courage）：問題がわかっていれば解決策となる行動を取り、問題の原因がわからなければわかるまで粘り強く耐えよう
• リスペクト（Respect）：他の人より重要な人はいない。私も重要であり、あなたも重要だという気持ちを持とう
• その他の価値（安全性、セキュリティ、予測可能性、生活の質など）

現代で「アジャイルにやろう」と言ったとき、この言葉は「小さく試して、改善を続ける」ことを意味します。アジャイル開発をXPの価値と照らし合わせると、互いにリスペクトをし合うチームがコミュニケーションを取って課題を解決しながら、シンプルに作ったものをリリースしてフィードバックを貰い、勇気を持って欠点を改善するといったところです。継続的に改善する精神は書籍の中でこのように語られています。

「継続的」改善というと、絶え間なく連続的に改善を続けているように聞こえるかもしれないが、そうではない。継続的改善とは、継続的に、注意して、フィードバックに反応して、積極的に改善を受け入れる、という意味だ。つまり、改善する方法がわかったときに、改善するのである。 「エクストリーム・プログラミング（第2版）」 p.137

また、XPはスクラム開発が重視するのと全く同じ価値である「勇気」と「リスペクト」を掲げていることは特筆すべきことです。スクラム開発とXPの共通点として、アジャイル開発ではこの2点が特に重視されていることがわかります。

エクストリーム・プログラミングの原則

XPの原則は以下のように多岐に渡ります。それぞれの項目は大きなものではないこと、またXPの価値やプラクティスほど大きく取り上げられることはないため各説明は省略します。

• 人間性
• 経済性
• 相互利益
• 自己相似性
• 改善
• 多様性
• ふりかえり
• 流れ
• 機会
• 冗長性
• 失敗
• 品質
• ベイビーステップ
• 責任の引き受け

XPの価値だけを知っていてもXPは実践できません。反対にXPのプラクティスを実践していても、その価値を意識しなければただやるだけになってしまいます。XPの原則とはその価値とプラクティスの橋渡しなのです。

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

XPのプラクティスは「全員同席」「プログラミング」「いきいきとした仕事」「計画」「インテグレーション」に大きく分けられます。さらにそれぞれの項目に対してより細かく分けられたプラクティスがあります。

• 全員同席
  • チーム全体
  • 情報満載のワークスペース
• いきいきとした仕事
• プログラミング
  • ペアプログラミング
  • テストファーストプログラミング
  • インクリメンタルな設計
• 計画
  • ストーリー
  • 週次サイクル
  • 四半期サイクル
  • ゆとり
• インテグレーション
  • 10分ビルド
  • 継続的インテグレーション

画像

各プラクティスの定義と自分たちのチームでの運用方法は今後の記事で詳述します。

XPのプラクティスはその価値とは異なり、それぞれ「できている」「できていない」という書き方で紹介されています。そのプラクティスを実践できているか明確に判定するためです。

XPのプラクティスは絶対的なものとして記述している。私としては、あなたに完璧を目指す動機を与え、明確なゴールを提供して、そこに至るまでの実践的な方法を授けたいと思っているからだ。 「エクストリーム・プログラミング （第2版）」 p.33

しかし、XPではこんなに多いプラクティスを全て実践しなければならないのかと臆する必要はありません。各プラクティスは選択制であり、自分のチームに必要なものを取り入れれば良いのです。

プラクティスを適用するかどうかは選択だ。プラクティスはプログラミングの効果を高めると私は考えている。プラクティスは単独でも機能するが、組み合わせたほうがさらにうまく機能する （同上）

なお、書籍では主要プラクティスの他にも導出プラクティスというものが紹介されていますが、この記事では説明を省略します。

エクストリーム・プログラミングとスクラム開発の共通点

XPに従ったアジャイル開発のフローは現代のソフトウェア開発の基本です。以下に書籍で紹介されている開発の流れを要約しました。

XPでは、プログラマが（時間単位の）ストーリーの工数を見積もる。プロダクトマネージャーがユーザーの立場になり、実装するストーリーを選んで優先順位をつける。 最初はリリースに必要な最低限の分のストーリーだけを実装する。優先順位は技術的な観点ではなく、ビジネス的な観点から設定する。 2~3週間を1つのイテレーションとして、ストーリーの合計時間と1つのイテレーションの期間を割った日数がリリース可能な日になる。 「エクストリーム・プログラミング （第2版）」 p.121 を要約

開発の流れはスクラム開発と大きく変わらないことが一読してわかります。XPは技術プラクティスだけと思われがちだが実際それだけではないのです。このことは、XPのプラクティスとスクラム開発のプラクティスを比較して共通点を挙げるとさらに明確になります。

例えば、XPの計画の「ストーリー」はプロダクトバックログアイテムです。また見積もりはストーリーポイントで行うことは両者の共通点です。「週次サイクル」はスクラムのスプリントに他ならず、導出プラクティスの「本当の顧客参加」はスプリントレビューに近いです。「情報満載のワークスペース」は自分たちのチームでFigJamというオンラインコラボレーションツールで各スプリントの情報、スプリントバックログアイテム、バーンダウンチャートなど開発に関することを一箇所に集めていたことに他なりません。

唯一大きな違いがあるとすれば、スクラム開発はプラクティスを全部必須としていることです。

スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。 すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 「スクラムガイド2020年版」p. 14

これはXPのプラクティスがチームごとに選択できるものであるとされている点で異なります。

エクストリーム・プログラミングが一番重視していること

Wikipediaのエクストリーム・プログラミングの項目はこのような画像を採用しています。これはXPが計画とフィードバックのループを一番重視していることを示しています。

まず、リリースの計画を立てます。リリース計画に基づき、月単位でイテレーション計画（スプリント）を実施します。イテレーション計画に基づいて毎週受け入れテスト実施します。

受け入れテストに基づいてスタンドアップミーティング（朝会）を毎日実施し、スタンドアップミーティングに基づきその日にペア同士の交渉を行い、ペア同士の交渉に基づいて毎時間でユニットテストを実施し、ユニットテストの結果に基づいて毎分でペアプログラミングを実施し、ペアプログラミングは毎秒でコードを書きます。ここまでが計画と実施です。

今度は書かれたコードがペアプログラミングにも、ユニットテストにも、ペア同士の交渉にも、スタンドアップミーティング受け入れテストにも、イテレーション計画にもリリース計画にも影響を与えます。書かれたコードが計画やコーディング内容にフィードバックを与えるのです。これがXPの計画とフィードバックのループです。

そしてフィードバックで得たことは各項目に適応していかねばなりません。状況は常に変化します。最初の計画通りに物事は進まないため、計画や実践を変えていかねばならないのです。コードから得られるフィードバックこそ、何かを変えるための最良の材料なのです。この変化に対応できないことこそが問題なのです。

これがXPのパラダイムだ。注意して、適応して、変更する。 ソフトウェアはあらゆるものが変化する。要件も変化する。設計も変化する。ビジネスも変化する。技術も変化する。チームも変化する。チームメンバーも変化する。 だけど、問題は変化ではない。変化はいずれにしても起きるものだ。問題はむしろ、我々が変化に対応できないことにある。 （中略） XPでは、こまめに小さな軌道修正を加えながら、適応することができる。つまり、短い間隔でソフトウェアをデプロイしながら、ゴールに向かっていくことができる。道を間違えているかどうかが判明するまでに、時間がかかることはない。 「エクストリーム・プログラミング （第2版）」 p.9-10

エクストリーム・プログラミングは1999年に発表されました。それから25年の時を経た2024年の現在でもXPが掲げる「価値・原則・プラクティス」は色褪せることがありません。XPとはまさに、変化に素早く対応するソフトウェア開発のための「時を超えた開発の道」なのです。