アジャイル手法は主流となっていますが、その人気ゆえに問題がないわけではありません。組織のリーダーたちは、期待した効果が得られないと不満を漏らしています。この記事では、アジャイルの考え方を最大限に活用するための熟達モデルを紹介します。熟達度は4つの異なるゾーンに進化し、それぞれに独自のメリット、必要な能力、主要な指標があります。

90年代にエクストリームプログラミングで良い経験をした後、スクラム、クリスタル、DSDMなど、似たようなアプローチに興味を持つようになりました。それらを掘り下げていく中で、これらの新しい方法論の共通の特徴を抽出し、予測型計画よりも適応型計画を優先し、成功においてプロセスよりも人材を重視することを見つけました。時を経て、これらのアプローチはアジャイルソフトウェア開発という旗印の下に集まりました（そして私は記事を改訂しました）が、この記事の視点がアジャイルの本質を理解する良い方法だと今でも考えています。

すべてを始めたわけではないかもしれませんが、この宣言は、運動に名前を与え、最初のエネルギーを与えました。10年後もなお、アジャイル手法の本質をとらえています。

2001年2月、ユタ州スノーバードで17人が集まり、軽量手法の新しいスタイルについて話し合いました。その結果の一つとして、ソフトウェア開発のための新しいアジャイルプロセスの種類を表す「アジャイル」という言葉が作られました。また、これらのアジャイル手法の価値観と原則を記述したアジャイルソフトウェア開発宣言も作成しました。Jim Highsmithと私は、この宣言をさらに説明するために、Software Development誌にこの記事を書きました。

エクストリームプログラミングに短期間関わった多くの人にとって、XPはソフトウェアデザインの死を意味するように見えます。「ビッグアップフロントデザイン」と呼ばれる多くの設計活動は嘲笑され、UML、柔軟なフレームワーク、さらにはパターンなどの設計手法は軽視されたり、完全に無視されたりします。実際、XPは多くの設計を含みますが、確立されたソフトウェアプロセスとは異なる方法で行われます。XPは、進化を現実的な設計戦略にすることを可能にするプラクティスによって、進化型設計の概念を活性化しました。また、シンプルなデザインの方法、リファクタリングによるデザインのクリーンな維持方法、進化型スタイルでのパターンの使用方法などを学ぶ必要があるため、設計者にとって新しい課題とスキルを提供します。

過去10年間、アプリケーションの開発に合わせてデータベース設計を進化させることができるいくつかの技術を開発および改良してきました。これは、アジャイル手法にとって非常に重要な機能です。これらの技術は、データベース開発に継続的インテグレーションと自動化されたリファクタリングを適用し、DBAとアプリケーション開発者の緊密な連携を図ることに基づいています。これらの技術は、本番前システムとリリース済みのシステムの両方で、新規プロジェクトとレガシーシステムの両方で機能します。

表面上、アジャイルソフトウェア開発の世界は明るく、現在は主流となっています。しかし、現実は問題が多く、行われていることの多くは擬似アジャイルであり、アジャイルの価値観と原則を無視しています。私たちが焦点を当てるべき3つの主な課題は、アジャイル産業複合体とそのチームにプロセスを押し付ける習慣との戦い、技術的卓越性の重要性の向上、そして製品（プロジェクトではなく）を中心としたチームの組織化です。問題点にもかかわらず、コミュニティの大きな強みは学習と適応能力であり、当初の宣言の著者たちが想像もしなかった問題に取り組んでいます。

Ryan Lockard（Agile Uprising）は、アジャイルプロジェクトにおけるアーキテクチャに関するポッドキャストの会話にRebecca Wirfs-Brockと私を招いてくれました。Rebeccaは、私がキャリアをスタートしたときに大きな影響を与えた責任駆動型設計を開発しました。私たちは、アーキテクチャの定義、テストがアーキテクチャに及ぼす影響、ドメインモデルの役割、どのようなドキュメントを作成するか、そして事前にどの程度のアーキテクチャを行う必要があるかについて話し合いました。

組織がアジャイルな考え方を取り入れると、エンタープライズアーキテクチャは消えるわけではありませんが、エンタープライズアーキテクトの役割は変化します。エンタープライズアーキテクトはもはや選択を行うのではなく、他者が正しい選択を行うのを支援し、その情報を広めます。エンタープライズアーキテクトは依然としてビジョンを形成する必要がありますが、その後はチーム間の橋渡しを行い、学習コミュニティを構築する必要があります。これにより、チームは新しいアプローチを探求し、互いに学び合うことができ、エンタープライズアーキテクトはその成長のパートナーとなります。

アジャイル宣言を作成してから10年後、私たちはAgile 2011カンファレンスで記念イベントに招待されました。17人の著者の中から15人が参加し、公園のベンチに座ってパネルディスカッションを行い、聴衆からの質問やコメントに答えました。再会できて本当に嬉しかったこと、そして快適なコラボレーションと議論にすぐに復帰できたことに、私たちは皆驚いたと思います。私たちの議論には、宣言作成の背景、過去10年間で私たちが満足したことと不満だったこと、アジャイルの今後の発展、そしてアジャイルとリーンの関係などがありました。

リモートワークとコ・ロケーションワークの単純な二分法はありません。代わりに、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと、それに適した効果的な技術があります。決定的な証拠を見つけることは不可能ですが、私の感覚では、ほとんどのグループはコ・ロケーションで働く方が生産性が高いです。しかし、分散型ワークモデルを使用することで、より幅広い人材プールにアクセスできるため、より生産性の高いチームを構築できます。

これはミュンヘンで開催されたOOP 2014での基調講演の第2部であり、説明するのが難しい講演です。通常、講演の内容を説明するためにタイトルと概要を使いますが、この講演は旅であり、どこに行くのかを伝えるのではなく、一緒に地面を探求したいと考えています。アジャイルソフトウェア開発の採用における私の最大の課題、つまりユーザー、アナリスト、プログラマー間の相互作用の性質から始まります。そして、これらの役割を探求し、プログラマーとユーザーの関係、彼らに対する私たちの責任、そして最後にプログラマーが直面しなければならないと思う2つの大きな課題について質問を投げかけます。

Neal Fordと私は、パリ（2010年）のUSIで、アジャイルが機能する理由（方法ではなく）に関するいくつかの側面について講演を行いました。これは、技術を見るのではなく、アジャイルを効果的にするコアな力のいくつかを探ります。特に、コミュニケーションとフィードバックの役割、そしてそれらがアジャイル環境でどのように相互作用するかを見ていきます。

ソフトウェアは柔軟で変化に開かれているべきだという仮定に基づいた方法が必要な理由。

Agile BrazilでのPaulo Caroliと私とのインタビュー

継続的インテグレーションは、チームの各メンバーが少なくとも毎日、同僚の変更と共に自分の変更をコードベースにマージするソフトウェア開発プラクティスです。これらのインテグレーションのそれぞれは、自動化されたビルド（テストを含む）によって検証され、統合エラーをできるだけ早く検出します。チームは、このアプローチにより、納期遅延のリスクが軽減され、統合の労力が軽減され、新しい機能を迅速に強化するための健全なコードベースを促進するプラクティスが可能になると考えています。

デイリースタンドアップミーティングは、特にアジャイルソフトウェア開発において、多くのチームの一般的な儀式となっています。しかし、効果的なスタンドアップと時間の無駄を区別する多くの微妙な詳細があります。

アジャイル宣言から10年後のSD Timesインタビュー

これは、同僚のダン・ノースと共にQCon 2007で行った基調講演です。私たちは、ソフトウェア開発における最大の課題は、開発者と顧客／ユーザー間のギャップであると考えています。（これを「断絶」と呼ぶこともできますが、その言葉は使い古されています）。この講演では、このギャップ、その重要性、そしてギャップを埋めるために何が必要なのかについて議論しています。特に、従来の仲介役であるビジネスアナリストの役割はフェリーのようなものであり、真に必要なのは開発者と顧客（そしてアナリストはそれを構築・維持する）を直接結びつける橋であると主張しています。この基調講演は私のお気に入りの共同講演の一つです。トピックが非常に重要であること、そしてダンが刺激的な共同講演者であることの両方からです。

2001年2月、17人のソフトウェア専門家がユタ州スノーバードに集まり、かつて軽量メソッドと呼ばれていた分野の成長について議論しました。私たちは、この新しいタイプのアジャイル・メソッドを記述するために「アジャイル」という用語を使用することにしました。また、アジャイルソフトウェア開発宣言を作成し、これらのアジャイルプロセスの価値と原則を定めました。私はこれらの自称の先見者の一人であり、それ以来、このグループの起源とその後のアジャイルアライアンスの設立について多くの質問を受けてきました。これは、これらの出来事に関する私の記憶です。

過去4年間、Thoughtworksはインドのバンガロールにラボを運営し、北米とヨーロッパのソフトウェア開発プロジェクトを支援してきました。従来のオフショア開発のアプローチは計画駆動型の手法に基づいていますが、私たちはアジャイル陣営にしっかりと属しています。ここでは、オフショアアジャイル開発における経験と教訓について説明します。これまでのところ、機能させることは可能であることがわかりましたが、その利点についてはまだ議論の余地があります。（この記事は2006年に最後に更新されましたが、2011年にオフショアワークを訪問し、教訓は依然として関連性があると判断したため、この記事はそれ以上の重要な改訂を必要としませんでした。）

マニフェストにつながる会議のために2001年にスノーバードに行ったとき、ジムは彼が執筆中の本のために私をインタビューしました。これは、エクストリームプログラミングと、数日後にアジャイルソフトウェア開発と名付けたものについての私の考え方のスナップショットを提供しています。

XPやその他のAgile手法の人気が高まるにつれ、10～12人を超えるチームへのXPのスケーリング方法に関する疑問が浮上し始めています。2003年2月中旬、このテーマに特化したワークショップがカナダのアルバータ州バンフで開催されました。この記事では、ケン・シュワバーとマーティン・ファウラーによる基調講演、およびその他の主要な実践者の発表について報告します。

リファクタリングは広く知られた手法となり、ほとんどのソフトウェア開発チームは少なくとも定期的にリファクタリングを行っていると主張しています。しかし、多くのチームは、リファクタリングに使用できるさまざまなワークフローを理解しておらず、そのため、開発活動にリファクタリングを効果的に組み込む機会を逃しています。この資料では、さまざまなワークフローについて探求します。これにより、チームがリファクタリングをより深く作業に統合し、より優れた設計のコードベースを実現し、新機能の追加を迅速かつ容易にすることを期待しています。

ここ10年ほどで、リファクタリングはコードベースの高い内部品質を維持するための広く使用されている手法となっています。しかし、ほとんどのチームは、リファクタリングを使用できるさまざまなワークフローを認識していないため、リファクタリングを十分に活用していません。ミュンヘンで開催されたOOP 2014でのこの基調講演では、Litter-Pickupリファクタリング、Comprehensionリファクタリング、Preparatoryリファクタリングなどのいくつかのワークフローについて探求します。また、リファクタリングの一般的な正当化理由がどのようにして最善の努力を妨げるのかについても思い出させます。（この講演はInfodeckとしても取り扱われています。）

Agile Uprisingポッドキャストは、アジャイル・マニフェストの著者へのインタビューシリーズを実施してきました。これが私のインタビューを受ける番です。スノーバードのワークショップ自体についてはあまり覚えていませんが、マニフェストにつながるコンテキストについて少し説明することができました。

Agile Australiaカンファレンスに出席した最近のオーストラリア旅行からの断片的な印象です。

アジャイル手法の認定プログラムが必要でしょうか？

アジャイルプロジェクトに関する最も一般的な質問の1つは、別のチームへの引き継ぎの方法です。開発チームが離れてサポートチームにサポートを引き継いだ場合、アジャイルプロジェクトは計画駆動型プロセスよりもはるかに少ないドキュメントを生成する傾向があるため、どのように対処するのでしょうか？

アジャイルアライアンスの現執行委員会によると、アジャイル手法は「断絶を乗り越えた」とのことですが、これは普及が進んでいることを意味すると考えられます。これには利点がありますが、問題も引き起こします。方法論や設計アプローチが流行すると、本質的な詳細よりも流行に焦点を当てている多くの人がそれを利用したり、教えたりするようになります。これにより、アジャイルの名で行われたとされることが報告されることがありますが、それらはムーブメントの創設者の原則とは正反対です。

2001年にユタ州スノーバードで開催された会議で、「アジャイル」という用語の使用が決定され、「アジャイルソフトウェア開発宣言」が始まりました。

アジャイルソフトウェア開発を使用することを考えていますが、代わりにリーンソフトウェア開発を使用するべきでしょうか？

先週、オーランドでAgile 2010カンファレンスに出席しました。Agile 20xxは、主要な米国のアジャイル指向カンファレンスであり、そのルーツはXP UniverseとAgile Development Conferenceにまで遡ります。私は主要なアジャイルカンファレンスに定期的に出席しているわけではありませんが、昨年も参加しました。統合された説明を試みるのではなく、いくつかの散らばった印象を紹介します。

C3は、クライスラーの給与計算プロジェクトであるクライスラー包括的補償プロジェクトの略称であり、その後エクストリームプログラミングの「誕生プロジェクト」として有名になりました。

アジャイル手法の共通要素の1つは、ソフトウェア開発におけるプログラミングの中心的役割を高めることです。これは、ソフトウェアエンジニアリングコミュニティが通常行うよりもはるかに大きな役割です。その一部は、コードを主要な、あるいは主要なソフトウェアシステムのドキュメントとして分類することです。

アジャイル手法に関するよくある誤解を紹介します。これは、ユーザーストーリーの作成方法と開発活動を通じてのフローに焦点を当てています。誤解とは、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、それを開発者に実装させることです。これはプロダクトオーナーから開発への流れであり、プロダクトオーナーは行う必要があることを決定し、開発者はそれを実行する方法を決定するという考え方です。

ダニエル・ターホルスト＝ノースによるソフトウェア職人技に関する最近のブログ投稿は、多くのブログ議論を引き起こしました（興味があれば以下に要約します）。そこには多くのことが含まれていますが、彼のテーマの1つは特に私に共感したので、この投稿を書きました。

一流のエンタープライズソフトウェア開発者を構成する要素を検討する場合、会話はフレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力に及ぶことがあります。私にとって、プログラマー、あるいは開発チームにおける最も重要な特性の1つは、顧客との親和性と呼んでいるものです。これは、開発者がソフトウェアが対処しているビジネス上の問題、およびそのビジネスの世界に住む人々に対して持つ関心と近さです。

数年前、クライアントと話していた際、彼がアジャイルアプローチについて気に入らない点を指摘しました。「プロジェクトのこの初期段階で、これほどの困難に直面するのは、気持ちの良いものではありません」と。彼の反応とは反対に、私にとってこの初期の苦痛は、アジャイル、あるいは実際にはあらゆる反復型開発プロセスの大きな利点の一つです。

エクストリームプログラミング（XP）は、主にケント・ベックによって開発されたソフトウェア開発手法です。XPは初期のアジャイル手法の一つであり、実際、スクラムが2000年代以降に主流になるまでは、90年代後半から2000年代前半にかけて最も普及したアジャイル手法でした。多くの人々（私自身も含め）は、XPがアジャイル手法への注目を集める主要な触媒であり、アジャイル開発の出発点としてはスクラムよりも優れていると考えています。

アジャイル手法の一般的な、おそらくは主流のプラクティスとして、開発中のソフトウェアの機能（しばしばストーリーと呼ばれる）のリストを作成することがあります。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールを使用して追跡されます。

多くの人は、アジャイルプロジェクトで固定価格契約はできないと考えています。アジャイルプロセスの本質は将来を予測できないことにあるため、これは不合理な推測ではありません。しかし、これは固定価格のアジャイル契約を結べないという意味ではありません。実際には、固定スコープの契約を結べないということです。

多くの企業は、スコープと価格を固定する契約を締結することに魅力を感じています。それはリスクを軽減すると考えているからです。この幻想は、彼らの財務上の義務が取引価格で固定されていると主張します。満足のいくソフトウェアが得られなくても、費用はかかりません。

最近、いくつかのプロジェクトで耳にした問題があります。それはこうです。

• 彼らはアジャイルプロセスを使用したいと考え、スクラムを選択します。
• 彼らはスクラムのプラクティス、そしておそらく原則も採用します。
• しばらくすると、コードベースが混乱しているために進捗が遅くなります。

私の好きな名言の一つに、「痛ければ、より頻繁に行う」というものがあります。表面上はナンセンスに見える一方で、深く掘り下げると貴重な意味を生み出すという素晴らしい特性を持っています。

平均的な開発者はアジャイル手法を使用できますか？

よくある質問として、大規模なプロジェクトをアジャイル手法で行うことができるかどうかがあります。多くのアジャイルアプローチは小規模なプロジェクト向けに設計されており、彼らが抵抗する重量級のアイデアは、大規模なプロジェクトではより必要とされるからです。

ペアプログラミングに関する一般的な誤解。

多くの人がアジャイル手法について理解するのが難しいことの1つは、アジャイルの人間中心主義です。アジャイルプロセスに関心のある人々は皆、プロセスはプロジェクトの成功に対する二次的な影響であることに同意しています。アジャイル宣言の最初の価値は、「プロセスやツールよりも、個人と対話の価値を高く評価する」ことです。

すべてのアジャイル手法は、システムの開発者と、最終的な受益者である顧客との直接的な相互作用の重要性を強調しています。アジャイル宣言には「ビジネス関係者と開発者は、プロジェクトを通して毎日協力しなければならない」とあり、これは高頻度の相互作用を強調するためにあります。エクストリームプログラミングは、オンサイト顧客というプラクティスを通じてこれを強調しています。

レトロスペクティブのプライムディレクティブは、レトロスペクティブプラクティスの重要な部分であり、ノーム・カースが最初にこのプラクティスを開始して以来、レトロスペクティブ思考の不可欠な部分となっています。最近、Pat Kuaの新しいRetrospective Handbookを読みました。これは、ThoughtworksのテクニカルリードとしてPatが長年培ってきたレトロスペクティブに関する広範な経験に基づいています。Patのプライムディレクティブに対するアドバイスは、反発するものの、彼がほぼ確実に正しいと言わざるを得ません。

私はしばしば、アジャイル手法には厳格な定義がないという不満に遭遇します。不満を訴える人は、これにより、特定のチームがアジャイル手法を使用しているかどうかを判断できないと主張するかもしれません。また、これにより、人々にアジャイル手法の実行方法を教えるのが難しくなるとも言うかもしれません。カリキュラムとは何でしょうか？

ある程度、この不満の痛みを感じますが、治療法がないことを受け入れています。この厳格性の欠如は、アジャイル手法の定義する性質の一部であり、その中核となる哲学の一部です。

n回目、そしておそらく最後ではないでしょうが、私はプラクティスの定義、その一部を「ベスト」とラベル付けすること、そしておそらくCワード（認定）についての話に滑り込もうとしています。それはなじみのある議論であり、まだ始めたばかりですが、どこに向かうのかをかなり予測できます。それは、より優れたソフトウェア開発者を見極め、既存の開発者が能力を向上させる方法を特定したいという、完全に合理的な願望によって推進されています。

自己テストコードとは、リファクタリングで、機能的なソフトウェアと同時に包括的な自動テストを作成するプラクティスを指すために私が使用した名称です。うまく行われた場合、これにより、テストを実行する単一のコマンドを呼び出すことができ、これらのテストによってコードに潜むバグが明らかになると確信できます。

時々、特定の専門分野を漸進的な方法で使用できるかどうかを疑問視する人がいます。「（セキュリティ|ユーザーインターフェースデザイン|データベース|国際化|*）をアジャイルプロジェクトで実行することはできません。なぜなら、この側面は事前に実行する必要があるからです。」

アジャイルプロジェクトでよく見られるのは、開発チームが単一のオープンテームルームに座っていることです。エクストリームプログラミングの初期に提唱され、第2版で主要なプラクティスの一つとして挙げられました。アジャイリストは、オープンテームルームを支持します。それは、チームのメンバー間の非公式で深いコミュニケーションを促進するからです。

時間制限付きイテレーションは、プロジェクトの作業を分割してスケジュールする手法であり、特にアジャイルソフトウェアプロジェクトに関連付けられています。チームは、ソフトウェアの見える機能をユーザーストーリーに分割し、時間を固定期間（例：1週間）に分割します。これはイテレーションと呼ばれます。次に、ストーリーをイテレーションに割り当てることで、ストーリーをスケジュールします。ストーリーはおおよそ見積もられるため、チームは1つのイテレーションにいくつストーリーが収まるかを判断できます。

ユーザーストーリーとは、ソフトウェアシステムの望ましい動作の塊です。計画の目的で大量の機能をより小さな部分に分割するために、アジャイルソフトウェアアプローチで広く使用されています。「機能」と呼ばれる同じ概念も耳にしますが、「ストーリー」または「ユーザーストーリー」という用語は、最近のアジャイル界では一般的になっています。