ソフトウェア構築自動化技術トレーニング〜Continuous Delivery〜に行って来ました！その１

07/21にAgile Conference Tokyo 2011の連動企画「ソフトウェア構築自動化技術トレーニング〜Continuous Delivery〜」に行ってきました。参加費75,000円の高額なイベントですが、あの"Martin Fowler"（マーチン・ファウラー）氏と、「Continuous Delivery」の著者である"Jez Humble"（ジェズ・ハンブル）氏によるトレーニングとあっては行かないわけにはいきません！

【参考URL】
ソフトウェア構築自動化技術トレーニング〜Continuous Delivery〜　・・・　開催概要

両氏に会えたこと、最前列中央に陣取ったおかけで目と鼻の先で両氏の生の講演を聞けたこと、トレーニング終了後に[twitter:@haradakiro]さんのおかげで両氏と立ち話に立ち会えたことは良い体験ができました！

主催者には貴重な機会を作っていただき感謝していますが、内容はだいぶ物足りなかったと言うのが本音です。

まず、トレーニングと銘打っていますが、ほぼ一方的にお二人の話を通訳を交えて聞かされるだけだったこと。上記開催概要に掲載されていた、“原則や実践方法の習得”や“習得知識に記載されている内容”、“Puppetの使用を含んだアジャイル開発基準”、“何故分岐（branching）がCDにとって有害”など、これらについては残念ながらとても“習得”できるような内容ではありませんでした。

本コースでは以下のようなアジェンダが事前に準備されていたようです。

introduction（イントロダクション）
the deployment pipeline（配備パイプライン）
automated testing（自動化テスト）
continuous integration（継続的統合）
techniques for continuous development（継続的開発のためのテクニック）
component-based architecutures（コンポーネントベースのアーキテクチャ）
going live（立ち上げ）
data management and migration（データの管理と移行）
managing environments and infrastructure（環境とインフラの管理）
managing continuos delivery（継続的デリバリー管理）

ところが、通訳しながらのためもあり実際に“話が聞けた”のは、上記のうち導入を除いて3.5個でした。逐次通訳の方はお二人いらっしゃいましたが、難しい話題（技術的という意味で）にも関わらず非常に丁寧かつ分かり易く訳していらっしゃいました。ありがとうございました！
ただし、コースとして通訳が必要だったかは疑問が残ります。私は英語はほとんどしゃべれませんし、聞く方も早口ではまったく対応できませんが、それでもニュアンス、抑揚、文節の区切りと言ったものが、講演者も通訳されることを意識しながらだっため、スムーズさにかけ、時間のロスが大きかった気がします。参加者は高いお金を払ってくる方々なので、通訳なし or イヤホン配布で同時通訳が良かったのかなぁ？と感じました。

さて、文句ばかり言っていても始まりませんので、聞いてこれたことをまとめたいと思いますが、このエントリ自体があまりにもネガティブなので、別エントリーで「社内フィードバック用」に作成する予定の、プレゼン資料をアップしたいと思います。ただし、このエントリ自体が文句で終わりも嫌なので、各アジェンダの最後に行われた質疑応答の中から印象に残ったものをピックアップして紹介したいと思います。

【問い】deployment pipelineについて、全体のどの程度、何パーセントくらいが自動化されていれば良いのか？
【答え】“・・・・・”（困った顔で沈黙）。何パーセントなんてない。コードカバレッジのカバレッジ率が何の意味も持たないのと同じ。あえていい指標を提示するとしたら、あらゆるテストを通って「デプロイボタン」をユーザーなりあなたなりが押すと、すべてがリリースされるとした時、あなたの腕に注射器をさして血液を抜いて検査し、アドレナリンが増えていなければ良い。

【問い】mavenを使っているのですが、（ここまで通訳されて割って入られる）
【答え】mavenのsnapshotはevilだ。mavenは確かに優れたツールかも知れないが、それでもおすすめしたくない。

【問い】フレームワークを使うべきではないと言っていたが、実際にそれを開発している。
【答え】フレームワークをどうしても作りたいのであれば、フレームワークを使わない2つのアプリケーションを作ってみる。その2つに全く共通の部分が現れたら、それをフレームワークにすればよい。優れたフレームワークはアプリケーションから抽出されるべきである。これを“harvested framework”（刈り取られたフレームワーク）と言う。良いフレームワークも世の中にはたくさんある、RoRやSpringなどだ。

前述の資料は2週間以内にアップしたいと思います。興味をお持ちいただけた方は乞うご期待。いや、あまり期待しないでください。