テストファーストでユーザーも開発者も幸せに：「ITアーキテクト塾」レポート（2） （2/3 ページ）

[トレッフェ「 岩崎史絵」，＠IT]

テストファーストと出合って衝撃を受けた

　続く第2部では、テストファーストの実践について、そのメリット／デメリット、そして導入を阻害している要因やその対応について、黒石氏を含む3人のパネリスト（永和システムマネジメントの平鍋健児氏、マイクロソフトの岩出智行氏）が登壇してパネルディスカッションを行った。途中、会場からも適宜質問が入り、受講者とパネリストとの活発な意見交換が行われた。司会・進行は、＠IT編集人の新野淳一が担当。以下、その概要を見ていこう。

新野　本日、モデレーターを務める＠IT編集人の新野淳一です。パネルディスカッションに先立ち、まずパネリストの方々に、「私とテストファーストとの出合いについて」というテーマで、簡単に自己紹介を行っていただきましょう。

平鍋　永和システムマネジメントの平鍋です。当社はアジャイル開発を中心とするコンサルティングや、SI事業、そしてマインドマップとUMLの融合エディタ「JUDO」などのツールを開発・提供しています。

　私が2000年にXPと出合ったときには、まだテストファーストは取り入れられていなかったのですが、その開発手法の斬新さに衝撃を受け、それ以来「XPの伝道師」として、2003年には「日本全国XP行脚」を行いました。その活動ではテストファーストのワークショップを開催し、おかげさまで好評を博しました。本日は、テストファーストの重要性とそのメリットについて、私自身の体験を基にお話ししたいと思います。

岩出　私は現在、マイクロソフトで「Visual Studio 2005」のマーケティングを担当しています。前職はSI会社のオージス総研に勤務しており、ラショナル社（現IBM）の「Rational Rose」でモデル駆動開発を行っていました。オージス総研に在籍していた2000年にXPが登場し、平鍋さんの活躍により、アジャイル開発に注目するようになったのです。

　モデル駆動開発は、モデルの再利用性を高めたり、良い設計を実現することで開発そのものを高めていこうというものでしたが、テスト駆動のアジャイル開発は、現場のやる気を出したり、テクニック的に開発や品質を高めようということで非常に面白いな、と思いました。また、開発にはツールも重要だと思い、それが縁で現職に至ったというわけです。

黒石　私も1年半前までマイクロソフトに所属していました。そのときにクライアント先でテストファーストを教えてもらったのです。こうした最新の開発手法や技術についてもっと触れたいと思い、独立したのですが、岩出さんからお話があった「Visual Studio 2005」のエディションの1つである「Visual Studio 2005 Team Suite」がもう少し早く出ていれば、まだマイクロソフトで頑張っていたかもしれません（笑）。

テストファーストの実践を妨げる“障壁”とは

新野　会場の皆さんに伺いたいのですが、「テストファーストをやったことがある／いままさにやっている」方はどれくらいいらっしゃるでしょうか？ ……本日、50人くらいの受講者の方がいらっしゃるようですが、テストファーストの経験者は2〜3名といったところでしょうか。

テストファースト経験者は少なかった

平鍋　世間比率より、ちょっと多いくらいでしょう（笑）。実は当社でも、アジャイル開発を取り入れているのは全案件の1割くらいです。完全ピュアなテストファーストを実行したのはいままで1件だけですから。

新野　テストファーストがもたらすメリットは、第1部で黒石さんからご紹介がありましたが、やはり実践するのは非常に難しいのですね。その理由は何なのでしょう？

平鍋　テストファーストではなく、範囲を「アジャイル開発」と広く取れば、クライアントの理解を得られるかどうかに掛かっています。ただ、テストファーストに限れば、比較的導入しやすいと思います。

岩出　基本的に新しい取り組みについて、クライアントの理解が得られないというのが最大の障壁でしょう（笑）。なので、特に付き合いの長いクライアントであれば、まずテストファーストなど開発側だけで取り組みを通じて、プロセスを変えてみる。そしてある日、クライアントから「品質が上がったね」と信頼を得る、そういういい関係を作っていくべきだと思います。

新野　あとは自社開発などで、比較的交渉しやすいプロジェクトで実践してみるのも1つの方法ですね。

平鍋　XPまで範囲を広げて考えるのならば、実はタイムボックスが一番導入しやすいのです。例えば1週間の作業を振り返る、イテレーションをやるというように、短い単位で作業を管理します。次に導入しやすいのが、テストファーストですね。そこでシンプルな設計を実践し、リファクタリングして、品質を高めていく。こうした方法を、個人からペアへ、チームへ、クライアントへと波及させていき、信頼関係を築いていきましょう。

いまや“デバッグ”は過去の遺産？

新野　「テストファーストをやっていて良かった」という経験はありますか？

黒石　プログラミングのスタイルが変わりました。テストコードがあると、すぐ問題点が分かります。これまでは、まず全部のコードを書いてからデバッガを動かし、問題点を洗い出していたのですが、テストファーストではテストコードを動かして、「これ動いていないからこのメソッドを見てみよう」と、問題点がすぐ分かる。労働時間が減ったかどうかは定量的にいえませんが、開発効率は上がりましたね。

平鍋　私の場合は、開発にリズムが出てきました。最初は失敗して「レッド」、次にテストが通って「グリーン」、さらにリファクタリングして「グリーン」という3ステップで、リズミカルに開発できる。黒石さんのコメントにあったように、問題点にすぐフォーカスできるのもありがたい。いまや“デバッグって何だっけ？”という境地に達しています（笑）。

岩出　私自身はテストファーストで実際に開発をしたことはないのですが、案件の中では単体テストを必ず作っていました。単体テストを作ると、確かにデバッグの負荷が減ります。一番問題が起こりやすい部分をきちんとやることで、開発効率が劇的に高まりますね。

新野　この点について、会場の方からのご意見や質問があれば聞いてみたいのですが、いかがでしょうか？

受講者A　従来「品質とはテストで作るのではなく、設計・開発で作り込むべき」といわれていますし、私もそれが正しいと思います。ただ開発者の立場で考えると、「コードを早く作って、早く動かしたい」という考えもあるでしょう。テストファーストでは、こうした定説や、開発者の思いについて、どう考えているのでしょうか？

平鍋　まず前者についてですが、現在のテストファーストでは、「デザインするためにテストをツールとして使う」となっています。コードの中身を最初に考えるのではなく、外側の鋳型が“テスト”になります。インターフェイスに着目できるので、テストファーストでは「Test is Design」なのです。

　品質を上げるためのテストは、やはり設計や一般のテスト工程で作り込むことが必要です。ただし「1回テストファーストを実施し、失敗するテストケースがなければ新しいコードは書かない」というルールを決めれば、全モジュールが完成したとき、一般の単体テストのカバレッジは通っていることになるので、品質も同時に確保できます。

岩出　実装コードを先に書き始めると、「このクラスだったらこういう機能があってもいい」と考えがちですね。しかしテストファーストでは利用するメソッドしか作りません。仕様変更などで次々にコードを追加していき、結局リリース時期を分けるといった選択が取られることもあります。そのような場合に、R1で作成されながら使用されなかったコードにバグが存在していたとすると、R1では問題ないのですが、R2になってそのコードを使用し始めたとたんに動作不具合を起こす、といったことが起こるかもしれません。テストファーストでは必要な時に必要なコードのみを作成するので、そのような問題を起こさずに済むメリットがあります。

黒石　また、開発者の立場に立つと「テストコードと実装コードの両方を書くことで、作業が増えるのではないか」という懸念も生まれますが、後工程でデバッグの時間が削減できます。定量的な数値を出すのは難しいのですが、作業量の増大とはならないと思います。

平鍋　確かに天才的なプログラマは、頭の中にあるものをそのままプログラムした方が早いかもしれない。でも産業プログラムはそういうわけにはいかないので、きちっと最初にデザインを決め、そのイメージをテストコードにしてテストファーストを行う方が、良いものができます。さらにテストコードをペアでやれば、コミュニケーションも円滑になるというメリットもあります。