エクストリームプログラミング解説 その6：使い方

中佐藤です。XP解説その6、これが最終回です。ここまでで、基本概念である価値・原則・プラクティスを解説しましたが、現場でどう役立てればいいか、考えていきます。

身も蓋もないことを言ってしまうと、昨今の状況も踏まえて、フレームワークはスクラムでよいと思っています。現時点では「アジャイルやっています」≒「スクラムやっています」ですし、情報も事例もたくさんある、教えてくれる人も多い。チーム内にXPのことをよく知っている人がいるとか、あえてXPにトライしてみたいとかでない限り、スクラムベースでよいのではと思います。

ただしスクラムはあくまでも「フレームワーク」です。システム開発に必要なプラクティスのことは語られていません。そのおかげでスクラムはシステム開発以外にも使えるし、その方向に発展しつつあるのですが、完結した開発手法として見ようとすると不足部分があります。Spring等のWebアプリケーションフレームワークが、それ単独ではWebアプリケーションにならないのと同じです。

この「穴」を埋めるのが、XPのプラクティスです。

正直なところ、こんなに大上段に説明するまでもなく、世のアジャイル開発のほとんどは自然にこれをやっていると思います。ストーリーはXP由来だと知らずに使っているチームがほとんどでしょうし、CI（継続的インテグレーション）も当然のごとく最初に環境を作ります。なら、それでいいんじゃないの、という意見もあるでしょうが、これで終わってしまうことには私は懸念を感じます。

アジャイル開発は思考停止を嫌う手法です。従来こうしてきたからこうする、スクラムガイドに書いてあるからその通りにする、アジャイルのことをよく知っている人がこう言ったからそうする、全部違います。とはいえ、人間誰しも最初の「足がかり」くらいは欲しくなるもので、それがスクラムのフレームワークだったり、よく使われるプラクティスです。そこで止まってはいけません。

同じことを繰り返していると、マンネリ化します。特にスプリントレトロスペクティブ。なんかもう改善することもないし、いいんじゃないの、やらなくても、なんて空気が出てきたら危ない。チームの誰かが声を上げましょう、「そもそも何のためにやってるんだっけ」と。プラクティスの回でお話しした、やっていることを価値(1/2)・価値(2/2)に持ち上げてみる、ということをしてみましょう。レトロスペクティブも、XPの考え方で言えば、プラクティスのひとつです。

自分たちのやり方にどうもうまくいかないことがある、何か新しいことをしたいけれど何をすればいいかわからない、という場合もプラクティス集は役立ちます。先人の知恵を遠慮なく使いましょう。もしくはそれを元に自分たち用にアレンジしましょう。ちなみに、この時にちょっと躊躇される場合があります。「いや、新しいやり方をやってみてうまくいかなかったらどうしよう」と。いいんですよ、やってみてうまくいかなかったら変えればいいし、止めてもいいんです。どうせ1～2週間後には、またレトロスペクティブで見直しの機会があります。その時に、やってみた結果をふりかえって「で、どうする？ 続ける？ 変える？ 止める？」を考えればいい。

もうちょっと熟練したチームになったら、原則を見直してみるのもいいですね。「え、こんなこと書いてあるの、意外」でも「これは賛同しかねるなあ」でもいい。こういう議論が成立することそのものが、成熟したチームの証です。

繰り返しになりますが、アジャイル開発は思考停止を許さない手法です。誰か他の人が要件定義をし、設計し、タスク分解をし、自分にアサインされたタスクを淡々とこなす手法ではない。一旦ストーリーやタスクに分解されたものであっても、それが全体から見てどういう意味を成すのか、考える必要がある。これは作るもの（プロダクト）に関してだけではなく、作り方（プロセス）についてもそうです。その時の一助が、XPだと思えばよいのです。

XPの「エクストリーム」たるゆえんは、その当時の考え方で言えば、結構過激なことを言っていたためです。「ペアプログラミング」しかり「40時間労働」しかり。でも本当は「なぜ」を考えないといけないのです。例えば、設計レビューやコードレビューって品質のために重要だよね、重要ならずっとやっていればいい、これがペアプログラミングです。よいと思われることを極限まで行い、不要と思われることは一切行わない（書籍の言い方では、目盛りを10にする／0にする）。一旦0や10にしてみて、いや自分たちは違うなと思ったら、そこから変えればいいのです。

ここは「デベロッパーサイト」ですからね、マネジメントの方が見ている可能性は低いと思いますが、これは言わずにはいられない。ここでいうマネジメントには、いわゆる上席者以外に、PMとかPMOとかSEPGとか言われる方々を含みます。

ここまで述べてきた「アジャイル開発はチーム単位で開発のやり方そのものが継続的に変化する」ことを理解して、「当社独自のアジャイル開発標準」を作る作業も継続的に行って継続的にリリースしてください。みなさんが考えることなんて、とっくにどこかの手法で考えています。世の中にある手法から、各社の事情でプラスアルファしたいというのは、まあ理解できます。それでも最初のリリースまでに四半期以上「標準作成」に費やすべきではない。アジャイル開発標準作成を、ウォーターフォール的にやらないでください。

え、うちの開発者は自分たちで手法を考えられる能力を持っていない？　そんなふうに能力に蓋をしてきたのはみなさん自身では？　でも安心してください。アジャイルの手法には、小さく失敗をしながらメンバーを育成する仕組みもあります。「アジャイル開発標準」では、大コケをしないための仕組みを作りましょう。

え、小さな失敗もしたくない？　そういう考え方をしているなら、アジャイル開発には向いていないので、諦めてください。