アジャイルの危機

アジャイルvsウォーターフォールの論争はしばしば起こりがちですね。

僕は2年前にエンジニアになって、その後
アジャイル(開発研修)
↓
ウォーターフォール(認可サーバーの開発)
↓
アジャイル(社内システム開発)
という変遷で経験してきました

そこで感じたのは「アジャイルと偽アジャイルの違い」です。

そもそもアジャイルとは教科書的には、素早く提供するために最小限の機能に絞ったものをリリースして、その後改善フィードバックを通してまた最小単位で機能を開発していきプロダクトの精度を高める開発手法だと認識しています。

従来のウォーターフォールに嫌な思い出のあった人たちはアジャイルを推し進めます。

私もそのような中で開発を経験してきました。

しかしそれは偽アジャイルだったのです。

正確には偽アジャイルというよりは「ウォーターフォールとアジャイルのいいとこどり」をしたものだったのです。

そう感じた理由は一言で言うならば「スクラムというアジャイル手法で開発をしながらも現場のエンジニアに権限がなさすぎる故にリリースを2週間や1ヶ月で回せた試しがない」ためです。

いくらエンジニアが生産性を高めて日々の開発はオンスケで終わらせたとしてもビジネスサイドの判断で結局リリースは半年後になったり、他チームにクリティカルな遅延が発生してリリースが延期になるなどがたくさんありました。

つまり関連部署が多くステークホルダーも多い、かつ、現場エンジニアにも権限がないため、「この機能だけお試しでリリースしたい」というような提案が通らなかったのです。

こうなってくるとやはりウォーターフォール開発の方がいいチョイスなのでは、と思ってしまいます。
が、やはりウォーターフォールにいい思い出はないのでアジャイル(風)な開発はしたいとなります。

すると偽アジャイルが誕生します。

しかしこの偽アジャイルはバランス感を考慮したものであって、これはこれでいい取り組みだと思います。

しかし「アジャイルで開発できている」わけではないので、小さくリリースして改善サイクルを回したいというのであればそれは実現できていないので危機と言えるでしょう。

ただ自分が感じたのは現場のエンジニアが単に「アジャイルでやります！」と声高々に言っても行き着くのは偽アジャイルにしかならないので、真の意味でアジャイル開発をしたければもっともっと上流のビジネスサイドの人とも絡めて議論して、その人たちが現場のエンジニアにいろいろな権限を渡せる覚悟をもってもらうような働きかけが必要なのかなと感じました。

つまりアジャイルかウォーターフォールかは「権限」というプロパティを誰にどのように所有させるかというところに行きつくのかなと感じました。

それではご精読ありがとうございました。