XP 2002 カンファレンス

精神を忘れない

カンファレンス本番は、Ken Schwaberの講演から始まりました。Kenは、アジャイル開発は単に古い技術の焼き直しではなく、新しく革命的なものであるというテーマで講演を始めました。Barry Boehmsの最近のIEEE Computerの記事のように、アジャイルを古いテーマのバリエーションと見なす記事は、アジャイルの特別な点を理解していませんでした。

Schwaberは、スクラムをソフトウェアだけでなく、製品開発の方法論として特徴付けました。彼は、XPは多くのIT組織に欠けているエンジニアリングプラクティスを提供し、XPとスクラムの融合がアジャイルプロセスの中で最も純粋なものだと述べました。

彼の経験では、アジャイルに興味を持つプロジェクトには、問題を抱えているプロジェクトと好奇心を持っているプロジェクトの2種類がありました。彼は前者の方が優れていることに気づきました。なぜなら、彼らはアジャイルのアドバイスに従うのに対し、後者は様々なアイデアに対して「しかし」と言うことが多かったからです。彼はアジャイル手法からいくつかのアイデアを取り入れるという一般的なアプローチを批判し、それは精巧に作られたスイス時計から素晴らしいゼンマイを取り出すようなものだと述べました。

Schwaberは、真のアジリティを示すいくつかの指標を提案しました。

• マネージャーは、すべての要件がなくても作業を進めてもよいと感じている
• ビジネス担当者は、ソフトウェアを提供することに興奮している
• エンジニアは、問題が発生したときに話を聞いてもらえる
• 建物内に活気がある
• チームは、作業方法を決定する
• 人々は、通常の役割について話さない

彼は、アジャイルはパワーシフトであり、ITをビジネスに戻すものだと述べました。ビジネス用語では、ROI（投資収益率）が成功の唯一の真の尺度です。アジャイルに対する大きな危険は、人々がプラクティスに焦点を当てすぎて、より大きな全体像、つまりアジャイル開発の革命的な側面を忘れてしまうことでした。

プラクティスと哲学の相互作用は、しばらくの間、アジャイルとXPコミュニティを悩ませてきたものです。XPには、ソフトウェア開発方法に対するいくつかの重要な哲学的アプローチと、それを実行するための非常に具体的なプラクティスの両方が含まれているため、これは特にXPの場合に当てはまると考えています。これは、XPの本質とは何か、プラクティスなのか、それとも根底にある哲学なのか、という真の疑問につながりました。これは、XPの経験を積むほど、実際のプラクティスの遵守がそれほど重要ではなくなるため、特に顕著です。しかし同時に、XPとは何かを本当に理解するためには、プラクティスを実行しなければなりません（これは、XPのテーマのバリエーションで探求した難問です）。

多くの点で、「アジャイル」というラベルは、分離についてより簡単に考えるのに役立つと考えています。スノーバードでの集まりの真の価値は、プラクティスに違いがあっても、哲学に多くの同意が見出されたことでした。だからこそ、マニフェストの価値はこれほどまでに雄弁に語っているのです。Kenの意見に同意しますが、アジャイルの本質的な要素（予測型から適応型、プロセス指向から人指向）への移行は、進歩というよりは不連続性ですが、境界線を見極めるのは難しい場合があります。

しかし、私はプラクティスに焦点を当てることをそれほど心配していません。実際、それは不可欠だと考えています。優れた開発プラクティスは、アジャイル開発の約束を果たすために不可欠です。将来の柔軟性を維持するためには、XPが提供する進化型ソフトウェア設計などの技術が不可欠です。すべての部品が揃っていなければ、賞賛に値するスイス時計は存在しません。

優れたドキュメントを作成する

アジャイルカンファレンスは、昨年のXP Universeで講演を行ったCMMのMark Paulkのように、多くの人がアジャイルの大義の反対者と見なす人々を招待することをためらいませんでした。今年のXP 2002では、XPに対してより批判的な立場をとったDavid Parnasを迎えました。

彼は、XPの大きな問題は、40年間ソフトウェア開発を悩ませてきた問題に焦点を当てていることだと言いました。XPのコードへのフォーカスには利点がありましたが、他の重要なソフトウェア開発の問題に対処できていませんでした。ソフトウェアの最大の問題は、予期しないイベントへの対応が不十分なこと、そしてインターフェースの定義と制御が不十分なことでした。

彼の批判の焦点は、XPの設計アプローチであり、彼はそれが問題の遅延につながると述べました。これは経済学の問題であり、後でコストがかかることを犠牲にして、今お金を節約しています。シンプルさに焦点を当てるのは良いことですが、近視眼的なシンプルさと先見の明のあるシンプルさには違いがあります。真の長期的なシンプルさには計画が必要であり、計画にはレビューが必要であり、レビューにはドキュメントが必要ですが、コードからのフィードバックは遅すぎるからです。

しかし、彼はほとんどのプロジェクトが行っているようなドキュメントを推奨していたわけではありません。彼は、ほとんどのプロジェクトドキュメントは役に立たないどころか有害だと考えており、「未定義モデリング言語」を酷評しました。XPのテストケースは、完全ではないため、十分ではありません。彼は明確に定義された数学的アプローチを支持しましたが、形式手法コミュニティは正しい道を進んでいないと述べました。なぜなら、これらの数学的仕様はコードよりも読みやすくなければならないからです。これは、ZやVDMのような一般的な形式手法については言えないことです。

彼は、そのような数学的アプローチは、関数と関係に基づいている必要があると言いました。監視および制御する必要がある変数を特定し、監視された変数から制御された変数の派生を形成します。これらの変数は、ドメインエキスパートが読むことができる表形式で配置でき、制御された変数ごとに1つのテーブルが作成されます。彼は、パイロットがそのような仕様に基づいて数百のエラーを発見した航空電子工学システムのプロジェクトを引用しました。当然のことながら、時間的制約のため、彼はシステムを詳細に説明することができませんでした。

XPの設計アプローチに関する議論は白熱しており、XP 2000での私の講演のテーマとして使用しました。厳密でありながら読みやすい仕様というアイデアは、ソフトウェアにおける私の初期のキャリアの多くでテーマとなっていました。ソフトウェアカンファレンスでの私の最初の論文は、グラフィカルな設計手法を数学的に厳密な方法で使用する方法に関するもので、同じ方向へと向かっていました。

私の見解、そしてParnasもこれに同意すると思いますが、そのような形式仕様の価値は、他の技術よりも効果的に修正できるようにエラーを発見できる能力にあります。開発アプローチが計画設計であり、コーディングを開始する前に設計がほぼ完了していると予想される場合、これは不可欠です。そうでなければ、仕様のエラーはプロセスのずっと後にならないと発見できません。

XPはこの問題にいくつかの方法で対処します。短いイテレーションを使用することで、ユーザーは数週間で作業できるシステムを入手できるため、コードから迅速なフィードバックを得ることができます。リファクタリングを使用することで、近視眼的な単純化を、リファクタリングなしの場合よりも低いコストで修正できます。また、積極的なテストと継続的インテグレーションをサポートしています。

問題の核心は、この形式の数学的仕様がXPのアプローチよりも費用対効果が高いかどうか、そしてどのような条件下でそうなるかということです。私は、特定のアプローチがすべての種類のソフトウェア開発に必ずしも適切であるとは信じていません。そのため、航空電子工学に最適な方法が、エンタープライズアプリケーションに適した方法ではない場合があります。エンタープライズ分野でのより正式なアプローチに関する私の実験では、ドメインエキスパートは、反復的な配信ほどエラーを見つけることができないほど、それらをうまく活用できていないことがわかりました。私はまだ計画設計を少しだけ好みますが、XPのコンテキストにおける進化型設計の有効性にも驚きました。しかし、そうは言っても、私はParnasの特定の技術を試したことがありません。XPの人々が顧客と協力してこの技術を試してみて、それらを使用するコストに見合う価値があるかどうかを確認してくれることを願っています。Parnasはこれらの技術を予測的な設定で使用されるものと見なしていると思いますが、反復的な環境で使用できない理由はないと思います。

20 年前に捨てられたプラクティスの使用

もしDavid ParnasがXPコミュニティにとっての部外者だとすれば、経済学の教授であるEnrico Zaninottoは、ソフトウェア開発の世界全体にとっての部外者と言えるでしょう。彼は、あるソフトウェア開発プロジェクトが、20年前に主要メーカーが放棄した手法を用いているのを目にした経験から、アジャイルアプローチと製造業における最近の動向を比較することに興味を持ちました。

Zaninottoは、製造またはソフトウェア開発の取り組みに複雑さを加える4つの主要な要因を概説しました。

• システムが取り得る状態の数
• 様々な部分間の相互依存関係
• 実行可能な様々なアクションの不可逆性
• 環境における不確実性

彼は、TaylorとFordのモデルは、システムが取り得る状態の数という問題に焦点を当てることで複雑さを処理していると説明しました。彼らは、分業、標準化された部品、そして製造可能な製品を固定する組立ラインによって、これらの問題に取り組み、状態の数を制限しました。Zaninottoは、ウォーターフォール型のプロセスはこのモデルに従っていると考えています。Taylor/Fordモデルの限界は、予期せぬ結果に直面したときにありました。このアプローチは、何が起こるかを知っている状況では最適化されますが、不確実性に対して脆弱になります。

製造業のパラダイムシフトはトヨタ生産方式です。4つの複雑さの要因のうち、トヨタ生産方式は不可逆性に取り組み、決定の変更を可能にすると彼は述べました。Taylor/Fordは情報のフローを制御し、システムに組み込みますが、トヨタ生産方式は意思決定をアクションの時点まで押し上げます。

トヨタ生産方式のような柔軟なシステムの最大の難点は、収束しない可能性があることです。収束させるために、トヨタ生産方式はバリエーションを一定の範囲内に保ち、高レベルの品質管理を使用します。Zaninottoは、この収束の問題をXPの限界点と見なしました。XPの真の境界は、収束が依然として発生する場所の境界です。

私はZaninottoの講演を万全の状態で聞くことができませんでした。カンファレンスの夕食には素晴らしいバンドとたくさんのミルトがあり、夜遅くまで疲れ果ててしまいました。そして、8時30分は、私にとってどんなに調子が良くても簡単な時間ではありません。しかし、私は講演に魅了されました。母国語以外で講演したZaninottoは、原稿を読み上げましたが、多くの点で、そのシンプルな話し方は内容の質を高めていました。トヨタ生産方式とアジャイルプロセスとの関連性は、Mary Poppendieckがすでに示した領域であり、私はそれをさらに探求するようになりましたが、Zaninottoは私がすでに学んだことに新しいアイデアを追加してくれました。（これは、全文を読む価値がある数少ないケースの1つです。）

可逆性の問題、そして不可逆性が複雑さの原因であるという考えは、特に私の興味を引きました。DSDMの興味深い点の1つは、その中核となる9つの原則の1つが「開発中のすべての変更は可逆的である」ということです。このような方法論の最上位に可逆性を置くことは珍しいことです。1つの議論は、可逆性は増分変更に必要な保護であるということです。つまり、起こりうる最悪の事態は一時的な問題と以前の状態への復帰です。もちろん、これらの 一時的な問題は、コンピュータの欠陥のように非常に深刻な場合がありますが、障害が発見されれば、根本的な欠陥をすぐに見つけることができなくても、常に復帰によって修正できます。

最近のFDDの本を読んだとき、彼らの中核となるプラクティスのリストに構成管理が含まれていることに気づきました。構成管理はXPから除外されましたが、それは必要ないからではなく、XPerは構成管理を基本的な能力の一部と考えているからです。それでも、構成管理の適切な使用方法を理解していないと思われる人に出会うことは珍しくありません。

私が感銘を受けたもう1つの要素は、可逆性と反復開発の相互関係です。間違った決定を下し、それを迅速に検出した場合、何らかの形の可逆性を使用して間違いを元に戻すか、間違いが手に負えなくなる前にリファクタリングすることができます。しかし、すぐに検出できない場合、それはシステムに組み込まれ、元に戻すのが困難になります。反復サイクルにより、エラーが元に戻すのが難しくなる前に、早期にエラーを発見することができます。また、リファクタリングにより、エラーを削除するコストがさらに削減されます。その結果、最初に物事を正しく行う必要がないため、複雑さの主な原因がなくなります。厳密なプロセスの考え方の多くは、不可逆的なプロセスへの対処に関するものであり、不可逆性への対処を目的とした手法は、その複雑さが解消されると、余分な荷物になります。

XPプラクティスのメタファー

Bill Wakeは、今年の全体講演プログラムで唯一の確立されたXPリーダーであり、彼の貢献は他の多くの全体講演よりも軽い調子でした。彼のテーマはメタファーでした。XPのメタファープラクティスの意味ではなく、さまざまなXPプラクティスのためのメタファーという意味です。私がメモしたものを以下に示します。

• テストファーストは、偶数の答えしか教えてくれない数学の問題のようなものです。重要なのは答えではなく、実行することです。
• スパイクは、どのように機能するかを確認するためだけに構築する大工仕事のようなものです。テストファーストは、アイテムを作成する前に、物事がどのように適合するかを理解するのにも役立ちます。
• 共同コード所有権は、映画やテレビ番組（West Wingなど）のシチュエーションルームのようなものです。重要なのは、誰もがすべての情報にアクセスできるため、問題解決に貢献できることです。
• ペアプログラミングは、4手連弾のピアノ曲、あるいはタッグチームレスリングのようなものです。
• イテレーションは、時計の脱進機のようなものです。
• XPの学習は、外国語の学習のようなものです。
• 継続的インテグレーションは、小切手帳の残高合わせのようなものです。年に一度しか行わないと大変ですが、毎週行えば簡単です。
• クリーンな状態で帰宅する（グリーンバーでチェックインする）ことは、1日の終わりにポートフォリオのバランスを取るデイトレードのようなものです。
• スタンドアップミーティングは、レースのスタートのようなものです。その後、全員が同じ方向に走ります。
• イテレーションのふりかえりは、スポーツチームが前回の試合のビデオを見るようなものです。

メタファーはXPにおいて議論の的となるテーマです。メタファーがうまく機能すると、非常に満足できるものになることがわかりましたが、うまく機能するメタファーを思いつくのは非常に困難です。このようなメタファー的思考を必須プラクティスとして使用することは、単純なことで十分な仕事をする場合が多いのに、難しいことをするように求めるため、制限的です。そのため、XPで作業する場合、メタファーについてはあまり心配しませんが、良いメタファーが思い浮かんだ場合は、それを使用することを止めません。

ほとんどのメタファーと同様に、Billのメタファーのいくつかは興味深いと思いましたが、ほとんどは私にはうまく機能しませんでした。継続的インテグレーション == 小切手帳の残高合わせは非常にうまく機能しました。また、自動化されたサポートがあると小切手帳の残高合わせはさらに簡単になると付け加えたいと思います（Quickenの使用は非常に役立ちました）。また、シチュエーションルーム/共同コード所有権のアナロジーも気に入っています。West Wingを見たことがありませんが。

しかし、私は4手連弾のピアノ曲はあまり好きではありませんでした。タッグチームレスリングについてはどうでしょうか？少なくとも、Ron "The Hammer" JeffriesとAnn "Wild Woman" Anderson対Kent "Alpha Chimp" BeckとRobert "Black Hole" Martinのメンタルイメージで遊ぶことができます。（Rob Meeが私のタッグパートナーであることを確認したいだけです。）

必要な機能だけを構築する

Jim JohnsonはStandish Groupの会長であり、そのため、彼の講演の多くにStandish Groupが過去数年間追跡してきた統計が含まれていることは驚くべきことではありません。よく引用される見出しは、ITプロジェクトのわずか28％だけが実際に完全に成功しているということです。49％は「課題を抱えており」、23％は失敗しています。

もちろん、この種の統計は成功の定義に大きく依存しており、Standish Chaosレポートが成功を期限どおり、予算どおり、そして予想される機能のほとんどを備えていると定義していることは重要です。ほとんどのアジャイルコミュニティと同様に、私はこれを疑問視しています。私にとって、遅れて予算超過したプロジェクトは見積もりの失敗です。プロジェクトは遅延し、予算を大幅に超過する可能性がありますが、それでもWindows 95がMicrosoftにとってそうであったように、大きな成功を収めることができます。プロジェクトの成功は、ソフトウェアが投入されたリソースのコストよりも大きな価値を提供するかどうかということに関係しますが、これは測定するのが非常に困難です。

Jimが引用したもう1つの興味深い統計は、ソフトウェア製品で使用されていない機能の割合が高いことです。彼は2つの調査を引用しました。DuPontの調査では、システムの機能のわずか25％しか実際に必要とされていないとされています。Standishの調査では、機能の45％が使用されたことがなく、機能のわずか20％が頻繁にまたは常に使用されていることがわかりました。

これは確かに、従来の要件収集アプローチが、リリースの使い物になるバージョンに実際に必要な要件よりもはるかに多くの要件を収集してしまうと感じている多くのアジャイル主義者の事例証拠と一致しています。また、ほとんどのプロジェクトは現在の規模の4分の1程度であるべきであることも示唆しています。ソフトウェアの規模の不経済も考慮に入れると、これは多くのチームがはるかに小規模であるべきであることも示唆しています。

この点は、Johnsonが2つのSACWISシステムを比較した際に明確になりました。SACWISは、米国のすべての州が実装しなければならない児童福祉システムです。彼は、フロリダ州が1990年にSACWISシステムを開始し、当初のコスト見積もりは3200万ドルで、1998年に約100人の開発チームで納入される予定だったと述べました。最後に確認したところ、新しいコストは1億7000万ドルで、2005年に納入される予定でした。彼は、ミネソタ州はフロリダ州とほぼ同じ人口統計上の問題を抱えているため、ほぼ同じ広範なシステム要件で同じ機能を構築する必要があると指摘しました。ミネソタ州は1999年に作業を開始し、2000年に8人で110万ドルの費用で完了しました。

この比較は、Chet Hendricksonの「すべての大きなシステムの中には、外に出ようとしている小さなシステムがある」という言葉を驚くほどよく表しています。これらの2つのシステムのコストと労力がこれほどまでに異なる原因となった詳細を実際に判断することはできません。Standishグループは、この違いは主にミネソタ州が要件の最小化と標準インフラストラクチャの使用により成功したためであるとしました。少なくとも、要件を本質にまで煮詰めることに注意を払うことで得られる影響の大きさを示唆しています。もちろん、アジャイルの主張は、事前に要件を収集するよりも、価値に基づく短いイテレーションの方が要件を最小限に抑える可能性が高いということです。それに関する実際のデータが得られるまでには、しばらく時間がかかるでしょう。

この「アジャイルな論争」に賛同するかどうかに関わらず、SACWISの事例は、ソフトウェア業界が「価値を提供するために、どれほど少ない機能で済むのか」を理解するという、非常に現実的な課題に直面していることを示唆していると思います。必要な機能だけを構築することで、ソフトウェアシステムのコストを大幅に削減できることを示唆しているのです。私の見解では、事前の要件定義プロセスは、この点で逆効果です。なぜなら、多くの場合、人々はコストを考慮せずに要件を考えているからです。私が調べた要件定義書には、コストや、要件収集の一環としてコストを理解することの重要性について、ほとんど言及されていません。コストを考慮しない要件定義書は、特に、不必要な費用を固定してしまう固定範囲/固定価格の契約に結びついている場合、過剰な開発をほぼ確実に招くでしょう。