プログラマに都合のいいスクラム

感想おまちしてます!

「どうやったらアジャイル開発が成功できますか?」という質問に答えられませんが、悲しいことに「どうやったら失敗するか」は答えられます。本当はうまくいく方法があって、それをみんなで共有できればいいんですが。今日はこれまでに経験した「アジャイル開発を失敗させる方法」について書いてみます。

スポンサーリンク

スケジュールにコミットしない

バックログというやることリストを作り、優先順位をつけ、上から順番にやっていきます。ベロシティとかがわかれば、「だいたいどれぐらいでどの量の作業が終わるか」を見積もることができますが、それとコミットメントは別です。

もちろん、関係者間で「ベストエフォートで作業する」という共通認識があり、信頼関係が築けているなら、多少の「ぶれ」、すなわち「ちょっとだけ目標より作業をこなせませんでした」とか「思った以上にできました」とかがあってもいいと思います。

ただ、その前提条件をクリアせずにやってしまうと「スクラムなんで計画に確実にコミットメント求められても困ります」といった、プログラマに都合のいいスクラムができあがります。

プログラミング以外に責任を持たない

スクラムをするならスクラムガイドの4ページ目にでてくる「スクラムチーム」を実現する必要があります。自分はこれが(スクラムだけでなくアジャイル開発全般における)前提条件であり、これが実現できればあとは簡単! と勝手に思っていて、このハードルが高すぎるから、いろんな失敗事例がでてくるのかなぁと思っています。例えば、スクラムガイドの説明を読んでみてください。

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。

世の中の「スクラムやってます!」って企業はもうとっくにこれを解決しているのでしょう。すばらしい! うらやましい! ごめんなさい。ちょっといぢわるに書きました。

僕が言いたかったのは、こういった人のアサイメントや組織レベルの変化を実現できる環境なら、成功への道のりが見えてくるのではないでしょうか。ただ、そうじゃない場合、なかなか超えるのが大変な壁に見えます。

話が少しそれました。「チーム以外に頼らずに作業を成し遂げる能力を持っているチーム」を作っても、役割が大きく変わるわけではないと思います。しかし、近くにいることをいいことに、本来持つべき責任を丸投げするプログラマがいるようです。

たとえば、テスターが都度QAをしてくれるので、コードレベルの単体テストを実施しないとか、デザイン崩れなどはデザイナ責任としてチェックすらしないとか、プログラマに都合のいいスクラムができあがります。

変化を受け入れない

時代の変化スピードがはやくなるにともない、「どうやればその変化にソフトウェア開発がついていけるか」を考えぬいた結果、「変化に強いプロセス」として生まれたのがこういった方法論なのかなぁと思うのですが、

・仕様がかっちり決まってないと作れない
・スプリント途中の変更は受けつけない

とか、ちっこいウォーターフォールみたいになっちゃうと、プログラマに都合のいいスクラムができあがります。

おわりに

最近、ふとこんなことを思いました。

知識だけあってもだめだし、行動力だけあっても人がついてこなかったりするみたいで、なんでもかんでもスクラムが最高だったり、スクラムが最悪だったりするのが最近見ている風景です。

残念な部分は多々あるんですけど、こういう経験は次に活かすためにあるものだと思うので、やる側は「次はうまくやるぞ」ってモチベーションを持ってもらい、やられる側は失敗を受け入れられる環境を整えたり、結局のところ、双方の信頼関係が重要なのでしょう。

「それはスクラムじゃない!」とかになりがちだけど、それは本質ではない。