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

いかに生産性を上げつつ、高品質なソフトウェアを開発するか。この究極の課題に応えるのが、「テストファースト」だ。「＠IT ITアーキテクト塾」第2回では、テストファーストの概要、メリットおよびその実践について、会場と講演者を交えてディスカッションを展開した

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

通常のテストと「テストファースト」の違い

　セミナーの第1部は、アークウェイの黒石氏による講演「テストファーストの実践」。黒石氏はマイクロソフトのコンサルティング本部を経て、現在は.NETを中心とするコンサルタントとして活躍している。マイクロソフトに所属していたとき、顧客企業が先行して実践していた「テストファースト」に衝撃を受け、これがコンサルタントとして独立する契機になったそうだ。

　では、そのテストファーストとはいかなる手法なのか。黒石氏は冒頭で「一般的なテストとは、システムに何らかを入力し、バグを見つけ出すこと」と説明し、「こうした一般的なテストと、テストファーストの“テスト”とは少し意味が異なります」と注意を促す。通常のテストが「バグ検査」であるのに対し、テストファーストのテストとは「書いたコードが仕様どおりに動くかどうか確認する」こと。各人が、自分の担当する個所の動作を、確認しながらコーディングすることで、仕様どおりのソフトウェアが保証できる。これがテストファーストだ。

　テストファーストが生まれた背景は何か。「そもそも一般的なテストには、『コストが掛かる』『バグを完全になくすこと不可能』という事実があります。予算、人員、期間など限られたリソースの中で、高品質なシステムを開発するには、どうしてもテスト戦略が必要になる。例えば顧客情報システムの場合、個人情報保護の観点からセキュリティ個所を重点的にチェックする、というように、戦略的にテスト範囲を選択しなければなりません。そのうえでテストファーストは、単体（ユニット）テストと回帰テストを効率化する極めて有効な手法なのです」（黒石氏）。

　テストファーストは「プログラムが、テストコードに記述した振る舞い（仕様）どおりに動作するか」を確認しながら、少しずつコーディングを進めていく。このことから黒石氏は、テストコードを“動く仕様書”という言葉で表現。ちなみにテストファーストは、その語感から「テスト計画を先に立てる」「テスト工程を先に実行する」と誤解されることが多いため、最近では「テスト駆動開発」または「Behavior Driven Development」（振る舞い駆動開発）と呼び方を変えるべきだという議論もあるそうだ。

テストファーストを支える4つのプラクティス

　 テストファーストでは顧客要件を基に仕様を固め、テストコードを書いていくが、設計せずにいきなりコード策定に入るわけではない。黒石氏も「システム全体の設計図やクラス図などがないとコードは書けない」という。ただし設計の際も、コードの中身からシステムを考えるのではなく、ユーザー要件を忠実にクラス図で表現し、動作イメージを固めながらテストコードを策定するため、設計段階から品質を作り込むことが可能になる。

　実行したテストコードが通らなければ『レッド』という状態になり、実装コードを修正する。一方、テストが通った状態は『グリーン』と呼ぶ。ただしテストが通っても、可読性を考えてコードをきれいに整えることも多い。テストファーストではこの修正作業を『リファクタリング』と呼んでいる。

　ここで「仕様変更が起こった場合、どうすればいいのか」という疑問がわいてくるだろう。これに対し、黒石氏は「テストファーストを実践し、より高品質なシステムを開発するには、XPで規定されているほかのプラクティスを組み合わせることが必要になります」と説明。具体的には「タイムボックス化」「週40時間労働」「ペアプログラミング」「常時結合」だ。

　タイムボックス化とは、定められた一定期間内でどんな作業をすべきか決めること。前提条件となるのは、クライアントから出された要件を基に、期間と作業内容を策定していく。決められたタイムボックス内では「仕様変更を行わない」などクライアントと合意を取り、開発を進めていく。

　次に「週40時間労働」とは、「無理なく仕事ができる労働環境が整わなければ、高品質は望めない」ということだ。XPの提唱者であるケント・ベックは、この原則をXP初版で「週40時間労働」と表現していたが、最新版では「人間性の原則」と変更している。「なぜかといえば、徹夜続きの労働環境では、どのようなテスト手法を用いても品質を保つことは困難だからです」（黒石氏）。

　そしてソフトウェアの品質向上に直結するのが「ペアプログラミング」と「常時結合」の2つ。ペアプログラミングは「2人のプログラマが1つのプログラムを開発する」プラクティス。自分の書いたコードが常にレビューされることにより、コードの質が向上する。常時結合とは、例えば1日1回ソフトウェアを結合テストを繰り返すことで、品質を確保する手法のこと。これには複数の開発者による作業のズレを解消するという効果も期待できる。

　さらなる品質向上を目指すのなら、開発者とテスト担当者の協調関係を保つことも重要だ。具体的には「開発者が仕様どおりに動くコードを保証し、テスト担当者は従来のようにバグを発見することに注力する。そのためテスト担当者は、テストコードをどのように追加していくかを考えなければなりません。XPでも、テスターという担当者を規定しており、顧客と折衝して品質レベルを調整しつつ、テストを実行する役割を重要視しています」（黒石氏）。

テストファーストで得る「安心感のある生活」

　テストファーストにより、どのようなメリットが生まれるのか。黒石氏は「どこに影響が出るのかをあらかじめ理解することで、安心してプログラムの修正に取り組めるようになったことが最も大きい効果です」とし、続けて「長い休暇から戻ってきたときも、休み前の進ちょくをすぐ確認できること、そして顧客先など異なる環境でもテストコードを実行することで、プログラムの動作を確認できることなど、安心感が得られるのがテストファーストのメリットでしょう」と述べた。

　「とはいえ、開発現場はやはり技術者の資質に負うところが大きいのも事実です。品質改善のため、長期的な視野に立って、技術者の育成、スキルアップを支援してください」（黒石氏）。

　さて、うまくはまれば「いいことずくめ」といえるテストファーストだが、実際にこの手法を適用している事例はあまり聞かれない。もし導入が難しいのであれば、その原因と対処策は何なのか。第2部では、テストファーストのメリット／デメリットを含め、導入のポイントと対応策について、3人のパネリストと会場の間で活発な論議が行われた。