「ソフトウェア開発ファシリテーション」アドベントカレンダー20日目の記事です。
私の中でアジャイル開発と言えば「エクストリーム・プログラミング」と「アジャイルサムライ」という感じなのですが、アジャイルサムライは教科書的な理解なのに対して、エクストリーム・プログラミングには私の普段の開発の様子がそのまま書かれているなぁ、という印象です。
例え資金を多く使っても、早くソフトウェアを作り上げることはできない。「女性が9人集まっても赤ん坊は一ヶ月では生まれない」のだ。
ケント・ベック著「XPエクストリーム・プログラミング入門」P.16
なんて、本当にそうだよな、と思うわけです。この例え方自体は、時代的に物議を醸すかも知れないですけどね。
（上記のリンクは第2版なので、私の持っているXP本とは中身が違うかも知れません）
XP本では第1章から「ソフトウェア開発の基本的な問題はリスクである」として、よくあるリスクをリストアップしているのですが、2000年ぐらいに書かれた本とは思えないぐらい、今となっても「あるある」な感じです。
スケジュールの遅延──納期が来たのに、ソフトウェアが完成するまでにあと6ヶ月はかかるとユーザ（顧客）に言わなければならない。
プロジェクトのキャンセル──度重なる遅延の末、プロジェクトは稼働（運用）されずに取り止めになる。
システムの陳腐化──ソフトウェアは無事稼働に入ったが、数年後には改良のためのコストまたは欠陥率が高くなりすぎて、システムを取り替えざるをえない状況になる。
欠陥率──ソフトウェアは稼働に入るが、欠陥率が高いので使われない。
ビジネスの誤解──ソフトウェア稼働に入るが、当初掲げられたビジネス上の問題を解決しない。
ビジネスの変化──ソフトウェアは稼働に入っている。しかし設計対象のビジネス上の問題がより切迫した別の事態により6ヶ月前とは変わってしまった。
誤った機能強化──ソフトウェアは潜在的に面白い機能をもっており、プログラムするのは楽しい。しかし、そういったもので、ユーザの利益になるものはない。
スタッフの退職──2年後、プロジェクトにいた優秀なプログラマは開発（改良）していたプログラムが嫌になり去っていく。
ケント・ベック著「XPエクストリーム・プログラミング入門」P.3
このリスクをシンプルなプラクティスによって扱おうとするのがエクストリーム・プログラミングというわけです。ソフトウェア開発の立場から見ればリスクですが、ビジネスにとっては不確実性と呼んだ方が良いかも知れません。「ちゃんと動くの？」「価値あるの？」「改善し続けられるの？」という問いに答えるためには何が必要か、ということです。
エクストリーム・プログラミングではこの答えを「開発規律を定めることだ」としていますが、規律というほど仰々しいものではなく、むしろ今読んでみるとクリエイティビティを発揮するためのルールだと思えます。
計画ゲーム──ビジネス上のプライオリティと技術的見積りを結び付けて、次のリリースのスコープをすばやく決定する。実際には計画と違ってしまった場合、計画を変更する。
短期リリース──シンプルなシステムをすばやく稼働（運用）させる。そして新しいバージョンのリリースを極めて短いサイクルで行う。
メタファ──すべての開発を、システム全体がどのように動くかというシンプルで共有されたストーリーによって導く。
シンプルな設計──システムはいつでもできるだけシンプルに設計されるべきである。複雑さを見つけたら、取り除かなくてはならない。
テスティング──プログラマは常に単体テストを書き、開発が続く限りテストは絶え間なく実行される。ユーザ（顧客）は機能の完了を検証するテストを書く。
リファクタリング──プログラマはシステムの振る舞いを変えずにシステムを再構築する。重複を取り除き、コミュニケーションを改良し、シンプルにし、フレキシビリティを持たせる。
ペアプログラミング──作成されるコードはすべて二人のプログラマが一台のマシンに向かって書く。
共同所有──誰でもいつでもシステムのすべてのコードを変更できる。
継続した結合──1日に何度も、ひとつのタスクが完了する度に、システムを結合しビルドする。
40時間労働──週40時間以上働かないことをルールにする。2週間続けて労働時間が超過しないようにする。
オンサイトのユーザ──実際のユーザをチームに加え、いつでも質問に答えてもらえるようにする。
コーディング規約──プログラマはコードを通してコミュニケーションを強調するルールに従って、すべてのコードを書く。
ケント・ベック著「XPエクストリーム・プログラミング入門」P.55
私自身のアジャイル開発歴はいよいよ10年になりますが、ふりかえると、現在していないのはペアプログラミングぐらいで、ほとんど全てのプラクティスを自然にやっている状態だなと感じます。チーム規模云々抜きにして、このプラクティスができていないプログラマと組むのはちょっと難しい・・・という感じです。もはやプログラマとしてのリテラシーみたいな位置づけにあると思います。
一つ一つのプラクティスは、本に書いてあることを遵守し続けているというより、それを基礎にした上で時を追うにつれて肉付けがされていっているな、というのが今持っている感触です。特にメタファあたりは最初読んだときは意味がよく分からなかったのですが、今読めば「全体をあらわす共通言語を持つ」「常に更新され続ける中で移り変わる全体像を表現し続ける」というように、メタファで語られていた内容の重要性を理解できます。
重要なのは、このプラクティスの実行をチーム内のそれぞれのメンバーで分業するということではなく、このプラクティス全体をコアスタンスとしてメンバー一人一人が持つということにあると思います。短期リリースのためにはメタファとシンプルな設計、さらにはテストコードがあって問題があったときに再現できることが重要ですし、それぞれのプラクティスは相互に作用しあっています（P.72の図4にそんな図がありますね）。
ペアプロやモブプロは最近本当にやっていないので、たまにはやりたいなー。
と、たまたまXP本が本棚から落ちてきたので読んでみたら改めて目からウロコだったのでこんなエントリを書いてみたのでした。
