はじめに
ここ数年でアジャイル、アジャイルという言葉をよく耳にするようになりました。
ソフトウェア工学的な意味で、"agile※1"開発を行うための開発手法（フレームワーク）の総称です。
今までのウォーターフォール型では、「最初に要件を決めて」、「開発期間を定めて」、「実装する」...という流れがあります。
しかし、これでは開発後期に発生したバグへの対応や、仕様追加と言った"変化"に対応することは難しいです。
ではどうするか、というところから生まれたのがこのアジャイル、と言うものです。
アジャイル型開発では、期間を短く区切って、この期間ごとに「実装」「設計」「テスト」を繰り返していき、徐々にユーザーストーリー※2に合わせて機能を追加していくようなイメージです。
個人的見解としてはスパイラルモデルのように、反復することに重きを置くものなのかな、と解釈しています。
ここではアジャイルがどういったものなのか、どうすれば取り入れられるのかといった具体的なお話はしないつもりです。
その辺の詳しいお話が知りたい方は、IPAがリファレンスガイドを出してるのでそちらあたりをご参考にされてください。
※1：agile...
俊敏な、素早い などの意味。
※2：ユーザーストーリー...
ユーザーがやりたいこと、やろうとすることから機能を洗い出していき、作られたもの。このユーザーストーリーをベースに見積もりを行っていく。
アジャイルソフトウェア開発宣言
というところで、2001年に宣言された「アジャイルソフトウェア開発宣言」をご紹介いたします。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
© 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
アジャイルの失敗
さて、こうして聞くとアジャイル開発はまるで魔法のような開発手法であり、これに切り替えるだけで今までの煩わしいあらゆる物事から解放されるような気になりますが、実際そんなことはありません。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
この辺だけ抜き取られていいように解釈された結果は...想像に難くないと思います。
ドキュメントなくても動けばいいんでしょ！変化に対応するなら計画立てなくていいよね！って。
だからこそ、
この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
ってことなんでしょうね。
とにかく、バカのひとつ覚えみたいにアジャイルアジャイル言っているうちは何も変わらないってことです。昔の自分よ、聞いているか。
ModernAgileの出現
そこで、Joshua Kerevsky氏が、Agile Japan 2017において「モダンアジャイル」というコンセプトを提言しました。
正直、自分の中でも咀嚼できてない部分があるので、「何言ってんだこいつ」的なところはあるかもしれませんが、個人的に思ったところをまとめていきます。
4つの原則
1.人々を最高に輝かせる
2.継続的に価値を届ける
3.高速に実験＆学習する
4.安全を必須条件にする
自転車とアジャイル
さて、モダンアジャイルを提唱した基調講演の中で、Joshua氏はいきなり、「自転車と補助輪」について話し出します。
「自分の娘に自転車を買ってあげたんだけど、補助輪付きで練習させても全然上達しないんだ。でも、かえって補助輪を外したほうが早く乗れるようになったんだよねHAHAHA」的なお話なんですが、この考え方が既にモダンアジャイルなんですよね。
ここで言う「自転車」がアジャイル型開発であることは自明の理なんですが、じゃあ補助輪ってなんでしょうか？
そうです、今までの先人方が築き上げてきたアジャイルプラクティス、いわゆる「アジャイル型開発を成功させるにはこういう取り組みをすればいいよ」的な部分そのものに他なりません。
それを初めからそもそも使う必要がないっていうのは...どういうことなんでしょうか。
確かに、型に囚われるあまり本質を見失う、なんてことはよくある話ですが。
そういった仕組みをチーム内で話し合って作り上げていくこと自体が既にモダンアジャイル、ということでしょうか。
OutputよりOutcome
そしてモダンアジャイルの核となる（と個人的には思っている）部分がこちらです。
たしかに今までのアジャイルでも、「よいソフトウェアはみんなをハッピーにする」的なことは言われてました。
ですが、人々が幸せになることは一つの「結果」です。じゃあどうすれば幸せになれるのか？
それは「成果」を通して実感することができます。
Joshua氏はこんな具体例を話していました。
「とあるレストランでケーキを作ったんだけど、シェフの手が滑ってぐちゃぐちゃに崩れちゃったんだよね。落としたシェフは顔面蒼白、作り直す時間もない。そこで上司の登場だ。もうダメだ、そう思った彼に、上司はこう言ったんだ。『じゃあいっそ割れたケーキとしてしたらウケるんじゃね？』って。結果？今ではそのメニューが一番の看板メニューさHAHAHA」
この話はOutcomeだけでなく、安全性なんかにも絡みついてくるのですが。
ちなみに引用している画像がその人気のケーキらしいです。お皿まで特注で作らせるという懲りよう。うーん
このOutputは「割れたケーキ」ですが、ではそのOutcomeは？
お客さんは待つことなく、一風変わった美味しいケーキが食べられました。
失敗したと思っていたシェフは、むしろその失敗を成功に変えました。
上司はスタッフ全員から尊敬され、飲み会のたびに讃えられることでしょう。
お店は一人の失敗から看板メニューを作り出すことができて、知名度が上がりました。
これです。これこそがモダンアジャイルの考え方なのです。って断言すると怒られそうなので、あくまでも一個人の解釈ということで。
ANZENEERINGと言う価値
Joshua氏、日本語の「安全」という言葉が好きすぎるあまり、「ANZENEERING」という造語を作ってしまいます。氏いわく、「ANZENって言葉はすごくセクシーだね。」とのことですが、こっちに言わせればそんな造語を作っちゃうほうがよっぽどセクシーです。
さて、安全という言葉を聞くと皆さんは何を想像されるでしょうか？
バグの少なさ？安定したプログラム？定期的に保守・リファクタリングが繰り返され、手入れの行き届いたソースコード？
おそらく思い描いたどれもが間違いではありません。正解です。
では、一歩大きな視野から開発の現場を見てみましょう。そう、いわゆる「心理的安全」と呼ばれるものです。
例えば振り返り中に記名投票を行ったとします。当然、正直ベースでの振り返りなのでいいところも悪いところも話すことでしょう。チーム内では。
さて、その結果を上司が見、その結果査定に響くとなれば、どうなるでしょうか。この職場は果たして、「安全」でしょうか。
では逆に、コードレビューをするときにレビュー内容を隠蔽したとします。
レビューする側からすると、「安全」ですね。では、される側は？悪く言えば、レビューする側は「安全に」相手に指摘することができますが、レビューを受ける側はされるがままです。
これではあべこべです。
心理的な不安を取り去り、精神的・職場的に安全な環境で働くこと。ここまで含めての「安全必須条件にする」ということなんだと思います。
## Amazonの失敗は失敗じゃない
皆さんはFire Phoneをご存知でしょうか？私は知りませんでした。
なんでも大ゴケしたスマホだそうなんですが、AmazonのCEOはインタビューでこう答えたそうです。
「すぐにもっとでかい失敗をして来るから待っててね！失敗できる環境があることが誇らしいです。」と。
これが「高速に実験＆学習する」という原則に結びついてきますが、要するにこの失敗すら、Amazonにしてみれば「実験した結果ダメだったからこれを次に活かそうぜ」ということになるんでしょう。
失敗は成功の母とは本当によくできた言葉だと思います。
個人的に解釈が追いつかなかった、「顧客の要求すら実験であると捉え、早期失敗をするべきだ」という言葉は紹介のみに留めさせていただきます。
語りきれなかった部分
特に基調講演中、印象に残った部分を紹介させていただきます。
以下の状況を想像してみてください。
あなたはソーシャルゲームのプログラマです。
ソーシャルゲームは既に稼働していますが、テスト環境が充分でないため、本番環境を触るしかありませんでした。
ですがそんなある日、うっかりユーザーテーブルを全て削除してしまいました。
はい、この場合悪いのは誰でしょうか？
もちろん本番でテストしてしまったことに全ての原因はあるように思えますが、そもそも大きな失敗から首の皮一枚のところに労働者を置いているのはどこの誰でしょうか？
こんな環境では心理的安全が保証されるわけもなく、生産性は上がらないままでしょう。
別の企業の面白い取り組みとして、「ソフトウェアのバグを引き起こした人に報酬を与える」というものがあります。
「チームでレビューしたのにバグった！そっかーじゃあチーム全員の連帯責任だよねー」という考え方を一歩進めたものかな、と思いますが、このようなチームは非常に生産性が高いことでしょう。
セーフティーネットがしっかりしており、リスクや失敗を受け入れられるチームは強い。
まとめ
段々と"アジャイル"ってのは幻想で、"職場がうまく行っていれば自然とアジャイルな環境になっていく"ような気がしてきました。
その足がかりとして、アジャイルという価値観を植え付けるのは大事だと思いますが。
よく耳にする話しとして、上司の理解が得られない、形だけのなんちゃってアジャイルが横行してる、プラクティスの取り入れ方がわからない、なんてものがあります。
私自身もう少ししっかり考えて、今のチームに取り入れられるような形でモダンアジャイルの土台作りをしていきたいなぁ。