第十三回 アジャイルサムライ読書会 埼玉道場に参加してきました（TD

　最近、仕事でもプライベートの方でも色々忙しく、勉強会にも月イチがせいぜいな
感じで参加するのがやっとという感じで、ブログもサッパリ更新できず、、、悶々と・・・
長くなるので（略）

　さて、お題の通りアジャイルサムライ読書会（埼玉道場）に参加してきました。

（「ざっくり」とまとめたつもりが、、、エラく長くなってもた。。。orz）

「第十三回 アジャイルサムライ読書会」
http://bit.ly/1BGPIVm

今回はTDDの章という事もあり、ゲストは t_wada さんでした。
⇒　どうやら第1回目のジョナサンがゲストに来てくれた時以来の大入りで、
　　15名の方々の参加がありました。

　流れは例の如く、今回は14章のテスト駆動開発の章を音読し、
チーム内で出た疑問をふせんにまとめ、それを全体でドット投票して
ネタを厳選して議論するという流れでした。ちなみに今回は
A卓、B卓、C卓の3卓に別れ、各テーブル5名ずつで進める事になりました。

　で、以下簡単にメモからの抜粋を。

【チーム内で出た話】
「お題：不慣れな言語でTDDを始める時はどうすればいい？」
　⇒　・RubyならRuby、JavaならJavaで書き方にクセやセオリーがあるので
　　　　良いお手本になるようなソース（例えばOSSとか）を読んだら良いと思う。
　　　・いきなりTDDを始めようとすると（本にもある通り、TDDは色々な技術の
　　　　集大成的なところがあるので）ハードルが上がるので、まずは
　　　　デバッグ的に始めてみるのはどうだろう。

【全体で議論した話】
「お題：TDDを習慣化させるコツは？」
「お題：ユニットテストを書く時や書かないときのムラを無くす為には？（メンタル的・技術的に）」
「お題：テストコードを書かない職場の雰囲気を変えるには？」

　⇒　参加者の皆さんから幾つかの回答が出ました。
　　　・TDDが始まった時のキッカケは、お金に直結する部分でバグが出て
　　　　大騒ぎになったから。
　　　・設計が整理できて、コードを書く時間がトータルで見ると減った。
　　　・リファクタリングが躊躇無くできるようになった。
　　　・全部に対してテストコードを書こうとしない。
　　　・テストファーストにこだわらない。
　　　・2人目の自分を作る
　　　・デプロイメントパイプラインを作ってテストコードを書かないと
　　　　コミットできないような仕組みを作る。
　　　
　t_wadaさんのまとめ
　　⇒　ざっくりまとめると、「1．TDDを導入するまで（キッカケ）」と
　　　　「2．TDDを導入した後の継続」の2つのフェーズに分かれる。
　　　　
　　　　1．については参加者からも話があったが、
　　　　某Coo●●ad社も以前はテストコードがゼロだったが、一度
　　　　お金に関わる部分でバグを出し、それから書くようになった。そういう
　　　　「痛い目に遭って」改善されるというパターンがある。
　　　　
　　　　2．については、リファクタリングのタイミングが分かりやすくなる
　　　　というメリットが継続のモチベーションに繋がる場合がある。
　　　　また、2人目を作るのは重要。その時は「TDD」ということだけではなく
　　　　「変化」に対して共感できる人を募るのが重要。
　　　　
　　　　技術についてはペアプロが一番伝達しやすいのでは。
　　　　ただ、2割位の人は「ペアプロ」が出来ない、という研究結果もあるので
　　　　要注意。（強制はダメ）。
　　　　そもそもペアプロはスゴク疲れるので、例えば新規機能の実装時のみ、
　　　　月曜はペアプロの日、バグが出た時にその改修だけ、という具合に
　　　　実施するポイントを決めるというのが良いかも。
　　　　
　　　　それと（TDDを伝える場合）相手にとって「刺さる」もので伝える事が大切。
　　　　「（品）質」を気にする人には「（品）質が上がる」であるとか、
　　　　「損得勘定で動く」人には「ペアプロがどれだけ得になるか」とか。
　　　　
　　　　後、エライ人に薦める場合、技術等が分かる人であれば話は通りやすいが
　　　　分からない人には論文からの引用データで説明するという手がある。
　　　　
　　　　で、ちょっと質問したのですが「ダマテン（エライ人には黙ってやる）での
　　　　実践は？」ということに関しては、
　　　　「基本的にはお奨めできない。けど、事例はたくさん聞く。
　　　　　その場合、徹底するのであればリポジトリにテストコードをコミットせずに
　　　　　完全ステルスでやったという話も聞いた」
　　　　参加者の方からは「分からないように、Frameworkのテストコードの中に混ぜた」なんて話も(^^;;
　　　　
　　　　また、t_wada さんから「質を下げれば納期が早まる」というような
　　　　「（品）質」と「納期」をシーソーにかけたような考え方が未だに
　　　　横行しているが、これは誤りである、という話もありました。
　　　　⇒　「質」を高める事で「結果的に（ソースの解析・作成・テストの）スピードが高まり」
　　　　　　納期も早まる、という考え方の方が正しい、と。
　
　で、ココで一旦休憩。
　
　続いて、
　「お題：本の中で「危ないところ」に対してテストする、というのがあったが、「危ない」というのは
　　　　　その人によって違うのでは？」
　「お題：全部が危ない場合のテストは？」
　「お題：危ないという事を決める人は？」
　「お題：全て（テストする）、と危ないところ（をテストする）の違いは？」
　「お題：危なっかしい、というところの見つけ方は？（特に自分の専門外の分野の場合）」
　
　というネタが議論の土台に上がりました。会場の時間の都合（と続く懇親会の時間の都合）の為
　「巻き」で進めたので、早速 t_wada さんのまとめ。
　
　　⇒　まず、前提として「危ない」という感覚は個人の主観に委ねられる所が大きく、定量化もしにくい
　　　（ので、昔から議論の対象になってきた）。
　　　　そのため、例えばチームで仕事をする場合、「一番リスクに敏感な人のレベルに合わせる」とか
　　　　「チームメンバの意見を平均化する」とかいうルールを決めて進めるのが良さそう。
　　　　
　　　　t_wada さん自身は例えば「カバレッジレポートと自分の感覚を突き合わせてそのズレを確かめる」
　　　　ということを継続していて、それによって「危ない」という「感覚」がどれ位確からしいかを
　　　　見ているそうです。
　　　　
　　　　自分の専門外の分野の場合、静的なコード解析結果なんかも利用して「危なそう」な所を
　　　　見つける工夫もされているそうです。（動的なテストを書ききれないような既存コードの場合も）
　　　　
　　　　要は「自分の感覚を磨き続けて、「危なさ」に対しての嗅覚を研ぎ澄ませておく」という事が
　　　　重要ということなんではないでしょうか。
　　　　
　　　　後、話の中で「原文では確か【break】という単語が使われていて「壊れやすいコード」という
　　　　意味である、という補足もありました。
　　　　
　　　　そこで、個人的には「危ない」という意味は腹落ちしていたんですが、「壊れる」という
　　　　意味がイマイチ理解できてなかったので、質問をぶつけてみました。
　　　　
　　　　
　　　　「危ない、というのは個人の感覚的なもので、割と腹落ちできたが、「壊れる」という
　　　　　事はどういうことでしょう？コードは（それが完璧な物かどうかはともかく）変更しなければ
　　　　　そのまま同じ結果を吐き出し続ける（＝良くはならないけど、壊れもせず変化しない）と思うんですが？」
　　　　
　　　　回答としては「確かに「コード自体」は壊れないが、【環境】は変化していく。その結果として
　　　　そのコードが正しくない答えを返してしまう。そういう場合に「壊れる」と表現しているのではないか」
　　　　ということでした。
　　　　「（そんなものが世の中に存在しているか、存在できるかは別として）もし100%完璧なコードと言う物が
　　　　　存在していたとして、そのコードと比較した場合に「壊れている＝正しい答えを返さない」コード」
　　　　　という意味で「壊れている」という意味でしょうか？」という追加質問したら「Yes」ということだったので
　　　　個人的には納得。
　　　　
　　　　
　　　　また、「たくさん書き換えられているコード（＝リビジョンがやたら上がっているクラスとか）」は
　　　　「危ない」と考える事も出来る、というお話もありました。
　　　　
　　　　結局、↑の通り、「危ない」という定義自体がフワッとしている分、周りで測れる（計測できる）モノがあれば
　　　　それを測って、定量化（客観化）していきましょう、という事でした。
　
　t_wada さんの悩み(ﾜﾗ
　
　　後、余談ですが、議論のネタ付箋の中に「テストコードを書いているけど、TDD出来ていない」というものがありましたが
　　最近良く「TDDできてないんですよ。。。」と申し訳無さそうに t_wada さんに話しかける人が多いとの事。
　　結論から言うと、「気にしなくていい！」という事でした。
　　
　　ある意味「TDD」という単語がキャズムを超えて一般化した単語になったという一例なのかもしれませんが、
　　ちょっと「宗教化」してきているようで、個人的には「。。。」という感じだそうです。
　　
　　⇒　それについては主催の inda_re さんからも意見があって、結局 本（アジャイルサムライ）の始めに書いてある
　　　　「大きな問題は小さくする」とか「ちゃんと動くソフトウェアを届ける」といった事を実現する為の
　　　　「やり方」の一つとして「TDD」に取り組むのは良いが、「TDDをやる事」が目的になるのはどうだろう、
　　　　という事でした。
　　
　　後、TDDには狭義のTDD（ボブ・マーティンが言ってるようなTDD）と広義のTDDがあるが、
　　狭義の意味では「TDDを始める時の養成ギプス」としてはいいかもしれないが、それに捉われすぎると
　　ついこの前の「TDD is Dead（http://bit.ly/1rcEdPB 日本語訳はやっとむさんが http://bit.ly/1rcEhij に）」とかいう話に
　　いってしまうのではないか、という事でした。
　　
　　結局「TDD」をやってない事に引け目を感じる事は無いし、逆に「TDD」やってるからバグは無くて完璧だ、
　　何て思い込みも危険だよ、というお話でした。
　　
　　最後に、 t_wada さんの補足として、「テストコードとプロダクトコードを書く時間的タイミングが近いこと」
　　というのが「TDD ができているか、いないか」の違いではないか、という事でした。何故かというと
　　テストコードがプロダクトコードに（良い）影響を与え、設計が改善されるからという事でした。
　　なので、テストコードを先に書くか、後に書くかはそれほど大きな問題ではなくて、
　　「テストコードを書くことでプロダクトコードが改善されていない＝TDDではない」ということになるかな、と。
　　
　　⇒　最後に inda_re さんから、参加していた常連の某氏にムチャ振りがあったんですが、その方が仰っていたのが
　　　　「（TDDに限らず、チームを変化させようとする場合）全員を相手にしない」という事です。
　　　　やはり、1人や2人は乗ってこない人がいるので、そういう人を納得させる為にエネルギーを使うより
　　　　↑に出ていたように2人目を作って（巻き込んで）、その他のメンバーに伝えていくのが良い、という事でした。
　
　ってなワケで、本編終了。
　
　続いて懇親会なんですが、電車的都合により、開始から1時間位で先に上がる事になったんですが、
　スペシャルゲストに某スクラムマスター登場（やっぱりか！ﾜﾗ）。
　
　残念ながらちょっとテーブルが離れてしまってたので、今回はあまり話せてなかったんですが、
　変わりに道場常連の方と某てら●でさんと話をして、今丁度悩んでいるC# でのテスト方法について
　いいヒントをもらう事が出来ました。
　⇒　ってか、丁度JJUGに応募したネタだったとか。とりあえず今回のPJTで試してみて
　　　何かFBかブログにまとめようかな、と。あ、そう言えばSessionStateServerで大ハマりしたこととか
　　　WinRMにヒドい目にあったこと、まとめてねぇな。。。
　
　そういや、今年のデブサミで t_wada さんに質問して、腹が括れて取り組んだ
　前プロジェクトの PL/SQL でのテストの件（※）とか結果だけでも報告したかったなぁ。。。
　
　⇒　結論から言うと、何とか上手く行ったみたいです。と、いうのも自分は結局
　　　リリースまで立ち会う事が出来なくて、その後の話をつい先日チームリーダから聞いたんですが。
　　　（とりあえず僕が担当して、その方法を実践した箇所についてはバグは殆ど
　　　　出なかったらしいんですが、、、まぁ、色々合って結局遅れた話とかは置いといて（ﾜﾗ）
　
　　　（※）PL/SQLを上手くテストする方法（既成のフレームワークとか）が見つからなくて、
　　　　　　「JavaとJ-UnitとDBUnit辺りを組み合わせて作ったら？」みたいなアドバイスもあったんですが、
　　　　　　結局、（作成・検証する時間・工数がなかった。作った後でメンテできそうな人がいなかった等の理由で）
　　　　　　「Excel に前提条件（と期待値）作成して、それをそのままSQL文になるような数式だけ書いて、
　　　　　　　PL/SQL実行前に流し込んで、対象のPL/SQL実行。その結果をSQLで引っこ抜いて、
　　　　　　　準備していた↑のExcelに貼り付けて「○・×」で検証する」という、、、
　　　　　　　これ、俺のTLに流したら非難轟々になるんだろーなー、という方法でやっつけてしまいました。。。
　
　っと、まだまだ雨の勢いが強いなぁ。。。（今日は台風18号の為に、午前半休にしてこのブログ書いてたりして）
　さて、今の仕事の仕組みを考えてみるかなー。