『パターン指向リファクタリング入門』の著者である Joshua Kerievsky が昨年の Agile 2016 の基調講演で発表した、「モダンアジャイル」というコンセプトがあります。
InfoQ で紹介されていたり、
永和システムマネジメントの平鍋さんがまとめ記事を書かれたりしています。
Modern Agile JPanagileway.wordpress.com
モダンアジャイルに対するざっくりした理解
Agile 2016 の基調講演については、transcript 付き(ありがたい!)で全編のビデオが公開されています。
これを通して見たので、記憶が新しいうちに、「モダンアジャイル」がどのようなものか、現時点での僕なりの理解をごくざっくりとまとめてみます。
モダンアジャイルの 4 つの指導原則
まず、全体像です。
モダンアジャイルは、上の図に示された 4 つの指導原則(guiding principles)によって定義されます。
これで全部です。
とても簡潔で、シンプルです。
あえてプロセスを定めない
モダンアジャイルでは、4 つの原則が掲げられている一方で、具体的なプラクティスは一切定められていません。
公式トップページで Joshua Kerievsky の発言として引用されてもいるように、「framework free」です。
Joshua は、スクラムに代表される従来のアジャイルメソッドを、「補助輪だ」と言います。
そして、彼の娘が自転車に乗れるようになった過程を引き合いに、補助輪を使っていると、なかなかうまくならない、と主張します。
彼の娘は、補助輪を外して、「ペダルを漕がずに、まずバランスを取る」ことから始めて、たったの一日で自転車に乗れるようになった。
さて、いきなりですが、これが何を意味するのか、よく理解できていません。
定められたアジャイルメソッド(たとえばスクラム)が、一種の補助輪だ、というのは同意できます。
アジャイルメソッドを使うことによって、アジャイルになることを始めることができます。
あまりにもうまく始められるので、びっくりしてしまうほどです。
そのことは、先日記事にも書きました。
さて、アジャイルメソッドが補助輪だとして、はじめからそれを使わないほうがいい、というのがどういうことかがわかりません。
今はスクラムを使っていますが、いずれ、(そのままの形では)使わなくなっていくのかも、という気はしています。
補助輪から始めて、徐々に本物に近づいていけばいいじゃないか、と思います。
ところが、Joshua は、そもそも補助輪は必要ない、と言います。
補助輪なしで指導できる優秀なコーチがいればいい、ということでしょうか……。(Joshua の娘の場合は、それが Joshua でした)
「ソフトウェア」ではなく「結果」にフォーカスする
アジャイルマニフェストは、その日本語訳が「アジャイルソフトウェア開発宣言」であることからもわかるように、よりよい「ソフトウェア開発」の方法を求めて定められたものでした。
一方、モダンアジャイルは、「結果」にフォーカスすると言います。
これを、僕は「枠を広げて考えよう」ということだと理解します。
「よいソフトウェアを作ろう」とすれば、よいソフトウェアができるでしょう。
しかし、ソフトウェアは作られることがゴールではありません。
ソフトウェアは使われるために作られるのであり、もともとそのソフトウェアで実現したいことがあったはずです。
そして、それはもしかしたら、そもそもソフトウェアで実現する必要のないことかもしれません。
それに、よいソフトウェアができても、ユーザが使うに至らなければ意味がありません。
存在に気づいてもらえなければ。買ってもらえなければ。使ってもらえなければ。せっかく入れた機能に気づいてもらえなければ。必要なときに間に合わなければ。
最高の開発者と最高の開発プロセスで、完璧に構築されたそのソフトウェアの価値はゼロです。
アジャイルとは「作らない」ことだ、とも言われるように、この考え方自体はもともとアジャイルマニフェストにも根付いているものですが、それをより推し進めたのがモダンアジャイルだと言えると思います。
「ユーザを喜ばせる」だけでは足りない
さて、4 つある原則のうちの 1 つめは、「人々を最高に輝かせる(Make People Awesome)」です。
これは、先ほど書いた「ソフトウェアではなく、結果(ユーザの満足)にフォーカスする」ということももちろんですが、それだけではありません。
モダンアジャイルでは、ユーザはもちろんのこと、開発者をはじめとした同僚(営業、マーケティング、……)、見込み顧客、購入の決裁者(えらい人)、などなど、ソフトウェアを取り巻くエコシステムのすべての「人々」を対象として考えます。
Done の定義でも、ベロシティでもなく、それどころか「顧客満足度」でさえなく、「人々を輝かせる」ことにフォーカスすることが本物の成功を導く、という考え方です。
論理的に説明するのはなかなか難しいものの、この考え方には個人的にとても共感できます。
「必須条件」としての安全
2 つめの原則は、「安全を必須条件にする(Make Safety a Prerequisite)」。
「心理的安全」については、昨年あたりからソフトウェア業界で頻繁に耳にするようになりました。
なので、「ここでも、出てくるか」という感覚です。
もしかしたら、この Agile 2016 の基調講演自体も流行のきっかけの一つだったのかもしれません。
心理的安全はさまざまなところで話題になっており、『チームが機能するとはどういうことか』をはじめとして書籍でも大きく取り上げられるような考え方なので、目新しいことはありません。
個人的にも、こうして数少ない 4 つの原則のうちの 1 つとして取り上げられることに、一定の納得感があります。
「必須条件」という言い方はさすがに伊達ではなくて、講演では、従業員の心理的安全、および顧客の心理的安全について、さまざまな角度からその重要性を強調しています。
Slack が、有料契約をしているのに未使用になっているユーザを見つけたら自動的に返金してくれる、という例には感心しました。
顧客の心理的安全。そうあるべきだ、そうありたい、と感じます。
これでもかというくらい失敗する
3 つめの原則は、「高速に実験&学習する(Experiment & Learn Rapidly)」。
これは、少し想像すればすぐにわかるように、「安全」と密接な関係があります。
「安全」が「必須条件」として確保されていれば、実験し、失敗し、学習することができます。
Joshua は、失敗しよう、と言っています。本気で。
たとえば、IMVU の例。
3D のシミュレーションゲーム(the Sims みたいなもの)をリリースするにあたって、「移動する」機能をつけずに出してしまう。
するとユーザから「移動したい」という要望が出る。
ならば、ということで、「クリックするとその場所にアバターが(瞬間)移動する」という機能をリリースする。2 日で。
the Sims みたいに「ちゃんと」移動する機能じゃなくて、アバターの位置がひょいと変わるだけの機能なら、2 日でリリースできるわけです。
そしてその「瞬間移動」が大人気になった、というストーリーです。
たまたまじゃないか、という気もしますが、「高速にリリースする」ことがいかに価値を生み出しうるか、ということを、僕はこの例で強烈に感じました。
あるいは、Amazon.com の CEO である Jeff Bezos の例。
Fire Phone は大失敗に終わったわけですが、そのことについてインタビューされた Jeff は、「すぐにもっとずっと大きな失敗をするよ」「失敗が起こることなんてわかっている。むしろ、Amazon が失敗できる場所であることが誇りだ」と(たぶん笑顔で)答えます。
これが強がりではないことは、Amazon の大躍進を見ていればわかります。
モダンアジャイルでは、短期的な成否にとらわれず、長期的に考えて、「積極的に失敗する」ことの価値を強調しています。
届いた価値だけが価値だ
最後の原則は、「継続的に価値を届ける(Deliver Value Continuously)」。
これもフレーズだけ聞けば「そらそうよね」と感じますが、たった 4 つの原則のうちの 1 つであるからには、これこそが極めて重要、ということになります。
たとえば、より多くの機能を開発することよりも。
あるいは、開発計画を予測可能にすることよりも重要かもしれません。
機能の多さや、中長期の見通しを犠牲にしてでも、継続的に価値を届けよ、と言っているのだと理解しています。
なぜかといえば、届けない限りは、それが価値かどうかもわからないからです。
最先端の技術と残業も辞さない努力で、丁寧に開発され、入念にテストされ、(幸運にも)出荷され、さっぱり使われない機能のいかに多いことか。
おわりに
「モダンアジャイル」について、Agile 2016 の基調講演のビデオを見た現時点での僕なりの理解を書いてみました。
あくまでも、これは一個人のざっくりした理解です。
「これがモダンアジャイルだ」というつもりはないので、ご了承ください。
「そうではなく、こういうことでは?」というツッコミは大歓迎です。
何かあれば、コメントでも、ブコメでも、ツイッターでも、ぜひ、お寄せください。
いずれにせよ、このモダンアジャイルというコンセプトをきっかけに、これからのソフトウェア開発(および、価値を生み出す集団の活動すべて!)をよりよくする方法について、議論が深まっていくといいなと思っています。