Hatena::ブログ(Diary)

Munch Box

2014-10-04 第十三回 アジャイルサムライ読書会 埼玉道場に参加してきました(TD

 最近、仕事でもプライベートの方でも色々忙しく、勉強会にも月イチがせいぜいな
感じで参加するのがやっとという感じで、ブログもサッパリ更新できず、、、悶々と・・・
長くなるので(略)

 さて、お題の通りアジャイルサムライ読書会(埼玉道場)に参加してきました。

(「ざっくり」とまとめたつもりが、、、エラく長くなってもた。。。orz

「第十三回 アジャイルサムライ読書会
http://bit.ly/1BGPIVm

今回はTDDの章という事もあり、ゲストは t_wada さんでした。
⇒ どうやら第1回目のジョナサンがゲストに来てくれた時以来の大入りで、
  15名の方々の参加がありました。

 流れは例の如く、今回は14章のテスト駆動開発の章を音読し、
チーム内で出た疑問をふせんにまとめ、それを全体でドット投票して
ネタを厳選して議論するという流れでした。ちなみに今回は
A卓、B卓、C卓の3卓に別れ、各テーブル5名ずつで進める事になりました。

 で、以下簡単にメモからの抜粋を。

【チーム内で出た話】
「お題:不慣れな言語でTDDを始める時はどうすればいい?」
 ⇒ ・RubyならRubyJavaならJavaで書き方にクセやセオリーがあるので
    良いお手本になるようなソース(例えばOSSとか)を読んだら良いと思う。
   ・いきなりTDDを始めようとすると(本にもある通り、TDDは色々な技術の
    集大成的なところがあるので)ハードルが上がるので、まずは
    デバッグ的に始めてみるのはどうだろう。

【全体で議論した話】
「お題:TDDを習慣化させるコツは?」
「お題:ユニットテストを書く時や書かないときのムラを無くす為には?(メンタル的・技術的に)」
「お題:テストコードを書かない職場の雰囲気を変えるには?」

 ⇒ 参加者の皆さんから幾つかの回答が出ました。
   ・TDDが始まった時のキッカケは、お金に直結する部分でバグが出て
    大騒ぎになったから。
   ・設計が整理できて、コードを書く時間がトータルで見ると減った。
   ・リファクタリングが躊躇無くできるようになった。
   ・全部に対してテストコードを書こうとしない。
   ・テストファーストにこだわらない。
   ・2人目の自分を作る
   ・デプロイメントパイプラインを作ってテストコードを書かないと
    コミットできないような仕組みを作る。
   
 t_wadaさんのまとめ
  ⇒ ざっくりまとめると、「1.TDDを導入するまで(キッカケ)」と
    「2.TDDを導入した後の継続」の2つのフェーズに分かれる。
    
    1.については参加者からも話があったが、
    某Coo●●ad社も以前はテストコードがゼロだったが、一度
    お金に関わる部分でバグを出し、それから書くようになった。そういう
    「痛い目に遭って」改善されるというパターンがある。
    
    2.については、リファクタリングのタイミングが分かりやすくなる
    というメリットが継続のモチベーションに繋がる場合がある。
    また、2人目を作るのは重要。その時は「TDD」ということだけではなく
    「変化」に対して共感できる人を募るのが重要。
    
    技術についてはペアプロが一番伝達しやすいのでは。
    ただ、2割位の人は「ペアプロ」が出来ない、という研究結果もあるので
    要注意。(強制はダメ)。
    そもそもペアプロはスゴク疲れるので、例えば新規機能の実装時のみ、
    月曜はペアプロの日、バグが出た時にその改修だけ、という具合に
    実施するポイントを決めるというのが良いかも。
    
    それと(TDDを伝える場合)相手にとって「刺さる」もので伝える事が大切。
    「(品)質」を気にする人には「(品)質が上がる」であるとか、
    「損得勘定で動く」人には「ペアプロがどれだけ得になるか」とか。
    
    後、エライ人に薦める場合、技術等が分かる人であれば話は通りやすいが
    分からない人には論文からの引用データで説明するという手がある。
    
    で、ちょっと質問したのですが「ダマテン(エライ人には黙ってやる)での
    実践は?」ということに関しては、
    「基本的にはお奨めできない。けど、事例はたくさん聞く。
     その場合、徹底するのであればリポジトリにテストコードをコミットせずに
     完全ステルスでやったという話も聞いた」
    参加者の方からは「分からないように、Frameworkのテストコードの中に混ぜた」なんて話も(^^;;
    
    また、t_wada さんから「質を下げれば納期が早まる」というような
    「(品)質」と「納期」をシーソーにかけたような考え方が未だに
    横行しているが、これは誤りである、という話もありました。
    ⇒ 「質」を高める事で「結果的に(ソースの解析・作成・テストの)スピードが高まり」
      納期も早まる、という考え方の方が正しい、と。
 
 で、ココで一旦休憩。
 
 続いて、
 「お題:本の中で「危ないところ」に対してテストする、というのがあったが、「危ない」というのは
     その人によって違うのでは?」
 「お題:全部が危ない場合のテストは?」
 「お題:危ないという事を決める人は?」
 「お題:全て(テストする)、と危ないところ(をテストする)の違いは?」
 「お題:危なっかしい、というところの見つけ方は?(特に自分の専門外の分野の場合)」
 
 というネタが議論の土台に上がりました。会場の時間の都合(と続く懇親会の時間の都合)の為
 「巻き」で進めたので、早速 t_wada さんのまとめ。
 
  ⇒ まず、前提として「危ない」という感覚は個人の主観に委ねられる所が大きく、定量化もしにくい
   (ので、昔から議論の対象になってきた)。
    そのため、例えばチームで仕事をする場合、「一番リスクに敏感な人のレベルに合わせる」とか
    「チームメンバの意見を平均化する」とかいうルールを決めて進めるのが良さそう。
    
    t_wada さん自身は例えば「カバレッジレポートと自分の感覚を突き合わせてそのズレを確かめる」
    ということを継続していて、それによって「危ない」という「感覚」がどれ位確からしいかを
    見ているそうです。
    
    自分の専門外の分野の場合、静的なコード解析結果なんかも利用して「危なそう」な所を
    見つける工夫もされているそうです。(動的なテストを書ききれないような既存コードの場合も)
    
    要は「自分の感覚を磨き続けて、「危なさ」に対しての嗅覚を研ぎ澄ませておく」という事が
    重要ということなんではないでしょうか。
    
    後、話の中で「原文では確か【break】という単語が使われていて「壊れやすいコード」という
    意味である、という補足もありました。
    
    そこで、個人的には「危ない」という意味は腹落ちしていたんですが、「壊れる」という
    意味がイマイチ理解できてなかったので、質問をぶつけてみました。
    
    
    「危ない、というのは個人の感覚的なもので、割と腹落ちできたが、「壊れる」という
     事はどういうことでしょう?コードは(それが完璧な物かどうかはともかく)変更しなければ
     そのまま同じ結果を吐き出し続ける(=良くはならないけど、壊れもせず変化しない)と思うんですが?」
    
    回答としては「確かに「コード自体」は壊れないが、【環境】は変化していく。その結果として
    そのコードが正しくない答えを返してしまう。そういう場合に「壊れる」と表現しているのではないか」
    ということでした。
    「(そんなものが世の中に存在しているか、存在できるかは別として)もし100%完璧なコードと言う物が
     存在していたとして、そのコードと比較した場合に「壊れている=正しい答えを返さない」コード」
     という意味で「壊れている」という意味でしょうか?」という追加質問したら「Yes」ということだったので
    個人的には納得。
    
    
    また、「たくさん書き換えられているコード(=リビジョンがやたら上がっているクラスとか)」は
    「危ない」と考える事も出来る、というお話もありました。
    
    結局、↑の通り、「危ない」という定義自体がフワッとしている分、周りで測れる(計測できる)モノがあれば
    それを測って、定量化(客観化)していきましょう、という事でした。
 
 t_wada さんの悩み(ワラ
 
  後、余談ですが、議論のネタ付箋の中に「テストコードを書いているけど、TDD出来ていない」というものがありましたが
  最近良く「TDDできてないんですよ。。。」と申し訳無さそうに t_wada さんに話しかける人が多いとの事。
  結論から言うと、「気にしなくていい!」という事でした。
  
  ある意味「TDD」という単語がキャズムを超えて一般化した単語になったという一例なのかもしれませんが、
  ちょっと「宗教化」してきているようで、個人的には「。。。」という感じだそうです。
  
  ⇒ それについては主催の inda_re さんからも意見があって、結局 本(アジャイルサムライ)の始めに書いてある
    「大きな問題は小さくする」とか「ちゃんと動くソフトウェアを届ける」といった事を実現する為の
    「やり方」の一つとして「TDD」に取り組むのは良いが、「TDDをやる事」が目的になるのはどうだろう、
    という事でした。
  
  後、TDDには狭義のTDD(ボブ・マーティンが言ってるようなTDD)と広義のTDDがあるが、
  狭義の意味では「TDDを始める時の養成ギプス」としてはいいかもしれないが、それに捉われすぎると
  ついこの前の「TDD is Dead(http://bit.ly/1rcEdPB 日本語訳はやっとむさんが http://bit.ly/1rcEhij に)」とかいう話に
  いってしまうのではないか、という事でした。
  
  結局「TDD」をやってない事に引け目を感じる事は無いし、逆に「TDD」やってるからバグは無くて完璧だ、
  何て思い込みも危険だよ、というお話でした。
  
  最後に、 t_wada さんの補足として、「テストコードとプロダクトコードを書く時間的タイミングが近いこと」
  というのが「TDD ができているか、いないか」の違いではないか、という事でした。何故かというと
  テストコードがプロダクトコードに(良い)影響を与え、設計が改善されるからという事でした。
  なので、テストコードを先に書くか、後に書くかはそれほど大きな問題ではなくて、
  「テストコードを書くことでプロダクトコードが改善されていない=TDDではない」ということになるかな、と。
  
  ⇒ 最後に inda_re さんから、参加していた常連の某氏にムチャ振りがあったんですが、その方が仰っていたのが
    「(TDDに限らず、チームを変化させようとする場合)全員を相手にしない」という事です。
    やはり、1人や2人は乗ってこない人がいるので、そういう人を納得させる為にエネルギーを使うより
    ↑に出ていたように2人目を作って(巻き込んで)、その他のメンバーに伝えていくのが良い、という事でした。
 
 ってなワケで、本編終了。
 
 続いて懇親会なんですが、電車的都合により、開始から1時間位で先に上がる事になったんですが、
 スペシャルゲストに某スクラムマスター登場(やっぱりか!ワラ)。
 
 残念ながらちょっとテーブルが離れてしまってたので、今回はあまり話せてなかったんですが、
 変わりに道場常連の方と某てら●でさんと話をして、今丁度悩んでいるC# でのテスト方法について
 いいヒントをもらう事が出来ました。
 ⇒ ってか、丁度JJUGに応募したネタだったとか。とりあえず今回のPJTで試してみて
   何かFBかブログにまとめようかな、と。あ、そう言えばSessionStateServerで大ハマりしたこととか
   WinRMにヒドい目にあったこと、まとめてねぇな。。。
 
 そういや、今年のデブサミで t_wada さんに質問して、腹が括れて取り組んだ
 前プロジェクトの PL/SQL でのテストの件(※)とか結果だけでも報告したかったなぁ。。。
 
 ⇒ 結論から言うと、何とか上手く行ったみたいです。と、いうのも自分は結局
   リリースまで立ち会う事が出来なくて、その後の話をつい先日チームリーダから聞いたんですが。
   (とりあえず僕が担当して、その方法を実践した箇所についてはバグは殆ど
    出なかったらしいんですが、、、まぁ、色々合って結局遅れた話とかは置いといて(ワラ)
 
   (※)PL/SQLを上手くテストする方法(既成のフレームワークとか)が見つからなくて、
      「JavaとJ-UnitとDBUnit辺りを組み合わせて作ったら?」みたいなアドバイスもあったんですが、
      結局、(作成・検証する時間・工数がなかった。作った後でメンテできそうな人がいなかった等の理由で)
      「Excel に前提条件(と期待値)作成して、それをそのままSQL文になるような数式だけ書いて、
       PL/SQL実行前に流し込んで、対象のPL/SQL実行。その結果をSQLで引っこ抜いて、
       準備していた↑のExcelに貼り付けて「○・×」で検証する」という、、、
       これ、俺のTLに流したら非難轟々になるんだろーなー、という方法でやっつけてしまいました。。。
 
 っと、まだまだ雨の勢いが強いなぁ。。。(今日は台風18号の為に、午前半休にしてこのブログ書いてたりして)
 さて、今の仕事の仕組みを考えてみるかなー。

2014-04-29 新人君へのアドバイス集(その1)

 2月半ばから本社を離れ、(一応数ヶ月の約束で)別の現場の方にヘルプに出てます。
そこで今年の4月で2年目を迎える新人君と、今年で4年目(?)位だけど
今迄全く開発に携わる機会が無かったメンバー2人と仕事をする事になり、
老婆心ながらこの二人に何とか自分の持ってる知識の一部でも伝える事が出来ればと思い、
日々アドバイスやらレビューバックした事をメモして、月一回それぞれに振り返りの為に送る
なんて事をしてました。

 結論を言ってしまうと、残念ながら前者の2年目君については、、、これ以上の
続行が難しいと判断して、自分の中で終了としてしまいました。。。。

 ただ、それ迄に記録した事がムダになるのも勿体無いので、業務とか現場に特化したような
知識とかは(守秘義務的な観点からも)載せる事が出来ないので
一般的な話に絞ってアップしてみようかな、と。

 ⇒ 正直なところ、周りの同期からみても既に遅れが見え始めている彼に対して
   勝手にこっちが「焦り」を覚えて、少々キビシ目に言っていたという事もあって
   それがプレッシャーになり、反発を招く事になってしまったようです。

 と、いつまでもボヤいてても仕方ないので、本題へ。

(※)以下、2年目君と4年目君にそれぞれしたアドバイスを特に区別せず
  混ぜこぜに挙げてます。
 
 
【彼がファシリテートしていた会議が終わった後にしたFB】
 ・議事メモは(提出を求められていなくても)取るようにしておいた方が良い。
 
 ・今回の会議の目的はそもそもどういうものだったのか?
  ⇒ 「情報共有?」「何らかの決定?」「相談・依頼?」
    参加してて何がしたかったのかが良く分からなかった。
    また、「出席者が次にどういうアクションを起こしたら良いのか?」は
    明確にしておいた方が良い。

【ソースと単体テストのレビュー後にしたFB】
 ・テストで大切な事は?
  ⇒ テストは「バグを見つけること」が目的。バグが見つけられないテストケース
    テストコードは極論すればゴミ。

  ・今回の(単体)テストの「ポイント」は?
   ⇒ 今回は設計書に書かれてることが間違いなく(=過不足無く)実装されていることを
     確認するためのテストケース(すなわち設計書と1対1)でないとダメ。
   ⇒ 例えば異常系のテストが記載されていないが、(設計書に載っている以上)
     それもやる必要がある。
     今回であれば、同じ処理を2回繰り返せば一意制約エラーが簡単に起こせるので
     異常系テストケース確認はそれでやれば良いのでは?

  ・ソースはシンプルに。
   ⇒ ソースのバージョン管理をしておけば、不要なコードをコメントアウトして残す
     みたいなことはしなくて済む。
     そういうものも含めたソースのゴミは極力減らして、シンプルに書く事。

     半年後の自分から「なんだこのコードは?」というツッコミが来ないように
     メンテナンスを意識してシンプルに書くようにした方が良い。

【質問があった時の(設計)課題に対しての考え方についてのFB】
 ・設計に関して課題が見つかった時、どう解決していくか?
  ⇒ まず、自分でその課題に対して「どうあるべきか?」を考えて、
    レビューを依頼する。もしくは有識者に確認するというのでも良い。
    いくつかの方法はあるが、要は結局「自分で考える事」が重要。

    ⇒ 今回なら、A案、B案、複数の方法があると思うが、
      どれを選択するか?についても頭を使う必要がある。
      また、その選択に関して(レビュアー等に確認する時は)
      「根拠(とか何故そのように判断したのかの理由)」を示しながら
      聞くのが良い。

【システム設計の考え方についてのFB】
 ・各処理の前提条件を押さえている?
  ⇒ 全体の流れの中で、その処理がどの位置に存在するのか?

    例えばワークテーブルのデータ削除はそのテーブルを利用する処理が
    動く直前に行うことが多いが、それはなぜか?(直後に動かさないのはなぜか?)

【レビュー後にFBした事】
 ・レビュアーは完璧ではない
  ⇒ レビューのレベルはレビュアーのレベルに依存するので、
    残念ながら100%の間違い・漏れぬけの指摘が出来るわけではない。
    (ハッキリ言ってしまえば、レビュアーのレベル以上の指摘は出来ないし、
     逆にあまりにも下らない誤字脱字等が多ければ、それらの指摘だけでレビュアー
     集中力・時間が割かれてしまって、レビュアーが指摘できる
     設計についての注意点等の指摘が半分も出来ないかもしれない)
    
    レビュアーの指摘にインスパイアされて、レビュアー
    指摘の漏れに自分で気づくことが大切。

    また、指摘点が100%正しいわけではない。
    勿論それなりの観点・根拠でレビューの指摘が上がってくるハズだが
    その指摘自体が妥当かどうかについても自分で一度考えてみる。
    妥当でない思ったら、その根拠を明示してレビュアー
    逆質問して、認識を合わせていく必要がある。

【作業の仕方についてのFB】
 ・SVNへのコミットはこまめにするべし。もしくは最低限ロックをかけて作業する事。
  (※)残念ながらこの指摘はこの後毎月のように指摘する事になったのですが。。。
  
っと、まだまだ1/3にもなってないけど、長文になりそうなんで、一旦区切りますか。
  

2014-04-26 AgileSamurai 埼玉道場に参加してました

 今年に入ってプライベートでも仕事でも色々あって
すっかりブログを書く、ということから遠ざかってしまってました。。。orz

 と、いうわけで短めですが、久々に(?)勉強会に参加したんで。
 
「第11回 アジャイルサムライ読書会 埼玉道場 - PARTAKE」
 http://bit.ly/1lrlJvQ
 
 当日はちょっと早めに出発してこれまた久々にアキバに寄ったりなんかして
USB扇風機やらを仕入れつつ、今回は赤羽ではなく王子の会場へゴウ。

 初参加の方も2人ほどいる中、3人3人のテーブルに分かれて例の如く
今回はユニットテストの章の音読と議論を開始。

 各自疑問に思う事とか議論のネタなんかを付箋に書き出しつつ、進行。
今回はワークショップは無く、章が短かった事もあり20〜30分ほどで
本は読み終わって後は議論でたっぷり2時間くらい?

 個人的に印象に残った話は、いんだれさんのAgileに対しての考え方。
WFが「系」の考え方を重視して整理・整頓して進める方向なのに対して、
Agileは「プロダクト」という枠を「TDD」「Scrum」「かんばん」等々で
埋めていくイメージである、というお話。

 ⇒ 陣取り合戦とか、塗り絵っぽいのかな、と。ご本人はまだしっくりきてはいない、
   ということを仰っていましたが面白い考え方だなーという事で
   新しい発見でした。
   
 後、みほらぶさんの「全体は部分の総和ではない」というお話。
こちらについては、個人的には大体理解できたつもりだけど、まだ腹落ちしきれて
ないかな、と。

 ⇒ 異論・反論がある、とかでは無くて、基本的に合意・同意なんだけど
   自分の中で他人に対してキッチリ説明できるロジックが構築できてないと言うか
   自分の言葉で説明できない感じかなぁ。

 と、いうわけで、今回は(引っ越して千葉になってしまったために)
懇親会はちょこっとしか参加できませんでしたが、いつものように
有意義な時間を過ごす事ができました。
どうも有り難うございました m(O)m

 あ、そういえば先日参加した新宿道場の方、まだアップしてなかったな。。。

2014-02-08

記録的な大雪!

22:11

 げ、気付いたら去年から更新してなかったのか。。。
 
 今日の東京地方は記録的な大雪で、朝から(正確には昨日の深夜から)
降り始めた雪が未だに降り続いてて、道路はもう20cm以上の積雪になってるみたい。。。

 いや、結局今日は近所の整体に行っただけで引きこもってたんで
特に何ということは無いんだけど、あまりの雪だったので書き留めておこうかな、と。

 これは1週間くらい雪残るなぁ、多分。。。

2013-09-14 「XP祭り2013 〜 XP 〜」に参加しました

 1年ぶりのXP祭り参加、ということで今年は去年途中からになってしまった
オープニング漫才(?)を始めから見ようと、ちと早めに出発、、、
したら、まだ開場準備中のタイミングで着いてしまいました(汗)
 
 ちなみに当日のまとめはこちら
 
 「『XP祭り2013 〜 XP 〜』のまとめ #xpjug」
  http://bit.ly/1eTSpuc
 
 午前中の漫才にはいつものお二人だけでなく、kawaguti さんも加わって
レッツゴー三匹状態でXPについての解説を。

 で、引き続いて kawaguti さんから
「高度12,000フィートからの Agile と Lean」のお話。
http://bit.ly/167ZPlU

 個人的には資料途中で話されていたバーンダウンチャートの
昇龍拳」と「かかと落とし」が面白かったなぁ、と(^^)

 で、例の如く(?)若干押し気味で、次の鷲崎先生にバトンタッチ。
 
 鷲崎先生からは「SEMAT」の内容についての講演がありました。
途中、チラッと呟いたんですが、AgileやらリーンやらDevOpsやらWFやら
色々ソフト開発に関する話(だけでも無いけど)がゴチャゴチャしてる
状況を整理しようとする試み自体は個人的に興味あります。

 が、確か自分の記憶ではOOの設計手法についてまとめようとして
結果的に纏まりきれずに、とりあえず記法だけでも統一するべ、
ってなって生まれたUMLの話と同じような事にならなきゃイイけどなー、と
思ったりします。

 お昼ご飯はコンビニおにぎりでチャチャっと済ませて、
(ちょこっとだけゲリラLT覗いて)昼イチのアジャイルセンター試験に参加。

 意外と参加者が少なくて(自分はすぐに満席になると思ってたのに)
結局自分入れて20人位だったかな?

 セッション中の静かな事(ワラ)
こんなに静かなセッションってのも初めてでは無かったでしょうか(^^)

 40分程度で39問、しかも半分は(センター試験だけど)記述式という
結構ハードなものでした。自分は試験やる時のクセで、問題用紙に回答を
書き込みながらそれを解答用紙に転記するという手間のかかるやり方で
取り組んだこともあり、結局3問程度空白のまま提出する事になってしまいました(残念)

 解いている最中、思わず吹き出すような問題(選択肢)とかありましたが、
こちらとしては時間的なものもあり、一杯一杯になってしまってボケる余裕も殆ど無く。。。orz

 とりあえず、何とか終了。疲れたー。
 
 で、続いて、やっとむさんの「宝探しゲーム」のワークショップに参加。
以前から幾つかのイベントで開催されているのは知ってたんですが、
どうもタイミングが合わず、今回ようやく初参戦。

 開発側とビジネス側が協力して如何に他のチームより
ユーザを獲得するか、というゲームなんですが、色々と示唆に富んだ内容でした。
(因みに4人チームで2人ずつビジネスとITの担当に分かれますが、
自分はビジネス側でゲームに臨みました)

 結果としては残念ながら4チーム中、最下位という結果でした。
ただ、戦略的には「追い込み方式」で「見せ場」は作れたと思うので
個人的には結構満足でした。

 ⇒ 負けた原因を分析すると、1.サイコロ運、2.最後のターンの
   仕掛けタイミングが1手だけ早かった、ということかなーと。
   1.のサイコロ運については、どうしようもないですが、
   2.の仕掛けタイミングはコントロールできたので、
   ビジネス担当として申し訳ないことをしちゃいました。。。
   それが上手くいってたら、多分トップ獲得も十分可能性があったかな。

 とはいうものの、何より良かったのは、ゲーム中にビジネスと開発が如何に協力・
ゴールの共有ができるかが、重要だという事が実感できるWSだった事です。

 市場の不確実性(変化)への対応や、ビジネスとITの協力、他チームの
動向を踏まえた戦略等々、こういう内容のWSを新人研修なんかでも取り入れられないか
チト検討したいですね〜。

 で、続いて、昼イチのアジャイルセンター試験の解説セッションに。
古文の先生っぽい(勝手なイメージ(ワラ))和服姿のマチ子先生、
ジャージを着た体育の(飲んだくれ?)nawotoセンセイ、
用務員のオジサンのm_pixyさんという3人が解説に。

 答案用紙の返却で中々名前を呼ばれず、「ヤバ、お前追試!というオチ?」と
若干ドキドキしてましたが、なんと結果は2位。自分でもちょっとビックリ。
平均は64.3点だったようですが、自分は何とか78点取る事が出来てました。

 ただ、個人的にはボケ切れなかった所がスゴく反省。。。解説中、
オモシロ回答を前で発表してたんですが、唯一取り上げられたのは
「旅に出る」という回答だけ。
もっと他にも色々ボケ方あったやろ、と・・・orz

 来年はキッチリとボケられるように修行を積んできます。。。

 で、最後はLT祭りにクロージングと続いて、今年の僕のXP祭りは終了となりました。
(懇親会の方、カード決済ができなかったので、参加を諦めたんですよね〜。
 まぁ、多分実行委員の人に掛け合えば現金払いとかでも良かったと思うんですが、
 余計な手間を増やすのも悪いんで、今回は素直に帰ることにしました)

 と、いうわけで1日充実した時間を過ごす事が出来ました。
スタッフの皆さん、登壇者の皆さん、並びにWSで同じチームだった皆さん
そして参加者の皆さん、どうも有り難うございました。