連載：VB研公開ゼミ議事録 第3回　実践！ .NETで変わるVB業務アプリ開発 デジタルアドバンテージ　遠藤 孝信 2007/08/03
Page1 Page2 Page3

非機能要件でのテスト駆動開発

【会場】機能要件に関するテストでテスト駆動（テスト・ドリブン）開発を行うというのは一般的だと思いますが、性能やセキュリティといった非機能要件に対してもテスト駆動による開発は行われているのか、今後行われていくのかをお聞きしたいのですが。

【小井土】非機能要件でも数値化可能な項目ならテストできるところはあります。例えば、ツリー型コントロールを作る場合で、あるノードに1000個のノードを登録したらまったくスピードが出なくなったとか、1万件のデータベースに対して検索に非常に時間がかかるとか。そういうところは1万件追加が5秒以内にできないと赤くする*ようなテストが書けます。ですので、非機能要件の中でも数値化できるものに関してはテストの作成にトライする価値はあると思います。

* NUnitなどの単体テスト・ツールでは、テストが失敗するとその項目を赤く表示して分かりやすく警告するのが一般的である。ちなみに成功した項目は緑色となる。

【小井土】Webサービスの呼び出しなども、その応答が例えば10秒以内に返ってこないと問題が起きているはずだとするテスト・コードを書いて入れておくというやり方があります。ただ、そういったテストは基本的には日々動かすものではなく、夜間バッチや週末のウイークリー・テストで実行したりするという方法をわたしは行っています。

【会場】そういったテスト・メソッドはテスト・ツールのフレームワークに含まれているのでしょうか。

【小井土】いえ、基本的に自分で作ります。ただ、最近ではいろいろなツールが出ていて、マルチスレッドのテストをしてくれるようなNUnitの機能拡張や、「NDbUnit」というデータベース用のテスト・ツールもあります。NUnit自体が世に出てからかなり時間がたっているので、いろいろな拡張機能が利用可能になっています。

アジャイル開発を社内展開するには

【会場】XPのツールについて、アジャイル開発も含めてですが、社内展開のための“キラー・ワード”があればアドバイスください。

【小井土】ツールを導入するときの問題は、まず開発手法の変化に伴うハードルの高さですね。これはハードルが低いところ（ツール）から入れていくのが一番です。また、どうしても全社的に導入を行うと、いろいろなチームとのネゴが必要になったりしますので、部分的に導入していくというのも有効だと思います。

　特にSubversionには、エクスプローラ上から使えるようにするためのアドインが提供されているため、導入のハードルは低いと思います。例えば、ソース・ファイルに対する導入が難しければ、Word、Excelなどのドキュメントに対してまず導入するといったこともできます。過去のバージョンに戻したいことが多々あるようなところから始めるのもよいでしょう。

　ポイントは「いま困っていることに対する解決」を目的にするということです。どこで困っているかをまず考えて、こういうことで困っているから、ちょっと大変かもしれないけどやってみましょう、というふうに話を進めるのです。困ってない人に使ってくれといっても、なかなか同意してもらえませんよね。ですので、困っているところを探すというのも1つの手です。

【西崎】Subversionはプログラムのソース・ファイルだけでなく、Wordなどのドキュメントなどにも使えるのですが、優れた点は、そういったドキュメントのバージョン管理は別にチームで共有しなくても、まず自分だけでできるというところです。

　自分がいま編集しているドキュメントをSubversionに入れておけば、大きく間違えたときや、思いっきり構成を変えたいというときに、ファイルを元に戻せます。前のバージョンを日付や名前を変えてコピーを取っておいて、元に戻したいときには再度コピーするといった方法に比べると、作業が圧倒的に容易になります。

　そんなふうに自分で使っていれば、周りにも広めやすいですよね。例えばセミナーを見てきて、これは便利そうだと思ってほかの人に資料を見せて「こんないいものがあるよ」と伝えても、「でもそれって本当にうまくいくの？」と切り返されてしまいます。しかし、自分でやってみて「こういうふうにうまくいっています」と自分の言葉で伝えることができれば、非常に説得力があります。

【小川】質問された方に逆に伺いますが、そうした質問が出るということは、有用そうな新しいアプローチの採用を提案しても、すんなりと始められない事情があるのだと思います。その原因は何なのでしょうか？ いまのままではいけないといった問題意識はあるのでしょうか？

【会場】問題意識はあっても、コストの問題や導入のハードルなどがあり、また自分ではアジャイル開発について勉強していても、それを横展開するとなると、やれ工数はどうなる、やれ導入してお客さまに迷惑をかけたらどうしようなどと、横やりが入ってしまうのです。

【小川】なるほど、問題意識があっても、それがどれくらいコストのかかるものかが分からず、なかなか始められないということですね。ここをクリアにする方法はないのでしょうか？

【小井土】ないですね（笑）。いや、Subversionなどは即効性があるから非常に導入しやすいですが、単体テストの自動化などは、即効性というより開発の平均的スピードを上げるものだからです。それは続けてみないと結果が出てこないものであり、「継続は力なり」といった面があります。ですので、自分だけでもどんどん導入して経験を積んでいかないと、なかなか横展開は難しいと思います。

　ただ、単体テストの自動化やテスト・ファーストは明らかに実践した方がよく、やったらやったなりの効果は絶対出ます。すべてに使う必要があるかというとそれは疑問ですが、使った方がよいところが明らかにあると思います。そういう意味では、自分で困っているところ、自分で無駄だなと思っているところに対して積極的にツールを入れてみて、それを広めていくのがいいと思います。

ツールで保守性を上げることはできるのか

【会場】ディスカッションのテーマでもある品質についてですが、他社さんに外部委託などをすると、確かに動くものが返ってくるのですが、その後のメンテナンス性が非常に悪かったりすることがあります。こちらからコメントを書いてとお願いしても、たまに中国語で書いてあったりして。その辺について何かアドバイスはありますか？

【荻原】そうですね、コメントに関してはVS 2005限定になりますが、シングルクオーテーション3つ（'''）でソース・コード内にXMLコメントを書いてもらうようにすれば、ツールでそれをドキュメントに落とすことができ、こんなメソッドを書いているんだなというのをチェックすることができます。

　このツールは、マイクロソフトがオープンソースとして提供している「Sandcastle」というツールで、これを使うとXMLコメントからMSDN風のドキュメントを出力できます。これにより、変なコメントが入っているところや、コメントが書かれていないところはすぐに見通しがつきますので、まずはこれを使ってみるのはどうでしょうか。

　コードの品質については、VSTSのコード分析ツールによりチェックすることができます。これはもともと「FxCop」という単体のツールでしたが、これを使うと変なコードを書いていないかをチェックできます。ほかに何かアイデアありますか？

【小井土】かけられるコストによりますが、できれば本当はテスト・コードを書いてもらって、それも納品してもらう方がベターだと思います。テストはアプリケーションを修正するときなどにも使えますし、特にバグの再現テストに関しては、必ず再現テストを作ってから修正してもらうようにできればよいですね。またテスト・コードがあれば、手元でコードのリファクタリングも行いやすくなります。

INDEX
	VB研公開ゼミ議事録
	第3回　実践！ .NETで変わるVB業務アプリ開発
	1．VB6でもツールの利用は可能か／移行時のツール活用／UIの単体テストについて
	2．非機能要件のテスト／アジャイルを社内展開／ツールで保守性アップ
	3．ツールを使う際のバグ管理／テストのメンテナンス／使っているツールの数

　

「VB研公開ゼミ議事録」

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