日経コンピュータ 2002年10月21日号、56ページより

「アジャイル・ソフトウエア開発」は、いま最も話題を呼んでいるソフトウエア開発手法だ。ドッグイヤーと叫ばれ出してから久しい今日、「完全な要件定義」、「完全な設計」、「完全な実装」を求める従来のソフトウエア開発手法は、もはや無力である。経営スピードにマッチした新たな手法が求められている。アジャイル開発は、ソフトに対する要求の変化を受け入れ、同時に“人間”を重視することで、ユーザーに価値をもたらすソフトを“超高速”で実現することを狙う。ここでは代表的な6種類のアジャイル開発手法の概要を紹介する。

本稿を含む特集「企業情報システムの再生に挑む【システム構築編】:
経営スピードに負けないシステム作り」
のページはこちら

 アジャイル・ソフトウエア開発(以下、アジャイル開発)とは、「ユーザー(顧客)に価値をもたらし、かつ動作が保証されたソフトを超高速で実現する」という目標を持つ複数のソフトウエア開発手法 注16)の総称である。日本で最もよく知られているのは、エクストリーム・プログラミング(XP)だろう。ほかにも表に示すような手法がある 注17)

 アジャイル開発手法は、長いもので10年以上にわたる利用実績を持つ。(1)余計な成果物や手順を排除した“軽い”手法を目指す、(2)動くソフトをできるだけ早く顧客に提供(リリース)する、(3)ソフトに対する要求の変化を可能な限り受け入れる、(4)個人のモチベーションやチーム内のコミュニケーションといった“人間系”を重視し、チームの生産性を最大限に高めることを狙う、(5)開発チームに必ずユーザーを参加させる、などの共通点がある。

 以下では、代表的な六つのアジャイル開発手法の概要を説明する。誌面の都合で、具体的な実践方法までは言及していない。記事の最後に掲載した参考文献1)~8)や表のURLを参照してほしい。

名称 提唱者 概要 URL
XP ケント・ベック、ウォード・カニンガム、ロン・ジェフリーズ 現在、日本で最も知られているアジャイル手法。コーディングやテスト、再設計を重視。12のプラクティス(実践項目)を明示 www.extreme
programming.org
クリスタル アリスター・コーバーン 「インクリメントは4カ月以内」、「インクリメント後に反省会を開く」の2点が基本プロセス。「クリア」、「オレンジ」など複数を用意 www.crystal
methodologies.org
スクラム ケン・シュウェイバー、マイク・ビードル チームの自己責任とプライドを信頼して、高い生産性を目指す。30日間のイテレーション(スプリント)を繰り返す www.control
chaos.com
DSDM アリー・バン・ベネカムなど 「初めから完全には構築できない」という前提に立った探索的な開発手法。RADをベースとする。プロトタイプを多用 www.dsdm.org
FDD ピーター・コード、エリック・レフェーブル、ジェフ・デ・ル 目に見える成果を2週間ごとにリリースすることが目的。比較的な大規模なプロジェクトにも適用できる www.nebulon.
com/fdd/
ASD ジム・ハイスミス RADを発展させた手法。綿密に計画を立てる代わりに、短期の計画(思索、協調、学習)を用いて開発する www.adaptivesd.
com/learn.html
ASD:Adaptive Software Development
DSDM:Dynamic Systems Development Method
FDD:Feature-Driven Development
RAD:Rapid Application Development
XP:eXtreme Programming
表●主なアジャイル・ソフトウエア開発手法の概要

200人規模の開発にも適応できる

 まず、それぞれのアジャイル開発手法がどのようなプロジェクトに向いているかを概観しておこう。図7[拡大表示]の縦軸はシステムの重要度を表す 注18)。上に行くほど、システムによって引き起こされる可能性のあるダメージが増大する。横軸はプロジェクトに参加する要員数を示す。

図7●アジャイル開発手法が適するシステムの規模と重要度

 XPは話題を集める一方で、「大規模プロジェクトへの適用は不可能」というイメージを植え付けてしまった。しかし図7を見ると、アジャイル開発はごく小規模の開発から最大200人規模の開発まで、広範囲なプロジェクトで適用できることがわかる 注19)

 アジャイル開発の各手法は、「その手順に従えばよい」わけではない。アジャイル開発手法の中から自分のプロジェクトに合いそうなものを選定し、その手法に追加・修整などのチューニングを施してから適用することが前提となる。複数の手法を併用してもよい 注20)

XP
12種類の実践項目を明示

 では、具体的にアジャイル開発手法を説明していく。後に説明する手法ほど、適用可能なプロジェクト規模が大きくなるととらえてほしい。

 XPでは開発リスクを早期に軽減することに主眼をおき,少数のプログラマが同じ部屋で非常に短いサイクルで開発する。顧客(ユーザー)も常駐し、業務知識を教える。コーディングとテスト、さらに初期設計よりも再設計を重視する 注21)。「12のプラクティス(実践項目)」を明確に示していることも特徴である。

図8●エクストリーム・プログラミング(XP)の流れ

 XPの手順を図8[拡大表示]に示す。1回のイテレーション(開発サイクル)で開発する機能(ストーリー)をユーザーが選び、そのストーリーをプログラムとして実現していくという作業を繰り返す。1回のイテレーションの期間は1週間から4週間。一つのストーリーを実現するのにイテレーションを2回から5回繰り返す。必要に応じて、ストーリーを随時見直すこともできる。

 開発チームは毎日、手短にスタンドアップ・ミーティング(立席会議)を開く。当然、ここにはユーザーも参加する。この会議で進捗や障害を報告する。その後、プログラマは毎日、異なる人とペアと組んで開発する。これは「ペア・プログラミング」というプラクティスとして、よく知られている。開発者同士のコミュニケーションを密にすることが狙いだ。

 イテレーションの最後に、動作可能なテスト済みコードをユーザーがテストする。パスすれば、そのコードを「リリース」する。早ければ2週間で、ユーザーは動作するソフトを入手できる。

クリスタル
基本ルールは二つだけ

 クリスタルは、XPに比べるとはるかに規律が緩いアジャイル開発手法である。ベースとなる規律は、「4カ月以内のインクリメンタルな開発をする」 注22)、「各インクリメント後に反省会(レビュー)を開く」の二つしかない。クリスタルでは、このレビューを開発プロセスを改善する機会として重視している。

 クリスタルによる開発プロジェクトは、動作可能なコードを頻繁に開発する。メンバー同士が密にコミュニケーションすることで中間成果物を削減しつつ、発生する問題を改善しながら作業を進める。コミュニケーションを重視するため、クリスタルは同じ場所にいるチームを対象としている。

 クリスタルは、プロジェクトの種類に対応した「ファミリ」と呼ぶ複数の開発手法で構成する。小規模開発向けの「クリスタル・クリア」は、6人までのメンバーが一つのチームを組み、同じオフィスまたは隣接するオフィスで重要度の低いシステムを開発するための手法。提唱者のアリスター・コーバーン氏によれば、この手法は図7[拡大表示]における「D6(縦軸がD=金銭的影響の小さいシステム、横軸が6 =参加要員は6人規模)」カテゴリのプロジェクトに向く。「拡張クリスタル・クリア」は、コミュニケーションと検証方法に注意を払うことで、クリスタル・クリアを「D10」または「E8」カテゴリのプロジェクトにも適用できるように拡張したものだ。

 「クリスタル・オレンジ」は「D40」カテゴリ、すなわち10~40人までのメンバーが同じ拠点で作業する、重要度の高いシステム開発に向く。トータルの開発期間は1~2年程度が目安となる 注23)

 クリスタルの各ファミリでは、プロジェクトを進めるうえで必要になる標準的なポリシーや成果物、メンバーの役割などを規定している。クリスタル・クリアなら、「ソフトは2~3カ月ごとに、インクリメンタルかつ定期的に納品される」、「ユーザーが直接関与する」、などのポリシーがある。

 クリスタルを用いる際は、前述のようにプロジェクトに応じてチューニングする必要がある。チューニングは「従来の作業習慣をどのように維持するか」ではなく、例えば「20人が共同作業するための方法とは何か」を考えて進める。

スクラム
チーム単位の高生産性を目指す
図9●スクラムの流れ

 「スクラムを組んでチームの勝利に向かって進む」。スクラムの目標は、まさにこれだ。チームの自己責任とプライドを信頼して、高生産性を目指すアジャイル開発手法である。XPはどちらかというとプログラマ寄りだが、スクラムはプロジェクトマネジメントの側面を重視する。

 スクラムでは、スプリント(短距離走)と呼ぶイテレーションを繰り返すことでソフトを開発していく(図9[拡大表示])。スプリントは30日単位で設定する。スプリントの期間中は要求の変更を認めない。チームが一つの目標に向かってまっしぐらに進めるようにするのが狙いだ。

 スクラムによる開発プロジェクトでは、まず「製品バックログ」を決める。製品バックログとは、システムに含むべき機能や特徴、技術、さらに実現のための解決策をリストアップしたものだ。続くスプリント計画ミーティングで、製品バックログを基に、スプリント中に実行すべき作業項目(タスク)を列挙する。これを「スプリント・バックログ」と呼ぶ。スプリントの目標は、スプリント・バックログに書かれたタスクをすべて実現することである。

 スプリントの最中、チームは毎日決まった時間にミーティングを開く。最大30分(15分を推奨)で「昨日何をしたか」、「今日何をするか」、「障害は何か」だけを確認する。そして障害を解決しながら開発を進める(日次スクラム)。スプリント終了後に実行可能なソフト(製品インクリメントと呼ぶ)をリリースする。製品インクリメントをスプリント計画ミーティングで評価し、作業の継続の可否を判断する。さらにチームが開発した製品インクリメントに基づいて製品バックログを見直す、という作業を繰り返す。

DSDM
プロトタイプを多用

 DSDM(Dynamic Systems Development Method)は、RAD(高速アプリケーション開発)をベースとするアジャイル手法である(図10[拡大表示])。RADにはあいまいな部分が多いという問題点を解決するため、実践すべき項目を明確にした。結果として、アジャイル開発にもカテゴライズできる手法となった。

図10●DSDM(Dynamic Systems Development Method)の流れ

 DSDMは「システムを初めから完全に構築することはできない」という前提に立った、探索的な開発手法である。「現在のステップでは、次のステップに進むために十分なことだけを完了させる」という方針のもと、プロトタイプを多用してコミュニケーションを密にしつつ、イテレーションを繰り返しながら開発を進める。納期はタイムボックス(イテレーションをいつ打ち切るかを示す)を使用することによって制御する。

 DSDMの中心を成すのは機能モデル、設計/構築、実装という三つのイテレーションである。その前段階として、フィージビリティ・スタディとビジネス・スタディを実施する。テストは機能モデルのイテレーションと設計/構築のイテレーションの一部分とみなしている。

 フィージビリティ・スタディでは、「DSDMがそのプロジェクトのための正しい手法かどうか」を評価したり、「システムをリリースするために必要な技術は何か」を決める。数週間以内に作業を終える。ビジネス・スタディでは、今回のプロジェクトによって影響を受けるビジネス・プロセスと、そのプロセスに関する情報の必要性を明確にする。

 機能モデル・フェーズでは、ビジネス・スタディで識別された抽象度の高い処理要件と情報要件を洗練し、モデル化する。設計/構築フェーズでは、それらに基づいて設計、構築を進める。機能モデルのイテレーションと設計/構築イテレーションではそれぞれ、(1)開発する機能の識別、(2)承認、(3)製品の開発、(4)正しく開発されたかの検証(文書のレビュー、プロトタイプ、システムの単体テスト)という四つの作業を実施する。実装フェーズでは、開発環境から運用環境に移行する。プロジェクトに参加しなかったユーザーの教育もここに含まれる。図10のように、開発は必要に応じて以前のフェーズに立ち戻りながら進める。

FDD
大規模開発への適用も可能

 FDD(Feature-Driven Development:ユーザー機能主導型の開発)は、目に見える成果を2週間ごとにリリースすることを目的とする。大規模開発にも適用できる点が特徴で、海外では250人が参加し、18カ月以上にわたった大規模プロジェクトへの適用実績もあるという。国内でも適用事例がある。

 FDDによる開発は,ユーザー機能(フィーチャ)の単位で進める。ユーザー機能は、顧客に実用的な価値をもたらす小さなかたまりのことで、XPのストーリーに類似している。そのユーザー機能を、チーム内で最も生産性が高いメンバー、すなわちチーフ・プログラマに割り当てる。チーフ・プログラマは、個々のユーザー機能を開発するために必要なクラス担当者(あるクラスの設計と実装に責任を持つ)を選定し、ユーザー機能チームを編成する。このチームは1~2週間だけ存続する。クラス担当者は、同時に一つ以上のユーザー機能チームで作業する。

 FDDの提唱者の一人であるピーター・コード氏は、「並行開発できるチーム数はチーフ・プログラマの数と一致する」としている。チームの要員数は2~9人が目安である。チーフ・プログラマの数をある程度確保すれば、FDDを大規模プロジェクトに適用できることになる 注24)

図11●FDD(Feature-Driven Development)の流れ

 FDDによる開発の流れを図11[拡大表示]に示す。「全体モデル構築」では、システム化する範囲における、初期段階の重要点だけを抜粋した抽象度の高いモデルなどを作成する。「ユーザー機能リスト作成」では、ユーザー機能を明確にし、優先度をつけたリストを作成する。「ユーザー機能単位計画」では、ユーザー機能リストにしたがって、ユーザー機能単位で設計・構築するためのマイルストーン(プロジェクトの節目となる期日)を確立する。

 「ユーザー機能単位設計」では、ユーザー機能単位ごとにクラスを識別し、シーケンス図 注25)を作成し、クラスとメソッドの概要を記述する。「ユーザー機能単位構築」では、ユーザー機能の実現に必要なクラスとメソッドを構築し、クラス単位のテストを実行する。ユーザー機能を実現するクラスをすべて作成したら、次のユーザー機能に移る。

ASD
思索~協調~学習を繰り返す

 最後に紹介するASD(Adaptive Software Development)はDSDMと同様、RADを発展させた手法である。「思索」、「協調」、「学習」という3段階のイテレーションを繰り返すことで、開発を進める(図12[拡大表示])。システム仕様の詳細は、実際に作ってみないとわからない部分も少なくない。また、システムに対する要求が急に変わるといった不測の事態も起こり得る。これらに対応できるようにするのが狙いだ。

図12●ASD(Adaptive Software Development)の流れ

 思索では、このイテレーションでどのような機能を開発するかを検討する。言い換えると、どのような知識が必要かを調査する。ここでは二つの作業を実施する。一つは「プロジェクト開始」。プロジェクト目的の設定、プロジェクト組織の編成、最初の規模と範囲の見積もりといった作業を2~5日で集中して実行する。もう一つは「適応サイクル計画」。プロジェクト全体の範囲と機能要件を見積もり、イテレーションの回数と各イテレーションのタイムボックスを決める。イテレーションの狙いは、ユーザーの目に見える実際の機能群をリリースすることである。開発者とユーザーは、機能を各イテレーションに割り当てる。

 協調は、思索フェーズで示された機能を満たすための知識を持ち寄る共同作業である。思索で決めたイテレーション計画に沿って開発を進める(「並行機能開発」と呼ぶ)。イテレーションでは、日次(または、より短い期間)で機能をリリースし、製品を開発チームに“見える”状態にする。機能開発時にテストする。

 学習では、イテレーションの結果をレビューしたうえで、理解できていなかった点を明らかにし、次のイテレーションに対して準備をする。「品質レビュー」で、並行機能開発の成果をレビューし、適応サイクル計画に戻るか、最終品質保証およびリリースに進むかを決定する。「最終品質保証およびリリース」で最終成果物をテストして、製品としてリリースするか、適応サイクル計画に戻すかどうかを決定する。


注16) 本稿でいうソフト開発手法は、「ソフト開発プロセス(手順)」と呼ばれることが多い。ここでは表現を平易にするために、「開発手法」に統一した。

注17) このほかに、XPとスクラムを組み合わせた「XBreed」や、1980年代の製造業をモデルにした「LD(Lean Development)」、米ラショナルソフトウェアの繰り返し型開発手法であるRUP(Rational Unified Process)をアジャイルにした「dX」などのアジャイル開発手法がある。

注18) アジャイル開発手法「クリスタル」の提唱者であるアリスター・コーバーン氏は、クリア、イエロー、オレンジ、レッド、マジェンダ、ブルー、バイオレットという結晶(クリスタル)のメタファーを用いて手法を分類している。ASDは適用範囲を示していないので図には載せていない。

注19) 現状のアジャイル開発手法は、図7の縦軸のL(人間の生命を左右するシステム)のプロジェクトまではカバーしていない。

注20) これは一見面倒に思えるかもしれない。だが、異なるプロジェクトに同じ開発手法を適用できると考えるほうがむしろ不自然ではないだろうか。

注21) 再設計とは、プログラムの外部仕様(入力と出力)を変えずに内部構造を改善すること。XPのプラクティスでは「リファクタリング」と呼ぶ。

注22) インクリメントは、開発すべき対象(タスク)をいくつかに分割した単位。その単位ごとに漸進的に開発していくことを「インクリメンタルな開発」と呼ぶ。

注23) ほかに、クリスタル・オレンジをWebシステム開発プロジェクト向けに特化した「クリスタル・オレンジWeb」や、100人規模のプロジェクト向けの「クリスタル・レッド」などがある。

注24) 多人数(多チーム)では、アジャイル開発が強調するコミュニケーションが難しくなるのではないかという疑問を持つ人がいるかもしれない。だが特に問題は生じないと思われる。筆者の知る限り、大規模プロジェクトは独立したサブシステムに分割して開発するのが普通であるからだ。

注25) シーケンス図とはモデリング言語のUMLで使用するダイアグラムの一つで、オブジェクトの動作を時間経過に沿って記述したもの。


[参考文献]
1) ケント・ベック,『XPエクストリーム・プログラミング入門』,ピアソン・エデュケーション,2001年.
2) アリスター・コーバーン,『アジャイルソフトウェア開発』,同上,2002年.
3) Schwaber K,Beedle M,Agile Software Development with Scrum,Prentice Hall,2001(邦訳『アジャイル開発手法スクラム』がピアソン・エデュケーションより近刊予定).
4) Stapleton J,Dsdm Dynamic Systems Development Method: The Method in Practice, Addison-Wesley,1997.
5) ピーター・コードほか,『Javaエンタープライズ・コンポーネント―カラーUMLによるJavaモデリング』,同上,2000年.
6) Highsmith J,Adaptive Software Development: A Collaborative Approach to Managing Complex Systems,Dorset House Publishing, 2000.
7) ケンドール・スコット,『入門統一プロセス』,ピアソン・エデュケーション,2002.
8) ジェームズ・マーチン,『ラピッドアプリケーションデベロプメント』,リックテレコム,1994年.


今野 睦
セルフ 取締役。欧米の最新技術をいち早く紹介することが使命と意欲を燃やす。現在は、アジャイル開発を主とするソフト開発プロセスやコンポーネント・モデリングのコンサルティングに従事。『アジャイルソフトウェア開発シリーズ』(ピアソン・エデュケーション刊)を監訳しつつ、アジャイル開発に関する書き下ろし書籍の発行準備も進めている。著書、訳書は40冊を超える(共著を含む)。オブジェクト指向技術に関するWebサイト(http://member.nifty.ne.jp/akon/)を主催している。