Rinse, wash, and repeat!

• 今回もAgile導入のお手伝いやらAgile開発のススメやらで来日。
• ゆっくりだけど確実にAgile開発は普及しつつある。
• だけど...組織の体質を変えるのはそんなに簡単ではない。
• それを実感した出来事。

なぜ文書整備から入るのか？

• 今回お話を聞いたプロジェクトのうち二つで、こんな悩みを相談された。
• 「Agileでは不要な分書類を作ってしまう。画面設計書、画面遷移図、テスト計画書など」
• よくよく理由を聞くとおもしろいことがわかった。
• それらの文書類を作る人達は、「なぜ、その文書を作るのか」という理由をわかってない可能性があるのだ。
• もっと具体的に言うと、「これまでの開発手順では、そういう文書を作ることになっていたから」となる。
• つまり、開発手順のマニュアル化による副作用だ。

対策

• マニュアル化＝考えないことの推奨
• つまり、その弊害を取り除くには「考える」ようにするしかない。
• 実践（プラクティス）あるのみ。

• だけど、そう考えない人もいる。
• 「考えない」人達でもAgileできるようにするには「こうすればAgileできる」というフレームワークを整備する必要あり。

→「こうすればできる」というフレームワークの前提条件に合致しないプロジェクトでは適用できない。適用範囲を広げようとすると、そのフレームワークが巨大化してなんだかわからなくなる。なんだかわからないものを手順書通りにこなすということは...「考えないこと」を推奨することに他ならない。