連載 NAgileで始める実践アジャイル開発 第1回 .NET＋アジャイルなら本当に幸せになれるのか？ ――フリーのN*ツールによる楽しいアジャイル開発―― デジタルアドバンテージ　一色 政彦 ＆ 正木 理絵子 2005/10/19

Page1 Page2 Page3

　なぜ現在のソフトウェア開発においてアジャイル開発が生まれたのだろうか？

　それは、「新しい時代の流れ（例えば、オブジェクト指向設計／開発やプロジェクトの短期化など）」と「古い開発体制（例えば、ウォーターフォール型のきっちりした開発プロセスやドキュメント作成を重視する姿勢など）」という無理な組み合わせにすでに大きな矛盾が生じており、その矛盾の中で実際に働いている多くのデベロッパーがそれを何とかして改善しようと思うようになってきたからだと筆者は考えている。要するに、矛盾が生じている現在のソフトウェア開発に対するアンチテーゼとしてアジャイルが提唱されたのではないだろうか（アジャイル開発については「.NET開発者のための開発プロセス入門」を参照してほしい）。

　アジャイル開発は、ソフトウェアの開発作業をもっとアジャイルにして（＝俊敏で柔軟なものにして）、現場のデベロッパーがもっと楽しく充実した開発者人生を送れるようにしようとするムーブメントの1つだ。つまりアジャイル開発とは、デベロッパーの、デベロッパーによる、デベロッパーのための開発手法だといえるだろう。

　だがそうはいうものの、.NETによる開発の場合にもアジャイル開発手法を持ち込めば本当に幸せになれるのだろうか？ そもそも.NETでそう簡単にアジャイル開発が実現できるのだろうか？ いまから.NETでアジャイル開発を始めるために必要なツールやドキュメントはそろっているのだろうか？ また.NETで行うアジャイル開発では、“NAgile”（発音は「エヌ・アジャイル」もしくは「ナジャイル」）という言葉を聞くことが最近よくあるが、それは一体何なのか？ 普通のアジャイル開発とはどう違うのか？

　これらの疑問を解消するため、＠IT／Insider.NET編集部では「NAgileを実践している開発者」（“NAgiler”と呼ぶ。発音は「エヌ・アジャイラー」もしくは「ナジャイラー」）による座談会を開き、NAgileとはどういうものか明らかにしようと試みた。

　今回の座談会では、.NET開発の第一線でNAgilerとして活躍されている以下の方々にお集まりいただいた。なお一部の方は、（座談会の会場に居合わせたのではなく）Skype（PtoP技術を応用した音声通話ソフト）の会議機能を使いインターネットを介して参加していただいた。

• 小島 富治雄 氏（Skypeにより参加）
• 小井土 亨 氏
• 小野 修司 氏（Skypeにより参加）
• 黒石 高広 氏
• 森屋 英治 氏
• 中西 庸文 氏（Skypeにより参加）
• 福井 厚 氏
• 市川 龍太 氏

　今回の座談会の主要トピックは以下の3点である。

1. そもそもNAgileって何？
2. NAgileを実践すると何がうれしいのか？
3. NAgileを始めるには？（＋NAgileの将来展望）

　それでは、さっそく座談会の内容に入っていこう*1。（以降、敬称略）

*1 なお以下の会話内容では、（内容を簡潔にするために）複数の参加者で交わした議論内容や発言内容を、1人の発言としてまとめて記述した。ここで発言者として記述されている人物は、その複数の発言者の中でも特に中心的な発言を行った人である。

1. そもそも“NAgile”って何？

―― 最初に、「そもそも“NAgile”とは一体どのようなものなのか？」ということについて聞いていきたいと思います。

　まずはこの「NAgile」というキーワードに関する質問です。このキーワードは森屋さんが新たに造語として使い始めたと聞いていますが、それはなぜでしょうか？

森屋：日ごろ.NET関連のブログを見ていて感じるのですが、やはり.NETでアジャイルを実践している開発者というのはまだまだ非常に少ないようです。ですがアジャイル開発は、現在のソフトウェア開発が抱える課題、例えば頻繁な要求の変化に対する柔軟な対応などを解決するための有効な手段の1つであるとわたしは思っています。

　そこで、「もっと多くの.NET開発者にアジャイル開発の良さを知ってもらって、実際の現場で活用してもらいたい。それによって、より幸せで充実した開発者人生を開発者に歩んでいただきたい。そのためにも、まずは分かりやすくてシンボルとなるキーワードが必要だ」と考えたのがNAgileのきっかけです。

　また、.NETでアジャイル開発を進めるための「N*」（エヌ・アスター）と呼ばれるフリー・ツールがすでにありますので、この「N*ツール」＋「.NET」＋「アジャイル開発」の3点を1つの開発手法（＝「NAgile」）にまとめて表現することで、これまでのように単に「.NETでアジャイル開発」というよりも、さらに的を絞ってもっと深く掘り下げた議論を行えるようにしたい、というのがこのキーワードの狙いです。

NAgileの概念

「.NET」には、開発基盤の.NET Frameworkや開発環境のVisual Studioなどが含まれる。「アジャイル開発」には、アジャイル開発プロセス、アジャイル開発の思想（価値や原則、プラクティスなど）、アジャイル要求開発などが含まれる。「N*ツール」については以下で簡単に紹介する。

　つまり「NAgile」というキーワードによって、より多くのデベロッパーに、.NETでのアジャイル開発をできるだけ分かりやすく、しかもできるだけ具体的に伝えていきたいと考えているわけです。

―― なるほど。NAgileでは、「N*ツール」を利用しながら、.NETでアジャイル開発を実践することが基本となるわけですね。それでは、そのN*ツールとは具体的にどのようなツールなのでしょうか？

黒石：N*ツールとは、本来は「NUnit」や「NMock」など、単語の先頭に“N”が付く.NET向けツールの総称です（NUnitやNMockについては「テスト駆動開発ツール最前線」を参照）。しかしこれはあくまで原則であって、.NETでのアジャイル開発に活用できるそのほかの開発ツールやフレームワーク、ライブラリなども、「N*」というくくりの中に含めています。

　N*ツールとしては、（これがすべてではありませんが）主に次のようなツールがあります。

	NUnit ＆ NMock	単体テスト・ツール。モジュール単位のテストを自動化できる。「エヌ・ユニット」「エヌ・モック」と発音する
	TestDriven.NET	Visual Studio .NETによる「テスト駆動開発」（Test-Driven Development）のためのツール
	NAnt	ビルドの自動化を行うためのツール。「エヌ・アント」と発音する
	CruiseControl.NET	継続的なビルドとテストの自動実行を行う「継続的インテグレーション」（Continuous Integration。「常時結合」とも呼ぶ）のためのツール。「クルーズ・コントロール・ドットネット」と発音する。以降、「CC.NET」
	FIT	「Framework for Integrated Test」の略。受け入れテスト・ツール。エンドユーザー（＝顧客）レベルのテスト、つまりユーザーの要求が満たされているかどうかのテストを自動化できる。「フィット」と発音する

　さらに、例えば次のようなフレームワークやライブラリも、N*ツールの1つとしてとらえています。

	S2.NET	DIコンテナを実現するJava向けフレームワーク「Seasar」の.NET版。DIコンテナについては「J2EE Watch［7］：DIとAOPがサーバ・コンポーネント技術を変える」を、Seasarについては「The Seasar Projectの全貌を探る」を参照されたい
	Enterprise Library	エンタープライズ・アプリケーション向けライブラリ。詳しくは「Enterprise Library概説」を参照

　簡単にいえば、.NETでのアジャイル開発を促進するためのツール／フレームワーク／ライブラリがN*ツールというわけです*2。

*2 これらのツールの具体的な内容は、これからの連載の中で用途ごとに個別に取り上げて紹介していく予定である。

―― N*ツールはすでに結構たくさんあるのですね。ところで、一口にアジャイル開発といっても、そこで採用されるアジャイル開発プロセスにはXP（eXtreme Programming）やScrumなどさまざまありますが、NAgileではどの開発プロセスを対象にしているのでしょうか？

小井土：そういう開発プロセスの限定はありません。それに開発プロセスよりも、むしろアジャイル開発の「プラクティス」（＝実践項目）と先ほど述べた「それを実現するためのN*ツール」の方が重要です。そしてこの「プラクティス＋ツール」を実践する際には、順を追って踏まなければならない明確なステップが存在します。

　具体的には、次のようなフェイズがあります。

「プラクティス＋ツール」の実践ステップ

まずは単体テスト・ツールの「NUnit」から使い始め、次に「NMock」を理解し、テスト駆動開発（Test-Driven Development。以降、TDD）を実践します

それができるようになったら「NAnt」を利用してビルドの自動化を実践します

そして次は「CC.NET」を利用して継続的インテグレーション（継続的なビルドとテストの自動化）を実践します

最後に「FIT」を使って、受け入れテストの自動化を行います

　このように系統立ったステップに従ってプラクティスに取り組んでいくことは、NAgileを実践するうえでの重要事項の1つです。

森屋：ほとんどのNAgilerは基本的にこの一連のフェイズを順に踏んでいます。というのも、あるステップにあるプラクティスを実践していると、さらに別のプラクティスを取り入れたくなってくるからです。例えば、NUnitやNAntが利用できるようになれば、「さらにそれを進めて、継続的なインテグレーションを実現したい」と思うのは当然の成り行きでしょう。

　これらの「プラクティス＋ツール」の利用が、NAgileのメインストリームになります。これら以外の（ソフトウェア開発に付随して必要となる）フレームワークやライブラリ、ツールなどは、このメインストリームの周辺にあるという構図になります。このような脇にあるテクノロジを実際にどう活用するかは、各開発者が状況に合わせて自由に決めればよいのです。

―― つまりNAgileには、コアな部分とそれ以外のオプションで追加できる部分があるということでしょうか？

森屋：そうです。NAgileではコアなプラクティスのステップに、さらに現実のプロジェクトに適したオプションをどんどん追加しながら、独自の開発スタイルを自由に築き上げることを重要視しています。

　つまり「いいもの（＝使えるオプション）はどんどん取り入れよう」という姿勢がNAgileの基本なのです。例えばオプションとしてDIコンテナのS2.NETやEnterprise Libraryなどのフレームワーク／ライブラリがありますが、これらは実際にプロジェクトにマッチするかどうかを判断したうえで適宜それを取り入れていけばよい、という考え方です。

小島：ちなみにNAgileを語りだすと、どうしてもN*ツールの話題に極端に集中してしまいますが、アジャイル開発のプラクティスや価値・原則の上にそれらのN*ツールやNAgileが成り立っていることを常にきちんと意識しておく必要があります。

　あくまでアジャイル開発ありきのN*ツールなわけです。「N*ツールさえ使えばそれでNAgileなのか？」というと、当然それは違うわけですから、そこは忘れないように注意していただきたいです。

―― ところで、まもなく「Visual Studio 2005 Team System」（以降、VSTS）が出荷開始される予定ですが、これに含まれる「Visual Studio Team Edition for Software Testers」（以降、VS Team Test）のテスト関連機能は、NUnitなどのN*ツールと非常によく似ていませんか？

小井土：VS Team TestとNAgileは、それぞれ異なる思想に基づいて作られています。というのも、テストには2つの考え方があるのです。

　1つは「設計のためのテスト」という考え方です。要するにこれは「設計の見える化」です。例えば「TDD」は設計の見える化の最たるものですが、テストを作ることによって、まずは設計を具体的なコードとして見えるようにし、さらにそれが設計にのっとって作られ、正しく動作するのかを確認できるようにします。

　もう1つは、「品質に関するテスト」という考え方です。つまりこれは「品質の見える化」です。テストを作り実施することによって、コード修正などによるバグを検出して防ぎ、製品の品質を常に一定に保ちます。

　テストに対するこの2つの考え方を世間の多くの人は混同していますが、これらは区別すべきです。

　NAgileのテスト機能は、前者の設計のためのテストへの比重が高くなります。しかしVS Team Testのテスト機能は、品質に関するテストの比重が高くなっています。またVS Team Testでは、その利用者が“Testers”と命名されていますが、そもそも「テスター」は品質管理者を意味するので、その名のとおり品質に関するテストの方に重点が置かれているわけです。

Visual Studio Team SystemとNAgileのテストに対する考え方の違い

森屋：これは名前空間（ネームスペース）にも表れていますね。NUnitの名前空間は「NUnit.Framework」となっており、テストをフレームワークとして位置付けているのに対して、VS Team Testの名前空間は「Microsoft.VisualStudio.QualityTools.UnitTesting.Framework」であり、あくまでテストをクオリティ・ツール（品質のためのツール）と分類しています。

小井土：そうです。ですから両者は一見、似ているようで、似ていない。正直にいうと、VS Team Testはアジャイル開発者にとってはいまひとつ使いづらいところがあります。これはアジャイル開発の気持ちがよく分かっていないからなのかもしれません。

　NAgileという視点から見た場合、ここで気付いてほしいのは、「設計が悪いものなら、いくら技術で頑張っても最終的には悪いものができる」ということです。まずは設計をきちんと行い、次に品質を上げていくことが重要です。

小野：要するに、NAgileは「テスト駆動“開発”」（TDD）というプラクティスを掲げていますが、実質的にはむしろ「テスト駆動“設計”」なんです。むしろ、設計をコード・ベースでやったらテストになった、という方が適切だと思います。

―― つまりNAgileは、TDDなどのプラクティスによって「設計の見える化」を目指しているので、これからNAgileに取り組もうという人にとっては、「品質の見える化」を目指しているVS Team Testでは方向性が違うために不向きなのですね。

　ここまでの話で、NAgileの定義やN*ツールの構成内容、NAgileの主な特徴などについては大体分かりました。次に「実際にNAgileに取り組むと、開発者はどういう面で幸せになれるのか？」というトピックに移らせていただこうと思います。

INDEX
	NAgileで始める実践アジャイル開発
	第1回 .NET＋アジャイルなら本当に幸せになれるのか？
	1．そもそも“NAgile”って何？
	2．NAgileを実践すると何がうれしいのか？
	3．NAgileを始めるにはどうすればよいのか？（＋NAgileの将来展望）

　

「NAgileで始める実践アジャイル開発」

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