2013/4/27(土) 「XP祭り関西2013」に参加してきました。
Doorkeeper
http://xpjug.doorkeeper.jp/events/3035Togetter
http://togetter.com/li/494409場所は大阪の鶴見区民センターです。
参加者は１００人以上かな？
ウチの会社、4/27(土)から10連休なのです。年休を1日くっつけて、11連休にしてやった！
んで、4/27(土)に大阪の実家へ帰省したのですが、そのついでにXP祭り関西に参加することにしたのです。
早朝6時23分、品川発の新幹線の切符を事前に購入してたのですが、なんと寝坊・・・ orz
起きた時には既に新幹線が品川から発車してる6時半くらいで、はぎょおおお。。な状態。
んで急いで身支度して出発し、なんとか7時くらいの品川発の新幹線に乗れました。
しかも、自由席はガラガラ。2日前に指定席取った時は、あと2席くらしいか残ってなかったのに。。。
会場に到着したのは10時10分くらいで、10分ほど遅れてしまいました。
・・・と思ったら、開始は11時からだった件。
いや、XP祭りのサイトには10時開始って書いてあるんだけど、なぜか11時開始。
んでも、遅れた私はちょうどよかった。
【出版記念講演】以下の書籍の著者のお2人による、出版記念です。
【出版記念講演１】「アジャイルの夢を現実に！ - プラクティス・プラクティス -」阪井 誠氏／株式会社SRA
以下、スライドにない口頭説明の部分を中心に、メモ。
■アジャイル開発への期待・スライドに「YAGNI」という言葉が出てきた。知らないのでググってみる。
・YAGNI： "You ain't gonna need it"、縮めて YAGNI。
機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則らしい。
■アジャイル開発への障壁いくつか障壁があるが、逃げ道もある。
(1) 契約
・障壁：
請負開発ではスコープを変更できない。全部開発しないといけないので。
・逃げ道：
請負といっても、リリースは１回だけ、とは言われていないはず。
要件が固まってなくても無理やり契約するのではなく、契約を複数にわけて、決まったところから契約すればよい。
(2) 場所
・障壁：
タスクボードがプロジェクトルームに置けない。
・逃げ道：
タスクボードが置けなくても、RedmineとかITSを使えば代用できる。
※ITS = （Issue Tracking System/問題追跡システム）
(3) 開発標準
・障壁：
納品ドキュメントが契約上、減らせない
・逃げ道：
納品までに作れば良い。（開発中は作らない）
■夢を実現する方法・プラクティス導入にも優先順位が大事。
・プラクティスをやることが開発の目的ではない。
・プラクティスが実践できない時は、期待しているものを他の物で実現できればよい。
・不安のままプラクティスを導入するのは信頼貯金に反するのでやめたほうがよい
・忘れていけないのは、黄色のパターンがあること。プラクティスにも相互関係がある。
■アダプタブル・ウォーターフォール・いろんな人の能力を最大限発揮できるようにする改善活動
・１００％アジャイルじゃなくてもよい。
■複数リリース・リリース後の修正が多い時は、一気にリリースしないほうが良い。
・最初にやってみた知見をもとに次の契約をするようにする。（複数契約）
■変化を受け入れて管理する・EXCELで管理やろうと思っても、できることはできる。ある程度まではうまくいく。
・ただ、変更が急に増えてきたりとか、人を投入し始めると、Excelだとしんどくなる。
・負担と効果が半々ならば、チケット駆動でやるべき。
■リスクベースの計画・「最終決定時点」という言葉は、リーンソフトウェア開発の言葉。
■自律的組織と集中・決定してしまう前に、チームのメンバみんなに見てもらうことが非常に大事。
・みんなで意見を出し合って、見積もりを確認しあって、計画を実現できるようにする。
・意見を言うということはコミットしているということ。自分で発言して自分でちゃんとやることが大事。
・サーバーントリーダーシップ（※１）という考え方が大事。
・偉そうにしている人と、本当に偉い人は違う。
・本当に偉い人は、必要な時は手を貸すし、そうじゃないときはメンバにまかせる。
（※１）サーバントリーダーシップ、という言葉を初めて聞きました。以下の記事が参考になるかも。
ITPro：サーバントリーダーシップとは
http://itpro.nikkeibp.co.jp/article/Keyword/20100723/350589/・お客さんから直接メールとかで指示がきたりとか、そういう割り込みを防ぐ仕組みが大事。
■ドキュメントの軽量化・綺麗な詳細設計書は、システムを作った後の作成で許してもらえるなら、後に作る。そうすると手戻りが減る。
■コミュニケーションと情報共有・お菓子を配りながら顔色を見ると良い。
・気を付けないといけないのは、お菓子をもらうと残業しないといけない、と思われてしまうところ。
■難しいプラクティス・請負契約という制約は、段階リリースとか複数契約で逃げるべき。
■まとめお客さんがアジャイルやりたい、と言ってくれた時のチャンスを逃さないよう、準備を整えておくことが大事。
【出版記念講演２】「チケット駆動開発をパターン言語で読み解く」あきぴー氏／XPJUG関西 副代表
以下、スライドにない口頭説明を中心に、メモ。
■「チケット駆動開発」の略称： TiDD （← 今日初めて知った）
■チケットとは・チケットはプロセスを管理するもの
・チケットは手順を書いたものなので、背後では状態遷移図というワークフローが動いていて、それで制御されている。
・チケット駆動開発はメトリクス収集ツールにもなる。
■TiDDの価値観とは・価値観はフワフワしているので、指針がほしい。それがプラクティス。
■プラクティスとは・プラクティスとは、良い方向に開発者を導くもの。
■チケットの粒度・チケットのサイズは、大きくても２～３日で実現できるようにすべき。
■TiDDによるパラダイムシフト・すべてのタスクはチケットとして上がってくる。
・チケットを登録していくと、チケットの枚数や内容をコントロールしていくことになる。これがスコープ。
■No Ticket, No Commit・ソースをコミットする前に、チケットにコミットの理由を書け。
・そうすると、人が途中で抜けたりしても問題なく開発できる。トレーサビリティが重要。
・チケットとソースコードが紐づくことによって、リズミカルな開発になる。
■小規模リリース・１イテレーションで消化したチケット数を数えてみると、各イテレーションであんまり変動がない。
→ イテレーション単位の平均消化チケット数がベロシティに対応すると考えている。
・メトリクスを貯めて振り返りで見てみるとおもしろい。
■開発のリズム・リズムがあるからこそ楽しい。これはチケット駆動開発をしてみないとわからない。
・持続可能なペースでしか開発しない。
■TiDDは自発的行動を促す・チケット駆動開発の良いところは、ツールの環境を作ってあげると人が勝手に育つとこ。
・従来はガントチャート作ってスケジュール管理したりして、上から目線だった。
・毎朝チケットを確認するようにすると、自分がどのくらい作業できるかを把握できるようになる。
→ 教育的な効果がある。
・社会人１～２年目でも新米リーダーでも、チケット駆動開発をやることでリスク管理とかを学んでいく。
■まとめ・チケット駆動開発はアジャイル開発の１つだと言いたい。
・パターン言語でそれをうまく表現したい。
・複数のプラクティスを組み合わせるとうまくいく。
→ プラクティスの組み合わせ方、パターンマップを作りたいと思っている。
・組み合わせの相乗効果を見たいと考えている。
■【アジャイル屋台】もう一つの会場は「和室」です。ここでは「アジャイル双六」なるものが開催されてました。
ということでお昼休みに覗いてみました。
和室に入ってみると、アジャイル双六が。
無料配布もされてたので一式、戴きました。感謝。
あと電源とかも提供されてて、ノートPCの充電とかもさせていただきました。
【講演１】「初めてのアジャイル開発」- 我々はどのようにアジャイルを実践したか-アジャイルサムライ読書会at大阪道場 by @kitora_naoki氏
発表スライド、公開されるかな。。？とりあえずメモ。
■アジャイルをやってみた理由：・やってみたかった
・このメンバならやれると思った
→ モチベーションが重要。
■コミュニケーション・仕事だけでなくランチとか飲み会が重要になってくる。仕事の場以外で、違う会話がでてくる。
→ 親交が深まる。
・いつもはお弁当だけど、月曜だけはみんなと外に食べに行く。
→ プロジェクトがうまくまわるようになった
■スクラムを選んだ理由・独自の方法を編み出すのは上手いやり方ではないかな、と思った。
・上手くいくやり方があるなら、そこに乗っかるのがいいかなと思った。（巨人の肩に乗る）
■インセプションデッキ・是非やるべきと思っている。
■3人の石切り工の話・「3人の石切り工の話」自体は以下とかが参考になるかも。
http://switchdec.com/peter-drucker-quarrier-three-1687.html・モチベーションがすごく重要。何のためにシステムを開発するのかを意識すること。
・4人目の話があってもいいのでは。
→ 4人目：「安らぎの場を提供するため、心の拠り所を作っているんです」
・システム開発も同様、モチベーションが大事。
■デイリースクラム・誰かへの報告になると、形骸化していく
・問題解決は別の場でやる。
・いつ、どこで、誰と、問題解決の打ち合わせするのかだけをデイリースクラムで決める。
■TDD・実装してからテストしようとすると、テストしにくいなぁ、と気づくことがある。
→ それで手戻りとか発生することもある。
・テストから先に書くと、そんなことにはなりえない。
・JUnitでテストをやるとき、テストメソッドは日本語でもいいと思っている。
■振り返り・いきなりKeepとかProblemとかを出そうとして、出てこないことをよく見かける。
・そんなときは、Good, Badを事実ベースで洗い出してから原因・問題分析すると良い。
・いきなりKPTのあのフレームを埋めようとしないほうがよい。
■継続的デリバリー・デプロイお願いします、とか頼まれて作業が中断されると、お互いに気を使うし、効率もよくない。
・あの人じゃないとリリースできない、とか属人性が発生すると良くない。
・本番に自動でデプロイできることはSIだと必須ではない。一日に何回もデプロイすることはない。
→ ただしステージング環境までは自動デプロイの仕組みを作っておく。
【講演２】「京アジャ 春の特別出張編」京都アジャイル勉強会
講演者は京都アジャイル勉強会のお二人です。
こんな用紙が配布されました。参加者みんなでエレベータピッチを作ります。
んで講演者が上司役になり、参加者が壇上に上がって「アジャイル開発を導入したい」と実際にアピールする実践の場が繰り広げられました（笑
これが盛り上がりましたねー。つーか、壇上に上がっていく参加者たち、アピールうますぎだろ。
関西人パワーを垣間見た気がする。いや、私も実家は大阪なんで、関西人なんだが。
■最後のまとめ・エレベーターピッチは、誰向けなのかによって変わる。
・チャンスは突然やってくる。でも、いきなりアピールするのは難しい。
・でも、素振りならひとりでもできる。チャンスに備えて素振りをやるかどうかは、あなた次第！
---
漫才のようなヒトトキ。笑いが溢れて、大変好評でした。
【講演３】「プラクティスって何だろう。」スクラム道関西
以下、スライドにない口頭説明の部分を中心に、メモ。
---
■プロダクトオーナーって、ホンマたいへん！
・責任は一人で追うが、タスクは一人で負う必要はない
■デイリースクラム
・みんながスクラムマスターを見て話すのはダメ。
・スクラムマスター中心でやるものではない。それだと報告会になってしまう。
■レビュー
・チームが頑張ったのでOK、はだめ。
・アウトプットは厳選に評価しないといけない
■レトロスペクティブ
・チームが改善を選択する。それを繰り返して改善していくことが大事。
・必ずしも問題は深堀する必要はないと考えている。
---
ここからはスクラム道関西の５名が壇上にあがり、参加者から質問を受け付ける質疑応答の時間です。
質疑応答Q1レトロスペクティブで最初は有用な意見が上がって来た。
でも最近、どうでもよさそうなものしか上がってこなくなった。
打開するアイデアあればおしえてほしい。
A1・気分を変えるために、何回か前の振り返りのホワイトボードの写真を持ち出してきて、それについて話してみる。
・飽きたら辞めてみる。振り返りがある時とない時の差がわからないからマンネリする。
→ 良いかどうかわからないのにリソースを投入するのは疲れるだけ。
・メンバを導いてみる。やりすぎると誘導になってしまうが。
---
Q2みなさんがスクラム、アジャイルを始めたきっかけは。
A2・走りながらやるしかないプロジェクトだったから、仕方なくやった。
・長い先のことは分からないので、2週間ずつできる開発方法を探したらアジャイルが見つかった。
・他に方法がなかった。
・デスマを経験して、なんか良いやり方はないかなぁと探してみた。
・「ピープルウェア」と「ゆとりの法則」という本を読んで、今の状況はおかしいな、と思った。
---
Q3スクラムをやって、顧客の感想とかなんかあったか。
A3・お客さんからの一番の感想は「しんどい」。システムって作るのこんなにしんどいのか。
→ 2週間ごとに高いレベルを求められる。
・「やっと、ウチのシステムを作ってる気になった」とお客さんから言われたのが嬉しかった。
→ お客さんはしんどそうだけど、楽しそうにやってた。
---
Q4アジャイル知らない立場の人たちに考え方を伝える良いアイデアがあれば教えて欲しい。
A4・やりかたに特殊なことはなんにもない。子供のやり方に戻す。うまくいかなければ変える。
・キャンプに一緒にいってカレーを作れ、と言う。
→ キャンプでカレーを作るとなると、みんな事前に調べて練習してくる。
→ チームで一緒になんかやってみると、アジャイルと同じなんだ、と気づく。
・朝会、タスクボード、振り返りの3つだけ、2週間だけでもやってみる。
・丸一日、時間をもらって、アジャイルの説明もきっちりして、ワークショップもして、スクラムを体験してもらう。
→ 参加者に、アジャイルっていけそうだね、と実感してもらえるように持っていく。
・ほんとにみんながアジャイルをやりたがっているかを確認したほうがよい。
・やってみると、しんどいけど楽しい、という雰囲気には絶対なる。
・紙飛行機ワークショップとか、マインドを盛り上げていくのが有効かな、と思う。
・チームメンバをアジャイルのコミュニティに誘う。勉強会に一緒に行ってみる。
→ そうすると個性の面白い人が周りにいっぱいいる。外の世界に触れてもらう。そうすると機運が高まる。
---
Q5POが価値をうまく定義できないとき、チームのメンバーってどう助けられるか？
A5・プロダクトバックログはREADYになってないといけない。でもREADYにならないことがある。難しいので。
・POに、水着に着替えて、遊びにいくぞ、と見せつける。
・いずれにせよ、POが要件をバックログに定義できないなら、チームは仕事をしてはならない。
・POがバックログにストーリーを定義できてないなら、仕事が止まっていることをPOにとことんまで見せつけろ。
・本当の価値はPOじゃないと決めるのは難しい。
・仕様をちゃんと作れるようにするのがPOの役割だが、それはチームで救えるところもある。
・POから「相談のってやー」と言われて、チームと一緒に話し合って手伝うこともある。
・POの下に8チームもついてたことがあった。
→ どうしても間に合わない状況になった。
→ 各チームから二人ずつ出して、POチームに投入した。
→ ベロシティが3倍になった。
・仕様が確定してないから適当に作る、は絶対ダメ。
・POとチームがバックログについて話す場で仕様が決まらなかったら、いったんその場を解散する。
→ POに考えさせる時間を設ける。
・無理してプロダクトバックログを書かずに、１回くらい１イテレーションをかけてエンジニアに好きなことやらせる。
→ その際、バックログに技術的負債を返すようなタスクを上げて、2週間でやる。
→ やってみて、その後すごい生産性あがった。
■まとめ
チームが考えて、工夫することが大事。
【ライトニング・トークス】（5名）Eishi Saitoさん
井上 和馬さん
Tatsuya Ishikawaさん
@HIDARI0415さん
@kazuhito_mさん
---
どれも素晴らしいLTでした。内容も良いし、なにより面白い。笑いがある。
ちなみにUstで見れるようです。
http://www.ustream.tv/recorded/32017285最後にXPJUG関西代表の西さんより、閉会のご挨拶。これにて終了となりました。
感想：予想を裏切らない素晴らしいイベントでした。
去年は東京のXP祭りにも参加しましたが、それと遜色ないレベルだと思います。
笑いアリ、感心あり。関西らしらを随所に感じられました。
来年もGW期間に開催されるなら、また帰省を兼ねて参加したいと思います。
惜しむらくは、関西のエンジニアさんとお話する時間がなかったこと。
来年もし参加するなら、懇親会にも出てみたいと思いました。
ワークショップとかもあるといいなぁ。
関西のアジャイルなエンジニアさんたちのお顔を拝見できて、講演も聞けて、満足。
運営者さん、講演者さん、ありがとうございました。
2013/4/25(木) SQLアンチパターン読書会 「ナイーブツリー」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/3682以下の書籍をターゲットとした読書会なのです。
会場は御徒町（湯島）の株式会社アルティネットさんです。
参加者は9人くらいかな。ディスカッションには最適な人数です。
今回も @t_wada さん参加です。感謝！
ちなみに私は前回も参加してきまして、そんとき書いたブログはコチラ。
今日は2章「ナイーブツリー」が読書会のターゲットでした。
■自己紹介2章「ナイーブツリー」の掲示板ネタにちなんで、「自己紹介で、掲示板に関する思い入れを述べよ」と主催者さんからのお言葉。
ここでまさかの @t_wada さんから
「掲示板でネカマデビュー」という衝撃発言（笑
参加者の皆さんも2chやらなんやら、懐かしい掲示板ネタを披露してくださいました。
つーか掲示板ネタって、それで年齢層がわかってしまうという。。。
■2章「ナイーブツリー」の紹介@osa2 さんが2章のアジェンダを作成し、紹介してくださいました。感謝。
@osa2 さんがDropboxにUPしてくださったPDF資料はコチラ。
スライドの背景画像が「枯れた木」なんですねー。まさに、
素朴な木（ナイーブツリー）！センス感じます。
■ディスカッション前のネタ出しディスカッションしたいネタを参加者みんなで付箋に書き出しました。
■ディスカッション以下、ディスカッション時に取った個人メモ。
■再帰構文・OracleのDBは昔から再帰を書けたが、オレオレ構文（独自構文）だった。
・プログラミング言語は再帰が当たり前に書けるのに、DBの世界では再帰は当たり前ではない。
・DBでの再帰は、最近ようやくDBMSがサポートし始めて、できるようになってきた。
・MySQLのストアドファンクションでは再帰ができない。PostgreSQLならできる。（らしい）
・再帰が各DBMSで標準サポートされきるのが良い未来。
■経路列挙（Path Enumeration）の弱点・LIKE句を使わないといけない
・参照整合性を維持できない
■経路列挙（Path Enumeration）とジェイウォーク・経路列挙はジェイウォークの一種とも取れる。（スラッシュ区切りでデータを突っ込むトコが）
・1章でジェイウォークはダメっていってるのに、2章で経路列挙として紹介している。
■入れ子集合（Nested Set）と閉包テーブル(Closure Table)・ミックさんの書籍「プログラマーのためのSQL」に、入れ子集合と閉包集合について詳しく書いてある。
・第4版が5/24に発売される。
・入れ子集合（Nested Set）は「ツリー」ではなく「入れ子」として捉えよう、と言っている。
（第2版か第3版の、29章の図29.4あたり）
・SQLの本では上級者向けだけど、学ぶことはとても多い。
・ミックさんの「達人に学ぶSQL」を読んだ後なら、「プログラマーのためのSQL」もいけるのでは。
■ON DELETE CASCADE修飾子（P.17 下から2行目）・SQLアンチパターンの4章にカスケード削除について書いてある。
・カスケード削除は、参照制約があるデータをバッサリ消すことができる。
・自動的にバッサリ消すのを嫌う人と、嫌わない人がいる。
・参加者で、カスケード削除をやっている方がいらっしゃった。
→ 親の「伝票」テーブルと、それに紐づく「注文書」テーブルの２テーブル間に参照制約を貼っている。
→ 親の「伝票」の方を消せば、それにぶら下がる「注文書」も消える仕組みにしているとのこと。
■物理削除と論理削除・物理削除すると痕跡が残らない。なので削除フラグ設けたりする。
■DBMSの経路列挙（Path Enumeration）サポート・SQL Serverがデータ型のレベルで経路列挙（Path Enumeration）をサポートしている。
・SQL Server 2008に実装されている「hierarchyid型は」、経路列挙モデルをベースにした型らしい。
■入れ子集合(Nested Set)・入れ子集合は、無駄に更新回数が多くなる。（更新量が大きくなる）
・「Nested Intervals Model」という概念があるらしい。
→ 各ノードに整数（Integer）ではなく浮動小数点（Float）を割り当てる、という思想（らしい）。
（整数だと有限なので、小数にすればいいじゃん）
・更新より参照が圧倒的に多くて、かつ参照のスピードが求めれれる時に入れ子集合が有効。
（例：「人事テーブル」とか）
・入れ子集合は、手でメンテは諦めないとダメ。
→ 例えば、テストデータを手で作るのは大変。（手でポインタの数字を数えるとか、無理）
→ 逆に、「経路列挙」は人間に優しい。
・O/Rマッパが入れ子集合をサポートをサポートするかどうかで、入れ子集合を使うかどうかの判断が変わる。
→ O/Rマッパのサポートがある設計を選ぶ。手で頑張るんじゃなくて、まず探す。
（ORマップ・ライブラリの「Active Record」とか「Hibernate」とかはサポートしているらしい）
・入れ子集合はInsertがトリッキーになる。でもワンパターンでいける。
・入れ子集合、本番系でDBがコケたときのデバッグで泣きを見ることがある。（手作業でポインタ追うとか orz）
あと、入れ子が途中で切れちゃって、断続的に空きができてコンパクションするとかする時も。
■閉包テーブル（Closure Table）・閉包テーブルはーブルが２つに分かれる。それが良いところでもあり、悪いところでもある。
・テーブルを２つに分けることで、データと関連を分けている。
・テーブルが２つになるので、データ量は他の経路列挙や入れ子集合に比べてかなり多くなる。
・閉包テーブルは、更新があまり多くない場合に使うべき。
・path_length属性は必須。
■プログラミング言語とDBMSのポインタの違い・データベースは、子から親を辿らないといけない。逆にプログラミング言語だと、親から子を辿る。
・これがプログラミングから先に入った人にとって、DBを後に学ぶとギャップに感じる。
■SQLアンチパターンの付録A・付録Aもおすすめ。
・関係（リレーション）と、テーブル間の関連（リレーションシップ）の違いについて書いてある。
■木構造を使うときのノウハウ・「木構造で実装しよう」というだけだと、考え方が荒すぎる。どういうツリーが適するのかを考えるのが重要。
・
ツリーの名を知ると、ググれるようになる。・
大事なのはテクニックの名前を知ること。そうすると自分が楽できるようになる。・ググってみると、大昔からこの問題に立ち向かってる人がたくさんいることがわかる。
@makopi23 の写経コーナー読書会に参加する前にひととおり写経してみたので、その時のメモ。
ちなみに環境は、OSがWindows7(x64), DBMSがMySQL 5.1.37, DBMS操作用のGUIが MySQL Workbench 5.2.47CE です。
■SQLテーブル作ったりデータをInsertする時に使った自分用SQL。
sqlap_chapter02.txt■2.2.1 隣接リストへのクエリ実行ツリーで直近の親子関係にあるノードをすべて抜き出すSQL文。
■2.2.2 「ON DELETE CASCADE修飾子」によるカスケード削除カスケード削除というものを初めてやってみた。
(1) カスケード削除の実行前
削除前は以下のように7件のデータが入っています。以下のSQLを実行し、ノード４以下のデータを一発で消してみる。
(2) カスケード削除の実行後
ノード４と、ノード４にぶら下がっていたデータがゴッソリ消えました。
■2.5.1 先祖の取得P.21のancestors.sqlをやってみました。
これ、
何故ノード7の 「1/4/6/7」 のデータがヒットしないんでしょうね？勉強会の場でみなさんのお聞きしましたが、解決せず。「キモいよね... orz」という結論で、先に進む。
■2.5.1 葉ノードの挿入P.21の最終行に誤植があります。発表者の @osa2 さんも気づいてらっしゃいましてスライドにも書いてありますね。
私も予習で写経してて気づきました。
【誤】他の行を修正せずに、
非葉ノードを挿入できます。
【正】他の行を修正せずに、
葉ノードを挿入できます。
■2.5.2 入れ子集合（Nested Set）以下はP.23のdescendants.sqlを実行したトコ。
BETWEENでc2.nsleftを間に挟んでいますが、これはc2.nsrightを間に挟んでも同じだそうです。
読書会の場で質問して確認しました。
ここに貼ったSQL以外も写経してますが、貼るとサイズでかくなるので省略。
■感想：今回も密度の濃い、とても有意義な勉強会でした。参加者の皆さんに感謝！
こーゆう読書会があると写経や予習のモチベーション上がりますね。
写経してみるのも大変勉強になりますし、ディスカッションで他の方の経験とか聞くのも刺激的です。
あと、やっぱ @t_wada さんの威力がデカいです。
ホントDBに関する色々な引き出しを持たれていて、大変勉強になります。
特に、以下のお言葉が印象に残りましたねー。
・
ツリーの名を知ると、ググれるようになる。・
大事なのはテクニックの名前を知ること。そうすると自分が楽できるようになる。最後に主催者の @natsu_nanan さん、会場提供の @heroween さん, @inda_re さんはじめ、@t_wada さん参加者のみなさまありがとうございましたー
2013/4/16(火) アジャイルサムライ横浜道場 特別編「宝探しアジャイルゲーム」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/3449以下の書籍をターゲットとした読書会なのです。
場所はいつもと同じ横浜のアットウェアさんです。
参加者は28人くらいでしょうか。盛況です。
今回は特別編ということで、やっとむ (安井 力)さんが開発した「宝探しアジャイルゲーム」をやりました。
ちなみに先日、やっとむさんが翻訳を担当された以下の書籍の読書会にも参加してきました。
場所は同じく、横浜道場のアットウェアさんでした。そんとき書いたブログはこちら。
今回の「宝探しアジャイルゲーム」は、Facebookでは「プロジェクトゲーム (Project Games)」という名称で紹介されているようです。
Facebook: プロジェクトゲーム (Project Games)ゲームはベータ版、またの名を「人柱版」の段階だそうな（笑
ブログに詳細を書いちゃうとネタばれとかもあるかもなので、ゲームの詳細はいったんこのブログでは伏せておきます。
■ゲーム概要簡単に言うと、複数チームで構成される「サービス企業」を作り、企業同士が市場を巡って争う、というゲームです。
今回は6～7人くらいのチームが4つあり、2チームで1社を作ったので、今回は2社が互いに争いました。
四半期ごとにチームでアクションを起こし、それを8回（≒2年分）繰り返して、最終的に価値を多く生み出した会社が勝ちです。
はじめに、ゲームの説明が書かれた用紙が配られました。ココに上のルールの概要が書いてあります。
あと、1チームの人員を「ビジネス担当」と「IT担当」の2種類に分けます。互いに約3人ずつくらい。
ゲームにはオセロの変形型みたいな要素が組み込まれており、「IT担当」はここで「開発」を行います。
あと、市場はこんなカンジ。4種のユーザ層があります。
「IT担当」が開発した製品を「ビジネス担当」が↑の市場で販売し、ユーザを奪い合って覇権を争うことになります。
あと、このゲームにはアジャイル開発を実践するための要素がいろいろ組み込まれてます。
ゲーム性も高く、ゲーム開始から終了までの約1時間強、熱いバトルが繰り広げられました！
■個人的な感想＆振り返り私は「IT担当」だったんですが、オセロ盤が込み入ってきた中盤以降、いかにオセロの石を多くひっくり返して機能をたくさん開発するか、ばっかり考えてしまいました。
開発に没頭してビジネスに目を向けられなくなった悪い典型ですね。。。
手持ちのお金がいくら残ってるか、とか、どの市場を攻めるか、とか、ビジネスに目を向ける心の余裕はぜんぜん無かったです... orz
それに対して隣のチームは、「IT担当」でも「ビジネス担当」と一緒に市場の様子を見ながら戦略立てたりしてて、あぁいいカンジでやってるなー、と感心しきりでした。
あと、稼いだキャッシュをこちらのチームに融通してくれたり、こちらのオセロ盤を覗き込んで助言をくれたりも。
短時間でゲームの本質を掴む頭の回転の良さとか、自分のチームだけでなく同じ会社に属するウチのチームのビジネス状況まで気を配る視野の広さとか、戦略選択のセンスとか、あと心の余裕とか、隣のチーム、ほんとスゲーなぁと思った。
と同時に、その差を見せ付けられて自分のヘボさに正直ヘコんだ。。。
あと変則オセロなんですが、これもかなり頭の体操になりますねー。
２～３先の四半期のことも考えて指し手を考えなきゃいけないとことか、面白いです。
あとひっくり返し方についても、「お！こんな指し方もあるのかー」と気付かされることも数度。
発想を少し転換してみて、思っても見なかった設計方法や実装方法に気付く、という経験をエンジニアならしたことあると思うんですが、そんな感覚でした。
変則オセロ、侮ること無かれ！
一番の収穫は、ITとビジネスを両立できない自分に気付けた点です。悔しいけど。
アジャイル開発では両者のバランス感覚も重要視されますが、ダメダメな自分... orz
自分のヘタれっぷりにかなり危機感を感じたし、もう少しバランス感覚を意識しないとヤバいな、と本気で思った。
あと、頭の回転の遅さにヘコんだ。ルールの飲み込みがかなり遅かった。
ゲーム終わった後、いったいどう振る舞えばもっと成功に近づけたのだろう？と考えることしきりでした。
それにしても、やっとむさんの企画力と行動力は凄いですね。
ゼロからゲームを作って、見事なまでに参加者に価値を提供している。
楽しい空間を作り出している。アジャイル開発の要素まで学習できる。
貴重な経験、感謝！
ゲームの改善点があるとすれば、市場のユーザはコインじゃなくて、人型の紙とかの方がいいかもですねー
あるいは、コインにアニメキャラのシール貼るとか？
キャッシュと誤解させないよう、ユーザ感をもっと出せるといいなぁ、と思いました。
あと、ルールが少し複雑かな？と思いました。ここのバランスは難しいところだと思いますが。
道場主さん、やっとむさん、参加者のみなさん、ありがとうございました。
2013/4/15(月) 「実践反復型ソフトウェア開発読書会 -反復2-」に参加してきました。
DoorKeeper
http://devlove.doorkeeper.jp/events/3438以下の書籍をターゲットとした読書会なのです。
場所は秋葉原のクラスメソッド株式会社さんです。
参加者は10人くらいかな？ディスカッションするにはちょうど良い人数です。
今回は以下が対象範囲でした。
・第4章 構成管理とブランチの戦略
・第5章 再現可能なビルドの実現
以下、読書会でのメモ。
■前回ディスカッションのとある一節について今回、著者の津田さんが参加してくださいました。感謝！ちなみに前回は残念ながらご欠席。
んで私はというと前回の第１回も参加しまして、ブログにもそん時のメモ書きました。
「実践反復型ソフトウェア開発読書会 -反復1-」に参加しました http://makopi23.blog.fc2.com/blog-entry-58.htmlこの前回ブログ、著者の津田さんが読んでくださってたようでした。
拙い殴り書きメモでお恥ずかしい。。。
んでブログの中に書いた、前回のディスカッションで出た以下のフレーズに意義あり！とのこと。
「チャンピオンやドライバに相当する人が自発的に出てこないとマズイ」前回ブログの、下の方に書いてあるやつですね。
これは前回のディスカッションで
結論として挙がったものではありません。
あくまでディスカッションの中で出た話の１つとして私がメモに残してた一節です。
この中の、「自発的に」という表現が書籍の意図と異なるようでした。大体、以下のような趣旨です。
---
「自発的に」という言葉に対しアジャイルでも「自己組織化」という言葉があるが、この意味を誤解している人が多い。
ソフトウェア開発において、
・「ドライバ」は、プロジェクトを前を動かし、チームメンバを勇気づける役割を持ち、
・「チャンピオン」はソフトウェアの品質のある側面を守る人であり、
・「コップ」はツールの運用などについて、ルールをチームに周知して守らせる人、
という位置づけである。
ここで彼らが「自発的に」なんでも個人ベースで行動に移せば良いか、というとそうではなく、チームとして役割を全うする必要がある。
行動する上では、当然チームのリーダーが期待するタスクをこなさなければならないし、やりたくないタスクが上から降ってきたからモチベーションが上がらない、やらない、というのはありえない。
そーいった間違った方向の自己実現を、「自己組織化」として誤解してほしくない。
大事なのは、例えばプロジェクトの初期にリードとエンジニアが１対１で会話して、リードが各エンジニアにアカウンタビリティを与えることも１つ。
チームが期待する役割を果たして成果を出すことが重要であり、そこには当然、統制も求められる。
---
といったような内容について、津田さんが説明してくださいました。（資料が手元にないのでうろ覚えな面あり orz）
このときに使った資料、あとで公開されるかな。。。？
■ディスカッション以下、ディスカッションの中で出た話の個人的メモ。
■ネタ出し最初に参加者さん全員で、今日ディスカッションしたいことを書き出しました。
大体、以下のようなネタが挙がりました。
1. 理想と現実のGap
2. CIビルドやってる現場どんなん？
3. ブランチした後メインに戻るコツ
4. バイナリファイルをコミットするかどうか
5. P.98のポートやってます？
6. 4.12節の、ブランチを上手く使うためのプラクティスやってる？
7. 構成管理をやっているロールってチームでは誰？
8. サンドボックスをどういう運用しているか
9. P.73の4.5節の、コミットの手順を唱和する
10. P.128のビルドの手順を唱和する
11. 津田さんコーナー
12. P.108で、みなさんの現場でどんなブランチの切り方をしているか
13. コミットベルやってるか
14. コミットの頻度
15. ルールの運用をどうやっているか。
こっから、１つずつ取り上げて話し合っていくことになりました。
---
■現場で使ってる構成管理ツールについて参加者さんの自己紹介タイムで、現場で使ってる構成管理ツールも合わせて紹介することになりました。
その中で私が知らなかったものとして、以下が挙がりました。
(1) Perforce
・
http://www.toyo.co.jp/ss/perforce/・東洋テクニカさんがサポートしている有償の構成管理ツールらしい。
・Tortoise系のようなエクスプローラ融合型ではなく、クライアントアプリケーションらしい。
・安定している。
・スケールしやすい
(2) Stash
・
http://www.atlassian.com/ja/software/stash/overview・JIRAなど、アジャイル開発系のツールベンダとして有名なAtlassian社の製品。Gitベース。
(3) SourceRepo
・
http://sourcerepo.com/■今の構成管理ツールをなぜえらんだのか？・構成管理ツールはインフラ。一度入れると、乗り換えるのが難しい。
・会社の他の部署やプロジェクトで使ってたりすると、リポジトリごと貰えたりとかもできるし。
・GitとかMarcurialは比較的新しいので、SVNとか使ってる人は乗り換える理由がないのでは。
・無理に新しい構成管理ツールを入れる必要はないのでは。それでコストかかってしまえば意味ないし。
■Perfoceをどういう理由で選んだか？・C/Sで使える。
・VSSよりは安定している。
・変なことも起きない。
・ブランチも簡単にできる。
・PerfoceとRational ClearCaseが候補にあがって、値段の面でPerfoceを選択した。
・Perfoceは1995年に発売された古参の構成管理ツール。当時、ブランチ開発はPerfoceしかできなかった。
・書籍のP.94の3行目にPerfoceが出てくる。エンジニア4人が有名なWeb記事を書いている。
・そのうちの2人が構成管理の話を書いている。
■コミットの頻度について(1) 書籍ベースのお話
・「頻繁にコミットしましょう」というプラクティスを書籍で紹介しているが、誤解を招くと思っている。
・大事なのは頻度じゃなくて一貫性のあるコミット。
・例えば、コミットは１週間に１回でもいい。バグが入らなければ。
・コミットしてからCIでバグを出すんだ、という思想は間違い。
・そうじゃなく、「頻繁な更新」が大事。衝突を減らすことができる。
・「更新」に精神的負担を感じるのは、「更新」が悪いのではなく、「コミット」が悪い。
・更新は頻繁に、コミットは丁寧に。
・意味のある単位でコミットすべき。
・書籍の4章の手続きに沿って、丁寧にやっていただければ、と思っている。
・テストを通したからコミット、ではなく、タスクが終わった時にコミットする感じ。
(2) TDDの観点
・TDDだと、テストが通ったらコミット、次にりファクタリングして、またコミットとなる。
・そのループが細かく回る。なので、コミット回数が多くなる。
・ユニットテストで、自分の環境で緑になることを確認してからコミットをする。
(3) コミットの履歴
・コミットが多いと、コミットの履歴を辿るのが大変では？
・いや、そんなことはない。
・というのは、コミットが頻繁な方が、前回の成功コミットから今回の失敗コミットまでの間の変更が少ないので。
(4) その他
・自分のローカル環境なら、頻繁にコミットして構わない。
・作業履歴を残したいからコミットしたい、という考えは良くない。
・バグがない、ちゃんとしたものをリポジトリに入れるべき。履歴を残すためでは無い。
・頻繁にコミットせよ、という言葉は初心者向けな面がある。大事なのは(1)。
・バグ管理票がないとコミットしちゃいけないと徹底されていた、という経験談あり。
■リリース管理をどうやっているか？・リリースでミスることが多い。手動でやる人はどうやっているか？
・ソースを直した人がコミットまでする、というプロジェクト経験談あり。
→ それって、怖いよね。。。という感想多数。
・チェックアウト時にロックをかける構成管理の仕組みを用いれば、基本的に競合は起きない。
→ この書籍ではブランチフリーズと呼んでいるが、推奨していない。
■構成管理をやってるロールって、チームでは誰？・大きいプロジェクトだと、専任で構成管理担当チームがいた。
→ 24時間体制でコミット申請を受け付け、確認や複数環境への反映などを行う。
■コミットベル使ってる？・参加者は誰も使ってない。
・コミットベルで知らせると、コンフリクトは基本的に無くせる。
・ベルじゃなくて、コミットをトリガーにメールを飛ばすくらいなら、やろうと思えばCIサーバでですぐできる。
■サンドボックスってどんなの？・ここでいうサンドボックスとは、ブランチと対応する作業場所としてのフォルダのこと。
・仮想環境とは限らない。
■理想と現実のGap・新しい人がプロジェクトに入ってきた人のために、構成管理の用語辞書だけでなくサンドボックスの構築手順とかをWikiに書くのが良いのでは？
・構成管理のルールはリードやマネージャが都度、メールで共有したりするのが良いのでは。
・CIでテストがこける部分を赤で放っておくよりは、そこをコメントアウトして緑にしたほうが良い。
・コメントアウトしたら、そのテストを直すチケットを別に切る。
・コミットをして、結果を確認せずに帰宅して、ビルドがコケて大変になったことがあった。
→ そのようなやり逃げの混乱を防ぐのに、バディビルドがお勧め。
★感想：今回、予習で4章と5章を読んできたのですが、構成管理の手順とブランチの運用方法がとてもよく纏まっていて、しかも私が欲していた情報にピンポイントでマッチしてて、ちょとビビった。
というのも今ちょうど、構成管理の運用でチーム共々ちょとハマっていて、コミットは長期間されないわ、コンフクリクトを無視してむりやりコミットするわ、ゴミファイルやゴミディレクトリが大量にあるわの状態で。。。。
んで、お手本となる良い手順がどこかにないかなぁ、と悩んでいたところなのでした。
この4章、チームに配布して唱和したいくらいだわ。
あと、私はこれまで受託開発のプロジェクトがメインだったので、ブランチをバリバリ使っているところを見たことがありませんでした。
そーゆう意味でも、今回のブランチ戦略の章は大変勉強になった。
ちょと今日のために最後の方、急ぎ読みしたところもあるので、読み返してみようと思います。
最後に主催のpapanndaさん、uejunさん、著者の津田さん、参加者のみなさんありがとうございました。
2013/4/14(日) 「『JUnit実践入門』写経・実践会 in 横浜 #5」に参加してきました。
DoorKeeper
http://connpass.com/event/1962/Togetter
http://togetter.com/li/465948以下の書籍をターゲットとした写経会なのです。
場所は横浜のタネマキさんです。
参加者は17名くらいでしょうか。これまでで参加者の人数が一番多かったようです。
今日は「第17章 振舞駆動開発」が対象でした。
いちおう一通り読んで、サンプルを動かして、写経は途中までしてから参加しました。
以下、個人的メモ。
■「17.1節 受け入れテストとは？」に関するディスカッション■ユーザが受入テストやってくれている人は？ → 参加者の半分くらい。
・参加者の大半がウォーターフォールかも。
・要件定義に対するテストが受入テストである。
・エンタープライズのメーカー系だと、受け入れテストをやるのは品質保証部門(QA)だったりする。
（メーカーだと、ユーザはコンシューマなので、ユーザが受け入れテストできないので）
→ プロダクトに責任をもっているQAとかシナリオを書き、仕様書に沿って操作をして受入テストをする。
・発注の時に仕様を曖昧にしておいたほうがいい、というのはある。
■BDDについて・BDDには「ユーザー視点」と「開発者視点」の2パターンがあるのでは。
→ それを「BDD」として１つに纏めるのに違和感がある。
■TDDとBDDの違いについて・明確に分類はあるような気がするが、境界線がふわっとしているという感覚。
・BDDを仕事で使ってる人は？ → 参加者でいなかった。
・BDDは、フレームワークというより視点の違いでは。
・プロセスとしてのBDDと、フレームワークとしてのBDDがある。
・プロダクトコードのクラスとテストコードのクラスを１対１に対応させると、変更に脆くなる。
→ BDDはそこに自由度を持たせ、外部仕様の振る舞いは動かさないけど、内部仕様は変えても大丈夫、とする。
・JunitだけでもBDDできるんじゃね？
→ JunitだけでもBDDできるかもだけど、Cucumberの方がBDDやるんだったら書きやすいだけでは。
・アジャイルサムライ横浜道場でCucumberハンズオンをやった時のスライドに、ユニットテストとの違いが書いてある。
・上の資料では、BDDには以下の書籍に書いてある前提知識がある方が良い、と言っている。
①継続的デリバリー
②エリック・エヴァンスのドメイン駆動設計
・ウォーターフォールのV字モデルだと、受入テストの反対側に要件定義や基本設計があるが、そこでBDDを書くのが理想。
→ でも難しいよね。
■「17.2節 振舞駆動開発とは？」に関するディスカッション■Cucumberはシナリオを日本語で書いて、それをテストコードに結びつける。
・可変部分がある日本語で書いて、それをテストコードに結びつける。
■誰が嬉しいかでTDDとBDDを区別できるのでは。
・TDDは開発者で、BDDはお客さん。
・BDDはTDDの先にある。
・BDDはユーザ視点が入ってくるのでは。
■Cucumber-JunitとRSpec
・JunitはJava。それに対しRSpecはrubyというよりDSLに近い。
・メタプログラミングを使うことによって、DSLによって、テストの中でテスト対象の振る舞いを駆動していくことに気づいた。
・CucumberはRSpecが起源。
■アジャイル開発でユーザーストーリーをどう判断するのか？
→ 受入テストを自動実行可能にすればいいのでは。
・受入テストの自動化と単体テストの自動化は補完しあう。どちらがいらなくなるわけではない。
・アジャイル開発だとDoneの定義としてフィーチャーテストを書けば、駆動してると言えるのでは。
■GOOS本の「外側のフィードバックループ」とBDDの関係について
・GOOS本では、外側のフィードバックループとして「失敗する受け入れテストを書け」と言っている。
→ 受け入れテストでエンドツーエンドのテストまでやれ。
・GOOS本では、外側のループもTDDの一部といっているような気がした。
・ただ、あれはモックでインタフェースを繋ぐことに焦点があるので、エンドツーエンドとは言い切れない部分もある。
・GOOS本は開発者視点だし。
■Cucumberはシナリオさえあれば、コードがなくてもテストできる。
・ただ、テストを実装してないのにテストを実行すると緑になってしまうのがダメなところ。
■BDDだと、お客さん側に厳密さが求めれるのでは。
・以前は「こんな感じでやっといて」とお客さんがベンダに伝えるだけで開発を進めることができたが、BDDだとテストを明確に定義しないといけない。
→ お客さんの負担が上がる？
■LTタイム 其の壱■LT No.1 @ageさん：「社内勉強会のSpock紹介資料」@aeg さんの同僚の @yamkazu さんがSpcokに関していろいろやっていて、社内勉強会をやった。
https://github.com/yamkazu今日のLT資料は後日公開予定とのこと。
■「17.3節 cucumber-junitによる振舞駆動開発」
各自BDDに関する実践タイム（15時～18時）各自、好きなBDDフレームワークを使って写経なりペアプロなり、実践する時間が3時間ほど。
私は書籍の17章の写経が残っていたところを実装し、ポーカーのツーペアのテストを追加で実装するトコまでやりました。
あとは時々、休憩にジョジョを読みつつ、ひとまず7巻まで読んだ。
ちなみにcucumber-junitのjarの最新版だと、featureファイルの「ならば」という文字でうまくいかないようです。
とりあえずjarのバージョンを書籍と同じ1.08に合わせれば大丈夫だとか。
■LTタイム 其の弐（18時～）■LT No.2 @ryu22eさん： PythonのBDDフレームワークbehaveについて・Git:
https://github.com/ryu22e/junitbook-behave・behaveの日本語訳を現在されているそうです
■LT No.3 @shinyaa31さん： BDDフレームワークJnarioについて■LT No.4 @grimroseさん： Groovy, Spock, Gradleを使ったBDD
■まとめ■cucumber-junitを使ってみた感想 by cucumber-junitチーム・cucumber-junitをオススメできるかをcucumber-junitチーム8人に聞いてみた。
→ Yesは、8人中0人。。。 orz
・なんか、Junitでも良くね・・・？
・cucumber-junitのjarのバージョンの違いのせいで、写経でパスや日本語でハマることがあった。
・テスト未実装で実行させると、デフォルトで緑になるのが危険すぎ。
■次回の写経会は5/25の予定。
★感想：cucumberは前から興味あったんですが、今回初めて触りました。
日本語でシナリオを書いてテストに繋げていくトコが斬新です。
でも、日本語で書けるからといってこのシナリオファイルをお客さん自身で書けるか、というと難しいと思います。
要件を決めきれない、仕様に落とせないお客さんが多いと思うので、現実はやはりエンジニアが書く事になるのかなぁ。
ただ今日の話にも出ましたが、cucumber使ってシナリオ起こしてテスト全部やろう！という思想に無理に持っていく必要はないでしょうね。
Junitの単体テストと補完し合うように仕込んでみたり、デプロイ後のスモークテストとして一部のシナリオテストをJenkinsに仕掛けるためにcucumberでテスト書く、というくらいが最初はいいのでは。
Junitよりもシナリオベースのテストが書きやすいのがCucumber、というくらい認識です。
まだ今日1日写経しただけなのでなんとも言えませんが。。。
あとは、Seleniumもちょと触ってみたいと思っている。
次回がCIの章あたりで、その次がWebのテストあたりやるらしいので、その時にやるくらいかな。
最後に主催者の @shinyaa31さん、参加者の皆さんありがとうございました。
2013/4/12(金) AEP読書会 第一章「計画の目的」に参加してきました。
DoorKeepr
http://aepreading.doorkeeper.jp/events/3452以下の書籍をターゲットとした読書会なのです。
場所はアジャイルサムライ横浜道場と同じく、アットウェアさんです。
参加者は12名くらいでしょうか。
去年の4月（ちょうど今頃くらいですね）、会社からの辞令で部署異動がありました。
配属された部署は「アジャイル開発を全社に適用推進していこう」というのがミッションの１つだったんですが、
そんなわけで会社からアジャイルに関する1冊の本が手渡されました。
それがこの書籍だったのです。
んでこの本を読み始めたのですが、とても良い本だなー、と気に入っちゃって、会社から借りた書籍は返し、
自分で買いなおしました。会社から借りた本だと、書き込んだり折り込みいれたりできないですからねぇ。
今回、この読書会が新たに始まることを道場主さんのツイートで知り、良い機会ということで参加することにしたのです。
ディスカッションできる場があるのも良いですねー。
今回の読書会は、いきなり最初からピザとビールを飲み食いしながらの進行です。
データベースリファクタリング勉強会もこんなカンジでやってますね。
以下、ディスカッション時に書き殴った個人的メモ。
---
■P.28に「計画づくりとは価値の探求なのだ」とあるが、「価値の探求」とは何を指すか？ → 読書会の中で結論でず。もやもや感があるが先に進む。
■プロジェクトが始まる前にコストは計れるが、価値は計れるのか？ → コストも始まる前にホントに計れるのか？
→ 両方とも大体の概算なら計れるのでは。
■信頼できる見積りとは？・計画作りの話だから、継続的に計画をつくる、ということでは。
・見積りを作成する人が信頼できるから、その見積もりも信頼できる。という理解もできるのでは。
・計画は、ある時点のスナップショットにすぎない。
・当初立てた計画が今となっては危ういと分かっているのに、それを守ろうとする行為は信頼できない。
→ ちゃんと計画変更の必要性をステークホルダーに知ってもらうことによって、信頼性が上がる。
■スケジュールとトレードオフになる品質について・お客さんには外部品質は求められるが、内部品質は求められない。
・でも内部品質を疎かにしていると、外部品質もそのうちダメになる。
■「計画」と「計画づくり」は何が違うのか？・「計画」は、ある時点の「スナップショット」。不確実なものでしかない。
・「計画づくり」は、それをつくる過程。
・開発に例えると、「計画づくり」は「プログラミング」で、「計画」はある特定の「リビジジョン」。
→ ある特定のリビジョン（計画）に拘るよりは、プログラミング（計画づくり）を繰り返して改善していく。
・「計画づくり」は行為であり、そのアウトプットが「計画」。
・「計画づくり」をするための「計画」を作れ、とか上司から言われそう。。。 orz
■計画しすぎるとよくない理由・時間がかかる
・時間をかけて作った計画は、信頼できる計画だと誤解される
・見積もりは計画の構成要素である。
・アジャイルサムライでも、計画は「あてずっぽう」と言っている。また不確実性コーンの左端は不確実。
→ その段階で計画しすぎても、どうせ状況が変化し、当初の計画はムダになる。
■計画へのバッファの積み方について・プロジェクト全体にバッファを積むのはいいが、タスク１個１個にバッファを積むのはダメ。
→ パーキンソンの法則が当てはまる状況になってしまう。
・バッファは50%～90%の範囲で積むのが良いらしい。
・プランニングポーカーで5か8のカードばっかり出す人は、「こいつバッファ積んでるな」と勘ぐるかも。
■どれくらい計画すれば適切か？・みんなが合意できるくらい計画できればいいのでは。
・みんなとは？
■良い計画と無駄な計画とは？・計画では、仮説と検証が大事。でも最初の仮説を間違えると、あとのモチベーションがすごく落ちる。
・計画しすぎると、間違えたときに戻れない。リソースを人に結びつけちゃうので。
→ 失敗とわかったら止められる計画が良いのでは。
・計画は、後で直せるコンテキストと直せないコンテキストがある。特に後者はハード開発で多い。
・計画に失敗して作業が無駄になると分かった時は、その仕事が無駄かどうかより「仕事があると人は成長する」という発想をする。失敗を価値と捉える。
・本当の無駄とは、「無駄に気づいても、それを続けること」では。
・上から提示された計画に沿って嫌々やるのと、自分達で作った計画に基づいて作業するのでは、モチベーションは全然違う。
→ 計画は自分達で作るのが良い。
→ 最初の計画は上の人が立てたとしても、その計画を変えていける状況ならば、それでいいのでは。
■これまで参加したプロジェクトで上手くいったものについて・自分一人で計画を作るのではなく、みんなで計画を立てて発言率が上がる状況にしたら、上手くいった。
・反復開発の1週目で、すごい失敗した。それで2週目は不確実性コーンを考慮したら上手くいった。
・顕在化したリスクを計画に組み入れた。
・とりあえず計画があると、議論する場が生まれた。それでいろいろ見直しをかけることができた。
・実装チームと検討チームを分けたらうまくいった。
→ デザイン担当とアプリ担当を一人ずつ呼んで、２ヶ月で作ってみる。
→ リリースのスピードはすごく遅くなったが、全体としては上手くいった。
■WBSについて・「ソフトウェア職人気質」という書籍によると、「炭鉱を掘る」という作業の見積りがWBSに関係があるらしい。
・炭鉱を掘る作業だと、一人の作業量が大体ブレなく見積もれる状況にある。ソフト開発はそうじゃない。
・炭鉱採掘は必ずやらないといけない作業は見えるが、ソフト開発は見えない作業がある。
・WBSの破綻をカバーできる予算があるのが、良いWBSでは。
・自分の作業をWBS化すると正確性は高い。チームでも、長く一緒にやってるメンバだとWBS上手く書けたりする。
・WBSはお客さんに見せるために作らざるを得ないことが多い。
→ 「適当WBS Creator」みたいなツールがあるといいかも。バックログを入力するとそれらしいWBSを吐いてくれるとか(笑
・一人作業に対してWBSを作るのは無駄では。バックログとかToDoリストで十分。
→ それは作業をやる時期によるかもしれないのでは？
・WBSで、タスクに作業者の名前を最初から入れずに、後でで決めるという方法もある。
★感想：本を独りで読むだけでなく、参加者とのディスカッションを通じて理解を深められるのがよいですねー。
昨日も「SQLアンチパターン」という書籍の読書会に参加してブログにも書きましたが、理解度が全然違う。
疑問点とかもぶつけてみて解決できますし。
あと、ピザとビールもおいしかったなぁ。量も十分で、これで1000円とは驚き。
酒代を負担してくださったスタッフ様、ありがとうございます！
。。。でも、ディスカッションしてるとピザが冷めちゃうのが難点でもある。
最後に道場主様スタッフ様はじめ、参加者の皆様、ありがとうございました。
2013/4/11(木) SQLアンチパターン読書会 「ジェイウォーク」に参加してきました。
DoorKeeper（告知サイト）
http://sqlap.doorkeeper.jp/events/3416以下の書籍をターゲットとした読書会なのです。
場所は御徒町（湯島）の株式会社アルティネットさんです。
参加者は全部で8名くらいでしょうか。
今回、主催者の @natsu_nanana さんにお誘いいただいて参加させていただきました。感謝！
先日2/26(火)、Devlove主催の「SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 -」というイベントがあり、これに参加してきました。
そこで「これは！」と思い、会場で販売していたこの書籍を即購入したのでした。
んで、その時に講演されてたのが、この書籍の訳者でもある @t_wada さんです。
そんとき書いたブログはこちら。
「SQLアンチパターン・レトロスペクティブ - データベース危篤患者の救出 -」に参加しましたhttp://makopi23.blog.fc2.com/blog-entry-54.html今回、この書籍をターゲットとした読書会が新たに始まるとのことで、とても楽しみでした。
しかも前日になって @t_wada さんも参加されると知って、テンションは急上昇！
ということで、頑張って写経してから参加することにしました。
以下、写経メモと読書会メモ。
ちなみに環境は、OSがWindows7(x64), DBMSがMySQL 5.1.37, DBMS操作用のGUIが MySQL Workbench 5.2.47CE です。
■ディスカッション前に、参加者全員で議論ネタを付箋に書き出しました。
■1.1節から1.2節へのProductsテーブル変更の方法・最初、DropしてからCreateし直すのかな？と思いましたが、Alter文でできました。
(1) account_id列に貼られている外部参照の名称を調べるために、以下のSQLを発行する。
| show create table products; |
→ 表示された結果のCONSTRAINT欄を見ると、参照制約の名称は products_ibfk_1という名称であることがわかる。
(2) 次に、account_id列に貼った参照制約を削除する。
| alter table products drop foreign key products_ibfk_1; |
(3) 最後に、account_id列の型をvarchar(100)に変更する。
| alter table products modify column account_id varchar(100); |
以上(1)～(3)の手順で、account_id列の型をvarchar(100)に変更できました。
ポイントは、外部参照制約を外さないとalterできないことですかね。
ちなみにproductsテーブルを一度dropしてcreateし直す場合、productsテーブルのproduct_id列は
他のテーブル（P.xxiiiのBugsProductsテーブル）から外部参照が貼られているので、そのままdropできません。
なのでいずれにせよ、account_id列の外部参照制約を外す必要があります。
■1.2.1節の正規表現について最初 REGEXP '[[:<:]]12[[:>:]]'の部分は LIKE '%12%' でもいいんじゃね？と思ってました。
ですが読書会で質問してみると、どうやらREGEXPの方は、単語境界を認識してパターンマッチする構文だそうです。
知らなかった。ググッても見つからなかったし。
ご教示ありがとうございます @t_wada さん。。。
■1.2.2節のSELECT文(regexp_2.sql)のインデックス使用について書籍に「両方のテーブルをすべてスキャンして、クロス積を生成し」という説明があります。
これがどうも腑に落ちませんでした。
WHERE句のp.product_id列は主キーなので、インデックスが自動で貼られているはず。
そうなると、Productsテーブルは主キー検索で1件に絞られるはず。
だとすると、ON句では1対Nのスキャンになるはず。
んで、この件を読書会で質問してみたら、@t_wada さん曰く、どうやら原著でもミスがあった箇所だそうで、
和書の方も修正するかも、とのことでした。
どうやら、ミスを見つけたということで、ちょとお役に立てたようです！
ちなみにexplain句で検索パスも調べてみました。
type列を見ると、Productsテーブル側が const となっており、インデックスアクセスです。
ちなみにAccountsテーブル側は ALL となっており、フルテーブルスキャン。
あと、SQLのファイル名称が regexp.sql と書かれてますが、実際はregexp_2.sql ですね。誤植かな？
■1.2.3節のSELECT文(count.sql)についてこれは何をするSQLなのかな？と、最初読んだときはピンときませんでした。
んで写経して動かしてみたら、これはCOUNT関数ですね。
account_id列にカンマで区切られた数字が何個入っているかを、product_id毎に表示します。
■データベースの構造変更について1.2節の最初に「データベースの構造に対する変更を最小限に抑えるために」とあるが、
1.5で交差テーブルを作成する時点で、Productテーブルをalter tableして
account_id列を削除しなければならない。
ただしバイト位置指定でデータを取り出す実装にアプリ側がなっている場合、カラム削除は影響デカい。。。
でも必要なことなので、痛みを伴うがリファクタリングすべき。
■多対多の状況に出くわした場合の対処方法@t_wada さんが「データベースリファクタリング」という書籍を使って説明してくださいました。
該当箇所はP.123の「関連テーブルによる1対多関係の置き換え」ですね。
大御所が説明してくださる醍醐味・・・！なんて贅沢な読書会なんだ。
ポイントは、関連テーブル（いわゆる交差テーブル）を用意するのと、同期用トリガーを導入して移行期間を設ける点ですかね。
ちなみに私、この書籍も持っていて、読書会にも参加してます。（前回は出れませんでしたが。。。）
■1,5.1のSELECT文(join.sql)のインデックスの使われ方について「このクエリは結合の際にインデックスを効果的に使う」と書いてありますが、Contactsテーブルのproduct_id列は主キーじゃないのでインデックススキャンできないのでは？と最初思いました。
んで読書会で質問してみたら、Contactsテーブルのproduct_id列には外部キーを付与しているため、MySQLだと自動的にインデックスが貼られるのだそうです。
ちなみにPostgresqlだと外部キーを設定しても自動でインデックスは貼られないのだそうな。
DBMS依存なんですねー
■ジェイウォークを選択してしまうような場面とは以下の２パターンが考えられるとのこと。
(1) 苦肉の策で、追い詰められてやる場合
(2) 正規化を理解していない場合
■ジェイウォークを選択してしまう心理プログラミング言語だと、カンマ区切り構造は普通なら配列で持とうとするので、自然な発想ではある。
それに対し、RDBMSは多対多というのは特殊な状況に当てはまる。
プログラミング言語でアプリ側でやる方が早い場合は選択肢としてはアリ。
ただしその場合のデメリットとして、参照整合性はアプリ側で頑張る必要がある。
■交差テーブルの導入について交差テーブルにIDのペアしか持たせないなら、論理設計としては意味が無く、単なる物理設計で仕方なく用意した位置づけとなる。
交差テーブルに、IDのペア以外にカラムを持たせることがある。
例えばCustomerとPolicyというキーのペアに加え、日付のカラムを持たせて日付情報を付与するパターンとか。
あとは履修管理システムとかだと、「Lesson(授業)」と「Student(学生)」の多対多の関係を維持する交差テーブルに、「履修登録した」という事実を持たせるために「Registration(履修)」というカラムを持たせる場合が該当する。
■日々使うSQLの先頭にEXPLAINを付けるとアクセスパスを見ることができるので勉強になる。
■最近はDBMSが実行計画をよく考えてくれる。
・コンパイラの最適化の世界と一緒で、SQLも素直に書いたほうが良い。
・各テーブルはメタデータを持っていて、データの偏りを判断してインデックスの使い方を制御したりしてくれる。
・性能のしきい値を設けて、それを超過した時にexplainで調査するくらいが良いのでは。
■SQLやDBに関するオススメ書籍
@t_wada さんからは以下のような書籍が紹介されました。
・中級者向け
・書いて覚えようという趣旨の書籍（著者の一人は @t_wada さんのパパ）
■勉強会の途中から @inda_re さんも飛び入り参戦。
しかもなぜか以下の書籍を手にしてて、奥深い名言を一言。「ジェイウォークなんかfoldrで一発でしょ！」
ちなみに私、この原著の読書会にも去年まで参加してました。
あと、訳者の一人が私の大学院の研究室時代の1年後輩なのです。
というわけで、私にとってもこの書籍は思い入れのある書籍なのです。
★感想：写経の段階で出た疑問も解決できましたし、皆さんとディスカッションで多くの気づきを得られて大変有意義でした。
@t_wada さんが参加してくださっているのも豪華すぎですし。
これからも継続して参加したいと思います。
あと、終わったあとに参加者さんとご飯を食べに行ったのですが、遅れて @yokatsuki さんが合流されました。
次回、@t_wada さんと @yokatsuki さんの2名が参加されたら、更に勉強会のクオリティが上がりそうで、贅沢な限りです！
最後に、貴重な場を提供してくださった @natsu_nanana さんはじめ皆様、ありがとうございました。
2013/4/2(火) アジャイルサムライ読書会 横浜道場 「アジャイルな意思疎通の作戦」に参加してきました。
DoorKeeper（告知サイト）
http://yokohama-dojo.doorkeeper.jp/events/3267以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者は20名くらいでしょうか。雨空でも参加率はとても良かったです。
今回は第10章「アジャイルな意思疎通の作戦」から読書＆ディスカッションしました。
■１．輪読・ディスカッションウチのチームは4名でした。ホワイトボードと付箋はこんなカンジ。
ウチのチームで話し合った内容のメモ。
---
■イテレーション計画ミーティングとストーリー計画ミーティングの関係
→ 1つ前の9章にあったP.189の図と説明で考える。
・「イテレーション計画ミーティング」は
イテレーション(n)で実施する。対象はn+1。
→ ストーリーの実装を予定しているイテレーションの、１つ前のイテレーションで「分析」をする。
・「ストーリー計画ミーティング」は
イテレーション(n+1)が対象。
→ ここでストーリーとして開発する作業に備える。
■イテレーション計画ミーティングは、次のイテレーションの直前に実施する「段取り」みたいな作業だと思う。
・次にやることを決めて見通しを見ておくだけでも、安心感は大分違うと思う。
■「ショーケース」って、Scrumで言うと「スプリントレビュー」のこと。
■「ミニふりかえり」が10～15分と書籍にあるが、短すぎじゃね？
→ どうやらKPTでいう、KeepとTryの２つのみに絞って口頭ベースで振り返りをやるみたい。
Problemはストーリー計画ミーティングで洗い出したり話したりするんじゃないか。
→ でも、口数が少ないエンジニアから意見を引き出すには、付箋に書かせることも重要だよね。
（声の大きいエンジニアの意見ばっか出る場にならない工夫として、あえて付箋に書かせる）
■P.216の「シナリオ１；完成してないストーリー」について。
イテレーション内で完成しなかったストーリーを、8割完成だから8割ぶんのストーリーポイントをベロシティに加算するか否か。
→ ベロシティは複数のイテレーションの
平均なんだから、8割と2割に分けて積んでも、10割を次で積んでも、長いスパンで見ればベロシティは変わらない。
→ それなら、8割と2割に分けて積む、とか面倒くさいことする必要ないのでは。
→ むしろ、ヘタに8割ぶんを余計に積んだりするとチームの能力が過大評価されたりして、期待のマネジメントに失敗する。
■２．各チームの共有タイム他のチームの共有タイムでは、以下のような意見が出ました。
■1日に3回、デイリースタンドアップをやるプロジェクトがあった。理由は以下2点。
①マネージャが早めに手を打ちたかった。
②作業に没頭するとハマっても気付かず進んでしまうので、間違った熱中から引き上げさせるポイントを1日に3回作った。
■ミニふりかえりで毎回褒めるのって難しいよね。
■デイリースタンドアップが形骸化する理由：
・困っている状況を報告しても助けてもらえないような環境だと、デイリースタンドアップのメリットを感じなくなり形骸化するのでは。
■デイリースタンドアップが長くなる場合、大抵とある2人同士で議論始めたりする。
→ 2人で話し始める状況になったら、無理やりにでも打ち切る。
■イテレーション計画ミーティングとストーリー計画ミーティングの違いに悩んだチームが複数あったようである。
ちなみにウチのチームも議論になって、その差は↑に書いたとおりだと個人的に感じた。
■３．おまけ@aeg さんがJubatas（ゆばたす）のシールを配布してました。
Jubatus はオンライン機械学習向け分散処理フレームワークだそうです。
公式：
http://jubat.us/ja/
★感想：改めて書籍を読み直すと、新しい気付きがけっこーありました。
次回から、予習していこうと思います。予習といっても、ただ該当範囲を読んでから参加するだけですが。
というのも、輪読してて、気になることをちょっと自分なりに考えたい場合、15分スプリントだとその時間が十分にとれないと感じたからです。
あと、10.7節のタイトルにもありますが、「自分たちにあった手段を選ぶ」というのは大事だと思います。
ウチのチームも、イテレーション計画ミーティングとスプリント計画ミーティングって合体できるんじゃね？
という話がディスカッションの中で何度も出ましたが、10.7節まで来て、あぁ合体してもいいんだな、と納得。
今回も有意義なヒトトキでした。
道場主さん、スタッフさん、参加者のみなさん、ありがとうございました。
-->
