#etrobo 2011東京・南関東・関西合同飲み会をやりました

1/14（土）に東京・南関東地区、そして関西地区それぞれで慰労会をやりました。その中で、Skypeでビデオチャットをつなげて、お互いに質問をやりとりをしてみました。

非常に有意義な会で、お互いに刺激を与え合うことができました。面白い取り組みだと思うので、やり取りの内容を乗っけてみます。

参加チーム

<東京地区>

• 飛べ! ぼくらの夢ヒコーキ
• StrayCab06
• チームSUPRAパンダ
• 田町レーシング
• 芝浦雑伎団

<南関東地区>

• TAKOS
• みらいウォーカー
• BNX
• ほぼ組
• AEK RUNNER11
• マイペース

<関西地区>

• ＨＡＫ
• 電子くん
• R-GRAY NEXT
• 猪名寺駅前徒歩１分
• NEXT KOBE 

（東京・南関東地区から関西地区へ質問その1）モデルとソースコードはどこまで一致していますか？　by ほぼ組

（関西地区）8～9割一致がちょこちょこです。逆に質問をしたいですが、どこまでやって100%なのでしょうか？完全にモデルから生成するだけで終わっているということでしょうか？

（東京・南関東）静的なクラス構造が一致していることです。関数内部のロジックは問いません。

（関西地区）クラス構造なら一致してるさ！

（関西地区）振る舞いなら100%だけど構造は90%とか謎のセリフも出ています。抽象的な部分は100%だけど具象化部分がもうちょっと、ということのようです。

（関西地区）そっちはどうですか？

（東京・南関東地区）静的構造の90%は一致しているけど、モデリングツールの機能的に難しいところがあり、100%には至りませんでしたた。by ほぼ組


（関西地区から東京・南関東地区へ質問その1）太陽光の影響が強いとのことですが、どのくらいですか？

（東京・南関東地区）試走と本番でセンサ値が違うのはざらです。by 芝浦雑技団

（関西地区）コース上に光の帯が出ている写真を見ましたが、その帯は移動するのですか? by HAK

（東京・南関東地区）ちょっとずつ移動しますよ。　by 田町レーシング2010大西

（関西地区）対応方法はマイマイ式だけですか？何か追加のやり方とか、そのあたりしか使わないとか、そんなTIPSがありますか？

（東京・南関東地区）マイマイを使ったのはチームSUPRAパンダさんだけでした。

（関西地区）それでも走れてしまうのですか？？

（東京・南関東地区）うちは光センサ値の移動平均とってました。移動平均を取るだけで、光の帯があるとこでもコースアウトしませんでした。by田町レーシング

（関西地区）そうなんですか。意外でした。


（東京・南関東地区から関西地区へ質問その2）R-GRAY NEXTさんへ。アイコンによるトレーサビリティはどれくらい時間かかりましたか？いつごろ導入しましたか？終盤？最初から？

（関西地区）アイコンを書くのは時間は滅茶苦茶かかりました。アイコンは3～4年前から導入していたので、最初から入っていました。

（東京・南関東地区）導入したのはロボコンですか？業務？アイコン入っている業務用のドキュメントを見てみたい！byほぼ組

（関西地区）業務じゃ使うわけないですよｗ


（関西地区から東京・南関東地区へ質問その2）SysMLの要求図を実際に業務で使っている方はどのくらいいますか？

（東京・南関東地区）ゼロです。そちらは？

（関西地区）学生さん（電子くん）が少し使ってみたと言われています。社会人は0ですね。

（東京・南関東地区）メリットは感じましたか?

（関西地区）機能と非機能をあわせて考えられたのが良かったです。


（東京・南関東地区から関西地区への質問その3）ロボコンのモデル図やロボコンの経験を業務にどれくらい生かせそうですか？byほぼ組

（関西地区）クラス図は超役立ってます。by R-GRAY NEXT

（関西地区）シーケンス図を書いたらUMLの説明に1時間かかりました…。by HAK

（関西地区）浸透してきたら分かりやすいとコメントされているそうです。 by HAK

（関西地区）ロボコンをやって読めるから書けるにステップアップしました。 by 猪名一

（関西地区）ぼくはよめるようになりました。by みずの

（関西地区）学外の人たちと触れられたのがとても刺激的でした。 by 電子くん

（関西地区）社会人でもこうやってたくさんの社外の人と触れられてつながりが出来るのが一番大きいとは思っています。

（東京・南関東地区）はい。いい意見ですね。たぶん、こっちも同じような意見ですね。


（関西地区から東京・南関東地区への質問その3）南関東・東京では連合活動が多いですが、具体的にどんな事をしましたか? あわせて、連合でどこまで共有してどこまで企業秘密にしているか、というあたりも教えてください。

（東京・南関東地区）月1くらいでモデルレビューしたり、試走会しました。また合宿しての試走会もしました。

（関西地区）合宿！？


（東京・南関東地区）企業の研修施設で、試走したり、モデルについてディスカッションしたり、卓球したり、マッサージチェアでマッサージうけたり。。卓球とマッサージで忙しくてワークショップに遅れたチームが1つ^^;

（関西地区）何？？めっちゃ楽しそう！！

（東京・南関東地区）情報共有の程度ですが、企業秘密はあまりなさそうです。ただ、終盤にモデルや競技の完成度が上がるので、結果的に一番大事な部分は共有できません。

（関西地区）コードレベルの共有もあったりしますか?

（東京・南関東地区）コードの共有はないですね。

（東京地区・南関東地区）では、そろそろコラボタイムは終わりですね。ありがとうございました。今年は、ともに上位を狙いましょう！

（関西地区）はい。お互いにがんばりましょう！！


本会を終えての所管


東京・南関東地区の方の〆の挨拶で、若いエンジニア達が企業の枠組みを超えて交流し、お互いに切磋琢磨していくことで、我々から日本をよくしていこう。経済を立て直していこうという、幾分か壮大な、でも本当にそうだと思える意見が出ました。


僕が個人の時間を使って、こういう活動をしている目的の一つと一致していると思いました。もちろん、個人の成長や仕事での成果につなげたいという個人的な気持ちはありますが。。がんばっている同世代の人たちを応援したいという気持ちが強いです。


今後も、企業とかチームとか地区とかせまいコミュニティだけでなく、参加者全体が切磋琢磨して成長していきましょう。それが自分のためにもなります。

英語を勉強する時はインプットとアウトプット両方やると良い

みなさん英語勉強していますか？私はほぼ毎日やってます。

先日、英語学習者の集まりに参加したのですが、英語を勉強している人が集まると、どういう勉強方法がいいか？という話題が挙がりますね。これまでの傾向で言うと、入門者の人ほどインプット中心で、文法やボキャブラリの学習に偏っている印象です。一方、ある程度、英語が使えるようになた人は会話や文章を書いたり、アウトプットの比率を増やしているようです。

僕の持論としては、バランスよくインプット・アウトプットの量をこなすのが一番だと思います。インプットに偏ると読んだり聞いたりはできるけど、英語を書く時や話すことができず、スムーズにコミュニケーションできなくなります。

このエントリでは、僕が日々やっているインプットとアウトプットを組み合わせた勉強方法を紹介します。

1. 文章と音声がついている英語記事を探す。

まずインプットのネタを探します。リーディングとリスニングの両方できる教材を探すのがポイントです。文章だけだと、どう発音されるか分からないし、音声だけだとちょっと聞き取るのに苦労します。だから両方付いている教材を探すわけです。

この時、自分が興味が持てる分野で、自分の英語レベルにちょうど良い、ある程度語彙が抑えているものを選ぶとよいと思います。興味が持てないような話題だと続かないし、語彙が難しすぎても続きません。英語はスポーツと一緒で継続が大事です。

 自分がお勧めなのは以下の3つです。私はVOA Special Englishから初めて、最近はBBC 6 minutes EnglishとTED Talkを併用しています。

• VOA Special English 
• BBC 6 minutes English
• TED Talk

VOA Special Englishはアメリカの国営放送VOA（Voice of America）がノンネイティブ向けに放送しているpodcastです。配信元の性格上、テーマがアメリカ寄りではありますが、テーマが多岐に渡っていて、いろいろな話を聞けるのが特徴。サイトでスクリプトを入手できます。スピードはかなり遅いので、初心者向けだと思います。

BBC 6 minutes EnglishはBBCが配信しているpodcastです。BBCのニュースをコンパクトに紹介しつつ、語彙の解説などもついていて親切です。語彙も比較的やさしめ。音声のスピードはネイティブに比べて少し遅い程度。中級者向けだと思います。

TED Talkは、15分程度の長さのスピーチがたくさん提供されています。テーマは非常に多岐に渡っていて、しかも個々のスピーチはとにかくレベルが高く、あきません。プレゼンの教材としても使えそうなのもよくあります。そして、カンファレンスのスピーチなので比較的聞き取りやすい話し方で話している点も良いと思います。ちょっとニュースだけじゃ飽きてきたという中級者向きだと思います。

2. 音声を聞きながらシャドーイングする（インプット：リスニングの練習）

入手したスクリプトを印刷しておきます。そして、1で入手したpodcastをiPodで聞きながら、同時にスクリプトも読みます。音声だけでは難しくても、スクリプトがついていると、かなり理解できると思います。

ここの練習としては、リスニングだけでなくシャドーイングという音声に続いて一緒に話す練習をするとよいと思います。シャドーイングをやる時は、続いて話さないといけないのでより注意深く聞くようになります。繰り返しやると、リスニング力の向上が自覚できるようになると思います。

私は通勤途中によくシャドーイングをしています。あまり大きな声でやると怪しい人だと思われます。恥ずかしがらずに（ただし少し小声で）やりましょう。

3. 音声を聞きながらスクリプトを音読する（インプット：リーディングの練習）

リスニングやシャドーイングだけでなく、音声を聞きながらの音読なども組み合わせてやるとよいと思います。

音声を聞く理由は、文章の順番に意味を取る練習をするためです。日本人の多くは学校の英語の影響で、英語を見ると文章を解体して、日本語に翻訳する傾向にありますが、はっきりいうとスピードが落ちるのでお勧めできません。英語は英語の順番で理解すべきです。それを強制的にやるためにも音声を聞きながら読んだ方がよいと思います。

4. 英語で感想文を書き、英語学習者のSNSに公開する（アウトプット：ライティングの練習）

ここからがこのエントリのハイライトですよ。英語を聞いたり読んだりインプットしだけで満足しちゃいけません。英語はコミュニケーションの道具です。アウトプットもできないと英語スキルは不完全です。

アウトプットする時のお勧めとしては、自分の日記に書いて終わりにせずに、誰かに伝えた方が練習としても効果は高くなります。レベルがある程度にならないと恥ずかしいとか言う人いますけど、気にせずどんどん出してください。はっきり言って自分の語学力が低いから文章を人に読ませたくないなんて言ってるの日本人だけです。国際会議とか行くと、発音がめちゃくちゃでもインド人や中国の人が積極的に活躍していますよ。不完全なものでも出しましょう。どんどん人にさらして相手の反応を見ないと、改善サイクルが回っていきません。

ここで日記を書く場として、お勧めしたいのが英語学習に関心のある人がいる場所に文章をさらすことです。おすすめは以下です。

• アルコムワールド
• lang8

アルコムワールドは、アルクという英語教材を販売している会社がやっているSNSですが、アルクの教材を買わなくても利用できます。実は、私はあまり英語にお金をかけない主義なので、アルクの教材を買ったことありません　＾＾；　

アルコムワールドはクラブというコミュニティがたくさんあって、活発に議論が行われています。私は、「英語記事を読む（聞く）会」というのに所属してて、ここに書かれている記事を読んだり、自分でも記事を書いたりしています。翻訳など英語を武器に仕事している人とかも混じっており、非常にレベルが高いので、彼らのやり取りを見るだけでもモチベーション維持の効果があります。

後者のlang8は、多言語対応の相互添削型SNSです。 英語や日本語だけじゃなく、アラビア語やロシア語やら、あらゆる言語の学習者がお互いの日記を添削しています。アルコムワールドがほぼ日本人だったのに対し、こちらはいろんな国籍の人が参加しています。

lang8が少し変わっているのが相互に添削をすること。相互添削が原則なので、こちらの日記を添削してもらう代わりに、日本語を学んでいる人の日記も添削してあげるとよいでしょう。たくさん添削してあげるとこちらも添削してもらいやすくなります。 いろんな人がお互いの学習を支援しあうという形態は、非常にインターネット的でもあり、私はすごいしっくり着ています。

ただし、語学を教えるのが専門の人が添削してくれるわけでもないので、添削の質は期待しないほうがいいかもしれません。「ネイティブから見て自然な書き方になっているか？」という使い方をするのがベターだと思います。

5. 読んだ記事について誰かと話す（アウトプット：スピーキングの練習）

ここは私はあまりやっていませんが、スピーキングの練習として読んだ記事について話すことも入れるとパーフェクトだと思います。日記を書いて添削してもらった後にやると、トピックについて理解できているので、スムーズに会話できると思います。

英語で話す相手がいない人は、最近はやりのSkype 英会話などを使うと良いと思います。Skype英会話だと、こちらからチューターに話題を提案すれば、記事について話できると思います。ただし、チューターが記事を読んでいないので、記事の内容を説明する手間がありますが、それ自体も簡潔に話す練習だと思えばよいのではないでしょうか？


---

いかがでしたか？英語の勉強の仕方は千差万別です。ここに書いているやり方は、お金がかからないし、楽しいので私は気に入っています。よかったら皆さんの勉強法も教えてください。

#etrobo で勝つために、どういう考え方が必要なのか？

まずは競合チームは何を考えているのか？それに対して我々は何ものか？我々しか提供できない価値は何なのか？という考え方です。

それだけではトップ10は入れても、トップ3に入れません。

トップ3に入るために何が必要でしょうか？

最終的な評価を行っている人が、あなた達がやっていることはすごい価値がありますとどうやって言ってもらえるかを考えることにあると思います。

ETロボコンであれば、競技規約でリザルトタイムが一番短いやつが優勝って言っているので、リザルトタイムを短縮するためにどう役にたっているかを提示する必要があります。

それは、ETロボコンを横においておいて、自分達が普段作っている製品の価値を考えると分かりやすいと思います。

我々はソフトウェアをキレイに作っています。論理的にうまくいく事を検証し、裏取ってますと言ったところで、自分の製品を使っている人にとっては、「それが私に何の関係があるんですか？」になってしまいます。

難しいのは、自分達がやりたいこととどう折り合いをつけるか？それは非常に難しい問題で、考えていかないといけない課題だと思います。

自分たちがやりたいこと、皆に求められていることが大きく重なるポイントを考えるのが一番でしょうけど、それできたらそもそも苦労しないしw

#CJP クーリエ12月号で朝食会＠自由が丘をやりました

これで三回目です。


前回の社会企業家特集の時は、わりと人が集まったんですが、今回の経済特集は人が少なかったです。集め方が悪かったのか、経済というテーマに集客力がないのかは今後観察していきます。

今回、「Occupy wall strert」を取り上げました

今回、私が取り上げたのは町山智浩氏の『激変するアメリカのメディア界を追え！USニュースの番犬『第23回ウォール街を選挙する若者達の講義活動が意味するもの』」。ウォール街で「Occupy wall street」という若い学生／フリーター／失業者を中心に、貧富格差の拡大を容認している政府を批判するデモがあったというやつです。アメリカでは上位5%が国富の40%を独占する一方で、公的医療保険がないあまりに、医療すらろくに受けられない貧困層が拡大しています。

私自身は、このデモ自体に興味があるわけではないですが、彼らがデモをやらざるをえない状況を生み出している経済状況を無視できない事情があります。

彼らが失業した理由の一旦は、技術の発達によって労働が機械に代替されていること、経済のグローバル化によって賃金が安い途上国に労働が移転していることだと言われています。これは製造業が事実上壊滅したアメリカに限った話ではなく、日本においても同じ状況にあります。実際にうちの身内も、何度か派遣切りにあって、かなり真剣な家族会議を何度も繰り返した時期がありました。世界の情勢に疎いうちの両親には理解できないメカニズムによって、身近な人の労働が奪われています。

先進国と途上国の賃金格差が埋まるまで、これは避けられない時代の流れであり、私自身はそれでも生きて行けるような道を自分で選んで行かざるをえないと思っています。どうしたら機械や途上国の労働者に仕事を代替されないか、先進国の全ての人が考える必要があります。

ある人は、金融や情報のような知的サービス産業の就業人口を増やせば良いと言っていました。私も同じ考えはあります。一人一人の生き方としてはそれが適切だと思います。私に子供がいたら、世界の動きと今後自分の身に降り掛かる状況について説明して、どういう考え方をすべきか話をするでしょう。

しかし、それを皆ができるほど強いのか疑問に思います。私の実家のあたりの人のように情緒的な日本人に、そのような強さを求めることに疑問を感じてしまいます。

一番良いのは、今後、民間の設備投資を促すような分野に政府がインフラ投資を行い、国内の雇用を吸収できるような産業が発達することですが、今、そういうことを考えている政治家は少ないです。残念。

#お上に頼れと言っている訳ではないですよ。民間が国内に設備投資をしない以上、政府が需要を作り出す以外に方法ないと思っています。ただし、政府がやる産業政策は失敗するのでNGで。あくまで需要が伸びるようなインフラ投資をすること。

クーリエジャポンに期待すること

なんかとりとめも無い感じになりました。
私は、クーリエジャポンは最近まれに見る質の高い雑誌だと評価しているので、今後ともいろいろ考えさせられる編集をやってほしいと思います。応援の意味でも、朝食会は続けて行こうと思います。

ただし、最近の特集は

• 個々の記事は良くても、全体を通してのテーマ性が弱かったり、
• 現状分析があっても、今後どういう考え方をすればよいか提案がなかったり、

するものが多いように思います。海外の記事を集めましただけではなく、何か読者に訴えかけてくるような何かを期待します。値段の割に高い注文ですんませんですが。

では、また来月朝食会やります。今度は人集まるといいなー。

#etrobo 「VDMで戦うETロボコン2011～Project VDM 2年目の挑戦～」を読んで

オブジェクトの広場2011年11月号にProjectVDMさんのETロボコン2011参戦記が掲載されました。

著者の植木さんは、私が2011年4月から6月にかけてロボコンのモデルに関する記事を連載したときに、Twitterに記事の感想をつぶやいていたのをきっかけに知り合った方です。

今回は、2011年の東京地区大会が終わった直後に参加しての感想をつぶやいていたので、参戦記を書いてみませんか？と誘ったところ、快く了承していただいて立派な記事を書いてくださりました。ありがたいです。

実は直接お会いして話した経験はありません・・・。

■Project VDMさんの取り組みについて

ProjectVDMさんがやっていることは、ロボコンの制御プログラムを実装してしまう前に、アーキテクチャ（全体的な構成）の実現性を形式手法という手法で検証したというものです。形式手法の実装言語としてはVDM++、ツールとしてはVDMToolsやVDMUnitというものを使っています。

また、2010年参加時に検証に使ったコードをそのままモデルシートに載せても審査委員に伝わらなかったという反省を生かして、2011年はUMLモデルとの対応付けを分かりやすくしたとのことです。

■ETロボコンでも形式手法は使えそうだ

この形式手法というのは、私は業務で見た経験はないですが、航空業界などミッションクリティカルな分野で活用されているようですね。仕様の間違いによって発生する不具合で、大きな損害（人命、金銭）が出てしまう場合に、ものを作る前に仕様が正しいことを保証しようという目的で使われるようです。

複雑な状態遷移や、並行処理の微妙なタイミングによって不具合がおきやすいところは使いどころだと感じます。ETロボコンで言えば、以下のようなところに使えるのではないでしょうか？

• 各難所の走行制御の仕様化
• マルチタスクにした場合に時間制約を守れることの確認
• 走行体内の各ハードウェア制御や、Bluetooth通信を活用する場合の走行と通信応答の兼ね合いなど

実際に、ほぼ組さんはBluetoothを使って制御パラメタをPCに送信する仕組みを作っているようですが、その際にマルチタスク処理の仕様はLTSA（Labelled Transition System Analyser）という形式手法のツールで検証されていたようです。

■Project VDMさんのVDM活用について

一方で、Project VDMさんが活用しているのは、よくある区間切り替え部分の検証です。記事に書いている範囲では、UMLのクラス図やコミュニケーション図（もしくはシーケンス図）で確認できる範囲かな？という印象を受けました。「マルチタスクやらハードの制御が複雑に絡み合って、UMLでは確認できない」というものではない印象を受けました。

ただ、まとめの部分に制御アルゴリズムへの適用を匂わせている記述があるので、本当にVDMが生きてくるところは来年以降出てくるのかな？と期待しています。

■開発プロセスとの絡みが知りたい

読んでいて疑問に思ったのは開発プロセスとどう関係してくるのか？というところです。

実開発では、仕様が固まっていない状態で大規模に人員を投入するわけにもいかないので、実開発が始まる前に仕様を固める段階で形式手法によるモデル検証を行うのでは？と予想しています。

一方、ETロボコンでは、時間的にも人手的にも、そう悠長なことを言っていられないはずなので、開発のプロセスとモデル検証のプロセスが平行して、フィードバックをまわしていくのではないかと思います。

• 開発のプロセスでは、UMLでアーキテクチャとサブシステムを設計し、実装に落として、コースでの走行テストを行う。
• モデル検証のプロセスでは、仕様化が難しそうなところをピックアップして、モデルで検証した仕様を開発のプロセスに展開する。

両者は完全に分離しているわけではなく、開発のプロセスの中で走らせて分かったことはモデル検証のプロセスにインプットされるし、モデル検証のプロセスで検証したことは開発のプロセスへのインプットになります。

実際にやったわけじゃないので、妄想ですがｗ どなたかノウハウ持っていたら、ブログ記事にでも挙げてくれるとうれしいです。ワークショップに行って聞けば教えてもらえるかもしれないけど、ネットを補完的に使えたらいいなー＾＾；

■参戦記募集！

地区大会の参戦記では1本のみでしたが、希望者いれば他にも参戦記を書いてもらいたいと思っています。もし希望者いたら、私までご連絡ください。「地区大会敗退したけど書いてみたい」という人でも歓迎しますよ。

#etrobo ETロボコン東京・南関東地区合同合宿をやりました

ETロボコンの東京地区・南関東地区のチャンピオンシップ大会参加者を中心に合宿つき合同試走会をやりました。結構珍しい取り組みかと思われるので、記録に残しておきます。

合宿の概要

• 日時：2011/11/5（土）〜11/6（日）
• 場所：TDI人材開発センター（静岡県熱海市）
• 目的
• チャンピオンシップ大会向けの合同試走会
• ETロボコン参加チーム間の交流

参加チーム
※総勢40人近くいたんじゃないでしょうか？

○CS選抜チーム

• StrayCab06（東京）
• 芝浦雑技団（東京）
• AEK RUNNER11（南関東）
• BERMUDA（南関東）
• みらいウォーカー（南関東）
• ほぼ組（南関東）

○地区大会敗退チーム

• マイペース（南関東）
• こっぺぱん♪♪（南関東）
• H23（南関東）
• チームてづっち（東海）

スケジュール
○11/5（土）
13:00 第一陣が到着。コース設営開始。
13:30 全員集合後、各チーム自己紹介。
14:00 試走開始
18:00 夕食
20:00 モデルワークショップ（と称した飲み会）
    - 各チームのモデルを見ながらわいがや
※この辺はただの飲み会です。

○11/6（日）
08:00 朝食
〜試走時間〜
12:00 昼食
13:30 模擬競技会
15:00 片付け後解散

模擬競技会

本番と全く同じ形式で競技をやりました。
各チーム、練習場との環境の違いに苦しんで、うまく調整できていなかったようです。競技会では、リタイアが続出しました。

そんな中、AEK RUNNER11、みらいウォーカーはぶっちぎりの速さでした。この2チームは本番でもきっちり仕上げてくるんでしょうね。

面白かったのは、ほぼ組。Bluetooth通信でPCから制御パラメタを送信して、パラメタ調整できるようにしていました。確かに、コンパイル＆ダウンロードはいっさいせずにコース付近でずっと調整をやっていたのには驚きでした。これは作業効率化の効果は大きそうです。

モデルワークショップ（と称した飲み会）

プロジェクターを用意して、モデルシートをスクリーンに投影しつつ、だらだら飲む感じの懇親会をやりました。結構議論が白熱したのは、ほぼ組とマイペースのモデルだったと思います。

ほぼ組は、いかにBluetooth通信経由でPCからパラメタ調整しやすくするかを徹底して考えていました。視点がかなり独特ですが、目的が明確で分析が徹底しているので、CSでもかなり評価されるのでは？と思いました。

マイペースについては、本人達がクラス図が分からないとよく口にしてたので、私が企画してネタふりしてみました。ここで話した内容は気が向いたら、ブログに書いてみようと思います。モデリングやオブジェクト指向に入門した人が素朴に疑問に思うことを話してたと思います。

所感

これまでうちの会社のコースを開放し、南関東地区のチームが混じっている合同試走会はよくやっていました。しかし、これだけ大規模で、かつ合宿つきは初めてです。

試走やるだけじゃなく、お酒を飲みながらお互いのロボコンの取り組みについて話するのは、お互いに刺激になっていたようです。皆さんが楽しそうにされていたので、スタッフ側としてうれしく感じました。
今回は、M田さんにいろいろ段取りしていただいたおかげで開催できました。来年以降も何かやれるといいっすね。

おまけ

湯河原ええ感じのとこでしたよ〜
ロボコン抜きで自然を散策＆温泉でも良かった〜

#tddbc TDD Boot Camp 東京 for C++ に参加してきました

C++プログラマ向けのTDD Boot Campに参加してきました。「ブログに書くまでがTDDBCです」とのことなので、参加報告をまとめておきます。

■TDDC BootCampとは？

TDD Boot CampはTDD（テスト駆動開発）について、実習形式で手を動かして体得することを目的とするイベントです。全国各地で開催されているようです。
http://devtesting.jp/tddbc/

今回のプログラミング言語はC++でしたが、他の開催日は言語を複数やることが多いようです。例えば、11/5の横浜はJava(JUnit4)、Ruby、C (cunit)、C++ (Emacs+cppunit/Google Test)、Groovy(Spock)、PHP(PHPUnit)、JavaScript(QUnit)と多彩です。
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C

■TDD Boot Camp 東京 for C++のプログラム

講演と実習＆レビューの繰り返しでした。みんなが煮詰まってきたら、適度なタイミングで講演やら休憩が入って助かりました。時折、チーム間のレビューや、全体でのレビューが入り、頭の中を整理しながら、課題に取り組めるように工夫されていました。

詳しくはイベント告知ページを参照。

09:30～10:00 開場
10:00～10:05 会場説明
10:05～10:35 中村薫さんによる講演(@kaoru)
10:35～12:00 実習＆レビュー
12:00～13:00 お昼休憩
13:00～13:40 井芹洋輝さんによる講演(@goyoki)
13:40～15:00 演習
15:00～15:30 レビュー、休憩
15:30～17:15 演習（続き）
17:15～18:15 レビュー、ふりかえり
18:15～18:30 和田さんによる総括と締めの講演(@t_wada)
18:30～ お片づけと懇親会

■TDDの演習課題
いわゆる探索の問題でした。

TDD Boot Camp 東京 for C++ 課題

View more presentations from Takashi Imagire

近いうちにどんなコードになるか公開しますので、お楽しみに。

■講演：TDDBC中村ヘようこそ（by @kaorun）

Welcome tddbc

View more presentations from かおる なかむら

TDDをやる目的や考え方が良く分かる講演でした。内容の詳細に関してはslideshareやブログ記事を参照してください。講演の中で特に心に残ったのは以下ですね。

• バージョン管理、タスク管理、自動化されたテストはプログラマの躾である。
• これらの躾をする目的はプログラマの心と体の健康を保つこと。

非常に納得感がありました。
私の場合、業務でオブジェクト指向設計でテストしやすい構造にしていますが、今思うと「心と体の健康を保つ」を狙っていたように感じます。テストをしやすい設計にすると、単体テストでロジックのミスを検出できるので、実機でのシステムテストが楽になって心が穏やかな状態で開発できますから。

おそらくはTDDもインタフェースを意識した設計にすることを目的にしていると感じているので、オブジェクト指向設計と似た効果を狙っているんじゃないか？と思いました。

ここ1年は「開発者の心と体の健康を保つ」は自分の中のキーワードとして心に留めておきます。

■講演：TDDネクストステップ（@goyoki）

テスト駆動開発入門ネクストステップ

View more presentations from H Iseri

こちらはTDDを実践するときの知識や、今後学習を進めていく上で有益な情報がつまっていました。

テストコードもメンテナンスプログラムである以上、プロダクトコードと同じように保守性を高く保つ必要があるという点が非常に有益でした。テストコードの保守性を上げるには、プロダクトコードを設計するときの同じ考え方で設計することが重要になるようです。

また、なるべくテスティングフレームワークの機能を活用することだと感じました。googletestを調べた感じでは、フィクスチャやParameterized Testなどの機能をうまく使うと、重複を排除できて、テストコードを書く量自体も減らせそうです。

講演中にTDDを学ぶ上での良書を紹介してくれていました。特にお勧めは以下の3つ。

テスト駆動開発入門

ケント ベック

ピアソンエデュケーション

発売日：2003-09

ブクログでレビューを見る»

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

Gerard Meszaros

Addison-Wesley Professional

発売日：2007-05-31

ブクログでレビューを見る»

レガシーコード改善ガイド (Object Oriented SELECTION)

マイケル・C・フェザーズ

翔泳社

発売日：2009-07-14

ブクログでレビューを見る»

レガシーコード改善ガイドは積読しているので、読みきります。

■講演：〆の講演（by @t_wada)

さすがの @t_wada さんで、聴衆が引き付けられる、すごい力がありました。Twitterでめっちゃつぶやいたので、すごい心に残ったものを少し挙げておきます。私が書きとめたものなので、実際に話しした内容とは多少違ってるかもしれません。

• なぜTDDをやるのか？自分が完璧ではないと知っているから。最初から思い通りにできるほど、対象は簡単ではない。素早く対処にちか付きながら、フィードバックを得ながらじりじりと動いて行く。
• 少しずつ動く開発の必要生を感じているからTDDをやる。テストは目的ではなく手段。ソフトウェア工学的なメリとではなく、書いたコードに自身を持つため。テストに通ったなら、少なくとも自分が考えた通りには動いている。
• テスト設計は間引きの考え方。どれだけのテストをやれば全部テストしていると言えるかを考える。
• 知識のインデックスを作る。グラフ、経路、重み。全部知るのではなく、探したいものに対してインデックスを貼っておくことがスキルの差別かにつながる。
• テストが無いコードがたくさんある。その現状に対してどう戦うか？その際にヒントになるのはレガシーコード改善ガイド。どうやって自信のある領域を作って行くか、そのヒントが詰まっている。
• 祈りではなく自信を。新規に書くときはテストコードを書こう。たくさん本を読もう。考え方を知ろう。書籍の中でよく参考文献に上がっている本を読む。
• TDDはスキルである。才能ではない。テストコードを書けばばくほどうまくなる。

@t_wada さんの講演を聞いて心構えは十分だと感じました。あとは実践ですね。業務の品質改善ネタにテストが入っていたので、レガシーコード改善ガイドなどを片手にテストに取り組んでいこうと思います。

■全体を通しての感想

イベント中から懇親会にかけて、組み込み屋さん、ゲーム屋さんといろいろ話しました。皆、業務ではテストコードのないレガシーコードにまみれていて、リリース間近は踏んだり蹴ったりの状態になっているようです。自動化されたテストに対する期待感は高いよう。

だからこそ、TDDBCに疑問を解決するために皆さん集っているようです。その期待に対して、TDDBCはTDDの考え方や実践的なスキルを経験する場として期待にこたえていると感じました。一方で、TDDBCで扱える内容だけで、業務のプロダクトコードに対応できるかというとそうではないと思います。もっと仕様やコードが複雑だし、金も時間もないし、絶望的な状況は多いです。

TDDBCはひとつのきっかけ。もらったヒントを手に、それぞれ自分の戦場でいかに戦うかは自分次第でしょう。

といいつつ、私自身は参加して満足です。しばらく自動化されたテストは自分の中の大きなテーマに設定しているので、継続的に学習は続けようと思います。

■Stay Tuned
近いうちにTest Driven Development for Embedded Cの読書会をやろうと思います。
時期が決まれば仲間を募集したいっす。

Test-Driven Development for Embedded C (Pragmatic Programmers)

James W. Grenning

Pragmatic Bookshelf

発売日：2011-05-02

ブクログでレビューを見る»