アジャイル教のダメなところ

うまくいかないのは、アジャイルを理解してないからだ
うまくいかないのは、アジャイルを実践してないからだ
うまくいかないのは、アジャイルを信じないからだ

・「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ

うまく言葉で表現できずに、細かい点をアレコレ違うんじゃないかなぁと書いてきたけど、本質的な問題として、そういうのがあるからだと思う。

　十分な単体テストを書こうと思うときに、後追いで、ユニットテストのコードを書くと死ぬほど難しく、複雑になる。本番のコードは甘くないのだ。じゃあどうする かというと、少しだけ先に「テストコード」を書いて、テスト実行。エラーになったのを確認してから、本番コードを数行実装、テストを実行してパスしたら、次のテストコードの実装を少しだけ、、、更に、コードが重複したら「リファクタリング」という方法でコードの設計を改善する。 　このようなステップを踏んで開発をすると、常にテストコードが十分な状態で無理なく開発を進めることができる。
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ

エンジニアや現場の人が、こういうのを真に受けて実践するのは、実践した結果が実感できるのでいいと思うんだけど、そうじゃない人が真に受けて実践させようとすると、泥沼になるような。
つまり、うまくいかないのは、エンジニアや現場が悪くて、アジャイルという方式でないってことになるので・・。

いかにも物議を醸しそうな（そして実際に醸しまくった）この記事を、Ruby on Rails の作者である David Heinemeier Hansson (DHH) 氏が発表したのが去年の４月、ということはあれから既に一年以上が経過している訳で、今更感が若干漂うところではあるが、このシリーズ「TDD再考」では、このDHH氏の記事に端を発して行われた様々な主張や議論を振り返りながら、アジャイル以後のプログラムデザインについて再考してみたいと思う。

件の記事でDHH氏は、「TDDは死んだ」と高らかに宣言しているわけだが、まず始めに気をつけなければならないのは、DHH氏が言うところのTDDというものが、かなり極端な例を念頭に入れて想定されているという事である。それは彼が「fundamentalism（原理主義）」や「fanatical（狂信的）」のような強い言葉を使っている事からも伺われる。

彼の批判を紐解くとポイントは二つある。一つはテストファーストこそがプログラミングのあるべき姿であり、プログラムのクオリティはそれをいかに正しく実践しているかによって査定されるという考え方が蔓延した結果、実際にそれが有効かどうかとは関係なく、それを実践しているかどうかで技術者の値踏みが行われるようなってしまったということ（ドグマ化）。そして、二つ目は、厳密な意味でのユニットテストでTDDを実施してプログラムデザインを導出すると、必要以上の細分化（これは James Coplien氏による指摘）と間接化（大量のMockオブジェクト）によって、過剰な複雑化を招くという事である
TDD再考 (1) – テストファーストとユニットテストへの死刑宣告 | ゆびてく

・TDDの実践者が言及するテストカバレッジ100%には意味が無い
・バグを取り除く最大の機会はテスト以外のところにある
・ユニットテストにビジネス価値はほとんどない
・TDDはプログラムデザインに害を及ぼす
・ユニットテストの維持コストは馬鹿にならない
・テストがコードのクオリティを上げる訳ではない、上げるのは開発者自身である
TDD再考 (2) – 何故、ほとんどのユニットテストは無駄なのか？ | ゆびてく

こういう指摘もあるんだけどね。、日本人だとダメみたいなので欧米人らしい人を・・。

まあ、実際やったらそんなのは、レベルの低い人でも実感できるわけで、問題点もなんとなくわかるんですけどね。でも、それはレベルが低い（能力が低い）からだということで片づける人たちもいるわけです。

思想としては、面白いし、何らかの改善にはなっている

しかし、万能でないし、思想ですべての問題が解決できるわけがない。

アジャイルには、経済的なものがあまり考慮されていないっていうのもあると思う。たとえば、「ユニットテストの維持コストは馬鹿にならない」とかは致命的だといういう場合もあるでしょう。