makopi23のブログ

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

DevLOVE "「アジャイルソフトウェア要求」を学ぶ。" に参加しました

2014/3/25(火) DevLOVE "「アジャイルソフトウェア要求」を学ぶ。" に参加してきました。

DoorKeeper
http://devlove.doorkeeper.jp/events/9353

以下の書籍をターゲットとした勉強会なのです。
アジャイルソフトウェア要求 (Object Oriented SELECTION)アジャイルソフトウェア要求 (Object Oriented SELECTION)
(2014/02/11)
Dean Leffingwell

商品詳細を見る


場所は品川のオージス総研さんです。
参加者は30名くらいでしょうか。

この本の存在自体は以前から知っていたものの、今回このイベントが告知されるまでSAFeの本だと知りませんでした。。。
SAFeの日本語サイトはこちら~ http://www.scaledagileframework.com/jp/

ちなみに昨今、エンタープライズや大規模をターゲットとしたアジャイルの本が出始めてきたように感じてます。
去年のDAD本然り。(ただDADは大規模をターゲットとしているわけでは無いと思いますが)
そんな弊社も規模が大きなSIerで、私自身、自社にアジャイルを推進する立場にあったりするのです。
んで、なんかSAFeってのがあるらしいで~、くらいの知識しか無かったので、このイベントはチャンス!と思ったのでした。
まぁ自分の立場は置いといて、単なる好奇心によるところが大きかったり。


■ 講演 
講師は監訳者の藤井 拓さんです。当日のスライドはこちら。
機敏な製品リリースを可能にする企業内の連携モデルを提示するScaled Agile Framework (SAFe) のご紹介 from takuf


ちなみに、事前にA4両面印刷の説明資料も配布されました。
オモテ面はSAFeのBig Pictureです。
20140325_devlove1.jpg

裏面は書籍の構成を説明した資料になっていて、講演の後半で使いました。
この配布は親切設計で良いですね~

以下、講演中にメモした内容を復習を兼ねてダラダラ書き起こしてみる。


■ 書籍について
  • SAFe (Scaled Agile Framework)の本。SAFe 1.0の解説書になっている。
  • SAFeは、チームレベルのアジャイル開発を大規模開発にスケールアップするためのフレームワークである。


■ チームを超えたものの必要性 (P.5)
  • 現段階では、アジャイル開発は7人±2人くらいのチーム向けの、小規模開発向けのイメージになっている。
  • ただ、本当にアジャイル開発が企業の競争の武器になるには、チームだけじゃなく中間管理やPMOなどと連携しないといけない。
  • それが日本とアメリカの差なんじゃないか。
  • 欧米はアジャイル開発が企業全体の競争力となる道具になっている。
    • 規模も大規模もあり中規模もあり。AmazonとかSalesforceとかの事例も言われている。
    • 今は金融システムにもアジャイル開発を展開しようとしている。
    • 欧米ではキャズム理論でいうアーリーアダプターやアーリーマジョリティを超えつつある。
  • 日本も早くキャッチアップしていかないといけない。


■ 知識創造企業:知識創造のコンテキスト (P.6)
  • 戦略と実現性の兼ね合いを取る中間管理職(リーダー)の存在が大事である。
  • SAFeは、知識創造のコンテキストを形成することを助け、アジャイル企業への転換を支援する。
    • ここを理解することが大事。


■ Scaled Agile Framework (SAFe) とは (P.7)
  • 3層構造となっている。
    • 一番上の層: ポートフォリオ(戦略とか企画とか)
    • 真ん中の層:、プログラム(複数チームを束ねて開発する体制とか)
    • 一番下の層: チーム(スクラムチームとか)
  • ここで言う「プログラム」とは「大規模プロジェクト」のこと。
  • 3層が一丸となってプロダクトを作っていくのがSAFeである。


■ Scaled Agile Frameworkの起源 (P.8)
  • SAFeにはいくつかの源流がある。
    • まず「反復的でインクリメンタルな開発」があって、その下に「アジャイル開発」がある。
    • 同じ方向性を向いてプロダクトを作っていくということで「リーン思考」を取り入れている。
    • リーンとアジャイルを融合した「プロダクト開発フロー」がある。
  • これらからSAFeが構成されている。


■ フレームワークの考案者: Dean Leffingwell (P.9)
  • 彼が面白いのは、いろんな側面を持っている点にある。
    • 著者: 要求管理の方法論とかツールの創業者である。
    • コーチ: アジャイルコーチとか要求開発のエキスパートでもある。
    • 役員: Rational社に買収されて、上級副社長になって、そのあと独立して自分の会社を興した。
  • 3つの側面をもっているのが面白い。


■ 知識創造のコンテキストとScaled Agile Framework (SAFe) (P.11)
  • SAFeの構成要素
    • 要求プラクティス
    • リーン (後継者の育成)
    • プロダクト開発フロー (どうやって効率的に作るか)
    • スクラムとXP


■ リーン思考が必要な手段を提供する (P.12~P.15)
  • トヨタウェイをベースに、価値をできるだけ早く届ける。
  • その2本柱が「改善」と「人々に対する敬意」である。
  • 真ん中に「プロダクト開発フロー」がある。
    • これはややこしい。。。
    • 基となる概念は、TPSとか、待ち行列理論とか、軍の用兵術がある。
  • 顧客から注文を受けてからお金を頂くまでの所要時間に注目し、無駄を省きましょう。 by 大野耐一
  • 価値の納品までの過程のサイクルタイムを短くする。


■ プロダクト開発フロー: 待ち行列とバラツキ (P.16)
  • 基本となるのは「リトルの法則」である。
  • 単純にいうと、待ち時間を減らすためには、「行列の長さを減らす」か「スループットを上げる」か。
    • でもそんなに単純ではない。
    • 例えば待ち行列が要求だったり設計だったりした場合、それらはバラバラにやってくる。
    • 例えば稼働率が変わるとスループットが変わる。このように、バラツキの要因がたくさんある。


■ プロダクト開発フロー: 経済的効果を考える (P.17)
  • 待ち行列は「製造」と「ソフトウェア開発」で異なる。
    • 製造: FIFOで、到着した順に処理する。
    • ソフトウェア開発: 製造と違い、待ち行列の順番を変えられる。それにより価値を早く高めて経済的な成果を上げられる。
  • TOCとか制約理論は製造よりの考え方で、通信系の待ち行列の考え方とはちょっと違う。


■ より速くお金を生む (P.18)
  • 「遅延のコスト」という概念がある。
    • プロダクトの価値は、市場に投入された時点の価値が最大で、時間とともに下がる。
    • プロダクトの投入の速さによって価値が変わる。
  • 「遅延のコスト」が発生するプロダクトは、早くリリースすることが大事。
  • プロダクト開発論の考え方が、SAFeの思想とプロセスのバックボーンになっている。


■ ポートフォリオレベル: 投資テーマ (P.20)
  • 投資テーマ、投資額の決定
    • どの分野にどのくらい投資するか、1年とかの期間で予算を割り当てしていく。
    • 予算が決まったら、作るものを決める。


■ ポートフォリオレベル: エピック (P.21)
  • ビジネスエピック
    • 新しいプロダクトに関する取り組み
  • アーキテクチャエピック
    • プロダクトには直結しないが、プロダクトを作るために内部的に役立つもの


■ ポートフォリオレベル: ポートフォリオカンバンシステム (P.22)
  • 何を作るかのアイデアを集め、バックログに追加して優先順位づけをして絞り込み、開発する。
  • ここでカンバンを使う。


■ ポートフォリオレベルの例 (P.23)
  • 投資テーマとして「インテリジェント家電」があるとする。
  • そのビジネスエピックの候補として以下が挙がった。
    • お掃除ロボット
    • インテリジェント冷蔵庫
    • インテリジェント調理器
  • そこから、価値が高いものから選ぶ。
  • 費用対効果を審査して、OKが出れば「ビジネスエピック」になる。
  • 選ばれたものがポートフォリオバックログ(開発候補)になる。


■ プログラムレベル: 開発 (P.24)
  • 開発すると決まったものを作るのがプログラムレベル。
  • プロダクトオーナーじゃなくて「プロダクト管理者」が登場する。
  • ここで言う「プログラム」とは、大規模開発のことを指す。


■ プログラムレベル: ビジョンとフィーチャー (P.25)
  • 「エピック」を構成する機能を分解したものが「フィーチャー」である。
  • 「ビジョン」はそのシステムを開発する意義(競合他社との差異など)を説明するドキュメントである。


■ アジャイルリリース列車(ART) (P.26)
  • ビジョンやフィーチャーが決まると、アジャイルリリース列車を編成して開発を進める。
  • ARTは5~12のチーム 50~100名からなる組織。
  • 人数的にも期間的にも、スクラムをスケールアップしている。
  • 8~12週ごとに開発したものを統合し、出荷可能なインクリメント(PSI)を評価して開発を進めていく。
  • スクラムのチームを自然にスケールアップしたものがアジャイルリリース列車である。
  • スクラムと対比するとわかりやすい。

■ 確実に納品するために同期する (P.27)
  • すべてのチームが同じ周期で開発する。
  • 各チームが作ったものを統合する専任として「システムチーム」がいる。
  • PSIの前の最後にHIPスプリントというのがある。ここで品質安定化をする。
  • PSIを使って、動くソフトウェアを評価して、次の計画を立てていく。


■ プログラムレベルの例 (P.28)
  • まず「ビジネスエピック」を設定する。
  • ビジネスエピックを「フィーチャー」として分解し、フィーチャー毎に担当するチームが編成される。
  • チーム毎にスプリントでフィーチャーを開発していく。
  • 最後にPSIのタイミングで、最低限の機能を達成できているか進捗状況を評価していく。
  • フィーチャーを貯めているのが「プログラムバックログ」である。
  • プログラムを実行することで、分野ごとにアジャイルリリース列車が並行で走っていく。
  • それで軌道修正をかけながらプロダクトを開発していく。


■ アジャイルチーム (P.30)
  • 「フィーチャー」は「ストーリー」に分解され、「チームバックログ」に積まれる。
  • ストーリーは2週間以内に開発できる粒度となる。


■ コード品質 (P.31)
  • 全体の品質を保証するために技術的なプラクティスを使っていく。XPのプラクティスが多い。
  • アーキテクチャを初期の段階である程度は作りましょう、という点をSAFeは強調している。


■ ベクトル合わせ (P.32)
  • エピックを決めて、フィーチャーに分解して、バックログに積んで、ストーリーになって、開発して、といった作業の詳細は、上の立場の人が全部決めるのではない。
  • チームが一丸となって、お互いに責任分担しながらベクトル合わせて進めていく必要がある。


■ 土台: リーダーシップ (P.33)
  • 中間管理職はリーダーシップ、部下の問題解決能力を育成していくことが重要である。


■ Q&A その1
講演の途中で、質疑応答の時間が取られました。

  • Q1.
    • Big Pictureの真ん中の層(プログラム層)で舵を取る人はプロダクトマネジメントに該当すると思うが、プロジェクトマネジメントは一番下の層にいるのか?
  • A1.
    • SAFeにプロジェクトマネージャ(PM)という役割はない。
    • プロダクトリリース列車の横にいる「リリース列車エンジニア」が、スーパーエンジニアスクラムエンジニアに相当する。
    • ファシリテートしたり相談役になったりと、スクラムマスターをスケールアップしたものに該当する。
    • プロダクトオーナーは、SAFeでは「技術も分かり、詳細を決めていく人」を指す。
    • 逆にプロダクト管理者は、ビジネスニーズを重視する人。技術はあんまりわからなくても良い。


  • Q2.
    • 「リリース列車エンジニア」の隣に「UX専門家」がいるが、これにについて教えてほしい。
  • A2.
    • これは共有リソースの役割がある。
    • UX専門家は、「専門チームとして集中させるべき」という考え方と「各チームに配置すべき」という2つの考え方がある。
    • どちらの考え方にも利点と欠点がある。
    • ただ、まず中央で決めて、UX専門化はチームに参画しながら作業したほうがいい。
    • UXデザインを先行して検討・実施し、概念レベルで考えてから実装するようにすることで、手戻りの無駄を減らすべき。
    • トライ&エラーでやるよりも、UXを安定化させてから実装にかかる方が良いのでは。


  • Q3.
    • 機能ごとにチームを分けると、機能要求がたくさん発生するチームと、そうでないチームが出るのでは。
    • そうなると開発規模とかは各チームで一律にならないと思うが、その辺はどうなのか?
  • A3.
    • まず、各チームの人数は「7人±2人」で揃える。
    • そこで、厳格に2週間毎に作ったものを統合していくのがSAFeの考え方である。
    • PSIで各チームが作ったものを統合し、大きいレベルの機能が動くものを作り、評価に耐えるようにする。
    • PSIは組み合わせテストのようなイメージ。残った細かいバグ対応とかをPSIで実施する。
    • 「システムチーム」が2週間毎に各チームの成果物を吸い上げて統合し、簡単なテストをして各チームに評価を返す。
    • このサイクルを進めていく。


■ 書籍の構成について
Q&Aの次は、配布資料の裏面に書いてあった、書籍の構成に関する説明です。
マインドマップで表現されています。あと、藤井さんの手書き説明もちらっとありました。

20140325_devlove2.jpg
  • 書籍は4部構成となっている。

  • 第Ⅰ部  「概要」
    • プロダクト開発フローの7つのテーマは説明が省略されてて、かなり読みづらいかも。
    • SAFeの概要として「3つレベル」が紹介されているが、ここもDeanの前の書籍の内容を知ってることが前提となっていて、やや説明が不親切かもしれない。

  • 第Ⅱ部 「チームのためのアジャイル要素」
    • 「プロダクトオーナーの役割」の章がある。POは技術とビジネスを分けて考えたほうがいいんじゃないか。一人が両方を担うのは難しい。

  • 第Ⅲ部 「プログラムのためのアジャイル要求」
    • 「優先順位付け」の章があるが、フィーチャーの優先順位付けはPJの成功に大きく影響するので重要である。
    • プロダクト開発フローの考え方を取り入れている。
    • どういう人をプロダクト管理者として育成すべきか、みたいな事例の話もある。
    • リリース開発列車のコンセプトの話とかもある。
    • ユースケースの章はアリスター・コーバーンがかなりコメントしてくださった。

  • 第Ⅳ部 「ポートフォリオのためのアジャイル要求」
    • アーキテクトとチームはどう関わるべきかといった話がある。
    • アーキテクトが全部決めるんじゃなく、チームと互いに決めるべき、という話とか。
    • モデリングをちゃんとしましょう、という話とか。
    • ドメインモデリングとかアーキテクチャモデリングの話とか。
    • アーキテクチャレベルまで再構成しないといけなくなった場合、プロダクトを提供できる状態のままアーキテクチャを変えるためにはどういうやりかたがあるか、みたいな話もある。



■ Q&A その2

最後に、再度質疑応答の時間が取られました。


  • Q4.
    • SAFeのバージョンが、書籍は1.0で、日本語版サイトは2.1で、本家最新は2.5で、すべて異なっている。
    • バージョン差異のギャップはあるか?
  • A4.
    • バージョン1と2.1で大きく変わった点として、バリューストリームの考えが2.0で入った点がある。Big Pictureの図の左上あたり。
    • 旧バージョンでガバナンスが強すぎたところは、改訂が入ったりしている。
    • すべてをカンバンシステムに通すのではないようにしたり、「テーマ」から「エピック」を飛ばして「フィーチャー」に行くパスとかも最新版では許している。
    • ポートフォリオレベルもけっこう変わっている。
    • バージョン2.5は、DevOpsという言葉も入ってきている。
    • バージョンアップの情報を順に追えるような日本語の情報は公開されていない。。。


  • Q5.
    • アジャイルに詳しくない人に「エピック」と「フィーチャー」の違いをどう説明すれば良いか?
  • A5.
    • 「エピック」は、システムそのものを表す。例えば「インテリジェント掃除機」みたいに。
    • 「フィーチャー」は、プロダクトが持つ機能を表す。例えば「自動でお掃除をする」みたいに。
    • 「フィーチャー」はPSIというサイクルで実現できる粒度に切り分けられる。
    • 「アーキテクチャエピック」は、MS Officeの各製品間で共通で利用する機能とかを表す。「クラウド連携機能」みたいに。


  • Q6
    • SAFeでここだけ押さえておけ、的なものはあるか?
  • A6.
    • SAFeで難しいのは一番上の層のポートフォリオレベル。
    • というのも、企業毎にの戦略の練り方とかが異なるので、そこを白紙に戻してやるのは難しい。
    • 更に、企画と開発が別会社とかもある。なので、会社間を超えるのは難しい。
    • なので、真ん中の「プログラム」の層のアジャイルリリース列車が基本的な部分じゃないかな、と思う。
    • アジャイルをスケールアップする本を何冊か読んだが、チーム間の連携を具体的に述べてるのがSAFeの特徴かな、と思う。


  • Q7.
    • SAFeはオープンか?
  • A7.
    • SAFeはPublicなので、Webサイトを見れば明日から使える。SAFeのコンテンツ自体は無償。
    • ただ、SAFeのトレーニングとかはビジネスになっている。


  • Q8.
    • SAFeの構成要素にScrumやXPやリーンなどがあるが、既存のプラクティスありき過ぎでは?
  • A8.
    • 新しいものを組織に導入するには2パターンある。
    • 1つは、自分でゼロからフレームワークを考えて強い組織を目指すパターン。
    • もう1つは、既存のプラクティスなどを利用して早く教育して上に持っていくパターン。
    • 2つのパターンは、どっちもどっちである。
    • 後者の典型は「学校教育」。学校教育は既存のカリキュラムで一律教育するが、それでも天才は出るので、天才が出るのは前者、というわけでもない。
    • ビジネスはコストなどを考慮しなければいけないので、なんぜもゼロから、と行かない面がある。



■ 最後に、藤井さんが思う「SAFeの良いトコ」
  • 「経営者」はアジャイルが企業を元気にしていくれるという期待感を持ちつつ、「開発者」はアジャイルをやりたいという気持ちを持っている。
  • でも、「経営者」と「開発者」の間にいる中間管理職の層は、アジャイルに危険性を感じ、危機感を持っている。
  • SAFeはそこにハマる。
  • 中間層向けに説明している本なので、説得材料として使ってもらえればいいと思う。


★感想:
SAFeについて一夜で学べる、とてもよい機会になりました。
しかも書籍を3割引きで現地販売していて、つい買ってしまった!3割引きはデカいですよ。
んでも、やっぱこれだけ分厚いとね。。。


・・・な~んて呟いていたら


読書会もやるそうな。イヤッホーー!
ってことで購入した書籍を読むモチベーションも上がります。

SAFeは人によって意見も分かれるところも多々あると思うのですが、まず私は中身をきちんと知るところから。。。

イベント関係者の皆様、ありがとうございました~
スポンサーサイト

SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました

2014/3/20(木) SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加してきました。

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

以下の書籍をターゲットとした読書会なのです。
SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


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

参加者は9人かな。
初参加も1人いらっしゃいました。新しい風が入るのは良いですね~

今回は16章「プアマンズ・サーチエンジン」が対象範囲でした。


■アジェンダ
今回は @natsu_nanana さんが急なお仕事で参加できないということで、急遽 @t_wada さんが章の説明&仕切り役を担ってくださいました。感謝!
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版) from Takuto Wada

過去の講演資料を使って「プアマンズ・サーチエンジン」のポイントをわかりやすく説明する対応力、さすがです。


■ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。
20140320_sqlap1.jpg
激しくピンボケした。。。
付箋と太ペンを用意してくださった @inda_re さん、ありがとーございました。
---

■ アンチパターン
  • 中間一致のLIKE検索はインデックスが使えない(フルスキャンになる)


■ 単語境界
  • P.175のREGEXP '[[:<:]]one[[:>:]]は、単語境界にマッチさせるSQL上の正規表現である。
  • 英語は単語間にスペースがあるが、日本語は明確な単語境界が無い。
  → そのため、分かち書きのライブラリと併用することが多い。
  → 日本語は、そもそも正規表現の世界以前の問題がある。


■ 正規表現
  • 正規表現はSQL標準に入ってきているので、頑張れば書ける。
  • ただ、SQL標準に正規表現を追加したことで、仕様がとても大きくなってしまった。
  (剰余演算子とLIKE演算子の見分けがつかない問題などの対処で、解析が必要になる)
  • 中間一致はインデックスが使えないが、前方一致はインデックスが使える。
  • LIKE述語の2つのワイルドカードの間にPreparedStatementのプレースホルダを入れ、LIKE "%?%" のように書いてしまうことがある。
  → ダブルクォートで ? を囲むと正しく動作しない。よくハマる。
  • 複雑な正規表現を考え始めたら、それは何かがおかしい、と疑うべき。


■ 解決策
  1. ベンダー拡張の全文検索機能
  2. サードパーティーの全文検索エンジン
  3. 転置インデックスの自作


■ 1.ベンダー拡張の全文検索機能
  • 全文検索のニーズはたくさんあるが、標準がない。
  • ベンダー拡張は全部方言になるが、製品の差別化要因としてアピールしてくることも多い。
  • MySQLのフルテキストインデックスは、MyISAMだけでなくInnoDBでも使えるようになった。
    • ただし、日本語が使えない。。。
    • 書籍の最新版では、その旨を脚注に追記している。
  • Oracleはデフォルトでテキストインデックスをサポートしているので使いやすいかもしれない。
  • SQL ServerはDBを停止させて設定しないと使えないのでハードルが高い。
  • iPhoneのSQLiteでテキスト拡張が使えるかどうかは、FTS拡張を有効化するようにビルドされたかに左右される。
  • 見事に全ベンダーの全文検索が違う。


■ 2.サードパーティーの全文検索エンジン
  • Sphinx Searchはミドルウェアみたいな検索エンジン。
  • Sphinxでググると、著名なドキュメント作成プログラムの方がヒットするので、検索がnoisyだったりする。
  • Apache Luceneを使ってる人は多い。Apache経由でSolrを使うパターンが多い。
  • 日本だと Groonga というオープンソースのカラムストア機能付き全文検索エンジンがある。
    • http://groonga.org/ja/
    • バインディングライブラリがいろいろあって、それを使うことも多い。
  • ドキュメントの全文検索エンジンとしては Namazu というものがある。


■ 3.転置インデックスの自作
  • 「全文検索の仕組みを自分で作っちゃおう」という、だいぶオレオレな解決策。
  • ストアドプロシージャとトリガーが使用できれば、それっぽいことはまぁまぁ出来る。
  • いきなりインデックスを作るのではなく、検索されたら1回目はフルスキャンさせる。
    • その結果をインデックスに取っておき、次に検索が来たらそのインデックスを使うようにする。
    • 1回目の検索はパフォーマンスが悪いが、次の検索からは速くなる。
    • そのため、裏で先に検索を流しておき、コツコツとインデックスを先回りで作っておくなどの工夫が考えられる。
  • 検索頻度を表すカラムを追加しておき、ストアドを使って裏で事前に高頻度キーワードのインデックスを作成する、という対応もありえる。
  • 思想は「1回目の検索が遅いのはかんべんしてください。ただし2回目以降の検索は速いので許してください」
  • 転置インデックスの更新同期はトリガーを使って取る。
    • オンライン業務に影響を与えないよう、トランザクションに注意する必要がある。


■ 解決策の選択指針
  • まずベンダ拡張を探し、最後の手段として転置インデックスという方法もあるよ、というくらい


■ タイトル 「プアマンズ・サーチエンジン」 の由来
  • 「プアマンズ(poor man's)」という語から始まる単語は、英語圏では結構使われるとのこと。
  • なので「プアマンズ」は使いたくないと思い、最初はタイトルを「手作りサーチエンジン」にしようとした。
  • ところが、この章の最後「転置インデックスの自作」で、著者が本当に"手作り"してしまったので、その命名は止めたw


■ パターンマッチ述語と全文検索エンジンの速度比較
  • 一般に、全文検索はインデックスサーチより速い。
  • ただし、速度比は検索対象の複雑さとかAnd/OR検索などの条件による。
  • And検索はSQLだとだいぶ辛い。
  • grepが100倍くらい速くなった、という経験談あり。
  • ただし特定の状況では何倍も遅くなった。
    • それはUTF-8のオプティマイザチューニングのせいだった。
    • UNICODEで日本語を扱うとなると、文字の正規化とかが必要になるので、簡単に地獄になる。。。
    • 濁点を独立させるか否かの判断とか、悲惨。。。


■ 転置インデックスと交差テーブル(p.183)
  • KeywordsテーブルのkeywordカラムにUNIQUE KEY制約を付与しているんだから、keyword_idカラムっていらなくね?
  • いや、そうじゃない。
  • もし交差テーブルを設けなかったら、1つのkeywordに対して複数のbug_idが紐付くため、多対多の組み合わせの数だけレコードが存在することになる。
  • そうなると、keywordの文字列×組み合わせ数分だけDB容量が必要となってしまう。
  • 頻出するkeywordが長かったりすると、かなりの容量を食うことになる。
  • 検索回数を保管するカラムを用意する場合も、keywordsテーブルを分離しておけばカラム追加で対応できる。


■ あいまい検索時にSQLを2回発行する是非
  • 以下のようにSQLを2回に分けて発行してはどうか?
    • Select count(*) from Table Where xxx LIKE %one%;
    • Select カラム名 from Table Where xxx LIKE %one%;
    • 1個目のSQLでは件数だけ取得して、その値が閾値以内なら2個目のSQLでデータを取得するようにする。
  • いや、SQLを2回に分けても速度的に意味はない。
  • ただしSQLのヒット件数が多すぎてメモリに乗らない場合は、1個目のSQLで打ち切る設計は王道だったりする。
  • Webの一覧画面に表示する件数とページ送りについて考える時によく遭遇する。
  • この辺のTogetterが参考になる。ちなみに1個目の話題は、2週間くらい前にホットエントリになっていた。
  • 検索ヒット件数は正確な数字を返さない、という設計も手である。
    • 例えばGoogle検索とかはその典型。
    • ヒット件数をキャッシュしておき、大体の数字を返す。
  • 一覧画面のページ送りとかページ戻りとかは、律儀に毎回検索するのではなく、裏で非同期処理で前後のページのデータを先読みしておくなどの工夫をする。
    • ただし、ページをめくる速度が速すぎると非同期処理が間に合わないことがある点に注意。


■ 複数カラムからのあいまい検索
  • 複数カラムから全文検索したい時、どーすれば良いか?
  • 複数カラムをconcatすると、1カラム目の末尾と2カラム名の冒頭の単語が合成されて、検索にヒットするのでダメ。
  • 並列処理で複数カラムそれぞれに全文検索をかけれるならば、処理性能的に有利になるかも。
  • 16.5.6節の最初のSQLは、複数カラムからのあいまい検索を実現しているので参考になる。


■ 検索方法の選択をユーザに任せる
  • 検索用のテキストボックスに「前方一致」と「中間一致」のラジオボタンを設けておき、ユーザに選択させる設計は見たことがある。
  • 氏名による検索の場合、珍しい苗字の人は苗字のみ検索でヒットするので苗字だけ入力させ、田中さんとか佐藤さんとかありふれた名前の場合は苗字と名前の両方を入力させて検索させる、という設計があった。


■ まとめ
  • SQLだけで頑張らない。
  • SQL標準外の力を借りる。

★感想:
全文検索エンジンって、私は使ったこともないし、それどころかこの章を読むまでは存在さえ知りませんでした。
あいまい検索ってのは身近な要件なので、今後、使用を検討することがあるかもしれないと思いました。

ちなみに弊社でよく使うHiRDBにもあるかどうか調べてみたら、あった。。。
ミッションクリティカル業務向け全文検索エンジン 「HiRDB Text Search Plug-in」

あと、読書会の最後に @grimrose さんから鹿児島のお土産、おまんじゅう戴きました~
薩摩のお芋のおまんじゅう。
ちなみに「薩摩」と聞けば、私は「サツマイモ」よりも「薩摩藩」が真っ先に思い浮かぶ。
ちょうど司馬遼太郎の「竜馬がゆく」を読み直してたところだったんですが、幕末の薩摩藩は熱い志を持った漢達が多くて泣ける。。。

次回、17章「スパゲティクエリ」は私が最初の説明を担当することになったので、早めに予習することにしよう。
皆様、ありがとうございました~


■おまけ:過去の「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

SQLアンチパターン読書会 「ランダムセレクション」に参加しました

2014/2/27(木) SQLアンチパターン読書会 「ランダムセレクション」に参加してきました。

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

以下の書籍をターゲットとした読書会なのです。
SQLアンチパターンSQLアンチパターン
(2013/01/26)
Bill Karwin

商品詳細を見る


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

参加者は9人かな。
この日は @yokatsuki さんからどらやきの差し入れが!美味しかった~

今回は15章「ランダムセレクション」が対象範囲でした。


■15章「ランダムセレクション」の説明
今回は主催の @natsu_nanana さんがスライドを作成して紹介してくださいました。

SQLアンチパターン読書会 15章 ランダムセレクション 説明資料 from Nao Yamamoto

図を上手く使ってわかりやすく纏めた資料です。
15.5.4節のオフセットについて質問して、疑問も解決できました。


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

以下、ディスカッション時の個人メモ。
---

■15.5.4節「オフセットを用いてランダムに行を選択する」
・OFFSET句は、ヒット件数のうち何番目を取ってくるかを指定するので、この方法は欠番があっても正しく動作する。
・Oracle Database 12cからfetch構文(FETCH FIRST n ROWS ONLY)が使えるようになった。
 - Oracle Database 12cリリース1 (12.1)の新機能: 問合せの行制限と行オフセットのネイティブSQLでのサポート
 - Oracle Database SQL言語リファレンス 12cリリース1 (12.1) 「row_limiting_clause: 行制限の例」
・SQL Serverだと、TOP句とPERCENT句を使用することで、結果セットの件数をパーセンテージで制限できる。


■ランダム性
・人間が感じるランダム性とSQLのランダム性は違う。
・WEB+DB PRESSの増井さんの記事 「10000件くらいだと均等に感じるが、100件くらいだと偏りがあるよね」
・@t_wada さんの知り合いの @kagamihoge さんが、ランダム性に関する記事を書いている。
 - kagamihogeの日記 「OracleのSAMPLE句によるランダムセレクションのばらつきを調べる」
  → 後半の行にいけばいくほど出現頻度が下がっていく、とのと興味深い調査結果が示されている。
 - kagamihogeの日記 「Oracleのdbms_random.valueで1とmaxの間によるランダムセレクションのばらつきを調べる」
  → DBMS_RANDOMパッケージのVALUEファンクションを使うと均等な結果が得られた、との調査結果。
・そもそもランダムって何?
 → 乱数であることの証明は数学的にできないらしい。乱数を定義するとそこで自己矛盾が起きてしまう。
 → そのため乱数は正式には「疑似乱数」と言う。
・きしださんが「きしだのはてな」というブログで乱数について書いている。
 http://d.hatena.ne.jp/nowokay/20081110/1226302607
 - Javaには「java.util.Random」と「java.security.SecureRandom」という2種類のクラスがある。
 - 前者は偏りがあり、後者はちゃんとばらつく結果が得られた。
 - 統計用などでまともに乱数を使うには Mersenne Twister を使いましょう。


■15.2節「ORDER BY RAND()」
・この構文の意味が分からない、こんなんできたんだ初めて知ったわ、というご意見がチラホラ。私も!
・すべての行に対して乱数を振って、その乱数値を基準にソートする動作になるっぽい?
 → すべての行に対して乱数が振られ、当然ソート時にインデックスも効かないので性能は極端に悪い。
 (参考) esehara / gist:5925390 「ORDER BY RAND() 使うな」
・「SQL ランダム」でググるとたくさんヒットする。これは発見だった。みんな悩んでるんだな…
・「ORDER BY RAND()の性能が悪いのはSELECT句に*を指定しているためで、*ではなくカラムを指定すると速くなる」という見解がよく見られる。
 → それは単純にカラム数の違いからくる話である。*がランダムソートが遅い直接の原因ではない。
・伊藤直也氏もブログで order by rand()について言及していた。
 - naoyaのはてなダイアリー: MySQL の order by rand()
 - ブログのコメント欄にある「order by rand()を使ったらいいんじゃないか会議」とは・・・
・"ORDER BY RAND()"のGoogleのヒット優先度を下げたい!
・このパターンを見たら「SQLアンチパターンを読め!」と言いたい。
・SQL Serverにはランダムにデータを抽出したい場合のために NEWID() という組み込み関数が用意されている。
 → 固定長の重複しないUUID(Universally Unique Identifier)が割り振られる。
・闇が深いよね・・・
・Order By Randなんて、フツーは思いつかないよね・・・


■15.5節 解決策
・乱数生成の解決策には、厳密さと速さのバランスがある。
・例えば40件から1件を選ぶくらいじゃ、厳密さはあまり要求されない。
・それに対して金銭が絡むシステムなどは、説明責任があるのでアルゴリズムを開示しないといけない。
・15.5.2節で欠番がある場合の解決策が紹介されているが、「欠番がある = 物理削除している」ということ。
・これがもし論理削除でやっていたら、更に闇になるw
・ちなみに「論理削除」はアンチパターンとして書籍に入れたかった・・・
・欠番だったらもう一度リトライ検索する、というロジックもコンテキストによっては解決策になる。
 → 欠番が多いとリトライ検索が多くなるので使えないが、欠番が十分少ないなら実用できる。
・ランダムに40個の数値を取ってくる要件には、この本の解決案が使えないやつがある。
 → 一本釣り系やLimit Offsetは使えなかったりする。


■乱数の生成
・確率に重みを付けたい場合、人間が感じるランダムは複雑なロジックになることが多いので、SQLではなくプログラミング側で実現したほうが良い。
・15.5.3節のようにSQLを2回投げる場合は、トランザクションに注意する必要がある。
 → ロックをかけるか、同時アクセスが万が一あった場合はしゃあないと諦めるか、などの戦略は、トランザクション分離レベルとか業務要件とかを考慮して決める必要がある。
・オンラインゲームのガチャを実現するには、先に抽選の当選リストを作ってしまう方法もある。
・乱数生成をDB側に寄せる場合は以下が考えられる。
 - APサーバが貧弱な場合。(一般に、DBサーバはCPUもメモリもAPサーバより潤沢)
 - DBからランダム値を取ってこないといけないアプリがたくさんある場合。
 - 件数が多い場合。
 - DBでなんでもやろうとしている会社の場合。
 - アーキテクチャがC/Sの場合。(クラサバ時代はこの発想が多かったかもしれない)
・DBの方がアプリより寿命が長いので、使用するロジックは寿命の長いDB側に寄せておきたいという考えもある。


★感想:
ランダムセレクションなんてやる奴ホントおるんか・・・?
な~んて最初は思ってたんですが、この日のディスカッションで思いのほか多くの人が悩んでいるのだなぁ、と驚きました。
いろいろ闇が深いようで・・・
あと、LIMITやFETCHやら、ベンダ依存も多いですね。
このへんは、どのDBMSを使っているかで解決策も分かれそうです。
とりあえず、乱数が必要になったら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

FC2Ad