そりゃ相性悪いっしょ
アジャイルとは、みたいな話をするといろいろ面倒なので省きますが、まぁ思想というかもっというと宗教に近いものがあるのでその辺は割愛。
たぶんだけど、日本でなんとか導入できるのはスクラムかなーと思うけど final answer でもないと思う。
ござさんの仮定もだいたいあっている。
もちろん、アジャイルは受託には不向きもいいところだね。
そもそも契約の考え方が違うし。
だから相性の問題じゃないんだよね、きっと。
で、質問に答えてみる。
最終的なリリース日はいつになるの？
ビジネスである以上、作りたいものがいつ頃上がって欲しいかは決まっているので、その日がリリース日になります。
これ案外大事なポイント。
予算との兼ね合いでどの程度の機能を作れば要求を満たせるかの調整はします。
これも重要です。
限られたリソース（お金、時間）の中で最大限に要求を満たし、満足できるものを得るためのひとつの方法です。
そのためには、まず動くものをとにかく早くだし（ショートリリース）、見て触ってもらって作りたいものの形を決めていくんです。
イテレーションって毎回納期もスケジュールも違うの？
基本的には、納期（というほど大げさじゃないけど）はどのくらいの開発単位にするかによるけど、概ね2週間が目安とされています。なので、基本的には定期的にお互いに決めた機能の実装を決めた期間のなかで作って顧客に出し、どんどんPCDAを回します。
ある機能の開発中、別の機能に要件漏れがあったらどうなるの？
そのためのTDDだったりするので、その辺はリファクタリングや機能追加なども含めて次のイテレーションのPlan時に決めていく。
逆に言うと、そういうモレなんてものは必ずあるわけで、あるのを前提に「変化を受け入れる」という信念に基づいてそれをサポートするためのTDDという位置づけです。
なので、ガシガシ修正していきます。
とにかくコードを書きまくるんです。
意志決定を先延ばしにする
これはちょっと読み取れなかったんだけど、例えば機能・要件・納期・予算を開発スタート前に決めるのが、機能も要件もつどつどのサイクルの中で決めていく＝これが先延ばしと言えばそうだけど、そうすることで変化に対応しやすくなる、というのが一番のメリットかな。
変化って、別にシステム要件だけじゃなく、ビジネス要件も開発と平行して検討・設計したりするものなので、最善の策はなにかをお互いが出し合って、都度都度決定をしていくことが、最初に決めるより先に延ばす、という言葉になっているのかな、と考えます。
アジャイル！アジャイル！
まぁ、ずっと種火のようにこの言葉はよく話題になりますが、少なくとも日本のSIer式の開発ではなかなか導入は進まないでしょうね。
まず人のレベルをある程度揃える必要がある。
でも、数人でいいのでいいメンツを揃えることが出来たらアジャイルやってみるのがいいと思う。
次に発注サイドだけど、もちろんアジャイルに関する意識を持って貰うことは当然として、どかんと当初予算をもらっておき、それを最終的に決済するのをイテレーションの切れ目切れ目で払っていく、というのが自然にやれることなんじゃないかなーと思う。
コストキャップがある中で、短期間に出来る限りの要求を満たすシステムを作ることができるんだから、滝のように開発する方法よりできあがるものに関しては満足度が高いと思うよ。
全部考えたものを意味不明な機能で実装されていくものに対するコストに比べると、だけど。
なので、コストが下がる下がらないというのはcase-by-case。
でもかかったコストに対する成果物はアジャイルの方が満足度は高くなる。はず。たぶん。きっと。おそらく。
内製も1ヶ月というスパンで区切って社員にコストを払っているわけだから、あとは手法（プラクティス）を導入するだけで、内製でもアジャイルになると思うよ。
散文的になっちゃったけど、この辺で。
