最近、社内の新人研修を企画・運営する仕事をしている。
まだ研修は進行中なので、得られた知見は研修終了予定の6月末以降に書くと思う。
しかし、「とりあえずプログラミングやっとくだろ」と思って考えたTDDBCが結構いい感じっぽいので、そこだけまとめてみようと思う。
TDDBC概要
個人的に親交がある某web系の会社から4人と、弊社から僕含めて2人の計6人が集まった。
僕は2年目、他の人達は1年目。
しかも、同じようなメンバーで4月にAnsibleの会をひっそりと行っていたこともあり、いわゆる顔見知りの集まりだった。
当日の流れ
0900 会場(弊社)集合
0900 - 1000 TDDについて、t-wadaさんの資料を見たりして全員の認識を合わせる(目的とか)
1000 - 1120 Perlの環境を揃えたり、use_okのテストだけ通すなどを全員同時に行って、最初の一歩をサポート
1120 - 1140 ペア作成、TODOリストの作成と発表
1140 - 1300 みんなで昼食
1300 - 1500 TDD
1500 - 1530 中間発表(困っていることとかを発表して意見交換)
1530 - 1700 TDD
1700 - 1800 コードレビュー(1ペア20分 x 3ペア)
問題
Perl限定について所感
まず、言語をPerlに限定したことが非常に良かった。
僕も何回かt-wadaさんのTDDBCに参加しているが、様々なスキルを持つ人が集まるため、いろんな言語のユーザのるつぼになる。
それでも講義は良いし十分勉強になるんだけど、第一希望をPerlで出してスキルのミスマッチが故に第二希望にアサインされる悲しみが無いわけではない。
今回は参加者募集の時点から言語縛りを強調していたため、その悲しみは一切なかった。
学習効果について所感
TMTOWTDIでお馴染みのPerlは、ペアによって実装方法が変わるので、「そんな設計や実装方法があったのか！」と、純粋にプログラミングの知見を得ることもできる。
もとが新人研修なのもあり、テストの前にPerlやプログラミング力(?)がバラバラな中、この教育効果は非常に良いものだった。
どう良いかというと、「この教科書読んどいて！」よりも、とりあえず2人組で手を動かし何かを作るという経験を積める分、最低限必要な知識を、素早く勝手に(明確な教師役が居なくても)修得することができると思う点で良い。
「勝手に修得することができる」というのが重要で、
- TDDBCの問題に段階的に設定されている目標を、
- テストという「問題」を自分で作り、
- その「問題」をクリアする
というように、実はTDDBCはプログラミングの知識に乏しい人でも自分で勝手にに成長して行きやすい課題だった。
よって、教師側のコストを大きく削減しつつ、生徒の自習を促しやすく、成長という目標を達成しやすい。
ちなみに、採用の時点でパソコンアレルギーな人はスクリーニングされているし、弊社の新人には4月の合間に僕が書いたServerspecを渡してLinux環境に触ってもらっていたので、そこらへんの最低限必要なスキルは全員確保されていた。
顔見知りのみを集めた件について所感
もともとこの勉強会、募集をかけたのが、親交がある会社の1,2年目のみが入っているFacebookグループなので、最初から顔見知りを集める気だった。
顔見知りが集まったので、事項紹介がどうとかコミュニケーションがどうとか余計なコミュ力を使わず、TDDに集中できたと思う。
普通のTDDBCだって自分たちと近しい人が集まるのでコミュ力は対して使わないので、実際のところこの制約は無くても良かったかもしれない。
でもTDDだけじゃなくPerlの学習という目的もあったから、「こんなのもわかんねーのかよ」みたいな変なプレッシャーが無かったのは功を奏したといえるかもしれない。
TDDは死んだのか
最近お亡くなりになったらしいTDD。
実際のところ、単体テストから結合テストやE2Eテストを重視するような風潮を、なんとなくだけど感じつつある。
しかしそれは単体テストをバリバリ書ける人(または環境)が増えて次のフェーズに至っただけであり、単体テストも満足に書けないような僕ら新人が言っていいセリフではないと思う。
BootCampという点から見て、TDDはまだまだ有効だ。
言語、設計、テストを学ぶのに、TDDがとても良いということがよく分かった。
僕の中でTDDは死んでいない。超生きている。
死ぬとしたら、小物エンジニアからの脱却を果たすような遠い未来なのだろうなあと思う。
まとめ
言語限定TDDBC、楽しかったです。