イテレーションはSW開発で何故重要なのか？

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠が思いのほか評価されていたので、理由を再考してみる。
以下、ラフなメモ書き。

【元ネタ】
アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟（1/4）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

チケット駆動開発の本質はバージョン・ファースト: プログラマの思索

牛尾さんが書いているように、イテレーションはAgile開発で最も特徴的な概念だ。
その発想はすぐに理解できるが、実際に実践してみると、そんなに簡単に運用できるものではない。
何故、イテレーションを実際のSW開発に運用するのが難しいのだろうか？

僕の数少ない経験上、イテレーションを実際の開発プロセスに実装した場合、3つの意味を持つと思っている。
一つ目はリリース予定バージョン。
二つ目はマイルストーン。
三つ目はベースライン。
この三つの意味を意識して使っていないから、イテレーションの意味を混同しているのではないか？

【1】イテレーションは構成管理上のリリース予定バージョン。
リリース予定バージョンの意味は、イテレーションがリリースできる最小の単位であることを意味する。
「リリースできる」という意味が重要だ。

WF型開発のように、工程単位に開発していく場合、要件定義が終わっただけ、設計が終わっただけでは、リリースとは呼ばない。
実際のシステムは作られていないし、動かないから、そもそもリリースとは言えない。

だから、Agile開発のようにイテレーションをリリース予定バージョンに対応付けると、小刻みに機能拡張しながら頻繁にリリースする開発スタイルになる。
これがXPの小規模リリースのプラクティスになる。

小規模リリースはインクリメンタル型開発の一番良い具体例。
リリースできる単位まで機能を分割し、イテレーション期間中に要件定義から設計、開発、テスト、デプロイまで全てを行う。
この開発スタイルを実現するために、テスト駆動開発で単体テスト品質は保証し、継続的インテグレーションで常時リリース可能な品質を保つ仕掛けが必要になる。

そのやり方は、アルゴリズムの分割統治やスクリプト言語の編集・実行・確認の手法に似ているから、開発者には馴染みやすい。

そして、プロジェクトマネジメントの観点では、品質・コスト・納期の三角形ではなく、スコープ・コスト・納期の三角形で制御するようになる。
つまり、品質やコストや納期は開発人数やイテレーション期間が固定のため、スコープをいじって調整するしかないことを意味する。
PMBOKではスコープ管理をとても重視するが、Agile開発も同様で、スコープを調整することによって、納期やコストのバランスを取ろうとする。

リリース予定バージョンを細かくたくさん作って運用すると、それらをまとめると、自然にリリース計画(ロードマップ)になる。
SW開発でもっとも重要な計画書はリリース計画だ。
いつ何をリリースするのか、を決めるのがマネージャの仕事なのだ。

そしてリリース済みのバージョンは、リリース履歴(ChangeLog)になる。
リリース履歴を見れば、システムがどのように修正されて成長したのか、一目で分かる。

【2】イテレーションはプロジェクトマネジメント上のマイルストーン。
マイルストーンは例えば、普通は上司へ進捗報告したり、顧客へ要件定義に出かけるタイミングに相当する。

Agile開発は上流工程へ応用しにくいと言われる最大の原因の一つは、イテレーションの概念を要件定義や上流工程の設計プロセスへ上手く運用出来ていないからだと思う。
でも、設計工程であっても、要件定義書や設計書を作るというプロセスがあって、アウトプットが出て、上司や顧客がそれを評価するサイクルになっている。
だから、アウトプットを評価するタイミングをマイルストーンに区切って、イテレーション単位に設計書を作ってブラッシュアップしていくプロセスにすればいい。

但し、そのプロセスの構造はXPの小規模リリースのような漸進型開発ではなく、RUP(Rationl Unified Process)のような反復型開発になっているのに注意しよう。
つまり、システム全体を薄く作りながら、アーキテクチャや品質を高めていくスタイル。
この手法も繰り返し型開発の一例であり、特に上流工程で有効な手法。

でも、反復型開発が漸進型開発よりも難しいのは、システム全体を薄く作りながらブラッシュアップしていく方法を取るので、スコープ管理が難しいこと。
要求の変更や要件漏れ、設計ミスなどを取り込んでいくうちに、スコープがどんどん発散しがち。
反復型開発を運用する時は、モデリング手法などのスキルが高くなければ、同じ作業を何度も繰り返すだけで成果物の品質が上がらないだろう。

逆に言うと、小規模リリースの場合、きちんと動くものをリリースすると言うわけだから、顧客の要望のスコープにも制限をかけることができる。
実際、Scrumでは1ヶ月のスプリント期間中は仕様変更を認めないように、イテレーション期間中はスコープを固定する。

僕がAgile開発を運用した経験上、小規模リリースをベースに、状況に応じて反復型開発を使ってシステムのアーキテクチャや品質を作り込むイテレーションを別途設けるなどすれば、繰り返し型開発を制御できると思う。

【3】イテレーションは変更管理上のベースライン。
ベースラインとは、プロジェクトの成果物に対し、顧客や上司などのステークホルダーが承認した状態を指す。
実際のプロジェクトでは、要求の変更や緊急の障害修正で、設計書やソースが頻繁に変わる。
ベースラインがあるからこそ、修正された成果物とベースラインの差分を計測して、工数や品質をステークホルダーが評価して、リリースするかどうか決定する。

つまり、ベースラインはチェックポイントでもある。
ベースラインがあるから、修正したソースをリリースした直後にトラブルが発生しても、前回のベースラインまで戻せばいい。
いつでも以前のベースラインは再現可能。
ベースラインがあるから、UndoやRedoが可能。

又、ベースラインは単なるタグ付けだけではない。
ステークホルダー全員が承認したというマネジメント上の意思決定も含む。
ダメなプロジェクトは、「ステークホルダーが決める」という行為を理解出来ていない人が多いために、いつまで経っても何も決まらない。

変更管理はそもそも、顧客から変更要求(Request for Change)が発生して、元々確定していた要件や仕様が変更されることを管理するためにある。
そもそもRequest(依頼)なのだから、対応せずに却下する時もありうる。

だから、変更要求がどんな経緯で発生し、どんな議論が生じて、どの仕様で合意したのか、を記録する必要がある。　
当然、開発チームは、工数や技術上の難しさなどの観点から、口を挟む権利はある。

しかし、マネジメントの弱い開発チームは、開発チームの立場の意見を言わずに顧客の言いなりで全てを抱え込んでしまい、合意を取らないまま開発を進めて、リリース間際になって火を噴くことが多いだろう。
あるいは、顧客と合意した内容や履歴をきちんと記録していないために、無駄に時間を浪費したり、他システムへの影響を把握できずに、リリース後に障害を発生させたりするだろう。

バージョンという概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいる。

つまり、イテレーションを開発プロセスに実装すると、単なるリリース単位だけでなく、繰り返し型開発の種類を決定づけたり、マネジメント上の合意を含むことも意味するようになる。

イテレーションは単なるタグ(符丁)ではなく、SW開発の根源に深く関わる概念だと直感している。