はじめに

みなさんはXP（eXtreme Programming）をご存じでしょうか。XPとは、アジャイル開発手法の1つです。5つの価値と、それを実現するためのプラクティスを持ち、ソフトウェア開発に特化したものとなっています。XPをご存じでないみなさんも、ペアプログラミングやテスト駆動開発という言葉は知っていたり、実践したりしたこともあるのではないでしょうか？これらも実はXPのプラクティスの一部です。
XPはアジャイル開発手法の中でも歴史が古く、1990年代後半から関心を集めるようになりました。しかし、XPというキーワードは現在ではほとんど聞かれなくなったように思いませんか？Googleトレンドの結果（図1）を見ても、2000年代前半は現在と比べると検索数が多いですが、2010年代後半にはほとんど検索されなくなっています。スクラム開発と比較しても、検索数が逆転していることがわかります。

図1　GoogleトレンドにおけるスクラムとXPの比較

上記のような状況を鑑みると、無意識にXPのプラクティスを使っている方が多いのではないかと思いますが、みなさんはXPの各プラクティスの目的を理解して使えていますか？
本記事では、あらためてXPの概念を振り返り本来の目的に立ち返ることで、XPのプラクティスをより効果的に使える方法を紹介します。

XPとは何か？アジャイルやスクラムとの関係

そもそもXPとは何でしょうか。まずは、アジャイルやスクラムとの関係性を考えながら、XPの歴史を振り返ってみましょう。多くの人はアジャイルが先に生まれ、その後アジャイルの概念を取り込んだXPとスクラムが生まれたと考えているように思いますが、実はそれは間違いです。
スクラムとXPがそれぞれ1993年、1999年に提唱されました。その後2001年にスクラムとXPも含めいくつかの開発手法の前提となる概念の共通部分をまとめ、「アジャイルソフトウェア開発宣言^注1」を発表したのが、アジャイルの始まりです。
そのため歴史的な親子関係は逆ですが、スクラムとXPは共通の概念であるアジャイル開発宣言を親として持つ、兄弟のようなものであると言えます。
次に各手法について掘り下げ、両者の違いを明らかにしていきましょう。
スクラムはプロダクトを作成するためのチーム運用を定義した「フレームワーク」です。より詳細な運用方法や開発方法（以降メソッドと呼びます）などについては決められていないため、ソフトウェア開発に限らずプロダクト開発全般に利用できる手法です。
XPは20個程度のプラクティスから構成される開発手法です。XPはスクラムとは違い、ソフトウェア開発に特化した手法であるため、20個のプラクティスの中にはソフトウェア開発にしか適用できないものも存在します。
XPのプラクティスには、メソッドのプラクティスもありますが、フレームワークとしてのプラクティスも存在します。そのため、XPはフレームワークとメソッドの両方を定義した開発手法であると言えます。
また、フレームワーク部分はスクラムと共通している部分がとても多いため、XPはスクラムにメソッドを足したものと言っても良いでしょう。
上述のようにスクラムとXPはかなり似ているものですが、メソッドがある分、XPのほうが開発手法としてはリッチと言えるでしょう。

XPはどうして知名度が下がったのか？

ではなぜ、XPの知名度が下がってしまったのでしょうか。
まず1つめの理由として、XPが「わかりにくかったこと」が挙げられます。スクラムは10個の要素（3つのロール、4つのミーティング、3つの成果物）を知れば、フレームワークを利用できてしまいます。一方、XPはスクラムよりも知っておくべき要素が多く、プラクティスだけでも20個近くを理解しなければなりません。
2つめの理由は、スクラムはソフトウェア開発に特化していないことです。プロダクト開発全般で使用できるフレームワークであるため、ビジネス側の人を巻き込みやすく、多くのシーンで適用できます。
これらの理由から、実際のソフトウェア開発においては、スクラムが主流となっていきました。
しかし、前述のとおりスクラムは詳細なメソッドを定義しておらず、その内容はチームに委ねられています。そこで取り入れられたのがXPのプラクティスです。XPとスクラムはフレームワークが似ているため、XPのプラクティスの中には、スクラムで使用しても有効なものが多くありました。
その結果、「フレームとしてはわかりやすさのスクラム、そのメソッドにはXPの優れたプラクティス」という組み合わせで、現在よく見られるアジャイル開発が生まれたと推察しています。

より良いXPプラクティスを現場に取り入れよう

前節までで、普段何気なく使っているスクラムにも、XPの考え方が取り入れられていることがご理解いただけたかと思います。本節では、とくによく利用されているXPのプラクティスについて、本来の目的を振り返り、より効果的な活用方法を紹介していきます。

ペアプログラミング

アジャイル宣言の背後にある原則^注2の中で

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
（中略）
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

とあるとおり、アジャイルでは優れた設計が生産性を上げる、優れた設計はお互いに助け合えるようなチームから生まれるという考えがあります。
その考えのもと、生まれたのがペアプログラミングです。このプラクティスの目的は、お互いに助け合う環境を強制的に作ることで、優れた設計を生み出すことです。また、コードの共通理解、知識・技術の共有によるチームの自己組織化の促進も目的の1つです。
ペアプログラミングでは2人が同じマシンに並んで座り、プログラミングを同時に実施します。1人をドライバー、もう1人をナビゲーターと呼ばれる役割に分担し、ドライバーはプログラミングを実施し、ナビゲーターはドライバーが書いたコードをレビューしたり、意見を出したりします。
しかし、この手法では2人の間でしかコードの共通理解や知識・技術の共有ができないため、チーム全体でその効果を得たい場合、効率が悪いという課題があります。
そのため最近では、モブプログラミングという手法が取り入れられるようになりました（図2）。モブとは「群衆」という意味で、3人以上でプログラミングをすることをモブプログラミングと言います。基本的なやり方はペアプログラミングと同様ですが、人数が増えた分ナビゲーターが増えます。モブプログラミングをすることで、より多くの人の考えが反映された設計とコードが得られますし、一度により多くの人とコードの共通理解や知識・技術を共有できます。

図2　モブプログラミング

ただし、モブプログラミングにも課題は存在します。現場の開発者からは「期待している効果が出なかった」「ナビゲーターが複数いることでほかの人に任せて自分の作業を始めてしまうメンバーがいた」という声を聞いたことがあります。
期待している効果が出ないのは、モブプログラミングの対象のコードが間違っているのが原因であることが多いです。すでにチーム内で十分共有されている技術や知識を対象にしている場合、モブプログラミングをやるメリットは少ないでしょう。逆に、新しいライブラリを導入したり、新たにほかの外部サービスと接続したりする場合など、メンバーに知識の共有が必要な場合はモブプログラミングが適していると言えるでしょう。モブプログラミングを導入する際には、知識共有の度合いを事前に確認しておくべきです。
適切に対象を選んだとしても、ナビゲーターがモブプログラミングに関連しない自分の作業を始めてしまう場合は、ナビゲーターが集中できない理由をさぐる必要があります。集中力を削ぐような横やりは入っていないでしょうか？
目先のスケジュールに追われている状況になっていないでしょうか？そもそも、担当するナビゲーターは「チームが責任を持つ」という意識を持てているでしょうか？このような場合は、スクラムマスターが先導して、参加者全員がモブプログラミングに集中できる環境を作るべきでしょう。
また、昨今は新型コロナウイルスの世界的な流行により、対面ではなくリモートでペアプログラミングを実施することが増えてきました。リモートでのペアプログラミングについては、本連載コラム第1回 コロナ時代のリモートアジャイル（2021.07.05）でも触れていますので、そちらもぜひご参照ください。

テスト駆動開発

前述したようにアジャイルには、優れた設計が生産性を上げるという考えがあります。テスト駆動開発も、優れた設計を生み出すための手法です。この開発手法はプログラムに必要な各機能について、最初にテストを書き、そのテストが動作する必要最低限の実装を行ったあと、テストが通ることを確認しながらコードを洗練 させるという短い工程を繰り返します。
テストを先に考えることで、機能が適切に分けられているか、仕様に矛盾や誤りはないかという点に気づきやすくなります。また、答えから記述し、逆算してコードを作成するため、無駄のないコードになります。
しかし、このようなテスト駆動開発の目的を理解せず、手段が目的化しているケースが見られます。その中でも代表的な事例を紹介します。
1つめは、テスト駆動開発をする前に設計を終わらせてしまっているケースです。たとえばJavaを利用した開発において、図3下側の「悪い例」のようにクラス設計書がすでにあり、クラス設計書を見ながらテスト駆動開発を行う場合です。クラス設計をもとにテストを作成してしまうため、テスト作成時に設計をする意識が薄れてしまいます。
また、仮に良いクラスの分け方やクラスの機能などに気づいたとしても、設計書の修正が必要になり、手戻りが起きてしまいます。またそれが続くうちに、設計書の修正が億劫になり、設計をやりなおすことを諦めてしまうでしょう。

図3　テスト駆動開発の良い例と悪い例

2つめは、テスト駆動開発をすれば誰でも優れた設計を生み出せると勘違いしているケースです。確かにこの開発手法は優れた設計を生み出すためのものですが、本手法を実施するだけでその目的が達成されるわけではありません。前提として、当然ながらソフトウェア設計の知識やセンスが求められます。テスト駆動開発を過大評価せず、開発工程や開発対象が適しているかを検討し、ペアプログラミングなどの手法と組み合わせたり、設計技術の習得に注力したりすることをお勧めします。

コードの共同所有

コードの共同所有とは、コードをチームの所有物とし、全員がすべてのコードに対して責任を持つという考え方です。こうすることで、全員がすべてのコードを参照・修正することが可能になり、さらにはチームメンバーがお互いにレビューやリファクタリングを行っていきます。全員がコードに責任を持つことで、属人化によるバグを減らしたり、チーム全体の知識を共有したりすることにつながります。
現在では、多くのチームがGitなどの分散型バージョン管理システムを用いてコードの共同所有を実現しています。運用上は、プロダクトバックログアイテムごとに作業用ブランチを作成し、作業が完了したら本体のブランチにマージするというやり方が主流でしょう。たとえばGitflowという運用ルールを聞いたことがあると思います。Gitflowでは目的に応じた命名ルールに沿ってブランチを切ります。マージする際のルールも厳密に定められています。並行開発がしやすくなり、プルリクエストのしくみも併せて使うことで、マージ時の品質低下を防ぐことができるメリットがあります。
しかし、コードの共同所有の原理に立ち返って考えたときに、ブランチを用いた開発は本当に適した手法と言えるのでしょうか？
ある時点で作業用のブランチが1つ以下であれば問題はありません。しかし、スプリントが開始すると各メンバーがそれぞれ別のプロダクトバックログアイテムを担当し、各メンバーがそれぞれ別のブランチを作成してしまうことで、スプリントの途中ではブランチが大量に存在する状態になってしまった、というチームを筆者は見たことがあります。担当ごとにブランチを作成すれば、ほかのメンバーの作業への影響を考えず自分の作業に集中することができますが、それは本来の目的である、全員がすべてのコードに責任を持つという考え方とは離れてしまっているとは思いませんか？また、優先順位順にプロダクトバックログに着手するというスクラムのルールも守られていません。
このような課題を感じるのであれば「トランクベース開発」への移行を検討してみてはいかがでしょうか？
トランクベース開発では、ブランチ開発のような運用をしません。自分の作業を小さな単位に分割し、1日に1回以上の頻度でトランクにマージしていきます。トランクというのはGitのメインブランチのことで、開発者はこのトランク上で作業を行い、変更を直接Pushするか、1～2日以内にマージすることを前提とした作業用ブランチ（short-lived branch）を作成し、トランクにマージします。ブランチ開発よりもかなり頻繁にマージが行われることがわかると思います。
頻繁なマージにより、常に最新のコードに保ち、ほかの開発者との共有もリアルタイムに近くなります。最新のコードのみを理解し管理すればよいため、チームでの責任も持ちやすくなると思います。また、トランクベース開発を実現するためには、テストの自動化や、自動ビルドなど、補助のしくみを活用し、動かないコードや、バグの混入を最小限に留めるよう工夫するとよいでしょう。
実際にトランクベース開発を始めようとすると、今までのブランチ開発と違う方法でコードの信頼性を守る必要があり、考えることが多いと思います。しかし、ここで一度コードの共同所有の目的に立ち返り、より良いコード管理の仕方について考えてみてはいかがでしょうか。

XPの導入の課題と対処

さて、ここまでXPを導入した場合を前提にして話をしていましたが、いざXPを導入しようと考えたときに問題が出ることがあります。XPのプラクティスの多くは、チームの成長を目的としたものであり短期的な効果が出づらく、その点をプロダクトオーナーやステークホルダーなど、ビジネス側の人に指摘されることがあります。
たとえばペアプログラミングの導入を考えてみます。2人で同じことをやるということは、生産性が半分になるのでは？と考え、反対する方がいます。さて、これにはどう対処するのが良いでしょうか。
確かにペアプログラミングをしている時間だけ見ると、生産性は半分に見えるかもしれません。しかし、この手法の導入によってチームが成長することを加味すると、中長期的な視点で考えれば、生産性は向上するでしょう。これをビジネス側に説明すればよいのです。ペアプログラミングをしたことで優れた設計・優れたコードが生まれ、テスト工程でのバグが減ることでバグ対応にかかる時間が短縮されます。また、メンバー間のコードの共通理解や知識・技術の共有が進むことでメンバー間で話し合う時間が短縮されます。メンバーが成長することで別のプログラムを書く際の時間も短縮されるでしょう。
そして、中長期で見た場合の生産性を見える化しましょう。ビジネス側の人は、理屈よりも誰から見てもわかる数字を求めています。ペアプログラミングを導入する場合としない場合で生産性がどう変わるのか。グラフや数字を使って、具体的に、かつ、わかりやすく説明しましょう。
ここまでできれば、ビジネス側の人も理解が深まると思います。
XPはほかにもリファクタリングや試験自動化など、ペアプログラミングと同様に、今の生産性を犠牲にして未来の生産性を高めるものが多くありますが、それらについても同様に対処すれば良いでしょう。
みなさんもXPを導入する際に反対された場合は、上記の対処法を参考にしてください。

おわりに

本記事で、これまでなんとなく知っていたXPは、正しく理解して、効果的に使うことで、チームの成長を加速できるものだということがわかったはずです。また、逆に言えば、目的を理解しないままXPを使うことによって、期待する効果が出ないことも理解できたと思います。
この機に、みなさんが実践している現場のプラクティスを見直してみてはいかがでしょうか。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx