Agileは難しいのか？
「Agile開発は難しい（難しそうだ）」という意見を聞くことがある。「難しい」のは
- 政治的に難しい（社内ルールと合致しない）
- 営業上、難しい（道幅課金を顧客に納得させる必要がある）
- 技術上、難しい
の３つに分類できるのだけど、ここでは「技術上難しいか」だけ書いてみたい。
Agileは「平均的な人達」のための技術
自分は「Agileは平均的な技術力を持った人達のための開発技術」だと思っている。
平均的というのは
- 要件分析や定義で平均的に抜けや誤りを発生させて
- 設計で平均的に抜けや誤りを発生させて
- 実装で平均的にバグを埋め込んで
- テストやデバッグでのバグ検知修正が平均的に下手
ということ。要は神でも天才でもない人達だ。自分ももちろんこの範囲に納まっている。
- 平均的な人達は平均的に間違いを犯す。
- ソフトウェア開発においては、それらの間違いは「発覚が遅れるほど、傷が深くなる」のは周知の事実。
神でも天才でもない平均的な人達は、要件定義や設計書だけから完成後の姿を完全に想像することは困難。つまり、間違いが発覚するときには傷が深くなっている。ウォーターフォールでプロジェクト後半（実装〜連結あたりから）が修羅場になるのは、当然の帰結かも。
Agileは間違いをできるだけ早期に検知し、対応する。そのために、開発対象（フィーチャ）を小規模に絞り、短期間で作るという周期を繰り返すわけだ。
でも、この「事前にごちゃごちゃ設計する」ことで、平均的な俺達は自分達の首を絞めてきたわけでしょ？
難しくやるから難しくなる
「Agileは難しい」と思っている人達全てとお話したわけじゃないから、自分の失敗経験を元に推定して書く。Agileを難しいと思うのは
- 事前設計をやりすぎている
- 一度の開発量が多すぎる
このどちらか（あるいは両方）だろう。
これらは平均的な俺達には無理なのだ。
訓練・稽古・演習・・・
とはいうものの、「ちょっと作って、テストして、リファクタリングする」というのは、「設計して、コーディングして、テスト」という流れに慣れた人は違和感を覚えるはずだ。そして、これはプロセスとして手順化することができないのも事実。出来具合を見て、どうすればいいのか考えるわけだからね。[*1]
この「考える」というのは、訓練が必要であろう。稽古や演習ともいえるかも。この訓練なしで、いきなり社運のかかったようなプロジェクトにAgileを適用するのはちょいと無謀。*2
