2010普段、イテレーションの終わり(ちなみに1週間)にKPTをやって問題点をだして、それを解決すべくTryを実践してはいる。短期的な解決で落ち着いてしまってしばらくすると似たような問題が発生する。結局のところ、問題が発生したらその場の解決だけではなく、問題の原因を検証して、自分達の開発プロセスに再発防止の仕組みを組込まなければならないなと思った次第。そんなことをFaceBookやTwitterに書き込んでいたら、諸先輩方(@kdmsnrさん、@nawotoさんありがとうございます)から「それがアジャイル」みたいなことを言われてしまった。確かに言われてみればそうだ。一定のプロセスにこだわらないからこそ、柔軟に問題・変化に合わせてプロセスを変えていけるのがアジャイルなんだよね。今までやってきたことを繰り返したところで結果は同じなのは当然。今までのやり方で「何かうまくいっていない」と思ったら、やり方を変える必要がある。その辺りの検証が今のチームには不足してるなぁ。あとは開発の遅れやバグの発生などが開発チームの問題として捉えられがちだけど、結構開発プロセスが上手くまわってなかったり、プロジェクト関係者のコミニュケーションロスが原因で発生してるものもある。いう意味でちゃんと開発メンバー外のプロジェクトに関わる人を全員まきこんでやっていかないといけないわけだけど現状出来てないなぁ。アジャイルごっこから抜けだすべき時期なのかもしれない。(アジャイルな見積りと計画づくりの訳者あとがき)その辺もなぜコミニュケーションが上手くいっていないのか、なぜデモ直前のテストで問題が多発するのかとか、ちゃんと原因を調べてプロセスに組み込んでいかないといけないなぁ。ソフトウエア開発に活かす7つの原則がきっかけ。リーンが何かと言うのはまだまだちゃんと理解しきれていないけれど、現状を色々考えさせてくれるいい本でした。