なぜアジャイルか？

先日書いた振り返り記事で、今後の教訓として、既存のシステムを別の仕組み（今回はRDB→検索エンジン）で作り直すタイプのプロジェクトは「アジャイルで〜」とさらっと書きましたが、なぜアジャイルか？が抜けているので、ちょっと整理してみました。

（じゃないと、またウォーターフォールでいっか、となりそうで・・）

アジャイルに対する理解不足などがあれば、ご指摘いただければ幸いです。

システムを作り直す難しさ - 仕様は誰も知らない - yoshi0309のブログ

なぜアジャイルである必要があるのか？ 単に十分な調査期間を設ければよかったのではないか？

まず、十分な調査時間が全体としてどのぐらいあるのかいっぺんに見積もることはできない。アジャイル的な進め方であれば、近い計画は比較的高い精度で期間を予測でき、小さく失敗することができるのでリカバリーも容易である。このため、調査時間や開発に必要な工数の精度を徐々に高めていくことができる。結果、ウォーターフォールと比べ、ぶれを小さく押さえることが出来ると考えられる。

仮に十分な調査時間を見積もることができたのであれば、かかる工数は同じではないか？

それができれば近くなるはず。しかし、それは結果論であり、そもそも調査前に調査期間を正確に見積もることができない。なぜなら、見積もり者（＝私たちSIer）は、既存のコードを知らず、既存のコードを知っているもの（=お客様、ないしはメンテナンスチーム）は、新たに作るものを知らないから。知るためには、どうやったって作業が必要で、つまりこのタイプのプロジェクトは「やってみなければわからない」部分が非常に大きい。実際に、システムテストで動いている新・旧のシステムを画面で比較してみてやっとわかった仕様もあった。

全体のコミットが出来ないアジャイルという手法を、どう受け入れてもらうか？

残課題。アジャイルに共通するそもそもの前提として、最終的な工数やスケジュールがどのぐらいかかるかはわからないことを理解し認めてもらう必要がある。（よく本では、全体のコミットはできないと書いてある）また、全体のコミットができなくとも、ブレるリスクを避けるための方法としてアジャイルを提案することはできる。（ある意味では、誠実な態度ではあるが、事業計画としてコミットする必要があるお客様側としては正直受け入れにくいようにも思う。どうすれば受け入れてもらいやすくなるかはよく考えてみたい。）

いろいろとメリットは大きいと思うのですが、どうやってお客様に理解してもらうか、また、お客様の事業計画にどうやって不確実性を理解しのせてもらうか・・。一般的にはどうやって解決しているんでしょうか？