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

先日、其の壱として和智さんのセッションについて書きましたが、今日は以下のセッションについて書いてみようと思います。

講演者和田卓人さん
タイトル愛せないコードを書くには人生はあまりにも短い
セッション2012/12/16(日) 17:10~18:00  Room A 
URLhttp://devlove2012.devlove.org/speaker#speaker_31
Togetterhttp://togetter.com/li/423728
スライド



■自己紹介
  • ブログのIDはt-wada。ハイフンは「真心」。
  • TwitterのIDは、@t_wasa。アンダースコアは「下心」。
  • githubはtwada。ハイフンもアンダースコアも無い、「心が無い」。
  • プログラマ兼社長。
  • プログラマが知るべき97のこと、という書籍の監修を3年前くらい前にやった。
  • DevLove2012で、TDDについて話す人が多すぎる。なので今回はポエムっぽい話をしようと思う(笑
  • TDDはもう宣伝とかは十分な地位にある。今日は、自分にとって、あなたにとってのTDD、という話だけをする。

■アジェンダ
  • 1.誇りを失う仕組み
  • 2.誇りを取り戻す一歩
  • 3.予期せぬ変化を予期する


■1.誇りを失う仕組み
  • 自分が楽しいプログラミングと楽しくないプログラミングの違いとは何か?
  • コピペ駆動開発
  • うんこ形式のコメント(バージョン管理システムを使わず、ソースに修正履歴がコメントで膨大に書かれている。)
  • 「動くコードに触れるな」(どうしても触れるときにはうんこ形式のコメントを残せ)
■官僚主義
  • 一番レベルの低いエンジニアに合わせたルールにする。(例:三項演算子を使ってはならない)
  • コードレビューは、被告席に立つようなもの。綴りミスとか延々指摘される。

■人海戦術
  • タコ部屋 ・・・ プロジェクトが炎上して人員投入 →  一人の作業スペースがXX(cm)になった。。。
  • エビデンス・・・方眼紙Excelに貼り付けられたスクリーンショット。。。
  • 負荷テスト・・・偉い人が号令を掛けて、体育館に集まったエンジニアが一斉にクリックして負荷テスト。。。

■ドキュメント
  • 大事なドキュメントはゼロでもいけないし、多すぎてもいけない。
  • ドキュメントというものの存在と難しさが、日々の仕事を疲れさせてしまう原因の1つ。

■技術的負債
  • 技術的負債という言葉は、悪い言葉ではない。(例:企業がビジネス上必要な賭けとして、市場にソフトウェアを早くだして挑戦のステージに立つために、テストを省く場合)
  • 技術的負債の問題は、返すチャンスが少ないこと。
  • 技術的負債を気づいているのに、直せない。
  • リファクタリングせよ、というタスクがずっと残ったままになると、心理的負債になる。(~せねばならない、というのをバックログで毎日見てると、自分の心や誇りをすり減らす原因のひとつ)
■教育的すぎる世界
  • ~なんて当たり前、と言って出来る人と、目の前にいる自分とを比較して、打ちのめされる。心をすり減らす原因の一つ。

■でも、本当は知っている本当のこと
  • 自分が自分のコードに愛着に持てなくなってきた原因は、ホントはみんな自分で知っている。
  • それは、自分の頭と自分の実力が、それについていけなくなったから。それを認めたくない。

■自分を失う原因
  • 自身を失う仕組みは、自信の持ちすぎである。
  • その自信は、自分の幻影。サクッと終わらせるつもりだったものがサクッと終わらせられない自分にガッカリする。
  • さくっと行かない現実とさくっとやってみせるはずだ、というギャップに打ちのめされる。
  • そういうので、自分の仕事やコードに愛着や自身が失われていく。

■自分の弱さ、自分の弱さ
  • なので、自分の弱さに立ち向かっていかないといけない。
  • 忘れっぽい、とか、移り気、というのは人間のスペックである。多かれ少なかれ、みんなこう。
  • なので、これに正面から立ち向かって克服する術を見つけていかないといけない。

■誇りと愛着を殺すもの
  • 誇りを殺すのは、自分の弱さ。
  • 誇りと愛着が持てないと、作るシステムは良くならない。

■ご参考「原メソッド」
  • スライドに講演者(自分)に対する指示を埋め込んでおいて、チェックポイントを自分に見せるというもの。
  • 原信一郎さんが提唱している手法らしい。


■2.誇りを取り戻す一歩

■教育的すぎる世界に抗う
  • ~できて当然、という話はどうでもいい。問題は、自分がどうあるか。
  • 人は、自分の成長速度でしか変われない。今できている人と比べたって仕方がない。打ちのめされるだけ。
  • ただし、諦めてはいけない。
  • 大事なのは、過去の自分との相対評価。
  • 過去の自分と比べる。過去に自分が書いたソースより良くなっているか、とか。
  • 他者と比べてしまうと、出口がないものが待っている。

■愚直であれ
  • 自分がガレー船の絶望と戦ったやり方は、愚直になれ、だった。
  • 写経をやる。自分がやりたいことを写経して動かしてみる。
  • そこのフィードバックから何を言おうとしていたのかを読み取る。
  • 技術書の写経の方法、でググると、t_wadaさんが140文字にまとめている。↓



■3本柱
人間の限界(忘れっぽいとか、継続してできないとか)と戦っていくために道具を身につけましょう。
  • バージョン管理
    • (CVSの頃は、ブランチ管理を手動でやる必要があった。)
    • ソフトウェアは意外に長生きする。人間の記憶力を、ソフトウェアの寿命はあっさり超えていく。
    • バージョン管理を身につける、ということは、自分の記憶力を拡張する、ということ。
    • バージョン管理をしないというのは、一回もセーブせずにRPGをやるようなもの。大きなリスクがある。
    • バージョン管理を使うと、簡単にブランチがきれる。

  • 自動テスト
    • ドキュメントと自動テストは強い相関がある。
    • 最近のソフトウェアを自然言語で書くには複雑すぎる。
    • 動くドキュメントとしてテストコードを書いていくほうが、最近では合理的である。
    • 劣化しないドキュメントとしてテストコードをメンテナンスしていく。それがテストコードの良いところ。
 
  • 自動化
    • 同じことを続けていると精度が落ちて、疲れて、飽きてくる。
    • 3回同じものを書いたらアウト。BY増井さん
    • 変更の阻害要因は全部リスク。
    • どれだけ変更についていけるか、を人間が努力せずに機械がサポートしてくれるか、を機械と歩んでいくための仕組みが自動化。
 
■動作する、きれいなコードへ
  • 動作するきれいなシステムを作りたい。
  • 官僚主義的な強迫観念とか技術的負債とかで、まず動くことに価値が求められる。
  • 動作する(グラフの右下)ことは正義。
  • だけど、グラフの右下(汚いけど動作する)にいると、心理的負債によってプライドがすり減っていく。

 
■リファクタリング
  • コードは動かなくても現実世界は動くんだから、結局コードにはどんどん変更を入れていかなければいけない。
  • 動くコードに触れずにそれをやらないといけないということになると、何が起こるかというと、コピー&ペーストになる。
  • それで誇りが失われている。
  • だから、リファクタリングには「意志の力」が必要。
  • 意志の力と、コツコツとテストコードを貯めていく努力、この2つが必要。

■TDDと黄金の回転
  • TDDにおける「テストコードを先に書く」というのは、コードの綺麗さには寄与しない。
  • TDDのサイクルと4象限のモデルを組み合わせると、黄金の回転になる。
  • 技術的負債がたまると心理的負債が溜まってプライドがすり減っていく。
  • 技術的負債を返すための期間とか予算とかの仕組みが必要になってくる。そうなると説明責任が発生する。
  • → どれだけ黄金の回転を小さく回して毎日ちょっとずつリファクタリングしていけるか、が重要。
  • 「リファクタリング」しましょう、と名前がついてしまう時点でやりにくくなるというジレンマがある。
  • そうじゃなくて、リファクタリングというのはプログラミング。
  • プログラミングの一部として、リファクタリングを入れる。
  • リファクタリング、というものとして切り出してしまうと、リファクタリングできなくなる。
  • プログラマはリファクタリングによって綺麗なコードを書いている実感によって、誇りを取り戻す。

■三本柱と黄金の回転の力
  • バージョン管理、自動テスト、自動化、TDDを回る4象限の力によって、恐怖を克服して、変更の勇気を得るための協力な仕組みになる。
  • これらによって、これまで自分をすり減らしてきたものに対するリベンジするための準備が整う。
  • 規模の大小は関係ない。自分たちの限界を認め、自分のスピードで自分の限界を引き上げる。
  • それを助けるための道具は近年揃っている。それを知って、使って、自分の弱さを克服し、限界を引き上げていきましょう。
 
■3.予期せぬ変化を予期する
「予期せぬ変化を予期する」という言葉は、先ほど和智さんのセッションで議題だったGOOS本に出てくる。

■予想外の変更
  • プログラムは価値を社会に提供している限り、変更に晒される。
  • 変更が予想内であることとはほとんどない。大体変更というものは斜め上からやってくる。

■予想できないことだけは予想できる
  • 自分が変更を予想できない、ということだけは予想できる。
  • 良いコードであればあるほど、FIXされない。良いコードであるほど使われ続けて、後から要望が出てくるから。
  • 変更は予想を超える。予想外に備えるためには、鎧を着込むのではなく、身軽であること。
  • どれだけコードが身軽であるか、が予想外に備えるということ。構えすぎないこと。
 
■シンプルさを保つには
  • 歴史を知る。これまで生き残ってきたものには理由がある。きっと何らかの秘密がある。良いと思うことを見抜くこと。
  • まだ生き残ってて上手くいっていると思うもの。
    • UNIX
    • REST
    • SQL
  • これらには身軽である、というヒントがある。
  • UNIX
    • 自分が変わるんじゃなくて、組み合わせることで対応する指針。
    • パイプとプロセス間通信の仕組みが発達している。一つ一つは単純だが、組み合わせることで複雑なことができる。
    • KISS(Keep It Simple, Stupid)
    • 単純に動け。(複雑にすると怒られる文化。シンプルなものを組み合わせて予期しないものに立ち向かう)
  • REST
    • URLが偉くて振る舞いが少ない。
    • できることは少ない。状態を持たない。これらが繋ぎやすさを生み出している。
    • URLがわかれば、やりたいことは4種類くらいに絞られる。その4種類は大体が合意されている。
  • SQL
    • すべてが集合。
    • できることは少ない。
    • すべての単位として、集合に帰ってくる。クロージャ。
  • 共通するもの
    • インタフェースが少ない。けど、インタフェースの組み合わせによっていろんなものができる。
    • 少ないインタフェースの合意が成されていて、かつ実装に依存していない。だから時間を跨がれる。
    • 40年前にかかれたプログラムの出力を、今書いた自分のプログラムが受け取って、その出力を30年前のプログラムに渡す、とか。
    • 再利用がしやすい
   
  • 穏当なコードで書きたい
    • 直行:自分がやりたいことを認識していて、他のことと離れていること。変更理由が1個。
    • キレイで読みやすくて、アクロバティックではないコードが良い。
    • アクロバティックなコードはスピードを求められる場合。
    • 時を跨いで使われるコードは、如何にも動きそうなもの。アクロバティックなコードはこういうものではない。
 
4.TDDとは何か

■プログラミングを支えるものは何か
  • 楽しさとか情熱とかモチベーションが、日々のプログラミングを支えている。
  • それらの多寡によって自分のモチベーションが変わる。

■TDDは弱い私たちのためのもの
  • TDDは、自分たちにプログラミングの楽しみを思い起こさせてくれる。
  • TDDは、自分の足で歩き出すための技術であり、道具。
  • 手元に、原風景の残す。TDDをやると、プログラミングの楽しさが蘇ってくる。
  • TDDはプログラミングの楽しさを取り戻すもの。
 
■TDDは結局のところ何なのだ?
  • 今が自分が思った通りに動いているし、静かな自信の上に歩いていけるのがTDDの良いところ。
  • 徹夜して気合で頑張るのは、勇気じゃなくて蛮勇。
  • TDDは、自分が自分の足で限界を引き上げて、静かな自信の上でもう一歩を踏み出すこと。そこには心の平安がある。

■作業者になるな
  • 大事なのは、考えることをやめないこと。
  • 考えること以外はコンピュータに取って変わられる。
  • 変化に対して、蛮勇ではなく静かな自信で立ち向かうために、一歩一歩砦を自分の中に構えていく。

 
■TDDはスキルです
  • TDDは才能ではなく技術です。才能は、ジョジョ風に言うと、スタンド。
  • ジョジョの第1、2部を私が好きなのは、才能に対して、技術と努力に立ち向かう物語だから。
  • 後天的に才能を得る寸前まで行って、そこから離れていく。(ジョジョねた)
  • 誰でもできるはず。
  • 大事なのは才能ではなく技術。自己研鑽によって取得することができる技術。
  • 練習すればするほどテストコードやリファクタリングはうまくなる。才能の入る余地はない。
  • 迷ったら、愚直に戻る。写経をする。
  • 自分の足で、自分の成長のスピードで一歩を踏み出す。

★感想:
和田さんのセッションはいつも熱いお話が多くて、この日もジーンと涙腺に来ちゃいました。
私の心はどちらかというとSEやマネージャといったロールではなく、かなりプログラマ寄りなので、同感する話が非常に多かったです。
和田さんが力説していたTDDを実践していくためにも、GOOS本の写経を頑張ろう。。。



スポンサーサイト

「第1回 読書会in東京 - スクラムを活用したアジャイルなプロダクト管理」に参加しました

2012/12/21(金) 「第1回 読書会in東京 - スクラムを活用したアジャイルなプロダクト管理」に参加してきました。

DoorKeeper(告知サイト)
http://agilepmwithscrum.doorkeeper.jp/events/2215

場所は楽天タワー2号館です。参加者は20名くらいでしょうか。
以下の書籍をターゲットとした読書会なのです。

scrum_product.jpg■ 名称:スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発
■ 単行本: 139ページ
■ 出版社: ピアソン桐原 (2012/11)
■ ISBN-10: 4864010978
■ ISBN-13: 978-4864010979
■ Amazon:http://www.amazon.co.jp/dp/4864010978/


アジャイルやスクラムといった本は最近よく見かけますが、プロダクトオーナーに着目した書籍というのは珍しいですよね。
ということで、何か別の観点で新しい気づきが得られるのでは、と思い参加することにしたのです。



↑は主催者の @fullvirtue さんの写真付きツイートです。

reading2.jpg


■資料
『スクラムを活用したアジャイルなプロダクト管理』第1回読書会 POStudy ~プロダクトオーナーシップ勉強会~ from Mitsunori Seki


今回はエクストリームリーディング、という方法で読み進めました。

■エクストリームリーディング

  • 全員が黙々と読みます。
  • 読み始める前に、ここまで読み返しましょうと合意をとります。
  • 読んでいる途中に分からないことがあったらいつでも互いに聞いて構いません。
  • 読み終わった人は「終わった」と宣言します。
  • 早く読み終わった人は、次を読んだり、自分有りに内容をまとめたりしておきます。
  • 読み終わったら、内容を誰かがまとめます。
  • 議論が長めになる傾向があるので、ほどほどで打ち切るようにしましょう。
  • 時間管理が必要です。
  • 発展的な議論を行うというよりは、本の内容を正確に理解しようという形の議論になります。
  • 以上のように、読み→議論を繰り返すことになります。


今回の読書会で多くの気づきを得ることができましたが、いくつか書いてみます。



■チーム分け

最初にチーム分けをしましたが、今回は同じような経験値を持つ人が5人ずつ集まるよう、チームを組みました。
まず、部屋に全員で一列に並びます。POやスクラム、アジャイルの知識が深い人から前の順です。
んで、前から5人ずつ、チームを作っていきます。
こうすることで、アジャイルの経験が低い人がチームの議論から取り残されることが無くなります。
またバックグラウンドが近い人が集まるこので、より一層深い議論ができるようになります。
私が参加しているアジャイルサムライ横浜道場の読書会では、経験値がバラけるようにチーム分けしますが、今回のような分け方もあるんだなー、という点が気づきでした。


■読み進める速度

最初、@fullvirtue さんの「15分で15ページ」という配分に従って読み進めたんですが、全然時間が足りませんでした。
その後、@fullvirtue さん曰く、これには以下の狙いがあったとのこと。

① まず15分でやってみることで、この読み進め方が正しいか間違っているかが早くわかる。
② 自分の作業量を見積もらずに作業を進めるとどうなるか、を知ってもらう。


①ですが、いかにもリーンスタートアップ的な考え方ですね。
今回は15分で15ページという配分でしたが、どうやっても無理でした。
この間違ったやり方に最初の15分で気づくことができたおかげで、残りの読書会の時間を無駄にせずに済みました。
早く間違いに気づいて、ピボットするチャンスを得たわけです。
むむむ。。。単なる読書会と思いきや、いきなり深い気づきを得られるヒトトキ。

②ですが、主催者の @fullvirtue さんが言った方法だからということで、何の疑問を持たずに「15分で15ページ」という無理な設定で全員が読書を開始しました。つまり、自分の読み進める能力を考慮せずに開始してしまったことになります。
@fullvirtue さん曰く、最初の説明を受けたときに「無理」だと気づかないとダメ!とのこと。
・・・反省。
ちなみに読書の適度なスピードとしては、日本語だと15分で5ページ、英語だと15分で2ページくらいだそうです。


■当日読書方式

この読書会は事前に読んでくる形式ではなく、当日黙読してから議論する方式を取るとのことです。
これは、事前に読んでくると、疑問点が出ても読書会当日までに忘れてしまうからだそうです。
読書会当日にその場で読むことで、湧いた新鮮な疑問に対し即座に議論できる。これが良いとのこと。

ちなみに私、アジャイルサムライ横浜道場、という読書会にも参加してますが、こちらも同じ当日読書方式です。
横浜道場は音読方式ですが、当日に読み合せすることで、いちばん脳に残った状態で議論に入ることができます。
また、全員の進捗が合う、という利点もあると思います。



■本を探す時のヒント

「本を探す時は、最初と最後を読むと良い」という話題が出ました。一般に言われていることだそうな。
今日の読書会でも書籍冒頭の「推薦文」から読み始めました。ココに良いことが書いてある、とのことでした。



■読書中にわからない単語は付箋に書き出す

読書中にわからない単語は付箋に書いておきチーム内で確認し合う、ということもやりました。
これ、良いですねー。
普段はわからない単語が出てきてもなんとなくスルーで読みすすめてしまうことが多いですが、「よくわからない単語がないか」を意識して読むだけで、熟読の深さが格段に上がった。これは良い気づきでした。



■「Doneの定義」を最初に決めて読み進める

今回、「Doneの定義」を決めて読み進める、というのをやりました。
読むと決めた範囲をチームで読み進める前に、何をもって今から読む範囲が「終わった」のかを決めます。
この範囲を読んだら、チームとしてどういう形で何を纏め、他のチームにどうシェアするのか、です。
これをやることで、漠然と読むのではなく観点を絞って読み進めることができるようになります。
これも良いですねー。
昨日今日と満員電車で死にそうになりながらこの本読んでたんですが、理解度がぜんぜん違う気がします。


■重要な文を付箋に「ページ番号と行番号を書き出す」のではなく「ポイントを簡潔に書き出す」
重要な文だと思った文章が読んでてあったら、付箋に「ページ番号と行番号を書き出しておく」というのも主催者さんの説明どおりやってみましたが、これはダメなやり方の1つとのこと。
議論タイムになって、短い時間に「ページ番号と行番号だけが書かれた付箋」を全員で眺めても、議論が全く進まない。やはり付箋には、太い字で簡潔にポイントを書くのが良いです。



■まとめと発表

最後にチームで纏め、発表する時間があるのも良いですね。他のチームの気づきをシェアできます。
ちなみにウチのチームの模造紙と付箋はこんなカンジ。
discussion.jpg


■KPT
もちろん最後にはチームでKPT。
kpt.jpg

写真がピンボケしてる。。。
『スクラムを活用したアジャイルなプロダクト管理』第1回読書会 振り返り結果 POStudy ~プロダクトオーナーシップ勉強会~ from Mitsunori Seki




★感想:
ただ本を読み進めるにあらず!
ということで、いろいろな気づきを得られた読書会でした。収穫です。
良い読書プラクティスが多かったですが、個人的には「途中割り込みを許す」という点については、なかなか難しいところもあるなぁ、と感じました。
というのも、自分の読書が割り込みで中断されて別の議論をした後に、すんなり前の箇所から続きで読み進めるのが意外に難しいと感じました。どこまで読んでたのかを忘れるし、直前に読んでた段落との繋がりとかが切られるので。
割り込みで議論になった箇所が、自分が読んでる箇所より先だったりすることもありましたが、「まだ俺そこまで読んでないよ~・・・」ということもありました。

この辺は次回以降に良い解が見つけられると良いなぁ。
読書の進め方メインに書いてきましたが、本の内容についてはまた次回に書いてみよう。

最後に主催者さん、運営者さん、会場提供者さん、有意義な時間をありがとうございましたー

「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人以上だったようです。大イベントですねー
著名な方も多数講演されるということで、とても楽しみでした。

んで、最初に感想。

マジで良かった!

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

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


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

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

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

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

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

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

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

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

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の著者は、巨人の肩に乗った。1から考えたのではない。
  • 先人が積んだ石に対し、もう一歩だけ石を積む。ひとつずつ石を積む。これがGOOSなんじゃないか。

3.少しだけ、前に


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

質疑応答

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


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


Q3.
訳本に出すにあって出版社の人と仲良くなるコツはあるか。
A3.
コネ的な考え方でやるよりは、本を出したいのであれば、企画書を作って正面玄関を叩くのが良いと思っている。

感想
ちょうどGOOS本の写経会に出ているということもあって、大変興味深く話を聞かせていただきました。
あと、GOOS本に関するいろいろな背景とか関連話を聞けて、大変ためになりました。

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

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



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

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