2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。

あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。

更にひどいのは、アジャイル開発手法そのものがアジャイルではなくなってきているということです。全く皮肉な話です。

どうしてこのような事態になってしまったのでしょう？

ルールという喜び

アジャイル的アプローチの原則は、変化を受け入れることです。開発中の製品、ユーザの要望や希望、環境、競合他社、市場、技術といった変化に意識を向けることです。これら全ては、不安定な変化の源になり得ます。変化の流れを受け入れるために、アジャイル開発手法は私たちに”調査と順応”を推奨しています。つまり、手法の変更やコードのリファクタリング、顧客と協調することなどによって何が変化したかを見極め、その変化に対して順応していくのです。

しかし、アジャイル開発手法を採用するほとんどの人が、これを実践できないでいます。そこには、正当な理由があります。

あなたが新しいプログラミング言語や技術、または開発手法などの新しいスキルを初めて学ぼうとする時、経験やメンタルモデル、”調査と順応”といった抽象概念に対応する能力を持ち合わせていません。これらの能力は、より経験を重ねた熟練者だけが持ち合わせているものです（詳しくは、私の記事 Why Johnny Can’t be Agile をご覧ください）。

初心者がこれに対応する唯一の方法は、コンテキストのない簡単なルールに従うことです。例えば、「 これ が起こったら、 あれ をする」といったようなルールです。ご丁寧なことに、アジャイル開発手法には初心者用にいくつかの具体的なプラクティスが提供されているため、初めてアジャイルを取り入れるチームは、これら全てもしくは一部に固執してしまい、凝り固まったやり方になってしまいます。

彼らは、アジャイルの原則やアジャイル宣言の概要を尊重することなく、鉄則となっているプラクティスを入手するだけで、それ以上何もしないのです。

アジャイル開発手法は、熟練者に 考える ことを求めます。はっきり言って、これは押し付けです。与えられたルールに従い、「規則どおりにやっている」と言えた方がずっと楽ですね。その方が簡単ですし、間違ったことをして笑われたり非難されたりすることも、クビになる心配だってありません。私たちはルールという窮屈な制限を公然と非難しますが、そこには安全と快適さが存在するのです。しかし当然ながら、アジャイルな、つまり効果的な開発は、快適さとは別物です（私の記事、 Uncomfortable with Agile をご覧ください）。

従いやすい一握りのルールだけを選んで難しいものは無視すれば、間違いなくうまくいくでしょう。誰かに何か言われたら、「アジャイル開発をしているんだ」と言って、ほとんど役に立たないルールの中からごく一部だけを実行することに力を注げばよいのです。そうすれば、みんなもっと快適に感じるようになるでしょう。実際に何かを送り出す時までは、それでいけます。

型にはまったやり方

厳密なルールに従っていると、初心者程度のパフォーマンスしか出せなくなってしまいます（詳しくは私の著書、 Pragmatic Thinking & Learning: Refactor your Wetware （訳注：日本語版『リファクタリング・ウェットウェア　―達人プログラマーの思考法と学習法』）をご覧ください）。そして自分たちのチームが知らないうちに型にはまったやり方をしていたのだと気づくでしょう。ただやみくもに凝り固まったルールに従っていて、ルールを打ち破ることの必要性に気づくだけの経験を積むことができていなかったのだと。

最近Twitterやメーリングリストでは、ルールに従うことこそ全てと信じているような人たちが、自分の満足いくようにルールに従わない相手に対して「あなたはアジャイルじゃない」と主張しているのを当たり前のように目にするようになりました。

調査と順応の概念は一体どこへいってしまったのでしょう。近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しようという考えは、どうなってしまったのでしょう。よく用いられる正統派なアジャイル開発手法は、本質的には10年以上何も変わっていません。私たちは型にはまってしまっているのです。

まさに私の好きな格言のとおり、決まりきった型と墓穴の違いは、その大きさだけです。

前進への道

これまで多くの人がアジャイルムーブメントについて不満を呈してきました。ある人は静かに、ある人は声を大にして。その内容はどれも目新しいものではありませんでした。そこで今、新たな試みとして、この状況を解決しましょう。今この場で、一緒にやるのです。アジャイルの採用と発展につきまとう本質的な問題を解決し、この業界の前進に一役買おうではありませんか。

そのためには、まず名前が必要です。通常、良いアイデアを寄せ集めただけでは、世界をリードできるほどの力は得られません。新たな概念を掲げる際は、名前やブランドが不可欠です。そこで私は、以下の名前をつけました。

GROWS™メソッドです。

GROWSはGRowing Real-World Oriented Working Systems（成長を続ける実世界指向の作業システム）の頭字語で、このアイデアはJared Richardsonと私（Andy Hunt）が練り上げたものです。

GROWS™メソッドにおける重要な概念は、ソフトウェアは設計・構築されるものではないということでしょう。つまり極端に決定論的で、プロセスの流れが直線的なモデルは役に立たないということです。Growingという表現ですが、成長（Growth）は変化を生むため、これはピッタリな隠喩だと言えます。また実世界指向（Real-world）というのは、全ての決断と指示は実証に基づくべきだとする考え方です。ここで言う実証とは、実際の何かしらの状況下で実世界から得られる反応を指します。それ以外は全て、空想や希望的観測などの不適切な組み合わせに過ぎません。当たり前のことですが、最終的な成果物は正しく動作するソフトウェアです。しかし、そのために正常に機能している チーム や組織全体を犠牲にしてはいけません。なぜならソフトウェアだけでなく、チームやユーザ、スポンサーまで含めて1つのシステムだからです。全ての関係者にとって、システム全体が問題なく機能していることを確認する必要があるのです。

私たちの”新たな”メソッドは、以下の4つの基本的な考え方に基づいています。

1. 実証ベースであること
2. Dreyfusの技能習得モデルに従うこと
3. 置かれた状況に順応すること
4. 包括的であること

つまり全てのチームに、実証や実世界の反応に基づいて調査・順応する能力が求められます。そこで必要になるのが、Dreyfusの技能習得モデルです。このモデルは、初心者にはサポートを、熟練者には裁量を与えます。こうした枠組みを整えることで、全てのチームが実証に基づいて安全に、そして置かれた状況に順応できるようになります。最後になりますが、私たちの最終的な目標は、 システム全体 を意識して作業するということです。開発者やマネージャ、テスター、ユーザ、スポンサーなど特定の人たちのことだけを考えてはいけません。”私たち”対”彼ら”の構図ではなく、皆が”私たち”なのです。

次回の記事では上記の基本的な概念ついて、それぞれ詳しく見ていきます。

この記事の内容に興味がありましたら、 growsmethod.com から、ぜひ私たちのメーリングリストに登録してください。

みんなで力を合わせれば、この状況を改善できます。

Andy Hunt

この記事のパート2はこちらです。 それは実験 ― 形骸化した「アジャイル」を再考する新手法”GROWS”について