11月17日に開催された、札幌Javaカンファレンス2012に参加しました。
今回は半スタッフとして参加（当日にセッションの動画を撮影する係をしました。）。
動画撮影係ということで、一番前の良い席でセッションを楽しむことができました。
私が見たのは次の5つのセッションです。（ルームC担当）
動画のボタンの押し忘れ、保存忘れに注意を払っていた結果、あまりメモが取れていないので箇条書きで思ったことを書いておきます。
Lambda への道（櫻庭祐一/@skrb さん）
- Java8ではいろんなことがかなり大きく変わるなあ
- 2008にクロージャー中止したけれど、2009にラムダの開発復活。
- キーワード：マルチコア、並列、非同期
- わかりやすい説明でLamdaへの苦手意識が薄れた
- LamdaExpressionでかなりいろいろ省略できる
- Default Method、インターフェースにメソッド….!
- Collectionクラスはかなり便利になりそう
- Stream (filter sorted map reduce)
作って学ぶデータベース（きしだなおき/@kis さん）
- 1つ1つのデータを確実に扱う、スモールデータの時代
- ひよこかわいい、ひよこ成長してる!!
- 手書きプレゼン、ライブ修正すごい
- SQLでFROM句があとにくるのはたしかに直感的ではない、「どこから取るか」を先に書くの良い
- 使っていないように見えて、DBの内部ではユニオンをたくさん使っている
- 「こう見えて、テンパってるんでｗ」← そうは見えなかったｗ
- やってみたら、わからなかった事の理解が進んだ（実装は楽）
- NOSQLの場合は基本的にRDBMSがやってくれていることを自分でやらなくてはいけないのでRDBMSの実装イメージや最適化の考えについては重要になる
顧客とPMとPGの話は、なぜ噛み合わないのか（鈴木雄介/@yusuke_arclamp さん）
- 利用時の品質、外部品質、内部品質、プロセス品質 => それぞれ依存しあうし影響を与え合う
- 各品質のバランスを取ることが大事、組み合わせが良くないというのは致命的
- どうやったら良い依存/影響関係を作れるのか
- 若い子は技術を妄信するので正しい。大人になるとややこしい事を色々勉強しないといけなくなる。
- 「PMBOKは計画と実行の差を把握するための知識群」にすぎない
- 「計画と実行の差」から「課題を予知/予測」し、「調整」を行う事で、プロジェクトを正しい状態に導く事が必要。=> !!!!!! PMの本質 !!!!!!
- アーキテクチャとマネジメントの2つがとても大事
- プロセス品質にだけコミットしているのはプロジェクトマネジメントではない（それ「だけ」ならただのスケジュール管理）
- 内部品質しか見ないのはアーキテクチャではない（それ「だけ」ならただの技術リーダー）
- PMとアーキテクトはどちらも品質の関係を重視している。
- PMとアーキテクトの結節点は「WBS」
- 不満をtwitterに書いてもプロジェクトはうまく回らない
- 覚悟しないと成功しない
- マネージメントとリーダーシップ ： これらは違うもの !!!
- いい諦め方をすること大事
- 内圧と外圧のバランスを取り、張りを継続させる
- ソフトウェア開発をするという事は常に選択するという事、選択する事は簡単ではない
- 理由を説明する「責任」と、結果を受け入れる「覚悟」が必要
コロケーションアジャイルの実践（松館渉/@matsudate さん）
- ソフトウェア開発はロケーションを選ばない
- 良いものは良い環境と良い人材で作られる
- 良い人材は良い待遇でしかるべき
- 信頼、安心を前提としてチーム構成
- http://martinfowler.com/articles/agileOffshore.html
- http://www.informit.com/articles/article.aspx?p=25929
- 物理的な距離を縮める => コミュニケーションギャップを埋める
- 目に見えないというのはとても危ない事。目に見えないと穏やかな関係が築けない。
- 信じて託す
- 結束力というのは同じ文化や小さいチームの方が結束しやすい
- 工程ではなく機能でチームを分担しよう、プロセスで割らない
- あくまでも対等なチーム、ロケーションが違うだけ => !!! これが最も重要ではないだろうか !!!
- プロジェクトの概要説明は動画に取っておく(なるほど！）
- アジャイルに取っての大きな障害は距離、時間差、距離は努力で簡単に埋められる
テストコードのリファクタリング（渡辺修司/@shuji_w6e さん）
- 継続的インテグレーションは強みではなくなった
- 確かにJavaの方がテストは書きやすい 個人的な技術のせいもあるのか => だいぶ克服してきた
- バージョン管理をやっていない現場からは逃げろ
- ユニットテスト(開発者テスト)は品質のためではない、直接の品質は上がらない、不安を解決するための手段として
- ビジネス面のテストが必要
- 技術的負債を減らしやすくなる
- !!!! ユニットテストは開発の基盤 !!!!
- デモ：Eclipseの各種ショートカットがためになる
ほんとうにバラエティ豊かで充実の、内容の濃い一日でした。
特に、自分にとっては、鈴木さんと松館さんのセッションで、心に来るキーワードが多かったです。
（なので、箇条書きもどんどん増える・・・）
鈴木さんのセッションでは、PMについての考え方やプロジェクトへの立ち向かい方（「覚悟」）を再度考えなおすきっかけとなりました。
松館さんのセッションで出てきた「ロケーションが違うだけの対等なチーム関係」というキーワードがずっと頭に残っています。
今回のカンファレンスは2トラック構成だったので、もう片方のトラック（Java色濃い目のお話）は聞けなかったのです。
動画があるのでもう1トラックの話も聞きたいです。
じゃんけん大会では本を頂いてしまった 🙂
懇親会はお寿司などなど盛りだくさん。
2次会でもたくさん濃い話を聞けて、とても楽しい一日でした。
お越しくださった講師の皆様、主催の@shuji_w6eさん、ありがとうございました。