アジャイルが失敗するのは、ルールが大好き人間がルールに安住するからだと、Andrew Huntが、The Failure of Agileというブログ記事に書いています。
Andrew Huntは書いていま2001年のアジャイルソフトウェア開発宣言に名を連ねているアジャイル開発提唱者の一人です。
他にも、以下のようなことを、Andrew Huntは書いています。
- アジャイルの原則は、変化を受け入れることだが、人は本来変化を嫌う
- 変化は不安定な変化になり得るので、新たな問題にも対処できるように手法革新と新手法導入を実務担当に強いるのがアジャイル開発である。
- 与えられたルールに従い、「規則どおりにやっている」と言えた方がずっと楽で簡単。
ルールを順守していれば、失敗しても笑われたり非難されたり、クビになったりしない。
ルールには安全と快適さが存在する。 - アジャイルな開発では、ルールに安住せず、変化を受け入れ、考えることが求められる。
ルールどおりに行動する快適さがアジャイルにはない。 - 素直にルールに従っていれば、失敗は個人の責任ではなく、ルールの不備に起因する失敗となる。
責任を問われない適さは、アジャイル開発には無い。 - ルールに従って快適さを享受していると、初心者程度のパフォーマンス発揮できなくなり、開発は失敗する。
GROWメソッド
打開策として、GROWメソッドが提言されています。
GROWメソッドでは、現実を調べ、現実からのフィードバックを受け入れることを提唱しています。
ソフトウェアは、設計に基づいて構築するものだと考え、設計どおりに動きさえすれば、役に立たなくても良いというような思想から脱却しいようという提言です。
設計＝絶対的で不動の指針として開発を行い、現実から乖離した役に立たないソフトができあがっても意味が無いという趣旨です。
動くソフトと役に立つソフト
英文のアジャイル宣言にある”Working software”が日本語のアジャイルソフトウェア開発宣言では、「動くソフトウェア」と和訳されています。
「動くソフトウェア」という言葉では、「役に立つ」とか「仕事をするソ」とかいう意味が薄れて、不具合が無く稼働するソフトという意味になってしまいます。バグ１つなく完璧に動くソフトであっても、実際の役に立たず、使えないソフトウエアでないと意味がないと思います。
ソフトを書いている下請けベンダーにとっては、設計どおりに作ってお金をもらうことが全てです。
そういう場合は、使えないソフトでも仕様書どおりに完成し検収に合格してお金がもらえるソフト＝役立つソフトです。
ベンダーにとっては、受注した時の設計どおりに動くことが全てで、役に立つかどうかは関係ありません。
自社開発なら、こういう事情は無いと思いますが、発注者と受注者、さらに下請けといった構造ではアジャイルは難しいかもしれません。
空気を読む社会
空気を読みながら仕事する社会では、アジャイルは無理なのかもしれません。
ルールとして明記されていない事項も、空気を読みながら、暗黙のルールとして次々と追加してい体質があります。
ルールじゃないけど、常識として暗黙のルールができます。暗黙のルールにさえなっていない事項も、「あり得ない！」という一言でルール違反として扱われます。
ルールや常識に縛られず、変化し続ける道が、破滅につながっている社会や会社では、アジャイルは止めといたほうが良い気がします。