社内向けにTDDの講習会を行いました
勤め先でTDDの講習会を行ったので、その内容について書きます。
この記事がTDD導入を検討している方の力になれば幸いです。
経緯
私はとあるSIerに務めており、部内ではテストの工数を削減することが課題となっています。
以前からTDDを同僚や先輩に宣伝していたこと、また、理解ある上司に恵まれたこともあって、
テストコードの書き方を講習する時間をもらえました。
そこで、TDDBCの要領で楽しみながらTDDを学んでもらうことにしました。
一人ではつらいので、TDDBCの参加経験がある先輩と二人で講習を行いました。
参加者について
- 若手開発者 3名
- 中堅開発者 2名
- 業務にオブジェクト指向の考え方を取り入れたのは2,3年ほど前?らしい。(要出典)
- 普段はC#、VisualStudio、VSSを使っている。
講習の目的
二人で話しあい、講習の目的を以下のように決めました。
- テストコードの書きかたを体験しながら学んでもらう。
- 技術習得に対するモチベーションを高める。
- (できれば)バージョン管理、テスティング、継続的インテグレーション、チケット管理を上手に適用すれば、無駄な工数を削減できること、しんどいタスクを楽にする力があることを知ってもらう。
講習の内容
TDDBCをベースに、今回の参加者向けにアレンジしました。
午前に講義、午後に演習を行いました。
午前の講義は以下のような構成にしました。
- 「新しく開発技術を学ぶ理由」
- 新規スライド
- 「最近の開発スタイル・ツールと導入事例」
- @shuji_w6eさんのJava Conference 2011のスライドhttp://d.hatena.ne.jp/shuji_w6e/20110710/1310291797
- codefirstさんのブログ記事 http://d.hatena.ne.jp/suer/20110620/codefirst_dev
- 「TDDBCへようこそ」
- @t_wadaさんのTDDBC Fukuoka Day1のスライドhttp://d.hatena.ne.jp/t-wada/20110321/tddbc_fukuoka
- 「ペアプログラミング」
- 新規スライド
- TDDのデモ
午後の演習は以下の内容です。
- LRUCacheの実装
- TDDBC Sapporo1.0 お題http://d.hatena.ne.jp/shuji_w6e/20110124/1295875892
- NUnitでテスティング
- VisualStudioとアドイン・コードスニペット、SubVersionを駆使してもらう。
- 2人チーム、3人チームに別れる
- 振り返り
- チームごとの発表
本物のTDDBCに参加する方々は意欲溢れる技術好きですが、
私たちの講習の参加者はあくまでも仕事として参加するので、モチベーションが全然違います。
本物と全く同じやり方では失敗するだろうと判断し、一部アレンジしました。
工夫点をいくつか挙げます。
結果
「テスト自動化を業務に導入すべきか?」という質問には、5人全員の賛成を頂きました。
「TDDを業務に導入できそうか?」という質問には、5人中3人ができそうだと答えてもらえました。
また、個別に以下のような意見を頂きました。短く翻訳して紹介します。
- 業務では長いメソッドばかり書いていたが、それではテストコードが書けないと気づいた。
- ペアプロたのしい!
- 業務でTDDすれば、品質のいいコードが書けそう。
- 再テストが楽!
- テストコードが開発のセーフティネットになることを実感できた。
- テスト対象のメソッドの独立性、テストケースの独立性が大事。
- 業務にペアプロ導入するとスケジュール管理するの大変そう。
- テストはアナログじゃないとダメだと思っていたが、案外自動テストも使えそうだと感じた。
- ペアプロすごく疲れる。業務でやるのはしんどい。
- 実業務で単体テストをどこに導入するべきか、わからない。
一緒に講師をしてくれた先輩にも意見を聞いてみました。
- 講義はみんな真剣にきいてくれていたようだ。
- みんながペアプロ楽しそうにやってた。俺もやりたかった!
- TDD以外の技術の話はイメージがわきづらかったが、その後の事例紹介でうっすら理解してくれたようだった。
- 筆者はしゃべりすぎ。
- 今回の講習やってよかった。
筆者の感想
講習の目的を振り返ります。
- NUnitを使ったテストコードの書き方は覚えてもらえました。
- 技術習得のモチベーションについては、少なくとも今回の講習はモチベーションを上げて楽しく学んでもらえたようです。今後のフォローが大事になってくるだろうと思います。
- ソフトウェア開発ツール3本柱の有用性については、あまり理解してもらえてなかったようです。講習の短かい時間の中に内容を盛り込み過ぎてしまいました。
以下、雑感です。
- TDDBCに参加するのも楽しいけど、講習の準備をするのも、講師やるのもけっこう楽しいです。
- TDDの効果を全員が体感できたようで、とても嬉しい。
- TDDBCの構成はとても良くできているなと、感心しました。
- 講義の主題は一つに絞るべき。全体としてまとまりがなくなって、主題がぼやけてしまう。
- ペアプロのチームを決める際は、相性をよくよく考えましょう。
- デモは短時間で華麗に見せられるよう、何度か練習しておいたほうがいい。
他にも細かい反省点はたくさんありますが、以上にします。
最後に
TDD伝道師の@t_wadaさんにはTDDBCを通してたくさんの技術・スキルを教わりました。技術者としての姿勢を尊敬しています。講師役の先輩も@t_wadaさんファンになったようです。
TDDBC Sapporo主催の@shuji_w6eさんには、始めてTDDを教わっただけでなく、TDDBCやJava Conferenceに参加させてもらいました。また、業務経験を踏まえて教えていただいた知識は、現在進行形でとても役立っています。
TDDBCのスタッフの方、参加者の皆さんのおかげで、楽しく、深くTDDを学ぶことができました。
また、講習会を許可してくださった私の上司や、参加してくださった方々、講師役の先輩にもお礼を申し上げます。
今回講習会を行えたのは皆さんのおかげです。ありがとうございました。