anfangsのログ

■社内向けにTDDの講習会を行いました 01:35

勤め先で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のデモ
  • FizzBuzz
  • 先輩とペアプロ

午後の演習は以下の内容です。

• LRUCacheの実装
  • TDDBC Sapporo1.0 お題
    http://d.hatena.ne.jp/shuji_w6e/20110124/1295875892
  • NUnitでテスティング
  • VisualStudioとアドイン・コードスニペット、SubVersionを駆使してもらう。
  • ２人チーム、３人チームに別れる
• 振り返り
• チームごとの発表

本物のTDDBCに参加する方々は意欲溢れる技術好きですが、

私たちの講習の参加者はあくまでも仕事として参加するので、モチベーションが全然違います。

本物と全く同じやり方では失敗するだろうと判断し、一部アレンジしました。

工夫点をいくつか挙げます。

• 自分たちの業務が具体的にどう良くなるかイメージしてもらえるよう、他社事例を紹介しました
• ペアプロの効果を具体的な数値で示しました
• 脱落者を出さないように、本物のTDDBCの内容に加え、参加者をフォローするためのスライドや資料を作成しました
• 業務でよく使うC#で快適にTDDできるよう、開発環境を整えました

結果

「テスト自動化を業務に導入すべきか？」という質問には、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を学ぶことができました。

また、講習会を許可してくださった私の上司や、参加してくださった方々、講師役の先輩にもお礼を申し上げます。

今回講習会を行えたのは皆さんのおかげです。ありがとうございました。