特集 .NET開発者のための開発プロセス入門（前編） アジャイル開発を導入できていない.NET開発者たちへ 福井 厚 & 小井土 亨 2004/11/20

Page1 Page2 Page3 Page4

　「あなたのプロジェクトでは、どのような開発プロセスを採用しているだろうか？」

　ご存じのとおり、「開発プロセス」とは、ソフトウェア開発の進め方を定めたものである。一般に開発プロセスでは、開発作業の手順と内容、それを実行すべき担当者の役割、各作業の成果物であるドキュメントやプログラム、さらにそれらの指針となるガイドラインなどが定義されている。

　今日まで、そのような開発プロセスがソフトウェア開発を成功させるために数多く出現してきた。これらは、単に開発プロジェクトの規模や開発言語だけを背景に考え出されたわけではない。当然、当時のソフトウェア開発が置かれていた状況や要求が大きく影響している。

　そこで本稿前半では、開発プロセスの成り立ちから、現在の最新開発プロセスが誕生するまでの経緯を、その時代背景を含めて説明する。このような開発プロセスの歴史を知っておくことは、開発プロセスの本質を理解するうえで役立つはずだ。

　また、数多く出現してきた開発プロセスの中で、「アジャイル開発プロセス」が最近特に注目を集めている。アジャイル開発プロセスとは、現代の複雑で変化しやすいソフトウェアの開発要件に「俊敏かつ柔軟に」（＝アジャイル）対応することを目指した開発プロセスである。

　しかしアジャイル開発プロセスに関する情報は、Javaに関するものが多く.NETに関するものは最近少し出てきたくらいでまだまだ少ない。もしかしたら読者の中には、「アジャイルは、.NET開発には関係がない」と思っている人もいるかもしれない。実際、.NETの開発プロジェクトへアジャイル開発プロセスを導入することはかなり難しいというのも事実だ。

　後半では、なぜアジャイル開発プロセスを現実の.NET開発プロジェクトに適用するのが難しいのかについて解説し、その壁を乗り越えてアジャイル開発を徐々に導入していくための秘策「ローカル・ライトウェイト開発プロセス」について解説する。

アジャイル開発プロセスが誕生するまで

　それではまず、アジャイル開発誕生までの開発プロセスの歴史を振り返ってみよう。

■開発プロセス誕生前夜

　日本でコンピュータが「電子計算機」と呼ばれていた時代、ソフトウェア開発における作業手順は非常に単純であった。この時代のソフトウェアは、コンピュータが一番得意とする「計算作業」を受け持っていたからだ。具体的には、以下のような作業である。

1. 大砲の軌道計算
   　風向きや相手の位置など刻々と変わる条件を計算式を用いて計算し、打ち出した大砲がどこに落ちるかを割り出す。
2. 給与計算
   　給与に関する多くの数値を基に、やや複雑な計算を行う。処理対象の数も多い。

　これらの計算は、確かに人が行うことも可能だ。しかし、それでは時間がかかるし、特に人間は計算を間違えやすい。これらの計算を間違えると、大きな問題となってしまうことは容易に想像できる。このように、当時のコンピュータは正確で高速な計算を要求される分野を主に担当していたのである。もちろんこういった計算作業は、いまなおコンピュータが最も得意とする分野である。

　当時の日本におけるコンピュータの普及率は低く、その数は企業単位ではなく地区単位でも数えられるほどだった。当然、コンピュータの価格も維持費も高く、時間当たりの稼働単価は、ほとんどの会社で、社長の所得より高額であった。ソフトウェア開発に与えられた課題は、コンピュータと相対する作業時間を短くすることであった（端末の使用料が非常に高額だったため）。多くの担当者は紙を使って手書きでプログラムを作成して、机上テストを行い、テープやカードにプログラムをパンチした。プログラム・コードについても、コンピュータのメモリ制限が厳しかったこともあり、そのサイズを小さくすることが担当者の最大の関心事で、プログラムの読みやすさなどはまったく考慮されなかった。

　当時のコンピュータは確かに非常に高額だった。しかし、コンピュータはあくまで単なる「計算機」でしかなかった。この時代のソフトウェア開発では、ごく少ない人数の技術者がソフトウェアの作成を担当し、ソフトウェアの規模は小さく、行う処理も単純であり、成果物はプログラムのみであった。このように当時のソフトウェア開発における作業手順や成果物は明確なので、あえてそれらを厳密に定義する必要はなかった。必然的に開発プロセスの出番はなかった。

■ウォーターフォール型開発プロセス

　コンピュータが単なる電子計算機ではなく、「汎用コンピュータ」や「オフィスコンピュータ（オフコン）」と呼ばれる時代になると、ソフトウェアは次第に大規模になり、相対的にソフトウェア開発も大規模になった。それまでのやり方では、ソフトウェア開発が失敗することも多くなり、プロジェクト管理が必要とされるようになった。しかし、この時代のコンピュータは、スタンドアロンでの動作が主で、コンピュータ同士が連携する場合でもオンライン・バッチ処理などが多く、それも特定のコンピュータ間で行われることがほとんどだった。

　また、この時代のソフトウェアが担当する業務分野は、それほど変化がなく、開発にある程度時間をかけることも許されていた。従って、顧客の要求はある程度予測できる範囲であり、これを最初の入力として、効率的な開発プロセスが考案された。それが「ウォーターフォール型開発プロセス」である。

　ウォーターフォール型開発プロセスは、以下のように作業を上位から下位へ順に進めていく開発プロセスである。

ウォーターフォール型開発プロセス

　この開発プロセスでは、各作業フェイズの成果物として、「○○定義書」と呼ばれる大量のドキュメントを作成する。このドキュメントが次の作業フェイズの唯一の入力であり、このドキュメントをよりどころとして作業を進める。

　ウォーターフォール型開発プロセスを採用することで、大規模システム開発の状況は改善された。しかし、失敗するソフトウェア開発プロジェクトも数多く発生した。この主な原因は、各フェイズ間のギャップである。例えば、顧客の頭の中にある要望と開発者が作成した要求定義書にギャップがあり、出来上がったシステムを顧客が操作して初めて、作ってほしかったのはこんなシステムではなかったというクレームが発生した。また別のケースでは、内部設計とプログラミング（実装技術）にギャップがあり、内部設計通りに作成したシステムでは実用レベルのパフォーマンスが達成できなかった。

　そこで、上位フェイズの作業が完全に終わってから下位フェイズの作業を行うのではなく、上位フェイズの70％〜80％が終了した時点で下位フェイズの作業を開始し、その作業によるフィードバックを上位フェイズに行うことで、フェイズ間のギャップを埋めるような工夫がされるようになった。この方法によって、上位フェイズの作業が間違っていた場合の補正の機会を得ることが可能になった。

■反復型開発プロセス

　ソフトウェアの担当する業務分野が広がり、ビジネス活動においてソフトウェアが必須となる分野が出現するようになると、「長い時間をかけて開発したソフトウェアを長期にわたって運用する」という形態ではなく、「ビジネスの変化に合わせて長い期間でソフトウェアを進化させる」といった形態への要求が出現してくる。要するに、ウォーターフォール型開発プロセスがよりどころとしていた、「要求定義を確定することに十分な時間をかけることができる」「一度確定した要求は簡単に変化することはない」といった前提条件が崩れるケースが発生したわけである。

　このようなケースの多くは、ウォーターフォール型開発プロセスを繰り返し行うことで対応していた。しかし、既存業務の効率化ではなく、新たなビジネス分野での活動を実現するためのシステムの開発では、開発期間中にもビジネス変化への対応や新しいビジネス・リスクへの対応が求められるようになった。このようなことを背景として、ウォーターフォール型開発プロセスに代わる新たな開発プロセスが必要となり、そこで生まれたのが「反復型開発プロセス」である。

　反復型開発プロセスでは、開発の最初からウォーターフォール型の開発サイクルを複数回行うことを前提としている。従って、1回のサイクル終了時に、評価と再計画を行うことで、さまざまなリスクを回避することができる。

反復型開発プロセス

　反復型開発プロセスをスムーズに行うためには、単に複数回の開発サイクルを行うのではなく、開発サイクルをいくつかのステージに分け、その各ステージの位置付けや解決すべきリスク、繰り返しの回数などといったプロジェクト戦略を立て、それを管理することが必要とされた。

　このように、開発プロセスが複雑になったことで、プロジェクト管理についても新たな技術が必要となった。反復型開発を成功させるためには、ウォーターフォール型の開発プロセスより複雑なプロジェクト管理が必要になったわけである。しかし、多くの企業がそのような開発経験を持っていなかったため、開発プロセス自体の習得には多くの教育と費用が必要であった。

　プロジェクト戦略の具体的な一例としては、方向付け、推敲（すいこう）、作成、移行といったフェイズ分けを行い、各フェイズの目的や解決すべきリスクなどを明確にするという方法がある。この方法では、システムのアーキテクチャに重点を置き、ユースケースを各ステージに割り当てることでプロジェクトの計画と管理を行う。

　ここまで説明してきたように、開発プロセスのなかった時代があり、ウォーターフォール型の開発プロセスが生まれ、反復型の開発プロセスが登場した。そして、本稿の話題の中心であるアジャイル開発プロセスが誕生することになった。次のページでは、そのアジャイル開発プロセスについて説明する。

INDEX
	[特集] .NET開発者のための開発プロセス入門（前編）
	1．アジャイル開発プロセスが誕生するまで
	2．アジャイル型開発プロセスとは何か？
	3．.NET開発者がアジャイル開発プロセスを導入できない理由
	4．アジャイル開発プロセスの導入
	[特集] .NET開発者のための開発プロセス入門（後編）
	1．1人からでも導入可能なローカル・ライトウェイト開発プロセス
	2．単体テストの自動化とテスト・ファースト
	3．Mockオブジェクトとリファクタリング
	4．数名のチームで導入できるローカル・ライトウェイト開発プロセス

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）