「コンセプト・アウト/デマンド・イン」型でソフトウエアを開発するなら,開発の進め方についても考慮する必要がある。仮に,ユーザーが「こんな製品・機能がほしい」と言ってから1~2年後に製品をリリース/バージョンアップしたとしても,ユーザーは納得しないだろう。市場の反応も冷めたものになるはずだ。

 では,「コンセプト・アウト/デマンド・イン」型の開発に有効なソフトウエア開発手法とは何だろうか?

 コンセプト・アウト/デマンド・イン型の開発プロジェクトには,以下のような特徴がある。

(1)要求がめまぐるしく変わる(3カ月前の要求が今も有効かどうか,疑わしい)。
(2)リリースごとのテーマと締め切りを守ることが最優先。スコープ(機能)は削ってもよい。
(3)開発は少数精鋭。チームは10名以下であることが多い。
(4)若い企業文化(モチベーションと成功意欲が高い)。
(5)継続的にバージョンアップを繰り返す(必然的なイテレーション型)。
(6)コミュニティからのフィードバックを得るとともに,開発の進ちょく状況などをトランスペアレントに外に発信。
(7)チームの生産性のためには,ソフトウエア資産の「再利用性」ではなく「保守性」が重要。

 これらの特徴を生かすには,アジャイル型で開発を行うのが最適だろう。XP(Extreme Programming),SCRUM,Crystal Clear,APM(Agile Project Management)など,現在はアジャイル型の開発手法が日本でも数多く紹介されている。

 どのアジャイル開発においても,「タイム・ボックス」(時間枠)を区切って開発を繰り返すのが基本だ(図1[拡大表示])。タイム・ボックスには,ソフトをリリースする単位である大タイム・ボックスと,開発を繰り返す単位である小タイム・ボックスの2つがある。後者をイテレーションと呼び,通常1週間~1カ月である。


図1 アジャイル開発の進め方
「小タイム・ボックス」ごとにフィーチャ・リストに定めた機能を実装・テストし,「大タイム・ボックス」ごとにソフトをリリースする。小タイム・ボックスの長さは1週間~1カ月。

[画像のクリックで拡大表示]

 各タイム・ボックスには,テーマと実装すべき機能リスト(フィーチャ・リスト)を定め,その時間枠の中で分析・設計から実装,テストまでを行う。作業が間に合わない場合でもタイム・ボックス自体の延長はしない。その代わり,実装する機能を減らす(先送りする)ことは許される。

 図1では,第1リリース(リリース1)の前に準備イテレーションを配置し,そこでアーキテクチャのバージョン0とテストとなるフィーチャを実装している。第1リリースは4つのイテレーションからなる。第1リリースにはテーマが決められており,そのテーマをブレークダウンすることで,それぞれのイテレーションのテーマ(テーマ1.1~1.4)が決まる。以後,第1リリースに向けて,イテレーションごとにアーキテクチャの確立とフィーチャの実装を進めていく。

 各イテレーションのフィーチャ・リストは,最初はあくまで目安だ。それぞれのイテレーションを開始する際に,その時点でのビジネス上の要求とプロジェクト・チームの生産性を考慮して,フィーチャ・リストを追加/削除する。

 そしてタイム・ボックスの最後に「ふりかえり」を行い,チームは自分自身を「カイゼン」するとともに,次のイテレーションに向かう。こうすることでチームは,要求の変化を吸収しながら,新しい技術を取り入れたり,より生産性の高い手法を発見したりできるのだ。


平鍋健児

株式会社チェンジビジョン代表。オブジェクト指向分析設計とプロジェクトの「見える化」を実践・推進する舞踏派コンサルタント。UMLとマインドマップを融合させたモデリング・ツールJUDEを開発中。