所用で Code Complete を読んでいると「反復型開発 (Iterative and Incremental Development)」と言うキーワードが出てきました*1。「反復」と言う単語を聞いてまず思い浮かんだのは昨今よく話題になっている「アジャイル開発」なのですが、「アジャイル開発」と言うキーワードが指しているものと「反復型開発」と言うキーワードが指しているものは果たして同じなのかどうか自分では判断が付かなかったので Web 上の記事を漁ってみる事にしました。
漁ってみた結果ですが、少なくとも「完全に同一のものである」と言う認識の人はほとんどいないようです。
インクリメンタル型開発とイテレーティブ型開発を合わせたソフトウェア開発手法のこと。システム全体をいくつかの部分に分割して反復しながら機能や品質を洗練し、それを段階的に全体に統合していく開発プロセスをいう。狭義にはアジャイル開発と区別されるが、広義には含まれる。
IID（あいあいでぃー） - ITmedia エンタープライズ
どの程度違うのかについては人によって主張にブレがあるようですが、少なくとも何らかの要素に関しては「反復型開発」と「アジャイル開発」には差異が存在すると言う認識については概ね一致すると言う結果でした。
アジャイル開発と反復型開発の違い
それでは何が違うのか。例えば、アジャイル開発と反復開発の落とし穴 (1/3)：ソフトウェア開発の匠（4） - ＠IT においては「反復開発は管理重視型開発、アジャイル開発は価値重視型開発」と言う主張がなされていました。
反復開発は、最初にソフトウェア化する意義をしっかりと議論する。議論を通じてビジネスモデリングを行い、ビジネス課題の理解を促進する。このような段階が「方向付け」と呼ばれ、必要に応じて「分析・設計・実装・テスト」を繰り返すことになる。この繰り返しには、プロトタイプやビジネス検証という意味も含まれている。
このようにかっちりビジネス課題を理解したうえで、プロジェクト計画（反復計画）を策定していくため、反復開発は「計画重視型」さらには「価値固定型」といえる。ビジネスにおけるシステム価値の全体像を明確にし、その全体価値を守るように管理しながら、部分集合をユースケースドリブン（ユースケースを束ねるごとに開発をプランする）で開発するのだ。
一方、アジャイル開発は、同じ繰り返し型開発であっても、反復開発とは異なり価値重視の印象がある。計画よりもむしろ開発するソフトウェアやソフトウェアが実現するビジネスの価値を重視している気がする。なぜそのように感じるかというと、反復開発よりもイテレーション（繰り返し）の期間が極端に短く（週単位）、計画よりも変化対応を大切にしており、さらに開発プロセス全体についても最小限の説明にとどめているからである。
アジャイル開発と反復開発の落とし穴 (1/3)：ソフトウェア開発の匠（4） - ＠IT
また、別の記事では「ウォーターフォール型や反復型開発は、最初に完成形を要求仕様として描く」と、「反復型開発」はどちらかと言うと「ウォーターフォール型開発」寄りのものであるとも受け取れるような主張も見られました。これは、前述した記事の「せっかくウォーターフォール開発という官僚的で、楽観的なプロセスから脱出する時代が到来すると思ったら、また反復開発という親せきがやってきた」と言う一文にも同様の趣旨が読み取れます。
確かに、「反復型開発」と言うキーワードの代表例としてよく名前の挙がる「Rational Unified Process (RUP)」の解説記事を読んでみると、「管理」が強調されているようにも感じられます。
RUPは、短期間のウォーターフォールを繰り返しながら、製品の機能を段階的に高めていく、いわゆる反復型プロセスに分類されます。
第1回 RUPはどこに消えたのか？ (1/3)：CodeZine（コードジン）
…（中略）…
これらのアプローチを現実にどうやって実行していくか？ そのために、次の6つのベストプラクティスを提唱していました。
その一方で、少なくとも Code Complete での「反復型開発」の項目では、そこまで管理重視と考えられているようにも見えず、個人的には「反復型開発」と言うキーワード全体に対して「管理重視型開発である」と断言するのは些か言い過ぎではないかと言うのが現時点での率直な感想です。
準備を事前にどの程度まで完了しておくかは、表3-2 で示したソフトウェアの種類、プロジェクトの形式、技術的な環境、スタッフのスキル、プロジェクトのビジネス目標によって異なる。次の場合には、より遂次性の高い（事前に準備を済ませる）手法を選択した方がよいだろう。
- 要求がかなり安定している。
- 設計が比較的単純で、かなり理解されている。
- 開発チームがそのアプリケーション分野に精通している。
- プロジェクトのリスクが低い。
- 長期的な予測が重要である。
- 要求、設計、コードを下流で変更すると、高くつく可能性がある。
一方、次の場合には、反復型の（作業を進めながら準備する）手法を選択した方がよいだろう。
- 要求が十分に理解されていない、あるいは他の理由により要求が変化しやすいことが予想される。
- 設計が複雑である、手間がかかる、あるいはその両方である。
- 開発チームがそのアプリケーション分野をよく知らない。
- プロジェクトのリスクが高い。
- 長期的な予測は重要でない。
- 要求、設計、コードを下流で変更しても、安価な可能性がある。
ソフトウェア自体については、逐次型よりも反復型の方がはるかに効果的だろう。反復型ならば、必要に応じて公式と非公式を使い分けたり、完成度を加減したりしながら、プロジェクトに適した準備を整えることができる。
Code Complete 第 2 版 - 3.2.2 反復型か、逐次型か（p.41）
アジャイル開発とはリリース駆動型開発？
こんな感じで今一つモヤモヤした感情が晴れない状態でいろいろな記事を読んでいたのですが、一つ興味深い指摘をしている記事を見つけました。
RUPのような反復開発は、アーキテクチャや品質を作り込むためにプロセスを反復する。しかし、1回の反復だけではリリースできるレベルまで開発できないし、リリースは普通最後の1回だけだから、結局ウォーターフォール開発と何ら変わらない感覚がある。
アジャイル開発は漸進型開発であり、小規模リリースを基本とする。1回のイテレーションでリリース出来る機能を実装しながら、小刻みにリリースしていく。だから、アジャイル開発ではリリース計画やイテレーション計画を作るのが非常に重要になってくる。その意味では、アジャイル開発はリリース計画駆動と言ってもいい。
繰り返し開発の罠: プログラマの思索
改めて アジャイル宣言の背後にある原則 を見直してみると、確かに「短い間隔でリリースする」と言う事が明示されていました。
アジャイル宣言の背後にある原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
「アジャイル開発」以前の開発手法については、（バグ修正、要求・仕様変更等があるので、結果的に複数回リリースする事になるが）基本的にはリリースは 1 回で終わったらいいなぁ〜と言うプロジェクト（契約）も多いと思われる中で、最初から「短期間でのリリースを繰り返す事」を前提としている点については、確かに明らかな差異かもしれません。
「反復型開発」と「アジャイル開発」は（少なくとも細部に関しては）異なる概念だと言う事は分かったのですが、どこが違うのかについては私自身ではまだまだ言葉でうまく言い表せられないので、他人に説明する際には注意しないとな……と思います。
*1:正確には、本書の中では「反復型手法」あるいは「反復型プロジェクト」と言う表記でした。
