Doingだけじゃアジャイルにならない？アジャイルになるための継続的デリバリとリーダーシップとは？

カンファレンス二日目に開催されたセッション「Adaptive Leadership: Accelerating Organizational Agility」。発表者は、マニフェスト著名者でもあるJim・Highsmith氏です。このセッションでは、組織レベルでアジリティを高めるための「適用リーダーシップ（Adaptive Leadership）」についての発表で、アジャイル開発へ戦略的に遷移するために必要な要素がたくさん盛り込まれていました。

今回は、エンタープライズアジャイル（Enterprise Agile）について、氏の経験を探検します。

継続的デリバリーに向けての戦略

「継続的デリバリー（Continuous Delivery）」という概念は、今年のAgile Conference Tokyoでマーティン・ファウラー氏のキーノートにも登場しました。Agile 2011では、継続的デリバリーに関して、このセッション以外に4つセッションがあり、関係する書籍も今年発表されているため、今後も注目されるプラクティスになるかもしれません。このセッションでは、このプラクティスを重要視すると共に、より具体的に継続的デリバリーに向けての戦略が共有されました。企業レベルでの価値創造を高め、さらにアジリティをも高めるため、以下のように段階的継続的デリバリーへと向かいます。

まずはイテレーティブな開発の導入
次に継続的統合（CI）の実現
最後に継続的開発へのシフト

継続的デリバリーを実現するには、継続的にデリバリーするためのタイムボックスの設定や、デリバリーに合わせた計画づくり、品質の担保やテストの自動化など、様々な課題をクリアする必要があります。既存のシステムなどの場合は、全ての要素を実現するのにさらに時間がかかるでしょう。そこで段階的に、

イテレーションによるタイムボックスの導入。これにあわせた計画づくり
CIによる品質の担保。手戻りの防止。
これらのプラクティスを基盤として活用し、継続的デリバリーを満たす継続的開発

と、様々なリスクを回避し、継続的デリバリーの実現へと迫ります。

この発表のホワイトペーパーにも書かれているのですが、継続的デリバリー実践者の代表例がFlickrです。Velocity2009というイベントで発表された「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」では、開発と運用のチームプレーから生まれる「DevOps」という概念を元に、アプリからインフラまでを統合的に自動化＆改善し、「1日10回リリース」を実現し、ユーザへと価値を提供しています。code.flickr.comには上記写真のように「先週は580の変更を18人のメンバーで73回デプロイしました。」と掲載されており、「回数＝価値の量」ではないでしょうが、デリバリースピードは実感できます。

「まとめてリリースする場合とどう違うのか？」と思うかもしれませんが、「常にデリバリできる」というのは、サービスにとって大きな強みになります。例えば、リリースした機能の効果測定を見ても、「予想通りうまくいっているか？いないのか？」を瞬時に判断することができ、価値の創出に失敗した場合に「やめる」判断も早くできます。リスクをうまく回避しゴールへ進んでいくアジャイルの特性を生かしています。もちろん、やめた後のリカバリも早いはずです。いくら開発スピードがアジャイルになっても、リリースに時間がかかってしまったり、手作業に寄るリスクを背負っているのでは価値の提供に遅れてしまいます。マーケットスピードが早い現在、継続的デリバリが重要視されるのも納得でしょう。

一見無敵に見える継続的デリバリですが、開発量に比例して問題となってしまう「技術的負債」が存在します。次に、技術的負債とデリバリの関係を見てみましょう。

技術的負債との戦い

継続的デリバリーを目指し、開発スピードが上がると、ソフトウェアのコードはどんどん膨れ上がることになります。うれしい悲鳴かもしれませんが、これに伴い技術的負債（設計上の問題や後回しにした課題などのこと）も大きくなってしまいます。上記図は、技術的負債によるコストの増加率とデリバリスピード・顧客との信頼の関係を表しています。

継続的デリバリーと技術的負債は、コインの裏表のようなものです。徐々にアーキテクチャを侵食し、ソフトウェアが成長すればするほど、修正コスト、リスクへと影響し、その結果、デリバリーのスピードも落ち、顧客の信頼も揺らいでしまいます。この問題を解決するためには、「リファクタリング」「継続的デザイン」など、あらゆる継続的な改善活動が重要になってきます。

こういった改善活動の中心になるリーダは、どのようなスキルセットやマインドを持つ必要があるのでしょうか？次に、アジャイルな組織を加速するためのリーダーシップについてみていきましょう。

「アジャイルをやる」と「アジャイルになる」の違い

今回紹介された継続的デリバリーのように、組織レベルでアジリティを高めるためにはどのようなリーダーシップが必要になるのでしょうか？その答えとして氏は、「適用リーダシップ（Adaptive Leadership）」を例にあげ、その核となる要素を紹介しています。

まずは、アジャイルをやるためのキーワードです（Doing Agile）。

「Speed-to-Value」の「Speed」は、マーケットスピードの速さを考えると、半年の計画すら長いということです。マーケットに反射的に動くために、イテレーションの考え方は必須となります。次の、「Value」は、「使われないものを作らない」という価値にシフトした考え方です。リーンの考え方から見ると「よくわからないことは後で考える（判断を限界まで伸ばす）」に似ている気がします。「Quality（品質）」はいうまでもなく、下げていいことがないので、維持する必要性があり、「Do Less」も「Value」に近い考え方で、大きなストーリーをやるのではなく、小さくちょっとずつ開発・リリースし、大きな変化の中の小さな変化という位置づけで、継続的にデリバリしたほうがいいということを指します。「Engage & Inspire」は、関係者を巻き込んで企業レベルでアジリティを上げるため、ゴールを達成するために、周りを刺激し、そのプロセスの中で効果的に約束を果たすという、リーダーとして大切なタスクの一つのことを指します。

これらのキーワードが指し示す「やりかた」は、プラクティスやプロセスで補完することが可能です。そのためのプラクティスやプロセスとも言えるかもしれません。アジャイルを始める上で「まずプラクティスをやってみよう」という場合は、「アジャイルをやってみる」形であると言えます。しかし、これだけではアジャイルになるとは限りません。

次に「アジャイルになる」ためのキーワードを確認しましょう（Being Agile）。

「Adapting」はその名の通り、適用すること。変化は必然であるので、従来のやり方しか知らないでは通用しない時代になりました。変化に適用し、改善することが重要です。「Exploring」は、適用と似ていますが、やり方を実験し、PDCAサイクルのように改善のループに乗せること。Agile2011でTPSについて発表された黒岩さん（セッションレポートはこちら）がおっしゃるには、「TPSを体にし見つけるまで３年ぐらいかかる」ということです。改善のサイクルを生み出し、その本質を理解するには時間がかかりますが、これも大切な活動の一つです。「Facilitating」は、自己組織化されたチームを育成するために、コマンドコントロール型ではなく、自走をうながすファシリテーションをすること。私の最近の仕事はファシリテーションが多いのですが、育成はほんとうに難しいと実感しています。「Riding Paradox」は適用リーダシップのパラドックスのこと。「これをやれば大丈夫」といった「銀の弾丸」は存在しないため、全てを「方法やツールでしかない」と考え、自分自身のコンテキストにあわせて適用するしかないということでしょう。

これらを実践することで、アジャイルの価値や原則に近づくことができ、それらをより意識せざるを得ません。これらを実践し守り切ることで、ようやく「アジャイルになる」ことができるのでしょう。

アジャイルになるためのアクション

現在は、エンタープライズアジャイルといっても、まだ先の事のように感じるかもしれません。しかし、Agile Conferenceでは、毎年大規模な事例が登場しており、氏は「近い将来もさらに事例も増えてくるだろう」と予測します。氏は、エンタープライズアジャイルに直面したときに役立つ５つのポイントを以下のように紹介しています。

自分のビジネスについて徹底的に理解すること
自分自身やチームの適用リーダシップの性能を評価すること
まずアジャイルをやってみる。そして、3ヶ月後、6ヶ月後、1年後でどうなっていたいかを考えること
自分の組織にとって、アジャイル適用のために最も重要なことを決定する。そして、3ヶ月後、6ヶ月後、1年後でどう達成するかを考える
そして、何よりもアジャイルを楽しむこと

将来のことは誰にも予想ができないかもしれませんが、Agile 2011 Conferenceに参加していると、アジャイル開発の広がりの速さを実感します。これからも様々な事例が発表され、日本でもメインストリームへと進んでいく可能性があります。上記5つのポイントは、「その時に考えればいい」ではもう遅いかもしれません。

セッションを終えて

氏はさすがにThoughtWorksのChief Agile Strategistだけあって、企業レベルでのアジャイル導入や、これからの展望など、氏の経験が多く語られたとても興味深いセッションのでした。このセッションは、Enterprise Agileステージでの発表でしたが、アジャイルの導入を考えているケースや、「Being Agile」になりきれないケースでも役立つ内容だと思います。

これは想像になりますが、アジャイルに興味のあるエンジニアは「アジャイルをやる」は経験したことがあるのではないでしょうか？しかし、継続的統合や、今回の継続的デリバリーといった、ヘビーなプラクティスを乗り切ることができず、アジャイルの導入に失敗するケースも多々あると聞きます。さらに、組織や文化の壁、リーダー不在、原則の理解不足などなど、ただでさえ勇気や覚悟のいるアジャイル開発は、そこにたどり着くまでが大変です。

導入した時点ではまだ「Doing Agile」です。企業レベルでなくとも、「Being Agile」になるためには、チームや組織を導くリーダーシップが必須となります。