2008-11-21

アジャイルの衰退と凋落

The Decline and Fall of Agile を訳してみました. 例のごとく YukiWiki におかせてもらってます. 最近は短いのしか訳す根性がない...

Agile 批判はよくあるけれど, これは割と良い指摘をしている気がした. 耳の痛い部分もある. たしかに日次のスプリントと月次の再計画は割と簡単に導入できて, チームも締まったかんじになる. けれどコードがよくなるわけじゃない.

一方で, この二つの trivial なプラクティスを取り込んだところで, 何かが悪化することはどのくらいあるんだろうか. 元記事の文脈を察するに, もともと重量プロセスがあったところに agile を持ちこみ, upfront の設計や計画がなくなって破綻したという話に思える.

数十人, 数百人のチームでソフトウェアを開発するプロジェクトには, おそらく何らかのプロセス, 秩序があるだろう. この規模で勝手気ままに作っていたら, さすがにすぐ破綻してしまう. 既存の秩序(重量プロセス)が支配するプロジェクトで, 別の秩序(Scrum)に乗り換えるのは, たしかに危険なことかもしれない.

けれど私が今まで見てきた(疑似) Scrum の導入は様子が違い, まともなプロセスらしきものが何ひとつ無い状態ではじまった. だから Scrum が既存の秩序を壊すことはなかった. もともと混乱しかないなら, Scrum ですら何らかの秩序をもたらすことができる. そこにプロセス乗り換えのリスクはない.

Scrum の導入をリスクと言えるだけ秩序だったプロジェクトが一般にどれだけあるのか, 私は知らない. Scrum を使って失敗したプロジェクトのうち, Scrum を使わなければ成功したであろうものはいくつあるのか. いずれにせよ失敗する定めにあるプロジェクトの言いがかりじゃないの? そんな疑いを向けたくなる. "すごくダメ" が "ふつうにダメ" になったくらいでは, 顧客の望みを満たすことはできない.

もっとも, こうした疑問は全体の論旨を損ねない. trivial でないプロセスやエンジニアリングの重要性を説く Shore の主張には意味がある. Agile は簡単なものではない. けれどそれは, 良いソフトウェアを作るのは簡単じゃないとか, 良いプログラマになるのは簡単じゃないという主張のサブセットである気もする.

Scrum だけじゃない, XP に代表される様々な Agile の方法論は, 面倒でもプログラマのツールボックスに収める価値がある. Shore の主張の核心はそういうことだろう. 異論はない. ただし, ツールボックスの中で Agile そのものが占める手ごたえについては合意を先送りしたい. 目の前のスカスカな道具箱に唖然としながら, 空欄に何を積めようかと空想する.