2013/2/26(火) 「「SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 -」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/2775Togetter
http://togetter.com/li/462950以下書籍をターゲットとした勉強会なのです。
会場はIIJです。参加者は130名くらいでしょうか。あと大阪会場ともTV電話システムで繋がれました。
この講演、前々からとても楽しみにしてました。
データベースやSQLは、ソフトウェアエンジニアにとっては避けて通れない道だと思います。
なんせ、DBがないシステムなんてほとんど考えられないですからねー
SQLの知識はアプリ開発だけでなく、運用や保守でも要求されます。
かくいう私も、システム稼動直後からサーバルームに張り詰めて、ひたすら不具体対応のDBパッチ（更新系SQL）を本番DBに投げまくったりとかしたこともあります。。。
あと、お客さんから「～の条件に一致するデータを今すぐ取得してくれ」みたいに急にサーバルームで言われて、その場で検索SQLを組み立てて発行したりとかも、ずいぶんやりました。
あの時はSQLの本が手放せませんでしたなぁ。。。。懐かしい。
あと、IPA情報処理技術者試験のデータベーススペシャリストの資格も頑張って取りました。
合格したときは凄く嬉しかったなぁ。あの試験勉強でデータモデルの設計とか、かなり鍛えられた気がします。
しかも今回の登壇者は @t_wada さん！期待せずにはいられない。
ということで、以下メモ。
■講演資料はデブサミのがベースとなっていたようです。
■最初に着席すると、「SQLアンチパターン」に書かれた25パターンの紹介資料が机に配布されていました。
親切設計ですなー
■「SQLアンチパターン」は和田さんがオライリーで手掛ける２冊目。１年半くらいかかって監訳した。
■「SQLアンチパターン」に関するツイートはハッシュタグ #sqlap まで。
■二度目の増刷決定。まだ品薄。
■ビスマルクの有名な言葉「愚者は経験に学び、賢者は歴史に学ぶ。」
■上記は誤訳、端折られた訳なんじゃないか、と思っている。
■「他人の失敗を学ぶことで自分の失敗を回避する」というニュアンスの方が適切である。
→ 歴史を学ぶというよりは他人の失敗から学ぶ、ということ。
→ 誰かが失敗した、ということを共有することで自分の設計をより良くする。
■「SQLアンチパターン」は４つの部と２５のパターンから成る。
■各アンチパターンの名称は、趣味でカタカナにした。
→ 目立つ ＆ 共有しやすいように。かなり中二病っぽくワザとしている。
Ⅰ部「データベース論理設計のアンチパターン」
■1章「ジェイウォーク（信号無視）」・ある製品に人が１対１になっていたが、仕様変更で１対多になった。
→ 多の情報を格納するカラムの型をvarcharにして、カンマ区切りで入れちゃおう。
→ ダメな典型。。。
・交差テーブルを避ける
→ ジェイウォーク
■2章「ナイーブツリー」・ツリー構造を設計する場合に、一番素朴に設計すると、親IDを持ってぐるぐる参照構造を持たせる。
→ 数階層ならいいが、どれだけ深くなるか分からない場合は、設計に限界が来る。
■3章「IDリクワイアド」・主キーをとりあえずIDにしよう
・連番にしょう
・Railsとかに乗っていると自然とこうなっている。
・何でもID振っちゃうパターン
■4章「キーレスエントリ」・外部キーを定義せずに、アプリ側で整合性を取ろうとするパターン
・いろんな恐れにより外部キーを持たせずアプリで頑張るパターン
■5章「EAV（エンティティ・アトリビュート・バリュー）」・ものすごく動的な項目を作りたい
・外部キー 値 名前
■6章「ポリモーフィック関連」・あるエンティティを複数のものに関連づける
・結局フォーリンキーをつけれなくなって、アプリで頑張らざるを得なくなる
■7章「マルチカラムアトリビュート（複数列属性）」・ジェイウォークでカラム区切りダメとなった場合によく陥るパターン
・テーブルに出してフォーリンキーを貼りましょう
■8章「メタデータトリプル（メタデータ大増殖）」・年でカラムやテーブルを分ける
→ 年が変わるとバグるシステムになる
・メタ（例：年）が増えることによってテーブルが増えるパターン
■和田さんもジェイウォーク以外はハマッたことがある。
→ EAVにハマッたのがこの本を訳そうと思ったキッカケ
Ⅱ部「データベース物理設計のアンチパターン」
■9章「ラウンディングエラー（丸め誤差）」・不動小数点を使って誤差が出る
・少数を表すために不動小数点を使うのがアンチパターン
・DECIMALやNUMBERを使うべき
■10章「サーティンワンフレーバー（31のフレーバー）」・特定の値のみを取り得るパターンにしたい
→ 列定義で限定してしまうのがダメ
・この値しか入れられないという制約は付けれるが、どの値を入れられるかは設定を追わないとわからなくなる。
■11章「ファントムファイル（幻のファイル）」・画像とか動画とか大きいバイナリを扱うとき、パスのみDBにいれて、本体は外に置くことをよくやる。
→ ファイルは外に置くもんだ、と考えるのがアンチパターン
・DBのロールバックとかで考慮されなくなってしまう。（DBはロールバックされても外のファイルは残ったまま）
・LOBに入れろ、というのが著者の主張。でもそれはないでしょ、という意見も多い。
■12章「インデックスショットガン（闇雲インデックス）」・インデックスを貼りまくる
・測定とかテストとかせずに、めくらめっぽうにインデックスを貼る
Ⅲ部「クエリのアンチパターン」■13章「フィア・オブ・ジ・アンノウン（恐怖のunknown）」・NULLは扱いが難しい。TRUE/FALSEにプログラマは慣れているが、DBはそうではない。
→ NULLを嫌って-1とかにする。
・ちなみに著者はNULL容認派。
■14章「アンビギュアスグループ（曖昧なグループ）」・製品ごとの最新のバグを取ろうとして、MAX関数でバグIDを取ろうととする
→ DBMS依存で必ずしも想定の値が返ってこないことがある
■15章「ランダムセレクション」・和田さんはやったことない
・バグの数が増えれば増えるほどすごく遅くなる
■16章「プアマンズ・サーチエンジン（貧者のサーチエンジン）」・全文検索をLIKEで頑張る。
→ 量が増えるほどとんでもないことになる
・DBMSの全文検索機能を使うべき
■17章「スパゲッティクエリ」・複数のことを一発でやろうとする
・プログラムの世界ではダメだとわかっているが、SQLだとやろうとする傾向がある
→ シンプルなクエリを複数に分けたりして避けるべき。
■18章「インプリシットカラム（暗黙の列）」・ワイルドカードをアプリケーションコードに入れていると、列の追加削除にアプリがついてこなくなる
・列名をちゃんと書きましょう
・コンソールでSQL打ち込む場合はいいが、アプリとしてやってしまうのはダメ
Ⅳ部「アプリケーション開発のアンチパターン」
■19章「リーダブルパスワード（読み取り可能パスワード）」・パスワードを平文でDBに入れる。最近もまだこんなことやってることがある
→ ソートつきのハッシュを使いましょう
■20章「SQLインジェクション」・エスケープしましょうというより、プリペアドステートメント使いましょう
・それでも上手くいかない場合にどうすべきか、本に書いてある
■21章「シュードキー・ニートフリーク（擬似キー潔癖症）」・欠番がある
→ 欠番があると埋めようとしてしまう。
・欠番を埋めてもろくなことない。
→ じゃあ、どうしますか、が本にかかれている
■22章「シー・ノー・エビル（臭いものに蓋）」・例外のハンドリングをしないのはダメ
・落ちるとどこが悪かったのかわからなくなる
■23章「ディプロマティック・イミュニティ（外交特権）」・SQLを特別扱いしてドキュメンテーションとかバージョン管理とかテスティングとかしないのはダメ。
・データベースの世界も従うべき
■24章「マジックビーンズ（魔法の豆）」・アクティブレコードを降るに使うと構造が丸見えになってしまう。依存性のグラフが複雑になりすぎる
■25章「砂の城」・想定不足のパターン。奥野さんの書き下ろし
■アンチパターンとは、べからず集、あるある集だけではない
■この形式を覚えておいてほしい。25のパターンは全部こうなっている
０．名前がついている
１．目的
２．アンチパターン
３．アンチパターンの見つけ方
４．アンチパターンを使ってもいい状況が書かれている
５．解決策までかかれている
■０．名前がついている
・アンチパターン名はなぜカタカナ？
→ 諸橋さん曰く「目立つようにしたい」
・「素朴な木」だと会話に混ざってしまう。
→ 「ナイーブツリー」とカタカナにした。
・議論のひとつのポインタにパターン名がなってほしい
・パターン名でいきいきとした議論ができるようにしたかった
・必殺技の名前のようにしたい
・名前だけで何がマズいか、とかを共有できるようにしたかった
■２．アンチパターン
＝ 良かれと思って裏目にでてしまう
・例：ナイーブツリー（素朴な木）
階層が深くなればなるほどJOINを増やさなければならない
→ 素朴すぎるがゆえにアンチパターンになる
■４．アンチパターンを使ってもいい状況が書かれている
→ この本のフェアなところは、アンチパターンを使ってもいい場合に言及していること。
・例：ナイーブツリー（素朴な木）
共通テーブル式という機能を使って再帰クエリを書けるのであれば親IDをもたせてもいい。
特定のDBMSならOKという制限を設けている
・アンチパターンでも、ある状況では正しい、ある状況では間違った判断、とコンテキストや制約で変わる。
→ ここをこの本は理解している
■５．解決策までかかれている
・ナイーブツリーの解決策として、階層をスラッシュ区切りで表現する代替ツリーモデルを使う
・解決策も得意不得意がある。１つ１つ論じられている
■おわりに
・この本は、他の人の失敗が結晶化されている。
・このままだとやばい、と嗅覚がはたらくように。
・きちんと名前つけて議論しましょう
グループダイアログ１「SQLアンチパターン・レトロスペクティブ」SQLアンチパターンのカタログを片手に、25の落とし穴それぞれについての失敗談を思い起こし話しあう時間です。
約1時間で、以下のことを行いました。
・各自の失敗談について約4名のグループ毎に話す。
・グループでどのアンチパターンを話すか決める
・カタログの解決策を横目で見つつ、どうすればよかったのかを全員で話し合ってみる
ウチのグループは4章「キーレスエントリ（外部キー嫌い）」について主に話し合いました。
大体以下のような意見が出ました。
・外部キーを貼ると、テストデータのinsertやdelete時に参照制約がかかりまくって上手くinsertやdeleteできないことがある。
・外部キーをDBに貼らないなら、アプリ側で整合性を制御しなければならなくなる。
・DBは最後の砦。アプリ側で必ず対策してくれるとは限らない。
途中、傍を通りがかった和田さんからも、キーレスエントリに関するコメントを戴けました。
・昔はテストデータのローディングに失敗するからやりたくなかった。
・今では、テスト毎にテストデータを作ることができるようになった。
次に、各グループで議論したことを共有する時間が設けられました。
■失敗談１「ジェイウォークとEVAの組み合わせ」
・テーブルにJSONをいれる
→ テーブルに何が入っているか誰もわからなくなった
■EAVについて。
・本当にバリエーションがわからないからEAVにせざるを得ない状況なのか、考えること重要。
・３つくらいバリエーションが出ると、めんどくさいから全部いれちゃえばいいや、となる。
・そうなるとDBMSの良さが失われる。
■失敗談２：オレオレ図
・ER図じゃなくて四角と線で結ばれているオレオレ図のような仕様書があった。
グループダイアログ２「26個目の落とし穴を探せ」SQLアンチパターンにはまだ無い、26番目のアンチパターンとは何か？をグループで考えることをやりました。
具体的には以下のことをやります。
・こーゆうのがあった、というのをグループで共有する。
・どーすれば良かったのか。
・アンチパターンの見つけ方はどうだったか
・どーいう状況が弊害が出たか
・アンチパターンの名前まで考えて付けてみる
■「形無しの型」
・カラムのデータ型を守らない
■「レインボークエリ（通天閣クエリ）」
・SQLはいろんな書き方がある。例えば、副問い合わせの代わりにUNION JOINとか。
■トリガーに関するアンチパターン１
・DBにはカスケードとかトリガーを仕掛けることができる。
→ DBに隠れた挙動というものが出てくる。
→ それが中性脂肪のように溜まっていく。
→ DBを扱っているだけなのに、裏でなにかが動いている、というような状況に陥る。
■トリガーに関するアンチパターン２「忍者屋敷」
・トリガーが連鎖的に反応し、あるトリガーの結果が他のトリガーに引っかかる。
■DBのドメイン定義が重要。トリガーは止むを得ない場合のみ使う。
■カスケードデリートとかカスケードアップデートというのは、和田さん（父）は設計したことがない。
■26個目のアンチパターンについて是非ハッシュタグ #sqlap #devlove でツイートしてほしい。
■みなさん、自由な設計で考えがちでは。
→ 論理設計段階でかっちりした構造がもっとできるじゃないか。by 和田さん（父）
■大事なのはバランスを取ること。Strictのレベルを自分として持っていくのが大事。
★感想：大変興味深い内容で、凄く引き込まれた2時間でした。
最初「SQLアンチパターン」というタイトル名を見たとき、「あぁ、インデックスが利かないSELECT文の書き方はダメ」とかのレベルがたくさん書いてあるんだろなー、と思ってました。
でもこの講演を聴いて、そんなレベルではなくDBの論理設計、物理設計から考察している点にビビッた。
DMLだけじゃなく、DDLも考慮しているんだ、むしろそっちの方が多そうだ、という感触でした。
ということで、コレは良さそう！と思い、帰り際に会場でSQLアンチパターンの書籍を買いました。
どっかでこの書籍の勉強会とか読書会あるといいのにな～
最後に、講演者の和田さん親子、papandaさん、スタッフさん、会場提供者さん、ありがとうございました。
2013/2/15(金)「Developers Summit 2013」に参加してきました。
公式サイト
http://event.shoeisha.jp/detail/1/先日、以下のセッションに関するメモと感想を書きました。
其の壱：
【15-C-5】ディシプリンド・アジャイル・デリバリー～エンタープライズ・アジャイル実践ガイド～其の弐：
【15-A-7】ワンクリックデプロイ ～いつまで手でデプロイしてるんですか～デブサミから少し時間が空いてしまいましたが、今日は以下のセッションについて、スライドに無かった口頭メモを中心に、書き残しておきます。
【15-A-8】 アジャイルサムライって当たり前になるのかな？Togetter
http://togetter.com/li/451011■AgileもScrumもLeanも、入り口が違うだけ。目指す場所は一緒。
■アジャイルが当たり前になるために、２つのことを乗り越えなければならない
・自分の現場で始めること
・成果を出すこと
■西村さんの場合
・一冊の本に出会った
・アジャイルやりたくて仕方なくてやり始めた
・独りで朝会や振り返りやペアプロやった
・そのおかげで自力がついた
・だから、始めるのは難しいとは思わない
■独りでやってると、いつかは上司とかとぶつかる
・その時に備え、価値ある成果を出せるように備えておく
・成果を出すと、話を聞いてもらえるようになる
---
ここから3人のエンジニアさんの登場です。
■及部さん
・アジャイルをやり始めて、チームを良くするには、ということを真剣に考えるようになった
・あたりまえなことができてない、ということを認識することが大事
■竹林さん
・スクラムマスターに向く人がいれば、やってみる？といって育成する
■上田さん
・開発初心者のチームでもアジャイルでサービスをリリースすることができた。
→ アジャイルを活用する理由も変化する。
■いちばんうまくいかなかった話 ●及部さん
・トレードオフスライダーが動かせない時に、教科書通りにやってたら、元に戻された
（進捗が見えないということで元に戻された）
・共感してもらう、ということができてなかったので、反省して、巻き込むようにした
●竹林さん
・ビジネス側の人とヒートアップして敵対関係になった。
・話聞きましょう、として、相手がわかる言葉でしゃべるようにした
●上田さん
・やりすぎた。いろんなプラクティスを知ると、やりたくなってしまう。
・やりすぎると計測できなくなって、どれが良い事か、わからなかった。
■成果が出たと思った瞬間 ●上田さん
・自分の手でリリースすることを成果と考えていた。
→ 売り上げを上げるプロジェクトであってもメンバが嬉しくなかったら成果と言えないと思った。
・人とかチームを育てようとして実行に移すようにアクションを起こすことが成果。
●竹林さん
・売り上げとか生産性は成果とは思わない。
・チームがやってよかったと口にするのが成果と感じる。
・何気ない会話で、このやりかたにしたほうがやりやすい、とかいってくれたときに成果だと感じる。
・言葉として出てくるまでに１ヶ月くらいかかると思う。
・実感する瞬間と、目の前でわかる瞬間は違うと感じる。
●及部さん
・自転車にのったときと同じ。立って放す瞬間がまず成果。
・最初の乗り方を覚えるのが成果。
・アクションを起こそうとした人が、それを起こしたことによって、他の人が変わり始めた瞬間が成果。
→ それまでに半年かかった。
■やってみてダダスベリだった事と、良かったプラクティス ●上田さんのダダスベリ
・ペアプロタイムを設けた。１３時から一時間はペアプロの時間、みたいな。
→ 全員初心者だったので、ペアプロの準備の時間を設けるようになって、品質に結び付かなかった。
●竹林さんのダダスベリ
・ペアプロ。ググって、ペアプロが良いらしい。 → じゃあペアプロやりましょう。
・チームでペアプロやってみると評判が良くなかった。
・TDDとか分かってない段階でやって、理想と現実に打ちのめされた。
・じゃあどうすればいいの？とチームに聞いたら、自分のやってる情報を共有する風にします、となった。
●竹林さんの良かったプラクティス
・振り返り。リーダー格の人が大抵いるので、振り返りの場がないと、その人がいつも仕切ってしまう。
→ 振り替えりをやると、皆から話が出る。
●及部さんのダダスベリ
・振り返り。普通に振り返っても重くなるのでアイスブレイクをやったりする。
→ そこでアニメのネタで振り返りをやったらダダスベリした。
●及部さんの良かったプラクティス
・同じく、振り返り。意外とみんな、言いたいことは持っている。
→ コミュニケーションの場がないと出てこない。
→ 振り返りで掘り下げて、みんなで考えよう、とすると上手くいった。
●西村さんのダダスベリ
・朝会。「何立ってるの！」と怒られた。
■他人の巻き込み方（自分以外の反応） ●上田さん
・POの反応
・今までは一方通行だった。今はチームから企画が出る。リスクもでてくる。
●竹林さん
・前の会社で成果は出していた。
・周囲からは、若造のくせに新しい事やりやがって、みたいのがあった。
・今の職場では、疑問点について他のエンジニアに質問を投げかける。
→ 「ペアプロやらないなら、どうやって品質を確保しますか」みたいに。
→ 自分達で改善していくようになった。
●及部さん
・アジャイルで失敗して嫌悪感を持ってる人がいると、アジャイルはダメ、って人になる。
・なので、アジャイルという言葉を出さない。改善をしていこう、とした。
・今まではうるさい、と言われてたのが、やってみたら良かった、というふうになった。
■間違った解釈をしてる人との向かい方 ●及部さん
・向き合うと敵対とは上手くいかない。
→ 間に人を立てて、その人のせいにする。
・信頼関係を築く。仲良くやれるようにする。
●竹林さん
・相手の考えを変えようとすると反発される。
・なので、ディスカッションの場をつくる。
・みんなのいる場で話す。
・相手の考え方を変えるのではなく、疑問点をぶつける。
～するにはどうしたらいいですか？という話し方。
●上田さん
・都合よく考える人のうち、きちんと理解していない人が主。
・なので、その人にちゃんと理解してもらった上で進める。
（@ryuzeeさんとかの資料とか使って理解してもらう）
■普通の人でもアジャイルできるのか？ ●竹林さん
・何かぶちあたった時に、諦める人と諦めない人がいる。
・今日の3名は諦めない人だと思う。
・フィードバックだと理解する。うまくいかない方法を知ったと前向きに捉える。
・自分がへこたれそうな時に、じゃあどうやればいいのか、マインドを切り替えられるかが大事。
●及部さん
・なるべく吸収していこうと思っている。
・いろんな人に聞いてプログラミングし始めたのが、始まり。
・上手くするためにどうすれば必死に考えて、手持ちの弾で頑張っている。
●上田さん
ごちゃごちゃ言わずに試せばいいんや！
ここまでが3人のお話でした。ここから再度、西村さん。
---
■アジャイル開発は成果を出さないと回りから認められない
■学び続けて上達していく。やってみる。
■やってみると、考えることができる。次何を試してみよう、というのがわかる。その繰り返し。
■学ぶというのは自然と備わっている。アジャイルは学ぶ仕組み。
■アジャイルの本質は、学ぶ仕組みだと思っている。
■学び会うことが重要。これがないとうまくいかない。
■アジャイルサムライの次に読む本はない。やってみるしかない。
■アジャイルサムライを読んで、ようやく同じ言葉でエンジニア同士しゃべれるようになった。
■あたりまえにするには
・現場で始める
・成果を出す
・互いに学び会う■4人のエンジニアの今後のAction ●及部さん
・いまやってることを会社として認めてもらって誰にでもわかる価値をユーザに届けることが必要。
・一番大事なのはビジネス価値を届けること。
・いまやってることがビジネス価値に繋がっているのかを見せる。
●竹林さん
・まだ会社ではアジャイルはメインストリームではない。
・押し付けるんじゃなく、みんなが達成感を得られて楽しくできるように、大きく広げていきたい。
●上田さん
・先行するチームを作りたい。自分の手を動かして経験を積むことが必要。
●西村さん
・スクラムブートキャンプの本でなにかやっていきたい。
・Agile Academyという、とびっきりの先生が教えてくれる場を作る。今頑張っているところ。
★感想：登壇された4名の方の事は、これまでの勉強会や講演とかでよく知ってましたが、あいかわらずイキキとしてます。
私も「現場でやってみる」というのは大事だと意識してるんですが、アジャイルをやって「成果を出す」という考えはあまり無かったです。
成果を出すというか、そもそもスタートすることに四苦八苦してるんで、まだそこまで及んでなかった。
でも、確かに継続性を持たせるには成果を出してみんなが納得できることが必要なわけで。
やってみるだけじゃなく、もう少し「成果を出す」を意識してみようと思います。
ちなみに最後に隣の方とデブサミで誓った自分のActionについて話し合う時間が5分ほど用意されましたが、私、残念ながらここで退室しました。
この後、JBL（プロバスケ）の試合を観戦しにダッシュで代々木体育館に向かわなければならなかったので。
隣だった方、ゴメンナサイ。
最後に、登壇してくださった4名のエンジニアさん、貴重な体験談ありがとうございました。
2013/2/22(金) 「横浜道場 番外編 "自分の価値観を見える化してみよう"」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2591Togetter
http://togetter.com/li/460726以下の書籍をターゲットとした読書会なのです。
今回は番外編ということで輪読ではなく、原田 騎郎氏によるワークショップが行われました。
テーマは「自分の価値観を見える化してみよう」です。
一応、ブログにワークショップのこと書いちゃっていいか、原田さんにTwitterでお聞きしました。
（オフレコのワークショップだったりするとネタバレになってしまうので）
んで、OKです、と了承いただきましたので、以下に書いてみます。
■１．アンケート＆チーム分け最初にアンケート。これで4チームに分けます。
一番下の行の数値が最も高い列が、自分のチームになります。
左から緑、青、赤、黄です。
ちなみに私は青でした。
■２．ディスカッション（1回目）次に色分けした４チームで、同じお題に対するディスカッションを行います。
ディスカッションの時間は15分で、お題は「ペアプロの良いところと悪いところ」。
ウチのチームのディスカッションの付箋はこんなカンジ。
1回目：ウチのチームの「ペアプロの良いところ悪いところ」| 良いところ | 悪いところ |
・品質が上がる
・常にコードレビューされている
・エディタの使い方や他の人の考え方が分かる
・知識やスキルの共有
・相方の強みを吸収できる
・学習効果
・コミュニケーションの促進
・話しながらできて楽しい
・アイデアの整理
・集中力の上昇 | ・プレッシャーがかかる
・向き／不向きがある
・相手との相性がある程度いる
・互いのスキルにギャップが大きいと辛い
・時間が二人分多くかかる
・疲れる |
■３．発表次に、各チーム1～2分で発表です。
他のチームからは以下のような意見が出ました。
1回目：他のチームの「ペアプロの良いところ悪いところ」| 良いところ | 悪いところ |
・Tipsに気づける
・知識が高い人のノウハウを吸収できる
・コミュニケーションの向上による相乗効果
・常に誰かにコードレビューされている状態
・上級者の仕事を常に見て学べる
・コード・知識の共有ができる
・品質が上がる
・レビューでバグが減る
・教えながらやるので生産性があがる
・知識が共有される
・楽しい
・一人でやると詰まる
・悪いところが早くわかる
・１ヶ月でPayした | ・上司が嫌がる
・コードの保守性があがる
・ケアレスミスがへる
・ナンバーが１になるのを防げる
・時間がかかる。コストがかかる
・ペアが固定化しがち
・人との相性がでてくる
・デメリットの方がでてくるのではないか
・そうなるとチームが崩壊する
・けんかになる |
ちなみに緑チームだけは「ペアプロは良くない」という結論で、他の3チームは「ペアプロは良い」という結論でした。
■４．各チームの感想各チーム発表後、原田さんのファシリテートで各チームで感想を言い合いました。
■青：
・メリットを強調してもよかったのでは。
・まとめすぎ。
■赤：
・ペアプロをやりたいという意識がとても出てた。
・通信販売みたいな発表。
■黄：
・まとまりがない。
■緑：
・局地的な話になっている。
■５．原田さんによる各チーム品評んで次に、原田さんが各チームを品評。
私は青チームだったんですが、原田さん曰く
「このチーム、ディスカッション始まってから４分後に纏めに入ってた。せっかちや」
とのこと。いや、そのとおりだったんですが・・・よく観察してますなー
ということで、
・青チームは、せっかち
・黄チームは、言い訳じみててBAD。
・赤チームは、実際に見てみろ、というタイプ。
・緑チームは、ペアプロは新しくないからツマラナイ、と感じてるはず。
とのことでした。
■６．競合価値フレームワークんで次に、色分けの種明かし。
緑
| 青 | 赤 | 黄 |
創造・創造
Innovate | 投資・市場
Invest | 改善・管理
Improve | 育成・関係
Incubate |
| 新しいことをやりたい | 競争して勝ちたい | 制御下におきたい
（官僚文化） | 一緒にやりたい |
各チームには↑のような傾向があるとのこと。
赤の「制御下におきたい」とか、発表の雰囲気からピッタリですな。。。
あと緑の「新しいことやりたい」というのも、ペアプロを否定してたとこ見ると、あながち合ってるのかも。
■緑から赤を見ると何が大事に見えたか
・想定外が嫌い
・着実に進む
■赤にとって緑がどう見えたか
・やったことがないことが好き
■青から黄を見ると何が大事に見えたか
・平和がすき 飲み会がすき
■黄から青を見ると何が大事に見えたか
・スピードすき
どうやったら信頼を勝ち取れるか、何がValueかは青が考えている、とのこと。
あと、黄色は人を育てること、どう一緒にやるかを考えている、とのこと。
ただ、こんなアンケートくらいで分かるわけないとのこと。
でも、そのくらいの差はあるはず、とのこと。
でも、反対のチームの話を聞くとめっちゃムカつく、とのことｗ
■７．ディスカッション（2回目）次に、各色が均等に分散するようチームを分け直して再度ペアプロの良し悪しに関するディスカッションをやりました。
ただし、1回目のチームで自分の色と反対の色の立場に立って発言せよ、とのこと。
私は1回目は青だったので、今度は黄色の立場で発言することになりました。
反対の立場に立つ狙いは、自分の正反対の人が何を考えてるのか知ること、だったはず。
んでも、これはかなり発言しにくかったですね。
私以外の人も、発言がかなり少なめでして、付箋も1回目より大分少なくなりました。
２回目：ウチのチームの「ペアプロの良いところ悪いところ」| 良いところ | 悪いところ |
・和気藹々できる
・コミュニケーションが良くなる
・リファクタリングがやりやすい
・レビューも込みで早く終わらせられる
・柔軟な発想（気付き）
・育成効果
・知識を共有できる | ・コードを批判して仲が悪くなる
・マネージャが仕事を管理できない
・疲れる
・スキルに差があると効率低下 |
■８．まとめ２回目をやった意図を原田さんが説明してくださいました。以下メモ。
---
■反対側の方をやってみると、わかることがある。
■隣あってるチームとは話しやすいとのこと。
■ハンロンの剃刀Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%83%AD%E3%83%B3%E3%81%AE%E5%89%83%E5%88%80Never attribute to malice that which is adequately explained by stupidity.
無能で十分説明されることに悪意を見出すな■要するに今回で言うと、反対側の色の考えは、自分の色の考えに対して悪意があるのではない、ということらしい。
→ でも、やっぱ反対側はできない。いきなりやるとムカつく。
■１回目は同じ色の人ばっかのチームだったので、ディスカッションできない状態になっていたはず。
同じ意見ばかり出るので。
■２回目は色を混ぜたおかげでぎくしゃくする。ディスカッションの量も多くないはず。
→ でも、出た結論は説得力あったはず。いろんな人とディスカッションできたはず。
→ 反対側は悪意があると見えるが、悪意はない。
■反対側の人は「自分が一番苦手なことをやってくれる奇特な人たち」と言える。■緑は新しいモノ好きだけど、すぐ飽きるタイプ。なので、フィードバック得られない
→ でも、赤が市場に出してフィードバックを得てくれるので、緑と赤は補完関係にある。
■１回目と２回目の違い
・１回目： やるべきだ
・２回目： やってみればいい
■反対側に悪意はない。自分のやりたくないことをやってくれる人だと認識する。 2回目でやったほうが意見は合わないけど、コンセンサスは近くなる。
★感想：反対側がいてくれるからこそ、自分がそれをやらないで済む。なるほど、です。
例えばSEと営業を例にとってみても、「俺は技術屋なんだから、営業なんかやりたくない」という思いがある。
でも営業がいてくれるからこそ、俺はエンジニアでいられる、という事実がある。
この補完関係は普段、忘れがちかもしれないと思った。
自分の価値観と異なる反対側の人がいるからこそ、物事が上手くいく。
んでも、原田さんも途中でチラッとおっしゃってましたが、このワークショップの題材は「ペアプロ」じゃない方がいいのかもｗ
というのも、アジャイルサムライ読書会なんだから、参加メンバーのほとんどは「ペアプロ肯定派」のはずで。
意見がほぼ全員、同じ方向に集約されやすい題材よりは、発散する題材の方がいいのかな？と思いました。
ちなみにブログ書いちゃって良いか原田さんにツイート送ったら、OKの一言と共に、以下の書籍を紹介してくださいました。今日のワークショップの元ネタだそうです。
最後に講師の原田さん、道場主さんはじめ、皆さんありがとうございました。
2013/2/20(水) 「ビルド中心の開発 - タイムボックスと継続的インテグレーション -」に参加してきました。
DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/2715場所は有楽町のぐるなびです。参加者は30名↑でしょうか。
私、このイベントの一番の申込者でした。
自分の仕事にも直結するし、なによりも自分にとって興味がある内容だったので即申込したのです。
ちなみにこの講演はデブサミの再演とのこと。
この再演に先に申し込んでたので、デブサミではあえてこのセッションを聴講対象から外しておきました。
以下、聴講時にとったメモ。
■講演者の津田さんからの宣伝（津田さんの著書）
■普段はマイクロソフトでテストエンジニアをやっている
■反復型ソフトウェア開発の特徴は2点。
①タイムボックスを繰り返しながらインクリメンタルに開発
②初期の段階でインテグレートする
■今日のゴール
・タイムボックスと継続的インテグレーションを理解することがゴール
・本を買ってもらうことがゴール
■タイムボックスとは
・入り口と出口で区切られた、開発プロジェクトの全期間を表す箱
・作業はすべて、この箱にいれて管理する
・作業を箱に詰めることをタイムボクシングという
・作業の大きさを適切に見積もることが重要
■三択の質問。箱に入らなくなった場合にどうするのか？
１．無理やり詰め込む。（品質を諦める）
→ 残業。品質を落として終わらせる。
→ ひどい結果になる。
２．箱を大きいものに取り替える。（納期を諦める）
→ つまり、スケジュールを伸ばす。
→ それでも入らないと、更に箱を伸ばす、ということを繰り返してしまい、いつまで経っても終わらない。
３．全部入れることを諦める。（スコープを諦める）
→ 正解
→ 本当に必要な作業を詰めていく事ででミチゲート（mitigation）できる。
（mitigation＝痛みを和らげること，緩和，軽減）
→ 作業を箱から追い出すことができる。リーズナブルな値段で開発できるようになる。
★作業の範囲を減すことで品質と納期を守る。これが基本的な戦略。
■ちょうどよいタイムボックスの長さは？
→ 入れたい作業の大きさによる。
→ でも、大きすぎる箱は使いにくい。
→ 大きい箱の中に小さい箱をいれて、間仕切りを作ることをやる。
■作業の大きさを見積もって、計画的に優先度の高い順に積めていく。
→ はみ出したものは次の箱にれる。
■スプリントの入り口では、スプリントプランニングをやる。
マイルストーンの入り口では、マイルストーンプランニンング。
■バックログは、残りの作業の一覧。
→ バックログには3つのことを添付する。
①具体的な作業の内容
②工数
③優先度
■時間を使うものをすべて作業としてバックログに積む。これを作業の入り口で作る。
■途中でバックログを増やすのは基本的にやらない。
・走ってる最中にゴールを動かしてしまうと到達できなくなる。
・次のタイムボックスの入り口で追加するのがよい。
・新しい作業を追加しないとどうしてもダメな場合のみ、バックログに足す。
その際、優先度の低い作業をバックログから削る。
・今目指しているゴールの方向性に「意味がない」と途中で気づいた場合は、プランニングからやりなおす。
■途中でバックログを減らすことはありえる。
・作業を延期する場合は、パントする。
・ボールが落ちる前に蹴って誰かにキャッチしてもらう。とりあえず作業を先送りする。
・作業を次のタイムボックスに蹴り入れる。
→ 「パント」という概念は便利なので覚えて帰ってもらいたい。
■出口条件（Exit Criteria）
・残作業がゼロ
・バグがゼロ(ZBB: Zero Bug Bounce）
・出荷可能（potentially shippable）
(ship 出荷する, shippable 出荷可能)
→ 具体的な数値目標になっていることが望ましい。
■ゼロ・バグ・バウンス
・一部分を引き伸ばすとバーンダウンチャートになる。
・出口条件の到達はプロジェクトを通して継続的に観察し、追跡する。
■出口でスプリントビルドを作る
・ジェフ・サザーランドのScrum Handbookに「スプリントビルド」というのが書いてある。
→ 無料でwebで読める。（
http://jeffsutherland.com/scrumhandbook.pdf）
■この範囲の作業は全部やらないといけない、という場合、優先度をつける必要がない。
＝ フィーチャーボックス
■逆にタイムボックスをやりたいなら優先度が大事。優先度を付けないとフィーチャーボックスになってしまう。
■スタンドアップミーティングの15分間のタイムボックスに入らない話題は、捨てるのではなく、次のミーティングにパントする。
→ 優先度をつけて大事なものから報告。
■ウォーターフォールはゴールにたどり着いてから、ゴールが目的のモノかどうか始めて分かる
■CI（Continuous Integration）
・継続的にインテグレーションビルドを作る
・継続的な統合
・XPの一部として紹介されることが多いが、CIも昔からあった。
■「デイリービルドをプロジェクトのハートビート（心拍）とせよ」 by スティーブ・マコネル
ちなみに彼の著書「Code Complete」は入社2年目くらいに読んだが、とても名著だった。
■プロジェクトの初期にビルドを作り、以降も継続的にやっていく
→ 最近は一日一回でなく、１日に何回もビルドをやる。
■「ビルド」を「ビルド」する
＝ 「実行可能なソフトウェア（名詞）」を「実行可能なソフトウェアを構築する（動詞）」
（料理を料理する、という日本語と同等）
■料理をお届けするときに大切なこと
→ いつも同じものを作ること。
■ソフトウェアも同じ。
・いつ誰が作っても同じビルドができる必要がある。また再現性がないとダメ。
・ビルドの再現性を確保することが重要。
■名著「達人プログラマー」
ビルドはCRISPであるべきだ。
・Complete : ゼロからビルド可能
・Repeatable： 再現可能
・Informative： 情報を提供可能（ビルドエラー情報とか）
・Schedulable： スケジュール可能
・Portable： すこかしこでビルド可能
ちなみに私、この書籍も入社2年目のときに読んだ。しかも「Code Complete」の次に読んだ本だ。
■CRISPなビルドは「さしすせそ」
■ビルドの再現に必要なもの
・材料一式（ソースコード）
・レシピ（ビルド手順書） → 作業の依存関係
・清潔な厨房（ビルドマシン）
・調理器具（コンパイラ、ビルドサーバ）
■子供をいれて自由に遊ばせるものが「サンドボックス」の由来
・サンドバックスは外界と隔絶している。
・サンドボックスはばっちいところ。
・サンドボックスで作った料理には、虫バグが入る
→ 清潔な厨房（ビルドマシン）でビルドすべし。
■AntはTomcat専用のビルドツールだった。
→ 便利なので、汎用ツールとしてリリースされた。
■リポジトリを清潔に保ちたい。
→ 悪いことを教えてくれるのは、ビルドが壊れたあと。
→ どうせならコミットの前に悪いことは教えてほしい。
→ バディビルドの自動化
■バディ＝相棒
■バディビルド ＝ 修正を相棒に渡してビルドしてもらう
＝ コミット依頼するとサーバがバディビルドとオートメーション（自動テスト）を実行し、OKならコミットする。
■Code Complete（コーディング完了） → 安定化 → Code Freeze（リリースの準備）
・安定化期間でテストをやってバグを消す。
・品質熟成期間、焼き上げ時間、と呼ぶこともある。
・スクラムだと、バグ修正スプリント。
■安定化の時間を長く使ってはいけない。バグ修正スプリントはスクラムでは推奨していない。
■テストをする目的は何か？
・バグを見つけるためにテストする
・バグを見つけられないテストは意味がない
→ 本当にそうか？いや、そうではない。
→ テストをする目的は、バグを見つけるためではない。
・品質の情報を集めるためにやるのがテストである。
・バグがないことを確認するためにするのがテストである。
■Code Complete（コーディング完了）したのに、テストしないとバグがあるのかないのか分からないのはダメ。
■ソフトウェアは短い時間で焼き上げる
■コードコンプリートのあとにテストコードコンプリートがある
■不定期なビルドは、CIビルドと呼ばれる。
定期的なビルドは、スプリントビルドと呼ばれる。
→ CIビルドと定期的なビルドの両方が必要。
■津田さんからのAction
・計画駆動なアジャイルをしてください
・津田さんの著書を買ってください
■ダイアログ■自動テストもいいけど、Selenimuつかいにくいよね
■手動テストでも、探索テストとかいいよね
■CIで政治的な問題で手動テストが採用されたりとか、CIの教育どうするかとか悩んでる。
■FlashとかSilvertestで自動テストできない。どうすれば良いか？
→ Viewの自動テストが難しいのでViewを極力薄くしてはどうか。
→ Flashのバージョンがまちまち。クリーンではない環境が反乱している。
■テストの自動化は単体テストレベルのイメージだった。でもテストにはフェーズがある。
→ 自動化はどこまで答えてくれるのか？
■開発者がコミットする前に、コミットしていいかのテストをテスターがやる
■実装とテストとレビューをひとまとまりにしている。
エンドツーエンドのテストは不足しがち。製品出荷可能なテストがないと苦しいなと感じている。
■手動テストと自動テストの話は、「テストの４象限」が参考になる。
■DBアクセスとか、振る舞いが時によって変わるテストはテストが作りにくい。自動化されてたりしますか？
・DBアクセスとかはものにやったらやらない、というのはどうか。
・ロジックのテストはけっこう自動かされている。
・自動テストは何度も実行する箇所をターゲットとするとスッキリするのでは。
・品熟期間に自動テストするのは意味ないのでは。
■最初からテストを作ってないとしんどい。ビルドシステムとかmakefileテストスクリプトもリポジトリに入れておく。
→ ソースをコミットするとmakefileスクリプトが動いてテストされるようにておく。
■4/19,4/20に渋谷の某所でテストのカンファレンスをやる。参加者は120～150人くらい。
CITCON (Continuous Integration and Testing Conference)
★感想：自分の多少なりともCIを仕事で使ってるので、とても興味深く話を聞かせていただきました。
バディビルドとかゼロ・バグ・バウンスとか、面白い概念や用語も知ることが出来たし。
あと、ダイアログの時間に話を聞いてみると、みんな悩んでるところはけっこー同じなんだな、と思いました。
デブサミの吉羽さんの話を聞いたときにも思いましたが、一度、徹底的に自動化の仕組みを作りこんでみたいと思いました。
最後に津田さん、ぱぱんださんはじめ、会場提供者さん、運営者さん、ありがとうございました。
2013/2/19(火) アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2592以下の書籍をターゲットとした読書会なのです。
今回は特別編ということで、「マシュマロ・チャレンジ」をやりました。
私、マシュマロチャレンジはもちろん初で、どんなものかもほとんど知りませんでした。
（来る前にググッて概要を知ったくらい）
ちなみに「マシュマロチャレンジとは」というキーワードで今ググッてみたら、横浜道場でも以前講演してくださった藤原大さんのブログがヒットした。概要を知るには良い記事だと思います。
チームとタワーを創造せよ！マシュマロチャレンジでチームビルディング #sgt2011 #CSPO要するに、以下のモノを使ってチーム毎にタワーを作り、高さを競うゲームです。塔の先端にはマシュマロ。
・スパゲティー20本
・マスキングテープと紐を90cmずつ
・マシュマロ
今回、これを18分間のセッションを２回やりました。今回は３～４名のチームが４つかな。
ウチのチームは3名で、全員マシュマロチャレンジは初でした。
■１回目3名とも初なので試行錯誤しながらの18分です。以下のようなカンジで議論しながら進めました。
・スパゲッティ3本あれば立つよね？
・3本束ねるのは、テープでやってみる？ → 上手くいかないので紐でやろう
・3本を広げると安定性がないなぁ → んじゃ、下に三角形の土台を作って、角に3本を引っ掛ければいいんじゃね？
・ぬお、土台を作ったら3本でちゃんと立った！
・その先に一本スパゲッティくっつけて延ばせるんじゃね → あ、安定性悪いなぁ
・んじゃ、もう3本使ってもう一段上積みしてみる？
・2段にしてみると安定性悪いなぁ → んじゃ補強用のスパゲッティを側面に付けよう。
・残り時間が少なくなってきたから、とりあえずマシュマロをそろそろ頂点に付けてみよう
・あ、なんか立った。。。
こんなやりとりをチーム内で交わしながら、完成！
やべぇ、予想に反して最初からなかなか良いのができた。。。
しかも、いろいろ考えて手を動かしてモノ作る作業、楽しすぎるｗ
なんやかんやで1回目で、48cmの塔ができました。
いちおう4チーム中、48cmが2チームあって同率TOPでした。他の2チームはタワーにならず、記録無しです。
■１回目の振り返り2回目に入る前に、1回目の振り返りタイムが取られました。
んでウチのチームは、2回目のチャレンジでもう一段上積みしようという作戦を検討しました。
あと、2回目やる前にマシュマロチャレンジに関する動画を全員で見ました。
TEDの「トム・ウージェック：チームとタワーを創造せよ」という動画です。
高学歴なチームの平均が、幼稚園児の平均に負けてたりとか、興味深い内容が非常に多いですねー
幼稚園児はまずマシュマロを一番上においてから、次々と試作を始めるので、自然と出来の悪い試作品を何回も修正することになるとのこと。
これって、まさしくアジャイルの概念そのまんま。あと、プレゼンの勉強にもとても良い動画ですね。
■２回目1回目に作ったタワーは破棄して、もう一度最初から18分間でチャレンジです。
もう一段足すため、スパゲッティを1/3と2/3に分かれるように切って、正三角形の枠を２つ追加しました。
あと、模造紙に設計を図示しました。これが結果的に良かったように思います。
作るべき塔の設計図が可視化されたことで、3名の方向性が合ったので。
途中、スパゲッティが折れるアクシデントがありましたが、代替を用意して補修したりしながら、時間内に完成。
やべぇ、１回目よりも更に良い塔が出来ちまった。。。しかも残り３分くらいまだ時間余ってるし。
と余裕ぶっこいてたら、３分前に完成してしまったのが命取りに・・・
頂上のマシュマロの重さにより塔が傾いてきて、タイムアップ直前に倒壊。
結局、２回目は記録無しに終わりましたが、完成時点は約70cmでした。んでも作業が楽しすぎてワロタ。
■振り返りKPT方式で振り返りをやりました。
前述した設計図がホワイトボードに書いてあるんですが、これが結果的に良かったのかも。（作：@s_kic 氏）
可視化したおかげで、全員が同じ方向を向いたというか。
あと、土台、大事。
アジャイルでいうと初期段階のアーキテクチャ設計に該当するかと思いますが、やっぱ大事。
アジャイルサムライのインセプションデッキで言うと「解決案を描く」に該当するかと思います。
あと、2回目の成功を目指して1回目は試作に当てた、というチームがありましたが、道場主の
「プロジェクトは1回きり。同じプロジェクトは2回と無いので、1回目を捨てるのはダメ」
という意見も出ました。確かにそうですねぇ。
あと１回目に失敗したチームは、２回目のチャレンジで、1回目に成功したチームの構造を目指す傾向があるように感じました。
要するに、1回目に失敗したチームは、2回目の設計方針が1回目成功チームの設計方針を超えられない。
ということで先行者利益ってのも大事なんだなぁ、と感じたり。
あと、他のチームの振り返りからは以下のような意見がありました。
■1回目はどういう構造にするか考えすぎて、試す時間がなかった
■マシュマロを最後に刺したら壊れた
■2回目は、マシュマロを置くことを前提に高くしようとした。トライ＆エラーが2回目では出来てよかった。
■1回目は試作の時間と割り切った。2回目で高いタワーが作ればいいや、という指針。
■1回目の振り返りで「Simmple is Best」とかチームで言ってたのに、2回目になるとみんな足を長くとか作り込み始めて、最後に倒れてしまった。
■マシュマロチャレンジは「プロトタイプ」というよりは「チームビルディング」だと思った
■ビアバッシュ最後にみんなでKPTやって、いつも通りビアバッシュタイムになりました。
毎回思いますが、ピザありビールありおつまみありで、よく1000円でこれだけできるなぁ、と。
赤字になってるんじゃなかろうか。
前のホワイトボードで道場主さん＋数名で、アジャイルを導入するしないの対比に関するディスカッションをしてました。
私は遠くから眺めてただけなんですが、周りの人に聞いてみるとどうやら「クラウド」と呼ばれるTOCの対立解消ツールを用いて議論していたらしい。
「クラウド」は対立構造を明確にしたり、対立を解消したりするのに用いられる手法だそうで、以下の書籍で取り上げられているとのコト。
全然知らんかった。というか、「クラウド」なんて単語、紛らわしすぎる。
ググってもあっちのクラウドばっかヒットして、全然ヒットしないし。
ちょと勉強してみようと思った。
★感想：マシュマロチャレンジ、アジャイルうんぬんは抜きにしても楽しいゲームですなー
やはりエンジニア魂は皆さん持ってるので、モノ作りしてると生き生きしてるというか、自分もすげー楽しかった。
といいつつ、アジャイルに関する概念も学べたりして、一石二鳥で良いプラクティスと思います。
最後に講師を担当してくださった野村さん、森野さんはじめ、道場主さん、スタッフの皆さん、入念な準備と楽しい時間の提供ありがとうございました。マジ楽しかったです。
2013/2/15(金)「Developers Summit 2013」に参加してきました。
公式サイト
http://event.shoeisha.jp/detail/1/昨日は以下のセッションに関するメモと感想を書きました。
【15-C-5】ディシプリンド・アジャイル・デリバリー～エンタープライズ・アジャイル実践ガイド～今日は以下のセッションについてメモと感想を書いてみる。
【15-A-7】ワンクリックデプロイ ～いつまで手でデプロイしてるんですか～■アジェンダ
http://event.shoeisha.jp/detail/1/session/41/■発表資料
■最初に書籍の紹介。吉羽さんが著者の一人となっている以下書籍が先日発売になったとのこと。
ちなみに、私はちょうど２,３日前にAmazonで買いました。
デブサミの書籍コーナーで買えば10%引きだったので、ちょと後悔。。。
■オレゴン大学の実験
参考：
http://itpro.nikkeibp.co.jp/article/COLUMN/20080828/313626/→ 期待のマネジメントに失敗している。これが今の状況。（作ってみなきゃわからない状況）
■システムの機能の利用割合
・まったくつかわないが45%
・ほとんど使わないが19%
→ 合計64%が使われない。
→ 実際は、作成しようとする機能の1/3で良いことになる。（コストも期間も1/3でいける）
■「トヨタ生産方式」は名著。７つの無駄を定義している。 → 64%が、作りすぎの無駄。
■例：上司からの依頼「カッコイイ資料を作ってくれ」
→ 加工の無駄
→ 普段の開発で無駄を無くしていかなければならない。
■不確実性コーン
最初の時点の見積もりは当たらない。
■WFの問題
時間がかかりすぎて、出来た頃には要求が変化している。そもそも要件が合っていないことがある。
■よく見かける光景
・結合試験で重大な問題がでてくる
・受け入れ試験でニーズ不一致が判明
→ 多くのリスクが後半になって顕在化する。顕在化した時点では取り返しがつかないのが従来型の欠点。
■アジャイルマニフェスト
・顧客満足度を最優先
・マーケットに製品を早期に投入して投資を回収し利益に結びつける必要がある
■最も価値をがあるものを作って、フィードバックを受けながらプロダクトを成長させていく必要がある。
→ これらができていると「アジャイル開発ができている」と言える。
■平鍋さんの有名な記事
アジャイルの「ライトウィング」と「レフトウィング」 → 今日は「ライトウィング」について話をする。
■毎日何回も本番環境にデプロイできていると、お客さんに継続的に価値が届けられる。
Amazonは一時間に1000回以上デプロイしている。
■自分たちのプロセスは自分達で進化させるしかない
・製品そのものをアジャイルな状態に保つ
・技術的負債を少なく保つ
■チームビルティングも大事だが、製品がよくならないとダメ。
■継続的デリバリーの原則 １．ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。
２．すべてを自動化する
３．難解なことや苦痛なことを繰り返し行い自動化の方法を考える
４．全てをソースコード管理システムで管理する
５．完了は「リリースされたこと」を意味する
６．品質を作り込む
７．すべての人にリリースプロセスに対しての責任がある
８．継続的に改善する
■継続的デリバリーの４プラクティス １．バイナリは一度だけビルドする
２．すべての環境にデプロイするのに完全に同一のメカニズムを使う
３．デプロイメントでスモークテストを実施する
４．何か問題が起こったらラインを止める
ここで「バイナリは一度だけビルド」の意味がよくわからなかったのでググッたら吉羽さんの記事がヒットしたｗ
[Agile]継続的デリバリの8つの原則http://www.ryuzee.com/contents/blog/4172わかりやすい解説付き。
■あたりまえだが、テストを自動化しなければならない
→ テストできてないとデプロイはできない。
→ アジャイルじゃなくてもテスト自動化は必須。
→ 小規模リリースのたびに手動でテストすると、コードベースが大きくなるにつれてテストコストが膨らむ。
■どういうところを自動化するか？
→ 自動化されたテストの損益分岐点を考える必要がある。
→ ２、３回の手動テストやると損益分岐点を交差することがほとんど。
■問題は早めに解決する。早く見つけて早く直す。
■デプロイのたびに人手でテストするのは無理。なので、自動化が必要。
→ テストしていないものを目をつぶってデプロイしてはいけない。
→ 清水の舞台から飛び降りるようなリリースはするな。そうならないための仕掛け作りが重要。
■アジャイルテストの４象限
・単体テストとコンポーネントテストは自動化する。
・探索的テストあたりは人手を使うしかないでしょう。
■自動テストに求められる特性
・繰り返し可能
・独立性
・自己検証
・簡単検証
■何をもってデプロイしてよいかの、完了の定義が必要。
→ 完了の定義を作り、何をもって出荷可能かを定める
→ 全部を短い間隔でできれば頻繁にリリースできる。
→ こーゆうのをやるのにXPのプラクティスを利用すればよい。
■CIサーバ
・
プロジェクトの初期での段階でコードがなくても構築する ・コードのメトリクス取得や静的解析は初期から継続的に実施
■CIアンチパターン
・頻繁にバージョン管理システムにコミットしない ・CIでテストを通すために手作業の準備が必要 ・本番環境やステージング環境と大幅に環境が異なる ・etc
■ソースコードのバージョン管理
・
コードの共同所有の原則への理解（あなたのコードだからいじりません、はダメ） ・リリースした際に、前のバージョンに即座に復元できるか（DB含む）
・etc
■DBスキーマの管理
データベースのスキーマの状態とリリース状態を関連付けることによって再現可能にする
■ソースコードを使ってマイグレーションを行う。
→ 設定じゃなく規約
■環境構築の自動化
・Chef ・・・ Ruby製のシステム管理ツール。環境構築の自動化に使える。
■VagrantのSandobox機能で、何度も環境の変更をrollbackできる。
■ゼロデプロイ
・プロジェクト最初に、デ（プロイするものがなくても）デプロイを自動化する ・デプロイが失敗した場合にロールバックできるようにする
■組織のアジリティを高めないとダメ。変化をしないとゆるやかに死ぬ。
■まとめ
・ビジネスのために継続的に継続的に成果を届ける
・そのためにはAgileなやり方が必要
・テスト自動化は必須
・常に出荷可能な状態を保つ
・
デプロイや環境構築も自動化・改善をずっと続ける
★感想：聴講時に取ったメモに加え、講演スライドの写経も兼ねて書いてみた。
私も今の仕事で、Jenkinsを使って自動ビルドと自動単体テストを実行してて、Subversionと連携させてます。
なので、この話は自分の仕事に直結してて大変興味深かったです。
特に「コレはいい！」と思ったトコは太字下線にしてます。
吉羽さんの講演は以前、アジャイルサムライ横浜道場の特別編でもお聞きしましたが、話に説得力がありますね。
前回の時は「改善しようとする態度重要」という言葉が印象的でした。
今の仕事で自動化が不完全なところがあるけど忙しさを言い訳にして放置プレイにしている部分もあるので、反省。。。
ちょと時間がとれたら、徹底的に自動化してみたいと思いました。手を動かすこと重要。
大変役立つ講演を聴講できてとても満足なヒトトキでした。
2013/2/15(金)「Developers Summit 2013」に参加してきました。
公式サイト
http://event.shoeisha.jp/detail/1/場所は目黒雅叙園です。
参加者は、どのくらいだろう・・・？ 1000名は超えていたのではないでしょうか。
ちなみに2/14の終日と2/15の午前は仕事の都合で参加できなかったので、2/15の午後のみ参加です。
やっぱ、午後だけでも参加して良かったとつくづく思いましたねー。素晴らしいイベントでした。
んで私が聴講してきたセッションについて、何回かに分けてブログにメモと感想を書いてみようと思います。
今日書くのは、以下のセッションについて。
【15-C-5】ディシプリンド・アジャイル・デリバリー～エンタープライズ・アジャイル実践ガイド～講演者は日本IBMの江木さんです。発表のアジェンダは以下。
http://event.shoeisha.jp/detail/1/session/55/発表スライドはこちら。
■『Disciplined Agile Delivery』が去年の５月に出版された。（英語版）
略称はDAD（ダッド）。
■DADの著者は、書籍「データベース・リファクタリング」の著者でもあるスコット・アンブラーらしい。
ちょと驚きでした。私、この本の読書会に参加しているのです。
■DADの日本語版がもうすぐ出版される。今は10人くらいで翻訳している。
■タイトルのディシプリン（Discipline）とは？
→ 意味は「作業分野、鍛練、規律、体系化」
→ どう翻訳するか議論になった。
→ 翻訳の際は、文脈を見ながら訳していくことにした。
■鍛練を積みながら秩序を上げていきましょう、というのがDADの趣旨の一部。
■DADは既存のアジャイルのプロセスを体系化している
■上司からアジャイルやれ、と言われた場合どうしますか？
→ おそらく、なんからの勉強をしたはず。今だと「アジャイルサムライ」とかかもしれない。
→ これだけを読むだけでアジャイル開発ができるかというと、もっと勉強が必要。
例えば「アジャイルな見積りと計画作り」とか「継続的デリバリー」とか。
→ 片っ端から読んでいくとすぐ何ヵ月も経ってしまう。
■プロジェクトとしてアジャイルを適用する段階になると、何と何を組み合わせるか、どのタイミングでどのプラクティスを使うか迷うことが多い。
→ そこでDADの出番。
→ DADは作業の分野に応じてプラクティスを体系化している。それが特徴であり、価値かなと考えている。
■DADが取り込んでいる手法
・技術的なプラクティスはXPから取ってきている。
・運営のプラクティスははスクラムから取ってきている。
・Leanとかカンバンの考えも取り込んでいる。
■DADは大規模・中規模で使われてきたユニファイドプロセスも取り込んでいる。
■DADは、ライフサイクル全体をカバーしている。
■DADは、スクラムの運営にのせる前の段階と後の段階に、フェーズを設けている。
・前の方は「方向付けフェーズ」と呼んでいる。
・後ろの方は「移行フェーズ」と呼んでいる。
・真ん中は「構築フェーズと」呼ぶ。
■方向付けフェーズ
このプロジェクトでは何を解決するかを合意するフェーズ。
あと、初期のアーキテクチャを決めることも重要。
■移行フェーズ
リスクを押さえるためのフェーズ。アジャイルやスクラムで用意された工程ではない。
■DADはプロジェクト全体のライフサイクルを規定している
■DADは既存の手法に比べてエンタープライズレベルを意識している点で違いがある。
■エンタプライズは規模や人数が大きいだけではなく、既存のシステムがあったりとか、チームが同じ場所で作業できない状況にあったりとか、利害関係者が多かったりとか、コンプライアンスのために制約を受けたりとか、
こーゆう現状におかれているのが一般的。
→ この状況でやっていかなければならない。この点ををDADは認識して、フレームワークを提供している。
■主流のアジャイル手法は、一般的な規模のプロジェクトに対し十分な手法を提供していない。
それに対しDADは、これまで嫌っていたカバナンスとかモデリングも、エンタープライズを考慮して一定の厳格さを認識している。
■更新版アジャイル・マニュフェスト
スコットアンブラーは従来のマニュフェストとを否定しているわけではないが、DADで新たに更新している。
・「動くソフトウェア」じゃなくて「動くソリューション」
・「顧客」じゃなくて「利害関係者」
■日本の特徴として、POがかちっと一人に決まらない。多くの利害関係者を想定して進めていく必要がある。
■更新された12の原則+３の原則
一例：定量的なビジネス価値こそが進捗のもっとも重要な尺度です
■新原則
組織のエコシステム内のアセットを促進、進化させ、これらのアセットに責任を持つ人々と強調します。
■江木さんがDADを読んだ感想
→ エンタープライズに限らず、ちゃんとできるプラクティスがやっとでてきたなというカンジ。
■経営層はアジャイルはアテにならないな、と思っているが、それをうまくやっていくプラクティスがやっと出てきたと感じている。
■日本語版は６月の予定。翻訳者の会社もバラバラだが、共感した人が集まって翻訳中。
★感想：なぜこのセッションを最初にブログに書いたかというと、理由は2点あります。
・今年のデブサミで一番最初に聴講したセッションだったから。
・ウチの会社が提唱しているアジャイル開発手法にそっくりの内容だったから。
特に後者ですが、ウチの会社で提唱しているアジャイル開発手法とそっくりで、かなり驚きでした。
ウチも日本IBMさんと同様、大手SIerですが、やっぱ考えることは似るものなのか。。。
ということで、書籍の発売が待ち遠しいです。即購入して読みたい。
１章のみサンプルでPDFが公開されているので、ダウンロードしました。これから読んでみます。
サンプルPDF
http://codezine.jp/special/dadbook明日以降も聴講したセッションを１つづつ書いてみます。
デブサミ、この規模と質で無料なんて最高すぎる。運営者さん、ありがとー
2013/2/12(火) 「エキスパートPythonプログラミング読書会 第二期 14」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/1727/Togetter
http://togetter.com/li/454750以下の書籍をターゲットとした読書会なのです。
場所はいつもの目黒、バリストライドグループさんです。
参加者は主催者さんいれて10名くらいでしょうか。
今回は「12章 最適化: 一般原則とプロファイリングテクニック」が範囲でした。
いちおう予習してから参加しました。以下、予習メモ。環境はUbuntu 12.04 ＆ Python2.7です。
■P.329 Gprof2Dotを使ってプロファイリングの結果をdotグラフに変換するwgetでgprof2dot.pyを取得後、実行してみようとしたらコケた。。。
どうやら本にも書いてあるようにGraphvizが必要となるようで、apt-getで取得する。
んで再度gprof2dot.pyを実行して統計情報ファイルを読み込ませると、ちゃんと画像ファイルが生成されました。
■P.337 Guppy-PEというメモリプロファイラのインストールと実行まず、easy_installでGuppy-PEのインストールを試みると、Python.hが無いといってコケた。。。
ググってみると、どうやらpython-devというものが必要らしいのでインストールしてみる。
再度、easy_installでGuppy-PEをインストールしてみると、警告を発しながら今度はコケずにインストールできた。
で、Guppy-PEのhpyという関数を使おうとしてみると、またコケた。。。
どうやら _PyLong_AsScaledDouble というシンボルが見つからなかったのが原因らしい。
このシンボル、インストール中のログにも警告で「暗黙的な宣言です」と出てたし。
このあと、easy_installではなくtar.gzを落としてきてソースからインストールしてみたりしたのですが、やっぱりうまくGuppy-PEを使えるところまで持っていけませんでした。
あんま時間がなかったこともあり、この時点で写経は保留し、勉強会で質問してみました。
その際は、清水川さんが実際にGuppy-PEのインストールを試してくださったのですが、Python2.6でやるとOKで、Python2.7だとNGでした。ちなみに私の環境はPython2.7でした。
やっぱeggのファイル名にも2.6という単語が入っていますが、Python2.6じゃないとダメそうです。
Pythonは2系と3系でだいぶ異なりますが、リビジョンの差異でもこーゆーことあるんですねー
こっから、勉強会での書き殴りメモ↓ 性能やプロファイラの話が中心です。
■Eclipseも起動は遅いが、起動した後は早い。起動は1回だけなので、ここを早くしようと頑張っても嬉しくない。
同様に、Webアプリケーションの起動時間を早くしようと頑張るのも同様、あんま嬉しくない。
■Pythonの場合、モジュールのグローバル変数へのアクセスは、ローカル変数へのアクセスより遅い。
（C言語とは異なるので、グローバル変数を使用して高速化しようとするのは無意味）
■2章で出てきたリスト内包表記を使うと、Pythonが早いコードにコンパイルしてくれることがある。
ただしソースコードの可読性を落とすのは良くないので、バランスが大事。
■Pythonでも +演算子による文字列連結は遅い。
(Javaも1.4までは遅かったので+ではなくStringBufferを使ったりしていたのと同件）
ループ内で+演算子で連結するのではなく、append関数でいったん配列に入れて、最後にjoinする方が早い。
■最近はUSBのシリアルI/O転送はソフトウェアでCPUパワーを使ってやったりする。
■Decimalで少数20桁の処理しようとすると数時間かかった。
→ DecimalからDoubleにしたら数倍早くなった
■Ubuntuはライセンスの都合上、apt-getでプロファイラがインストールできない
■Pythonのプロファイラのマニュアル：
http://docs.python.jp/2/library/profile.html■-mオプションについて。
-mオプションを使うと、Pythonで実行できるモジュールで、かつmain文があれば実行できる。
【例】
[akanegasaki@ ~/python/expy/section12]$ python -m zipfile -h
Usage:
zipfile.py -l zipfile.zip # Show listing of a zipfile
zipfile.py -t zipfile.zip # Test if a zipfile is valid
zipfile.py -e zipfile.zip target # Extract zipfile into target dir
zipfile.py -c zipfile.zip src ... # Create zipfile from sources
PCにPythonがインストールされていれば、解凍ソフトがなくても上記のように-mオプション使ってZIP解凍できる。
■Pythonの-m指定で便利なモジュール類を紹介しているサイト
http://www.freia.jp/taka/blog/766/index.html http://answer.pythonpath.jp/questions/506/python-m■cProfileで結果を出力すると、abc順で出力される。
ただし別のディレクトリにある同じファイル名も隣に表示されてしまい、見分けがつかない。
■pystoneは関数の処理速度を計測するには使える。
逆に、お客さんから「1秒以内のレスポンス」と言われた場合の計測には使えない。
■いつもpythonコマンドを実行すると、実はシンボリックリンクが貼られていて、python2.7というコマンドが起動されている。
■以下のコマンドでPCのpystone値が計測できる。
python -m test.pystone
■Pystoneで自動テストをやる際に、pystone値で上限をassertするスクリプトを埋め込んでおけば、リファクタリングの際に劇的に性能が悪くなった場合とかに検知できたりする。
■JPythonとCPythonではメモリの開放タイミングが異なる。
CPythonは参照カウント方式で、JPythonはマーク・アンド・スイープ方式。
（このへんはググったらwikiに載ってた：
http://ja.wikipedia.org/wiki/Python）
★感想：今回もいろいろ有意義でした。
ケントベックの言葉、なるほどー、と思いましたね。
"まず動かす、次にそれを正しくする、最後に速くする"誰のための高速化か、を常に意識するのも大事です。
あとPystoneという概念が出てきましたが、こーゆう環境に依存しない性能値の概念は、他の言語でも大事だなーと感じました。
あと今日はビアバッシュではなく外に飲みに行くことになりましたが、私は22時からオンライン上で別件の用事があったのでお先に失礼しました。
次回はビアバッシュとLTタイムがあるといいなぁ。
最後に講師の清水川さんを始め、運営者さん会場提供者さん、皆様ありがとうございました。
テーマ:プログラミング - ジャンル:コンピュータ
2013/2/5(火) "アジャイルサムライ読書会 横浜道場 「現場で実践する」"に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/2590以下の書籍をターゲットとした読書会なのです。
場所は横浜のアットウェアさんです。参加者は20名くらいでしょうか。
この日は8章「アジャイルな計画づくり：現実と向きあう」の8.7節「現場で実践する」から開始しました。
ちなみにウチのチームの模造紙はこんなカンジ。
以下、チームでの議論や最後の発表で他チームから出た意見で気になることを書いてみる。
■P.179の上から3行目の文章
「これを当初の計画と現実の状況との差分として把握しておけば、当初立てた計画自体は何も損ねずに済む。」この意味について。
この直後の文章で弟子とセンセイが「計画は変更されてしまうもの」と言っているので、↑の文と矛盾してて、
この3行目の文章が何を言いたかったのかがわかりませんでした。
ウチのチームでは、ここで言う「当初立てた計画」が「スケジュール」のことではなく、「お客さんがホントに欲しがっているモノ」という解釈をしました。
そういう意味で取ると、スケジュールは変わるけど「お客さんに価値があるものを提供する」という当初の計画は損ねない、という理解になります。
でも、なんかモヤモヤしてたので、最後のチーム発表の時間にこのへんについて参加者さんに聞いてみました。
そこで出たご意見は以下のとおり。
★意見１．
パーキングロットチャートでストーリーをToDo, Doing, Done, Parkinglotの4種に分類した際、やらないことリストに挙がるようなストーリーはParkinglotに入れられる。
ここで、このToDo, Doing, Done, Parkinglotの4個を集めて全体を「当初計画」と見ると、その中の4種の間で移動はあるものの、全体としては変わらないという解釈が出来る。
（当初挙がったストーリーのうちいらなくなったものはParkinglotに入るだけで、全体は変わらない）
★意見２．
計画を差分で管理する。つまり「現在の計画＝当初の計画＋差分」と認識する。
つまり、当初の計画と差分とを合わせて1セットと認識するのであり、当初計画は意味があるものとなる。
そういう意味で、当初立てた計画は損なわずに済むと言える。
■ちなみに「パーキングロットチャート」というものが何者か知らなかったのでググってみたら、書籍「アジャイルな見積りと計画づくり」のP.236に書いてあるのとのコト。
書籍を持ってたので読んでみて、ナルホドと理解した。（↑の「意見１」とは少し違うようだ）
■DBを大きくリファクタリングする必要に迫られた際、ストーリーとして管理すべきか否か？
・DBのリファクタリング自体は顧客にとって価値ではない。
・DBのリファクタリングが本当に必要ならば、顧客にきちんと話して理解してもらうべき。
・ストーリーとして挙げるかどうか悩むくらいなら、挙げて管理したほうが良い。
■「やらないことリスト」にきちんと書いておくことで、お客さんが上げて却下になってしまったストーリーでも、きちんと残して管理しているというアピールになる。（お客さんの意見を尊重しているというアピール）
■CCPMとバックワードスケジューリングに関する話題が出た。
・CCPM： Critical Chain Project Managementの略で、期間短縮を図るためのプロジェクト管理手法の1つらしい。
・バックワードスケジューリング：ゴールを決めて、それを達成するためにはどうするか、と深堀していく手法らしい。
22時からはいつもどおりビアバッシュタイムです。
参加者さんとSeleniumとかRedmineとかをどう使うか、みたいな話をしたりました。
Redmineとかんばんを併用しているプロジェクトでは、ストーリーはRedmineのチケットとして管理し、そのストーリーをタスクに分解したものを付箋に書いてかんばんで管理している、という話をお聞きしました。
管理の方法や粒度はいろいろありますなー
今日も深い議論が出来てよかったです。次回は特別編ということで、また楽しみだ。
最後に道場主さん、スタッフさん、参加者のみなさん、ありがとうございました。
2013/2/2(土)「『JUnit実践入門』写経・実践会 in 横浜 #3」に参加してきました。
connpass（告知サイト）
http://connpass.com/event/1668/Togetter
http://togetter.com/li/448707以下の書籍の勉強会なのです。
参加者は13名くらいでしょうか。
んで、直前に
@t_wadaさんが飛び入り参加されました。
TDD界隈では有名な方ですねー。12月のDevlove2012でも講演を聞いてきて
ブログにも書きました。
t_wadaさんが来るとあって、みなさん先日発売された以下の書籍にサインを貰うべく、買い出し部隊まで結成w
（t_wadaさんはこの書籍の訳者の一人なのです）
主催者の @shinyaa31 さんが近場の大型書店に電話で問い合せ、即席で5冊確保。
んで勉強会中にt_wadaさんのサイン会が開かれました。
こーゆう飛び込みイベント、らしさがあっていいですねー
ちなみに私、この勉強会には今日が初参加でした。
前々からこの勉強会には興味あったのですが、都合が合わなかったりして参加できなかったのです。
今日は11章「テストダブル」が勉強会のターゲットでした。
先日書籍を購入し、8章くらいまでは写経まで終え、今日の午前に11章を読んでから参加しました。
以下、今日行われた議論のメモ。
■11.1節 「テスタビリティを高めるリファクタリング」■お題１： private メソッドはテストするべきか否か？■privateメソッドををpackage privateに変更してテストしている。
package privateだと、公開範囲は最小限にして、テストプログラムを同一のpackageに属させてテストできる。
■privateメソッドは本質的に閉じてるんだから、テストやらなくてもいいでしょ。
■privateメソッドはリリースする機能とは直接関係ないから、テストやらなくてもいいのでは。
■Javaのリフレクションを使えばテストできないことはない。でもリスクになる。参照とか追えないし。
■privateメソッドを使っているpublicメソッドをテストすれば、privateメソッドも一緒にテストできる。
でも、その場合はテストケースが爆発したりするし、引数とかも増えたりすることが多い。
■privateメソッドはpackageプライベートに格上げして、コメントでなぜそうしたか、理由を書いておく。
そして格上げしたコードをそのままリリースする。
■お題２： privateメソッドをテストするとき、その工数は誰が持つの？■リファクタリングの工数は、誰が捻出するのか？という問題。
■永和システムマネジメントの「価値創造計画」という話では、リファクタリングの時間を確保して、
お客さんからその分を請求する、とのこと。
■お客さんを説得して納得してもらうことが必要。
■受託の一括請負だと、難しいところもあるし、認められないこともある。SIerだと難しい。
■自社開発だと、汚い家に住みたくない、というのでリファクタリングをやる。
お題３： 生産性という言葉について■生産性、という言葉は使うべきではない。
■価値は、提供する機能と、それを実現するためにかかった時間、で測るべきでは。
■COBOLの時代なら、生産性という概念は確かにあった。コピペ文化で、書いたもん勝ち。
■工場の製造ラインにあった生産性の概念を、そのままソフトウェアに持ってきたのがCOOBLの時代だった。
■11.2節 「テストダブルとは？」■モックの利用場面が思いつかない。
■モックは、メソッドが呼ばれたか呼ばれてないかをテストするもの。
■メソッドが呼ばれたことを確認するテストをやったことある人いるか？
→ 参加者の中にはいなかった。。。
■「xUnit Test Patterns」という書籍を渡辺さんが訳して、Webから見れる。
■モック／スタブ／スパイの違い
・
モック：
スタブとかスパイの上位互換。
・
スタブ：
そのままだと扱いにくいものはテストを不安定にするので、それを置き換える。
（扱いにくいものを置き換えるためのもの）
・
スパイ：
戻り値がないので確認の方法がない場合がある。そういうのをテストしたい場合に使う。
呼ばれる側のものを差し替える。
■モックは、スタブやスパイの振る舞いも包含している。
■モックには2種類ある。
・
Strict Mock：
言われてないことが発生したら即テストを失敗させる。
・
Lenient Mock：
スタブ＋スパイ。いわゆる、緩いモック。
■先にStrict Mockが登場したので、そちらばかり注目されてる状況にある。
■Strict MockとLenient Mockは、アサーションのタイミングが違う。
・
モック（Strict Mock）：
アサーションを先にやる。最後はベリファイをやる。
こーゆうことが起こるから、後はよろしくな、というスタイル。
・
スタブとスパイ（Lenient Mock）：
作る→テスト→アサーション、の順。
■Strict Mockはプロダクトモックと密接なので、テストのコストがかかるのでは？
→ 実際かかる
■モックの力は強力。惚れ込んで、痛い目をみて、元に戻ってくるくらいがちょうどいい。
■「Fragile Test」という用語がある。何かを変えるとテストがいきなりどかーんと壊れる。
崩れやすい、脆いテストのこと。
■モックを使いすぎると、リファクタリングしたくなくなる。（負の連鎖の不幸）
■モックは、楽にスタブやスパイのように使える。勉強の手間が減る。
■TDDのMLには2種類の人がいる。
・Mockist：
モック急進派の人たち。例えば書籍「実践テスト駆動開発」の著者とか。
・Classicist：
モック古典派の人たち。例えば、Kent Beckとかt-wadaさんとか。
Kent Beckは、書籍「実践テスト駆動開発」の書評で、「これは私の遣り方と違うが良い本だ」と言っている。
（モック古典派だけど、書評を頼まれてモック急進派を褒めざるを得ない状況だったみたい）
■Classicist vs Mockist
http://codebetter.com/iancooper/2008/02/04/classicist-vs-mockist-test-driven-development/ ■モックは設計ツールとしては凄く良い。使われ方を必ず考えるようになるので。
■周りをモックで囲むと、木を見て森を見ず、にならないか？
→ 全体を見えなくするために周りをモックにする、のがモックの役割。
全体を考えてするテストは、モックテストとは別物。なのでそれで良い。
■DIもInjectionされまくる。全体を知らない。そのおかげで依存度が下がり独立性が高くなる。
ただ全体性は見えない。
■そのへんのバランスが大事。自分のちょうどいい間合いを自分で知る。
モックという道具があることを知る。
■テストには濃淡がある。例外的な条件を作りやすいのがスパイとかモック。
■DBを落とした状態でテスト、とか、ファイルシステムの容量あふれたとか、例外条件を作りやすいのがテストダブルの利点。
■代役（テストダブル）が本物と同じということを保証するのは、結局のところ人間。ここが致命的。
■本物の方の仕様が変わったのに、モックをメンテしてないと、モックのテストは通るのに何故か本番でコケます、という事態になる。
→ なので、モックの使いすぎテストだけやるのはダメ。
■11.3節 「Mockitoによるモックオブジェクト」■Mockitoの発音について。
・今日の勉強会では、
「モック伊藤」連発状態w
Togetterに「モック伊藤」ネタがある。
http://togetter.com/li/422376 ・t-wadaさんは「モヒート」と発音してる。
→ モック ＋ キラキラネーム ＋ ググりやすい の3要素がある。
・Mockitoの開発者は「モキート」と読んでるらしい。由来はカクテルの名前。
■Seasar2を使ってるプロジェクトでEasyMockを使ってる。
→ なぜなら、Seasar2からEasyMockを使いやすいようになっているため。
■モックのライブラリは、プロダクションとフレームワークの相性で選定する。
■2002年くらいの頃は、モックを使うときにメソッド名を文字列で書いていた。
→ これからこーゆうメソッドが呼ばれるからよろしく、という書き方。
（「こーゆうの」の部分を文字列で指定していた）
→ IDEでリファクタリングが着いてこなかった。。。
■後発のEasyMockとかMockitoは、インタフェースで書けるようになってIDEで補完されるようになった。
→ これまでの反省から、上手くするコツを取り入れた。
■t-wadaさんのモック歴：
jMockで痛い目 → EasyMock → Mockito
■現在はmockitoが第一候補。
・バランスが良い。
・語彙と考え方が一致してる。
・やりすぎてないところがいい。
■モックライブラリを選ぶコツ
・語彙を理解して実装されているか
・モック、スパイ、テストダブルという語彙がライブラリ名に現れているか
■モックが高機能になるほど、レガシーコードがテストできるようになってしまう。
→ レガシーコードを改善しようとする意識が働きにくくなるという負の面がある。。。
■正統派モックライブラリを使うのが良い。魔改造なのは用途限定で。。。
■プロジェクトにモックを導入しようとしてみた。
→ 比較的上手くいっていて、メンバーが結構学んでくれた。
→ なぜなら、JUnitでテストができなくて困った思いをモックが解決できると知ったから。
→ テストが成長するのと同時に人も成長する。
■Mockistのマップがある。
■書籍「レガシーコード改善ガイド」 其の壱
p.12, p.14, p.17あたりに、ユニットテストのスコープを定義している。
（これはユニットテストで、これはユニットテストではないという区分け）
→ ちょっとやりすぎな気がする。。。
■書籍「レガシーコード改善ガイド」 其の弐
テストのスピードについて言及している。
（～以上時間がかかるのテストは、ユニットテストではない、と言ってしまっている。）
→ でも、最近はスピードは金で買う時代。
スピードがユニットテストの判断基準になることは減ってきている。
■モックを作ると、対象特有の動作が検知できなくなることがある。
例えばDBをモックに置き換えると、DB特有のエラーが検知できなくなる。
■ネットワークアクセスはモックやスタブにする。あとは特殊な環境も。
■@sue445 さんによるLT「TestCode Refactoring Using ExternalResource 」 ■継承を使ってSetupとかTeardownとかはやらないほうがよい。
■代わりに、@ruleを使って初期処理・終了処理を抜き出すべし。
■JUnit3の時代だと、継承は避けられなかった。
■JUnit4からJunitの世界に入る人は、継承をそんなに使わないのが当たり前になる。
■@t_wadaさんへの質問タイム■11.1節のお題「private メソッドはテストするべきか否か？」に関して■privateメソッドはテストすべきでない。publicメソッド経由でテストできるはず。
■自分にとって大事なprivateメソッドは、別のクラスのpublicメソッドに抜くべき。
■privateメソッドをテストしたい状況は、そのprivateメソッドに責務を持たせすぎでは。
→ 分割していくべき。privateではなくpublicの責務として抜き出していく。
■privateメソッドは、リフレクションとか使ってテストはできるが、やったとしても幸せにはならない。
■11.1節のお題「privateメソッドをテストするとき、その工数は誰が持つの？」について■お客さんにリファクタリングの重要性を説得するための統計資料はなかなか出てこない。
→ 結局は、たらればの話になって、感覚的な話になってしまう。
■プロジェクトへの価値は、機能を予想可能な間隔でリリースできること。
→ このままリファクタリングしないでいくとヤバくなる、ということをお客さんに理解してもらうべき。
■「リファクタリング工数」という言葉が出てきた時点で負けでは。
■リファクタリング自体は価値を産まない。
■リファクタリングはプログラミングの一部としてやる。
■リファクタリングの許可を求めにいって、OKがでることはまずない。
■リファクタリングは日々の作業にまぶして、ちょっとずつやっていく。日々のプログラミングに組み込む。
■自動テストを書くのも、リファクタリングも、プログラミングに入れてしまわないと実行不可能。
■11.1節のお題「生産性という言葉について」■「生産性」という言葉が出た時点で負けかなと思っている。
■「生産性」はコード量ではなく、時間で測る。
■品質が同じものをどれくらいの時間で届けることができるか。
■自分が見積もった量と、実際にできた量がだんだん一致してきた時に、ベロシティは生産性と呼べる。
■出来る人ほどコード量は少なくなる。
■唯一変わらないのは、人間のスペック。
→ 短い行数で、少ない暗記で実現できるプログラミング言語は生産性が高いと言える。
■ファンクションポイント見積もりの方がステップ見積もりの方が良い。
■生産性は、他の人と比べても意味はない。
そうではなく、昔の自分と比べる。その場合は、生産性という言葉はありえる。
■研究開発と製品開発では、生産性はぜんぜん違う。研究開発では製品開発ほどテストは要求されないので。
10倍くらい生産性が異なるので、お互い話がまったく噛み合わない。
■生産性が悪かったのか、見積が悪かったのかは、プロジェクトの最後にならないとわからない。
★感想：上のような熱い議論が約4時間にわたって繰り広げられ、とても濃い時間でした。
あと、勉強会の会場なんですが、ジョジョが全巻置いてあって、私、この日がジョジョでびゅーでした。
次回は少し早めに行って、ジョジョの続きを読もう。。。
テストは書いた分だけ上達する、とは以前t_wadaさんがおっしゃっていましたが、この本だけでもきちんと写経していこうと思います。
あと、goosの写経会もどっかにないかなー。あれ一人でやるの辛いんで。。。
次回開催は3/3の予定だそうで、次も写経して参加しようと思います。
最後に、主催者の@shinyaa31さん始め飛び入り参加の@t_wadaさん、みなさんありがとうございました。
-->
