makopi23のブログ

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

「XP祭り関西2014 ~ やってみよう!XP ~」に参加しました

2014/4/26(土) 「XP祭り関西2014 ~ やってみよう!XP ~」に参加してきました。

DoorKeeper
http://xpjug.doorkeeper.jp/events/9030

Togetter
http://togetter.com/li/659934

場所は大阪市鶴見区民センターです。
参加者は50人くらいでしょうか。



東京在住の私が2年連続で参加できたのは、ちょうどGW帰省の初日に開催されたからなのです。
朝7時くらいの品川発-新大阪着の新幹線に乗り、新大阪駅からJRと地下鉄を乗り継いで30分くらいかな?

ちなみに去年書いたブログはこちら。

「XP祭り関西2013」に参加しました
http://makopi23.blog.fc2.com/blog-entry-72.html

もう1年経ったんですねぇ。
ということで、取ったメモを自分の復習用にダラダラと書き起こしてみる。


■オープニングセッション
「わかりやすいアジャイル開発の教科書 ~ 教科書の向こうに何が見えてますか? ~」

書籍「わかりやすいアジャイル開発の教科書」の著者3名が、参加者のアジャイルに関するご質問、お悩み、課題などに答えていくセッションです。

わかりやすいアジャイル開発の教科書わかりやすいアジャイル開発の教科書
(2013/03/28)
前川 直也、西河 誠 他

商品詳細を見る

以下、個人メモ。

Q1.
  • 要件や仕様が確定しないと進めない、レビューが完了しないと先へ進めない現場がある。
  • でも、アジャイルだとそれはマイクロPDCAになってしまう。
  • がんじがらめの組織の場合にアジャイルをどう導入していけば良いか?

A1-1. 細谷さん
  • 「Doneの定義」を満たすことで「完了」にしますよ、といったように、プロセスを明確にしている。
  • ステップの管理という意味では、ステップは小さくするようにしている。
  • 今の現場は、1~2ヶ月単位で第三者検証を実施しているが、計画がミソ。
  • アジャイルの計画を立てて、それを第三者検証の担当者と合意をして、各フェーズにメトリクスを設定し1~2ヶ月単位で検証していく。
  • キモは、プロセス検証をしてる人とどう合意できるか、という点である。

A1-2. 前川さん
  • 重いことをやっている間にどんどん変わる。
  • どんどん仕様が変わっていかないと勝てない。
  • でも好きなようにやらせるとバグだらけになる。
  • なのでタイムボックスを切って、動くものを出していく。
  • 現物を見て、直すということを繰り返す。
  • QAの人にも早く入ってもらう。
  • それを経営者がそろそろ気づいている。なので現場も「やりましょうよ」と変えていかないといけない。

A1-3. 細谷さん
  • やり方を変えなきゃいけないと気づいてないケースがけっこうある。

A1-4. 西河さん
  • スマフォ開発はウォーターフォールでやってる間にOSのバージョンが上がる。
  • メーカーもそれに合わせて対応していかないといけない。
  • 各プロセスをちゃんと通らせるが、そこにどう変更プロセスを組み込むかが大事。
  • 変更プロセスを仕組みとしてちゃんと組み込むようにしている。



Q2.
  • アジャイルって少数精鋭?

A2-1. 西河さん
  • 新入社員のころからアジャイルが当たり前になるように、仕組みでアジャイルな組織にしている。

A2-2. 前川さん
  • 少数誠意なのはウォーターフォールもアジャイルも一緒では。
  • 成長していくアプローチができるのがアジャイルのいいところ。
  • 小学校や中学校が30人クラスだからといって、人が成長しないわけではない。
  • 100人で「なんちゃってスクラム」を回しているが、小さいサブユニットが複数できるのでチームは少人数になる。

A2-3. 細谷さん
  • いかに成長していくチーム作りをするかが重要。
  • 現場で実践すること。
  • 1つ1つのことをチームでしっかり見ていくこと。
  • ストーリーカードを詳細化するときには、チームで話し合う。
  • 設計はホワイトボードの前にチームで集まって話し合おう。
  • コーディングはペアプロとTDDを取り入れ、コミット時にはレビューをする。
  • 振り返りをしっかりやる。
  • 少人数は結果。1つ1つをしっかり見ていけるチームじゃないと成長できないし、品質も保てない。



Q3.
  • 考え方の古い管理職をどう指導していけばいいか?
  • PO的に暖かく見守ってくれる人になってほしいが、どうすればいいか?

A3-1. 細谷さん
  • 相手がどんな価値観を持ってるかをよく理解する必要がある。
  • チームが活き活き働いて、成功して、自分が評価される、というのを嫌という人はあまりいない。
  • そこは共有できるはず。
  • でもアジャイルを提案すると「嫌」という人は、何かリスクを感じてるはず。そこを観察するのはすごく大事。
  • アジャイルをネガティブに思ってる間は、アジャイルに否定的である。でもポジティブに感じ始めると上手く回りだす。
  • 小さい成功をプロモーションするのが結構大事。
  • エンジニアはプロモーションあんまりしない。そうじゃなく、上手くいったことを伝えて、ちゃんと広げること。
  • チームメンバーのプロモーションも大事。お互いのいいところを口にだして共有すること。

A3-2. 西河さん
  • アジャイルは「やる」ものでなくて、「組織が成る」もの。
  • 「やりましょう」じゃなくて、「なりましょう」。
  • 作るものの価値を最大化することが最大の目的。
  • その価値を達成するための行動を定めているのがXPとかアジャイル。
  • 上司は説得するものではなく、なるもの。価値観を共有すること。
  • プラクティスから入るより、飴ちゃんを机に置くだけでもアジャイルは始まる。それだけでもほんわかするよね。

A3-3. 前川さん
  • オンサイト顧客でストーリーを書きましょう、というのと一緒。
  • 互いの価値を共有すること。

A3-4. 細谷さん
  • 急に変えれないことは、変えれない。
  • すぐに変えれることは、すぐにやればいい。
  • アジリティを高めていくことを際限なくやり続ける。
  • 今よりも少しだけアジリティを高め、実行して結果を出しましょう。
  • それをずっとやり続けること。


Q4.[失敗談、デメリット] 
  • なんでも変更を受け付けてきて、責任が曖昧になって地獄になることがあるが、どーすれば。

A4-1.
  • その機能ってホントに使うんですか?と踏み込むのがアジャイル。
  • やりたいことはいっぱいあるけど、機能的に、、提供時期までにホントに全部必要なのか?
  • その機能だったらリーズナブルにこの期間で届けられますよ、と導いていく。
  • お客さんの予算で最大の価値を届けるようにすること。
  • ストーリーの優先順位がシビアになることが多いが、優先順位を3つのカテゴリに分けるようにしている。
    • 1.法律違反とか、ぜったいやらないと存在しえない
    • 2.これやらないと価値がない
    • 3.その他
  • 優先度をA,B,Cと3段階に分けるのは良くない。優先度は主観が入るし、属人性がある。
  • 誰の目にも分かるように、「カテゴリ」に分類すること。
  • 優先順位を付けるのではなく、3つのカテゴリに分類してください、と持っていく。
  • カテゴリ分けをやっている間に、お客さんが優先順位に気づいてくる。
  • それを元に交渉して、プロダクトバックログに落としていく。

A4-2. 前川さん
  • 責任どーするの?と曖昧になることある。
  • 責任を取らないといけないのは、POとかマネージャ層。
  • POやマネージャに、チームメンバがひっきりなしに聞きに来るので、面倒くさい。
  • んじゃ、ドキュメントに書きゃいいじゃん。
  • 何のためにドキュメントを作るのかを書くこと。
  • アジャイルって面倒くさい。でも、メンバーが成長してくれれば良いと思う。


Q5.
  • 印税はいくらくらい?

A5.
  • 書籍の値段を下げるため、細谷さんと西河さんは印税を貰っていない。
  • 前川さんは、印税で家族を旅行に連れて行くという目的を最初に立てたので、少しだけ貰っている。
  • コンビニでバイトしたほうが儲かる。


お題
  • 書籍に「Smiling Adventure」という章がある。これは前川さんの案で書いた。
  • 「お客様は誰?」、「誰のために作ってるの?」という問いに、結構即答できないことがある。
  • 第一歩は「お客様は誰か」を把握すること。
  • 次に「そのお客様にとっての最大の価値は何か」を考える。
  • 何からアジャイルを始めたら良いかを考える際は、この2つの議論をチームで話すことから始めたらいいのでは。
  • お客さんのhappyを考えてそれを実現したら、あなたはどう思いますか?
  • そこまで考えるようになると、チームのモチベーションが変わってくる。

Q6.
  • 書籍を書いて良かったことは?

A6-1. 前川さん
  • 普段思っていたことを書けたこと。「読んでください」と言えるのが良い。

A6-2. 細谷さん
  • 「Fealess Change」という書籍に「モノを渡すことが大事だよ」という、「トークン」というパターンがある。
  • なので、形になってるのは偉大だと思った。

A6-. 西河さん
  • 日本のアジャイルってやっぱあると感じる。
  • そういうものを考えて、本に纏めるために深く考えることができたのが良かった。

---
Q&Aの一場面はこんなカンジ。

20140426_xpjugkansai1.jpg


■アジャイル和室

お昼休みに、別室に設けられている「アジャイル和室」にも行ってきました。
参加者の皆さんが「アジャイルかるた」なるものをやってました。

20140426_xpjugkansai2.jpg

読み上げるカードには「Redmine」といった単語と、その説明が書いてあります。
それを読み上げて、「R」のカードを参加者が探して取る、といった具合です。

20140426_xpjugkansai3.jpg


そういや去年は「アジャイル双六」でしたねぇ。
あと、コンセントを借りてPCの充電をさせていただきました。

こっから午後セッション。だらだらメモを書き起こしてみる。

■講演1 今日から始めようXP

稲田信平さん

■ そもそも、グローバルに働くとは?
  • 英語が出来ることではない!
  • 「どこでも通用できる働き方がグローバルな働き方」だと自分で定義している。

■ これからXPを始める方へ
  • 肩の力を抜く
    • IT業界のエンジニアって、みんな真面目で頑張っちゃう人が多い。
    • なので「それ以上はやらないで」と止めるようにしている。
    • やらないでいいことをやりすぎると、本来やらないといけないことができなくなる。
  • 常にアラートを出すようにしてもらう。
    • アラートを出さない人には怒るようにしている。
  • 教科書どおりにやらない
  • でも知識として知っておく必要がある。

■ ビジネスモデルの作成
  • ビジネスモデルを書いて、クライアントと方針を決めた。
  • ビジネスモデルはどんな立場でも書ける。
  • ビジネスモデルは、誰がどういうことをするかを掴みやすくする図。
  • 仕様変更って、プログラマの立場からするとピンポイントで来る。
  • それをピンポイントに修正しだすと、コードベースがぐちゃぐちゃになってしまう。
  • その仕様変更が正しいかどうかを判断するために、ビジネスモデルのどこに埋め込むのが正しいかを判断する必要がある。


■ 取り入れたXPのプラクティス
  • リファクタリング
    • ソースコードをチームで共有するためには、ソースを綺麗に保つ必要があった。
  • ペアプロ
    • ペアプロを応用して、リーダーと設計者で「ペア詳細設計」をやった。
    • プログラミング以外でもコミュニケーションをとって仕事をしてくれるようになった。
  • 朝会
    • 朝会でアラートを出してもらう。
    • デスマになる時は、独りで仕事や悩みを抱え込むことが多い。
    •  なので、アラートを出すタイミングは「朝会」の場であると指示していた。

■ 機能ごと設計・開発(ぜんぶ作らない)
  • まずゴールがあって、それまでにどんだけ作らないといけないかがある。
  • これを考慮しないと、一方だけ高機能で、もう一方が低機能、みたいになってしまう。
  • 必要なものから作る。

■ ハイブリッド
  • 全体計画はウォーターフォールで、どこをゴールとするかを決める。
  • 細かく計画、開発を繰り返す。
  • アジャイルとウォーターフォールの良いトコ取りをすると良いものができる。

■ WBSは無視する
  • WBSの順番でやって絶対できないことがでる。
  • 重要なのは問題点を洗い出して共有すること
  • まずシンプルに設計段階で切って回す。

■ XPをやってみた気づき
  • ペアプロは人によることが大きい。理解度とか教育とかでいろいろある。
  • いろいろな形態があり、それに合わせることが可能。
  • 捨てることが重要。
  • はまりすぎないこと。WBSがあったら、この期間中にやらないと!って背負っちゃう。
  • できないことはできない、やらないことはやらない、という勇気が必要。

■ コツ
  • 目標を立てて仕事しよう
  • 短期的な目標でもいい。
  • 早く帰りたい、休みたい、色んな仕事をしたい、etc
  • それをよりよくしようとそれを目的にしちゃうとそこにハマってしまう
  • XPのプラクティスを完全ゴールにしちゃうと良くない
  • 経験の積み重ねが重要。

■ グローバルって?
  • 何処に行っても通用すること。
  • 何処に行ってもパフォーマンスが発揮できること。
  • XPは、言語依存じゃない、国依存じゃない。
  • どこでも使える、その根底がXP。

■ 結論
  • グローバルにはXPは最高のプラクティス。

■ おまけ
  • 趣味を持ちましょう。
  • 人を作るのは仕事だけではない。


■講演2 ビジネスモデル・キャンバス入門

山中美智子さん

■ビジネスモデルって何?
  • どのように価値を創造し、顧客に届けるかを論理的に書いたもの
  • ビジネスモデルは営利企業とか以外でも、家庭とかでも使える。
  • 収益を上げ、体制を維持、発展させる活動を行うことに変わりはない。

■ ビジネスモデルを書く狙い
  • 見える化できる
  • 鳥瞰できる
  • 現在のビジネスモデルの分析と、新しいビジネスモデルの構築がしやすくなる

■ ビジネスモデルキャンバスとは
  • ビジネスモデルに必要な要素を1枚の絵に纏めたもの
  • 9つのセグメントに分かれている。
    • 1.顧客セグメント
    • 2.価値提案
    • 3.チャネル
    • 4.顧客との関係
    • 5.収益の流れ
    • 6.リソース
    • 7.主要活動
    • 8.パートナー
    • 9.コスト構造

そういや、アジャイルサムライ横浜道場の特別編でビジネスモデルキャンバスを書いたことがあったなぁ。
そんとき書いたブログはこちら。

横浜道場 特別編 「現場で役立つ(かもしれない)ビジネスモデル・キャンバスのワークショップ」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-106.html


■講演3 XP入門と導入の壁についての話

平田大作さん

■ ソフトウェア開発は設計
  • 「リーンソフトウェア開発」という書籍に、「ソフトウェア開発は試行錯誤を含む学習プロセス」と書いてある。
  • この言葉は衝撃的だった。
  • ソフトウェア開発は、完璧に計画可能な「製造プロセス」ではない。

■ ソフトウェア開発は複雑で難しい
  • ソフトウェアの構成要素は言語である。
  • 言葉は物理的制約を受けない。この制約の無さが捉えどころの無い複雑さを生んでいるのでは。
  • 逆に、建築とかは物理的な制約を受ける。
  • ソフトウェア開発は測定できない。
  • 建築だと材料力学とかあって、性質とかは実験して測定できる。
  • モノは決まった性質しか示さないが、ソフトウェア開発はそういうところがない。
  • WFでもXPでも、難しいものが簡単になるのではない。アプローチが変わるだけ。
  • 難しいものを相手にしていることを忘れないようにしよう。

■XPとは?
  • 5つの価値と12のプラクティスから成る。最近は12から拡張して19のプラクティスと言われる。
  • 5つの価値は、迷ったときの判断基準になる。
  • 何かに迷ったり複数の選択肢があった場合は、この5つの価値に照らして活動を選択する
  • 陥りがちな5つの価値
    • 1.ルール重視、ドキュメント重視
    • 2.機能を詰め込めばいい
    • 3.動くものは触るな
    • 4.波風を立てない
    • 5.権威

■ 計画ゲームと小規模リリース
  • イテレーションに盛り込むものを計画ゲームで決める。ここがキモだと思っている。
  • 試行錯誤と学習の機会を与えてくれる。

■ 小規模リリース
  • 2週間は、難しくても制御可能な期間である。タイムボックスを切る。
  • 計画ゲームが重要。
  • 計画ゲームはあまりしっくり来てなかったが、やってみると腑に落ちる。
  • 例えば前のバグの積み残しが後のイテレーションを圧迫すると、大変な開発になる。
  • こういったときに、イテレーションの前に計画ゲームを実施し、どれを入れるかをちゃんと決める必要がある。
  • 計画ゲームで負荷を制御する。
  • XPが「学習プロセス」というのは、イテレーションを繰り返すことによってどのくらいの難しさでどのくらいでできそうか、が段々わかってくる点にある。

■ テスト駆動開発
  • インタフェースを決めたらテストコードを書く。
  • テスト先に書くことで使い方の理解を得られる。
  • テスト駆動開発の注意点
    • テストコードの粒度を細かくしていると変更コストが増大する。
    • テストコードはインタフェース=Public Methodに対して書く。

■ ペアプログラミング、共同所有権
(1) 利点
  • リアルタイムレビュー、強制的コミュニケーション
  • 品質、実力の底上げ
  • ばらつきが減る
  • シンクロ率アップ
  • 人の流動に対してフレキシブルになる。
(2) 注意点
  • かなりの労力が必要。
  • 向き不向き結構ある。

■ その他の話題
  • 開発全体の計画は必要。
  • ドキュメントは考えたことを伝える手段として必要。文書化の手間はかかるので、wikiでも充分。
  • 保守用ドキュメントは別途作成が必要。 

■ 導入の壁
  • 「人の壁」の対策
    • 新人教育からXPを教える組織として変えていくのはこれがいいかなと思っている。
    • XPJUGに入ってもらう




■講演4 KPTによるプロセス改善~あなたはPDCAを回したことがありますか?

KPTによるプロセス改善~あなたはPDCAを回したことがありますか? from akipii Oga
  • KPTはCAPDから回すべし。
  • 自分の考えを共有するよりも、自分以外の人間に景色がどう見えているのかを認識することが重要。
  • コンフリクトが起きたらKPTを実施して、意識して「雨降って地固まる」プロセスを通過させよう。


今回の講演について、あきぴーさんがブログに書いてます。





■ライトニング・トークス

3名の方によるLTです。

■ @sakaba37 さん
リーダー諸君!アジャイル開発を学び未来への道を切り開こう(XP祭り関西LT) from Makoto SAKAI

5分の枠が、まさかの3分半で終了。
残り1分30秒あまりを埋めるのに苦労するさかばさん。。。


■ @Chuki さん
  • 「わんくま同盟」で活動中。
  • 「コタツモデル」というのが出てきた。


■ 開原さん
XP祭り関西2014 LT やってみよう!スクラ○ from Takahiro Kaihara
  • スクラムを社内に取り入れるためのノウハウに関するLT~


★感想:
去年に引き続き今年も東京から参加したんですが、東京と大阪のノリの違いとか随所に感じられて楽しかったです。
参加者にカメラ役を任せたりとか、最後のクロージングの西さんの振る舞いとか、関西なんやな~とw
いや、私も実家が大阪腑箕面市なんですけどね。。。

来年も参加できるといいなぁ。
スタッフ、参加者の皆様、ありがとーございました。

スポンサーサイト

SQLアンチパターン読書会 「インプリシットカラム」に参加しました

2014/4/25(金) SQLアンチパターン読書会 「インプリシットカラム」に参加してきました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/10832

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は13人かな。全員おなじみの方ばっかです。
この日は18章「インプリシットカラム」がターゲットでした。


■アジェンダ
今回は @setoazusa さんが発表担当でした。
Sqlアンチパターン読書会 インプリシットカラム from Hiroyuki Ohnaka



■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140425_sqlap1.jpg

以下、復習用の個人メモ。
---

■ 運用上がりのエンジニアとインプリシットカラム
  • オペレータとか運用担当者は、GUIのSQLコンソールでSELECT *を実行することに慣れている。
    • 最近のツールだと、Excelのようなスプレッドシートっぽく結果が表示される。
    • しかも、カラム数が多くてもGUIの右にスクロールすれば見れるし、レスポンスが遅ければ途中打ち切りもできる。
    • これに慣れた運用あがりのエンジニアさんは、アプリでもSELECT * としてしまう人が多いように感じる。
  • でも、SELECT * だと遅いということで、運用でも使わない派もある。
  • このへんは文化かもしれない。


■ RailsのActiveRecord
  • Rubyはメタプログラミングが強い。RailsのActiveRecordはSELECT発行時にSQLが2回走る。
  • 1回目はテーブル定義のメタデータを取得する。カラム名はメソッド名となり、メソッドを生やす。
  • 2回目に実際のデータをDBから取得する。
  • Rubyは動的型付け。DBにないデータもconcat関数やave関数を使えば作れるが、型がずれる。


■ カラム名と予約語
  • カラム名にcountと付けたらエラーになった・・・
  • あとは、classとかcontinueとかの予約語がカラム名に入っていて死んだことがある。
  • Cake PHPとかはSQLに予約語が入ってても、エスケープして発行してくれたりする。


■ Viewで逃げる
  • Alter Tableでカラムの追加や順番の入れ替えをした場合は、Viewを旧テーブル名で残す。
  • 表の構造を変更したのを知っているアプリは、新表にアクセスさせる。
  • 昔のアプリは旧表名のViewへアクセスさせる。
  • こうすることで、旧アプリがSELECT * でアクセスしていても、旧定義のViewに逃がすことで不整合を回避できる。


■ 仕様と実装の差異
  • JOINでカラムが重複してたときに、JDBCの仕様は先勝ちなのに、ドライバの実装によっては後勝ちだったりと異なる。
  • 大文字と小文字が混在している場合、SQL標準は大文字側に倒す仕様となっている。
  • ところが、PostgreSQLは小文字側に倒す仕様だし、MySQLは大文字と小文字の混在はそのまま扱う。
  • ちなみに昔、MySQLは擬似データベースとして呼ばれていた。仕様と異なるところ多いし。


■ 複数テーブル間でのカラム名の重複
  • 複数テーブルでカラム名は重複していても良い。
    • 今回の例だと、BooksテーブルとAuthorテーブルにtitleカラムがあるような設計はOK。
  • JOINを指定しつつSELECT * する場合は、ネームスペースが被っているんだからカラムが重複するのは当たり前である!
  • それはフレームワーク開発者が受け入れるしかない。
  • カラム名が重複してもSQLとしてはエラーにならず実行されてしまう点が手強い・・・
  • ORMはインプリシットカラムを自動で回避してくれる。
  • インプリシットカラムでハマるのは、ORMを使わずに手でコードを書く場合が多い。


■ カラム名による指定と、カラム番号による指定
  • SQLでカラム番号を指定してデータにアクセスするような場面はほとんど見ない。
  • アプリでは、カラム番号を指定してデータにアクセスすることはある。
  • JDBCはアクセス速度の都合上、カラム番号でデータを取得することを推奨している。名前解決が省略される分、高速。


■ PostgreSQL vs MySQL
(1) PostgreSQL
  • OSSのDBで、SQL標準の準拠率が最も高い。
  • Javaとの親和性が高い。
  • SQLは動的型付け言語であるが、PostgreSQLは強い型付け機構を持つ。
  • MySQLより高速。JoinはMySQLよりかなり速い。
  • 堅い運用に向く。疑わしきはエラーに倒す。
  • 透過フェイルオーバーが出来ない。クラスタ構成でサーバ側がコケるとロールバックできずに死ぬ・・・

(2) MySQL
  • だいぶ型付けが弱い。
  • 性善説で、曖昧なSQLをなんとか解釈して動作しようと頑張る・・・
  • 文字と数値が混在している場合は、文字っぽい箇所をDoubleにキャストするような変な挙動になる・・・
  • MySQL はスレッドモデルだが、PostgreSQLはプロセスモデル。
  • ちなみに初期のWindowsはCeeate Processが遅かった。プロセスモデルはプロセス生成のコストが重い。


■ SQLと正規表現
  • SELECT句にアスタリスクが使えるなら、SELECT句に正規表現が使えるようにしても良かったのでは?
  • いや、SQLに正規表現が導入されたのはだいぶ遅かった。
  • 正規表現がSQL標準に入ってから、SQLの文法が凄くデカくなって、パーサーを書くのが大変になった。
  • そんなで、SELECT句に正規表現は使えない。Drop table *とか出来たらヤバいよね・・・


■ DBのメタデータ
  • MySQL以外のDBMSは、メタデータをテーブルに保持している。
  • MySQLはメタデータを取得しようとすると、DB全体を舐め始める、なので監視してないと遅くなる。


■ JavadocのResultSetの説明は教育的?
  • JavadocのResultSetの説明に、列名が重複した場合について言及している。
  • java1.4は「列名を使用する場合、実際に目的の列を指すことを保証する方法がプログラマにはありません。」と書いてある。
  • Java1.4はツンな表現であるが、Java6は「一意にしたければAsを使え」と教育を始めている。


■ インプリシットカラムの解決策
  • インプリシットカラムはSQLの限界なので、他でカバーするしかない。「不要な列以外のすべての列」とか指定できないし。
  • 18.5節の「解決策」は、元々の目的であった「タイプ数を減らす」の解決になってない。
  • 列名を全部列挙したら、タイプ数って減らせない・・・。でも、これはSQLの限界なので、「そういうもの」として諦める。
  • SELECT句に列名をきちんと書かないといけないと、面倒くさいのでサボるようになり、本当に必要なカラムしか指定しなくなる。
  • これがパフォーマンスに好影響に傾く。(アスタリスクで全部取ってくるより、ネットワークの帯域とか減らせるし)



■終了後のお食事会
お食事会というか、今回はガチな飲み屋へ。
今回も木村さんのトークが炸裂して、みんなずっと大爆笑w








締めのお茶漬けにて。


これも皆でワロタw

★感想:
Select * の弊害について書いた章で、とてもシンプルです。
列の追加削除にアプリ側がついていけなくなり不整合を起こす問題と、パフォーマンスが悪化する問題と、弊害の観点は2つある点がポイントですかね。
とくに前者は、ズレに気づかずにアプリがたまたま動作しちゃったりすると悲惨です。。。
あと後者は、カラムの途中にLOB型があったりするとレスポンスが返ってこなかったり。。。
たぶん、参加者のみなさんもインプリシットカラムは一度は目にしたことあるんじゃないでしょうかね~
ということで、とても馴染みあるネタで付箋の数も多かったです。

今回で第Ⅲ部が終わり、次回の19章から第Ⅳ部に入ります。これも楽しみだ。
皆様、ありがとうございました。



■おまけ:過去の「SQLアンチパターン読書会」ブログ

1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-65.html

2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-70.html

3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-73.html

3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-77.html

4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-84.html

5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-90.html

6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-94.html

7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-97.html

8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-105.html

9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-109.html

10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-115.html

11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-118.html

12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-121.html

13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-128.html

14章:SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-130.html

15章:SQLアンチパターン読書会 「ランダムセレクション」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-133.html

16章:SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-134.html

17章:SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-136.html

「スクラム道場.11」に参加しました

2014/4/23(水)「スクラム道場.11」に参加してきました。

DoorKeeper
http://taoofscrum.doorkeeper.jp/events/10630

場所は品川シーサイドの楽天さんです。
参加者は12人くらいでしょうか。

今回のテーマは「スクラムが難しい状況や環境とは?」でした。
ちょうど今参加してるWGでもScrumを社内に展開していく上での課題とか整理してたところなので、個人的にはちょうどストライクなテーマなのでした。



■アジェンダ

最初に、楽天の川口さん(@kawaguti)から、今日のテーマに関連した内容の説明がありました。


この公開スライド、当日使ったものよりだいぶ歯抜けの状態のようです。
イベント当日1週間前くらいに登録されたもので、未完成バージョンっぽいけど、更新されるのだろか・・・?



■ディスカッション
参加者全員で「スクラムがうまくいかない状況」をテーマにディスカッションを行いました。
20140423_scrumdo11.jpg

概ね、以下のような感じで進みました。

1.各人で、スクラムがうまくいかなかったストーリー(経験)を付箋に書き出す。
2.1人ずつ、書き出した付箋をホワイトボードに貼りながら、付箋の内容を参加者に説明する。
3.各付箋に書かれたアンチパターンを改善する案がある人は、改善案をその付箋の右下に貼り付けて説明する。

以下、復習用に雑多なメモ書き。



■ makopi23が書いた付箋と回答 ~其の壱~
Q.
アジャイル開発では個人でなくチームで責任を全うし、チームとして評価されるべき、という考えがある。
その場合、会社で半年毎に行われるような個人査定は、どのように評価されるべきか?

A.
Agile 2011 で Linda Risingが講演で触れていた書籍に「Hard Facts」というのがある。

Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based ManagementHard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management
(2006/02/28)
Jeffrey Pfeffer、Robert I. Sutton 他

商品詳細を見る


これによると、人は以下のような感情を持つらしい。
  • 高い評価をされた人は、それが当たり前だと感じる。
  • 低い評価をされた人は、それを根に持つ


要するに、成果報酬制度はモチベーションへのマイナスの影響の方が大きいらしい。
ということを川口さんがおっしゃってたので、ググってみたら川口さんのブログがヒットした。

HARD FACTS ~ 事実に基づいた経営
http://d.hatena.ne.jp/wayaguchi/20120611/1339362414

あと、他の方からは以下のような意見がでました。
  • 個人評価をするなら、チーム全員が自分の目標と評価を公開する仕組みにしたほうが良い。
  • 360度評価で、チームメンバが個人を評価するようにする。
  • 「チーム評価+個人評価」の2段階で評価する仕組みしている。


■ makopi23が書いた付箋と回答 ~其の弐~
Q.
アジャイルやXPの有効性を偉い人に示すための数値をどう提示すればいいかに悩んでいる。

A.
参加者さんからは以下のようなアドバイスをいただきました。
  • 数値で有効性を示す指標としては「Chaos Report」というものが公開されている。
  • なぜその数値が欲しいのか、偉い人に聞いてみる。Whyを明らかにしないと数値化しても意味ない。



■ その他の雑多なメモ

  • 打ち合わせを午後のど真ん中にセッティングすると、割り込み感を感じて嫌がられる。
    • 朝会とか昼休みの直後にセッティングすると、拘束時間は同じなのに抵抗感が少なくなることがある。
    • チームに時計を合わせることが重要。

  • 相手が切羽詰っていると振る舞いに出る。逆に言うと、そこから相手の状況をキャッチでき、ヘルプに繋げられる。

  • チーム文化を維持するには、元のチームの過半数以上の人数が必要。
    • チームを解体する場合は、元のチームに半数以上を残すべき。
    • あるいは、アジャイルコーチなどの力を借りる。

  • 「シュナイダー文化モデル」というのが出てきた。ググると川口さんのブログが出てきた。


  • スキル差が大きい場合のレビューだと、指摘修正が何度も発生して効率が悪いので、ペア作業をやらせた。
    • レビュー時間も削減できたし、相手の理解度も上がった。

  • クロスファンクショアナルペアリングで異なる担当をペアにし、相手の理解度を上げる。

  • ペアプロをやってて、理解の違いがある場合はペアを交代する。
    • 理解度が高い人がナビゲータ、低い人がドライバとなるように作業をする。

  • ペアプロやるときは、100円ショップで売っているホワイトボードを手元に置いておく。
    • 2人で議論したい場合はそのホワイトボードに書くようにする。

  • GitHubを使った開発で、プルリクエストにレビュアー2人以上が「いいね」をしないとマージさせないようにした。
    • 未レビューのコードがマージされないようにした。

■ 書籍のプレゼント
最後に、川口さんから2名の方に書籍のプレゼントがありました。じゃんけん、負けた。。。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターンFearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
(2014/01/30)
Mary Lynn Manns、Linda Rising 他

商品詳細を見る

★ 感想:
みなさんが上手くいってない事項に対してみんなで解決策を考える、というコンセプトは良いですね。
私もいくつか悩みを付箋に書いて、それに対していろんな意見を貰えて、とても参考になりました。
イベントが終わった後に参加者で飲み会にも行ったんですが、こちらも濃いメンバーと濃い話が出来ました。

参加者、スタッフの皆様、ありがとーございました。

SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました

2014/4/3(木) SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました。

DoorKeeper
http://sqlap.doorkeeper.jp/events/10206

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。

参加者は11人かな。初参加はお2人です。
この日は17章「スパゲッティクエリ」がターゲットでした。
身近なネタということで、ディスカッションもとても盛り上がって楽しかったです。


■ アジェンダ
今回は私が発表当番でした。
SQLアンチパターン読書会 「スパゲッティクエリ」 from makopi 23


なんの捻りもなくてゴメンナサイ。。。
私が過去に出会ったスパゲッティクエリを最後に紹介しようと思ったんですが、探す時間が無かった。。。

あと、確認のため写経も一応やりました。そんときに使ったINSERT文を参考にアップしておきます。
sqlap_chapter17.txt


ちなみにスライドをアップする時に気づいたんですが、Railsの勉強会で発表した時のスライドのViewが36,000回を超えていてフイたw
HerokuではじめるRailsプログラミング入門 6-3節「複数モデルの連携」



■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140403_sqlap2.jpg


今回は身近なネタということで、付箋の枚数も多かったですね~
以下、ディスカッション時の個人メモ。
---

■ 17.3 アンチパターンの見つけ方
  • とりあえずDISTINCTを付けてみよう!ってのは超あるあるw
  • 3階上のフロアでは実際に繰り広げられていた。。。
  • 似たようなのに「とりあえずGroup byを付けてみよう!」ってのがある。


■ 17.5.5 SQLを用いたSQLの自動的な記述
  • ストアドプロシージャをやる時間が無い時に採用することがある。
  • 例えば、監査ログを取りながら別のSQLを流したい場合など。
  • teeコマンドで標準出力に出したINSERT文を解釈しながらSELECT文を組み立てて流すとか。


■ 17.2 アンチパターン:複雑な問題をワンステップで解決しようとする
  • 快感駆動はダメ! (1行で複雑に書いて、ちゃんと動かした自分に酔うみたいな)
  • SQL麻疹(はしか)
  • SQLを1行で書きたい、という人はコマンドラインを意識していることがある。
    • コンソールにSQLを貼り付けて実行する場合は、改行で実行されるため1ライナーで書く必要があった。
    • コンソールにSQLを貼り付けて動くことを確認してから、ソースコードへコピペする、ということをよくやる。
  • SELECT句の1カラム毎に改行する書き方もある。
    • DIFFを取る時に便利
  • 昔のC/S方式の時代は、サーバだけマッチョな性能のマシンを割り当てるのが一般的だった。
    • 複雑な処理はサーバのDB側でやらせたほうが性能的に良かった。
    • そのため、貧弱なクライアント側のアプリで処理をさせず、サーバ側で1SQLでやらせることがあった。
  • 昔はDBへのConnectが遅かった。
    • そのため、ループでConnectを複数発行するのではなく、1SQLでConnectを1回に制限させることがあった。
    • 最近はループを回してもいいから、インデックスを効かせるように書きましょう、という風潮にある。
  • 3000行のSELECT文を見たことがある。
    • 就職支援サイトだった。
    • 「女性に優しい」とか「沿線沿い」とか、あらゆる条件を考慮してDBからデータを引っ張ってくるSQLだった。
    • Where句は動的に組み立てるが、表示データを取ってくるのにそのSQLを使っていた。
  • 複雑な1ライナーSQLの悪いトコは、SQL嫌いを生むこと。


■ 17.4 アンチパターンを用いてもよい場合
  • プログラミングフレームワークに縛られて1SQLにすることはほとんど無い。
  • 帳票出力ツールは1SQLに縛られることはよくある。
    • MS ACCESSとか
    • SQL Server Reporting Servicesとか
    • SQLを書くと、ビャーっとExcelにグラフが出てくるみたいな挙動の帳票ツールの典型。


■ 駆動表
  • JOINする時は、軸足となる側のテーブルを決めましょう。
  • メインとなるレコードセットを決めて、そこから根を生やしていくイメージ。
  • OracleではNested Loopの外部に配置する表を 外部表(駆動表)、内部に配置する表を 内部表 というらしい。
  • SQLには書き順がある。
    • まずFROM句から書く。
    • FROM句にどのテーブルを指定するかが、頭の中の軸足になる。


■ ストアドプロシージャ
  • SQLが複雑になった場合はストアドプロシージャに逃げるという手もある。
  • ただ、ストアドプロシージャはテストがしづらいのが欠点である。リファクタリングも弱い。
  • データを加工する程度ならストアドでもよいが、ロジックをストアドで書きだすと手に負えなくなる。。。
  • C/Sの2層時代はサーバが強力だったのでストアドプロシージャは一般的だった。
  • 最近は高トラフィックはDBネックになるので、DB側でストアドを使うよりは、Web/APサーバ側に処理させるのが一般的。


■ テンポラリテーブル
  • SQLが複雑になった場合は、いったんテンポラリテーブルに結果を逃がすという手もある。
    • MySQLでは、CREATE TABLE文に「TEMPORARY」キーワードを付けることで一時テーブルを作成できる。
    • テンポラリテーブルはメモリにデータを置くので、接続が切れるとデータも自動的に消える。(後処理不要)
    • メモリ上なので、速度も速い。
  • MySQLのトランザクション分離レベルのデフォルトは、「Repeatable Read (RR)」である。
  • MySQLのRRとスナップショットの特徴を使い、「ザ・ワールド!」で時間を止めて細かくメンテする。
    • これ便利! by 木村さん


■ スパゲッティクエリの境目
  • 行数よりも、意図が読めないSQLがマズイ。
    • 例えばこの章の最初のSQLも、前後に説明文章があったからこそ、なんとか理解できた。。。
  • まず、結果が間違っているのは言語道断。
  • 結果は合っているけど、意図が読み取りにくいSQLが該当するかもしれない。
  • 要件を解きほぐす必要がある。
  • 出力結果に引っ張られると、スパゲッティクエリの原因になりやすい。
    • 例えば、横に長い結果を出せ、という要求に引きづられてSQLが複雑になる場合 etc
  • まず、スパゲッティになるなら最低限、コメントを書きましょう。
  • あと、エイリアスにわかりやすい名前をきちんと付けましょう。


■ 17.5.3 CASE式とSUM関数を組み合わせる
  • この章は、原書のSQLの間違いが多かった。。。
  • このCASEとSUMのSQLも、原著のSQLの結果が合わなくて、イライラして自分で書いた!(笑
  • CASEとSUMを組み合わせるこの形式は、かなり頻繁に使うがとても便利。

■ ホワイトボードまとめ

今回は @inda_re さんが後輩を1名連れてきてくださったのですが、その方がこまめにホワイトボードに纏めてくださいました。
20140403_sqlap1.jpg

これは良いですね~。毎回お願いしたいw


本日初参加の木村さん、Oracleにて奥野さん(@nippondanji)と一緒にMySQLのサポート業務をされているそうです。
ディスカッション時のお話も、MySQLの経験豊かな点が髄所に出てました。
あと、DBの書籍も執筆されているそうです。

プロになるための データベース技術入門 ~MySQLforWindows困ったときに役立つ開発・運用ガイドプロになるための データベース技術入門 ~MySQLforWindows困ったときに役立つ開発・運用ガイド
(2012/03/16)
木村 明治

商品詳細を見る

読書会の後、参加者で担担麺を食べに行ったんですが、お話も面白かったw
あと最終回の25章、執筆者の奥野さんに参加いただけるよう取り計らってくださいました。感謝!


★感想:
スパゲッティクエリは馴染みが深いテーマなので、話題もいっぱいでした。
個人的には7テーブルをJOINするSQLを実際に見たことがありますが、それが私のスパゲッティクエリな経験かなぁ。

あとデカルト積のとことか、INNER JOINをLEFT OUTER JOINに書き換えるトコなんかは、写経していろいろ動作を追わないと理解しづらいとこもありました。
やっぱ写経していろいろ弄ってみて理解するのが一番です。

あと、個人的には17.5.3のCASEとSUM関数を駆使するSQLをスラスラ書けるようになりたい。
ここは復習しておくと後々役に立ちそうだ。

みなさま、ありがとうございました~



■おまけ:過去の「SQLアンチパターン読書会」ブログ

1章:SQLアンチパターン読書会 「ジェイウォーク」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-65.html

2章:SQLアンチパターン読書会 「ナイーブツリー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-70.html

3章:SQLアンチパターン読書会 「IDリクワイアド」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-73.html

3章:SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-77.html

4章;SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-84.html

5章:SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-90.html

6章:SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-94.html

7章:SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-97.html

8章:SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-105.html

9章:SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
 http://makopi23.blog.fc2.com/blog-entry-109.html

10章:SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-115.html

11章:SQLアンチパターン読書会 「ファントムファイル」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-118.html

12章:SQLアンチパターン読書会 「インデックスショットガン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-121.html

13章:SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-128.html

14章:SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-130.html

15章:SQLアンチパターン読書会 「ランダムセレクション」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-133.html

16章:SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
 http://makopi23.blog.fc2.com/blog-entry-134.html



FC2Ad