TDD Boot Camp 東京 1.6に参加してきた #tddbc

勉強会 TDD

関東地方久々のTDDBC 1.5 in Tokyoが告知即定員オーバー瞬殺且つ定員の3倍近い募集が殺到(定員36名:募集114名)し、改めて関東/東京の需要の高さを実感。


勉強会主催者はなかやん・そるじゃー・ゆーき(TwitterID:@pocketberserker) さん。開催に至るまでの経緯は下記ブログに記載されていますが、彼のおかげでこうしてイベントに参加＆貴重な体験をする事が出来ました。ありがとうございます！

会場はニフティ株式会社 セミナールームにて。少々の時間押しの中、主催者のなかやんさんからの挨拶。

  • 速攻和田さんに話を振ろうとしたら和田さんに注意される(笑)
  • 東京1.5の人気の凄さに驚く
  • 当初、和田さんの都合が微妙だった
    • TA(Teaching Assistant)を各方面に依頼…イケメンTA達が続々集結！
    • みんなでペアプロ大会やろう！という方向へ
  • 開催を前にして、改めて和田さんに状況確認
  • (当初は午前講演のみお願いする形だったが)『午後も行けます』『懇親会も途中までなら』と嬉しい結果に!
  • →結果、かなり豪勢な講師・TA陣に!!

という流れで晴れて和田さん登壇＆午後の演習にフルで参加して頂けるという何とも嬉しい形となりました。午前の講演を直に聞けるだけでも…という感じですが、これは自分個人としても嬉しかったです。


基調講演

基本的な流れとしては、下記TDDBC福岡初日(氏のTDDBC関連スライドでは一番最近のもの？)のものとほぼ変わらないと思いますので、参照用に。

また、講演自体は自分もUst動画で前回東京1.5のものを観て/聴いてはいるのですが、やはり実際に本人を目の前にして、直に話を聴けるというのは情報の入り度合いが違ってきますね。メモも前回取っていますが、今回も改めてメモ。

  • 感謝!!
    • 会場の皆様
    • 主催者
    • TAの皆様
    • 運営の皆様
  • これまで描いたモノ
    • WEB DB PRESS各種

WEB+DB PRESS Vol.35

WEB+DB PRESS Vol.35

WEB+DB PRESS Vol.37

WEB+DB PRESS Vol.37

WEB+DB PRESS Vol.42

WEB+DB PRESS Vol.42

WEB+DB PRESS Vol.49

WEB+DB PRESS Vol.49

    • きのこ本

プログラマが知るべき97のこと

プログラマが知るべき97のこと

WEB+DB PRESS Vol.63

WEB+DB PRESS Vol.63

  • 作者: 竹迫良範,和田卓人,おにたま,中島聡,角田直行,はまちや2,上谷隆宏,青木俊介,大塚知洋,生尾剛士,大和田純,永安悟史,馬場俊彰,久保達彦,白土慧,じゅんいち☆かとう,太田昌吾,小野修司,ミック,嶋田裕二,個々一番,みやけん,清水亮,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2011/06/24
  • メディア: 大型本
  • 購入: 20人 クリック: 434回
  • この商品を含むブログ (22件) を見る

  • TDDBCへようこそ。
    • ビリー(Billy's Boot Camp)の挿絵：もうこれも(時代的に)良いんじゃないか...(笑)
    • 優しくTDDを教えます（と言いながら、挿絵には優しくない写真）
    • ペアプログラミング体験
      • 本番は午後
      • 仕事でフルでペアプロ導入している会社もそう多く無いのでは？
      • 体験すべき活動、体験して帰って貰いたい。
      • 良いところも悪い所も。
    • コードレビュー大会。
      • だいたい自分の書いたコードを人が見る
      • 同じ１つの課題をみんなで解いて人が見るなんて事は無い。
      • 人によってやり方が違う。
      • 自分が解いた問題を人がどう解くか。考えたか。
    • ふりかえり。
    • 今後の予定
      • 東京1.7：2011/08/21
      • 横浜：2011/11/05
      • 大阪
      • 四国
      • 岡山
      • 新潟
  • ソフトウェア開発の3本柱
    • バージョン管理
    • テスティング
    • 自動化
    • ※どれがもっとも大事か･･･和田さんとしては『バージョン管理』。
    • 本日全部触れるのはスコープがあふれてしまう。
    • 今日はテスティングのみ対象。
  • バージョン管理
    • 製品開発をしていた頃のCVSのログ
      • 概念はあるがソフトが管理してくれない。
      • 人間が頑張るしかなかった。
      • 現在はsvn/gitなど管理を自動でソフトが行ってくれるようになっている。
      • 手管理する時代ではなくなった。
      • バージョン管理巻物
  • テスティング
    • 自分が書くコードに関してユニットテストを書く。
      • 今日はここについて学ぶ。
  • 自動化
    • 手作業（ビルド・デプロイ・テスト）をコンピュータにやらせる。
    • 最近ではjenkinsが有名
      • （電子工作が得意なメンバーが作った環境の写真）
    • 人間しか出来ない事
    • 機械に出来る事を見極めてこちらは機械にやらせよう
      • 自動化
      • 自働化
        • トヨタのカンバン
        • 全て自動化
        • 何か伝えるときだけ（矢印が逆になるときだけ）人間が見る
  • 三脚椅子のメタファ
    • 例えとして切実さが足りない･･･良くある例えの場合(例:くさなぎの剣とか)、気合いで何とかなる(笑)
    • →三脚椅子（切実さのある概念として）
  • TDDを語る前に
    • 『テスト』という言葉の混乱
      • テストという言葉の指す者がバラバラ
      • 単体、ユニット、結合、機能、システム
      • たくさんあるけど、何が何やら･･･/単体/ユニットって意味は同じ？
      • テスト範囲による分類には曖昧さ、限界がある
        • 和田さんはきのこ本を書くときに『ユニットテスト』で統一させた。
        • テストの大きさ、粒度、範囲をベースにして話すとまとまらない。
    • 再分類のための視点を探す
      • テストは品質保証のため？動作確認のため？
      • 目的に戻って考えてみよう
      • 誰が、何のためにテストを行うのか
    • テストの再分類表
    • 『テスト』という言葉から思い浮かべるものを、『誰が、何のために』という視点で再分類する。
    • ソフトウェアが満たすべき質を満たしているか。
      • Developer Test/開発者:開発促進
      • Customertesting/顧客(のロール):進捗管理
      • QA Testing/品質保証担当者(のロール):品質保証担当者（のロール）

テスト駆動開発入門

テスト駆動開発入門

        • 会場内所有者は半分位。あまり読まれていないというのが現状。
        • ある本屋、無い本屋がある？
        • 翻訳の質について言われる本でもある。
        • 和田さんが写経した本。
        • 動作する、きれいなコードへ。
      • 和田さん、大学でソフトウェア工学を勉強していた。
      • 和田さんの最初のキャリアはソフトウェアを綺麗にすること
      • 綺麗な設計とは？完璧主義の呪いにハマった。
      • どれだけ頭脳を駆使して設計しても･･･
      • 動作する側からフィードバックが得られる。
  • TDDのサイクル
    • (1).テストを書き
    • (2).そのテストを実行して失敗させ(red)
    • (3).目的のコーどを書き
    • (4).１で書いたテストを成功させ(green)
    • (5).テストが通るままでリファクタリングを行う(refactor)
    • (6).(1)〜(5)の繰り返し
  • TDDと黄金の回転

  • TDDのこころ
    • １つずつ、少しずつ。
    • 達成可能なものを、１つずつ倒していく。
      • 小さく区切りながら。
    • 達成可能な小さなステップを定義
      • スキルの問題。
      • どうしても大きい塊で対処してしまう。最初は。
      • 小さい問題の集合に分解する･･･演習が必要。
      • 困難を覚えるペアは多くなると思う。
      • この辺体験してもらえれば。
    • ひとりずつ仕留める（by 宮本武蔵）
      • 五輪の書：一対他の対応方法。
        • 大勢を相手にするのではなくて、一対一の連続にしよう。そうすれば負けない可能性が高くなる。
    • すばやくまわす
    • 大きいテストよりは小さい、素早いテスト。
  • 自分が最初のユーザ
    • 開発するテストをコードを先に書く。
      • 自分が書いたコードの最初の利用者は自分。
        • 私つくるひと、あなたつかうひと、だとコードの使いやすさがわからない。
        • 自分が常に利用者の立場で。
          • 使いやすいかどうかが一目瞭然で分かる。
        • 利用者の視点に立つことが出来るのがTDDの利点
        • 自分のドッグフードを食え(Eat Your Own Dog Food)

  • 道具にこだわる
    • ツールには常に気を配るように。
    • 開発環境自身がTDDを後押しすための作業を厭わないように。
      • オートテスト、ガード
      • IDEの便利なプラグイン調査・導入。
      • 道具にはこだわれ。
      • 自分好みの環境→宗教戦争。醍醐味。
  • 不安をテストに。
    • どこに、何に対してテストをすれば良いか。
    • 工学的な定義は沢山成されている。
      • 書籍を紐解くのが早いよ。
    • 和田さんが言いたいのは開発者テスト（developer testing）。
      • 開発者が手を止めるのは何か。
        • →不安。
        • →不安が手を止める。『ここのアルゴリズムは簡単なのか？』
        • 不安が開発の促進を妨げる。
      • 自分自身が答えを持っている。何がわかって何がわかっていないのか。
      • 不安の量を削り取っていく。
      • 例)組織のコーディング規約
        • getter/setterには不安を持たない。
        • メインのメソッド（の不安）はsetter/getterの比では無い。不安の濃淡が違う。
        • TDDのテストは不安を克服して前に進めていくための手段。
  • 祈るのではダメ
    • 3本柱が一本も無い･･･リリースしてみるまで本当に動くかどうかわからない。
    • 常に爆弾処理をするような状況でリリースを行ってしまう現場、現状は沢山ある。
    • どうやったら現状を救うことが出来るのか。楽になるのか。
    • 編集→祈る、では現在的な開発とは言えない。
  • テストが命綱
    • 全部グリーンならリリース出来る。
    • それまで書いたテストコードが潜在的なバグを見つけてくれる。
    • 自動化されている場合に、どれだけ追い詰められていても実施出来る。
      • 追い詰められた人間が出来る手数は限られる。
      • 追い詰められてから飛び込むのは遅すぎる。
      • 緊急の時にセーフティネットになってくれる。
      • 日々テストを育てられる事がTDDの良い点。
  • なぜTDDをするのか
    • わたしたちは完璧なプログラマではない
    • 最初から思い通りにコードが書けるほど、私たちは賢くない。
    • 最初から思い通りに動作するほど、対象は単純ではない。
    • 素早く対象に近付き、フィードバックを得て方向修正をしながら開発を行う必要がある
  • テストは目的ではなく手段
    • 心理的なものが大きい
      • 即座にフィードバックを得るため
      • 書いたコードに自信をもつため
      • これから書くコードに自信をもつため
  • TDDの真の目的
    • 健康!!
      • 変化に対応出来るのは健康体のコード
        • 変化：学ぶ事によって、もっと良い書き方が出来る/新しいテスティングフレームワークを覚える
        • 健康体：無駄のない、引き締まったコード/コピペ繰り返しのようなものは変更が大変
      • 変化に対応出来るのは健康体のチーム
        • 夜遅くまでバグ修正のコードを書いているとか、毎日毎日レッドブルを飲んでいるとか（笑）
        • プログラマとしては生き生きとコードを書き続けたい。
        • 今コードが動くか動かないか
        • 常に分かる状態
        • TDDは個人スキル。どんな絶望の中でも自分一人から始める事が出来る。
    • 不安の克服
    • 健康の維持
    • 自分たちの手をとめるものたちに立ち向かい、健康を維持する。
  • 事例
    • TDD導入効果（MS, IBM）
      • TDDをやっていない：バグが4割減った（IBM）6割へった（MS）
        • 劇的にへった。（MSは何をやっているんだ？）
          • バグの欠陥密度は減っている。
        • 実装時間
          • 概ね15〜35％。コードの実装時間は増えている。
        • 5秒で説得するなら『実装時間が2割増えて、バグが半分になります』
    • TDD導入効果（エリクソン他）
      • TDD実施した場合に報告されている治験
        • 機能テストでの不具合検出件数が１８％削減された
        • コーディング（実装）の時間が16%増えた
        • テストのカバレッジが大きくなった
    • 被験者を対象としたアンケート
      • 実装時間はテストコードを書く時間も含めるので当然増える。がしかし全体では明らかに減る。
      • 96%の人がデバッグ工数を減らすと感じている。
        • 圧倒的な早さでバグの絞り込みを行えているから。
      • 88%の被験者が要求が洗練されると感じる
      • 92%の被験者がコードの品質を上げると感じた
      • 50%の被験者が開発工数を減らすと感じた。
    • ※和田さん自身、デバッグ機能を使わない生活を続けている。

…とここで所定の時間となったため、一旦講演はキリの良いところで終了。残りの部分を演習終了後に持ち越すことになりました。

Backlog利用に関する説明

今回のTDDBCでツールとして使うBacklogの登録・利用に関する説明。商品開発元のヌーラボさんの中の人からの簡単な説明がありました。今後継続して使うかもしれないという事です。

TDD実演デモ

少々の休憩を挟んだ後、TDDの実演デモ。言語はJava(on Eclipse)で、和田さんと今回大阪からはるばる東京まで来られ、#jggug → #scmbc → #tddbc と共に3連戦されたいろふさんによるデモペアプロとなりました。

お題は『FizzBuzz』。いわゆるナベアツなやつですね。

どういった設計思想なのか、命名規約ひとつにとってもどういった指向/考えを持っているのか。そういった点についてお互いコミュニケーションを重ねていき、交互にプログラミングを重ねていきます。

また、テストを先に書く(ゴールから書き始める)事＝利用者の視点、『ゴール指向』に立って考え、進めるという点が強調されました。これは後の演習でも効いてきます。

主催者権限LT

LT資料はこちら。

なかやんさんのBootCamp系イベントに関する妄想・構想について。

  • 事業化
  • TDD Boost Camp
  • 講師(和田さん)の問題
  • TDDBC Boot Camp
  • 認定TDD伝道師
  • TDDBC本
  • レガシーコード改善Boot Camp

等々、実現されたら面白そうなものばかり。また、講師の和田さんに頼り切っている部分もあるのでその辺りを今後どう良くしていくかなどのお話もあったり。

  • まとめ
    • 開催するなら皆で準備しましょう
    • 妄想はときに現実となる
    • 皆で考え実践してこそアジャイルでは？

演習１/レビュー/演習２/総括

自分が座ったJavaのグループメンバーは以下のお三方。

プラス、TAに太田＠ついったー(TwitterID:@oota_ken) さんがついて頂き、演習スタート。

@shokos さん以外はTDD未経験・浅い感じなので最初のうちは進め方に手間取ったりしましたが、2〜30分もして慣れてくると良い感じに回転していく感覚が実感出来てました。

やはりペアプロをやる事で新たにな発見や、見落としている部分も多く、一人では悩んでいたミスの原因等も即座に判明したりなど、ペアプロの効果を存分に体験出来たりしました。

課題自体は前述のBacklogに各自ユーザログインし、課題を確認。

演習時間は2時間/1時間半とたっぷり取ってあるように思えましたが、いざこなしてみるとあっと言う間に時間が過ぎており、『全然足らない！』と実感。疲労度は半端なく、TDD/ペアプロ体験者、業務経験者の『残業出来ない、定時でヘトヘトになる』という言葉そのものの真相を見事に体感。(実質、演習時間内は全く休憩を取っていませんでした)

時々刻々と変化する要求仕様(登録時にメールアドレスも設定しているので、変更通知が来たりもした)に頭を悩ませたりも。

上記の仕様変更はちょうど和田さんの講義内で出た『不安をテストする』の言葉通り、本来なら感じた時点でテストなりリファクタリングをすべき所を1点しておらずにいた部分を突かれたものであり、時間も差し迫っていた為に完全には対処出来ませんでした。これは非常に良い経験になりました。

また、『時間が来るから終わらせなきゃ』となるのではなく、目の前のタスクを倒す事に集中して取り組む、不安を解消するのが優先…という取り組みの切り替え方だったり、問題の切り分け方、対処の仕方などを適宜@oota_kenさんにご教授頂き、非常にスムーズに進める事が出来ました。

結果として出題された7つの課題＋1つのバグに対して私たちのグループは4〜5個消化したところまで行ったのかな？最後までこなせなかった悔しさとか残念さとかは全くなく、不安を解消し、自信を積み上げて行った事による達成感・爽快感しか残ってませんでした。

グループの皆様、@oota_ken さんありがとうございました！

(ペアプロ時の風景。画面中央のRedBull×3は全て自分が飲んだものです(笑))

模範レビュー

この日のお題にF#で取り組んでみたという@bleisさん解説によるレビュー。Visual Studio/NUNit/git nowという環境で課題5(＆バグ8の対応)まで進んだ時点で終了。

プロダクトコードわずか36行、テストコード約120行という成果物の見事なコンパクトさに驚きつつも、コード実装上における@bleisさんのとある解説箇所に和田さんが『なるほど…』と感心されていたのが非常に印象的でした。

講演(続き)

午前中に消化しきれなかった基調講演の残り部分の講演。

  • 応用
  • 現実と戦うための本
    • 1.レガシーコード改善ガイド

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

      • 帯の『テストが無いコードはレガシーコードだ！』
      • Disる本では無い
      • どうやってテストコードを書いていくかについて解説されている本。
      • 現場にとって最も重要となる一冊では。

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (53件) を見る

  • 既にデータの入ったデータベースがある環境に取り組むための本。
    • 3.xUnit Test Patterns

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

One More Book…

    • 4.Growing Object-Oriented Software, Guided by Tests

Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))

Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))

  • この先生き残るために
    • 沢山本を読もう

  • TDDはスキルです
    • 才能ではなく、取得可能です
    • 量は質に転化します
    • 写経しましょう！

  • 技術書の写経の方法


  • TDDと黄金の回転
    • 緑のバンドに刻まれた、『acts as professional』の意味
    • テストコードを書くのはプロとして当然のたしなみ
      • Bob Martin曰く『テストを先に書くことが面倒だと思うときがある』
        • ボブ：辛いときに左手のバンドを見てるらしい。和田さん『Bob Martingも辛いんだな･･･』
      • ↓
      • 名古屋で作る話に→出来た！
      • 懇親会参加されない方には、後ほど応募フォームを告知。
      • (懇親会参加者はその場で購入することが出来た。後述)

Bob MartinやTDDBCにおけるグリーンバンドのお話については以下の辺りを参照。

時間が押していたので、ふりかえり(KPT)の時間は取れず。後日、Backlogに各自で記載するという形となりました。

総括

『t_wada賞』と題して、今回最も印象に残った方を表彰するというサプライズが。和田さんの選定により、Twitter上で精度の高いtsudaりを見せておられたSHIOYA, Hiromu(TwitterID:@kwappa) さんが見事受賞！商品として、なかやんさん自腹購入による書籍『データベースリファクタリング』が贈呈されました。

最後に、主催者であるなかやさんさん・和田さんからのコメント。

  • 仙台に次ぐ短納期でした。
  • irofさんスタッフ昇格。
    • 7/30のSCMBCも同様。拍手！
  • 和田さん登壇・スケジュール調整の件(前述)について。
  • 会場提供して頂いたニフティさん、拍手！
  • なかやんさん『今日のTDDBC、満足された方！』→会場のほぼ全員が挙手。
  • なかやんさん『次回も参加したい方！』→会場のほぼ全員が挙手。
  • なかやんさん『今挙手された方！次回は主催者で参加です！』
  • アウトプット出すまでがTDDBCです。
  • グリーンバンドの件。和田さん『1本500円でご提供させて頂きたく…』と口調が通販番組風に。


以上で本編終了。てきぱきと撤収作業を終え、お開きとなりました。

この日は直前で懇親会参加を申し込んでいたので、そのまま大森駅近辺のお店でで開かれる懇親会に参加。

懇親会


約20名が参加。周りを見渡すと凄い人ばかり。ってな感じの雰囲気でした。

本編開催中にも『和田さんは懇親会も参加されますが、途中で帰られます』というアナウンスがされていたので、時間の早いうちに！と思いサインを頂きに。

バッチリ頂きました！

…というかですね、自分は今回『TDDBCで和田さんなら、この本にサインを頂きたいな』と思い『テスト駆動開発入門』を持参してきたのですが、本来ならこの時期であれば『きのこ本』だろう。と他にサインを頂こうと持参しておられた方のきのこ本を見て『あ〜っ！しまったぁ。』と若干後悔w

プログラマが知るべき97のこと

プログラマが知るべき97のこと

そんなお願いにも、和田さんは快くサインをして頂きました。本当にありがとうございます！
次回何らかのイベントの際には改めて『きのこ本』へのサインを頂きに参加していきたいと思いますので、その時はまた宜しくお願い致します！
(縦サミレポートの件 をお話したところ認識はして頂けていました、そこにも感動！)


懇親会の途中で、希望者に対してのグリーンバンド販売が行われました。自分は最初1つ購入し、一巡してまだ在庫に余裕があったので追加でもう1つ購入。晴れて修了証を手にする事が出来ました!!次回またどこかのTDDBCに参加出来た際、そして日々の作業でテストに励む際等には身につけてモチベーションをUPさせていこうと思います。


このエントリで直近1週間、怒涛の勉強会参加ラッシュ(7日間で5個の勉強会参加・うち2つはBootCamp)＆参加レポート書きもひと段落。かなり無理したスケジュールとなりましたが、そのどれもが参加した意義のある、非常に中身の濃いものでした。このエントリ執筆時点で既に8月に途中してますが、8月(以降)も興味関心のある勉強会には顔を出しつつ、実装・アウトプット出しを主眼に置いて活動出来るように日々精進していこうと思います。

(追伸)実はこの日は誕生日でした！Twitter上でお祝いコメントくださった方々、どうもありがとうございました♪(^o^)

その他関連レポート：