2010年7月17日に、栃木県北部の西那須野公民館に30名近くの人が集まり、「とちぎテストの会議」が開催されました。本稿では、本イベントのレポートをお届けします。
本レポート写真協力：佐々木揚さん、中内章一さん
深夜のTwitterから始まった、とちぎテストの会議
本イベントは、2月ごろにTwitter上でTDD（テスト駆動開発）をめぐる議論が行われたことが発端となっています。同じ「TDD」という言葉を見たときに想像する内容が人によって大きく異なるらしい、ということがこれらの議論から見えてきたため、「それなら、様々な立場の人を集めて議論してみよう」というところから本イベントが企画されました。
和田さんによるTDD講座
テスト駆動開発の第一人者の和田さん（@t_wada）と、当日発対面のリックさん（Ruby歴1年）によるペアプロ＆TDD講座のデモンストレーションがありました。Rubyの世界でメジャーになりつつある、RSpecを使い、スタックを作る（車窓からのTDD）のサンプルを参考にテスト駆動開発にある5つのステップのデモンストレーションが行われました。
1. テストを書く
まずはテストを書きます。テストを書くときは、結果の比較検証を行うアサート文から先に書き、「これをするためには何が必要か？」と問いながら、最後に初期化処理を書いていきます（アサート・ファースト）。「スタックが空かどうか調べる」では、「スタックは空か？（ stack.empty?.should == true ）」から始まり、次に「じゃあ、スタックが必要だから作ろう（ stack = Stack.new ）」と書いていきます。
2. テストを失敗させる
次にテストを実行し、まずはテストが失敗することを確認します。デモの環境ではソースコードを保存するたびに自動でテストが走り、結果がポップアップするようになっていました。アサートの行の失敗を確認するため、実装が空のStackを実装するところまで行います。
「まず失敗させる」というのは「テストコードがうまく動いているのか？」というテストのテストという意味があるため、一見無駄に見えても大事なステップになります。
3. コードを実装する
次にテストを通る最低限のコードを書いて実装します。最低限なので、ここでは常にtrueを返すように、empty?を実装し、うまくパスすることを確認します。これも「テストのテスト」の一環です。
4. テストが通る
テストが通ることを確認します。
5. リファクタリング
次にテストコードを見て冗長な部分を削っていきます。RSpecにある、テストコードを短く実装するための機能を使ったり、Rubyっぽいコードになるようにしていきます。「早すぎる最適化には注意が必要」とのことです。
1.2. 次のテストを書く
次のテストを書きます。「空のスタックのempty?はtrueを返す」というのを実装したので、次はこれの逆の「空ではないスタックのempty?はfalseを返す」を実装したくなりますが、これを実装するには「データを変更するメソッド」と「内容を問い合わせるクエリーメソッド」の2つが必要となります。データ構造系のテストが簡単そうに見えて、少々大変なのがこの部分です。他のメソッドを先に実装する必要があります。
このような感じで、ペアプログラミングで進行していきました。一人でデモするのとは違い、デモ自体にも途中で間が入るため、とてもわかりやすいデモでした。テンポ良く「次になにをすべきか？」と、キーボードを持っていない側がナビを行ったり、初めての環境でも道に迷わずにコードが書けるというのがおもしろかったです。
ポジショントーク
後半のディスカッションに向けて、パネルのメンバーによる、それぞれの考え方の意見表明がありました。筆者はTwitterのテストの議論をすべて追いかけてはいなかったのですが、ここで行われたポジショントークのおかげで「今TDDの周りではどのような議論があるのか？」というのが明確になりました。
和田卓人さん
和田卓人さん（@t_wada）はタワーズ・クエストの社長であり、プログラマとしてサービスやシステムの開発と提供を行っているプログラマーでもあります。『WEB+DB PRESS』での特集記事やgihyo.jpでの連載など、TDDといえば和田（t-wada）さんというぐらい、著名な方です。
和田さんにとってのTDDは、決して工学的なテストではないが、間違えば即座にフィードバックされるため、心理的な自信を持って開発を行うことができる、というものだそうです。また、Twitter上の議論に関しては、公開の場で様々な人が参加したことに意義はあるが、議論が長く続くということはまだまだコンセンサスが取れていないと感じたそうです。
庄司嘉織さん
Twitter上のTDDの議論のきっかけになったのが、庄司嘉織さん（@yoshiori）のデブサミでの発表で言及された「TDDの目的はテストではなく、TDDは開発手法」という説明からでした。
嘉織（Yoshiori）さんがTDDの効果として考えているのは、公文式と同じく、何度も高速に繰り返すことによる学習効果です。「筋電義手」というものを付けたら、脳は学習して自分の手のように動かすことができるそうです。これも試行錯誤の結果です。テストが良いシステムを作ってくれるわけではなくて、「いいものを作るのは人」であり、その開発者の味方となるのがTDDと考えられているそうです。
井芹洋輝さん
井芹洋輝さん（@goyoki）はTwitterでの議論を分析して、「どこで議論がすれ違っているのか？」という原因を分析し、議論が空中戦に陥らないために、「スキル構成」「利益」をモデル化して紹介されていました。
スキル構成は、Kent Beckやt-wadaさんが語られているような、TDDの進め方を「原則」、次により効果的なテストの書き方に関する「運用」、そして継続的インテグレーションとの組み合わせなどの「活用」の3つであることを示しました。
利益に関しても、TDDそのものがもたらす「直接利益」と、テストが容易になるなどの「副次的効果」、そして品質アップの一部には貢献するが、完全に保証するわけではないという「一部サポート」の3つを挙げていました。
井芹さん自身は、品質改善の分散担保という意味で、プログラマーレベルのTDDと、後段のテスト工程の両方を重ね合わせるのが良い、と考えられているそうです。
関将俊さん
今回のイベントの発起人の咳さん（@m_seki）は、さまざまなテストのイベントに（ヒールとして）呼ばれることもあり、テスト系の知り合いも多いため「HUBとして、周りの人を繋げたい」「同じ時間、同じ場所で顔を合わせたい」と思われたそうです。
テストというのは設計やコードが正しいかどうかを破壊しに行く必要があるが、TDDにはそこまで品質を確認しようという破壊的な意図を感じないそうです。また、TDDは名前が微妙であり、テストを先に書くのは「（補助線を書くための）定規」であるが、その線が本当に欲しい線かどうかは分からないし、保証もない、と述べられていました。人間はいつでも間違える可能性があり、通ってきた道を確認するテストスイートとして意味があるとのことですが、TDDをプロセスとして考えると、XPなどとは異なり、プロセス自体に対する破壊（更新）がないところが不十分とのことです。
ライトニングトークス
パネルディスカッションの前に、ライトニングトークスが行われました。
庄司嘉織さん
嘉織さんによる、ネタ満載の動画による発表でした。映画の台詞（元はドイツ語）とは関係なく、TDDに関する台詞を字幕でつけていました。
「BDDとは何だ？」「TDDの言葉を換えただけじゃないのか？」「振る舞いなんて言葉は使わないから感覚的に分からない」という、嘉織さんの気持ちをストレートに代弁したものでした。確かにBDDは言葉を換えることでTDDのテストという言葉で生じる誤解を減らそうというものですが、コンセンサスを得ているとは言えない要因が、この動画で語られたようなところにあるのでしょう。
森田尚さん
オーム社でさまざまな書籍を手がける森田尚さんによる発表でした。書籍の作業にも、ソフトウェアのさまざまなプラクティスを応用してみました、とのことです。そのままソフトウェアに応用できないモノも数多くあり、まだまだ色々試行錯誤中とのことでしたが、評判が良かったり、効率が上がったり、質が上がったというのを実感されているそうです。
秋山浩一さん
秋山浩一さんは、大きめのシステムでバグが1つしかなかったというSmalltalk-80における経験から、バグの削減に効果のあるSmalltalk-80の開発環境、習慣、フィロソフィーなどを分析されていました。
eXtreme Programmingの出発点となったC3プロジェクトもSmalltalkだったということで、テストなどのいくつかの共通点はありましたが、バグが発生したらその場でエディタが起動して修正して継続実行できたりとか、開発者同士のお披露目など、「ワイワイ感があった」とのことです。
stsuboiさん
咳さんと同じ会社に勤めているstsuboiさんによる、「賢者」咳さんの分析の発表です。
賢者を捜し出すことで、さまざまなことが学べる。ただし賢者を見分けるのは難しい。初見の人には一見電波系でありなかなか区別が付かない。山の上に住んでいて、たまに下界に降りてくる。また、メーリングリストでは自らの発言はほぼせず、他者のメールに返信を返す程度。しかもそれは一見KYに見えるため、的を得た返答が帰ってきたと思えることはあまりないが、落ち着いて眺めると本質的な問いかけであることが多いという、様々な賢者の分析が紹介されました。
後半の資料を見ると、賢者のシンプルかつ鋭いツッコミの事例の紹介が多数出てくるのですが、時間切れでちょうど「KYっぷり」の紹介が大多数になってしまいました。ですが、それもまたライトニングトークスです。
小笠原秀人さん
テストをとっても楽にするツール（TETRA）などの開発も行われてきた小笠原秀人さん。新規製品開発のプロジェクトにおけるテストマネージャの仕事とテストについての話がありました。
重要プロジェクトであれば、かなり上の方まで報告する必要があるため、メトリクスプログラムを構築して定期的なデータの収集と分析が大切になります。実際には、仕様変更やテスト環境上で動かないといった状況があり、テストは予定どおり進まないこともあったそうです。スケジュールに関する予定と実績の見せ方に苦労したそうです。予定の変更をうまく吸収して進捗グラフを作成することも必要とのことでした。テストは最終段階のプロセスなので、スケジュールに乗っているかどうかよりも、裏を取るのが重要とのことです。
太田健一郎さん
太田健一郎さんからは、イベント駆動開発（EDD）が紹介されました。別名デスマーチ？すべてがイベント（部長の行動）で駆動され、部長の満足という個人的要因でプロジェクトの意思決定がなされる。部長の発言ですぐにタスクが大幅に変わり、変化を抱擁できない。WBSもない。開発側のプロジェクトリーダーが何人も倒れ、SE残酷物語を地で行くような内容でした。おそらく、資料の公開はないでしょう。
坂田アキノリさん
坂田アキノリさんからは、メインフレームのテストが紹介されました。特にテスト工程という名前ではなかったのですが、3つに分割された工程が開発の途中にあり、その中で単体テストなり、結合テスト相当ものを担当されていたとのこと。ただし、担当されていた内容がOSの資源管理に関する部分であり、単体で動作させても分からないため、すべてをくっつけて丸ごとステップ実行をして、マシン語を見ながらデバッグされていたそうです。
パネルディスカッション
イベント後半に入り、Twitter上で行われていた議論からいくつかのトピックをピックアップし、それを下地に、パネルの4人と参加者で自由にディスカッションを行って議論を行いました。
TDDはあくまでも開発手法
「TDDをやればすべてうまくいきます、品質も良くなります」というマーケティングをしたために、TDDが一人歩きをしてしまったが、「TDDはあくまでも開発手法である」という論点で議論が行われました。
嘉織さんからは、「同じコトを何度も繰り返すのは大変。TDDなら簡単に繰り返せる。世の中でTDDがどういわれているかは関係なく、面倒だからテストをやっている」という意見が述べられました。井芹さんからは、副次的効果を除いて、原則に限定すれば確かにそうだという話がありました。
「TDDが品質にどのように貢献できるかを示せないのが、問題なのではないのか？」という意見に対しては、リックさんが「品質というけれど、どの品質があがるのかが曖昧」と述べると、「品質と言っている人ごとに品質の定義が違う。Twitter上の議論でも、みんなが大事だと思っているが、ここが統一されていないのが炎上した原因だろう」など、さまざまな意見が出ました。
咳さんからは「テストはあくまでも見つける技法」「コード修正をしなければ品質はあがらない。テストだけでは品質は上がらない。直す人に伝えるのもセットのはず」という意見が出ました。
また、嘉織さんからは「どのような開発手法も品質を上げるのを目的としていて、下げるのを目的としているものはない。品質が上がる副次的効果があるのは当たり前のこと」と、まとめていました。
TDDは単にコンパイル通りましたという感じ
「静的言語であれば、コンパイル時にある程度型チェックなどが行われますが、TDDのテストはそれと同じような水準ではないか」と咳さん。動的言語であればコンパイルがないため、テスト駆動開発をすることで多くのミスが発見できます。「Javaなどのコンパイル言語でTDDをする必要はあるのか？」という疑問に関しては「使う人が多かった」「動的言語のように気軽に動かせないから」という意見が参加者から挙がっていました。
また、ここに関しては和田さんからは、型推論がしっかりした関数型言語が広まれば、必要性は少なくなるのではないか、という意見が出ました。
嘉織さんからは「gccではWarning Optionを設定すれば親切にさまざまな情報を教えてくれるが、TDDはそのようなWarning Optionをみんなで共有している感じに近い」というコメントも述べられました。
品質管理とはプロセスの微調整を繰り返すこと
品質管理のプロセスにおいて繰り返すべきはデバッグではなくて、行動の修正である、という話が咳さんからありました。これは生産工場では当たり前のことで、どんなに設計図を丁寧に引いたとしても、製造機械のくせに合わせて現場で調整が必要です。
逆に、品質管理においてどうでもいいことは、手順を守ることと、バグの数で管理すること。手順は壊されるべきであるし、工程の数字にはどうしても本音と建て前が混ざってくる。果たして、これらを守っている人は「本当に役立っているのか？」という意見が出ました。
TDDしたからバグがありません、は本当か？
昔、「TDDをやったからバグがありません」と納品してきたが、やはりバグ残っていた、というケースがあったそうです。それに対しては「TDDは自分でやるテスト」「自分で『できた』というのは信用できない」「TDDをやれば軽微なバグが減るので、テストケースを実行する回数は減らせるが、テストケース数は変わらない」という意見などが出されました。
TDDのメリットは？
TDDのメリットは「めんどくささが減る」というのが挙げられました。
「TDD導入の障害として挙げられるのが契約。TDDを導入すると、後工程の工数は下がるが見た目の工数は上がってしまうため、契約の中に入れるのが困難となる」という話が出ましたが、和田さんがスライドで紹介したアメリカの研究データによると、大手企業への導入の結果、工数は2～3割増えているが、おおむねバグ密度が0.1～0.6倍になっているという統計が出ているそうです。
バグ密度という数値はやっかいで、「この行数であればこの数のバグがリストアップされていなければ納品を認めない」という大手企業もあり、「昔、バグをねつ造して納品したこともある」という人もいました。そもそもバグ密度に関しては「作業者と作成する対象、言語や手法などのさまざまな要因で変動するはずのものなのに、定数を強いるのは科学的とは言えない」など、冷淡な意見が相次ぎました。バグ密度を強いる会社に対しては「そもそも指標が変なので、（品質の高いソフトウェアと、ねつ造したリストと）2種類の納品物を用意すべき」「ねつ造OK」「勝てばよかろう」と盛り上がりました。
「（契約の中に）品質アップに関するインセンティブがあれば、このようなおかしなコトにはならない」という意見が最後に参加者の中から出されました。
一般的なテストの技法があればTDDはもっと良くなる
スモークテスト、ディシジョンテーブルなどテストに関する技法を知っていれば、TDDがより便利になるという意見が太田さんから出されました。「そもそもディシジョンテーブルなどは、昔は設計技法でもあったため、設計の中でテスト方法の確認もきちんと行われていたはずである」「前工程と後工程でチームが違うからといって、技法まで分かれているのは変」などの意見が出ました。
「開発がより幅広いテストも見てくれれば手戻りが減る」という意見に対して、咳さんから「開発にとっての後工程は明日の自分」という意見が述べられ、きちんとしたTDDをすれば、後工程と開発者の両方にメリットがあることが確認されました。
ディスカッション後
ディスカッション後、参加者参加のワールドカフェ形式での議論が行われました。ですが、ディスカッションで予想外に時間を使ってしまったために、ライトニングトークスのトーカーごとにテーブルに分かれ、手短に様々な意見交換を行う形になりました。その後は、参加者一人一人が感想を述べて、懇親会に移りました。
イベントの企画通り、パネラーだけではなく、会場の人も含めてみんなで意見を言い合う場となりました。最近ではTwitterやUstreamなどで擬似参加できるイベントも増えてきていますが、テストの場合はテーマの都合上、外に出すのが難しい情報も出てくることが考えられたため、動画配信などは行いませんでした。その代わりに、その場にいる人でなければ体験できないような、貴重なイベントになりました。参加した人もみな、良い刺激を受けたようです。
本イベントが呼び水になって、イベント終了後もTwitter上で議論が行われたりしました。
