2012/12/9（日）にGlobal Day of Coderetreatに参加してきました。私は昨年のGlobal Day of Coderetreat以来、1年ぶり2回目の参加です。
このエントリでは、
- Coderetreatとはどういうイベントなのか？
- Global Day of Coderetreatとはどういうイベントなのか？
- Coderetreatをどう楽しむか？学びを有意義にするか？
をお話したいと思います。
■参考
■Coderetreatとはどういうイベントなのか？
まず、
告知ページを一見しただけでは、「プログラマが1日中ひたすらペアプロをするイベントかな？」と思われるかもしれませんが、それだけではありません。
Coderetreatはプログラマのretreat（避難所とか静養所という意味）です。プログラマという職業の人は、普段の業務では常にリリースで追われていて、プログラミング、設計、テストなどの基礎テクニックをあらためて習得する機会に巡りあうことは少ないでしょう。納期とは無縁な場所で基礎テクニックを習得する機会を与えるのがこのイベントの趣旨です。
特徴としては以下の通り。
- 題材は「コンウェイのライフゲーム」です。人工生命のシミュレーションをするやつですね。
- 45分で1セッションのペアプログラミングを6回繰り返します。ペアは毎回変更します。
- セッション終了時にはコードを全て削除し、毎回、ゼロからライフゲームというゲームのコードを書いていきます。
- これは新しい設計アイディアに挑戦させる狙いがあるそうです。
- 実際、セッションを経る度に、ファシリテータが設計制約を課してくるので、それを乗り越えるたびに普段と違った発想で設計する強制力が働きます。
- ペアプログラミング、TDD、オブジェクト指向設計といったプラクティスを習得する機会が得られます。
- 手取り足取り教えられるわけではありませんが、やり方はファシリテータが説明しますし、ペアの人が詳しければ実地で教えてもらえます。
- プログラミング言語が限定されていないので、やり方によってはいろんな言語の学習機会が得られます。
- どの言語でコードを書くかはペア次第なので、ペアの話し合いの結果によってはあまり馴染みのない言語で書く場合もあります。私は普段、C/C++/Python/VBなど使っていますが、今回は「普段使ってない言語を使う」というポリシーなので、相手の特異なJava/Ruby/Scala/JavaScriptを使いました。
- ちなみに公式イベントは昼食とおやつはスポンサー持ち！
■Global Day of Coderetreatとはどういうイベントなのか？
今回は単にCoderetreatではなく、頭に「Global Day of」とついています。つまり世界中で同時に開催されているわけです。実際公式サイトを「
Global Day of Code Retreat 2012」で検索すると、ものすごい量の開催告知が出てきます。少なくとも50都市以上で開催されているのではないでしょうか？
今回、日本ではおそらく東京、大阪、福岡、愛媛で開催されていて、会場ではGoogle Hangoutというツールを使ってリアルタイムでお互いの状況が分かるようになっていました。たしか、海外の会場ともつながっていたと思います。昨年はインドと中継して、「How are you doing?」なんてやり取りする場面もあり、なかなかおもしろかったですが、今年は海外とのやり取りがなくて物足りなかったです^^;
■Coderetreatをどう楽しむか？学びを有意義にするか？
せっかく丸一日使うのだから十分楽しみ、有意義な時間にするべきだと思います。楽しめて有意義にするためには、どうしたらいいんでしょう？普段とは違うやり方に取り組んだり、他の人から違う考え方を学び、視野を広げることだと思います。
今回、私が意識したのは以下です。
○普段と違う言語・フレームワークを使う
私は組み込みソフトウェア開発者なので、主に業務で使うのはC/C++です。開発環境のマクロを組む時にVB、スクリプトを開発する時にPythonなどを触る機会がありますが、他の言語を触る機会はありません。
しかし、他の言語の方がプロダクトコードやテストコードを書きやすい言語仕様やテスティングフレームワークになっている場合があり、他の言語のやり方を学ぶ良い機会になります。
今回一番良かったのはRubyとそのテスティングフレームワークのRSpec。直感的に書いたコードがだいたい動く感じが非常に気持良いです。そして、RSpecのdescriptionやcontextという要素でテストコードを構造化していくやり方は非常に頭が整理されているようで良かったです。
普段の言語にはそのまま持ち込むことはできないケースが多いと思いますが、エッセンスを咀嚼して普段の開発に活かすことはできるかもしれません。
○普段と違う設計をする
今回のイベントの趣旨は、業務ではできない体験をすることなので、普段とは違う考え方で設計をやるのが一番でしょう。普段、モデリングして、オブジェクト指向的に設計していない人はオブジェクト指向にチャレンジする機会です。私はオブジェクト指向設計に慣れているので、あまり慣れていないペアの時はモデルを書きながら、オブジェクト指向設計をリードして、「なるほど、こんな風に考えるんですね。勉強になりました。」とペアの方に言われて嬉しかったです。
また、for文を使わないようにするという設計制約を乗り越える過程で、普段あまり使わない言語要素の map & filter で簡潔にコードを書く方法を教えてもらったりしました。これは勉強になりました。
○理想的な形で技術プラクティスにチャレンジする
1セッション45分で非常に短いのでちょっと焦りますが、仕事と違って完成しなくても上司とお客さんに怒られたりしないので、理想的な形で試してみたい技術プラクティスに取り組んでみるといいのではと思います。
TDDって知識として知ってはいるけど、やってみたことはないという人は絶好の機会なので本に書かれているTDDをやってみてみて下さい。きっちり歯車が噛み合っている状態でバグを発生せずに少しずつ前に進んいく感覚は非常に気持が良いと思います。
今回、私がやってみたのは「
実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)
」で紹介されている「
二重のテストループ」です。翻訳者の和智さんがブログエントリ「
テスト駆動開発の進化」で紹介されています。
coderetreatで起こりがちなのが部品となるクラスの完成度が上がっていったけど、ライフゲーム全体は殆どできずに終わるというケースです。本番のシステム開発でやるとダメパターンですね。
これをアジャイル開発のように常に全体が動くようにするために、ユーザ視点で意味のあるシナリオ1つに対して受け入れテストを書き、内部をテスト駆動で書いていきます。これをやると、特定のシナリオに対して動くシステムが早めにでき上がって確認できる上に、アーキテクチャ設計から細部の設計・実装までひと通り通しでやってみて気づくような設計判断が早め早めに分かるというメリットがあります。
実践テスト駆動の題材に比べると細かいテストコードを書いていましたが^^; 雰囲気だけ分かって良かったです。
○振り返りで面白かったネタをシェアする
セッションの最後にペアで振り返りし、その時の付箋をボードに貼って、皆と体験をシェアします。基本的にはファシリテータの方が全体にシェアすべきことを拾ってくれますが、特にこれは！と思う内容は付箋を貼る時に皆に話してみると取り上げてもらえる確率も上がると思います。
○海外の人と交流する
そして、今回は global day ということで、ハッシュタグ #gdcr12 で世界中の人がいっせいにつぶやいていました。私も #gdcr12 に対して質問してみたのですが、J. B. Rainsberger（@jbrains）というヨーロッパ系カナダ人のコンサルタントの方から即座にコメントがありました。
ちなみにcoderetreat.orgの
Activity CatalogというページにCoderetreatでよくやれているアクティビティの紹介が書かれていて、そこに「Verbs Instead of Nouns」と書かれていたので、何ですか？と書かれたので質問しました。回答は「Name your modules or classes with verbs instead of nouns（モジュールやクラスの名前に名詞ではなく動詞を使いなさい）. It affects how I divide responsibilities（このやり方は責務の分割に影響します）.」とのこと。どう影響するのかは教えてもらえませんでしたが、ビデオを見つけたので後で見ようと思います。
Verbs Instead of Nouns - Next Up at Coderetreat from
Coderetreat on
Vimeo.
■最後に
本エントリでは、Coderetreat自体とその楽しみ方を紹介してきました。このイベントはかなりよく練られたイベントで、世界中でやられているのも頷ける内容です。
なにより、違う分野の人同士が、それも国境を超えて、切磋琢磨する場があるといいうのがすこい素晴らしいと思います。異業種の人にも紹介してみましたが、そんなイベントがあるなんて！と驚いていました。
今後も定期的に開催されると思うので、今後とも参加したいと思います。
#やっぱコード書きたいからなるべく一般参加者で・・・^^;
」が出版され、対談まであると知り、日本人なら聞いておくべきだろ！と思い立って参加に至りました。
」で、同様に全機能を持って自律的に動く組織を作ることを推奨しています（資料p.61）。その組織が生み出した「時間あたりの付加価値」が分かるようなインセンティブ手法を確立し、製品開発に必要な社内の調達も市場取引と同じようにやっているそうです。これにより、市場が変わるとその変化が社内取引にダイレクトに反映されて、各組織が自律的に「時間あたりの付加価値」を最大化するように動き始めるそうです。
」は購入して読んでみようと思います。