新しい方法論

設計と構築の分離

方法論の一般的なインスピレーションは、土木工学や機械工学などのエンジニアリング分野です。そのような分野は、構築前に計画を重視します。このようなエンジニアは、構築する必要があるものと、これらのものをどのように組み合わせる必要があるかを正確に示す一連の図面に取り組みます。橋の荷重に対処する方法など、多くの設計上の決定は、図面が作成される際に下されます。図面は、多くの場合異なる会社である別のグループに引き渡され、構築されます。構築プロセスは図面に沿って行われると想定されています。実際には、建設業者はいくつかの問題に遭遇しますが、これらは通常小さなものです。

図面は部品とそれらをどのように組み立てる必要があるかを指定しているため、詳細な建設計画の基礎として機能します。このような計画は、実行する必要のあるタスクと、これらのタスク間に存在する依存関係を把握できます。これにより、建設のスケジュールと予算を合理的に予測できます。また、建設作業を行う人がどのように作業を行うべきかを詳細に示します。これにより、建設は知的にはそれほど熟練する必要はありませんが、手作業では非常に熟練していることがよくあります。

したがって、ここで見られるのは、根本的に異なる2つの活動です。予測が難しく、コストがかかり創造的な人々を必要とする設計と、予測が容易な構築です。設計が完了したら、構築を計画できます。構築の計画が完了したら、構築をより予測可能な方法で処理できます。土木工学では、構築は設計と計画よりもコストと時間の両方で大きくなります。

したがって、ソフトウェアエンジニアリングの方法論のアプローチは次のようになります。私たちは、より低いスキルを持つ人々を使用できる予測可能なスケジュールを求めています。これを行うには、設計を構築から分離する必要があります。したがって、計画が完了したら、構築が簡単になるように、ソフトウェアの設計方法を把握する必要があります。

では、この計画はどのような形をとるのでしょうか？多くの人にとって、これはUMLなどの設計表記法の役割です。UMLを使用してすべての重要な決定を下すことができる場合は、建設計画を作成し、これらの設計を建設活動としてコーダーに渡すことができます。

しかし、ここに重要な質問があります。コーディングを予測可能な建設活動に変えることができる設計を得ることができますか？もしそうなら、このアプローチを価値のあるものにするのに十分にコストが小さいですか？

これらのことから、いくつか疑問が湧いてきます。まず第一に、UMLのような設計をプログラマーに引き渡せる状態にするのがどれほど難しいかという問題です。UMLのような設計の問題点は、紙の上では非常に良く見えるものの、実際にプログラムする必要が生じると、深刻な欠陥がある可能性があることです。土木技師が使用するモデルは、長年の実践に基づいており、工学コードに規定されています。さらに、設計における力の働き方などの重要な問題は、数学的な分析に適しています。UMLのような図面に対してできる唯一のチェックは、ピアレビューです。これは役立つものの、設計上のエラーにつながることが多く、コーディングやテスト中に初めて発見されることがよくあります。私自身も含め、熟練した設計者でさえ、このような設計をソフトウェアに変換するときには驚かされることがよくあります。

もう1つの問題は、費用対効果の比較です。橋を建設する場合、設計にかかる費用は全体の約10％で、残りは建設費用です。ソフトウェアでは、コーディングに費やす時間ははるかに少なくなります。McConnellは、大規模プロジェクトの場合、プロジェクトのわずか15％がコードと単体テストであり、橋梁建設の比率とほぼ完全に逆転していると指摘しています。テストをすべて建設の一部として含めたとしても、設計は依然として作業の50％を占めます。これは、ソフトウェアにおける設計の性質と、他の工学分野におけるその役割を比較する上で重要な疑問を提起します。

これらの種類の疑問から、ジャック・リーブスは、実際にはソースコードが設計書であり、建設段階は実際にはコンパイラとリンカーの使用であると示唆しました。実際、建設として扱うことができるものはすべて自動化されるべきです。

この考え方は、いくつかの重要な結論につながります。

• ソフトウェアでは、建設は非常に安価であり、無料同然である。
• ソフトウェアでは、すべての労力が設計に費やされ、そのため創造的で才能のある人々が必要となる。
• 創造的なプロセスは容易に計画できるものではないため、予測可能性は不可能目標である可能性がある。
• ソフトウェア構築に関する従来の工学的な比喩には、非常に注意する必要がある。それは異なる種類のアクティビティであり、異なるプロセスが必要である。

要件の予測不可能性

私が遭遇したすべての問題プロジェクトで耳にした決まり文句があります。開発者が私に「このプロジェクトの問題は、要件が常に変化していることだ」と言うのです。この状況で私が驚くのは、誰もがそれに驚いていることです。ビジネスソフトウェアを構築する場合、要件の変更は日常茶飯事であり、問題はそれに対してどう対処するかということです。

1つの方法は、要件の変更を要件エンジニアリングの不備の結果として扱うことです。要件エンジニアリングの背後にある考え方は、ソフトウェアの構築を開始する前に要件を完全に理解し、これらの要件に対する顧客の承認を得て、承認後に要件の変更を制限する手順を設定することです。

この問題点の1つは、要件のオプションを理解しようとすること自体が難しいということです。さらに難しいのは、開発組織が通常、要件に関するコスト情報を提供しないためです。結局、自分の車にサンルーフを付けたいと思っているのに、営業担当者がサンルーフの費用が10ドルなのか10,000ドルなのかを教えてくれない状況に陥ります。コストがほとんどわからない状態で、そのサンルーフにお金を払う価値があるかどうかをどうやって判断できるでしょうか？

見積もりは多くの理由で難しいです。その一部は、ソフトウェア開発が設計活動であり、計画とコスト計算が困難であるということです。その一部は、基本的な材料が急速に変化し続けているということです。その一部は、どの個人が関与するかによって大きく異なり、個人は予測して定量化することが難しいということです。

ソフトウェアの無形性も影響しています。ソフトウェア機能の価値を実際に使用するまで確認することは非常に困難です。ソフトウェアの初期バージョンを使用してみて初めて、どの機能が価値があり、どの部分がそうでないかを実際に理解し始めます。

これにより、人々が要件は変更可能であると期待するという皮肉な点につながります。結局のところ、ソフトウェアは「ソフト」であるはずです。したがって、要件は変更可能なだけでなく、変更可能であるべきです。ソフトウェアの顧客に要件を固定させるには、多くのエネルギーが必要です。ソフトウェア開発に少しでも関わったことがある場合はさらに状況が悪化します。なぜなら、彼らはソフトウェアが簡単に変更できることを「知っている」からです。

しかし、たとえそれらすべてを解決して、正確で安定した要件セットを本当に得ることができたとしても、おそらくまだ失敗する運命にあるでしょう。今日の経済では、基本的なビジネス要因によって、ソフトウェア機能の価値が急速に変化しています。今では適切な要件セットであっても、半年後には適切なセットではなくなる可能性があります。たとえ顧客が要件を固定できたとしても、ビジネスの世界は彼らのために停止することはありません。そして、ビジネスの世界の多くの変化は完全に予測不可能です。そうでないと言う人は、嘘をついているか、すでに株式市場で10億ドルを稼いでいます。

ソフトウェア開発における他のすべてのものは、要件に依存します。安定した要件を得ることができない場合、予測可能な計画を得ることはできません。

予測可能性は不可能か？

一般的に、不可能です。予測可能性が可能なソフトウェア開発もいくつかあります。NASAのスペースシャトルソフトウェアグループなどの組織は、ソフトウェア開発が予測可能になる可能性のある代表的な例です。これには、多くの儀式、十分な時間、大規模なチーム、および安定した要件が必要です。そこには宇宙シャトルであるプロジェクトもあります。しかし、ビジネスソフトウェアの多くはそのカテゴリに当てはまらないと思います。このためには、異なる種類のプロセスが必要です。

大きな危険の1つは、できないときに予測可能なプロセスに従うことができると装うことです。方法論に取り組む人々は、境界条件、つまり方法論が適切から不適切に移行する場所を特定するのがあまり得意ではありません。ほとんどの方法論者は、自分の方法論を誰でも使えるようにしたいと考えているため、境界条件を理解したり公表したりしません。これにより、予測不可能な状況で予測可能な方法論を使用するなど、誤った状況で方法論を使用する人が生まれます。

そうしたいという強い誘惑があります。予測可能性は非常に望ましい特性です。しかし、できないときに予測可能であると信じていると、早期に計画を立てても、計画が崩れた状況に適切に対処しない状況につながります。計画と現実がゆっくりと乖離していくのがわかります。長い間、計画がまだ有効であると装うことができます。しかし、ある時点でずれが大きくなりすぎて計画が崩壊します。通常、その崩壊は苦痛を伴います。

したがって、予測不可能な状況にある場合は、予測的な方法論を使用することはできません。これは大きな打撃です。これは、プロジェクトを制御するための多くのモデル、顧客関係全体に対する多くのモデルが、もはや真実ではないことを意味します。予測可能性の利点は非常に大きいため、それらを手放すのは困難です。多くの問題と同様に、最も難しい部分は、問題が存在することを認識することだけです。

しかし、予測可能性を手放すことは、制御不能な混乱に戻る必要はないことを意味します。代わりに、予測不可能性を制御できるプロセスが必要です。それが適応性のすべてです。

予測不可能なプロセスを制御する - イテレーション

では、予測不可能な世界でどのように自分自身をコントロールするのでしょうか？最も重要で、依然として難しい部分は、自分がどこにいるかを正確に知ることです。現在の状況を頻繁に正確に伝えることができる正直なフィードバックメカニズムが必要です。

このフィードバックの鍵は、反復開発です。これは新しいアイデアではありません。。反復開発は、増分、進化型、段階型、スパイラルなど、さまざまな名前でしばらくの間存在しています。反復開発の鍵は、必要な機能のサブセットを備えた最終システムの作業バージョンを頻繁に生成することです。これらの作業システムは機能が不足していますが、最終システムの要求に忠実でなければなりません。それらは完全に統合されており、最終的な配送と同様に慎重にテストされる必要があります。

重要なのは、プロジェクトに現実を力強く導入する上で、テスト済みの統合システムに勝るものはないということです。ドキュメントはあらゆる種類の欠陥を隠す可能性があります。テストされていないコードは多くの欠陥を隠す可能性があります。しかし、人々が実際にシステムの前に座って作業すると、バグと誤解された要件の両方の点で、欠陥が本当に明らかになります。

反復開発は、予測可能なプロセスでも理にかなっています。しかし、適応プロセスでは、必要な機能の変更に対処できる必要性があるため、不可欠です。これにより、長期的な計画が非常に流動的になり、唯一の安定した計画が単一の反復のために立てられた短期的な計画になるような計画スタイルにつながります。反復開発は、後で計画を立てるための確固たる基盤を各反復で提供します。

これに関する重要な質問は、反復がどのくらいの長さであるべきかということです。人によって答えが異なります。XPでは1週間または2週間の反復が提案されています。SCRUMでは1ヶ月の長さが提案されています。Crystalはさらに長くなる可能性があります。しかし、傾向としては、各反復をできるだけ短くすることです。これにより、フィードバックの頻度が高くなり、自分がどこにいるかをより頻繁に把握できます。

適応型顧客

この種の適応プロセスでは、特に開発が別の企業によって行われる場合、通常考えられているものとは異なる顧客との関係が必要です。ソフトウェア開発を別の企業に依頼する場合、ほとんどの顧客は固定価格契約を望んでいます。開発者に何を求めているかを伝え、入札を依頼し、入札を受け入れれば、ソフトウェアを構築する責任は開発組織にあります。

固定価格契約には、安定した要件と、したがって予測的なプロセスが必要です。適応プロセスと不安定な要件は、固定価格の通常の概念では機能しないことを意味します。適応プロセスに固定価格モデルを当てはめようとすると、非常に痛みを伴う爆発につながります。この爆発の厄介な点は、顧客がソフトウェア開発会社と同じくらい傷つくことです。結局のところ、顧客は自分のビジネスで必要としない限り、ソフトウェアを欲しがらないでしょう。それを得ることができない場合、彼らのビジネスは損害を被ります。したがって、開発会社にお金を払わなくても、彼らは損をします。実際、ソフトウェアに支払うよりも多くの損をします（ソフトウェアのビジネス価値がそれよりも低い場合、なぜソフトウェアにお金を払うでしょうか？）。

したがって、予測的なプロセスを使用できない状況で従来の固定価格契約を締結することには、両当事者にとって危険があります。これは、顧客が異なる方法で作業する必要があることを意味します。

これは、ソフトウェアの予算を事前に固定できないという意味ではありません。これが意味することは、時間、価格、範囲を固定できないということです。通常のアジャイルアプローチは、時間と価格を固定し、範囲を制御された方法で変更できるようにすることです。

適応プロセスでは、顧客はソフトウェア開発プロセスをより細かく制御できます。すべての反復で、進捗状況を確認し、ソフトウェア開発の方向性を変更することができます。これにより、ソフトウェア開発者とのより緊密な関係、真のビジネスパートナーシップにつながります。このレベルの関与は、すべての顧客組織、すべてのソフトウェア開発者に適しているわけではありません。しかし、適応プロセスを適切に機能させるためには不可欠です。

これらすべてにより、顧客にとって多くの利点が得られます。まず、はるかに応答性の高いソフトウェア開発が実現します。最小限ではありますが、実用的なシステムを早期に本番環境に移行できます。その後、顧客はビジネスの変化に応じて、またシステムが実際にどのように使用されているかから学習して、その機能を変更することができます。

これと同じくらい重要なのは、プロジェクトの真の状態に対する可視性の向上です。予測型プロセスの問題は、プロジェクトの品質が計画への適合度によって測定されることです。そのため、現実と計画が乖離したときに、人々がそれを知らせることが難しくなります。一般的な結果として、プロジェクトの終盤でスケジュールが大きく遅れることになります。アジャイルプロジェクトでは、反復ごとに計画が常に再調整されます。悪いニュースが潜んでいる場合、何か対策を講じる時間があるうちに、早期に表面化する傾向があります。実際、このリスク管理は反復型開発の重要な利点です。

アジャイル手法は、反復の長さを短く保つだけでなく、これらの変動を異なる視点で見ることによって、これをさらに発展させます。メアリー・ポッペンディークは、私にとってこの視点の違いを「要件の遅延による変更は競争上の優位性である」という言葉で最もよく要約しました。ほとんどの人が、ビジネス担当者が最初にソフトウェアに何を求めているかを本当に理解するのは非常に難しいことに気づいていると思います。多くの場合、人々はプロセス中に、どの要素が価値があり、どれが価値がないかを学びます。多くの場合、最も価値のある機能は、顧客がソフトウェアを実際に使用してみるまでまったく明らかになりません。アジャイル手法はこれを利用しようとし、ビジネス担当者がシステムが構築されるにつれてニーズを学び、変更を迅速に取り込むことができるような方法でシステムを構築することを推奨します。

これらすべては、プロジェクトの成功を構成するものに重要な影響を与えます。予測型プロジェクトは、計画をどれだけうまく達成できたかによって測定されることがよくあります。予定どおり、予算どおりのプロジェクトは成功と見なされます。この測定は、アジャイル環境ではナンセンスです。アジャイルの支持者にとっての問題は、ビジネス価値です。顧客は、投入されたコストよりも価値のあるソフトウェアを手に入れたかどうかです。優れた予測型プロジェクトは計画どおりに進み、優れたアジャイルプロジェクトは、当初の計画が予見していたものとは異なり、より優れたものを構築します。

プラグ互換のプログラミングユニット

従来の方法論の目的の1つは、関与する人々が交換可能な部品であるようなプロセスを開発することです。このようなプロセスでは、人々をさまざまなタイプで利用可能なリソースとして扱うことができます。アナリスト、コーダー、テスター、マネージャーがいます。個人はそれほど重要ではなく、役割だけが重要です。そうすれば、プロジェクトを計画する際に、どのアナリストとどのテスターを取得しても問題ありません。必要な数がわかれば、リソースの数が計画にどのように影響するかを知ることができます。

しかし、これは重要な疑問を提起します。ソフトウェア開発に関わる人々は交換可能な部品なのでしょうか？アジャイル手法の重要な特徴の1つは、この仮定を拒否することです。

おそらく、人々をリソースとして扱うことに対する最も明確な拒否は、アリスティア・コックバーンによるものです。彼の論文「ソフトウェア開発における非線形、一次要素としての人の特徴づけ」では、予測可能なプロセスには予測可能な方法で動作するコンポーネントが必要であると指摘しています。しかし、人は予測可能なコンポーネントではありません。さらに、彼のソフトウェアプロジェクトの研究から、人はソフトウェア開発において最も重要な要素であるという結論に至りました。

記事のタイトルで、私は人々を「コンポーネント」と呼んでいます。これは、プロセス/方法論の設計文献で人々が扱われる方法です。このアプローチの間違いは、「人々」は非常に変動的で非線形であり、独自の成功と失敗のモードを持っているということです。これらの要因は、無視できない一次要素です。プロセスと方法論の設計者がそれらを考慮しないことが、私たちがよく目にする計画外のプロジェクト軌跡につながっています。

-- [cockburn-non-linear]

ここで、ソフトウェア開発の本質が私たちに不利に働いているのではないかと思われます。コンピューターをプログラミングするとき、私たちは本質的に予測可能なデバイスを制御しています。私たちがこのビジネスにいるのは、それを得意とするからです。そのため、人々と向き合う際に混乱するのに最適な状態です。

コックバーンは、ソフトウェア開発における人間中心の視点を最も明確に述べていますが、人を第一とするという概念は、ソフトウェアの多くの思想家にとって共通のテーマです。あまりにも頻繁に問題となるのは、方法論がプロジェクトの成功における第一要素としての人の概念に反対してきたことです。

これは強力な正のフィードバック効果を生み出します。すべての開発者をプラグ互換のプログラミングユニットとして期待する場合、それらを個人として扱おうとしません。これにより、士気が低下します（生産性も低下します）。優秀な人々はより良い場所を探し、最終的にはあなたが望むようなプラグ互換のプログラミングユニットになります。

人を第一に考えるという決定は大きな決断であり、それを押し進めるには多くの決意が必要です。人をリソースとして捉えるという概念は、ビジネスの考え方に深く根付いており、そのルーツはフレデリック・テイラーの科学的管理アプローチの影響にまで遡ります。工場を運営する場合、このテイラー主義のアプローチは理にかなっているかもしれません。しかし、高度に創造的で専門的な仕事、つまり私がソフトウェア開発であると信じているものについては、これは当てはまりません。（そして、実際、現代の製造業もテイラー主義モデルから離れつつあります。）

プログラマーは責任ある専門家である

テイラー主義の重要な部分は、仕事をしている人々が、その仕事を最も効果的に行う方法を最もよく理解できる人々ではないということです。工場では、いくつかの理由からこれが当てはまる可能性があります。その理由の1つは、多くの工場の労働者が最も知的で創造的な人々ではないということです。これは、管理職と労働者の間に緊張関係があり、管理職は労働者が少なく稼ぐほど多くの金を稼ぐという緊張関係があるためです。

近年の歴史は、これがソフトウェア開発には当てはまらないことをますます示しています。ますます明るく有能な人々が、その華やかさと潜在的な高額報酬の両方に惹かれて、ソフトウェア開発に惹きつけられています。（どちらも私が電子工学から離れる誘惑になりました。）2000年代初頭の不況にもかかわらず、ソフトウェア開発には依然として多くの才能と創造性があります。

（ここには世代的な影響があるかもしれません。いくつかの逸話的な証拠から、過去15年ほどで、より優秀な人々がソフトウェアエンジニアリングに挑戦しているのではないかと思われます。もしそうなら、これがコンピューター業界に若者のカルトがある理由であり、ほとんどのカルトのように、それには真実の断片が必要です。）

優秀な人を採用して維持したい場合は、彼らが有能な専門家であることを認識する必要があります。そのため、彼らは技術的な仕事の進め方を決定するのに最適な人々です。計画部門がどのように物事を行うかを決定するというテイラー主義の概念は、計画担当者がその仕事をする人よりもその仕事のやり方をよく理解している場合にのみ機能します。もし、明るく、やる気のある人がその仕事をしているのであれば、これは当てはまりません。

人を中心としたプロセスの管理

人への指向は、アジャイルプロセスでさまざまな形で現れます。それは異なる効果につながりますが、それらのすべてが一貫しているわけではありません。

重要な要素の1つは、プロセスの押し付けではなく、プロセスを受け入れることです。多くの場合、ソフトウェアプロセスは管理職によって押し付けられます。そのため、特に管理職が現役の開発からかなりの時間が経っている場合は、反発されることがよくあります。プロセスを受け入れるにはコミットメントが必要であり、そのためにはチーム全員の積極的な関与が必要です。

これは、開発者自身だけが適応型プロセスに従うことを選択できるという興味深い結果につながります。これは、実行するために多くの規律が必要なXPに特に当てはまります。Crystalは、より幅広い聴衆に適した、それほど規律のないアプローチであると見なしています。

もう1つのポイントは、開発者がすべての技術的な決定を下せる必要があるということです。XPは、計画プロセスで、作業を行うのにどれくらいの時間がかかるかの見積もりを立てることができるのは開発者のみであると述べている点で、これの中核を突いています。

このような技術的なリーダーシップは、多くの管理職にとって大きな変化です。このようなアプローチでは、開発者と管理職がプロジェクトのリーダーシップにおいて平等な立場を持つ責任の分担が必要です。私が「平等」と言っていることに注意してください。管理職は依然として役割を果たしますが、開発者の専門知識を認識しています。

これの重要な理由の1つは、私たちの業界におけるテクノロジーの変化率です。数年後には、技術的な知識は時代遅れになります。この技術的なスキルの半減期は、他のどの業界にも匹敵しません。技術者でさえ、管理職になることは、技術的なスキルが急速に衰えることを意味することを認識する必要があります。元開発者は、自分の技術的なスキルが急速に消え、現在の開発者を信頼し、頼る必要があることを認識する必要があります。

測定の難しさ

どのように作業を行うかを指示する人が、実際に作業を行う人と異なるプロセスがある場合、リーダーは、作業を行う人がどれだけ効果的であるかを測定する方法が必要です。科学的管理では、人々の生産量を測定するための客観的なアプローチを開発しようとする強い動きがありました。

これは、ソフトウェアへの測定の適用が困難であるため、ソフトウェアに特に関係があります。私たちの最善の努力にもかかわらず、生産性など、ソフトウェアに関する最も単純なことを測定することはできません。これらのことに関する適切な測定がない場合、あらゆる種類の外部制御は失敗する運命にあります。

適切な測定なしに測定された管理を導入すると、それ自体の問題につながります。ロバート・オースティンは、このことについて優れた議論をしました。彼は、パフォーマンスを測定する際には、すべての重要な要素を測定対象にする必要があると指摘しています。欠落しているものがあれば、必然的に、作業を行う人は、たとえそれが彼らの本当の有効性を明らかに低下させるとしても、最良の測定値を生み出すために彼らの行動を改めるでしょう。この測定機能障害は、測定に基づく管理のアキレス腱です。

オースティンの結論は、測定に基づく管理と委任管理（作業者が作業方法を決定する）のいずれかを選択する必要があるということです。測定に基づく管理は、反復的な単純な作業、低い知識要件、および測定が容易な出力に最適です。まさにソフトウェア開発の正反対です。

ここで重要なのは、従来のやり方では、測定に基づいた管理が最も効率的な管理方法であるという前提で運用されてきたということです。アジャイルコミュニティは、ソフトウェア開発の特性上、測定に基づいた管理は非常に高いレベルでの測定機能不全につながることを認識しています。実際には、委任型の管理スタイルを使用する方が効率的であり、これはアジャイルの視点の中心となる種類のアプローチです。

ビジネスリーダーシップの役割

しかし、技術者だけでプロセス全体を遂行することはできません。ビジネスニーズに関するガイダンスが必要です。これにより、適応型プロセスのもう一つの重要な側面、すなわち、ビジネスの専門知識との緊密な連携が必要になります。

これは、ほとんどのプロジェクトにおけるビジネスロールの関与を超えたものです。アジャイルチームは、時折のコミュニケーションだけでは存在し得ません。ビジネスの専門知識への継続的なアクセスが必要です。さらに、このアクセスは管理レベルで処理されるものではなく、すべての開発者に提供されるものです。開発者は自身の専門分野において有能なプロフェッショナルであるため、他の分野のプロフェッショナルと対等に働くことができる必要があります。

もちろん、その大部分は適応型開発の性質によるものです。適応型開発の前提全体が、物事が急速に変化するというものであるため、変更を全員に知らせるための継続的な連絡が必要です。

開発者にとって、自分の苦労が無駄になるのを見るほどイライラすることはありません。したがって、開発者が利用できるだけでなく、開発者が信頼できるだけの十分な品質を備えた、質の高いビジネス専門知識を確保することが重要です。

アジャイルマニフェスト

「アジャイル」という用語は、2001年初頭にこの活動のためにハイジャックされました。この活動に深く関わってきた人々が集まって意見交換を行い、アジャイルソフトウェア開発のためのマニフェストを作成したときです。

このワークショップに先立って、多くの異なるグループがソフトウェア開発に関する同様のアイデアを開発していました。この作業のほとんどすべてではありませんが、そのほとんどは、反復型開発アプローチを長らく提唱してきたオブジェクト指向ソフトウェアコミュニティから生まれました。このエッセイは、もともと2000年に、これらのさまざまな流れをまとめようとして書かれました。当時、これらのアプローチの共通の名前はありませんでしたが、「軽量」という愛称がそれらの周りに生まれていました。関与した多くの人々は、これがこれらのアプローチの本質を正確に伝えていないため、良い用語ではないと感じていました。

2000年、オレゴン州でケント・ベックが主催したワークショップで、これらのアプローチにおけるより広範な問題について話し合われていました。このワークショップはエクストリームプログラミング（当時、最も注目を集めていたコミュニティ）に焦点を当てていましたが、複数の非XP者が参加していました。議論されたことの一つは、XPが広範な動きである方が良いか、具体的な動きである方が良いかということでした。ケントは、より焦点を絞った結束力のあるコミュニティを好みました。

ワークショップは、私の記憶が正しければ、主にジム・ハイスミスとボブ・マーティンによって組織されました。彼らは、同様のアイデアを持つコミュニティで活動していると感じた人々に連絡を取り、スノーバードワークショップのために17人を集めました。当初のアイデアは、互いのアプローチに対する理解を深めるために集まるだけでした。ロバート・マーティンは、業界をこれらの種類のテクニックに結びつけるために使用できるマニフェストのような声明を得ることに熱心でした。また、さまざまなアプローチの包括的な名前として機能する名前を選択することにしました。

ワークショップの過程で、「アジャイル」を包括的な名前として使用することに決め、マニフェストの一部である価値観を思いつきました。原則のセクションはワークショップで開始されましたが、主にその後Wikiで開発されました。

この努力は明らかに神経に触れたと思います。マニフェストが受けた注目と感謝の度合いに、私たち全員が非常に驚いたと思います。マニフェストはアジャイルの厳密な定義ではありませんが、アイデアを集中させるのに役立つ焦点となる声明を提供します。マニフェストが完成して間もなく、ジム・ハイスミスと私は、マニフェストに関する解説を提供したSDマガジンの記事を書きました。

その年の後半、マニフェストを書いた17人のほとんどが、OOPSLA 2001で他の多くの人と再び集まりました。マニフェストの著者が進行中のアジャイル運動を開始すべきだという提案がありましたが、著者は、そのワークショップにたまたま参加してマニフェストを作成した人々でしかないことに同意しました。そのグループがアジャイルコミュニティ全体のリーダーシップを主張する方法はありませんでした。私たちは船を打ち上げたのを手伝ったので、彼女の中で航海したい人が誰でもそうできるように、それを手放すべきです。それが、組織化された団体としての17人のマニフェスト著者の終わりでした。

この次のステップは、これらの著者の多くが積極的に関与して、アジャイルアライアンスの設立につながりました。このグループは、アジャイル手法を推進および研究することを目的とした非営利グループです。とりわけ、米国で毎年開催される会議を後援しています。

XP（エクストリームプログラミング）

1990年代後半のアジャイル手法の人気が高まった初期には、エクストリームプログラミングが最大の注目を集めました。多くの点で、今でもそうです。

XPのルーツは、スモールトークコミュニティ、特に1980年代後半のケント・ベックとウォード・カニンガムの緊密な協力関係にあります。両者とも、90年代初頭の数多くのプロジェクトで実践を洗練させ、適応型で人間志向のソフトウェア開発アプローチのアイデアを拡張しました。

ケントは、コンサルティング契約、特にクライスラーC3プロジェクトでアイデアの開発を続けました。このプロジェクトは、後にエクストリームプログラミングの創設プロジェクトとして知られるようになりました。彼は1997年頃から「エクストリームプログラミング」という用語を使い始めました。（C3は、エクストリームプログラミングとの私の最初の接触であり、ケントとの友情の始まりでもありました。）

1990年代後半、エクストリームプログラミングの話は、当初はニュースグループやウォード・カニンガムのWikiでの説明を通じて広まりました。ケントとロン・ジェフリーズ（C3の同僚）は、さまざまなアイデアについて説明し、議論するのに多くの時間を費やしました。最後に、90年代の終わりから00年代の初めにかけて、このアプローチのさまざまな側面を詳細に説明した多くの本が出版されました。これらの本のほとんどは、ケント・ベックのホワイトブックを基盤としていました。ケントは、2004年にホワイトブックの第2版を作成しました。これは、アプローチを大幅に再明確化したものです。

XPは、5つの価値観（コミュニケーション、フィードバック、シンプルさ、勇気、尊重）から始まります。次に、これらを14の原則に、さらに24の実践に詳しく説明します。アイデアは、実践はチームが日々行うことができる具体的なものであり、価値観はこのアプローチを支える基本的な知識と理解であるということです。実践のない価値観は適用が難しく、非常に多くの方法で適用できるため、どこから始めればよいかわかりません。価値観のない実践は、目的のない暗記活動です。価値観と実践の両方が必要ですが、それらの間には大きなギャップがあります。原則は、そのギャップを埋めるのに役立ちます。XPの実践の多くは、古く、試行錯誤を重ねたテクニックですが、ほとんどの計画されたプロセスを含む多くの人に忘れられがちです。これらのテクニックを復活させるだけでなく、XPはそれらを互いに補強し合い、価値観によって目的が与えられる相乗的な全体に織り込んでいます。

最も印象的で、当初は私にとって魅力的だったのは、テストに重点を置いていることです。すべてのプロセスがテストについて言及していますが、ほとんどの場合、非常に低い重要度で言及しています。ただし、XPはテストを開発の基礎に置き、すべてのプログラマーがプロダクションコードを書くときにテストを記述します。テストは継続的な統合およびビルドプロセスに統合され、将来の開発のための非常に安定したプラットフォームを生み出します。XPのアプローチは、テスト駆動開発（TDD）の見出しで説明されることが多く、XPの他の部分をあまり採用していない場所でも影響力がありました。

エクストリームプログラミングに関する出版物は非常に多いです。しかし、混乱している点の一つは、ホワイトブックの初版と第2版の間の変化です。上で述べたように、第2版はエクストリームプログラミングの「再構成」であり、アプローチは同じですが、異なるスタイルで記述されています。初版（4つの価値観、12のプラクティス、そして重要だがほとんど無視された原則）はソフトウェア業界に大きな影響を与え、エクストリームプログラミングの説明のほとんどは初版の記述に基づいて書かれました。特に2005年より前に作成されたXPに関する資料を読む際には、この点を念頭に置いてください。実際、XPに関する一般的なウェブ上の説明のほとんどは初版に基づいています。

詳しく知るための自然な出発点は、ホワイトブックの第2版です。この本は、XPの背景とプラクティスを短い（160ページ）パッケージで説明しています。ケント・ベックは、世紀の変わり目頃にエクストリームプログラミングに関する多色刷りの本シリーズを編集しました。もし1冊選ぶとしたら、紫色の本をお勧めします。ほとんどの資料と同様に、これは初版に基づいていることを覚えておいてください。

ウェブ上にはXPに関する多くの資料がありますが、そのほとんどは初版に基づいています。私が知っている数少ない第2版を考慮した説明の1つは、サルデーニャで最初のXP会議を主催したミケーレ・マルケージによるThe New XP（PDF）に関する論文です。XPに関する議論については、yahooのメーリングリストがあります。

初期の頃の私の関与とXPコミュニティ内の友情は、私がXPに対して特別な親しみと偏見を持っていることを意味します。その影響は、アジャイル開発の原則と、それらを実際に実行するための確固たる技術を結びつけたことにあると思います。アジャイルに関する初期の著作の多くは後者を無視し、アジャイルのアイデアが本当に可能なのかという疑問を提起しました。XPは、アジリティの希望を実現するためのツールを提供しました。

スクラム

スクラムもまた、80年代から90年代にかけて、主にOO開発サークルで高度な反復開発手法として開発されました。最も有名な開発者は、ケン・シュウェイバー、ジェフ・サザーランド、マイク・ビードルでした。

スクラムはソフトウェア開発の管理面に焦点を当てており、開発を30日間のイテレーション（「スプリント」と呼ばれる）に分割し、毎日のスクラムミーティングでより緊密な監視と制御を適用します。エンジニアリングの実践にはあまり重点を置いておらず、多くの人々がそのプロジェクト管理アプローチをエクストリームプログラミングのエンジニアリングの実践と組み合わせています。（XPの管理プラクティスは実際にはそれほど違いはありません。）

ケン・シュウェイバーはスクラムの最も積極的な提唱者の1人であり、彼のウェブサイトはより多くの情報を探すのに良い出発点であり、彼の本はおそらく最初の参考資料として最適です。

クリスタル

アリスター・コックバーンは、長年にわたりアジャイルコミュニティの主要な声の1人でした。彼は、チームの規模に合わせて調整された一連のアプローチとして、Crystalファミリーのソフトウェア開発手法を開発しました。アリスターは、チームの規模やエラーの重大度が変化するにつれて、異なるアプローチが必要だと考えているため、Crystalはファミリーとして見なされています。

それらのバリエーションにもかかわらず、すべてのCrystalアプローチは共通の機能を共有しています。すべてのCrystalメソッドには、3つの優先順位があります。安全性（プロジェクトの成果）、効率性、居住性（開発者がCrystalを受け入れることができる）。また、共通のプロパティも共有しており、最も重要な3つは、頻繁なデリバリー、反省的な改善、および密接なコミュニケーションです。

居住性の優先順位は、Crystalの考え方の重要な部分です。アリスターの探求（私の見解では）は、人間には避けられない低規律を前提として、成功するためにできる最小限のプロセスを探すことです。その結果、アリスターはCrystalをエクストリームプログラミングよりも規律を必要としないものと見なしており、より優れた居住性と失敗の可能性の低下と引き換えに効率を下げています。

Crystalの概要にもかかわらず、そのすべての形態の包括的な説明はありません。最もよく説明されているのは、現代的な本の説明があるCrystal Clearです。さらに、Crystalに関する資料や議論のためのwikiもあります。

コンテキスト駆動テスト

当初から、アジャイルコミュニティを牽引してきたのはソフトウェア開発者でした。しかし、ソフトウェア開発には他の多くの人々が関わっており、この新しい動きの影響を受けています。そのようなグループの1つは、ウォーターフォール思考に大きく閉じ込められた世界に住んでいることが多いテスターです。テストの役割は、ソフトウェアが事前に書かれた仕様に適合することを保証することであると述べている一般的なガイドラインでは、アジャイルの世界でのテスターの役割は決して明確ではありません。

結局のところ、テストコミュニティの何人かの人々は、かなり前から主流のテスト思考の多くに疑問を呈していました。これにより、コンテキスト駆動テストとして知られるグループが生まれました。これの最も良い説明は、ソフトウェアテストで学んだ教訓です。このコミュニティはWeb上でも非常に活発です。ブライアン・マリック（アジャイルマニフェストの著者の1人）、ブレット・ペティコード、ジェームズ・バッハ、セム・カナーが主催するサイトを見てください。

リーン開発

数年前、ソフトウェア開発会議でアジャイル手法に関する講演を行い、アジャイルのアイデアと製造におけるリーン運動の類似点について熱心な女性と話したことを覚えています。メアリー・ポッペンディック（と夫のトム）は、特にリーン生産とソフトウェア開発の間の重複とインスピレーションを考察しながら、アジャイルコミュニティの積極的なサポーターになりました。

製造におけるリーン運動は、トヨタ自動車の大野耐一によって先駆的に進められ、しばしばトヨタ生産方式として知られています。リーン生産は、初期のアジャイリストの多くにとってインスピレーションの源でした。特にポッペンディック夫妻は、これらのアイデアがどのように相互作用するかを説明しています。一般的に、私はこのような類推による推論には非常に慎重です。実際、設計と建設の間のエンジニアリングの分離が、そもそも私たちをこの混乱に陥れたのです。しかし、類推は良いアイデアにつながる可能性があり、リーンアイデアはアジャイル運動に多くの有用なアイデアとツールを導入したと思います。

ポッペンディック夫妻の本とウェブサイトは、より多くの情報を得るための明白な出発点です。

（ラショナル）ユニファイドプロセス

オブジェクト指向コミュニティから生まれたもう1つの有名なプロセスは、Rational Unified Process（単にUnified Processと呼ばれることもあります）です。当初のアイデアは、UMLが統一モデリング言語を統一したように、UPがソフトウェアプロセスを統一できるということでした。RUPはアジャイル手法とほぼ同時期に登場したため、両者が互換性があるかどうかについて多くの議論があります。

RUPは非常に多くのプラクティスの集まりであり、実際にはプロセスというよりもプロセスフレームワークです。ソフトウェア開発のための単一のプロセスを提供するのではなく、個々のプロジェクトのためにチームが選択できる共通のプラクティスセットを提供しようとしています。その結果、RUPを使用するチームの最初のステップは、個々のプロセス、またはRUPが言うところの開発ケースを定義することです。

RUPの主要な共通点は、ユースケース駆動型（開発はユーザーに見える機能によって駆動される）、反復的、およびアーキテクチャ中心（プロジェクト全体を通して存続するアーキテクチャを早期に構築することが優先される）であるということです。

RUPに関する私の経験では、その問題は無限の可変性です。私は、「分析イテレーション」を伴う厳格なウォーターフォールから、完璧なアジャイルまで、RUPの使用に関する説明を見てきました。RUPを単一のプロセスとして市場に出したいという人々の願望が、人々がほとんど何でも実行してそれをRUPと呼ぶことができるという結果につながったことが私には衝撃的でした。その結果、RUPは意味のないフレーズになっています。

それにもかかわらず、RUPコミュニティには、アジャイルの考え方に非常によく適合している非常に強力な人々がいます。私は、フィリップ・クルーヒテンとのすべての会議で感銘を受けており、彼の本はRUPの出発点として最適です。クレイグ・ラーマンはまた、OO設計に関する彼の人気のある入門書で、アジャイルスタイルでRUPを使用する説明を開発しました。