アジャイル開発は構成管理ツールが必須条件だ

「Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」を何度も読み直している。
下記のBlogも読みながら、ソフトウェア構成管理について考えたことを書く。

【元ネタ】
ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー

ソフトウェア構成管理方針の策定（変更管理編）

バージョン管理とソフトウェア構成管理の関係

【1】アジャイル開発は変更管理プロセスに強い

　変更管理プロセスが弱いとトラブルが多いという話を聞いたことがある。

　ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
　例えば、OSやソフトのバージョンアップなど。

　つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
　このギャップがトラブルだ、と。

　だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
　むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
　そこに矛盾がある、と。

　ここで、XPはイテレーション単位にバージョンアップしていく開発スタイル。
　チケット駆動開発は、チケットをバージョン単位にグループ化して小刻みにリリースする開発スタイル。

　チケット駆動開発もXPもそうだし、アジャイル開発は変更管理プロセスに強いフレームワークなのだ。

　アジャイル開発の利点は、イテレーションのサイズを短くできれば、頻繁な仕様変更に対応できることもあげられる。
　頻繁な仕様変更に耐えうる開発体制があれば、仕様変更を受けることで顧客満足度をUpする戦略も意図的に選択できる。

　ソフトウェア開発は、変更管理プロセスが鍵だと思う。

【2】変更管理プロセスに弱いチームは、ソフトウェア開発力が弱い

　ソフトウェア開発の殆どの作業は変更管理であると言って良い。
　だが、変更管理プロセスは諸刃の剣だ。
　
　Windowsパソコンのように、ソフトウェア環境は、そのハードやOSのVerUPが頻繁にある。
　又、セキュリティパッチなど、むしろバージョンアップしなければいけない状況は多い。
　しかし、VerUpはトラブルの源になりやすい。
　
　ソフトウェア開発では、いわゆる仕様変更や障害対応で変更管理プロセスが必要になる。
　障害対応は、バグが原因だから、ソフト会社に責任がある。
　特に運用保守では、バグ修正にスピード感がないと、顧客の業務システムが止まるだけでなく、社会的責任も発生する。
　
　仕様変更は、変更要求(RFC)を元に設計して、機能を修正したり追加していく。
　そもそも、変更要求(RFC)の発生源は顧客なので、お金を取りやすい状況にある。
　
　しかし、顧客と変更要求をレビューする技術力も時間もないまま、五月雨式に開発して、テスト工程で仕様変更が発生する時が多い。
　そうなると、仕様変更は本来、顧客の要望から発生するのに、ソフト会社の技術力の低さにすりかえられてしまう。
　つまり、変更管理プロセスが弱いSIerは、ソフトウェア開発力が弱いし、ソフトウェア・ビジネスが弱いことになる。

　ここに、変更管理の難しさがあると思う。
　そもそも、要求とは、顧客と開発チームが要件や仕様で合意を得るプロセスも含んでいる。
　つまり、変更管理プロセスが弱いSIerは、ステークホルダー間で合意を得るマネジメント力が弱いのだ。

　変更管理プロセスが強いSIerは、顧客の合意が得られるように、要件を、自分たちが持つ技術力や工数、機能の優先順位の観点から分割したり、代替案を出して、顧客が選択しやすいように誘導する。
　変更管理プロセスはマネジメント要素だけでなく、技術力も必要としている。

【3】アジャイル開発は構成管理を必要とする

　ウォーターフォール型開発よりもアジャイル開発が優れているし、プログラマなら誰でもアジャイル開発したいと思っている。
　でも、実際の現場は、10年前と比べて、技術が変わっただけで、開発プロセスはそんなに変わってない。
　
　僕は、Redmineを運用してみて初めて、XPの計画ゲームはこういう意味だったのか！と気付いた。
　そして、アジャイル開発は決して、小さなウォーターフォール型開発の繰り返しではないことを知った。
　更に、アジャイル開発は広義の意味でのソフトウェア構成管理(SCM)が必須であることを肌で感じた。
　
　「ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 」では、短いサイクルのシステム開発は構成管理ツールを必要としている事実を下記のように記述している。

ツールの優先事項は、特定の作業の効率をサポートすることから、作業間の効率的な切り替えをサポートすることに移行しています。

アジャイル開発はウォーターフォール開発の縮小版ではなく、分析とテスト、設計とテスト、およびコーディングとテストの実行を結び付け、実装中に得た情報に基づいてその後の分析、設計、および実装に関する決定を迅速に下すことができるフィードバック ループを構築します。

(中略)

アジャイル開発を実現するツールの役割は、それだけにとどまりません。 以前、量的な変化が一桁分発生すると、質的な変化が 1 つ発生することを教わりました。そのため、時速 10 km の馬が時速 100 km の車に変わったことは、単に移動速度が向上しただけでなく、(最終的に) 移動に対する人々の考え方を変え、移動性が生活の中で果たす役割を変えました。

1 年に 1 回の展開が 1 か月に 1 回行われるようになり、それが 1 日 1 回になった場合、量的な変化は 100 倍になります。つまり、アジャイル ソフトウェア開発では質的な違いが生じることになります。『テスト駆動開発入門』に私が書いた 1 つの "違い" は、プログラマが自分の作業の質に責任を負う必要があることです。それには、効率良くツールをサポートし、考え方を変える必要があります。開発者が記述したテストによってもたらされる個々の透明性は、チームの透明性を向上させるために不可欠です。
アジャイル ソフトウェア開発では、チームの透明性が最も重要な要素になります。作業計画の細部が毎日変更される場合、どの作業者にも、他の作業者が行っている作業を把握する方法が必要になります。

ウォーターフォール型開発は、最後の1回しかリリースしない。
アジャイル開発は、Scrumなら4週間に1回、FDDなら2週間に1回、ベータ版を作っている最中なら1日～1週間単位で小刻みにリリースしていく。

リリース間隔が短くなるほど、従来の開発スタイルが通用しなくなり、開発プロセスの質が劇的に変わらないと対応できない。

上記では更に、構成管理ツールが、開発メンバー、開発チームの意識を大きく変えることも示唆している。

僕は、チケット駆動開発によって、開発者が積極的に行動し始める事実を知った。
実際、開発者は毎朝、管理者の指示が無くとも、Redmineのロードマップやチケット一覧を見て、自分のチケットを探して作業している。
又、システムにバグを見つけたら、自発的にバグの内容を記述してチケット登録するようになった。

だから、チケット駆動開発とプロジェクト・ファシリテーションには関連があるのではないか、と最近思っている。

「構成管理を導入すると、チーム内のコミュニケーションが活性化する」事例はいくらでも探せるように思う。

しかし、実際の多くの現場では、ソース管理していても、ビルド/リリースのプロセスに問題があって、任意のバージョンのシステムをビルドで再現できなかったりする。

本番リリース後の障害対応の作業履歴をきちんと残していないために、引継ぎ後に火を噴いたり、いつまで経ってもバグ発生が落ち着かず、システムが不安定だったりする。

アジャイル開発を実践するには、ソフトウェア構成管理のインフラが必須条件だ。