アジャイル開発の本質は頻繁なリリースにある

アジャイル開発の本質はどこにあるのか？を考えてみた。
ラフなメモ書き。

アジャイル開発の特徴は一体何があるか？

それはタイムボックス形式で小刻みにリリースすること。
それは小規模リリース。
それは設計と開発に区別がないこと。
それは人を重視したプロセス。
それはリーン開発である。
それはテスト駆動開発である。
それは変化を受け入れるプロセスである。

色々言われているけど、本質は何だろうか？
僕は「頻繁にリリースできること」だと思っている。
技術・マネジメント・環境の3つの観点で考えてみた。

【技術】
以前に比べると、「頻繁にリリースできる技術」は確実に進歩している。
XPが生み出した継続的インテグレーション(CI)はその最たるものだ。

CIの本質は、常時リリース可能なコードラインを保持出来る点にある。
trunkをHudsonでワンクリックすれば、すぐにビルド＆デプロイできるのだ。
Cobolやアセンブラの開発が主流の頃に比べると、ワンクリックでリリースできる技術が既にある。
従来は、手作業でビルドして、FTPでサーバーにアップして、サーバーを再起動する手間がかかっていた。

そのコードラインの品質を保持するための技術が、TDDでありリファクタリング。
頻繁にリリースするために、コードラインにたくさんの手が入り、強固なルールが無ければすぐに品質は劣化する。
だから、テスト駆動で開発するし、継続的にリファクタリングしてソースの品質を維持する。

昨今は特にソフトウェア構成管理(SCM)の技術革新の影響が大きい。
MercurialやGitのような分散バージョン管理のおかげで、ブランチ管理とブランチの品質維持がすごく容易になった。
そのおかげで、コードラインを特定の目的で使い分けることができる。
リリースブランチは障害修正だけで品質重視。
trunkは常時最新の機能を反映しておく。
タスクブランチやトピックブランチは、特定の目的のためにパッチを作るための一時的なブランチ、など。
それらのブランチは分散バージョン管理の優れた自動マージ機能ですぐにtrunkへ安全に反映できる。

だから、勇気を持って新機能を実験できるし、それをすぐにリリースして反映できる仕掛けがある。

【マネジメント・プロセス】
PMBOKもScrumもスコープ管理を重視する。

例えば、PMBOKの品質管理では、スコープ外の品質向上の作業は「金メッキ」と呼ばれて、けなされる。
Scrumでは、バックログを常に保守してリリース予定の機能を優先順位付けするし、スプリント計画を実行している間は、外部からチームへ割り込みの作業を許さない仕掛けがある。

Scrumの言う日次Scrumは、PFの朝会のようなものだ。
日次Scrumは、メンバーに自身の役割を自覚させるだけでなく、スプリントのゴールを共有し、スコープから外れないように意識づける仕掛けだ。
そして、日々の問題はScrumマスターが解決するように動く。

アジャイル開発は、繰り返し開発の一つ。
繰り返し開発には、漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)の2種類があると思う。
漸進型開発が反復型開発よりも優れているのは、頻繁なリリースがあるために、自然にスコープに制約がかかること。
リリースが定期的にあるため、イテレーションを超えるスコープは実現できない仕掛けがある。
昔も今も、リリース作業は大変だから。

RUPのような反復型開発は、内部で繰り返し開発があるものの、最後の1回しかリリースしない。
だから、スコープがどんどん増えてしまい、WF型開発と何ら変わらない。
よくある失敗例は、設計工程だけ、開発工程だけ、などのように、工程ごとの繰り返し開発を実践して、スコープが発散してしまい、リリースには程遠い品質になってしまうこと。
「頻繁にリリースする」という小規模リリースの制約条件が、スコープの発散にたがをはめるのだ。

アジャイル開発を運用すると、当初見積もったタスクよりも作業は増える。
実際、Redmineの1個のバージョンに、WBSから落としたタスクを一括インポートするものの、バグが出たり、設計漏れが出たり、予期していない技術リスクが判明したり、当初予定しなかったチケットがどんどん増える。
だから、予定通りにリリースするには、チケットの整合性を図りながら、タスクを削ってリリースする時が多い。

これが本来のマネジメントなのだ。
そして、これが「変化を抱擁する」ことなのだと思うようになった。

【環境】
とはいえ、アーキテクチャや品質を度外視してリリースできるわけではない。
でも、以前に比べると、ソフトウェアを巡る環境が随分良くなってきている事実もあると思う。

まず、強力なフレームワークが普及したおかげで、アーキテクチャの作り込みに力を注ぐ必要が減った。
例えば、RailsやSeasarがあげられる。
これらのフレームワークのおかげで、アーキテクチャの開発は不要になり、アプリケーション層の業務ロジック実装に専念すればいい。
つまり、頻繁に変わりやすい業務ロジックやUIに注力すればいい開発スタイルが主流になりつつある。

また、安いHWのおかげもある。
HDDは壊れても取り替えた方が安い。
サーバーも安くなったので、スケールアップしやすいし、更には、仮想化技術を使って、開発環境そのものを仮想化できる。
仮想化された開発環境で何度もテストできる。

更に、頻繁にリリース可能なデプロイ環境が普及したこともある。
例えば、Webシステムならば、warファイルをデプロイするだけでリリースが終わる。
組み込み製品でも、例えば携帯電話ですら、ソフトウェアアップデート機能が標準化されたおかげで、アプリケーションを販売後に更新できるし、更にはROMすらもアップデート可能になった。
だから、ある程度の品質を確保できたならば、リリースを優先して、後から細かなバグFixしたソフトをバージョンアップする戦略も取れる。

これらを考えると、アジャイル開発しやすい技術やマネジメント、環境が普及して、より早くリリースできるようになったと思う。
昨今「2週目のアジャイル」「Agile2.0」と呼ばれるブームはそのような背景があるのかもしれない。