「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ www.publickey1.jp/blog/13/7_3.html の議論を、とても興味深く拝読していた。
それに対して、論争が発生したときの心構えについて『若い人や新人へのメッセージ http://d.hatena.ne.jp/masanari/20130102/1357069163 』として、このブログの昔のエントリに書いてあったので、ひとつの意見として、ぜひ読んでほしい。しかし、紹介だけでは少し寂しいので続きを書く。
アジャイルについて最初に学んだのはリーンについての書籍だったと思う。リーンの原則に照らし合わせ、プロセスや方法を見直すなどの経験をした。しかし、その後、XPやScrumの話を聞いたときに「そのときの私が対面している状況は違うこと」を理解した。むろん、おやつを置くとか有用なことはまねをしたけれど、前提としている状況が違うのだ。たとえば、イテレーションごとに計画を立てよう、ということは、ビジネスの状況が日々変わらないことを前提にしているのだろう。大幅に状況が変わるのであれば、その計画の多くは無駄になる。しかし、プロジェクトが肥大化してくれば、協調作業が発生するので計画を立てることはとても役に立つ。
『いいアジャイルと悪いアジャイル http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm』を読んだとき、共感したことを覚えている。特に「Scrumは、本当によくできたビジネスモデルだ」とも感じていただけに私の感覚に近いところが多くある。
しかし、状況によっては「悪いアジャイル」も必要なのだ。ペアプログラミングはうちには合わなかったけれど、ペア作業や運用が有用なときもあった。たとえば、自動化したスクリプトの起動や状態の確認などの作業について相互に確認することによってミスを減らすなどの結果を出してくれた。悪いアジャイルが「状況の現実に盲目になる」という主張に激しく同感だ。ただ、盲目になる必要がある（正確には、状況を切り離し、自ら立ち上がれるまで守る必要がある）ときもあるのだろう。あまり望みたくはないが、そのような酷い状況のときは選択肢として残されている。
で、今後はどんな感じになるのか。
たとえば、IPAの『アジャイル型開発におけるプラクティス活用事例調査調査報告書~ガイド編~』を見ると、
- 事例(4) C 社では、アジャイル型開発(XP)とウォーターフォール型開発を並列に行っている。
- 事例(7) E 社では、"業務要件定義を実施した後に、画面インターフェイスの定義から結合テストまでを反復型開発した"
- 事例(8) F 社では、"基本的にスクラムであるが、制約理論(TOC)と組み合わせている"
と、様々な手法を取り入れるようになってきている。
もはや、アジャイルとウォーターフォールの優位さを論じる時期ではなく、状況に応じた手法やプラクティスを取り入れることが「ふつう」になってくるのではないか。
巷には、たくさんの方法論やプラクティスや手法、思考などがあふれている。読み学ぶにしても一生は短い。意見も様々で、議論をする時間も果てしなく必要だ。これらの手法や思考に対するメタな取り組み方を開発しなければならなかった。
そのひとつの例とした「ゆる思考」を考えている。なぜ、ゆる思考が必要なのか、その実現技術はどのようにすればいいのか、そのときの「基準」はどうすれば良いのか、たくさん書きたいことがあるが、エントリを分けて紹介したい*1。
*1:がんばって仕事しなくちゃと思ったのでした。
