レポート

「とちぎテストの会議」レポート

この記事を読むのに必要な時間:およそ 5 分

パネルディスカッション

イベント後半に入り,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上で議論が行われたりしました。

著者プロフィール

渋川よしき(しぶかわよしき)

社内SE。ソフトウェアを中心に,ライフハック,インラインスケートなど,様々なコミュニティの運営に関わってきた。日本XPユーザグループには設立準備の時から。現在メインのコミュニティはとちぎRubyとPython温泉(系)で,ドキュメントツールのSphinxのコミュニティの設立準備中。趣味は技術文書の翻訳とLT。

Twitter:@shibukawa

ブログhttp://blog.shibu.jp