株式会社adingo所属かつアジャイル戦略室（勝手メンバー）の@katzchangです。先日、VOYAGE GROUP社内勉強会としてTDDワークショップを開催してみましたので、そのご報告です。
まずは「TDDってなに？」っていうお話をさせていただいたあと、ペアプロでTDDを体験して、最後にどんなコードができたかレビューするという、いわゆるTDD Boot Campスタイルをとりました。課題は「ECナビ会員のグレード（http://ecnavi.jp/mypage/guide/condition/）を判定しよう」。
ふりかえり
Keep
- ペアプロがよかった、安心できてかつ慎重になる（というのが6票）
- ECナビネタの課題がFizzBuzzよりも実務に近く感じて勉強になった
- 進み具合に応じて追加の課題がでてくることがすごくよい
- 課題の要求があいまいだったので思考できてよかった
- 数人が教える側に立った
- テストの価値説明が最初にあるので理解しやすい
- テストコードは書いた方がいい
Problem
- OSSだとテストコードがなければ無視されるような話を是非
- 言語はもっとバラエティに富んでた方がよい
- 全員ペアプロだったので、ペアプロじゃない人と比較したかった
- （PHPで）Shift_JISでは日本語メソッドは構文エラーになる
- パソコンは一人一台あるとよい
- もう少し時間が長くてもよい
- 仕様が不明な時に、もっと積極的に出題者に質問できればよかった
- （コードレビューのとき）ThinkPadがプロジェクターに映らなかった
- Eclipseよくわからなかった
- お腹すいた
Try
- パラメタライズド・テストでテストを書いてみたい
- ペアプロ大会したい
- 今日参加できなかったエンジニアのためにまた開催してほしい
- ピザでも食べながらコードレビュー
これを受けて
ペアプロがとても好評だったのは、想定通りでした(ﾄﾞﾔｯ
ペアプロとTDDの相性の良さについては、書籍「ペアプログラミング」（ピアソン・エデュケーション）の中でも触れられています（私の席に置いているので、読みたい方は声をかけてみてください）。
テスト駆動開発を活用してください。（中略）
テストファーストプログラミングと組み合わせると、ペアプログラミングの価値が本当にわかると言った人たちがいます。その人たちは、最初にテストを作成することで、ペアが2人とも、取り組んでいる問題を正確に把握すると述べています。
ペアプログラミング 第11章 ペアプログラミング実践の秘訣 p101
TDDを使わずに作業の結果を確認するためには、ドライバーは黒目を動かして広大なブラウザ画面のどこかの文字列を網膜に写し、それがドライバーの脳内にある意図に沿っているかを検査することなります。当然、横で見ているパートナーには伝わるはずがありません。ドライバーが「ここがゴールド会員だから、このメニューがこうなって…」みたいな独り言を言いながら進めるのはとても良いことですが、なかなか限界があるでしょう。目標（テストコード）を明確にして実装を進めるTDDは、ペア同士のコミュニケーションも促進するということだと思います。
これからのこと
現在、VOYAGE GROUPエンジニアのためのTDD Boot Campを企画中です。社内向けの研修ではあるのですが、外部の方にも参加していただけるような形で開催したいと私個人としては思っていて、おそらく、そのようにできると信じています。
時期は年明けくらい、12月くらいには何かお知らせできればば、順調に進んでると安心していただけるはずです。とりあえずあと2回程度ワークショップを開催してみて、そこから先の「使える武器」をどう増やしていくにフォーカスするという方向もアリかもしれないと思いながら、まーどうしましょうかねぇ。
現状、プロダクトによってはレガシーコードとの熾烈な戦いがあったり、自分も含めてまだまだ経験が足りていない――言い方を変えれば、挑戦すべき多くのことが目の前に転がっています。これはとても恥ずかしい話ではありますが、ただ、それらを一つ一つ片付けながら進むという、泥臭く、かつ人間臭い仕事ができるエンジニアは、プロフェッショナルと呼ばれるにふさわしいのではないかと思うわけです。
というわけで、最速最強の開発を目指して、今の開発を加速していきましょう。
