(この記事は 「 アジャイルの破綻―原因、そして新たな提案 」の続編にあたる記事です。)

前回のブログで、私はアジャイルの変動について、 「調査と順応の概念は一体どこへいってしまったのか」、「近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しよう、という考えはどうなってしまったのだろう」 、と問いかけました。

VersionONEによるアジャイル開発の2014年アンケートによると、アンケートに答えた56％のチームがスクラム、10%ほどがスクラムとXPの併用、8%がアジャイル手法の混合（XP, かんばん, リーンなど）を使っていることがわかりました。私からすると、アンケートに答えた18%は だいたい 正しいことをしているように見えます。他は、もしかしたら、いつもしている単なる朝礼をアジャイルと呼んでいるかもしれません。

それは少し言い過ぎたかもしれませんが、同アンケートの別の設問によると、継続的なデプロイを行っているのはたった26％のチームだけに留まっています。私が思うに、これこそが実態を物語るデータではないでしょうか。ひとつの手として、”継続的インテグレーション”と称してビルドマシンをバックグラウンドで稼働させておくということもできますが、次のステップにいくためには、実際に本当にあなたが何をしているかを理解し、継続的なデプロイに備える必要があります。それれこそが、本当に有効なアジャイルチームであることを証明することだと思います。あなたが一貫して正確且つ自動的にソフトウェアを生産できなければ、いくらデザインがステキで顧客のニーズを理解していたとしても、意味がなくなってしまうのです。

そして8％のチームを見てください。私は彼らが本当に有効で、変化を利用できるチームなのではないかと考えます。彼らは、あるプラクティスが標準的なスクラムかXPかリーンなのかなどについて騒いだりせず、自分達で混合したり、調和させて一番使いやすいものを使っています。これがアジャイルであるということで、これは単に型にはまったスクラムやXPのプラクティスを使って成し遂げられることではないのです。

問題点は、アジャイルは必要に応じてあなたに調査と順応をさせますが、どのアジャイル手法もそのことを最上のポリシーとして提示してくれないことにあると思います。新しいプラクティスを生み出すことを目的としたスクラムのプラクティスはありませんし、エクストリーム・プログラミングでも同じことが言えます。Dave Thomasは「真のアジャイル熟練者は下記のような人だ」と このブログ で上手く指摘しています。

• 自分がどこにいるかがわかっている人
• 少しずつ自分のゴールに向かって進む人
• 学んだことによって考えを調整していく人
• 繰り返す人

わかりやすいですが、実際に実行することはとても難しいです。運転の教本（アジャイルの本）を読んで、免許（それか変な証明書）が取れたとしても、F1レースやル・マン24時間レースや、マンハッタンのラッシュに挑戦できるわけではないのです。これがJaredが このブログ で指摘した、アジャイルにおける順応の大きな問題です。

だから私は一つの実験をしてみたいのです。それは、 「実験」 という行為を至上命題とするとし新たな手法を提案することです。順応からはじまり、最後には一人一人固有で特定の展開に終わります。あなたは、この実験の実際のコンディションによって出てきた実際の結果に導かれます。(初心者は具体的で明確なステップ/チェックリストから始めて、スキルが上がっていくにつれてステップ/リストから離れていくようにしましょう)

他の誰かがどこかで使えたであろうものに頼ってばかりいるのではなく、あなたにとって適切な環境で調査や順応していくことができます。

この実験を使うことで、もう一度自分の思い通りにできます。それがどのような仕組みなのかみていきましょう。

参加する

一般的に人々は変わることを嫌がります。かえてほしいと思うのはオムツ替え待ちの赤ちゃんぐらいで、それでも泣いたり叫んだりします。なので本当は、誰も変化を望んでいません。

人々がほしいものは新しくて、ちがう結果です。できれば無料で、なるべく著しく変化しないものです。でもほとんどの場合、みんなは 変わる こと自体を好みません。少しでも成功するためには、本心から変化を望まないといけません。「電球を換えるためには、電球自身が変わりたいと望まないといけない」という古いジョークのように。

よって人々にとってとてもカスタマイズされていて、良いことずくめに見えないといけません。”より高品質なコード”や”市場に投入するのにかかる時間を短縮する”などの抽象的な概念では人々は動じません。デベロッパーとしてなら、自分への直接的な利益とは無関係なので、私はたぶんこういう問題を気にしません。カスタマーサポートの代表としてなら、自分に影響するコード品質にもっと関心を持つかもしれません。セールスの副責任者としてなら、市場に投入するまでの時間は重要で、コードの質には見向きもしないでしょう。私のような、何か違ったことを必要とするような新しいアプローチに賛成する立場としては、はっきりとどのように自分に利益をもたらしてくれるのかを理解しないといけません。そこでやっと、もしかしたら、あなたが言っている新しくてとっぴなことに挑戦するかもしれません。

GROWSのより良い導入方法は以下のようなものです。

まず、すべてはあなたの能力のレベルによって調整されます。ここで導入方法について話している通り、皆GROWS初心者であり、まだ経験がありません。初心者として、いくつか試してみたいプラクティスや、GROWSで推奨されるプラクティスがあります。

GROWSでは、実験を行うことでプラクティスを採用していきます。一つ一つのプラクティスがそれぞれの実験と対になっていて、これらが実験の状態を見極めたり、フィードバックや評価をする際に役立ちます。初心者にとって、フィードバックや評価は非常に具体的で明確なものであり、判断する必要はありません。その部分は後ほど。

実験は固定時間で区切られるため、コミットメントとリスクは限定的なものになります。そのため、これは永久的で自由で、より形のない”変化”とは違います。全てを含んだ上でも、あなたがこのプラクティスをまだ採用しないということや努力をしないということはとても明確です。ちょっとやってみるだけです。

皆がこの実験と結果の評価に参加するようにして、卵をケーキミックスに加えるような参加のチャンスを皆に与えます。（Betty Crockerは最初、ミックスに水を足すだけで作れるようなケーキミックスを作りましたが、これは失敗でした。そこで、彼女達はミックスのレシピを変え、新鮮な卵と水をいれるようにすることで、もう一度消費者に料理をしているような気分にさせました。そして、成功しました。どれ程参加しているかで、結果が変わるのです！）

フィードバックを使うことを学ぶ

採用の初期段階でのお勧めのプラクティスは、実践的に健全で、安全な方向へと関連付けられているものです。物議をかもしたり、抽象的だったり、遅れた満足感を頼りにするものではありません。これらの最初のプラクティスは最も即時的で、使いやすく、大部分がアイディアを紹介するために役立つので、時間を費やす前に何かに挑戦したり、ビルドしたり、安心して展開することができます。この方法は、思い通りにプラクティスを採用し、それらを修正したり拒否できる基本となる環境を成立させ、さらに積極的にそうさせます。（それと、ご想像の通り、お勧めのプラクティスはチームと組織の能力が上がって伸びていくにつれて変わっていきます。固定的ではないのです。）

私たちは人々に教える手助けをして、短いフィードバックループを使ってフィードバックに基づいて予測したり、実行するという考え方に慣れていってほしいのです。ですが、これはまだ簡単な方です。

難しいのはフィードバックを評価する方です。このような初期段階ではGROWSは具体的で明確なフィードバックを見るように明示します。のちに、能力が上がってくると、このプロセスはもっとおもしろくなっていき、難しくなっていきます。ですが、その頃にはチームと他の参加者は信頼を築けていて、お馴染みのやり方でフィードバックを探したり適用したりしています。そうすることで、より難しい問題がでてきても、簡単に力を合わせることができます。

これは実験です

GROWSの考え方は、これ自体が実験です。そのため、どんな特定のコンテクストにも使えない考え方もあるかもしれません。しかしまた、実はそれこそが核心なのです。私たちはこれらのいくつかに挑戦してきて、これからもどんどん挑戦していきます。そして、これからメソッド自体、プラクティス、実験についてより多くの情報を発表していきます。

現在フィードバックを集めたり、結果を評価したり、調整したりしています。よろしければ、growsmethod.comからご参加ください。

“行動に際して、あまりに臆病になったり神経質になることがないように。すべての人生が実験なのだ。実験すればするほどうまくいく。”
―ラルフ・ワルド・エマーソン

（このシリーズの前編は “アジャイルの破綻” をご覧ください。）