2013/7/23(火) アジャイルサムライ横浜道場 特別編 「ざっくりわかる DevOps ～ ビジネスよ！これがおれたちの力だ！」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/4599Togetter
http://togetter.com/li/537974以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者は30名くらいでしょか。
今回は特別編ということで、Microsoftの長沢さんによる、DevOpsをテーマにしたの講演がありました。
特別編ということもあり、またテーマがいま流行のDevOpsということもあり、満員御礼です。
私、ちょうどこの道場告知の2週間前くらいに、社内のDevOpsをテーマにしたワーキングに放り込まれました。
んで、DevOps勉強せなあかんなぁ、どーしよかな、とか思ってたら横浜道場の告知が！
これはまさしく俺のための道場！
ということで告知が出て、速攻申し込んだら前から2番目だった。
以下、長沢さんの口頭説明を中心に、個人メモ。
■講演 by 長沢さん
■[P.3] Developers Summit 2013 Summer・8/1のDevelopers Summit 2013 Summerで、基調講演でDevOpsについて講演する。
[S1]DevOpsは開発現場とビジネスの間に何を生むか？ ：
http://event.shoeisha.jp/detail/46/session/83/・あと、セッションA2でも講演する。
[A2]DevOps × Enterprise ：
http://event.shoeisha.jp/devsumi/20130801/session/87/■[P.4] DevOpsがビジネスの成功を左右する時代へ・開発だけアジリティを高くしてもしょうがない。運用も機敏に対応しないといけない。
・DevとOpsの壁が問題視されている。
・現場の立場によって何をどうしなきゃいけないかは変わる。
・ツールや自動化を導入すればいいよね、という単純な話ではない。
■[P.5] 本日の目的・重要なのは、今から何しなきゃいけないのか、その先、半年、3年後、5年後どういう状態になっているのかを考えること。
・「運用者はいらなくなるのでは」、「開発の知識がいるのでは」といった不安が取り除ければいいかな、と思っている。
■[P.6] 本日の内容今日は3本立てで話をする。
・ビジネス
・戦略的なIT
・DevOps
■[P.8] Customer Development・この図は、リーンスタートアップに出てくる。
・欧米ではこれが適用できると言われている。
・カスタマーを見つけてきて検証して、本当にカスタマーと呼べるかを確認する。
・ちゃんと検証を繰り返して、しっかりとした顧客を定義して回していく。
・普通にやってて、このイテレーションが回るかを考えないといけない。
・ITの力を借りたりとかして、競合他社よりも早くやることが必要。
■[P.9] Build - Measure -Learn・この図はリーンスタートアップのモデルを示していて、いま注目されている。
・ビジネスモデルが変わっても、このサイクルを回していることによって対応できる。
・この図は、TDDのビジネス版。
・真ん中にDevとOpsとBizがいる。
■[P.10] ビジネスのリズムの変化・変化はあまりしないように、という考え方がある。変化を求めない。
・これからは変化に対応しないといけない。そうしないとビジネスモデルが古くなって、競合他社に負けたりお客が離れたりする。
・変化してインパクトを市場に与えることを取り入れていかなきゃいけない。
・成長し続けること。
・ビジネスを動かして検証して、育てていく。実測駆動。
・新しいチャレンジをするので、未経験に対して実践しやすいモデル。スクラムに近い。
・DevOpsはアジャイル、リーンなやり方に影響を受けている。ビジネス駆動。
■[P.11～P.14] リズム・これまでは、開発(Dev)と運用(Ops)とビジネス(Biz)のリズムがバラバラということが多かった。
・それぞれの見直し時期が異なるとかの問題があった。
・それぞれ必ず同じリズムになるとは限らないが、ビジネス駆動を加速させるには融合せざるを得ない。
・それぞれがお互いのリズムを尊重しながら進める。
■[P.15] ビジネスのトレンド・新技術が新たな価値を生み出すドライバとなる。
・新技術を活用して製品を作ったりサービス拡大したりして、ビジネスの進化を支える。
・利用者に直接貢献するようなビジネスモデルが増えている。
・できるだけ利用者の近い所でビジネスを起こすことが強いビジネスになる。
・デバイスとか組み込み系とか、目に見えないものが価値を提供する。
・お客さんは意識しないが、欲したことがデバイスを通じて自分のところに手に入る時代になる。
・検索して手に入れるのではなく、自然に提供される時代になる。なので利用者直接ということを意識せざるを得ない。
・エンタープライズだと、利用者はコンシューマだけではない。従業員も利用者になる。企業間連携も生まれる。
・技術的革新でビジネスが激化し、競争が激しくなる。
・なので技術を活用せざるを得ない。
・競合他社に負けないビジネスモデルをリフレッシュしながら進んで行かないといけない。
■[P.17] Microsoftが提唱している今後のアーキテクチャパターン・利用者はデバイスから入っていくが、裏側では様々なサービスが動いている。それがContinuous Service。
・Continuous Service層により、自分たちが意識することなく情報が取得できる。外部サービスとの連携もある。
・DevOpsはこういうアーキテクチャを意識する必要がある。
・DevOpsはこれらのアーキテクチャをひっくるめて考える。
・Identity（認証）とAPIは裏で絶対絡んでくるので、意識しておかないと開発も運用も回らない。
■[P.18] ITの戦略的な役割・一番良いのは先手必勝。
・マーケットをITの力で挽回する。
・一過性じゃなく、継続的にビジネス価値を提供する。一発屋で逃げるのはダメ。
・バランスが必要。ビジネスの賞味期限が短くなっているので、見直しが必要。
・ただ、ガバナンスを忘れてはいけない。
・コンプライアンスとビジネス品質とのバランスをとらないとけない。
・それを主導でやろうとするとすごい負担。
・なのでITの力を借りて可能な限り自動化する。あとスケールアップする。
■[P.19～P.22] ビジネスとIT・ビジネスとITはだんだん融合して、互いに不可欠な存在になりつつある。
・ビジネスの成長をITの力を借りて盛り上げていく。
・1990年代 [ITが"便利"と認識され始めた] - ビジネスが確立された状態で、より便利にするためにITを使うという考え。
- 技術的な意思決定はIT部門が行っていた。
・2000年代 [ITが"有効"だと認識され始めた時代] - ITに対してビジネスパーソンが関与してくる。
- 技術的な方向性は経営者層が絡んでくる。
- QCDSが求められる時代。
・2010年代 [ITが"不可欠"と認識され始めた時代] - ジャストインタイム(JIT)
- IT計画と投資は、顧客中心に。
- CIOから顧客寄りに権限が移行し始めた。
- 具体的にはCMOやマーケティングオフィサーに権限がどんどん移っていく。
・ワールドワイドで見ると、今は2010年代の段階に来ていて、DevOpsが必要となっている。
・ただ、なんでもかんでもDevOpsが必要なわけではない。1990年代とかはDevOpsは必要なかった。
・Information TechnologyからBusiness Terchnologyへ。
■[P.24] Road to DevOps・昔は、ビジネスモデルが確定しやすかった。 - 長い計画を立ててリリースするのが許されていた。
- 定義を固定 → 完全に作る
・これからの時代は、ビジネスモデルが変動しやすい。 - 要求は変化するという仮定で進める。
- ただ、なんでもオンデマンドで対応するわけではない。
- ポイントは、「定期的に、計画」。不定期だと期待値がコントロールしづらくなる。
・昔と今で提供モデルが変わってきている。
■[P.26～P.30] IT = Dev + Ops・DevOpsを説明するのに、いつもP.26の図を使う。
・大事なのはビジネスのアイデアとか課題。それをITを使っていかに克服するか。
・アイデアをソフトにして開発する必要がある。そのあと運用する必要がある。
・エンタープライズだと「開発が無い」、「パッケージカスタマイズだけ」、ということあある。
・エンタープライズは2種類ある。
①基幹システム、ERP
②カスタマーアプリケーション
・前者①は既存のパッケージを買ってきて済ませる。
・後者②は競合優位性を出すための、会社で使わないといけないアプリ。B to CのCが絡むとこがカスタマーアプリケーション。
・前者①は開発がないことがあるが、後者②は必ず開発が絡んでくる。
・DevとOpsのサイクルがうまく回って続いていると、ビジネスに対してITが貢献できている状態にある。
・実際はDevとOpsの間に壁があって進まない。
・運用と開発が分かれていると以下のような弊害が起きる。
①運用で起きたバグが開発で再現できない。。。
②開発したアプリが運用でデプロイできない。。。
・運用と開発の壁を取り払って、リズムを作っていく必要がある。
■[P.31～P.32] IT ≒ Dev + Ops・混沌 開発がブラックボックスで誰がなにをやってるかわからない。
・重量級 承認作業がたくさんある。
⇒ 守らなきゃいけない課題があるので解決していかなきゃいけない。
■[P.33] IT = DevOps・これは、Microsoftが出している図。
・この図が回っているとDevOpsがうまく行っている。
・この絵が持っていきたいTo Be。この図は是非覚えておいてもらうといい。
■[P.34] Why DevOps・2本の線がある。サイクルタイムとMTTR。
■[p.35] DevOps | Why Cycle Timeサイクルタイム ＝ ビジネスアイデアが出てきてから動くソフトを出すまでの時間
- 試行（思考）するビジネスの根幹。短ければ失敗のリカバリが効く。
- 「テスト駆動ビジネス」のドライバとなる。
■[p.36] DevOps | Why MTTRMTTR ＝ 障害が発生してから治すまでの時間
- 動かない状態が極力ないようにする。
- 壊れること前提に運用戦略を考えることが重要。
・サイクルタイムとMTTR、この２つをとにかく短くすること。これによって価値を提供し続けられる形になる。
■[P.37] What DevOps・この図で挙げているのは代表的なもの。
・「やるべきもの」のビジネスシナリオ、運用要件をちゃんと明確にする。
・各フェーズで品質を作り込む。可能な限り本番環境に近い環境でテストを回す。
・運用に渡す際には、どの要件がそこに盛り込まれているのか、どこにバグがあるのか、そういう情報を開発から運用に渡すこと。
・よくあるのが、「開発したモノの状況がよくわからないので、頻繁なリリースが怖い」と言う状態。
→ なので、最大限の情報を渡せるようになれば限定でもリリースできたりする。
・開発のリソースを運用と共同所有することが重要。ソースコードだけでない。
・開発者が運用まで持っていく、一人が全部やる、というのも共同所有の一つ。
■[P.40] 機敏なアイデア獲得と短い計画と確認・ビジネスシナリオをしっかりキャプチャする。
・決めたビジネスシナリオは、動くソフトウェアときちんとリンクしないといけない。そこのトレーサビリティは必須。
■[P.41～P.42] Operation Readiness・早い段階からやることを明確にしましょう
・品質を挙げれる状態にしましょう
・本番環境に近い状況にしましょう
運用を含めたビジネスアイデアがバックログに入っていて、開発と運用を回していける。本番と近い状態でテストが回っている。トレーサビリティがとれたものがデプロイされると、状況がわかる。
■[P.43] 短いサイクルでの開発とテストの継続的実施・長い仕掛かりはやめましょう。
・動くソフトウェアはどういうものかをしっかり見極める。
■[P.44] Just-in-Time Delivery・ビジネスモデルがあんまり変化しないならウォーターフォールでもよい。
・スクラムの「検査と適用」のモデルが取れると良い。
■[P.46] 稼働してから本番！ビジネスの足をひっぱらない・障害が再現しませんとか、デプロイした後は開発の仕事じゃなく運用の仕事だ、といったことがないように。
・問題の切り分けがしっかりできることが重要。
■[P.47] Mean time to Repir(MTTR)・最近は仮想化技術で、本番と近い環境を再現できるようになってきた。
■[P.48] ビジネス／アプリ中心のシステム運用・今のインフラとアプリの関係は、器ありきで考える。まず置き場所を決めてアプリを作って乗せる。
・先にアプリを考えて、乗せる側は自由に選べる時代にもうすぐなる。アプリ中心になる。
■[P.49] Mean Time to Repair・開発側の問題解決フローと、運用が障害を検知してから解決するまでのフローは違う。
・これを踏まえた上で開発と運用のコラボレーションを考えていく必要がある。
・開発側は運用側の改修依頼を受けて始めて障害に気づく。障害情報が足りないなら運用側からもらう。
・開発側で問題解決しても、運用側はそれを検知できない。治ったといっても、どこが原因だったのかとかが分からない。
・開発と運用でリソースを共有してると、そういうことがなくなる。
・サイクルは全く違うが共同所有することでうまいリズムを作ることは可能。
・あるいは、開発側がまるごと運用も丸抱えするか。でもそれは大変。
■[P.50] まとめ●DevOpsをざっくりと感じたつもりになる
・それで自分のDevOpsを考え、やるかやらないかを決める。
・サイクルの絵と、サイクルとMTTRを短くすることは覚えておいて欲しい。
●今から準備することをなんとなく感じる
・自動化でうまくやる。
・今注目されているのは、仮想化でなく、それを如何に効率よく自動で運用していくか。
Dev:基礎がため、継続的縲怐A自動化
Ops：自動管理、インフラ最適、開発の理解
●漠然とした、期待と不安を共有する
■[P.53] 宣伝：これからのデリバリーサイクルを知りたい人向けの書籍・@AgileSeBookBot というTwitterアカウントで定期的に呟いている。
■[P.55] TFSUG・TFSに関係ないアジャイルとかDevOpsとかの現場に近い勉強会もたくさんやっている。
■[P.56] Are you a pig?・有名な「ブタとニワトリ」の話。
・DevOps = DevもOpsも、みんなpig.
・We are Pig!
★感想：タイトルに「ざっくりわかる」とありますが、確かに「ざっくり」とDevOpsを理解することができました。
具体的に「これをこうしなさい」という話はあまりなく、それよりもDevOpsの思想や心構えについてが中心ですね。
DoorKeeprに「今後のたたき台として利用してください」とありましたが、具体的なアクションを起こすのは聴講者次第！ということでしょう。
長沢さんの主張は明瞭で、プレゼンも上手く、非常に理解しやすい内容でした。
この日のお話を聞いて私が個人的に思ったのは、SIerのSEはDevOpsがある程度、あたりまえの状況にあるのではないか？ということでした。
弊社は「拝承」とか「～していただきたく」とか「この木なんの木～♪」とか、巷で良い噂をまったく聞かない某SIerなのですが、一応、SEは要件定義もするし、設計もするし、インフラ面もお守りするし、稼動後の運用・保守に至るまで面倒を見ます。
開発だけする、運用だけする、という状況は少なくとも弊社ではほとんど有り得ない。
（プログラミングを自分であんましない弊社のエンジニアをSEと呼んでいいかは置いといて）
なのでもっと単純に考えて、DevとOpsをもっともっと融合させよう！という趣旨で私はDevOpsを今のところ捉えてます。
そんなことをいろいろ考えさせられる講演で、大変参考になりました。
あと、やっぱエバンジェリストさんはお話上手ですね。。。
私も新人研修とか設計講座とかの研修講師を担当してるのですが、とても参考になりました。
皆様、ありがとうございましたー
2013/7/18(木) SQLアンチパターン読書会 「ポリモーフィック関連」 に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/4717以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、アルティネットさんです。
参加者は10人かな。
今回は @t_wada さんに加え @inda_re さんも緊急参戦。
この日のターゲットは「第6章 ポリモーフィック関連」でした。
■模造紙＆付箋いつもと同じく、ディスカッションしたいネタをみんなで最初に書き出しました。
今回は主催者の @natsu_nanana さんがアジェンダ資料を作成し説明してくださいました。
ありがとうございますー
あと一応、写経してから参加しました。@makopi23が写経用に用意したSQLはコチラ↓
20130718_sqlap_Polymorphic.txt
■ディスカッション以下、個人メモ。
■6.5.3節 "交差点に交通信号を設置する"・6.5.3の方法では、完全に1回しか参照されないことは保証できない。（両方のテーブルから1回ずつ参照される）
→ ただ、DBMSのトリガーなどの制約を付けることで1対1にできる可能性はある。
■6.5節の解決策は2種類に分かれる・交差テーブルを用意する方法（6.5.1節～6.5.5節）
・共通の親テーブルを用意する方法（6.5.6節）
■6.5.4節の「両方の道」・バグからコメントを探しに行く向きの道が、前者のSQL。
・あるコメントに紐付いているバグ or フィーチャを探しに行く向きの道が、後者のSQL。
・両方のSQLとも、結果がNullにならないよう、アプリ側で制約をつけておく必要がある。
■6.5.5節 「道」を合流させる（UNION版）・UNIONの前者と後者で、カラム数が同じ必要がある。
・6.5.4節の後者のSQLは外部結合なので、片方がNullになる。
→ 取得結果を使う側にとっては不便。
・これを改善するため、UNIONを使い和集合を取る事でNullデータを無くそうというのが6.5.5節のUNIONのSQL。
→ Nullデータが無くなった。これだとアプリ側で扱いやすい。
・6.5.5節のUNIONを使っているのは、良いクエリ。
■6.5.5節 「道」を合流させる（COALESCE版）・COALESCE関数は、OracleだとNVL関数に置き換えられる。
・NVL ( expr1 , expr2 )
・式 expr1 が NULL なら expr2 の値を戻す。
・NVLはNull Value Logic の略らしい。
■"6.5.5節 「道」を合流させる"の利点・UNION版もCOALESCE版も、必要な列数だけ手に入る。
・ただ、BugsCommentsかFeaturesCommentsのどちらから取得したかが分からなくなる。
→ 専用のカラムを用意して、どちらのテーブルから返ってきたかを示す定数を格納することは良くやる。
■6.5.6節 "共通の親テーブルの作成"・例えばコメント数だけを集計したいなら、IssuesテーブルとCommentsテーブルだけ参照すれば行ける。
・BugsテーブルとFeatureRequestsテーブルの共通カラムをIssuesテーブルに抜くことで、Issuesテーブルだけ見ればある程度の情報は取得できるように設計している。
■6.5.5節「道の合流」と6.5.6節「共通親テーブル」のどちらを採用するか？・パフォーマンスは、どのくらい集合に偏りがあるかに関係しそうなので、6.5.5か6.5.6かは場合による。
・6.5.5節はRDBの解決策。
・6.5.6節はRDBとOO(Object Oriented)の、ハイブリッドの解決策。
・テーブルのサブタイプまで分かるなら6.5.6節を採用すればいいのでは。
■本来のあるべきテーブル設計とは・・・・そもそも後から交差テーブルを同数追加するくらいなら、最初からCommentsテーブルを分けとけよ！と・・・
・つまり、最初からBugsCommentsとFeaturesRequestsは本来、別テーブルとして設計すべき。
→ でも、この章の題材は暗黙の条件があったと考えるべき。
→ つまり最初の頃はテーブルを分けるかどうか判断材料が無かったので、後で仕方なく分けた、という前提。
■破壊的な変更・参照の向きを逆さにする設計変更は、破壊的変更になるので無理。
・それに対して、交差テーブルの追加は既存テーブルをAlterする必要がないので、破壊的変更になはならない。
■ORMとポリモーフィック関連・ポリモーフィック関連はRuby on Railsのキモ。
・Hibernateもポリモーフィック関連をサポートしている。
・ORMを使わないなら、ポリモーフィック関連ではなく本章6.5節「解決策」の方を採用すべき、が結論。
■6.4.1節 "ポリモーフィック関連を意識的に選択するとき"・どのテーブルと関連付くかが事前に分からない場合にポリモーフィック関連は使う。（他システム連携とか）
・システムを再コンパイルできないような環境で、メタデータを渡して参照先を変える必要がある場合などに使う。
・いろんなもの対してコメントを付けれるシステムを作りたい！って時に採用する。
・ただ、動的なテーブルがシステム連携先側にできた時に、連携先側に交差テーブルを作ってもらうのも手。
→ その場合は6.5節のとおり、参照整合性を貼ることが出来る。
・あとは、相手側のテーブルの作成時期が自分側と大きく異なる場合は、ポリモーフィック関連をやることがある。
・他には、ワークフローシステムとか、データウェアハウスとか、CMSとか、在りモノのパッケージを買ってくる場合にポリモーフィック関連を使わざるを得ない場合はよくある。
・そもそもDBMSを使うには、メタデータを持たざるを得ない場合があるので、その際はEAVとかポリモーフィック関連とかを使わざるを得ない場合がある。
■DBのテストデータとして使えるデータを提供しているサイト・SQLアンチパターンの写経で使えそうなDBテストデータを提供するサイトが3つある。
①MovieLens
・
http://www.movielens.org/login ・
http://www.grouplens.org/node/73 ・調査サイト
・いろんな人が星をつけた生データが提供されている。
・リコメンドエンジンを作成する時に良く使う。
②MySQLのemployeeデータベース
・
http://dev.mysql.com/doc/index-other.html ・MySQL公式のサンプルデータベース
③KEN_ALL.CSV
・
http://www.post.japanpost.jp/zipcode/dl/kogaki-zip.html ・日本郵政公社「ゆうびんホームページ」で公開されている郵便番号データ
・上記URLにある「都道府県一覧」から「全国一括」を選択するとKEN_ALL.CSVがダウンロードできる。
・自治体が公開しているデータは「作りモノ感」が無いのが良いところ。
■PictMaster・組み合わせテストのテストケースをExcel上で自動生成するツール。
・
http://sourceforge.jp/projects/pictmaster/■View・6.5.5節でUNION使って複雑なSQL書くよりは、Viewを作るという手もある。
・Viewを作ってもマテリアライズド・ビューでなく論理ビューなら性能への影響は無い。
・論理ビュー： 普通のView
・マテリアライズド・ビュー： ある単一の時点での表の完全コピーまたは部分コピーが含まれるView
■ORM・PHPのCakePHPは地獄のようなSQLを履くので馴染めない。。。括弧が多い。。。
・JavaだとS2JDBCとかS2Daoとかがある。
■S2JDBC・
http://s2container.seasar.org/2.4/ja/s2jdbc.html・データベースプログラミングの生産性をJava標準のJPA(Java Persistence API)を使ったときよりも10倍以上高めることを目標として作成した Seasar2のO/R Mapperとのこと。
■S2Dao・Seasar2のO/Rマッピングのフレームワーク
・
http://s2dao.seasar.org/ja/・・性能的にSQLをメンテナンスしたい場合にはSQLに手を入れることができる。分業できる。
■MySQLのWrite Lock・MySQLでInsertすると、裏でロックのSelectが走る。(Write Lock）
→ 大きなデータの移行がしにくい。
■@NEKOGET さんからの差し入れ・冷たく美味しいデザートの差し入れ！休憩時間に美味しくいただきました。ありがとうございます！
★感想：今回も大変勉強になりました。
内容的には5章のEAVと似てるカンジでした。メタデータを持たせると参照整合性が維持できなくなったりとか。
UNIONなんて滅多に使わないけど、こんな有用な使い方があるんですねぇ。
あと、DBテストデータを作るのに役立つサイトとかも教えてもらったりと、話が多少脱線したりするのも歓迎です。
皆様、ありがとうございました。
2013/7/16(火)「ディシプリンド・アジャイル・デリバリー 〜アジャイル開発の現実解〜 」に参加してきました。
DoorKeeper
http://devlove.doorkeeper.jp/events/4659Togetter
http://togetter.com/li/534630http://togetter.com/li/5349216月に出版された以下の書籍をターゲットとした勉強会なのです。
場所は新宿のTISさんです。
参加者は60名くらいでしょうか。
ちなみに私がDADの話を聞くのは、これが3回目です。
初回は、Devsumiで江木さんの講演を聴講した時。そんとき書いたブログはこちら。
「Developers Summit 2013」に参加しました ～其の壱～http://makopi23.blog.fc2.com/blog-entry-48.html2回目は、DADについて弊社で講演いただいた時。
そして3回目が、今回のDevlove。
ある程度規模が大きいプロジェクト向けのアジャイル開発ガイド、一応、弊社にもあります。
しかも私、その担当者だったり。。。
んで、何かしらそこにDADのノウハウをフィードバックできないか、期待しつつ書籍を購入し読んでいたとこなのでした。
そんな私にとって、今回のDevloveのイベントはストライク！
というわけで告知を見て速攻申し込んだら、見事トップバッターだった。
以下、個人メモ。スライドに無い口頭説明が多かったので、そこんとこを中心に
■DAD本（ディシプリンド・アジャイル・デリバリー）の歩き方 ■ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド・ずっしり重くて、持ち歩くとアジリティが失われる（笑
・略称は「DAD」、読み方は「だっど」
・448ページ、896gもある。
■DADとは (P.4/58)・アジャイル開発プロセス。ちなみに「プロセス戦争はアジャイルが勝利した」と書籍の最初の方に書いてある。
・日本でも1/4くらいはアジャイルをやっているのでは。
・成功が５９％で失敗６％、という統計がある。
・もっと成功確率を上げられる、としてDADが作られた。
■本書のメッセージ (P.5/58)・DADはツールでなく、知識体系、書籍そのもの。
・この本を携えて現場に行く。
■アジャイルの現実 (P.6/58)・"ウォーター・スクラム・フォール"の蔓延
・ウォーター・スクラムとは：
→ スクラムを始めるんだけど、その準備にエラく時間をかけて、なかなか着手しないスクラム。
・スクラム・フォールとは：
→ スクラムをやっているんだけど、なかなかデリバリしない。
・ガバナンスや組織から目を逸らす
→ スクラムっていろんなものを削ぎ落したコアなプロセス・フレームワーク。
→ しがらみのない環境で回しやすい。
→ でもお客さんに強要したり、エンタープライズから距離を置いているチームも目につく。
・流儀に固執し、古いものを否定する
→ アジャイルの世界よりも古いウォーターフォールのなごりを頭から否定する。
・ベンダーやアウトソーサーの怠慢
→ リスクをお客さんに転嫁してみたりとか、お客さんにストレスを与えてしまっている現場はUSでもよく見かける。
・これらの解決策の一つにDADがなればいいな、と思っている。
■Project Context (P.8/58)・同じContextは、存在しない
→ 業界全体に目を広げると、エンタープライズがあったり、スタートアップ系があったり、スパコン用システムがあったり、いろんなコンテキストがある。
→ IT業界でも、違うコンテキストでモノを見てしまうことが多い。「ウチは〜だから」とか。
■Why DAD (P.12/58～P.16/58)・これまでは、Enterpriseから離れたとこにAgileが小さくあって、粛々やってる感じ。
→ このギャップを埋めるために苦労しているのでは。
・ギャップとは
①予算に合わせないといけない
②既存システムの制約
③他のプロジェクトの制約
etc
・ピュアな環境だとスクラムはうまくいく。でもエンタープライズだと、ギャップを埋めるのに苦労した・・・
・EnterpirseとAgileの間を埋めるのがDADかというと、そうではない。
・Enterpriseのど真ん中にアジャイルを持っていってみよう、というのがDADの本質。これは本に書いてない。
・エンタープライズアジャイルは、エンタープライズとアジャイルを糊代でくっつけるのではなく、エンタープライズの真ん中にアジャイルをもってくる。
・これを意識すると視界が開ける。
■伝統的なエンタープライズ開発 (P.17/58)・ウォーターフォールは１つに過ぎない。
・ウォーターフォールは「成果物駆動」。エンタープライズ分野にそもそも合わない。
■その結果、生まれた行動様式 (P.20/58)・BxUF（Big XXX Up-Front）
→ 要するに、「最初にしっかり〜する」
・BxUFは良くない。
■成果物駆動の活動 (P.22/58)・20章
・各作業の間にレビューがあり、これがゲート（ルールの強要、違反の発見）。
→ １００％にしなきゃいけない、と束縛が生まれる。
→ 作る側もレビュー側も単純プロセスになる。これが一番良くない。
・本当は知的労働活動なのに、句読点チェックとか単純チェックプロセスに落ちる。
・目も時間も労力も全部そこに注がれてしまう。
・最終成果物に何も関係ないところに力を注ぎ過ぎてしまう。
■"アジャイル"な開発とは (P.23/58～P.26/58)・AgilityではなくJIT（Just-In-TIme）。必要なときに必要なものを。
■JITの活動 (P.27/58)・要求分析から受入テスト・リリースするまでのやり方は何種類もある。
→ それぞれ、タスク自体を必要な時に実施するのがシステム開発のJITである。
・JITに対し、RUPは成果物駆動、ユースケース駆動。必要がないところまで精緻に成果物を作っていた。
・この違いに衝撃を受けた。
■Enterprise Agile (P.29/58)・真ん中にJITがいる。周辺は今までと一緒でいい。
・真ん中にJITを置いてあげる。これがDADの本質的な考え方。
■世代が変わった (P.32/58)・昔のクラウドとかがまだない時代は、成果物駆動で良かった。
・でも、今はエンタープライズで成果物駆動はすでにオーバースペック。
・エンタープライズのcontextでは、95%以上はJITでいける気がする。
■Rhythm (P.34/58)・JITとの乖離をどう埋めるか。この埋め方が Rhythm。
・3Cリズムで動くことでギャップを解決してくれる。
■スクラムの3Cリズム (P.38/58)・プロダクトバックログからスプリントバックログに落とす箇所がCoordinate。
・スクラムでも3Cリズムで動いている。
・なので、スクラムもそのままエンタープライズの真ん中にもっていっても破綻しない。
■DAD (P.39/58)・基本はスクラム。
・プロダクトバックログに積む前に、やることがある。これが「方向付けフェーズ」。
・作ったあとリリースに乗せるまでに、やることがある。これが「移行フェーズ」。
・アジャイルサムライも、スクラムをやる前にインセプションデッキを作れと言っている。
→ どんなプロジェクトにも方向付けは必要になる。
・DADの7章分（6章～12章）が方向付けフェーズに費やされている。
・方向付けフェーズで、ギャップを解消するための「見通し」を立てる。「解消しよう」じゃない。
■方向付けフェーズ (P.41/58)・プロジェクト全体の「見通しを立てる」
①リスクを識別して軽減させよう！
②ヤバいものはここで調整しておけば、相当ヤバさが軽減される。
・BxUFに注意！日本人は中途半端に対し民族的に抵抗感がある。
・本の帯に「早期の詳細すぎる要求定義は、詳細化された憶測だ！と言いたい」と書いてある。
・形になってないものをいくら精緻にしても、所詮書いている人の憶測に過ぎない。
■DADに息づくプラクティス (P.45/58)・７つのプロセスと６０のプラクティスを織り込んでいる。
・こーゆう時にはこうしましょう、と具体的にスコット・アンブラーが細かくケアしている。
・それが、そのまま書籍になっている。
・どのプラクティスをどの局面で使うか、が具体的に書かれている。
・スクラムとLeanは色が強い。
■DADに備えられている戦略 (P.47/58)・比較の表が多い。３７の戦略比較表がある。そこに各戦略の利点と欠点が書かれている。
・個人的には、この表が一番使えると思っている。
・自分達が選択しようとしている戦略を、戦略比較表に当てはめて取捨選択する。そのきっかけ作りがしやすい。
■Case Study：方向付けフェーズ (P.50/58)・12章にケーススタディで読み物形式で書いてある。
・最初にこれを読むとイメージしやすい。
■DAD本の構造 (P.52/58)・書籍の各章がDADライフサイクルのどこに該当するのか、図に纏めてみた。
・（@makopi23的には、この図が目から鱗だった！）
■「知の道具箱」 (P.53/58)・「知の道具箱」をみなさんの体の中に作って欲しい。DAD本は、そのためのポインタになる。
・アジャイルプラクティスだけじゃなく、これまでのプラクティスを総動員してJITに使えるように願って書かれたのが、このDAD本。
■DAD = Process Decision Framework (P.54/58)・何らかの判断を各場面でしないといけない。その時に使える枠組みがこの書籍の主題。
・本でDADを勉強するのではなく、DAD本を現場に持ち込むこと！
■DADの学び方 (P.56/58)１．スクラムを学ぶ
２．JITの思考と行動を習慣づける
３．DADのフェーズを学ぶ
４，3Cリズムで生活する
５．DAFのライフサイクルを学ぶ
６．属性の違う人とのコミュニケーション
７．いろいろな道具を手に入れよう
■アジャイリストの（現実的な）心得 (P.57/58)・軸足をJITに。BxUFの誘惑に負けない。
・己の力量を知ること。（無理な規模に無理にやろうとするとハマる）
・こだわりを持ち過ぎない。（スクラムは～だから、とか固定観念は捨てる）
・アジャイルを言い訳にしない。
（アジャイルだから〜できません、は無し。それはお客さんにとって、ネガティブ要因にしかならない）
・関係者みんなに嬉しい驚きを届けるために。（できるはず）
■グループダイアログ＆共有タイム4人ぐらいのグループに分かれ、DADについてグループダイアログをやりました。
んでその後はその共有も兼ね、岡さんとDADの監修にあたった藤井さんへの質疑応答タイムとなりました。
■アジャイルの導入・大きなプロジェクトになると腰が引けて、「しっかり準備しよう」となる。
・それで、実装から距離を置いてしまう。デカくて失敗しちゃいけないから、準備に時間を割いてしまう。
・そうならないよう、できるならプチ基幹システムを作ってみて欲しい。
・それをやってみて、最短距離はどのくらいになるのか、目安を知る。
・ある程度自由にやれる環境にあるなら、最短距離を走ってみる。その経験が見積もりになる。
・現実的な見積もりが見えてくる。
・まずフィージビリティで最短距離を走る。
■エンタープライズって何？・基幹システムとか業務システムとかを指すことが多い。
・この本だと、既存システムとの依存関係が避けられないシステムのことを「エンタープライズ」と言っている。
・依存がある連携先の相手は、アジャイルでやっているとは限らない。
・また、みんながアジャイルをやりたいと思っているわけではない。
・「エンタープライズ ＝ 大規模かどうか」ではない。
・DADはエンタープライズでアジャイルをやるための、具体性を意識している。
■お客さんを巻き込むには？・受託だとお客さんを巻き込むのは難しい。
・DADではリリースを「内部リリース」と「外部リリース」を分ける。その話は１４章に書いてある。
・インセプションデッキなしにプロジェクトを始めるのはありえない。
・DADでも方向付けフェーズを最初にやる。それは７章に書いてある。DADだと、開発構想書。
・お客を巻き込めると思わないほうがいい。
・スコット・アンブラーは、「アジャイルは、持ってるお金をうまく使う手法です」と説明した。
・顧客に巻き込まれるようにしないといけない。お客さんに対する啓蒙をもっとやるべき。
・受け身のお客さんを巻き込めるわけがない。
・お客さんが本当にITの予算にシビアになるか、キャッシュアウトを減らすんじゃなくてコストを減らす意識を持たないとダメ。
・それがDADが上手くいくか、いかないかの分かれ目。
・中間の良いトコ取りはありえない。
■翔泳社の方から書籍について一言・これまでスコット・アンブラーの本を３冊出版しているが、全く売れない！（一同、笑
・今回も編集長に３回くらい頭下げた。なのでDAD本は売れないと困る。。。
■楽天・川口さんの補足・P.102から、スプリントの前と後にこんな作業があるよ、と言及しているのがDAD本の良いトコ。
・アジャイルテスティング、という本も合わせて読むといい。
★感想：ホント参考になるお話が聞けて満足でした。
私はこの日まで4連休だったのですが、時間を作ってはDAD本を読んでました。
ですが、なにぶん分厚くて、どう読んでいけばいいのか悩みどころでした。。。
今回、岡さんの講演を聞いて、一気に視界が開けたと言うか、新しい気付きが多すぎてビビッた！
特にスライドP.52にある、書籍の各章がDADライフサイクルのどこに該当しているのかを示した図は、目から鱗でした。
この日の講演で学んだことを足がかりにDADの理解を広げていければいいなぁと思います。
あと、DADは1人で読むにはキツいので読書会あればいいのになぁ、と思ってたんですが、ちょうど @papanda さんがDADの読書会やるよーとツイートしてて、ナイスタイミング過ぎてフイたｗ
これはぜひ参加せねば。
皆様、ありがとうございましたー
2013/7/9(火) アジャイルサムライ読書会 横浜道場 「リファクタリング:技術的負債の返済」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/4513以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者さんは20人くらいでしょうか。
今回は「リファクタリング:技術的負債の返済」がテーマということもあり、通常会ながら参加者多いですね～
以下、個人メモ。
ウチのチームは4名です。ホワイトボードと付箋はこんなカンジ。
うちのチームのディスカッション、あと各チーム毎の発表の中で、以下のような意見が出ました。
---
■リファクタリングってどこまでやればいいの？・書籍に紹介されていたリファクタリングの例が、ディスカッションの際に善し悪しが分かれた。
→ ソースの読みやすさは主観が入る。人によって異なる。ペアプロの際にも衝突することがある。
→ んじゃ、リファクタリングの落としどころってどうやって決める？
・互いに合意ができればいいのでは。
・互いに相反する場合は、第三者の有識者に意見を仰いではどうか。
■リファクタリングの方法・リファクタリングの方法には２種類あるのでは。
①リファクタリングをタスクやチケットとして切り出し、リファクタリング自体を可視化する方法
②リファクタリングはプログラミングの中にまぶしてしまう方法
・@t_wada さんは②をお勧めしていた。
■ソースコードのチェック・コードの品質を保つには静的解析も有効では。
・コードレビューだと人手がどうしてもかかるけど、静的解析なら自動化できるし。
・コーディング規約で枠組みを決めるのも有効かも。
■リファクタリングとテストコード・テストコードがないと、リファクタリングって難しいよね。
・リファクタリングはテストコードがあることが前提。
・「リファクタリング」の定義に、テストがあること、があったはず。
・テストがないなら書けばいい。
■悪いコードってどんなん？・ドキュメントとコードが一致してないとか
・DBが正規化されていないとか
・バッチファイルがビルド職人の技になって保守できないとか
・etc
■コードレビューやってる？・プロダクトコードだけじゃなく、テストコードもレビューがないと辛い。
・レビューの前に、「読みやすさ」の認識合わせをしておくべきでは。
■リファクタリングとデグレードのジレンマ・「動いているコードに手を入れるな！」という思想がある。
・テストでガードしてからリファクタリングすればいいじゃん。
■リファクタリングと新機能開発のバランス・数回のイテレーションを回したあと、負債を返すイテレーションを１回入れるのはどうか？
→ 負債を返すだけのイテレーションって、お客さんに価値を提供してないじゃん。
・収入のすべてを借金を返すことに当てることはできない。
■技術的負債の原因・無知
・新しい技術をなんとなく入れてみた
・設計の失敗
■リファクタリングに必要となる能力・技術的な引き出しが必要になる。
・デザインパターンの知識があればなお良い。
■生産性・生産性はLOC(Line of Code)で測るプロジェクトがあった。
→ リファクタリングしたらコード行数が減って、生産性がマイナスになった（笑
・リファクタリングで浮いた工数を測る方法がない。
■リファクタリングの禁じ手・バグ修正とリファクタリングは同時にやるのはダメ。
■リファクタリングには２種類ある・次の機能を追加するためのリファクタリング
・コードを読み易くするためのリファクタリング
■バグ票・リリースしたコードに修正を加えるには、バグ票が必要になる。
→ つまり、バグ以外は修正の入口さえ用意されていない。。。
・バグ票を書いて、バグを修正する際に、その周辺をリファクタリングすれば良いのでは？
・バグ修正の工数を多めに申請して、リファクタリングも一緒にやっちゃえばいいのでは？
★感想：こんだけ暑いと、AEP読書会のようにビール飲みながらやりたい！
...と、激しく思った。思わずTryに書いてしまった。
リファクタリングはやったほうが良いとわかっていながら、上の理解を得るのに苦労している人が多そうに感じた。
特に、リファクタリング工数の捻出と、デグレードの危険性の点で。
バージョン管理と次章のTDDがこの手の問題に貢献するとは思いますが、いずれにせよ難題だ。。。
今日はいろんな意見を聞けて大変参考になりました。
これも頑張って読む！
道場主さん、スタッフさん、参加者のみなさんありがとうございました。
2013/7/6(土) 『JUnit実践入門』写経・実践会 in 横浜 #8 (最終回) #junitbook に参加してきました。
connpass
http://connpass.com/event/2590/Togetter
http://togetter.com/li/529598以下の書籍をターゲットとしたお勉強会なのです。
場所はいつもの横浜タネマキさんです。
参加者はいつもよりちょっと少なめの9人かな。
今回は最終回ということで、各自がこれまで学習したことをベースに実践する会となりました。
以下、個人メモ。
【ディスカッション】■JUnit実践入門を（新人君たちが）読む前、もしくは読んだ後にお薦めしたい本私が真っ先に思いついたのは以下の書籍です。
入社2年目、技術力を磨きたいという心が新鮮だった時期でもあり、一生懸命読んだもんです。
懐かしい。。。
あと、皆さんが挙げた書籍の中にも私が読んだものがけっこう混じってました。
「達人プログラマー」とか、結城さんのデザインパターン本、ナドナド。
（詳細はTogetter参照）
■新人が最初に学ぶのにおススメなプログラミング言語・Javascriptという意見が出た。
・エディタとブラウザがあれば簡単に始められる。
・基本的な構文は他の言語と同じように備えている。
・Hello Worldの出力も簡単。他の言語だと回りクドイことしないといけなかったり。
■アジャイル開発・そういや、さっきのおススメ本に「アジャイルサムライ」を入れるべき？
・でも、アジャイルを薦めるかどうかは、業種によるのでは。
・というのも、２次請け３次請けの立場でアジャイルの本を薦めるのは難しいことがある。
・でも、TDDなら１人でも出来る。そっからなら始められるのでは。
■スローテスト問題・スローテスト問題にどう対処するか？ → 10章に出てきたカテゴライズでテストを分ける。
・DBのテストデータを作るのに時間がかかる。なんかいい方法あるか？
・Excelで力技、という意見が多かった。
・Excelだと、セルをドラッグするとデータが連番の形で増幅しやすい。あとVBA使ってデータ増幅しやすい。
【TDD/ペアプロ実践】これまで学んだことを踏まえ、各自TDDなりペアプロなり実践する時間です。
私は10章だけまだ取り組んでいなかったので写経をし、そのあと18章の演習問題に取り組みました。
あと、先週の
「Javaで実践するリーダブルコードぷらす」のお題を完成させていなかったので取り組むつもりでした。
ちなみに隣の @uasano さんも @terahide27 さんとペア組んで、この課題に取り組んでました。
他にも予想外に、このネタがチラホラと話題になってました。この用紙、持参して良かったなぁ。
んでも私、10章と18章に取り組んでて、結局こちらのネタは実装できず。。。
あとは、ジョジョを読んでいた！第3部、怒涛のクライマックス！
★感想：この勉強会があったおかげで、JUnitをじっくり学ぶ機会が持てました。感謝！
やっぱこーゆう勉強会があるとモチベーションも上がるし、毎月勉強の機会が強制的にやってくる環境に自分を置けるのが良いです。
おかげさまでJUnitの基本を身につけることができました。あとは実践あるのみ！
あと、タネマキにジョジョ全巻が置いてあるのもGOOD！結局こんなに読んじまった。。。
主催者の @shinyaa31 さん、参加者のみなさん、ありがとうございました！
2013/6/27(木) SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/4507以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、アルティネットさんです。
参加者は10名かな。初参加1名です。新しい風が入るのは良いですね。
今日も相変わらず頼もしい！
ちなみに @t_wada さんがこの書籍を翻訳しようと思ったキッカケは、このEAVだったそうです。
そういう意味でも、非常に興味深い章ですね。
■アジェンダby @grimrose さん
今回は @grimrose さんがアジェンダ資料を作成し説明してくださいました。感謝。
テーブル継承をサポートしているORMの紹介など、本に無い部分まで紹介されているのが良いですね。
あと、その前の自己紹介の場で @t_wada さんより書籍の紹介がありました。
■エンタープライズ アプリケーションアーキテクチャパターン・通称：PofEAA
・@t_wada さんの机にあったはずだが、見当たらなかったので持ってこれなかったとのこと。
・5章のEAVネタは、この書籍に登場するらしい。
■ディスカッション今回も議論したいネタを全員で付箋に書き出し、グルーピングしました。
以下、個人メモ。
■EAVでよくある３パターン(1) カタログデータベース問題
(2) アンケートフォーム問題
(3) コードテーブル問題
■(1) カタログデータベース問題・製品の仕様を表す各項目は、製品毎に異なる。
・これを製品数分だけ別テーブルとして作成すると、テーブル数が膨大になる。
・この欠点を回避するためにEAVを採用することがある。
■(2) アンケートフォーム問題・アンケート項目は、アンケート毎に異なる。
・更に、エンドユーザがアンケート項目を決めれるようにすることがある。
（例：DoorKeeperのアンケートフォーム。あとRedmineの項目やナレッジデータベース等も該当する）
・以上より、アンケート項目は自由度が高いため、そもそも最初に項目を決め切れない。
・何が入ってくるかよくわからない、という前提がある。
・これらを踏まえてEAVを採用することがある。
■(3) コードテーブル問題・いろんなコードデータを１テーブルに突っ込むような汎用設計にする。
（例： [男性 = 1 , 女性 = 2] みたいな、コードと値のペアが多数登録されている状態）
・この設計の意図は、「テーブル数を減らしたい」という点にある。
・例えば、１つのテーブルにいろんなアプリを繋ぎたい場合に採用する。
・利点： DBでコードを一括管理できる。
■EAVを使うかの判断・バリエーションが有限なら、5.5節のテーブル継承でやりましょう。
・たとえ12種くらいあっても、よく似ている12種類なら継承で表せるかも、と考える。
・バリエーションが20未満くらいなら、サブタイプ（テーブル継承）で行くべき。
・テーブル継承にはやり方が３つある。
①シングルテーブル継承（略称： STI）
②具象テーブル継承
③クラステーブル継承（略称： CTI）
■@t_wadaさんのテーブル継承レクチャー・上で挙げた書籍 PofEAA に関するWebサイトの題材を使って、@t_wada さんがホワイトボードでレクチャーしてくださいました。感謝！
http://martinfowler.com/eaaCatalog/singleTableInheritance.html・[題材]： スポーツ選手のDBを作りましょう。
- Footballer
- Cricketer
- Bowler
- etc
・このテーブル設計の方法がわからなくて、EAVでやりがちなのは以下の設計。
(1)まず Playerテーブルを作る。カラムは以下２つ。
①id
②name
(2) 次に、EAV用に PlayerArgsテーブルを作る。カラムは以下３つ。
①id （Playerテーブルへの外部キー）
②attrname（キー）
③attrvalue（バリュー）
・でも、この程度ならEAVを使うべきではない。解決策として以下3種のテーブル継承を使う。
【1】シングルテーブル継承（STI）・PofEAA： Single Table Inheritance
http://martinfowler.com/eaaCatalog/singleTableInheritance.html・要するに、全部入りテーブル。
・type列に、"Footballer"とか判別タイプが入っている。
・typeの扱い方と、共通しない列にnullが入ることを受け入れられるのなら、使える設計。
・ORMはデフォルトでSTIを採用していることが多い。
・ただ、nullが多くてスカスカになる。密度が低くなる。
・データの偏りが性能に影響する。Footballerの人数が少なかったら、"Footballer"の検索が遅くなったりとか。
・なので、ちゃんとインデックスを設計しないといけない。
・DBのディスク容量を厳しく管理するプロジェクトは、STIを嫌がることがある。
・具象テーブル継承やCTIよりは、検索は速いことが多い。なぜなら全部入りテーブルなので、Joinが必要なくなるから。
【2】具象テーブル継承・PofEAA： Concrete Table Inheritance
http://martinfowler.com/eaaCatalog/concreteTableInheritance.html・Playerテーブルがない。
・絶対に必要なカラムだけテーブルに用意しましょう、という設計。
・nullでスカスカな状態は生まれない。
・でも、nameで検索したい時、全テーブルを検索しないといけない。なので串刺し検索に弱い。
・でも参照整合性とかには強い。
・あと、STIで必要だったtype列が必要がなくなる。
・1人が複数のプレーヤーをこなすマルチプレーヤーも扱える。
・STIだとマルチプレーヤを扱うのは無理。type列で区別すればいけるが、主キーが衝突するので、新しいキーを設計する必要が出てくる。
【3】クラステーブル継承（CTI）・PofEAA：
http://martinfowler.com/eaaCatalog/classTableInheritance.html・要するに、差分だけ各テーブルに持たせる設計。
・CTIだと、Bowlersの情報を取得するためには、CricketerテーブルとPlyaerテーブルとjoinしないとダメ。
・ただ、設計に一番柔軟がある。
・でもテーブル数が増える欠点がある。
---↑ ココまで@t_wadaさんのレクチャー ↑---
■どのテーブル継承を採用するかの判断ポイント・まず、RDBMSは動的項目を扱うのは無理、ということを認識する。
・最初はプロトタイプはSTIで作り初めて、行き詰まったらCTIとかリファクタリングを考える。
・STIはシンプルなので、ORMとかはデフォルトで使えることが多いのでコストが少ない。
・テーブルの継承関係が分かってくるまではSTIで行く。分かってきたらCTIとかにリファクタリングを考える。
■NoSQL・NoSQLとRDBMSを、アプリ側で切り替えて使い分けるアーキテクチャは有り得る。
・NoSQLはDBの補集合でしかない。どのNoSQLを使うべきか、理解してから使うべき。
・医療関係はRDBMSは辛い。というのも、カルテとかは人によって項目が違うので。
→ 医療機関ではCaché（キャシエ）というDBMSがよく使われる。
http://ja.wikipedia.org/wiki/Cach%C3%A9・HadoopとかはRDBMSではないが、SQLインタフェースが用意されるようになってきた。
→ データの貯め方はRDBMSではないが、インタフェースはSQLが使える。
■XMLデータベース・XMLデータをDBに入れる場合も、スキーマを定義すべき。
・XMLをLOBとかで丸ごと突っ込むと、検索時に全文検索エンジンが必要になったりして不便。
・XPathを書けるならXMLデータベースも有り。
■振り返り（KPT）1～5章が終わった区切りに、今回は振り返りとしてKPTをやりました。
参加者の皆さんがどんなことを考えてこの勉強会に参加してるのか、KPTを読むと伝わってきます。
この試みも良いですね。
★感想：@t_wada さんのテーブル継承レクチャーは大変分かりやすく、腑に落ちました。
本当にバリエーションがわからないからEAVにせざるを得ない状況なのか、考えることが重要ですね。
３つくらいバリエーションが出てくると、めんどくさいからEAVで全部いれちゃえばいいや、となっちゃいがちですが、そうなるとDBMSの良さが失われてしまいます。
ちなみに参加者のうち、EAVの経験者は2名のみでした。
私もEAVは経験したことはありませんでしたが、今後どっかで十分ハマりそうだなぁ、とは強く感じました。
この設計にいつか出会ったら、「あ、この構造、SQLアンチパターンのEAVだ！」みたいに気付けるといいなぁ。
そういう意味でも、EAVという「名前」を書籍で与えたのは大きいですねー。
最後に参加者の皆様、関係者の皆様ありがとうございましたー
-->
