TDD Boot Camp 札幌 2.0 開催しました！（運営編）
本日、札幌では４回目となる TDD Boot Camp 札幌 2.0 を開催され、
TDD界のリーダーであるid:t-wada氏に札幌で２回目の登壇をしていただきました。今回はTDDに関連する部分は、参加者のブログにお任せし、自分の方からは主催者視点でのレポートとしたいと思います。これを機会に他地域でのTDD Boot Campの開催の参考になったり、開催したいなと思って頂ければ幸いです。
開催まで
今回は札幌開催で４回目ということもあり、開催自体の準備は少なかったです。これは言い換えれば、はじめての時は色々と試行錯誤が必要ということでもあります。
参加人数の動向
札幌開催での参加人数は次のようになっています。
| 日付 | No | 参加者 | 備考 |
|---|---|---|---|
| 2010.12.18 | 0.5 | ６名 | Javaのみ |
| 2011.1.23-24 | 1.0 | ２６名 | @t_wada氏登壇、言語自由（Java, Ruby, VB, PHP, JavaScript, Smalltalkなど） |
| 2011.5.15 | 1.5 | １７名 | Javaのみ |
| 2011.6.4-5 | 2.0 | ４３名 | @t_wada氏登壇、言語制限（Java, Ruby, Python, Smalltalk, C++） |
Javaのみで開催している時は運営はほとんど自前で少し手伝って貰う程度に済ませたいという会です。勿論、@t_wada氏が登壇することで参加者は増えるのは自然なことですが、制限されている会はコンパクトに出来るというようにも解釈できます。
制限会の経験
先に結論を言ってしまえば、地方でTDD Boot Campをやってみたいな、と思っている人がいるならば、まずは自分たちでコンパクトにやってみると本編で生きてきます。主催者の得意な言語を使って、テスト駆動開発について勉強しようというのをやってみるべきです。ここで他地域のTDD Boot Campに参加した経験がある人がいればベターですが、絶対に必要というわけではありません。@t_wada氏の講演のスライドやustは幾つか公開されていますし、テスト駆動開発入門を写経するでも良いと思います。このステップを踏むことで、色々な言語をサポートする場合にも、お題を考えるなどの際にも経験が生きてくるわけです。いきなりたくさんの参加者が予想され、それに戦いを挑むより、小さなステップで１人づつ仕留めましょう（TDDのこころ）
コンパクトにやる場合のポイント
上にも書きましたが、無理に色々やる必要もないと思います。自分で行ったり、やってみたら良さそうなパターンを列挙してみます。
- テスト駆動開発入門の写経または読書会
- 過去の講演について上映会＋ディスカッション
- 過去のお題をやってみる
- 他地域の参加者から話を聞く
ぱっと思いつくのはこんな所かと思います。写経とか講演の聴講などは１人でも出来ますが、ディスカッションやペアプロなんかは集まってやると見えなかった部分が見えてきます。例えば、開発環境の問題であったり、会場のネットワークの問題であったり、ぶっつけ本番で望むと結構反省点が多い部分です。また、各地域でTDD Boot Campが開催され、お題も多く公開されてきています。なので、まずはそれを中心メンバーでやってみて、TDD Boot Campの雰囲気を感じてみる事が良いと思います。
タイムスケージュール
TDD Boot Campは泊まり込みで２日開催であル場合と、１日開催である場合の２パターンがありますが、当然１日開催の方が参加者の敷居は低くなります。
とはいえ、１日では物足りない…という場合もありますし、１日の中でお題を上手くやりとげるのは難しい事もあるため、厄介な問題です。
幾つかのパターンはありますが、札幌で工夫しているのはお昼をお弁当にして、スタッフ側で準備しています（当然参加費に含む）。お弁当にすることでゴミ問題など幾つかの問題も発生しますが、参加者が外に出る必要がなくなるというメリットが生まれます。また、お題を考えながらお昼を取れば、コミュニケーションも円滑になるのでオススメです。お弁当を食べつつ自己紹介しながら、ああだこうだと話するのはオススメです。札幌では会場の横にスーパーがあるため、お弁当コーナーのおばちゃんに頼んで大量につくっておいて貰っています。
また、会場は朝から晩まで確保しておくべきです。講演等で午前中を使うとなると、午後から演習になりますが、３−４時間では物足りない事になります。というのも初めての人と一緒にやるには、やはり最初の１時間くらいはお互いに様子見になりますし、打ち解けるには時間がかかります。休憩などもありますので、演習の時間は５時間は確保しておいた方が良いです。また、後述しますが、振り返りの時間の確保は１つの課題です。
これは地方で何回か開催している場合には特に有効なパターンになるかもしれませんが、演習を多く確保するためと基調講演については何回か聞いたことがある人のため、基調講演は前日の夜にやるパターンもありかもしれません。金曜日の19:00〜21:00くらいに基調講演を行い、次の日は朝から演習というパターンです。これならば演習の時間がかなり多く取ることができます。
参加人数との兼ね合いになりますが、振り返りの時間をどのくらい確保するかは課題です。札幌では45分ほどを想定していましたが、Java５チーム、RubyとPythonが各2チーム、SmalltalkとC++が各１チームと合計１１チームになった結果、かなりオーバーしてしまい、懇親会の時間がずれこんでしまいました。コードを説明しながら各チームで振り返りを行うならば、想定チーム毎に10分くらいは想定しているべきでしょう。ただ、１１チームやるとなると約２時間になるわけで・・・厳しいですね。
サポートスタッフとオペレーション
TDD Boot Campはスタッフのオペレーションがセーフティネットです。また、人数が増えれば増えるほど難しくなるので、自分の経験的には次のような数を上限とした方が良いと思います。
| スタッフ数 | 参加者上限 |
|---|---|
| １人 | １０名（３チームまで） |
| ３人 | ２０名（５チームまで） |
| ５人 | ３０名（８チームまで） |
| ８人 | ４０名（１０チームまで） |
つまり、1人でも10人くらいは捌けるんですが、チーム数が増えると一気に運営が難しくなります。不慣れな状態で運営するのであれば、２０名以下の定員でやるのがオススメです。コンパクトに10名以下でやるならば、右も左も解らないスタッフ同士で見よう見まねでやってみるのも問題ありません。尚、初めてのスタッフであれば、0.5人換算でいいかなと思います。また、６チームを超える場合は、なるべく各チームに1名くらいはスタッフをいれたほうが圧倒的に楽です。
前回、札幌1.0では参加者の自己責任で言語を選択して貰いましたが、今回の2.0ではサポートスタッフがいる言語に制限しました。というのは、前回の反省で、幾つかのチーム（言語）で開発環境の構築やユニットテストの実行方法などに時間がかかりすぎて、テスト駆動開発の演習まであまり進めなかった班があったからです。なので、サポートできない言語は扱わない方針で行いました。これは効果がありましたが、一方でPHPやVBなどやりたいけど自分の言語はないという問題になるため、難しい問題です。しかし、自分は運営の負荷をあげることはやるべきではない、というスタンスなので今後もサポート言語はサポートスタッフのいる言語にすると思います。
また、サポート言語を制限したため、別の問題も発生しました。今回、半分くらいがJavaになりましたが、これは「Ruby,Python,Smalltalk,C++よりは自分のホーム言語ではないけどJavaの方が理解できるだろう」という意識の結果であると分析しています。結果として、Javaは１チーム４名の中で２−３名が初心者という状態です。一方、他言語は熟練者２−３名に初心者１−２名という理想的なチーム配分となりました。どうしてもある程度は経験の高い人がチームをリードしないと、演習が回りにくいため、これは切実な問題かもしれません。初心者お断りにしないで、かつ上手く回すには何か手はないかなと考えていますが、なにか具体策ないでしょうか？
というわけで、札幌 2.0の主催側からのレポートでした。
*1:スクール形式の定員での換算
