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

.NET開発者がアジャイル開発プロセスを導入できない理由

　ここまでで説明したように、開発プロセスは歴史とともに進化を続けている。そして、その最右翼がアジャイル開発プロセスである。アジャイル開発プロセスは多くの現場、とりわけJava開発で採用され、すでに実績を残している。では、.NET開発者は実際の開発プロジェクトでアジャイル開発プロセスを積極的に取り入れているといえるだろうか。

　筆者らの感覚では、残念ながら現状では.NET開発者が実務でアジャイル開発プロセスを積極的に取り入れているとは思えない。少なくとも筆者の知る限りは、従来からのウォーターフォール型の開発プロセスが多いという実感がある。これはどういうことなのだろうか。.NET開発者はアジャイル開発プロセスなどのほかの開発プロセスに対して関心がないということなのだろうか。

　そんなことはないと筆者らは考えている。これは、アジャイル開発プロセス関連のセミナーやセッションに多くの.NET開発者が詰め掛けているという事実からもうかがえる。先日、マイクロソフトの開発者向けカンファレンスであるTech・ED 2004 Yokohamaで行われたWelcome to INETA Japan Events！「アジャイル開発ライブ！」には、それがメイン・セッション終了後の18時30分から行われたにもかかわらず、多数の参加者があり、活発な質疑応答が行われた。質問者の多くは、アジャイル開発プロセスに強い関心を持っており、どのように自分たちのプロジェクトにアジャイル開発プロセスを導入すべきかを真剣に考えているということがうかがえる内容であった。このイベントに参加できたのはTech・EDに登録して参加していた開発者のみであり、その多くは当然ながら、.NET開発者であると考えられる。

　また、XPの普及を主目的としたユーザーグループである「日本XPユーザグループ」が行っている「XPユーザー会」や「XP祭り」にも多数の参加者があり、この中にも多くの.NET開発者が含まれている。日本XPユーザグループでは、XPのみならず、アジャイル開発プロセスに関する多くのセッションを行っているが、その参加者が年々増加し、アジャイル開発プロセスに対する関心の高まりを強く感じている。そこでは参加者が開発プロセスを熱心に勉強する姿が見られる。

■なぜアジャイル開発プロセスを導入できないのか？

　それでは、なぜアジャイル開発プロセスの導入がそれほど進まないのか。筆者が考える2つの理由を挙げてみたい。

（1）オブジェクト指向開発に慣れていない

　1つの理由として、開発者がオブジェクト指向開発に慣れていないという点が挙げられる。オブジェクト指向開発というと、RUPのような開発プロセスやUMLモデリングなどを含む広い意味を持つが、ここではもっと単純にオブジェクト指向プログラミングについて考えてみることにする。

　現在.NETで開発を行っている開発者で、特に業務系アプリケーションを受託開発している人の多くは、マイクロソフトのVisual Basic 6.0（以下VB 6）の開発経験者であると思われる。VB 6は、オブジェクト指向プログラミングのエッセンスを取り入れたクラス・モジュールなどの機能を持ってはいたが、継承ができない、コンストラクタでパラメータが渡せないなどVisual Basic .NET（以下VB.NET）と比較するとオブジェクト指向プログラミングとしての十分な機能を提供していなかった。

　また、VB 6のクラス・モジュールはCOMコンポーネントの作成を念頭に設計されており、ActiveX DLLを作成するために用意されていたと考えることもできる。そのため、クラス・モジュールを使う必要があるのは、開発したActiveX DLLコンポーネントをCOM+に登録して利用する多階層アプリケーション、いわゆるWindows DNAアーキテクチャを利用する場合であり、高度な分散システムを開発するためであった。ところが、一般的な業務アプリケーションの開発では、従来から行われていたクライアント／サーバ型の開発が多く、VB 6開発者はCOMコンポーネントを開発するのではなく、フォーム・モジュールやコード・モジュールに直接データベースを操作するためのSQL文を記述していたので、必ずしもクラス・モジュールが使われていたとはいえなかった。

　VB 6は構造化プログラミング言語であり、業務アプリケーションの開発者がデータベース設計とデータベースに対するSQL文を中心にプログラミングを行っていたので、多くのVB 6開発者はデータ中心のアプローチ（DOA）で開発を行っていたことになる。つまり、構造化プログラミング言語であるVB 6を使用して開発を行っていた多くの開発者は、オブジェクト指向プログラミングではなく構造化プログラミングのアプローチに慣れているということである。

　構造化プログラミングでアジャイル開発プロセスができないかというと決してそうではないが、アジャイル開発プロセスについて書かれている多くの書籍や情報が、オブジェクト指向技術を前提として書かれていることもまた事実であり、オブジェクト指向開発に慣れていない.NET開発者はハードルが高いと感じているのではないだろうか。

（2）日本の企業文化

　もう１つの理由は、実際にはこちらの方がより強い理由だと思われるが、日本独特の企業文化にあると考えている。日本では企業がシステムを発注する際に、見積書の提出を要求する。この時点では、発注側には漠然としたシステムのイメージがあるだけである。つまり要求仕様も完全に固まっていない。もちろん提案依頼書（RFP）のようなものはあるが、実際には顧客側にはシステムに対する知識が不足しており、新しいシステムが実現する機能を正確に予測することなど不可能である。

　要求が固まっていないにもかかわらず、発注する側には見積もりを要求する都合がある。これは発注担当者が稟議（りんぎ）を通す必要があり、事前に費用を知る必要があるためだ。受託する側は顧客のあいまいな要求を基に見積もりをしなければならない。文字どおり「ざっくり」とした見積もりを出すことになる。これに対して発注する側は見積もりの金額を基に稟議を回すため、その予算内で希望するシステムが構築されることを期待する。

アジャイル開発プロセスを導入できない2つの理由

.NETでは、次の2つの理由により、アジャイル開発プロセスの導入が進んでいないと考えられる。 1. .NET開発者はオブジェクト指向プログラミングに慣れていない 2. 稟議（りんぎ）を通すために事前の工数見積もりが必要

　このような状況では、受託する側の立場からすると要求された内容から予想される機能を基にすれば作業の工数が予測しやすく、見積もりが提出しやすいという理由でウォーターフォール型の開発が採用されるということになりがちだ。また発注側の顧客にとっても計画を理解しやすいため、ウォーターフォール型の見積もりが定着しているのが現状である。

　プロジェクト・マネージャや管理職にとっては、見積もりを行ううえで慣れている方法を採りたいのが人情である。新しい開発プロセスを導入した結果、プロジェクトが失敗するかもしれないというリスクを考えれば、たとえ失敗することはあっても、現状のやり方を変えたくないと考えてしまう。管理職にとっては、いままでのやり方を変える勇気がなかなか出ないのも仕方がないことかもしれない。

　この点については.NET開発プロジェクトだけの問題ではないが、いわゆる従来型基幹系システムを受託し開発を行っている開発プロジェクトはこの傾向が強いのではないだろうか。

　それでは、そのような状況に置かれている現実の.NET開発プロジェクトに、アジャイル開発プロセスを導入することは不可能なのだろうか。そこで、それを解決するために筆者らがお勧めする秘策を次のページで紹介する。

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

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