[わんくま同盟 名古屋勉強会] 第3回 - アンケート

7月 26日の わんくま名古屋勉強会 第3回 で、 みなさんに書いていただいたアンケートです。
全部にお返事できなくてもうしわけないんですが、 いくつかにはコメントさせていただきました。 ( 「⇒」 で始まる行です。 )

◆ 全体アンケート

・ TDD についてもっと深くつっこんで欲しい
⇒ 仕様書から、 個々のクラスやメソッドの仕様を考える話。 リファクタリングの話。 TDD の効果や、 従来のテストとの関係についての話。 …いろいろありますが、 勉強会の 1セッションとしては、 ちょっと重過ぎるかなぁ、 と。 あ、 リファクタリングパターンあたりは、 いいかもしれませんね。

・ 全体的には雰囲気として面白いと思います。

・ すごく、 ありがとうございました。

・ お代はみてのおかえりなんて安すぎます。

・ 笑いあり、 涙なし、 勉強にもなる楽しい勉強会でした。

・ 次回も期待しています。

・ MISAO についてですが、 いつも楽しいし盛り上がるしすごくいいと思うのですが、 「スピーカーさんの話と全く異なる話題でつなげる」 「馬鹿とか、 アレはダメ、 とか取りようによっては不快になる内容 （今回けっこうありましたよね？） については自粛するようにお願いして頂けませんか？ 今回、 biac さんのお話の最中、 ちょっと気の毒でした。 一番聞きたかった内容だったので残念でした。
⇒ 今回、 ズレた話題がチャット側で盛り上がってましたね～。 時間に余裕がなくて、 フォローできなくてすみませんでした。 ( もう少し、 初音さんのページにコメントしました。 )

・ 良かったです。 biac さんのプログラムの育て方、 作りやすく、 バグ、 失敗させやすくなるなど、 貴重な話を聞く事ができた。
⇒ ありがとうございます。 TDD に興味を持ってもらえたなら、 Web の記事や本を探してみてください。 私が発明した技法なんて何も無くて、 本に書かれていたことなどを実践してきて、 それを紹介させてもらってるだけですので。

・ 出てほしいゲストって、今回出た人から選ぶとすると、鶏唐揚さん、biacさんです。
⇒ これまた、 ありがとうございます。

・ 組み込み系の話題を増やしてほしい。

◆ セッション別アンケート

Q1.セッションの内容は期待通りでしたか
    172.2
Q2.セッションの内容は理解できましたか
    144.4
Q3.このセッションを知り合いなどに伝えたいと思いますか
     166.7

⇒ わりと好評だったようで嬉しいです。 ただ、 やはり詰め込みすぎたため、 分かりにくくなってしまったようですね、 反省。
※ あのスライド資料の分量は、 普通に話すと 3～4時間分あるんですよ。

・ 先に苦労するか、 後で苦労するかですね。
⇒ はい。 で、 後の苦労は、 たいてい大騒ぎ  f(^^;

・ TDD を順を追って説明してくれたので分かりやすかった。 現場のメンツ全員に聞いて欲しい内容でした。

・ えムナウさんの指摘然りだと思いました。 私的に怖いのが、 テストが通った事自体が心理上の楯な存在になる事。 テストが通る＝自分の期待が通る≠「すべての」事例が通る、 という事を心にとめないと危ないかと。
⇒ 自分が思いつくことの出来たテスト 「しか」 通っていない、 ということを忘れるとダメですね。

・ テストは重要ですね。

・ *** の方がみなさんお優しい、またわかりやすく丁寧な説明をされるのは、biac様に原点があるのかなーと思いました。勉強になりました。
⇒ ( "***" は社名、 いちおう伏字に。 ) えーと… いやたしかに、 少し教えたことはありますが… f(^^;

・ 組み込みの経験がないので、 難しかったですが面白かったです。

・ やはり開発プロセスに基づいて説明して頂けるのは判り易くて良かったです。

・ テストファーストスタイルのプログラミング方法が良く分かりません。

・ これを実際に現場で使えるような知識にすることを （自分への） 宿題にしてみます。

・ 話題にしてみたいです。

・ NUnit も使ってみたいと思っていたので、 初歩から教えていただけたので勉強になりました。

・ 勝手に理想の上司No1の座に据えさせていただきております。 biac さんのセッションを聞いた後は NUnit とか入れてないけど、 テストに対するモチベーションが上がります。

・ 社内で NUnit を使うとあると、上司に NUint を使う事の優位性を説く必要があるのですが、 ソースにテストコードが入ることや結局はそのテスト結果が信頼できるということを証明するために今までと同じように手動で動作させる必要があるんでは？
⇒ ソースにテストコードが入る :
NUnit や Visual Studio の場合、 製品コードとテストコードは、 別のプロジェクト ( 別々のバイナリ ) に分けることができます。 今回のサンプルコードもそうなっていますので、 ご覧ください。
また、 納品するときに、 テストプロジェクトを外すこともありますよ。
⇒ 今までと同じように手動で動作させる必要があるんでは？ :
もちろんです。
これは、 TDD を語る時に、 これまでのやり方と違わない部分は説明しないのが ( 私も、 今回は端折りました f(^^; )、 よろしくないのだとは思いますが、 テストファーストで製品コードを作ったからといって、 それ以外のテストが一切不要になるはずはありません。
例えば MSF Agile ver.4 でも、 TDD を取り入れていますが、 テストチームによるテストもちゃんとあります。
テストファーストによる不具合の削減効果は、 結合テスト 2回分くらいのものです。 けっして不具合がゼロになるわけじゃありません。

・ ピンとこなかったので何か作ってみます。

・ 自分もテスト手法についてマスターして、 会社の品証担当にすすめたいと思います。

・ 一度、じぶんでも試してみたいと思います。

⇒ ( いくつかの質問に、まとめて ) テストファーストで一番難しいのは、 詳細なテスト仕様を、 しかもブラックボックステストとして、 考えなきゃいけないところのようです。
とすると、 導入するにあたっては、 チーム内にそういうスキルがあること、 という条件がクリアされている必要があります。
個々人の勉強の指針としては、 自分の書いたコードの正当性を示すにはどうすればいいか、 という視点をもって、 テストについての参考書を学ぶこと、 でしょうか。
あと、 身近にバグの少ないコードを書く人が居たら、 「自分の書いたコードの正当性をどうやって確認していますか?」 と尋ねてみてください。
テストファーストしてるとは限りませんが、 おそらくはかなり細かい単位で、 正当性をチェックしているはずです。 その技法や考え方を教えてもらうことができれば、 必ずプラスになりますよ。 ( ただし、 言葉でさらっと説明してもらえるとは限りません。 私も、 たとえば、 クラスの粒度をどうやって決めてますか、 という質問には、 他人に分かるように説明できません。 )