先日こんな記事を見ました。
・自動テスト ・ペアプログラミング あとは何だろ アジャイルは胡散臭いんだけど、メリットデメリットが理解しやすい方だと思う 追記：語弊があるな、自動テストは重要だ。TDD、XP界隈と言ったほうがいいか 追記：胡散臭いのと、不要ってのはちょい違う。必要でも胡散臭さは放てる。過大評価が近い。あと、複数人でやる方法論で胡散臭さが出がち。 出典：プログラミング、三大胡散臭い開発手法
こういった印象を持ってしまうのもわかるのですが、この結論を出してしまうのは早計かなというのが僕の感想でした。アジャイルでも、アジャイルのフレームワークであるスクラムでも理論は非常にわかりやすいのですが実践することが難しいから、というのが僕の感想の理由です。
ただ、これらは色々な方々からのコメントも見ている限り、日本では同じような意見を持っている方もいるようですのでせっかくの機会ですので僕の考えをまとめてみたいと思います。
アジャイルは胡散臭い？メリット/デメリットを感じやすい？
投稿者の方の意図を全てくみ取ることはできませんが、まず僕自身が思うアジャイル開発のメリットデメリットをざっと考えてみます。
- メリット
- 変化に対応することを重視しているため価値ある動くプロダクトを届けられる可能性が高い
- イテレーションを繰り返すためステークホルダーと対話をしながら変化に対応しやすい
- デメリット
- (特に今の日本では)関係者にもアジャイル開発手法について理解をしてもらう必要があるケースが多い
- 理論はわかりやすいが、実践することが難しい
ちょっと書くのに苦労しましたがいったんこんなところでしょうか。
メリットについて
アジャイルについてはアジャイル開発というふわっとした概念があり、それらの概念を継承した様々なフレームワークがある、という状況です。有名なものですとスクラムやカンバンがそうですね。
今回はアジャイルということに絞ってメリットを書いてみましたがメリットとしてはアジャイル開発宣言にもあるように変化に対応することを重視する思想になっていることにより得られるアウトプット(成果物)なのかなと思います。
アジャイルだと早い、とかそういったことは僕自身は考えておらず、重要なのは早さというよりは変化する状況に対応するような思想だということだと思っています。なので"早さ"についてのことは特にメリットの項目に記載しませんでした。
僕自身も普段はスクラムで開発をしていますが"早さ"について何かメリットを感じているというよりは"変化"に対応しやすいのが一番だなと思っています。
デメリットについて
メリット、デメリットで分けて話をするのもなかなか難しいのですがいったんデメリットもリストアップしています。
記載したようにデメリットとしては実際に何らかのアジャイル開発手法を取り入れる場合、周囲の関係者を巻き込む必要があるケースが結構あり、それが大変かもしれないな、と考えています。僕自身もなんどもスクラムを開発現場に取り入れてきましたが、一番大変なのはやはりスクラムチームをはじめに立ち上げる時です。
なぜこういった方法でやるのか、前の手法の方が早かったんじゃないの？、・・・などなどやはり手法を根本的に変えようとする時、そして変えた時にはハレーションが起こります。
まして、受託開発をしていたり、大企業で開発手法を変えようとすると諸々の調整を考えただけで目眩がしますねw そういう意味でそういったケースではやはり経験者にサポートに入ってもらうのが一番でしょう。
この点についてはスタートアップの企業では特に問題になるケースが少なく、アジャイル開発という視点においても大企業や古参のシステム会社よりも何歩も先に行っていると思います。組織としてフットワークが軽く、ハレーションも少ないですからね、アジャイル開発という点においては学ぶ点は非常に多いでしょう。
ということでアジャイルを導入する、という点において大変さがどうしてもあると考えるためデメリットの1点目としてあげました。
次の理論はわかりやすいが、実践することが難しいについても近しい内容です。
大組織においては上述のように導入までに社内の関係者と調整が大変、という意味で実践をするまでに非常に困難なケースがありますね。そして具体的に始められたとしても多くの現場で問題が起きてきます。原因は様々ですがこれらに対して僕が例えばスクラムの研修で教えていただいたのは、
スクラムは問題をあぶり出すフレームワークだから問題が出て当たり前だ、
ということでした。
なんだか狐につままれた気分ですが、そういうものか、と理解して僕はそれぞれの問題の解決に取り組んでいます。実際、アジャイルにおいては対話を重視していますし、他の手法よりもそういった対話の中でどんどん課題が出てくるのは納得できます。他の手法においても課題はそれぞれの開発フェーズであるでしょうし、アジャイルだけが課題がどんどん出てくる、というようには思いません。
そして、実践するのが難しい、ということについてもこの対話を重視している点と関係しているように僕は思います。
今までしたことのない新しい手法でやっているから慣れるまで時間がかかる、というのも原因としてあるでしょうが、意外にも(当然ですかね？)対話をする時間が長くなっているからちょっと口論になったり、チーム内で軽いいざこざになったり、なんていうのもあるかもしれません。
そういったシーンもうまく乗り越えながらチームで成長していけるよう、例えばスクラムにおいてはスクラムマスターがリードできたりすると何とかスクラムというフレームワークを実践することができたりすると思います。
スクラムガイドにはチーム内で振り返りの打ち合わせ(スプリントレトロスペクティブ)の時にちょっと口論になったらどう対処したらいいか、なんてことは書いてないわけです。しかし、対話を重視して価値あるプロダクトを届けよう、という考えがあるのでそのプロセスは必要でなんとかその状況も乗り越えていく必要があります。
一つの例ですがそういった意味でも理解は簡単だが実践は難しい、ということだと僕は理解しています。
胡散臭いのか？
こちらもなんとも言えませんが、僕の想像ではおそらくアジャイルを導入したことによる成果が過大に評価されているケースがあるためそれらをみて胡散臭い、と感じているケースが多いのかなという印象です。
上述してきたように、変化を重視し、対話をしよう、、というような発想が元になっているため、大げさにアジャイルだと早くなる！、みたいなことを期待していると胡散臭さを感じる結果になるかもしれませんね。
この辺りは何かうまく情報が整理されていくといいなと思います。
TDD、ペアプロ、XPは胡散臭い？
こちらもなかなか難しいお話ですが、まず僕は特に胡散臭いとは思っていません。
それぞれに適切な使いどころで導入していけば非常に有効な選択肢ですし、僕自身も所属するチームで柔軟にTDD、ペアプロをしています。
僕の予想ですが胡散臭い、という印象を持っている方は実際にある程度の期間、規模でTDD、ペアプロ、モブプロ、XPなどなどを実践したことがないのだろうと思います。
それぞれの手法には適切なシーンがありますし、例えばTDDであっても毎回TDDを実践してもいいですが、場合によって今回はTDDで実装していこう、というような手法でもいいわけです。胡散臭い、とだけ感じている方はおそらくこの発想ができるところまでまだ習得されていないと僕は考えます。
それぞれの手法は全く胡散臭くはないですし、詳細は割愛しますがそれぞれに効果がしっかりあります。
さて本記事はこれで以上です。
アジャイルについては非常に習得が難しいと思いますしまだまだ日本ではこれから普及されていく必要があると思います。全く胡散臭くはないですので先人の経験や書籍など諸々で学びつつぜひ実践していきたいですね。
アジャイルについては下記記事でもまとめていますのでぜひご覧ください。
https://masaytan.com/archives/678
それでは。
