Agileで失敗する時
ちょっと古いけど、こんな記事があったので訳してみた。
Allan's Blog: Failures in Agile process?(Agileでの失敗?)
ACCU*1の会議でよく受ける質問に「Agile開発の欠点は？」「Agileでの失敗はどんな感じなの？」というのがある。
一つ目の質問には答える事ができなかった。ただ、プロダクトオーナーに負担がかかりやすい、という問題点はあるかもしれない。通常はビジネスアナリスト、製品マネージャ、顧客、あるいは顧客窓口の人がプロダクトオーナーになるのだけど、とても負荷のかかる仕事だ。このあたりはJames Nobleが研究しているね。
プロダクトオーナーは本来の仕事をこなしつつ、Agileチームの相手をすることになる。Agile開発チームの生産性があがってくれば、チームはプロダクトオーナーに「あれはどうするの？」「これはどうするの？」と色々と質問する頻度があがってくる。どこかの時点でプロダクトオーナーは手一杯になり、生産性が天井に達する。
でも、これはAgileの欠点ではないと思うんだな。むしろこれは事業の失敗と思うべきだろう。こう考えてみよう： 何年にも渡って、経営側は開発チームの生産性の低さに対して文句を言ってきた。欲しいタイミングで欲しいソフトウェアを届けてくれない、と。そこにAgile開発チームが現れて、こう言うわけだ。「必要なソフトウェアをどんぴしゃりと納品してみせましょう」ただし「何が欲しいかを正確にきっちりと説明してもらいますよ。」
6人の開発者を用意して、欲しいものが出来上がってくるのをまってれば良い、なんていうことはもはや許されないのだ。何が欲しいのかをきっちりと開発者達に伝える必要がある。詳しく、ね。
二つ目の質問「Agileでの失敗はどんな感じなの？」も中々難しい。失敗を分析した事例がまだまだ少ないからね。これはAgileに限らず、ソフトウェア産業全体について言える事だ。どの企業も失敗事例については語ろうとしないもんだ。
とはいうものの、Agileの失敗は下記のように分類できると思うんだな。
- 開発チームが途中から昔ながらのやり方に戻ってしまう。自分は遭遇した事はないけど聞いた事はある。よくあるパターンは、たくさんのシステムコンサルタントを呼び寄せた上で、AgileチームとAgileプロセスを作り上げ、そのコンサルタント達がいる間はうまくいくけど、コンサルタント達が引き上げたら、また昔のやり方に戻ってしまう、というやつだ。ユニットテストが落ちてもそのまんま放置され、計画会議は開催されなくなり、品質は下がっていって納期も守れなくなる。コンサルタント達の存在は、開発チームの支えにはなってくれるけど、知識の移転には至らなかった、ということだ。
- 管理層が買ってくれない。開発現場主導でAgileが導入されるのは珍しくない。でも、どこかの時点で管理職達が継続か中止かを決める日がやってくる。あるいは何の判断もくだされず、開発プロセスはバラバラになってしまう、とか。
- 開発現場が買ってくれない。前述とは逆で、管理側がAgileでやると言ってるのに、現場がついてきてくれない状態。テスト書きたくねーよ、コードレビューいやざんす、ペアプロいやっす、「可視的な計画よりも技術の信奉」なんてまっぴら、等々。結果、開発プロセスはズタズタになる。この手の失敗は今後増えていくだろうね。
でも、これらもAgileが悪いのではないね。結局の所、ITプロジェクトや開発プロセスの失敗というのは常に起きているし、それがAgileだからといって特別なわけでもない。ウォーターフォールやRUPでも、コケるときは同じようなもんでしょ。
Agileのもたらす効果を見落とすと、Agileは失敗しやすい。ちょっとAgileしたけど品質向上が見られなかったら...納期を守るようにすることで、問題点が見えてくるはずだ。
