アジャイル開発を支援する

アジャイル開発とは（1）

こんにちは、日本ヒューレット・パッカード（以下、HP）の岡崎です。早いもので、この連載も今回が最終回となりました。今回は、今注目を集めているアジャイル開発プロセスをHPのソフトウエア・ソリューションがいかにサポートするかについて説明します。

今、従来のウォーターフォール形式の開発アプローチに代わるもの、あるいは補完するものとして、アジャイル開発アプローチが注目を集めています。では、アジャイル開発は、これまでのやり方とどこが違うのでしょうか。

端的にいうと、従来の開発は「プロセスに依存したアプローチ」と言えます。

従来の開発プロジェクトでは、開発メンバーの個々のスキルや関係に多少問題があっても、プロセスがうまく回っている限り、大きな失敗なく完了します。一方で、うまく回すためにプロセスは単純化され、要件定義、設計、開発、テストというようにフェーズごとにサイロ化されます。

例えば、要件定義のフェーズでは、要件定義にかかわるメンバーだけが要件定義の作業を集中的に行います。フェーズから次のフェーズに移る際にレビューが行われますが、いったんレビューを完了したら前のフェーズの成果物は正しいもの、十分なものとして次のフェーズで使われます。

このため、フェーズごとに大量の文書が成果物として作られます。このようなやり方は、開発を外部委託するケースと非常によくマッチし、また、個人のスキルによらないところから、メンバーが多い大規模開発に適していると言えます。

アジャイル開発とは（2）

これに対してアジャイル開発は、「メンバーの協調に依存したアプローチ」と考えられます。

開発メンバーには、設計者とかプログラマとかテスト担当とかいった厳密な役割はなく、全員が協力して開発を進めます。

最終的な開発スコープをあらかじめ決定して要件を全部洗い出し、そのあとに集中的に開発する、というスタイルではなく、比較的短い開発サイクルを何度か回しながら、サイクルごとに要件を決定し、実装して、テストします。

サイクルの終わりには、成果物として、必ず機能するソフトウエアを作成します。このため、サイクルごとに実装される要件は、サイクルの初めに優先度と工数を考慮して、柔軟に決定されます。メンバー全員の協力が成功のカギとなることから、比較的小規模な開発で効果を発揮すると考えられています。

XPとスクラムが有名

「アジャイル」という言葉は、メンバーの協調に基づいた、サイクルの繰り返しによる開発アプローチを総称するものであり、これを実現する具体的な方法については、いくつかのプラクティスが考えられてきました。中でも有名なのは、エクストリーム・プログラミング（以下、XP）とスクラムです。

本記事は、アジャイル開発の詳細を説明するものではありませんが、話の都合上、この2つについて簡単に説明します。

1つ目のXPは、アジャイル開発の技術的な側面に注目したプラクティスです。

XPでの開発は、最大3カ月程度の比較的短いリリースを何度か繰り返すことにより、行われます。1つのリリース内では、何回かのサイクルを繰り返します。このサイクルは、「イタレーション（反復）」と呼ばれます。

イタレーションごとに、実装する要件（「ユーザー・ストーリ」と呼ばれます）を選定し、工数を評価し、プログラム作成し、テストを行って、イタレーションの終わりには、機能するソフトウエアを作り出します。この過程では、テスト駆動開発やペア・プログラミングといったやり方が使われます。

これに対して2つ目のスクラムは、プロセスに注目したプラクティスであり、技術的な詳細についてあまり定めていません。

スクラムでは、開発はスクラム・チームと呼ばれる10名程度のグループにより行われます。スクラム・チームには、スクラム・マスターと呼ばれるリーダーと、要件をよく知る製品オーナーが含まれますが、そのほかのメンバーの役割は流動的です。

チームは、「スプリント」と呼ばれるサイクルごとに、実装する要件（「バック・ログ」と呼ばれます）を選択します。そして日次スクラム・ミーティングというミーティングを行って、全員で進ちょくを管理しながら開発をすすめ、スプリントの終わりには、機能するソフトウエアをデモできるようにします。