エクストリームプログラミング解説 その2：価値(1/2)

中佐藤です。エクストリームプログラミング解説 その1：全体像に続き、その2です。なぜかその2から入ってしまった方は、その1から読んでください。ここまでで、価値・原則・プラクティスという3つの概念をざっとご紹介しました。

早速「価値」について・・・と行きたいところですが、その前に、書籍（第2版）でも紹介されている、最初のXPのプロジェクトにちょっと触れておきます。1996年、クライスラー社の給与計算プロジェクトです。これを Kent Beck が引き受ける経緯もなかなかおもしろいのですが、そこは書籍を読んでください。

注目していただきたいのが、XPの始まりが「給与計算システム」という、典型的な社内基幹系システムであるということです。イケてるWebサービスを作る華やかなスタートアップ企業における開発では決してなく、実にありがちな炎上プロジェクト（「本番稼働するのに後2か月」と5か月言い続けていた）をどうにか立て直すために、少しずつプラクティスを導入していったことが書籍の記述からうかがえます。

また、最初にユーザーストーリーを洗い出し、1日かけて計画会議をして見積りをしたと書かれています。「計画づくり」も「見積り」もしているのです。「エクストリーム」なプログラミングだからといって、決して「とりあえず作って動かせ」ではなく、やるべきことはきちんとやっている。

当然なんですよね。何らかの仕事をするからには「いつ頃完了しそう」という見込みは必要なわけです（たとえそれが途中で変わったとしても）。ただそれを、実態を知らない人が押し付けた（と思われる）絵空事のスケジュールではなく、ユーザーストーリーという単位で現実的な見積りをする、という当たり前のことを当たり前にやっています。これは覚えておいていいのではないかと思います。

これは前回言い忘れたので、補足します。XPには、スクラムのようなフレームワークの定義はありません。ロール、イベント、作成物のような「これは必須」というものがない。XPに初めて触れる方が戸惑われる一因ではあります。

ロールの定義がないので、認定○○コース／試験とか作れない（おっと、以下略）。逆に言うと、従来のロールを否定していません。テスターもアーキテクトもプロジェクトマネージャーも出てきます。ただ、従来とは役割が変わるよ、ということは、ちゃんと書いてあります。本当はこのほうがいいじゃないかな、と思うところではあります。とりわけ「私はスクラムマスターだから」とか「これはプロダクトオーナーのやることではない」とか、こだわる人を見ると、本当は違うんだけどなあと思う今日この頃です。

イベント（会議体）の定義がないのも、えっ、と思うところでしょうか。プラクティスに「計画ゲーム」というのがあって、これを読むと（第2版より第1版のほうがくわしく書いてあります）、スクラムとそれほど違ったことをしているわけではありません。でも、こういうプロセス・手順でやるんだよ、ということが明確でない。初めての方にはシンドイところでしょう。

じゃあXPには何があるの、というと、それが前回お話した「価値」「原則」「プラクティス」です。

スクラムで言えば、三本柱（透明性・検査・適応）に近い、というのは既にふれました。XPの価値は、以下の4+1です。

• コミュニケーション
• フィードバック
• シンプリシティ
• 勇気
• リスペクト

これは、言うまでもないことですね。開発において、コミュニケーションは重要かつ重大。チーム内外で発生する問題の原因の、結構な割合を占めています。

上の図の白い矢印部分、顧客と開発チーム間の仕様の認識齟齬、リーダーとメンバー間の進捗についての理解の違い、メンバー間の（例えば）API仕様についての誤解。あらゆる場所でコミュニケーションギャップは発生する可能性があります。

もうひとつ、書籍には書かれていないのですが、私は青い矢印のところも考慮したほうがいいのではと思っています。つまり、自分たちが作っているシステムとのコミュニケーション。使っているOSSのバージョンが記憶していたのと違ったとか、外部サービスの機能変更に伴い動作がおかしくなったとか、結構よくあるのではないでしょうか。

書き始めた時点で予想したことですが、残りの価値をすべて解説すると、記事が長くなりそうなので、今回はここまでで。ひとつだけ補足しておきます。

価値の話から始めたので、「で、それが一体何なの」と思っている方がいると思います。「コミュニケーションが大事なのは知ってるよ。大事なのは皆わかっていて、それでも問題は起こるんだけど」と。

あらためてこの記事の最初の図を見直してみてください。価値とプラクティスをUMLの「実現線」で結んでいます。価値は非常に抽象的です。じゃあどうやってそれを実現するの、という実現手段が「プラクティス」なのです。

プラクティスについてはあらためて解説しますが、要はみなさんがアジャイル開発ってこんなことするよね、と思っているいろんな手法のことです。例えば、「継続的インテグレーション」「テスト駆動開発」「ペアプログラミング」「顧客同席（オンサイトユーザー）」「ストーリー」。これらの手法は、今回解説したコミュニケーションを含む、何らかの価値を実現するための具体的手段であると考えると、価値というものの意味が少しおわかりいただけるでしょうか。