Agile Samurai Base Campに参加してみた
2013/12/08(日)@渋谷マークシティ、AgileSamuraiBaseCampなるものに参加してみました。
早割で￥1,000-というものもあり、相当軽い気持ちで行ってみたのですが、想像した以上に面白かったというか、インパク知MAXというか、とにかく記憶が薄れないうちにBlogを初めて見ることにしました。（といっても気づいたら１週間経ってしまいましたが・・・）
自ら何かを発信するブログを書いたことがないので、以下、１００％主観と１２０％以上の駄文でありますが、不備があってもご容赦頂けるとありがたき幸せm(__)m
※UPが遅れたことも含めて・・・
～～～～～～～～～～～～～～～～～
■当記事のアジェンダ
（１）自分の立ち位置
（２）このイベントへの期待とMy目標
（３）このイベントでの収穫
（４）まとめ
（５）補足・・・関連リンク集とか
～～～～～～～～～～～～～～～～～
（１）自分の立ち位置
・SIerで勤務10数年（最近はPM、PLあたりが多く、コードと触れ合う感覚が鈍め）
・仕事では受注したシステム開発（エンタープライズ系）をいつもウォーターフォール型で、「アジャイル」とはまだまだ縁が薄いかも
・世の中におけるITビジネスの将来と、ソフトウェアエンジニアリングの、両方と向き合うのが趣味
・アジャイルサムライは１年ほど前に読んで、体のどこかで化学反応を感じ、
つい最近社内の数人の仲間と「我流読書会」を試してみた
・ということで「アジャイル」的な何かを少しでもモノにして、現状をより良くし続けていきたい、というのが平時のMIND（今回の参加は直接的にはこの理由がメイン）
（２）このイベントへの期待とMy目標
・アジャイルサムライの本の中の正解が夢物語ではなく、現実にそういう世界があることをこの目と肌で確認したいぞ
・「アジャイル」って何者？ということも含めて、その中身を具体的に感じて、自分の行動のヒントを得るぞ
・アジャイル開発に身を置く人がどんなことを考えているのか、本の中身と何が「同じ」で何が「違う」のかを体感するぞ
・実際にやっているエンジニアの方が楽しそうかどうか（楽しそうな場合それは何故なのか）を聞いてみるぞ
・TDD（テスト駆動開発）～テスト自動化～CI（継続的インテグレーション）あたりの生事例を見せり話を聞いて、今の自分たちに取り入れられそうなことがないかどうかを探してみるぞ
・Ｎ年ぶりに会う先輩に話しかけてみるぞ
（３）このイベントでの収穫
・これが「アジャイル開発」なんてものは無い。今のプロジェクトや環境を如何にアジャイルにしていくか、だ。という言葉を聞けたこと。「アジャイル」ってのはこうなんだ！という理屈や形に捕らわれるよりも、変えていく行動の重要性を感じた。すいません、かなり意訳です。
※基調講演より（角谷さん）
・自分も最近よく引用させていただく、アジャイルのライトウィングとレフトウィングの話（平鍋氏blog）。私自身もレフトウィングであるヒューマン系から入ったのですが、最近はそれを支える技術的なライトウィングをもっともっと勉強したいとおもっていて、このイベントの二択では「インセプションデッキ」ではなく「TDD」を選択。今回のTDD（ユニットテストとリファクタリングも含む）は、アジャイルサムライの中で「問答無用で実践すべき」とされている３／４を勉強できた！私自身エンジニアのハシクレであるものの、この辺の技術がまだまだ弱いのは今後の課題でもあり、今日はちょっぴり前進（した気になれた）。
・ソフトウェア工学的寄りでは「良い設計が良い実装を生む」という考え方があるが、対してTDDはテストコードを書いてから実装しリファクタリングを繰り返す「ボトムアップ的に良いコードに仕上げる」という、極めておおきなパラダイムシフトがあるという話。少しづつでもコードをより良くしていく「やり方」としてのTDDの持つチカラが、エンジニア自身やソフトウェアの「健康」につながるというイメージと理屈を納得。
※和田さんの講演より
・「リファクタリングをやらせてくれ」と言ったら負けだ、とのこと。なるほど確かに。これは良いことを聞いた。確かに「はいどうぞ」という人はいないでしょう。その時に想定する回答としては「ちゃんと動いてるんならおＫ」もしくは「負債を溜めるなってあれほど（ry」みたいな感じかなぁー
※和田さんの講演より
・Javaのライブコーディング（ペアプロ）を通じて、実際にTDDをやるとどんな感じなのかを初めて見れた。考え方や理屈だけではなくて、実際にはどうなの？というのがとても分かり易かった。現場感がちょー伝わってきてとっても良かった！「カートゼロ件で注文出来てしまう」という想定ケースがおもしろすぎ＆分かりやすすぎ。障害報告を受けて再現するかどうか確認して、欠陥かどうかを調査するのは、どこも一緒ですよね。ここで「テストコード」。なるほど！
※TDDライブコーディングより
・テスト駆動開発。なるほど確かに、コーディングレベルでこのTDD（テストコードを書いてからコーディングで、赤→青→リファクタリングのサイクル）が動くソフトウェアを作るという開発を駆動していることを理解。ここでの生まれた疑問。TDDは内部設計や結合テスト、もしくは要求開発～システムテスト全体の開発ライフサイクルを含めて、どのように駆動していくのだろうか、という点。上手く質問できなかったのですが、懇切丁寧に答えてくださった皆さま、感謝です。「仕様のテスト」と「実装のテスト」を分けて考えるという大切なことを学びました。
※TDD初心者向けアンカンファレンスより
・「仕様のテスト」と「実装のテスト」を区分けした上での、更なる私の疑問には、有野さんがガチンコで受け止めてくださり、ホワイトボードを使って沢山教えてくださりました！
TDDによる「実装のテスト」と、Cucumber＋Jenkins＋gitの「仕様のテスト」の具体的な形を聞き、両方の住み分けと繋がり、更にはCucumberのことは知らなかったので、帰ってググってみたり、と。
※左下のところにTDDの黄金の三角形（実装のテスト）
・過去プロジェクトでJunitを使いこなせなかった経験を基に、当時は何が問題だったか / どうすればよかったのか、という自分の中で長年解決できなかった「問い」の答えが見えてきた気がする。複数の方が同じことを言っていたので間違えないだろう。具体的には、繰り返しになるが「仕様のテスト」と「実装のテスト」を分けて考える、という話。ここを完全にごっちゃにしてしまったのが大きな原因だったという大きな発見。UNITテストは後者。過去プロジェクトでのJunit利用では、前者も一緒にやろうとしていたことが上手くいかなかった大きな原因の一つという学び。
※終盤、沢山の有識者・実践者の皆さまに囲まれて
・テストコードを書いてから実装する（新規コード作成も既存コード修正も）ことが、どのようなプロダクトコードに繋がるか、という点。クラス分割・メソッド分割をどうすべきか、の共通指針がTDDの中にある。たぶんこれはテストファーストでないと難しい・・・
・テストコードってプロダクションコード（いわゆる本番で動く製品のコード）の何倍ぐらいになるものなのか、という疑問について。もちろんケースバイケースで数倍から時には１０倍以上になることもあるらしい。ただTDDを通じてプロダクションコードは勿論のこと、テストコードもリファクタリングされて、目指すは２倍程度とかとも。
（４）まとめ
「アジャイル」 のことを知れば知るほど、「アジャイル」という（美味しそうな）言葉に騙されないようにしなくては、と感じている。
騙されるということ言葉が悪いが、表面的な「ドキュメント作らなくてよい」とか「少人数で１か所じゃないと実現できない」とかいう誤解を少しでもなくしていき、もっともっと具体的な良いところを今の仕事に取り入れていけるようにしたいな、と。
特に今日のTDDには、アジャイル云々ではなく、より良いソフトウェアを作りたいというエンジニアにとって、大事な技術が詰まっているとおもうし、実際にTDDを実施しているかたの言葉からもそのことを強く感じたので、周りに伝えていきたい。数は少ないが社内でも「アジャイルサムライ」に共感した仲間がいるので、その人たちとともに、少しづつサムライ候補に近づいていけたらな、と、イベントからちょうど１週間たった今夜も思っています。（ちょうど明後日社内で集まりがあるし！）
私の拙い質問にお付き合いくださった心優しき皆さま、本当にありがとうございました。またこのようなイベントに行きたいとおもいますので、再会することがありましたらヨロシクおねがいしますですm(_ _)m
うーん、長い。。。
だらだら書きすぎたorz
公開するblogなので、1/3 ぐらいの文章量にできるよう、こっちも日々精進しないと。
（５）補足・・・関連リンク集とか
https://speakerdeck.com/kakutani/opening-keynote-for-agilesamurai-basecamp
http://grimrose.blogspot.jp/2013/12/agile-samurai-base-camp-agilesamurai.html?spref=tw
http://makopi23.blog.fc2.com/blog-entry-125.html
http://lewuathe.com/blog/2013/12/09/agile-samurai-basecamp-in-tokyo/
http://sue445.hatenablog.com/entry/2013/12/09/013010
※他にも多数（あとで追記）
