fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DevLOVE Conference 2012」に参加しました　～其の壱～

2012/12/15(土)～12/16(日) 「DevLOVE Conference 2012」に参加してきました。

DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1846

DevLove 2012 公式
http://devlove2012.devlove.org/

Togetter
https://docs.google.com/spreadsheet/ccc?key=0AhD6eLMu1vRNdEdGakNieGRpNUFvMTdEODNXVmcyR0E#gid=1

場所は渋谷の株式会社サイバーエージェントです。
参加者は200人以上だったようです。大イベントですねー
著名な方も多数講演されるということで、とても楽しみでした。

んで、最初に感想。

マジで良かった！

何回か、ジーンと涙腺に来たよ。。。。

ホント刺激的な２日間でした。
ということで、ブログを書くところまでが勉強会、という言葉もあるように、今日から何回かに分けて私が取ったメモと感想を書いていこうと思います。
（セッションが多いので、一日で全部をブログには書ききれない。。。）

最初にどのセッションのメモ＆感想を書こうか迷ったのですが、今週の12/19(水)に私が参加してるオンライン実践テスト駆動開発写経会があるということで、以下のセッションにについてまず書いてみようと思います。

講演者和智右桂さん
タイトル世界をすこしだけ前に進めるということ
セッション2012/12/16(日) 16:00～16:50  Room A 
URLhttp://devlove2012.devlove.org/speaker#speaker_28
Togetterhttp://togetter.com/li/423717
スライド

私、前述したオンライン実践テスト駆動開発写経会という勉強会に隔週で参加してます。
この勉強会は以下の書籍をターゲットとしているのですが、この本の訳者が和智さんなのです。

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)
(2012/09/14)
Steve Freeman、Nat Pryce 他

商品詳細を見る

通称、GOOS本。

以下、講演時に私が取ったメモ。スライドに文章は無いけど口頭で説明があった内容を中心に書きます。

■タイトルについて
  • 「世界をすこしだけ前に進めるということ」というタイトルの「少しだけ」という意味について。
  • イノベーションといっても、みんながスティーブ・ジョブズになれるわけではない。
  • 普通の人たちがどういうふうにやればよいのか、を今日は考えていきたい。

■自己紹介
  • JavaEE勉強会というのに５，６年参加している。
  • グローバルエクスパートナーズという会社で、下請けではなくお客様と直接やり取りをしている。
  • 今はプロジェクトのリーダーをやっている。
  • 大規模な受託開発は減っていくという時代の方向性にある。
  • エンタープライズという土俵でお客様にサービスを提供していきたい。デリバリーに実際に関わっていきたい。
  • 開発に軸を置きながら翻訳とプレゼンもやっていく。
  • どうしても翻訳したい本と、そうでない本がある。これまで訳した本は、どうしても訳したかった。
  • どういう基準をもって訳したいと思っているかというと、ソフトウェア開発をどういうふうにやっていけばいいかのマイルストーンになっている本、例えばいろんな本から参考文献に指定されている本、方向性を整理して打ち出しているような本はどうしても訳したい。
  • 訳すだけだと不十分で、どういう意味があるのかを訳者の立場として理解して、整理してプレゼンスしていくのが自分のコミュニティ活動だと思っている。
  • マイルストーンになるような本を書く人が実際に何をやっているかを学ぶことが、一般人の私たちが何をしていくべきなのかを学ぶヒントになる。

１．テスト駆動開発の進化
  • GOOS本は、TDDにおける2冊目のバイブル。
  • １冊目：2002年の「Test-Driven Development」 ケント・ベック著
  • ２冊目：2007年のGOOS本
  • GOOS本は、アジャイル開発が実践的にも進化してきた時代に一翼を担った本だと思う。

■二重のループ
  • GOOSでは、外側にループが入る。
  • 失敗する受入テストを書く。内側のループであるユニットテストの前に、機能のテストが入口になっている。

■GOOS本
  • 開発スタイルとしての完成度が非常に高い本。

■フィードバックループ
  • 著者たちは、フィードバックループが大切である、と言っている。
  • 開発のあらゆるプロセスに取り入れていこう。

■フィーチャを差し込む
  • ループを繰り返す中で、ベースとなるアプリケーションにフィーチャが差し込まれていく。
  • アリスター・コーバーンが2008年に「エレファント＆カルパッチョ」というブログを書いている。
  • カルパッチョは、肉の薄切り。
  • カルパッチョのように、フィーチャーを薄くして取り出すことが大事なんだ。
  • 薄いフィーチャはリリースできる単位でなければならない。
  • 開発をDriveするために何をしたらいいか？
    • まず、オブジェクト指向ってどういうもの？と考えてみる。　→　関連し合うオブジェクトの網の目でソフトウェアを構成する。
  • オブジェクトの関係が網の目だとすると、影響関係があるオブジェクトをあらかじめ用意しなければいけない。つまり際限なくコードを書かないとテストできない。
  • そうではなく、隣接オブジェクトをモックに置き換えて、網の目の構成の１つ１つをテストする。

■内側の質／外側の質
  • 品質を大きく２つに分ける
    • 内側の質（内部品質）・・・プログラマにとっての質。ちゃんと設計・実装されているか。
    • 外側の質（外部品質）・・・システムが外から見て機能要件を満たしているか。受入テストで保証する。
  • ユニットテストは、内側の質を高めるツール。
  • ユニットテストと受入テストで二重のループを構成し、内側と外側の質を担保する、というのが著者の考え方。
  • カルパッチョでフィーチャを差し込んで作っていく時に、始まりを考えてみてほしい。
    • 何も無い状態で一番最初のフィーチャってどうやって実装できますか？
    • この問いに対する著者の回答が、ウォーキングスケルトン（動くスケルトン）。
  • ウォーキングスケルトン　≒　すべてのコンポーネントを通過する最低限の実装
  • どういうコンポーネントがDBアクセスをどういう方式でやるのか、とか、画面を何で作るのか、といったような設計判断を決めないと、ウォーキングスケルトンは作れない。
  • ウォーキングスケルトンは動かすだけではダメ。
  • バージョン切ってリリースするやり方はどうすればよいか、デプロイするときには何を使うのか、デプロイ先はどうなっているか、ということを、ウォーキングスケルトンを１つやるだけで、いろんなことを考えないといけなくなる。そこが利点でもある。
    • 和智さんは、やってみて最初うまくいかなかったとのこと。。。
    • 最終的な複雑さを読みきれていなくて、重要なことを曖昧にしたまま自動デプロイできるからいいや、と進んだら、後々でオーバーヘットが大きくなってしまった。

■コードを書く事から、ソフトウェアを作ることへ
  • 前者が1冊目、後者が2冊目のバイブル。

２．進化の正体

■時代背景
  • 受け入れテストの2重のループは、2000年のXPのケントベック白本に現れている。
  • ケントベックの本には、失敗する受入テストから始める、と書いてある。
  • 2000年～2005年にかけてはフレームワークの充実期。
  • 2005年～2010年はドキュメントの充実期。（本として整理されてきた）

■知の流れ
  • こういうことを総括すると、誰かがなにかやってるというより、集団的な方向性、大きな流れがある。
  • GOOSは著者二人が何か考えたよりは、大きな流れの中に立って作り上げたもの。

■モック
  • モックとウォーキングスケルトンについては、GOOSのあとがきにも書いてある。
  • 1999年に、ロンドンでたまねぎの絵と「No Getters！Period！」という話が盛り上がった。
  • システム全体の中で中心のオブジェクトをテストをしたいが、皮をむきたくない。だからといってgetterを用意するのも良くない。
  • 2000年にEndo-Testingという、モックを使ったテストが提唱された論文が出た。（スライドP.31）
    • ユニットテストをやろうとすると問題に行き当たった。　→　モックオブジェクトを使えばいいじゃないか
    • 今のモックオブジェクトの原型は、この段階にほぼ出来ている。
    • ただ、論争を引き起こして「大変じゃん」ということであまりウケはよくなかった。
  • 2004年にMock Roles, Not Objectという論文が出た。著者も関わっていた。
    • 2000年の論文は実装に着目されていたが、今回のはオブジェクトに関わるロールに着目した。
    • インターフェイスの発見がメインになっている論文。

■インターフェイスの発見
  • Aをテストするのに、sというインタフェースが必要になることがわかる。ここをモック化して、Aをテストする。
  • Aのテストが終わったら、次に、Sがモックで本物が無いので、sというインタフェースに対するテストを書いていく。
  • おのテストを通すためにBを実装していくと、tとかuというインタフェースが新しく見つかる。
  • 外側から内側に入っていきながら、インタフェースを見つけていく、そういうのが重要なんだ、というのに着目している。
  • モックするのはオブジェクトじゃなくて、ロールである。これがgoosの思考になっている。
  • この論文は和智さんが訳している。今消えてしまっているので復活さえてもらうようお願いする予定とのこと。

■DSL
  • 2006年に、Javaで組み込みドメイン特化言語を開発する論文が出た。
  • 流れるようなインタフェース　＝　メソッドを繋げた時に、ソースを読むと、文章として読めるようなもの。ドットつなぎになっている。
  • この論文はマーティンファウラーのDSL本でも引用されている。
  • DSL（Domain Specific Language）

■ウォーキングスケルトンの起源
  • 誰が考えたかというと、Alistair Cockburn。
  • ウォーキングスケルトンは、アーキテクチャリングが多少インクリメンタルにならざるを得ない。
  • アーキテクチャをインクリメンタルに構築していく。
  • 他の人も同様のことを言っている。
    • メアリー・ポッペンディークのSpanning Application
    • 達人プログラマーの著者のTrace Bullets（弾道が見える玉）

■フィードバックの源泉
  • ウォーキングスケルトンをフィードバックの源泉として使う。
  • ウォーキングスケルトンを基にビルド・デプロイを自動化する。
  • フィードバックループを構築して、後の開発をスムーズにする。
  • 継続的デリバリーの中でGOOSが参照されている。

■ここまでの話
  • 彼らがGOOSに至るまでに何をしたかを説明したかった。
  • GOOSの著者は、巨人の肩に乗った。１から考えたのではない。
  • 先人が積んだ石に対し、もう一歩だけ石を積む。ひとつずつ石を積む。これがGOOSなんじゃないか。

３．少しだけ、前に

■進むべき道はどこに見つかるんだろう
  • 実践し続けること
    • 何もやらなければ、問題は出ない。
    • 実践し続けると問題が起きて、やらなければいけない方向性が見えてくる。
  • 学び続けること
    • 車輪の再発明はやめましょう。
    • 過去に誰かがハマったコトに自分が落ちるのは馬鹿馬鹿しい。
    • 同じ解決方法に辿り着くのに時間をかけるのは馬鹿馬鹿しい。
    • 他の人が既に見つけてくれているものにハマってしまわないようにする。
  • 考え続けること
    • そのとおりにやっても、うまくいかないことがある。
    • 現場にいくと、あてはまらないことはいくらでもある。
    • じゃあどうすれば良いのかを考える。同じ失敗をしないように。
    • 学んで実践しようとすると、誰も行ったことのない道に自分が一歩を踏み出すことがある。
    • 誰もやったことがないので、険しい道。すごく困る。でも、そこで一歩を踏み出すことが大切。
    • さらに、足跡をきちんと残すことが大切。（ブログとか文章とか）
    • 誰も踏み出したことがない道は、足跡を残すことで、自分が1年をかけた道を、次の人が1日でできるようになる。そうした小さな一歩の積み重ねで、世界は前に進む。
質疑応答

Q1.
GOOSを写経しているが、二重のループを書くときに、外側のテストが失敗したまま内側に行くのが腑に落ちない。
A1.
内側のテスト（ユニットテスト）は落ちてはいけない。それは、内側のテストがコードの品質を保つものだから。
でも、外側のテストは落ちててもいい。それは、進捗の指標だから。
厳密にすべての受入テストが書かれるとすると、それが赤から緑になるのはイテレーションの最後。
まだバーンダウンチャートが落ちきっていない、という目安で考えられる。


Q2.
ウォーターフォールをどっぷりやっている２次請け３次請けのSIerでアジャイルはできるか。
A2.
WFがダメで、アジャイルが良くて、という議論では無いと思っている。
アジャイルでやったほうが良いところは絶対ある。
たとえば、共通部品の開発とか。
そういう共通部品の開発は、設計書をしっかり書きましょうとはならない。
そういうところで、アジャイルチームを小さく作って、アジャイル的にやるとかがいいのでは。
期限とスコープが決まっているプロジェクトなら、WFでもいいのでは、と思っている。
アジャイルをやらなければ、という考えは捨てて柔軟にやったほうが良い。


Q3.
訳本に出すにあって出版社の人と仲良くなるコツはあるか。
A3.
コネ的な考え方でやるよりは、本を出したいのであれば、企画書を作って正面玄関を叩くのが良いと思っている。
感想
ちょうどGOOS本の写経会に出ているということもあって、大変興味深く話を聞かせていただきました。
あと、GOOS本に関するいろいろな背景とか関連話を聞けて、大変ためになりました。

というか、私の真ん前に座っていた方が質疑応答でQ1の質問をされたんですが、写経をやっているとのことで、セッション終わった後に話しかけてみました。そしたらなんと、私と同じくGOOS写経会の参加者とのことで、ビビった。。。
なんつー偶然。世界は意外に狭かった。。。ということで、名刺交換しました。

私、まだ今はGOOS本の11章までしか写経できていないので、今後もちょっとずつ進めていこうと思います。


ということで、今日は和智さんのセッションについて書いてみました。
以降も、日を分けてブログにメモと感想を残して行こうと思います。

土曜、日曜と、ホント有意義な時間を過ごすことができました。
主催者さん、運営者さん、発表者さん、会場提供者さん、ありがとうございました。

-->