2013年振り返り

今年も一年、大変お世話になりました。

年末ということで、飲み会なども諸々ありましたが、そう言った場で、直接・間接的に一緒に仕事をしている人や、同じ会社・業界の様々な人と話すことができて、

改めて、素晴らしいメンバーや環境に囲まれてお仕事をさせていただいていることを感じることができました。

できたこと

さて、今年もは1月に、二つの目標を立てていました。

一つは、1月に書いた、「本番作業に強いプロダクト」を作る 内で触れていた、様々なオペレーションやテストの自動化。
そしてもう一つが、プログラマ／エンジニアとして、学びの機会を持つ、というものでした。

「強いプロダクト」は作れたのか

 前者は、改めて見返すと、（若干年末に駆け込んだものの）以下のことがチームとして達成できました。

・手持ちの各プロダクトのデプロイスクリプトができた

これまでかなり時間がかかる＆面倒だったリリース作業がだいぶマシになりました。
※実際はスクリプトを作ったあとも、プロダクトが抱えている問題のせいでなかなか自動デプロイができなかったのですが、11月にようやく解決しました！

・自動コンポーネントテストの基盤ができた

　コンポーネントテスト向けに、アプリケーション外で自動に動作するテストフレームワークを作ることができました。

　まだまだケースが少ないですが、あとはこのフレームワーク上に、各修正案件ごとのコンポーネントテストを乗せていくことで、

• コーディング前に「動作するテスト」を作成できるので、コーディングする人のゴールを明示的にできる
• マージ後や、本番デプロイ直前の最終確認なども安全・かつ高速・かつ小さな手間で行うことができる
• UTと分離したので、Jenkins上でのビルドの高速化につなげられる
• 定期的なリグレッションテストができる

といったことが可能になりました。

 

なお、こうしたツールは、私…というよりは、一緒にチームを組ませてもらっているメンバーの皆さんが主に手を動かして作ってくれていて、本当に感謝です。
いつも言いたい放題ばっかりですみませんｗ

「プログラマ／エンジニア」として学べたのか

昨年は、自分の興味がプロジェクトマネジメントとか、チームマネジメントとかに偏りすぎていたかな、という思いがありました。
そこで、もう一度、技術者としての立ち位置を探すために、こういった目標を立てていました。

まず、上記に書いたような改善は、エンジニアとしてのバックボーンがあってこそ、理解して推進できたことだと思いますし、若干、手を動かす機会が足りなかったものの、
TDDブートキャンプや、システムテスト自動化カンファレンスなどの外部勉強会や、書籍などでまずは自分が学んで、そこからチームのメンバーに協力してもらう、ということはできていたと思います。

また、言語面では、JavaDay TokyoやJavaOneへの参加をはじめ、コードの書き方の本を読んだりだとか、Javaという言語にある程度向かい合う時間を意識してとることができました。

新規で使うフレームワークの勉強などはしていましたが、言語そのものにここまでフォーカスしたのは初めてだったかもしれません。

結局、「自分の立ち位置が見つかったのか」というと怪しいのですが、現在または今後にぶち当たる問題を解決するための、「引き出し」はある程度見つけられんじゃないかと思います。

スクラム

スクラムに関しては、

私、スクラムを分かってませんでした 〜Jim Coplien氏のScrum Master 研修を受けて 1〜

に書いたとおり、この研修が非常に衝撃的でした。

この研修の後、（これまでもそうでしたが）チームのメンバーに協力してもらって、ちょっとずつ、案件の進め方を変えてもらって、より、これまで以上に、「群がる」開発にシフトしてきました。

振り返りでは、「チームワークが発揮できた」という意見がメンバーからも上がり、ある程度の効果が出せているのではないかと思っています。

できてないこと・これからやること

上記、「できたこと」に書いたことでも、できていないことはまだまだあります。

リグレッションテストはようやくフレームワークができたところで、これと「群がる」開発を組み合わせることで、仕組みとして機能しだします。
…が、一筋縄ではおそらくいかないでしょう。

リリースの自動化はまだまだ、安全性・信頼性・準備の簡単さなどの面で改善すべき点が多くあります。
ちょっとずつ、時間をとって改善する必要があります。

プログラムは、ふと気付くと、ここ数年Javaばかり（それも、ろくに書いていない）ので、久しぶりにまっさらな状態で別の言語を学んでみようかと…。
遅ればせながらScalaあたり狙ってるんですがどうなんでしょう…　Groovyも気になります。

…などなどあるんですが、この記事を書くにあたって、今年一年のブログを読み返したところ、（薄々気付いてはいたものの）改めて、まるでできていない、大変なことが2点あることに気付きました。

1. 積読本が多すぎる
2. 「続きを書きます」といった記事の続きが書かれていない

もうこれね、ひどすぎる。

積読本に関しては、手をつけない、というより、読みかけの本が多すぎるんですよね。もともと隙間時間を見つけて本を読むのが下手なので、継続して読めない人で…
ちょっと意識して、週に一度でも、ゆっくり本を読む時間と場所を見つけたいと思います。（技術書って、単に読むだけじゃなくて整理とか写経とかするので時間と場所が必要なんですよね…　みんなどうしてるんだろ）

とりあえず、未読了の本の、たな卸しします。年内、って言うか今日。

2.の、ブログが続かないのも、おおよそ1．と同じ理由なので、やはり意識して自己研鑽の時間をとりたいと思います。

今後、自由な時間が減ることはあっても、増えていくことは恐らく無いので、来年の目標の一つは、自分にあったインプット・アウトプットの方法を見つけること　としたいと思います。

ではよいお年を。

GroovyでJUnit用のテストフィクスチャを宣言する を試してみたのだけど

結論から言うと、思ってたのとは違ったかも。

こちらの後半で触れたとおり、テストフィクスチャの外部セットアップをした場合、
可読性があまりいけてないという問題を現在抱えておりまして、その解決法として、Groovyがよさそうだという事でTryしてみたいと思っていました。

で、私、ひとつ勘違いしていまして、GroovyのクラスをJavaのクラスのインナークラスとして宣言することで、1ファイル内で宣言もテスト実施もできるもんなんだと思っていたのですが、Javaのクラス内にGroovyのクラスは宣言できないのですね。（この点間違っていたら、どなたか突っ込んでください）

となると、結局JsonファイルかGroovyクラスかの違いで、別のファイルに定義するのには変わりないと。

一応クラスなので、Eclipseの補完機能が諸々使えるアツいのです（リンクをたどってクラスまで飛べたり、リネームがちゃんと効くのは確認）が、
プロダクト自体がJsonで入出力するAPIのため、Jsonファイルでテストフィクスチャを定義しておいたほうが、何かと便利なのでした。

どっちかっていうと、Reflectionを使わずにPrivateフィールドにアクセスする、とかの方が利用用途が高いかも。

なお、実施に当たってはこちらを参考　というか、ほぼそのままパクらせていただきました。ありがとうございました。

リモートで消したブランチをローカルから見えないようにするには

備忘録として残しておきます。

git remote prune origin

http://qiita.com/nantekkotai/items/0ca7c9e850eff65aaf66
より。

システムテスト自動化カンファレンスに参加してきました #stac2013

システムテスト自動化カンファレンスに参加してきました。

テストの自動化は昨年から私の大きなテーマの一つになっています。今の自分のチームではユニットテストについては随分整ってきた（まだまだやりたいことはありますが）ので、
次はインテグレーションテスト（コンポーネントテスト）、そしてシステムテストだなーと思っていたところでタイムリーにこのカンファレンスがあり、参加してきました。

午後はTRIDENTの伊藤さんによるSelenium Web Driverのハンズオンセッションに参加しました。

はじめに、テキストフォームへのテキストの入力方法や、ラジオボタン、チェックボックスなどのフォームの基本的な操作法、更にそれらからの値の取得方法とアサーションの方法を教わりました。
後半では、ページオブジェクトデザインパターンによる、保守性の高いテストの書き方を体験しました。

ページの論理的な意味をクラスとして定義するため、HTMLとのコンバート層が入ることに違和感を感じたほか、1ページあたり1クラス作っていくのが面倒そうに感じ、腹落ちしないところはあったのですが、こういった、UIレベルのテストのあり方について考える切っ掛けができたことは良かったと思います。

講師の伊藤さんにも色々と質問させていただくことができ、良いカンファレンスとなりました。

私、スクラムを分かってませんでした 〜Jim Coplien氏のScrum Master 研修を受けて 1〜

社内で、Jim Coplien氏による、2日間のスクラムマスターの研修を受けさせてもらう機会をいただきました。先週のJavaOneに続いて、会社からすごいお金と時間を出してもらってるなぁ…自分。

なかなかショッキングな内容も多く、整理するのに時間がかかりましたが、まとめと、今後のアクションを書いていきたいと思います。

 

用語：PBIとSBI

初めに今回覚えた用語を二つ。PBIはProduct Backlog Item, SBIはSprint Backlog Itemの略です。

概念的にはすでに馴染みのあるものですが、PBI、SBIという呼称は今回始めて知りました。

 

私は「スクラム」を理解していなかった

さて、本題です。研修の一番冒頭で、Jimから、スクラムのたった一つの約束が紹介されました。

"It promises only that the team will work on the most important things first"「約束は一つだけ。チームが最も重要な作業から手をつけること」

そんなの知ってるよ！ とこの時は思っていたのですが、やがて、この言葉の意味をまるで理解していなかったことに気づきました。

 

チームは「群がる」

仮にスプリントチームのメンバー数が4人で、あるスプリントでPBI#1〜PBI#3の3つのPBIがあり、それぞれ、複数のSBIに分割されているとします。このとき、スプリント内でどのような順番で進めて行くのが良いのでしょうか。答えは

 

全員でPBI#1をやる

 

です。

PBI#1にみんなで「群がる」んです。

これを聞いた時に、これまでスクラムで何と無く腑に落ちなかった点が一気にクリアになってきました。

 

なぜ「スクラム」というのか。

なぜ個人のベロシティには意味がなく「チームのベロシティ」が大事なのか。

なぜ時間では見積もらずに「ストーリーポイントで見積もる」のか。

なぜ誰かがタスクをアサインするのではなく、「Pull型」でおこなうのか。

なぜ「特定のロールはない」のか。

なぜ「小さな単位でリリース」が可能なのか。

 

それは、チーム全員が、一つ一つのPBIに対してスクラムを組み、開発・テストが終わった、リリース可能な状態の小さなプロダクトを順に作っていくからなんですね。

 

なお、PBIのサイズによっては、「PBI#1は4人でやるには小さすぎるから、PBI#1は1人でやって、PBI#2を3人で」ということはあるそうです。

 

だから受け入れテストの自動化が重要なんだ

これは、Copeの研修では言及されていなかったのですが、上記のことを踏まえて、受け入れテストの自動化（または 結合テストの自動化。自分の中では同じ意味で使ってます）が重要であると感じました。

 

マニュアルのテストは、コーディング終了後にしか行えません。ですので、プログラマが実装を終えた後、時間差でテストが始まり、テスト中、プログラマはまた別のPBIの実装（もしくは別のPBIのテスト）へ移ることになります。

ここでもしバグが出ると、すでに他のPBIに移ってるプログラマが戻ってきて直す（か、他の人が直す）まで、テストが進められないのでそのPBI自体が止まってしまうんですね。

 

ですが、もし自動テストだったらどうでしょうか。あるPBIの、実装の開始と同時にテストの作成を始めることができ、実装終了後、即座にテストを実施することができます。そこでバグがあれば、そのまま実装していたプログラマが修正に入ることができるわけです。一方のテスター（ここではテストを書いた人）は、すでにテストを書き終わってますから、修正を手伝うなり、次のPBIにかかるなりすることが可能です。

実際には、そこまでタイミング良く実装とテストが同時に終わることはなかなかないかもしれませんが、マニュアルテストに比べて、かなり効率良く進められることができ、一つ一つのPBIに「群がった」開発ができるようになるのだと思います。

 

そして、修正のテストが完了し、CIも完了したら、自動でみんなが見られる環境へ（もちろん自動で）デプロイ。
これで、QAや、POへのデモ用の環境が整います。

 

※続きます

JUnit実践入門 読書レポート Part1 & 第7章

ほぼ発売と同時に買ったにもかかわらず、ずっと積読本になっていた「JUnit実践入門」をようやく読んでいます。

ここ最近で、バグによるリリーストラブルがあったり、単体レベルのバグがQAでボロボロ出てきたりということがあったため、改めてテストコードの品質（テストとしての品質はもちろん、可読性やメンテナンス性も含めて）について考えていたのですが…

 

もやもやしてたこと、ほとんど書いてあるじゃん！

 

ぐぅ、もっと早く読んでいればよかった。

 

レポートの前に、現状の問題

自分の書いたものも含めてなのですが、いまの身の回りにあるテストコードの多くにおいて、可読性が低く、何をしているテストコードなのかわかりにくい という問題が見られます。

（そうでないものも多くあります）

自分なりに原因分析をすると、以下のような原因が見られます。

• テストメソッド名に意味がなく、コメントも無いので、何をするテストなのかよくわからない（最近は結構改善されてきた）
• テストメソッドが長く、どれが前処理で、どれが実行で、どれが検証なのか、一目でわかりにくいものがある
• プロダクトの特性上、メソッドの入力値や期待値が巨大なオブジェクトとなることが多く、別のファイルで定義されたjsonやXMLを読み込んでオブジェクトを用意している。しかしそのため…
• テストの内容を把握する際に2ファイル開く必要があり、レビューの時に面倒
• 同じようなJsonファイルが散乱し、スキーマ変更時などに、大量のJsonを直すハメになる
• ファイルのIOが多く発生するので（特にローカルで動かす時に）速度のボトルネックになってる模様
• テストメソッドが長く、どれが前処理で、どれが実行で、どれが検証なのか、一目でわかりにくいものがある
• カバレッジはとっているが、入力値、期待値の網羅性がわかりにくい

 

で、改善したいんだけどどうするがいいのかなぁ と思っていたところ、「JUnit実践入門」のPart1（第1章〜第3章）と第7章を読んだ時点でかなりの収穫がありましたので、そちらを中心にレポートを書かせていただきます。

 

Setup（前処理）、Execute（実行）、Verify（検証）、TearDown（後処理）を明確にする

第2章の冒頭に、以下のようなことが書かれています。

ソフトウェア開発によるテストの定義は「【ある条件下】において【ソフトウェアの振る舞いを記録】し、その記録が【期待される結果となっていることを検証】するプロセス」。

なので、JUnitによる自動ユニットテストも、この3点、

1. 「ある条件」の定義
2. テスト対象のプログラムを動かして「振る舞いを記録」
3. 振る舞いと期待値を比較して「検証」
4. （必要なら）後処理。

からなっています。

これがテストコード上できれいに表現できていないと、可読性の低いテストコードになってしまう可能性があります。

わかりやすい方法として、第3章でやっているように、Setup, Execute, Verify というコマンドを各テストメソッドに書く方法があるそうです。これはいっそテストコードのコーディングルールにしてしまうのもありだと思いました。

 

適切な方法でテストフィクスチャをセットアップする

そもそもテストメソッドの行数が多くなければ、前述のようにコメントを入れたりする必要もないのですが、中には10行を超えるようなテストメソッドもあります。

条件の定義、実行、検証しかしていないのになぜこんなに長くなるかというと、メソッドの入力値や期待値に使われるオブジェクトを作るのに手間がかかっているのです。

 

この問題に対するまさに「回答」が「第7章 テストフィクスチャ」に書かれています。

テストフィクスチャ（Test Fixtures）とは、入力するデータ、テスト実行のための予備操作、データベースなどの外部リソース、検証に必要なデータなど、テストに必要なデータやオブジェクトの状態のことを言うそうです。

ユニットテストの事前準備フェーズでは、これらのフィクスチャをセットする必要がありますが、これがなかなか大変で、テストコードが長くなってしまう傾向にあるようです。

第7章では、用意するテストフィクスチャの複雑さや出現の仕方によって、複数のセットアップ方法を紹介しています。

 

インラインセットアップ

テストメソッド内でSetterなどを使ってオブジェクトを用意する方法です。セットアップの量が少ないのであれば、テストメソッドの可読性が良くなるメリットがあります。（上から順に読めばいいので）

一方、前述したとおり、この行数が増えると、準備・実行・検証の区別がつきにくくなり、一気に読みにくくなります。

 

暗黙的セットアップ

Beforeアノテーションを使ってセットアップを共通化する方法です。

この方法によりテストメソッドはテストの実行と検証が中心となるため、何をテストしようとしているのか明確になります。

（本には書かれていませんが、修正が必要になった時の修正が1回で済むようになるのも大きいと思います）

欠点は、テストクラス内の各テストケース固有の事前処理は記述できないことです。

 

生成メソッドでのセットアップ

複数のテストクラスで共通に使われる事前処理を、独立したメソッドにまとめる手法です。

暗黙的セットアップに比べて、使いたい箇所で使えるメリットがあります。

複数のクラスで使えるよう、独立したクラスで、public staticで作るのがいいそうです。

 

外部リソースからのセットアップ

生成メソッドの利用はテストメソッドの可読性は上がるのですが、結局生成メソッド自身は読みにくいコードのままになることが多いです。これはsetterやputでインスタンスに値をセットするJavaでは越えられない壁… ということで、コードでセットするのを諦めて外のファイルにデータ定義してしまったのがこの方法です。

XML, Json, YAML, CSV などでデータを記述したファイルを別で用意し、それを読み込むことでセットアップする方法です。筆者のオススメはYAMLとのこと。シンプルながらxmlと同等の記述力があるとのことです。フィクスチャがリスト構造で、かつデータが多いならcsvがオススメとのこと。

 

この方法のメリットは、データがJavaでゴリゴリ書くのに比べて読みやすいこと。一方デメリットは、テストデータが、Javaでないファイルに置かれるため、テストコードを追いずらくなることです。

 

前述の通り、今、私の周辺ではこの「外部リソースからのセットアップ」をメインで使っていまして、まさにこのデメリットに悩んでいるところです。

外に記述されたデータそのものは読みやすいのですが、IDEでそのファイルを開くのがほんの少し面倒なんですね。

 

で、本文では、最後に、Javaのプログラム内で、setterなどを使わずにオブジェクトを定義する方法を二つ紹介しています。その中でぜひ試して見たいと思ったのがGroovyを使った方法。

 

static Book createBookObject(){

  new Book(

    title: "Refactoring",

    price: 4500,

    author: new Auhor (

      firstName:"Martin",

      lastName:"Fowler",

    ),

  )

}

 

こんな風に、まるでJsonのように記述できるそうで、これはぜひ試してみたいと思いました。

 

 

【送料無料】JUnit実践入門 [ 渡辺修司 ] 価格：3,465円（税込、送料込）

JavaOne2013 総括 : JavaOne2013 レポート6 #j1jp

まだ何件かセッションのレポートを上げる予定ですが、先に全体の総括を書かせていただきます。各セッションレポートはこちらから。

なぜ今回JavaOneに参加したか

今年の自分のテーマの一つが「技術力」。
昨年はどちらかと言うと、アジャイルやスクラムがおもしろく、かつ広げていくのが自分のテーマでしたので、マネジメントやチームビルディングなどのトピックスに興味がありました。
しかしその中で改めて、「自分はエンジニアである。コンピュータ技術者として改めてプログラミングと向き合いたい」という想いに気づきました。そこで、今年のOSC（OverSeas Conference。エンジニアを海外のカンファレンスに年一回行かせてくれる、弊社の大変すばらしいプログラム）は、JavaOneに行ってみたいと思うようになりました。

もう一つ後押しになったのが、以前にどこかのブログか何かで、新人エンジニア向けのメッセージとして「自分が使っているプログラム言語のカンファレンスに出てみよう」という記事を読んでいたことです。今年で職業エンジニア6年目になり、Javaとの付き合いも5年近くになる一方で、Java系のイベントへの参加経験は一度もなし。
一度Javaの最大のカンファレンスに出てみたいと考え、参加させていただくことにしました。

セッションを選ぶ段階での気付き

セッションがたくさんあるとは聞いていたのですが、いざSchedule Builderが公開されると、本当に本当に多くのセッションの中から選ぶことに驚きました。

単に数が多いだけでなく、「Java」という技術は非常に周辺技術が多く、
プロダクトの種類だけでもJavaSE／JavaEE／JavaFX／JavaME…、それらに含まれるフレームワークであるJAX-RSやJPAなどなどがあります。セッションがフォーカスしている内容も多岐にわたり、新機能の紹介や、現行の機能のパフォーマンスチューニング、さらには少しJavaから離れてクラウド、PaaS／IaaSの話やREST、コミュニティ、などなどなど。ほんとうに様々なセッションがありました。

それらを眺めながら聞くセッションを選んでいった結果、ある程度自分の中で興味の方向性があることに気づきました。具体的には、今の仕事とリンクしている、RESTやクラウド、運用関連のセッションが中心になりました。結局言語仕様から少し離れたところに興味があったようです。
あとは申し訳程度にJava8のラムダ式絡み。（←これが申し訳程度でなく、非常に良かったことに後に気づく）

これまで、「Java」という広大な技術に対して、漠然としたイメージしかなかったのですが、このスケジュール作成を通して、自分の興味の方向性がある程度見えたことは（来年には変わっているでしょうが）、今回の収穫の1つ目です。

何を得たか　何を知ったか　何に気づいたか

実際にJavaOneに参加して得た、もっとも大きなことは、私はアプリケーション開発の際に、様々な構成要素を検討できるチャンスをたくさん持っているということに気付けたことです。
さらに、そういった時に検討できるよう、日々の「素振り」が大切である、ということにも改めて気付きました。

具体例1　アプリケーションサーバの選定

「CON4117:The Adventurous Developer's Guide to Application Servers」はこの点において大きな気づきをくれたセッションの一つです。

記事中にも書いていますが、正直これまで、アプリケーションサーバについては「とりあえずtomcat使っておけばいいんでしょ」というスタンスでした。
しかし、アプリケーションサーバには様々な種類があり、ここ最近でも新しいものがどんどん出ていること、それらにはそれぞれ特徴があることを知ることができ、常に、「本当にtomcatでいいのか？」の考慮は必要であると思い知らされました。

この発想に至ったのは、カンファレンス期間中に、少し時間をとってGrassfishを試してみたのも大きかったと思います。

具体例２　Java８導入について考える

言語にもっと近いところでは、Java８の導入について考えられたことが大きかったです。ラムダ式については５月に参加したJavaDayTokyoでも聞いていましたので、「大体わかってるし、現場で使えるようになるのは１年以上先だし、まだ深くは知らなくていいや」と実は思っていました。
しかし、キーノートや、「Programing with Lambda Expressions in Java」などのセッションを通じ、改めてこの変化が非常にJavaにとって大きなものであること、コードの可読性が非常に向上するため是非導入すべきであること、そして、いざ導入となった時にその素晴らしさを理解し、メンバー全員で使い始めるには、ある程度の事前知識を、自分はもちろん、メンバー皆が持っていることで、導入のハードルを下げることができるだろうということに気づきました。

この気付きは自分の中では大きかったです。

「海外」に意味はあるのか

はたしてこういった気付きは、わざわざ海外のカンファレンスに行かなければ得られないのでしょうか。
今回の参加には、往復飛行機代と宿泊費、さらにクソ高い参加費で、私の一ヶ月分の給料くらいのお金を会社から出してもらっています。一方、上に書いた、私の「気付き」は国内で雑誌でも読んでいればわかるのではないか、というものにも思えます。

それでもあえて、海外の、JavaOneに、参加しなければ得られなかったと思うことがいくつかあります。

自分の英語力のなさに対する気付き、勉強へのモチベーション

事前知識があまりないセッションを聞いたこともおおきかったですが。

クソ多いセッション数から選ぶ中での、自分の興味の気付き

これは上に書いたとおり。

「素振り」に専念できる時間の捻出。合宿。

今回のカンファレンス期間中、実は、セッションを聞いていた時間よりも、電源スペースに居座って、セッションで聴いた内容を調べたり、手を動かして検証してみたり、ブログにまとめてみたりという「復習」に割いた時間のほうが多かったです。
また、こういったことに時間がとれるよう、セッションは実はスカスカにして、空き時間をかなり多くとっていました。

これこそ一見、海外に行かなくても、わざわざカンファレンスに出なくても、できそうなことですし、事実普段から意識的に時間を作られて、こういった情報収集と検証に時間を割かれている方はいらっしゃると思いますし、そうあるべきだと思います。

ですが現実問題、日々の業務の中で、もしくは自由時間の中でまとまった時間を確保するのは難しいですし、国内カンファレンスの場合、時差がないのもあって結局会社のほうが気になってしまったりということもあると思います。

その点、海外のカンファレンスですと、日程が長く、またリアルタイムに日本の人とやりとりする機会が少ないことから、こうした「素振り」に割く時間を取りやすいと感じました。

言ってみれば、スポーツの合宿みたいだな、と感じました。普段の生活から離れて、その専門のことのみに専念する。

非常に高い金を出してもらっての合宿なのですが、日本を離れたことの大きな一つの意味はそこにあるのではないかと思いました。

今回は上記のような気付き、考えを頂きました。本当に非常にいい機会になったと思います。

なお、セッションの聴き方などは前回参加させていただいた海外カンファレンスと同じ方法＋上記のとおり、素振りに時間を割くという態度で参加させていただきました。