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

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

テストファーストのデメリット

新野　テストファーストのデメリットとは何でしょう？

平鍋　言語によるかもしれませんが、C++のような“堅い”言語の場合、includeファイルの依存関係が深くなるため、難しかったという経験があります。依存性が深くなると、いろんなクラスが集まった上の部分ではコンパイルが多くなり、時間がかかりました。結局、テストコードのメンテナンスと開発速度をそいでしまったのです。

黒石　私の場合、開発者の性（さが）かもしれませんが、今度は「テストコードをどう完ぺきに作るか」という志向に走ってしまいました（笑）。テストファーストの深みにはまると、今度は実装コードの方がおろそかになるので、そこはバランス感覚が必要でしょう。

頻発する仕様変更にどう対応するか

新野　受講者の方に事前アンケートを取り、質問したい事項を書いていただいたので、今度はそれを紹介しながらテストファーストの実践について考えていきましょう。まず「コードを書いている最中に仕様変更が起こってくる場合にも、テストファーストは可能か」という質問が来ているのですが、これについてはいかがでしょうか？

アークウェイ 黒石高広氏

黒石　毎日仕様変更が発生するのならば、確かに追い付かないと思います。ただ要求が安定しない場合には「なぜ安定しないのか」「どうすればいいのか」を考えていく必要があります。

　私の場合は、先にプロトタイプやモックアップを作って提出することで、要件のズレを最初の段階で徹底的につぶす。テストファーストだけですべて解決しようとはしていません。

平鍋　私がXPを導入している案件では、完全にクライアントを巻き込んでいるので、タイムボックス化により「この期間で、ここまでリソースする」という形で、その都度交渉しています。

岩出　私も平鍋さんと同じ考えです。ただテストファーストの領域と、プロジェクトマネジメントの領域があって、タイムボックスは後者の範囲でしょう。

　よくいわれるように、XPは現場の実践的な方法論であって、プロジェクトマネジメントについてはほとんどカバーしていません。そこで、XPと同じアジャイル開発の1つである「SCRUM」と組み合わせることで、XPのプロジェクトを効率的に進めていくという方法もあります。SCRUMの中に、タイムボックスと似た「スプリント」という考え方があり、「スプリントを実行している最中には変更要求を受け付けない」というルールを定めています。つまり、最初に決まったスプリントに対して全速でコードを書いていけばいいという保証が得られるんですね。こうしたルールを決めて、開発者を守ることが必要だと考えています。

黒石　私もSCRUMは大好きな開発手法で、中でも「SCRUM Masterによるファイアウォール」というプラクティスには共感しています。SCRUM Masterとはプロジェクトリーダーに相当し、「むちゃな要求変更が開発チームに届かないように、SURUM Masterがブロックしろ」といっているのです。これが難しいことは、重々承知しているのですが、こうした方法も有用ですね。

テスト粒度のベストプラクティスは「ない」と心得よう

新野　さらに事前アンケートでは「テストの粒度をどの程度に設定すればいいのか」という質問も寄せられました。これについてはいかがでしょう？

マイクロソフト 岩出智行氏

平鍋　JUDE開発の一例を紹介しますと、3段階に分けています。まずデザインのリズムを作るために単体テストを作ります。これは1つのメソッドに付き、大体3つほど。これをブレイクダウンして、1クラスに付き1テストクラスのようにし、全メソッドをテストするテストケースになります。

　次に中間粒度があります。「あるクラス群が一連に動いて結果が出るもの」で、アセンブリテストもしくはコマンドテストと呼んでいます。

　そして最後に受け入れテスト。メニューのボタンを押し、処理がどのように流れているか、データの状態や表示はどうなっているかを確認するテストですね。

黒石　ツールの機能になるのですが、カテゴリを付けることで動かすテストを選ぶという方策もあります。粒度については平鍋さんと同じなのですね。

永和システムマネジメント 平鍋健児氏

岩出　私がVisual Studio 2005単体テスト機能をお客さまに説明していると、必ず「粒度やカバレッジ率はどれくらいか」「ベストプラクティスはあるのか」と質問を受けます。正直に答えると、当社の中に「統一されたベストプラクティス」はありません。その代わり、Windowsのクライアント開発チーム、サーバ開発チーム、Microsoft Officeの開発チームと分け、それぞれで「Engineering Excellence」という活動を実施しています。これは「よりスマートなエンジニアとして働けるように知識を共有しよう」というものですが、そこでいろいろなメトリクスを取っています。ただ、各チームによってメトリクスも評価基準も異なるので、カバレッジ率や粒度も異なります。

　まず考えていただきたいのは、「ソフトウェア全体としてどれくらいの品質を設定しているのか」ということです。品質のしきい値を設定し、次にメトリクスを測る。例えば1メソッドの中に複雑なロジックを書いているのであれば、粒度を細かくしてカバレッジ率を上げるといった工夫が必要です。このように、先にゴールを決めるのが良いのではないでしょうか。

新野　ここで会場に質問してみましょう。現在、「会社の方でメトリクスを測ったり、もしくは品質指標を決めている」という方、具体的にどのような指標をお使いでしょうか？

受講者B　当社の場合は、ラインごとのバグの件数を取っています。

受講者A　かつて品質学会などでは、ファンクション・ポイントを適用するといったカバレッジの範囲設定がメインでした。現在は当社も、設計を固めるためにスパイラル開発を導入していますが、「単体テストでバグが出ないだけで本当にいいのか」という疑問もありますね。例えば新幹線や原子力発電に求める品質と、家電に求める品質が違うように、指標と求める品質の間にはギャップがあります。ここをどうすべきか、いつも考えている状態ですね。

テストコードを成果物として提出できるのか？

新野　仕様が決まってからテストコードを書くまでの間に、何か成果物は必要なのですか？

黒石　私の場合はクラス図です。クラス図を基にイメージを固めます。

平鍋　私の場合、XPの「ストーリー」（ユーザーの言葉で書かれた仕様の1単位）をタスクに分解し、さらにそのタスクをクラスに分解して1クラスくらいのものにして、テストコードに入ります。ちなみに、この分解作業が「デザイン」なんですね。

岩出　なるほど。そこで平鍋さんに質問があります。前職で私は「モデルで設計する」モデル駆動開発を実践していました。一方、テストファーストでは「テストで設計する」といっていますが、両者が衝突することはないのでしょうか。

平鍋　個人的には、複数のクラスが動いているトップレベルに近いところからの設計は、テストファーストでは不可能だと考えています。「テストファーストでどこまでデザインするか」ですが、「どのようなメッセージが流れるか」はもっと上のデザインの範囲で、そこはテストファーストの設計とは違うと思います。テストファーストはもっと具体的な1クラスくらいの単位で考えた方がいいのではないでしょうか。

岩出　するとトップレベルのデザインは、スコット・アンブラーの書籍「アジャイルモデリング」に出てくる「捨てるモデル」と同じですね。すると、ここで1つ問題があります。最近はユーザー側にもUMLが浸透しており、UMLの成果物が欲しいというケースが増えています。捨てモデルだとアップデートしないので、最終的にシーケンス図も含めて全部書き直さす必要があるのではないでしょうか。最も良いのは、テストクラスを設計図として納品する方法ですが、どこまでクライアントの理解が得られるか未知数ですし……。

平鍋　その場合、例えば最初のうちは捨てモデルを手書きし、仕様が固まってからツールで図に落としていくという方法もあります。一番良いのは、ソースコードがテストの中にあることです。ただそうはいっても、ソースコードを全部読むのは難しいので、ソースコードに反映できない意図などは仕様書に残す。さらに、アーキテクチャを含めた設計のアウトラインを最後に出すというパターンが多いですね。

テストファーストに必須のツールたち

新野　テストファーストのために、これだけは必要なツールというのはありますか？

黒石　.NETの場合、NUnitなどのテスト環境があればなおいいでしょう。あと、最近では「MocObject」というコンポーネントを使用しています。テストファーストの場合、まだ開発していないコードを呼んでテストを走らせることもありますが、MocObjectを使えば仮の値を返してくれるので、効率的にテストを進められます。

平鍋　Java開発の場合はJUnitでしょう。またJUnitのテスト結果をきれいに整形する「JUnit Report」も便利です。ちなみにこれはNUnitでも同様のツールがあります。またソースコードを管理する構成管理ツールやバグトラッキングシステムと組み合わせると、さらに有効でしょう。

岩出　有償のツールであれば「Visual Studio 2005 Team Suite」の中にも単体テスト、結合テストを実行する機能があります。フリーならば、黒石さんや平鍋さんが紹介したツールもいいですね。

　ちなみにVisual Studio 2005 Team Suiteは、当社で利用していたチーム開発の環境を商用レベルにグレードアップしたものですので、さまざまな「効率的に開発を進め、品質を保つ」機能が搭載されていますから、ぜひ試していただきたいと思います。

たまにはジョークで頭を休めよう

新野　では最後に、パネリストの方々が参考にしている書籍や、アジャイル開発の最新動向についてお願いできますか。

黒石　タイトルだけ見ると超初心者向けの本のようですが、実は中身が濃くてお勧めしたいのが「はじめてのアジャイル開発」です、XPやSCRUMなど最新のアジャイル開発プロセスが紹介されています。ぜひご一読ください。

岩出　私は個人的に、スコット・アンブラーの「アジャイルモデリング」という本が非常に気に入っています。正直なところ、読むのが苦痛になるほど冗長性が高いのですが、でも考え方としては非常にシンプルなので、一度ご覧になってはいかがでしょうか。またMS Pressからも、テスト駆動開発の解説書などが出ているので、そちらもぜひ参考にしてください。

平鍋　好きな本はたくさんあります。テストファーストであればケント・ベックの「テスト駆動開発入門」もお勧めですし、あとマーチン・ファウラーのブログはいつも読んでいます。

　また最近非常に面白かったネタは、アジャイル開発の対抗馬として再び注目され始めた「ウォーターフォール」について、「Waterfall 2006」というイベントが4月1日にナイアガラの滝で開催されることです（編集部注：このイベントはエイプリル・フールに引っかけた冗談です）。ここでは新しい手法として、2人のマネージャーが1人のプログラマに付く「ペアマネージング」や、「テストは、したいときに実施すればOKであり、そうでないなら飛ばせ」といった斬新なプラクティスが発表されるようです。これは1つのジョークですが、たまにはこうしたサイトを見て、頭を休めるのも一手ではないでしょうか。

「「ITアーキテクト塾」レポート」バックナンバー

• テストファーストでユーザーも開発者も幸せに
• ビジネスモデリングと“見える化”のいま