ウォーターフォールの逆襲2006

先日、テストファーストをテーマにしたイベントのパネルディスカッションで、モデレータをしてきました。テストファーストというのは、ここ数年盛り上がりを見せているアジャイルなプログラム開発手法の中の1つです。

パネルに参加して頂いたのは、アークウェイの黒石さん、永和システムマネジメントの平鍋さん、マイクロソフトの岩出さんです。約90分のパネルで、テストファーストだけでなくアジャイルや品質管理にまで話がおよびました。

テストファーストのメリットは？

テストファーストをご存じない方のために簡単に説明すると、まず仕様に合致する単体テストを先に書いて、その単体テストに通るようなコードを書いていく、というプログラミング手法です。詳しくは下記の記事などが参考になると思います。

・EclipseとJUnitによるテスティング（＠IT）
・NUnit入門 Test Firstのススメ （＠IT）

パネルではいろいろテストファーストのメリットについて意見が出たので、覚えているものをピックアップしてみましょう。

1. 先にテストを書いておくことで、中身のコードをあとからいじってもいじり壊すことを心配しなくていい。つまりリファクタリングがやりやすくなる。「テストコードを書かずにリファクタリングをするなんてリファクタリングじゃない」という発言もありました。
2. 自分の書いたコードがどこまで完成しているか、テストコードを走らせればすぐ分かる。テストを書く、コードを書く、テストが通る、というリズムで仕事が回り、仕事にリズムが出てくる。こうしたことで、プログラミングの効率があがったり、プログラミングに集中しやすくなる効果もあるようです。
3. チームで開発するときも、単体のテストが通ったコードが集まるので、ビルドの信頼性があがってチームの効率が高まる。

一方で、テストファーストは何度もコンパイルと実行を行ってテストする工程が入るので、一部を書き換えるだけで全体に影響するようなインクルードが多数ある場合は効率が悪くなる。といったことがデメリットとして挙げられました。

また、テストファーストは仕様に沿って先にテストコードを書くため、開発の途中でコロコロ仕様が変わらないように上流で仕様を固めておけるようなプロジェクトマネジメントをしなければいけない、という指摘もありました。

産業としてのソフトウェアには必要

パネルが終わったあとの懇親会で来場者から話をうかがったところ、テストファーストはプログラミングテクニックのようなものなので1人でも始められるけど、チームに広めようとするとスキルが揃わないとか意識が揃わない、といったことが導入のハードルになるそうです。ペアプログラミングをしながらチーム全体のスキルを揃えていくことが解決になる、とのことですが、そういった開発プロセスを導入するにはまだまだ上司や会社の理解が必要で難しいのが現状です。

ITは、企業の効率化を実現するという用途から、企業活動や社会活動のインフラとして機能するものへと変化し、重要性が高まると同時に、品質に対する目は非常に厳しくなってきています（東京証券取引所のシステムなどがいい例でしょう）。開発手法やプロジェクト管理、アーキテクチャなどに注目が集まっている現状は、こうしたニーズにソフトウェア業界が応えようとしている証拠です。

一発で確実なコードを書けるスーパープログラマーにとっては、実はテストファーストも、ペアプログラミングも、プロジェクト管理も、余計な仕事を増やす面倒なものなのかもしれません。しかし、産業としてソフトウェア業界が品質管理や開発効率を向上させていこうとするとき、チームのための開発方法論、開発効率といった議論はとても大事な議論だと思います。

ウォーターフォールの逆襲？

ところで、このエントリのタイトルは、パネルの最後に平鍋さんが紹介された米国の最新事情にちなんでいます。いま米国ではアジャイルのブームに対抗して「Waterfall 2006」というイベントで、伝統的な開発プロセスであるウォーターフォールを盛り上げよう、となっているとのこと。そのイベントでは、

• Joy of Silence：余計なことはしゃべらず、必要最低限のコミュニケーションで済まそう
• Document-Driven Documentation：ドキュメントの正確さをドキュメントによって確かめよう
• テストは最後に：テストは本来あった場所、つまりプロセスのいちばん最後に置くべき

なんていう主張が語られるそうです。というこのイベントは4月1日開催。このイベントやイベント紹介のホームページ全体が（アジャイルの盛り上がりに対する）全くの冗談ですが、このホームページを平鍋さんが紹介しながら、パネルは笑いに包まれつつお開きになりました。