マーチン・ ファウラー
チーフ・サイエンティスト, ThoughtWorks

講演で実際に用いられたスライドはhttp://xp2002.org/を見て欲しい。

• 初心を忘れるな
• 優れたドキュメント化とは
• ２０年前に捨てられた実践
• XPプラクティスを表現するメタファ
• 必要な機能だけ実装するべし

初心を忘れるな

カンファレンスの実質的な幕開けとなったのは、Ken Schwaber による講演である。Ken はまず「アジャイルな開発は、単に昔の技法をまとめて再パッケージしただけではなく、新しくて、革命的な要素を含んでいる」という主張を打ち出した。最近 IEEE Computer に掲載された Barry Boehm の論文は、「アジャイル」など古いメロディの変奏曲に過ぎないとみなしているが、この考えは「アジャイル」の本質をとらえていないというのだ。

次にKenはScrumを取り上げ、単にソフトウェアにとどまらない、製品の開発方法論としてこれを位置づけた。そしてXPが、多くのIT関連の組織で等閑視されている技術的なプラクティスを示しており、XPとScrumとを組み合わせこそ、もっとも純度の高いアジャイル・プロセスであると述べた。

Giancarlo Succi と Michele Marchesiの二人は、サルデーニャ島で過去三回行われたXPカンファレンスの主催者である。次回からは別の場所になってしまうので、残念ながらサルデーニャ島でのＸＰカンファレンスは今回が最後である。

彼の経験から言って、アジャイル型に興味を示すようなプロジェクトには二種類ある。トラブルを抱えたプロジェクトと、いろいろ試したがっているプロジェクトだ。トラブルを抱えたプロジェクトのほうがましだと言う。彼らはアジャイルなアドバイスに従ってくれる。しかしその一方で、興味を抱いただけの人たちは、アジャイルの多くのアイデアに対して「いや、だけど」という反応を示すのだ。アジャイル方法論からいくつかのアイデアだけを抜き出すということは、精巧なデザインを誇るスイス製の腕時計から、極細のバネを一本取り出す仕儀に等しい、と彼は批判した。

Kenは、本当の「アジャイル」を見分ける指標を提案した：

• 要件が全て揃ってないまま先に進んでも、大丈夫だとマネージャーが感じている
• 「このソフトウェアを世に送り出すのだ」というやる気を、ビジネス側が抱いている。
• 問題が起きた時、技術者の声に、耳を傾けて貰える。
• 職場には、何かガヤガヤとした感じがある
• 仕事のやり方について、チームが決定を下している
• みんな「普段の役割」が何かなど、話題にもあげない

アジャイルとは、ＩＴ技術をビジネス側へ取り戻す「パワーシフト（権力の移動）」だ、と彼は言う。ビジネスにおいて、成功を示す唯一の指標は ROI （投資対効果）だけである。みんなが細かい技法のことばかりに気を取られてしまい、アジャイルな開発の革命的側面という、より大きな全体像を見失うことは、アジャイルを推進する上では、とても危険なことだ。

しかし、「技法」と「哲学」の相互の絡み合いは、アジャイルやＸＰのコミュニティがずっとつきまとわれていたものではないだろうか。ＸＰはまさにそうで、というのもＸＰには、ソフトウェアの開発思想として非常に重要なアプローチと、それを実現する個別具体のプラクティスとの、両方が含まれているからだ。であれば「ＸＰの本質とはどちらか」という難問に相対せざるを得ない -- 技法なのか、その下にある哲学なのか？ ＸＰに慣れ親しめば親しむほどに、実際に技法に従うこと自体の重要性は薄れていくのだから、この問題が前景に浮かび上がってくる。とはいえ「ＸＰとは何か」を感じ取るには、実際に技法を実践してみるほかないことも事実だ（私は前に、この両立しがたさについて「ＸＰ変奏曲」で取り上げている）。

「アジャイル」というラベルは、この違いについて考えをまとめるのに役立つところが大きい。 "get together at Snowbird" 宣言の真価とはなにか。細かい技法についての意見の違いは在るにせよ、そこに名を寄せたひとたちが、思想的な面では意見の一致を見る部分がたくさんあったという事実に気づいたことだ。マニフェストに謳われた価値観が雄弁なのも不思議ではない。本質的な部分において、アジャイルへと切り替わっていくこと（予測から適応へ、プロセス中心から人中心へ）が、仮にその区切りを明確に見定めがたいとしても、連続的なものというよりは不連続的なものを含むだろう。この点については、私もKenと同意見である。

しかし私は「技法にこだわりすぎるべきではない」と言いたいわけではない -- それはそれで必要だし、重要なことなのだ。優れた開発技法があることは、アジャイルな開発が行った約束を果たす上で、不可欠なことである。XPのもたらした果実、たとえば進化的なソフトウェア設計のための技法は、将来のフレキシビリティを確保したいと思うのならば、中心的な役割を果たす。高い評価を得ているスイス製の腕時計だって、「部品」が無ければ作りようがないのだ。

優れたドキュメント化とは

彼は言う。XPが持つ大きな問題点は、ソフトウェア開発を４０年に渡って悩ませてきた問題と同じである。つまり「コード」を重視することには利点もあるだろうが、他の重要な開発上の問題がなおざりなってしまうというのだ。ソフトウェア開発における最大の問題とは何だっただろうか。それは、予期せぬ出来事が起きた時の対応が不十分であったこと、そしてインターフェースがきちんと定義されなかったり、またその管理がおろそかになったりすることである。

David Parnas は、数学的に厳密であると同時に、ドメインの専門家が欠陥を指摘できる程度に理解可能な、そういった仕様が必要とされているのだと述べた。

ＸＰに対する彼の批判点は、設計への取り組み方にある。これは、問題を先送りしているだけではないかというのだ。経済学的に言えば、お金をいま節約して、あとでコストを払うことと等しい。単純明快さを目指すことはよいが、その単純さが、ビジョンに裏付けられたものなのか、単なる近視眼の産物なのかでは全然違う。本当に長期的な視野にたった「単純さ」ならば計画が必要とされる。計画にはレビューが必要とされる。そしてレビューをするなら、ドキュメント化が必要とされるだろう。コードからフィードバックを得ようにも、それでは遅すぎるからだ。

しかし気をつけて欲しいのだが、彼は通常のプロジェクトで用いられている種類のドキュメントが必要だと訴えているわけではない。それどころか、普通のドキュメントなど使えないどころか悪影響があると考えており、"Undefined Modeling Language" という名前をつけていたりする（訳注：Unified Modeling Language「統一モデル化言語」をもじっている）。XPのテストケースですら、完全な記述ができていないという理由で、不十分である。彼が好むのは、定義に従った数学的なアプローチである。しかし彼は、この点において形式的手法を研究している学会が、正しい方向に歩んでいるとは思えないと述べた。数学的に書かれた仕様書は実際のコードより読み易くなくてはいけないはずなのに、Z や VDM といった有名な形式的手法に関して、「コードより読み易い」などという評判は聞いたことがないからだ。

彼によれば、数学的なアプローチは「関数（functions）」と「関係(relations)」に基づいたものでなくてはならない。まず制御対象となる変数、観測対象となる変数を洗い出し、後者から前者への導出式を書いてやる。そしてそれを、ドメインの専門家でも読むことができるように、タブロー（表）形式にまとめる。タブローは、制御対象となる変数それぞれに一枚ずつ用意する。講演で彼が例として取り上げたのは、とある航空制御関連のプロジェクトだった。パイロットたちは数学的な仕様書を前にして、数百にも及ぶエラーを指摘した。そのシステムの細かい説明は、時間的な制約もあり割愛された。

XP流の設計アプローチをめぐっては、火花散る議論が戦わされている。私も XP 2000における講演でこの問題を取り上げた。「厳密でありながら、読み易い仕様書」という考えは、ソフトウェア業界で駆出しだった頃の私も、テーマとして取り組んだことがある。私がとあるソフトウェアのカンファレンスに提出した処女論文が扱っていたテーマは、グラフィカルな設計技法を数学的に厳密な形で用いるやり方、というものだった。方向としては、Davidとかなり近いところにいたはずである。

形式的に書かれた仕様書に価値があるとすれば、それは他の技法を使った場合に比べて、間違いの発見が容易になり、修正がずっと効率的になるという点に求められるはずだ。これが私の、そしてParnasも同意するであろう見方だ。開発アプローチとして、コーディングが始まる前に大部分の設計が完成させておくべきだという「計画的設計」を採用している時には、これは非常に大事なことである。というのも、仕様での間違いが、プロセスのずっと終わりのほうにまでいかないと、発見されないことになるからだ。

XP側も、さまざまな方向からの取り組みを行っている。短期間のイテレーションを使うということは、コードからのフィードバックを短くするということだ。数週間で、ユーザがいろいろ遊んでみることのできるシステムが出てくるのだから。積極的なテスト作業と継続的インテグレーションによるサポートを行ったうえで、リファクタリングを用いるということは、仮に近視眼的な単純化があったとしても、低いコストで修正が可能になることを示している。

リズムに合っていないって？誰も気にしてないって！

数学的に書かれた仕様書があれば、ＸＰ流アプローチに比べて、より高い費用対効果が実現できるのか？仮にできるとしたら、その成立条件は？私は、ある特定のやり方が必然的に、あらゆる種類のソフトウェア開発で有効なものとなるなどということは、起きないと信じている。航空制御の分野でうまくいったものが、企業向けシステムを作る際には、取るべき正しい道ではない可能性もあると思う。ドメインの専門家は、形式的な手法を用いたからといって、反復的デリバリーを使ったときと同じくらい多くのエラーを指摘できるわけではない。以前、Parnasよりもさらに形式的な手法を企業向けシステムで試したときの自分の経験から、そう信じるに至った。さらに言えば、まあ私自身ほんの少しだけ計画的設計を入れることを好む部分があるとは言え、「進化的設計」がＸＰという舞台の上でどれほど効果をもたらすものなのか、とても驚かされている。さて、ここまで述べてみたものの、まだ私は Parnas のやり方を試してはいないのだ。だれかＸＰの関係者で、彼の技法を、顧客と折衝をするときに提案してみようという人はいないだろうか。コストに見合うだけの価値があるかどうか、調べてみてはくれないだろうか。Parnas は自分の技法を、予測を中心とした環境で用いられるだろうと考えているはずだが、逆に私にはこの技法が、反復的な環境では使えないという理由が想い当たらないのだ。

２０年前に捨てられた実践

ＸＰコミュニティにとって David Parnas が部外者ならば、Enrico Zaninotto はソフトウェア業界全体からみて異邦人である。彼の職業は、経済学の教授なのだ。アジャイルなアプローチと、製造技術における近年の発展とを比較することが彼の関心である。先導的なメーカーでは２０年も前にやめているような技法が、あるソフトウェア開発のプロジェクトでは使われていることを知ったことから、彼の興味はスタートしたのだった。

Zaninotto は、ソフトウェア産業と製造業における開発を複雑化させる主要なドライバー （要因）を、四つ取り上げた。

• システムが取りうる状態の数
• 部品間の相互依存
• 選択できるアクションの、取消し不可能性（irreversibility）
• 環境に含まれる不確実性

彼の説明によれば、問題を「システムが取りうる状態数」に絞ることで複雑さへの対処を行っているのが、テイラーモデルでありフォードモデルだということになる。作業配分、部品の標準化、製品を限定した組立てラインなどが、取りうる状態数の限定につながる。Zaninotto は、ウォーターフォール的な見方はまさにこれに従ったものだと考えている。しかし、予期せぬ結果を目の当たりにしたときに、テイラー／フォードモデルの限界は現れる。このアプローチは「何か起こるか」が分かっている時の最適化になるのだが、不確実性に対しては逆に無防備になってしまうのだ。

Enrico ZaninottoはXPを、トヨタの製造システムで用いられた「取消し不可能なことが作り出す複雑さ」への対処と比較してみせた。

トヨタ方式こそ、製造業における「パラダイム転換」だ。Enricoによれば、複雑性の要因となる四つのドライバーのうち、「取消し不可能性」の問題から攻撃しているのがトヨタだ。彼らは決定を、後で変えられるようにしたのだ。テイラー／フォードは、情報の流れを管理して、システムの中にそれを埋め込んでしまう。一方でトヨタは、アクションを起こす場所へと、意思決定を移動させてしまうのだ。

トヨタのようなフレキシブルなシステムにおける最大の問題点は、それが収束（converge）しなくなる恐れがあることだ。収束させるためにトヨタが行っているのは、バリエーションをある枠内に限ること、そして高いレベルの品質管理である。Zaninottoは「収束」の問題を、ＸＰの範囲を限定するものとみなしている。「それでも収束が起きる」という範囲を描いてみれば、それが、ＸＰの本当の限界を示す境界となるのだ。

Zaninottoの講演を聴いたときの私の体調は、ベストとは言い難かった -- 前の晩に開かれたカンファレンスの夕食会には、優れた演奏がついていたし、Mirto（訳注：サルデーニャ伝統の食後酒）もたくさん飲めたので、夜更かししてしまったのだ。しかも行われたのは朝の 8:30。普段だって厳しい時間だ。ところが、彼の講演には惹きつけられてしまった。英語が母国語でない彼は、用意したテキストを読み上げていたが(完全版は XP2002 ウェブサイトを参照のこと)、そのデ リバリーの素っ気無さがむしろ、内容の重要性をより際立たせていたとも 言えよう。トヨタ方式とアジャイル・プロセスとの関連は、すでに Mary Poppendieck が切り拓いていた領域でもあり、私自身もさらに調べてみようと思っていたところだが、そこにZaninotto はまったく新しいアイデアを付け加えたというわけだ。

「取消し可能性」という問題設定、そして取消し不可能性によって複雑度が上がるという認識には、とりわけ興味を掻き立てられた。DSDM(Dynamic Systems Development Method)が持つ９個のコアプラクティスの１つには、「開発で起きた全ての変更は取消し可能である」と謳われている。「取消し可能性」をこんなふうに開発方法論の先頭に持ってくるというのは普通ではない。ひとつ言えるとすれば、インクリメンタルな変更の中では、取消し可能性が「保護」として必須であるということだ。最悪の問題が起きたとしても、それは一時的なもので、それが取り消されてもとの状態に戻るというだけだ。もちろんこの「一時的な」問題がすべて軽微だとはいえないことは、他のコンピュータにおける不具合と同じだ。しかしその失敗が分かりさえすれば、仮に本当の問題自体はすぐに切り分けられなかったとしても、いつでも「取消し」によって解決が可能となるのだ。

FDD(Feature-Driven Development)に関する最近の本を読んだとき、著者がコア・プラクティスの中に「構成管理」を挙げていることに気づいた。ＸＰでは構成管理の話は無い。それが必要でないからという理由ではなく、ＸＰ信奉者は構成管理を、基本的能力の一つとして数えているからだ。とはいえ、正しく構成管理を使う方法を把握していない人に出くわしてしまうことも、まれではないのだが。

もう一つ、私が驚かされたのは「取消し可能性」と「反復的な開発」との相互作用である。間違った決定を下したが、それを即座に見つけた場合は、それを取り消すために、なんらかの「取消し可能性」を利用するか、手遅れになる前にリファクタリングを行うことになるだろう。しかし、もし間違いを見つけるのが遅れたらどうするのか？それはシステムに埋め込まれてしまい、取消し困難となるだろう。「反復的な開発」が、取消し困難になる前での、エラーの早期発見を可能にする。そしてリファクタリングによって、エラー除去のコストはさらに引き下げられる。そして「最初から正しく行わなくてはいけない」というくびきから解放されることは、結果として複雑さを大幅に軽減することにつながる。厳格なプロセスの裏側にある思想は、かなりの部分、この「取消し不可能なプロセス」に対処するために割かれている。しかし、この複雑さが取り除かれてしまえば、取消し不可能性に対処するための技法群など、余計なお荷物に成り下がるだろう。

XPプラクティスを表現するメタファ

今年の正式な講演者の中で、ＸＰ指導者として名が通っている人物はBill Wake 唯一人だろう。他のスピーカーと比較して、彼の講演はより明るい感じのものであった。テーマは「メタファ」であるが、これはXPプラクティスの一つとしてのメタファではなく、種々のXPプラクティスを表現するためのメタファを指している。手元のノートに書き取ったものを並べてみよう：

Frank WestphalはドイツにおけるXPの立役者の一人である。

• 「テストファースト」とは、「結果は偶数になる」と書かれた数学の問題のようなものである -- 答えではなく、道筋をたどることが重要。
• 「スパイク」とは、どうすれば失敗しないか見るために、まず作ってみる大工のようなものである。また、個々の要素を作る前に全体がどう収まるか把握するため、ここでは「テストファースト」も関係してくる。
• 「集団的コード所有」とは、テレビ番組の"West Wing"や映画などでおなじみの、指揮官がいる戦況指令室（situation room）のようなものである。つまり、誰もが全ての情報にアクセス可能で、問題解決への貢献をすることができるということだ。
• 「ペア・プログラミング」とは、ピアノの連弾、またはプロレスのタッグマッチのようなものである。
• 「イテレーション」とは、懐中時計の脱進機（訳注：時計の部品の一つで、巻いたゼンマイの反発が等間隔で起きることを利用して、間欠的な始動・停止の動きを歯車に伝える装置）のようなものである。
• 「XP を学ぶ」ことは、外国語を学ぶようなものだ。
• 「連続的インテグレーション」とは、貸借の差引勘定を合わせるようなものだ。「年に一度」なら大仕事だが、毎週やっているならラクなものだ。
• 「残作業なく帰宅すること」（グリーンの表示を見てチェックイン）とは、日ベースで「締め」を行うデイ・トレーダーのようなものだ。
• 「椅子無しミーティング」とは、徒競走のピストルのようなものだ。直後にみんなが、同じ方向に走り出す。
• 「イテレーションの反省会（iteration retrospectives）」とは、スポーツチームが、前回の試合での自分たちの動きを、ビデオで再確認するようなものだ。

XPにおけるメタファには、賛否両論ある。メタファがバシッと決まれば、信じられないような満足感が得られる。しかしそのようなメタファを思いつくこと自体が至難の業だ。メタファで考えることを必須項目に挙げてしまうと、ＸＰの足枷となりかねない。というのも、そのような苦難を、他のもっと簡単なものでも十分だというときに押し付けることになるからだ。だから、XPを実践するときに私はあまりメタファのことを気にしたりしない。と同時に私は、何かの拍子で思いついたよいメタファを用いることに、躊躇することもないのである。

まあほとんどのメタファがそうなのだが、Billの挙げたものには面白いものがあるとはいえ、私自身にはどうもピンとこないものがほとんどだった。まあ、「連続的インテグレーション」とかけて「差引勘定」と解く、というやつはよくできているだろう。私ならさらに拡張して、そのココロは「自動化のサポートがあるとさらにラクになるでしょう」（Quickenとか便利だよね）と言いたいところだが。あと、「集団的コード所有」と「戦況指令室」のアナロジーは面白い -- "West Wing" なんて見たことないけど。

しかし、「ピアノの連弾」っていうのは... さらに言えば「タッグマッチ」ってのもどうよ？まあ、「鉄槌男」Ron Jeffriesと「野生女」Ann Anderson に、「スーパー・チンパンジー」Kent Beckと「ブラックホール」Robert Martin が戦う試合というのも、見てみたい気がするが(私が組む相手はRob Meeだな)。

必要な機能だけ実装するべし

アルゲーロの街並で見かけた屋根

Jim Johnson はStandish Group会長である。彼の講演には、期待通り Standish Group がこの何年か集めてきた統計がいっぱい含まれていた。引用されることの多い数字だが、ITプロジェクトのうち完全に成功したといえるのは28%にしか達していない。あとは49%が「問題を抱えている（"challenged"）」であり、23% が「失敗」だ。

もちろん、この種の統計など「成功」の定義に左右される部分が大きいだろう。だから、カオス状態を警告するStandish のこのレポートが、「成功」の定義を「納期通り、予算内、そして予定された機能群の過半数があること」に置いていることは注意しておきたい。私はこの定義はおかしいと思うし、アジャイルのコミュニティのみんなもそうだろう。納期遅れがあったとか、予算超過があったとかいうことは、私に言わせれば「見積り」の失敗なのだ。「プロジェクト」そのものは、納期を破って予算を超過して、それでも大きな成功を収めることがある -- マイクロソフトの Windows 95 を見て欲しい。プロジェクトの成功は、ソフトウェアが投入した資産のコストを上回るだけの価値を産み出したかどうかにかかって来る。しかし、それを計測することはとてもややこしいことである。

彼が引用した統計の中で、もう一つ私の興味をひいたものがある。それは、ソフトウェア製品の機能で使われていないものが結構ある、ということだ。引用された調査結果は二つあって、一つは「システムの持つ機能のうち、本当に必要とされているものは25%しかない」というデュポン社の調査である。もう一つはStandish グループのもので、45%の機能がまったく使用されていないし、常時もしくは頻繁に使用されている機能は、たったの20%しかないという。

これは、アジャイル派の人間から得られた経験則からみても納得できる数字である。というのも我々は、今までの要件聞き取りのやり方が、リリース可能なバージョンで本当に必要とされる機能より、ずっと多くの要件を集めてしまっていると感じているのだ。さらに言えば私は、この数字から、ほとんどのプロジェクトはサイズにして現在の四分の一以下にすべきということが導かれると考えている。ソフトウェアにおける「規模の不経済」という要因も考えに入れれば、チーム自体ももっと小さめにつくるべきだということにもなるだろう。

Kent Beckが、カンファレンスの閉幕式でのスピーチを行った。彼が心配しているのはXPプラクティスの「化石化」だという。XPerにはもっと、プラクティスについて色んなことを実験して欲しいし、またその結果を報告して欲しいという。さらにKent は、学会の方々には、プラクティスそのものを取り上げるのではなく、XPを評価する方法を探求して欲しいという注文を出した。

これは実際には、Johnsonが「二つのSACWISシステムの比較」として出した例に関係したものだ。SACWIS は児童向け福祉関連のシステムで、米国の全ての州が実装を義務付けられている。Johnsonによると、フロリダ州では1990年に、費用を3200万ドル、納期を1998年という見積りで、100人程度のチームを組んでこのシステムを作り始めた。最新の情報では、コストは1億7000万ドルに跳ね上がっており、納品予定は2005年となっていた。実は、ミネソタ州も同じ機能を実現しなくてはならないのだが、この州の人口規模はフロリダ州と同程度であり、広範囲で、かなり似ているシステム要件があがってきた。1999年に作業を始めたミネソタ州は、しかし、8人のチーム、110万ドルのコストで、2000 年には作業を終わらせてしまった。

Chet Hendrickson は「大きなシステムの内部にはいつも、小さなシステムがいて、外に飛び出そうともがいている」と言っていたが、そのとても分かりやすい例と言える。何が起きて、実際にコストや労力の面で二つのシステムにこれだけの開きが出たのか、細かいところまで判断できる材料は私には無い。Standish group はこの違いを、ミネソタ州が要件の最小化に成功したこと、そして標準的なインフラを採用したことに求めている。まあ他の要因はともかく、必須部分だけに要件を煮詰めていけば、かなり大きな成果が得られることがよくわかる。もちろんアジャイル側は、短期間の、価値に基づいて動くイテレーションのほうが、前払いの要件聞き取りよりも、要件を最小化しやすいはずだという主張を持つ。しかし実際のデータが集まるまでには、まだ時間がかかるだろう。

アジャイル側の主張を受け容れるかどうかは別として、ソフトウェア業界が直面する挑戦課題は「なるたけ小さく作って、それでも価値を生み出す」ことを、どこまで追求できるかという点であり、SACWISの例はこれをものがたっていると思う。なんとなれば、必要とする機能だけを実装できれば、ソフトウェアシステムにかかる費用を大幅に削ることができるのだから。多くの人は、要件を考える時点では、コストのことを考えないのだから、前払いの要件集めプロセスのほうが不利であるというのが私の見方である。要件に関する本を何冊か読んだが、「コスト」について記述したものはほとんど無いし、また「要件の一部」として見たコストの重要性に触れたものもほとんど無い。コストへ言及することなく書かれた要件定義書など、「作り過ぎ」につながることは必定である。特に、範囲確定／値段確定型の、無駄な費用をそのまま取り込んでしまうような契約形態の場合は、なおさらそうなるだろう。