後編　新しい開発スタイル「ＲＵＰ」と「ＸＰ」：いまなぜ開発プロセスを注目するのか（2/2 ページ）

[岡村敦彦（株式会社豆蔵 上級コンサルタント）, 羽生田栄（CEO），＠IT]

（2）ＸＰはプログラマーの復権を目指す？

　次は、RUP以上に注目されることも多いエクストリーム・プログラミング（eXtreme Programming：XP)について取り上げてみることにしましょう。

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

　本稿をお読みいただいている皆さんの中には、ここで取り上げているXPがマイクロソフトのプラットフォームのことであると思われている方はもちろんいらっしゃらないでしょうが、一応断っておきますと、当然まったくの別物です（マイクロソフトがXPという名前を採用したときに、Bill Gates氏がこちらのXPを知っていたかどうかをご存じの方がいらっしゃったら教えてください）。

　XPとは、いわゆる伝説のC3プロジェクトとして知られるクライスラーでの Smalltalk によるシステム開発において、Ward Cunningham、Martin Fowler、Ron Jeffriesらとともに経験した内容を中心に、Kent Beck（CRC：Class Responsibility Collaborationの提唱者としても有名）が体系化したソフトウェア開発のベストプラクティスです。

　このXPに代表される小さいプロセスは、従来の重厚長大な方法論に対して軽量（LightWeight）なプロセスと呼ばれていましたが、最近ではこうした意図を強く持ったプロセスに対しては、Agile（俊敏な）という言葉が使われることが多いようです（確かに、LWPではSolaris のスレッドと紛らわしかったりしますが）。

　さて、先のRUPとこのXPという2つのプロセスに関しては、大規模な開発はRUP、小規模なシステムならXP、というコンテキスト（文脈）の中で語られることが多いようで、実際に本稿もそうした話の流れの中に存在していることは否めない事実です。しかし、果たして本当にそのようにとらえることは正しい理解といえるのでしょうか。この問いに対しての考察は今後のお楽しみということにしまして、今回はそのXPの特徴から見てみることにしましょう。

XPの特徴

　XPもやはり、従来のやり方ではうまくいかなかった開発上の問題点の上に成り立っているプラクティスだといえるでしょう。ただし、XPのユニークなところは、それらのプラクティス1つ1つは特に目新しいものではないものが多い、ということにあります。従って、XP入門書などを斜め読みしただけの人に見られがちな反応としては、「そんなことは当たり前だ。あらためていわれるまでもない」。または、「それができれば、苦労しないよ」というたぐいのものがあります。確かにそうかもしれません、というよりはそういうものなのです。重要なことは、それらを「着実にかつすべてを一緒に実施」することにあります。いうはやすく行うは難し、これがXP実践の際のポイントではないでしょうか。

　XPにもその根底に流れる４つの概念（というよりは思想（というよりは心構え)）があります。

• コミュニケーション
• シンプルさ
• フィードバック
• 勇気

　これら4つの言葉（XPでは価値といわれています）をご覧いただいて、いかがでしょうか。システム開発上の技術的な単語はここにはないことにお気付きかと思います。つまり、XPを実現するものは決してテクノロジに依存したものではなく、人間的な側面によるものが大きい、ということがここで明らかになります。

　考えてみれば（みなくても）それは当たり前のことです。ソフトウェアというものは人間が作ります。プログラムを書くのも人間ですし、仕様を決めるのも人間、発注をするのも受注するのも人間、出来上がったシステムを使うのも人間、文句をいうのも人間、人間、人間。こうした各人間同士の共同知的生産活動の結果をある目的のために実現したものが、1つのシステムになるわけです（CSCWはどこへ行った？)。

　そうであれば、システムを開発するうえでのさまざまな問題も、実際にはそうした人間同士の活動の中に存在（散在）しているはずです。そのときはそうは見えなくとも実はさかのぼってみれば原因としては人間の問題が起因しています。XPはそれを再認識させてくれるものです。

XPが解決するもの

　さてそれではXPを採用すると、具体的にはどのような問題が解決できるのでしょうか。前回の記事でも挙げられていたような従来型プロセスの問題点の中から、例えば２点ほど問題点を取り上げてみることにしましょう。

• 頻繁に変化する要求に対応できない
• テストが失敗する

　こうした問題に対してのXPの解答は実にシンプルです。

頻繁に変化する要求に対応できない（変化を抱き込む）

　“embrace change”。これはXPの標語といってもよいもので、そもそも現在のシステム開発というものの変化スピードが速すぎるため、そうした変化と一緒に共存していこうという趣旨の下に、XPの目的が設定されています。素早く変化に適応することこそが大事だということです。つまり、システムに対する要求の変更は当然発生するものとして受け入れる、そのために短い期間のイテレーション（開発の反復）を設け、その間に作成できるものだけを作成する、その後で変更されるものは、後のイテレーションで対応する、という方針です。

　さらにここでは、要求の変化のみならず、開発していくうえで発生するさまざまな変更要因をすべて包容しよう、という意味が込められています。

　誤解のないようにいっておきますが、これは顧客の変更要求をすべて無条件に受け入れましょう、といっているわけではありませんので、念のため。

テストが失敗する（最初にテスト）

　従来のプロセスではテスト工程が開発ライフサイクルの後半に位置付けられているために、こうした問題が発生します。そうであれば、最初にテストすればよいのです。そして XP のさらに徹底しているところは、まずテストから作り始めることです。実際にシステムの一部として稼働するコードを書き始める前に、そのコードをテストするテストプログラムから書き始めるのです。それからそのテストをパスするコードを作成していきます。そのようにしてテストをクリアしたコードは、システムの一部として取り込まれます。そしてそこで必ずビルドとテストが行われるわけです。ここではこの「必ず」というところがポイントです。よくスパイラルな開発をしているという組織でも、新しいコードをデリバーしたとしても、結合テストはあるタイミングで後から行われることが結構多かったりしますが、XPでは必要であればいつでも、毎日、というよりは、1日に何度もテストが行われます。ここがXPのエクストリームたるゆえんだと思います。

　こうした具体的な問題に対処するための実践原則が、XPでは12挙げられています。すでにいろいろなところで紹介されているものなのでいまさらという感じはしますが、一応列挙してみます。

• 計画ゲーム
• 短期リリース
• メタファ
• シンプルな設計
• テスティング
• リファクタリング
• ペアプログラミング
• 共同所有
• 継続した結合
• 40時間労働
• オンサイトのユーザー
• コーディング規約

　今回はこれら個々のプラクティスに関して説明する字数はありませんので、また別の機会にしたいと思います。

XPが本当に解決するもの

　もうお分かりですね。XPは上述のような具体的な開発上の問題を解決します。しかし、本当にXP解決するのは、そうした問題が具現化する前の潜在的な人間同士の問題を解決します。つまりXPというのは、システム開発という複雑な問題領域に対して、人間対人間に起因する種々の問題が発生することを未然に防ぐための現実的かつ強力な解法である、ということができます。

なぜXPがこれほど注目を集めるのか

　それでは、XPはなぜこれほど人々の注目を集めるのでしょうか。まずいえることは、視点が斬新な点です。従来のプロセスに多く見られる「プロセスとは」というような大上段に構えた観点からではなく、「良いソフトウェアを作るには？」という基本に戻ったところからXPが考察されている点です。重厚長大なHeavy Weight なプロセス群ももちろん当初は同じ目的だったのだと思いますが、次第にそうしたところからプロセスそのものが目的化し、初心を忘れてしまったものが多くなってしまったのではないでしょうか。

　次に魅力的なのは、いわゆる「プログラマーの復権」です。プログラマーという言葉は非常にあいまいで、なおかつ日本と欧米とではその意味するところも多少異なっているように思えますが、いずれにせよ、欧米でもやはりそれほど地位は高くないのが現状です。そこにカスタマーと同程度の権限を持たせたのがXPです。XPは、それまでは管理職やカスタマーに任されていた業務をプログラマーの手に取り戻し（というよりは、取り上げ）ました。その中には、作業の見積もりやタスクのアサインといった開発者のモチベーションを低下させる要因となっていたものも含まれていて、プログラマーの自立、いや自律を促します。こうして開発のイニシアティブをプログラマーの手の中に取り戻したことは非常に大きな功績といってよいでしょう。

　そのほかにも開発者からの視点で見た場合、「こういう感じで開発できたらいいなあ」と思える魅力的なことが多く盛り込まれています。

　仕事は楽しいに越したことはなく、それこそが効率を上げる一番の方法です。

---

　今回はRUPとXPという対照的なプロセスを選び、それぞれ基本となる考え方を中心に紹介してみました。もちろん本稿だけでは両プロセスとも、どのようにプロセスを考えればよいかという観点から語られているだけで、実際にはそれぞれを構成する基本要素すら説明していません。またRUPにしてもXPにしても、確かにそれぞれ特徴的な話はされたけれども、何だか別々のことのように書かれている、そんなふうに感じられていた読者はいないでしょうか？ もしそういう方がいらっしゃったとすれば、今回の記事は成功したといえます。その理由は……今後の連載の中で明らかにしていくことにしましょう。