何をしたらアジャイル開発なのか？

これはアジャイル開発を自分以外の人に伝えようとする際に必ず立ち塞がる疑問だと思います。

社内でアジャイル開発を認めてもらうまでに社内外問わず、色々な人からこの疑問についての意見を頂きました。「朝会(デイリー・スタンドアップ・ミーティング)をしたらアジャイル開発」、「TDDをしたらアジャイル開発」、「ペアプロをしたらアジャイル開発」、「いやいや、それら3つをして初めてアジャイル開発」等々の意見を聞きましたが、少なくとも私の中ではこれらではないと考えています。現にスクラムではTDDやペアプロをする様に規定していませんが、それをもってアジャイル開発ではないとは言えないはずです。同様に、朝会(デイリー・スタンドアップ・ミーティング)をしているからといって、それをもってアジャイル開発であるとも言えません。

他にも「ユーザに価値を提供する意識を持って行動を判断出来ること」、「ユーザとチームを組めること」といったものをあげる人もいますが、これはアジャイル開発を実践した場合の効果であって、アジャイル開発である要因ではありません。

私も同じ様にこの疑問に遭遇しました。そこで私の出した答えは、“アジャイルソフトウェア開発宣言”に書かれていることを実践出来た時、アジャイル開発をしていると言えるというものです。

つまり、"個人と対話”、"動くソフトウェア”、"顧客との協調”、"変化への対応”に対して、価値をより多くおくということです。これは"プロセスとツール”、"包括的なドキュメント”、"契約交渉”、"計画に従うこと”に価値を認めないということではなく、上記の4つに対して、より価値をおくということです。

アジャイル開発の良さを伝えると、必ずと言って良い程、“何をしたらアジャイル開発なのですか？”と、本当に色々な人に聞かれますが、『アジャイルソフトウェア開発宣言を読み解いていけば分かると思います』と回答しています。

極端な話、朝会(デイリー・スタンドアップ・ミーティング)、ふりかえり、TDD、ペアプロ、リファクタリング、ソースコードの共有所有、継続的インテグレーション(CI)、YAGNI等々の一般的にアジャイルソフトウェア開発手法のプラクティスをどれだけ実践していたとしても、"個人と対話”、"動くソフトウェア”、"顧客との協調”、"変化への対応”よりも"プロセスとツール”、"包括的なドキュメント”、"契約交渉”、"計画に従うこと”に価値をおいている、つまり、"個人と対話”をせず"プロセスとツール”にばかり拘っている、"動くソフトウェア”をいつまでも作らず"包括的なドキュメント”を作り続けている、"顧客との協調”をせずに"契約交渉”ばかり行っている、"変化への対応”よりも"計画に従うこと”を重視するのであれば、それはアジャイル開発とは言えないのです。

同様に、朝会(デイリー・スタンドアップ・ミーティング)、ふりかえり、TDD、ペアプロ、リファクタリング、ソースコードの共有所有、継続的インテグレーション、YAGNI等々の一般的にアジャイルソフトウェア開発手法のプラクティスを一切実践していなくても、"プロセスとツール”、"包括的なドキュメント”、"契約交渉”、"計画に従うこと”よりも"個人と対話”、"動くソフトウェア”、"顧客との協調”、"変化への対応”に価値をおいている、つまり、"プロセスとツール”に拘らず"個人と対話”を重視する、"包括的なドキュメント”を作ることよりも"動くソフトウェア”を作る、"契約交渉”よりも"顧客との協調”を優先する、"計画に従うこと”よりも"変化への対応”を行うのであれば、それはアジャイル開発と言えるのです。

「スクラムで開発をやっているのでアジャイル開発をやっています」と仰る方に良くお会いします。そういった方に次の様な質問をすると、殆どの方が同じ答えを返してくれます。

Q：スプリント中にユーザから変更要求がありました。競合他社から新サービスがリリースされる情報が入ったので、どうしても現在のスプリントで競合他社の新サービスに対抗出来るサービスをリリースして欲しいそうです。そのサービスの内容は既に決まっていましたが、優先度が低くされており、今回のスプリントには入っていませんでした。対応中の全てのストーリーを次のスプリントにまわしてよいのであれば、現在のスプリントにユーザの入れて欲しいサービスを入れることが出来ます。スプリントのちょうど半分だったので、ストーリーポイントは半分以下になってしまいますが、ユーザはリリース出来るストーリーポイントが減っても良いので、変更要求を受け入れて欲しいそうです。あなたならどうしますか？

A：スプリント中にユーザからの変更要求は一切受け入れません。

この答えはスクラムとしては正しいものです。スクラムではスプリント期間中は顧客からの変更要求は一切受け入れない、スプリント中に変更要求が発生したら次スプリントまで受け入れないと言われています。

http://www.metabolics.co.jp/XP/SP03-02.html
http://kanan.air-nifty.com/blog/2011/09/post-4f02.html

この様に答える方々は確かにスクラムで開発をしているかもしれませんが、彼らがやっているものはアジャイル開発ではない別のものかもしれません。

この様に、価値をおくといっても、中々難しいものです。そういった場合に、既にあるプラクティスを導入するというのは良い導入方法だと思います。しかし、"個人と対話”、"動くソフトウェア”、"顧客との協調”、"変化への対応”が重要であるという様に意識を変えずに、ただプラクティスだけを取り入れたところで、それはアジャイル開発ではないと言えます。

上にも書きましたが、スクラム、XP、AUPといった開発手法ではなく、ウォーターフォールで開発をしていたとしても、"動くソフトウェア”、"変化への対応”を今より価値をおく＝より出来る様にする、という考え方からTDDや継続的インテグレーション(CI)を導入しているのであれば、それは十分アジャイル開発を目指していると言えるのです。

アジャイル開発はデジタルにアジャイルであるか、アジャイルでないかが分かる様な all or nothing ではありません。アナログなもので、度合いといえます。どれだけ"個人と対話”、"動くソフトウェア”、"顧客との協調”、"変化への対応”に対して価値をおいているかなのです。