2012/12/28

2012年の活動まとめ。初の勉強会主催、海外著者インタビュー記事公開、グローバルな技術系イベントで海外の人と交流、初の自著執筆など

今年の振り返り。
今年意識したことは以下。それなりにできたので満足です。

  • 自分の能力が最大限に発揮できる道と社会が発展する道がうまく交差するような場を見つける。頑張って楽しいと、社会に何がしかポジティブな影響を与えることを両立する。
  • 国境や母国語の違いを超えてグローバルに海外のエンジニアとも交流する。そのために日本語だけでなく英語でコミュニケーションする。

----

■1月

  • 2011年から検討してきた組み込みTDD読書会を告知しました。技術系の勉強会初のイベント主催です。
  • 最初に告知に反応してくれたのが著者James Grenning氏でした。来日予定あったJames氏が僕のツイートを発見し、「本読んでくれてありがとう。近々日本に行くから、会おうよ。日本の読者と話してみたいし。」とコンタクトを受けました。ちょっとびっくりですが、著者と読者を交えて座談会をしようと企画を練り始めます。

■2月


■3月


■4月

■5月

  • 組み込みTDD本の著者James氏の来日がキャンセルになり、日本人読者との座談会の企画もキャンセルになりました。でも、計5名が横浜に集い、JamesさんはアメリカからSkypeで参加してくださり、こじんまり短時間ではありますが、意見交換をやりました。まさかこんな展開になるとは思わなかったので感動しました^^
  • この時に、原田さんから紹介頂いた名古屋の組み込み開発者の方がわざわざ横浜まで来て座談会に参加してくださりました。この方が後に翻訳書の企画を出版社に通し、監修者になります。

■6 - 7月

  • 定例でTDDの読書会を開催したり、あとはJamesさんが来日キャンセルになったけど、いろいろ質問事項がたまっていたので、インタビューしようと企画しました。実施方法は悩みましたが、職場の方がAgile 2012に参加するから代理でインタビューしようかと言われたのでお願いしました。

■8月

  • インタビューの録音データをいただいたので、ここから自分がインタビューしたわけではないインタビュー音声のテープおこしが始まります^^; しんどいけどヒアリングは練習したかいもあってなんとかなりました。アジャイル開発をやるやらないに限らず、持続可能な開発をやる基盤としてTDDの可能性は感じていたので、やはりここはインタビュー記事をしっかり書いて公開したいなと思いました。僕だってたいしたことはできんけど、世の中の役には立ちたいという気持ちはあるからね。

■9月

  • Jamesさんのインタビュー記事を公開するに先立って、そもそも書籍がどういうものか認知度を上げる必要があるなと思い、書籍紹介の記事を公開しました。ニッチではあるけど、組み込み・テスト・アジャイルクラスタの間で本書の認知度が上がり始めます。
  • 5月に座談会でご一緒した方から翻訳書の企画通りました!との連絡あり、監修体制について議論を始めました。出版社からは早く市場に出したいとのことで、翻訳はプロが監修やレビューについては我々が責任をもってやるという役割分担をすることに。インタビュー記事があり、レビューどこではありませんでしたが、幸い翻訳原稿が届くのは少し後とのことでホットしました。

■10月

  • Jamesさんのインタビュー記事前編を公開しました。僕にとってアジャイルマニフェストは社会に出た時にすでに本に書かれた昔のできごとであり、そんな人間がアジャイルマニフェストの著者のインタビュー記事を書いていることに違和感を感じました。XP/アジャイル直撃世代の方がふさわしいのでは?と思いましたが、企画したのは自分だし、これを世に送り出すことは僕の使命だなと思い、通勤電車の中で何度も読み返しながら推敲しました。Jamesさんが話していた「アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。」という言葉を何度もかみしめました。
  • この辺から翻訳書監修チームでの会合が始まり、おおまかな体制が決まりました。

■11月

  • Jamesさんのインタビュー記事後編を公開しました。アジャイル・テスト・組み込みクラスタJamesさんの話していることは、仕事の中で培ってきた価値観にすごい合う印象でうんうんそうそうと納得しました。テクニックというよりアジャイルのマインドを理解し始めました。
  • Ultimate Agilist Tokyoに参加。これまでのTDDの活動についてプレゼンしました。短い時間ながらも、大きな規模のイベントで話する側に回れて満足感を得ました。
  • この辺から翻訳原稿が届き始め、ビューが本格的にスタートします。

■12月

  • Global Day of Coderetreatのファシリテータ研修に参加。テレビ会議をつないで4カ国から6名の人が研修に参加。受講者のうち一人がJamesさんの元クライアントであり、中国語版翻訳者の同僚であることが分かりびっくり!世界はせまい。
  • 本番ではJava/JavaScript/Ruby/Scalaでペアプロをやり、大満足。TDDのリズム感は楽しいな!と実感。TDDが血肉になりつつあるのを感じました。
  • 書き忘れてたけど、1年通して自著を書いてて、今ようやくゲラチェック中^^; 来年初めには出版です!

2012/12/09

世界規模のプログラミング教育イベント Global Day of Coderetreat 2012 は楽しかった!!

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自体とその楽しみ方を紹介してきました。このイベントはかなりよく練られたイベントで、世界中でやられているのも頷ける内容です。

なにより、違う分野の人同士が、それも国境を超えて、切磋琢磨する場があるといいうのがすこい素晴らしいと思います。異業種の人にも紹介してみましたが、そんなイベントがあるなんて!と驚いていました。

今後も定期的に開催されると思うので、今後とも参加したいと思います。
#やっぱコード書きたいからなるべく一般参加者で・・・^^;

2012/12/01

Ultimate Agilist Tokyoに参加してきた

先日のブログにも書いたとおり、Ultimate Agilist Tokyoというイベントに参加してきました。ここでは聴講した他の方の発表についてレポートしたいと思います。


細谷 泰夫さん:アジャイル×テスト開発を考える



http://togetter.com/li/407192
http://yasuo.hatenablog.com/entry/2012/11/18/225159

アジャイル開発において成果物の品質を早期に確定させるためにどのようなテストを計画していくかについて発表されていました。2000年代からXPの推進者であった細谷さんが10年近くにわたって他部門の方(品質保証?)の方とアジャイル開発の導入について議論してきた経験が反映されている発表だという印象を受けました。

細谷さんによると、アジャイルに批判的な人の中には「品質の確定性」を気にしていて、「頻繁に変更が加わって品質が安定しなさそう」と言う方がいるのだそう。おそらくは、頭の中に理想的なフォーターフォール(つまり目標の品質に対して直線的に向かっている状況)を思い描き、それと対比して、頻繁にリリースをしながら徐々に目標の品質に向かうアジャイルに対してネガティブな印象を持っているのではないか?という話です。

しかし、細谷さんはプロセスの違いが問題ではなく、
  • 利害関係者の間でどうやって目標の品質を共有するのか?
  • その目標の品質をどうやって達成するのか?
が大事だと説明しました。

前者については、コンテキストに依存するので計画の段階で合意する必要があるようです。後者については、アジャイル開発をやると早期に開発とテストが協調し始めて、テストコミュニティでよく話題に挙がる「Wモデル」と同じ効果が得られるのだそうです。このWモデルとは、V字モデルの左側(要求分析・基本設計・詳細設計・実装)と並行してテスト設計を始める手法です。

そして、早期に開発とテストを協調させる上で重要になるのが「テスト計画」のようです。テスト計画としては以下を考えるとよさそうです。
  • いつ、どんな品質を確定させたいか?
  • 複数のテストの粒度をどう組み合わせるか?(ユニット、インテグレーション、受け入れ、etc)
  • どう自動化するか?
  • 誰からどのようにフィードバックを受けるか?
このテスト計画をやる上での知見については、アジャイルプロセス協議会のテスト・レビューWGでヒアリングしているとのこと。私はテスト計画をやった経験ではないのですが、開発において重要な分野だと思うので少し勉強したいと思います。WGの今後の成果に期待ですね。※こんなこと書くと、お前が参加して貢献しろと言われそう :)


前川 直也 さん: 家電商品を開発してみると目からウロコなAgileの本質

http://togetter.com/li/407795

本職は家電メーカーのPMである前川さんが、大規模開発でアジャイル開発を実践する上での体験を話されていました。昨今のニュースで見聞きしているのと同じで、やはり家電開発はかなりしんどい状況におかれているようです。かなり際どい話だったので資料は非公開のようです^^;

円高、新興国メーカーの台頭、消費者の趣向の変化など社会が急速に変わっていく中で、市場に受け入れてもらって、企業が生き残っていくには、どの分野でどういう価値を提供して利益を得ていくかはかなり深刻な問題です。昨今のニュースを見る限りでは、次から次へと起こる変化に対応していくうちに、開発規模は膨れ上がり、他社との価格競争は激化し、疲弊していっているのが現状だと思います。

先日の主要エレクトロニクス企業の決算を見る限りでは、もはや一度敗北してしまって、今焼け野原の中にたっているということを認めてしまった方が良いのかもしれません。そこから、もう一度、我々の事業は何なのか?を見つめなおして再スタートを切るべきなのかも。これは家電企業だけの話をしているわけではなく、私のいるSI業界も似た状況に立たされると思っています。


そこで、前川さんが話していたアジャイルの本質(おそらくは「現場、人、お客さんの価値提供を重視すること」だと思います)の重要性が増してきているのだと思います。そして、前川さん自身は主要エレクトリにクス企業の創業者の格言の中にアジャイルの本質を再発見しているそうです。戦後の焼け野原の中でエレクトロニクス企業が次々と立ち上がったように我々も立ち上がる時期がきています。

たぶん、SI業界もタイミングが少し遅れてきっつい状況が来るのだと思うので、今から準備しておくと良いでしょうね。


原田 騎郎 さん:Can you keep doing that? <No-Bull Know-How>



こちらは講演はなしです。「No-Bull Know-How」というのはAgile 2012などでも実践されているセッションのスタイルの一つだそうです。有識者が一人壇上に上がり、聴講者が質問を投げかけ、それに対して有識者がアドバイスします。そのアドバイスを聞いた他の聴講者がアドバイスが妥当かどうかを判断するというものです。

@daipresentsさんのブログにも紹介されているのでぜひ読んでみて下さい。
Agile 2012「No-Bull Know-How Stage」はアジャイル著名人とディスカッションできるステージ

私自身は個々の質問が、というより、このスタイルに興味を持ちました。一般的に、日本で講演スタイルを取ると講演者が質問して、残り数分で質問の時間に入りますが、あまり質問できずに終わることが多いと思います。そして、スキマ時間に1対1で質問する人も多いと思います。

しかし、もっと講演者と聴講者が対話的になることで生まれる価値みたいなものもあるのでは?と思います。あるいは、「あ、○○さんいた。○○さんの方が詳しいからちょっと話してよ。」みたいな無茶ぶりすることで、別の視点が引き出せたり。指名された人はえーって驚きそうですが。

これまで、このスタイルはあまり一般的ではなかったですが、イベントでこういう対話的なセッションが増えてもいいなと思っています。


井芹 洋輝 さん:テストを支える。テストを育てる。



Test Driven Development for Embedded C読書会でご一緒した井芹さんの発表です。発表の内容は、現状のテストで起きる問題を「テストを育てる・支える」という視点で解決しようというものです。問題というのは以下のようなもの。
  • テストの保守性が低くて、変更の度に生産性が下がる。
  • テストの要求を見逃してしまったり、目的が異なるテスト同士が阻害しあったりする。
  • テスト全体として整合性がとれておらず、穴があったり冗長だったりする。
それに対する解決作は資料で詳しく解説されているので、そちらを参照していただきたいと思います^^; かなり情報量が多くて理解しきれていません。。

「育てる」の方は、ソフトウェア開発における要求分析やアーキテクチャ設計でよく言われるような話をテスト全体に適用しているような印象を受けました。

「支える」の方は、検討したテストが破綻しないように効率化したり、保守性を向上したりする話だと思います。一旦、作り上げた後もメンテナンスが走るのは世の常なのでどうフォローするかも重要な視点だと思います。

特に「育てる」の方で挙がってたテストの全体の計画については自分が計画する役割ではなかったとしても、その視点は持っていた方が良いと思うので、たびたび引用されていた「ソフトウェア・テスト PRESS 総集編 」は購入して読んでみようと思います。




最後に

おそらく、遊びを除いて、イベント参加はこれが今年最後だと思います。今回のイベントは自分が話す側だったこともあって、非常に有益な場だと思います。アウトプットする側の方が良いインプットも得られるというのが私の持論です。今、裏でいろいろと準備をしているので、またイベント参加の際は話す側に回って皆さんに情報提供したいと思います。いい話をできるように頑張ります!