┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.321 2010/04/07
■ I N D E X
┃
┣【プログラミング】ドキュメント指向データベースMongoDB [3]
┣【要件定義】要求とか要件についての四方山話 [2]
┃ 〜ユーザーストーリーのワークショップで感じたこと〜
┗ 編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】ドキュメント指向データベースMongoDB [3]
MongoDBの最新安定版、1.4.0がリリースされました。
http://www.mongodb.org/display/DOCS/1.4+Release+Notes
クエリ構文の拡張や空間インデックスのサポートなど、面白そうな変更が加え
られています。データベースは1.2系と互換性がありますので、すでにお使いの
方はバージョンアップを検討されてはいかがでしょうか。
● ドキュメントとBSON
さて、今回はMongoDBのドキュメントについて詳しく見ていきましょう。MongoDB
のドキュメントは、BSON(Binary JSON)[*1]と呼ばれる独自の形式で格納されま
す。これはJSONをベースとして、オブジェクト参照やバイナリデータを扱える
よう拡張したものです。
MongoDBはBSONを採用することで通常のRDBMSとは異なる特性を備えています。
第1に、MongoDBのドキュメントは固定したスキーマを持ちません。1つのコレク
ション中に異なる構造のドキュメントを混在させることができます。
> db.foo.insert({a: 1})
> db.foo.insert({x: 2, y: 3})
また、RDBMSと比較して多くのデータ型をサポートしています。文字列や数値は
もちろんのこと、正規表現や配列、オブジェクトに至るまで値として使用でき
ます。
> db.foo.insert({str: 'hello', int: 100, regexp: /^[A-Z].*/})
> db.foo.insert({ary: [1, 2, 'foo'], obj: {x: 1, y: 2})
2つ目の例のように、ドキュメントの値として埋め込まれたオブジェクトのこと
を「Embedded Document」と呼びます。RDBMSでは関連を使って間接的に表現し
ていた構造を、MongoDBではより直截的に表現できます。
● 基本的なクエリ
MongoDBは、格納されたドキュメントを取り出すためのクエリ機能を備えていま
す。シンプルなKVSではIDの完全一致でしか検索できないものもありますが、
MongoDBはRDBMSに近い柔軟なクエリをサポートします。
検索には db.<コレクション名>.find(<セレクタ>) を使います。セレクタは検
索条件を表すBSONオブジェクトです。一番単純な形式は {プロパティ: 値} と
なります。
> db.foo.find()
コレクションfooに格納されているすべてのドキュメント
> db.foo.find({x: 1})
プロパティxが1に等しいドキュメント
> db.foo.find({x: 2, y: 3})
xが2かつyが3のドキュメント
LIKE検索相当のクエリには正規表現を使います。
> db.foo.find({str: /^h/})
文字列strがhで始まるドキュメント
配列型のプロパティに対する検索は特別な処理が行われます。単一の値を指定
すると「その値を含む配列」という意味になります。
> db.foo.find({ary: 'foo'})
配列aryが'foo'を含むドキュメント
> db.foo.find({ary: ['foo']})
配列aryが['foo']に等しいドキュメント
Embedded Documentのプロパティで検索するには、Embedded Documentを格納し
ているプロパティと検索対象のプロパティを"."で連結します。
> db.foo.find({'obj.x': 1})
Embedded Objectであるobjのプロパティxが1のドキュメント
● 次回予定
より高度なクエリ機能についてご紹介します。(ursm)
[*1] http://www.mongodb.org/display/DOCS/BSON
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】要求とか要件についての四方山話 [2]
┗ 〜ユーザーストーリーのワークショップで感じたこと〜
こんにちは、平田です。
要求とか要件につい筆者なりの視点で話題を広げていく連載の2回目です。前回
の最後に予告した内容とは違うのですが、とても興味深い話を聞いたので、そ
の内容を中心に書いていきます。
先日開催されたすくすくスクラムでの角さんのユーザーストーリーの講演に参
加してきました。[*1]
今回は、その中の特にワークショップで感じたことを中心にお話したいと思い
ます。
ユーザーストーリーとは、XPなどで使われることの多い、ステークホルダー間
で会話した際の記録としてカードなどに記述されるものです。このユーザース
トーリーには、振る舞い要求やビジネスルールなどが書かれます。
ユーザーストーリー全般については、最近このメールマガジンの連載の中で家
永さんが書いているのでそちらを参考にしてください。[*2]
また、すくすくスクラムでの角さんの講演内容も公開されています。[*3]
ワークショップでは、参加者の人達がそれぞれ家族の誰かの役割(父、母、娘、
猫など)を決め、その人の立場になったと想定して、「新しい家に望むこと」を
ユーザーストーリーで記述していくということをやりました。このことは思い
思いにユーザーストーリーを書くことで、ユーザーストーリーというものがど
ういうものなのかを体感することができました。
その後、そのユーザーストーリーの中から任意のものを選び、他の人達がイン
タビューしてそれを詳細化していくということをやりました。私たちのテーブ
ルでは最初に
・猫として、
・キャットタワーが欲しい。
・爪を研いだり遊んだりするためである。
というユーザーストーリーについてインタビューを開始しました。しかし、開
始と同時につまづきました。それはワークショップのお題が「詳細化する」と
なっていたため、「キャットタワー」という具体的な欲しいもの、実現手段ま
で見えている状態のストーリーに対してそれ以上の詳細化が難しいと感じてし
まった人が多かったようです。
その直前の講演の中では「中心的な課題を探る」ということで、「そもそもな
ぜそれが必要なのか」「代替手段はないのか」などのように視点を変えていく
質問をすべきだということを言われていたので、私たちのグループでもその方
向で話を広げていくことにしました。
(でも実はそれでもあまりうまくいかなかったように感じます。それは猫が爪を
研ぐという目的のために作られたキャットタワーというものは、きっとよく考
えられた最適解なので、代替手段を探したりするのが難しかったということも
あるのかもしれません。)
少し時間があったので、次に、私が書いたユーザーストーリーを使ってインタ
ビューしてもらうようにお願いしました。
・母として、
・掃除がしやすい家が欲しい。
・それは家事を楽にするためである。
先ほどのキャットタワーの例が、実現手段を明確にした最下層の要求であると
するならば、私の書いたストーリーはかなり上位の要求なので、詳細化、具体
化していくのに面白いのではないかと思って提示したのですが(たとえば、「収
納が多いリビングが欲しい。ものをフロアに置かずに済むので」など)、結果的
にはみんながその目的や、代替手段を考える質問を多くされたことにびっくり
しました。
「家事を楽にしたいだけなら、掃除をしてくれる旦那に取り替える」や「お手
伝いさんを雇えばいい」、「なぜ家事をしないといけないのか」などなど。こ
ちらが想定していたものとは違うアプローチでの考え方を提示してもらえたこ
とに感動しました。
ユーザーストーリーは、いわゆる一般的な要件定義の文書からすると、情報量
が圧倒的に少ないです。角さんが講演の中でも言われていましたが、情報量が
少ない分を、対話で補う必要があると思います。でも、その対話をすることに
よって、それまでにお客様でさえ気づかなかった真の要求に気づく機会が増え
るということに、ユーザーストーリーというものの力を感じました。もちろん
その実現のためには「命令的ストーリー」ではなく「対話的ストーリー」であ
ることが必要です。[*4]
私自身は実際のプロジェクトで「ユーザーストーリー」を使って要求引き出し
をやったことはなかったのですが、固い要件定義の中でも対話を重視しながら
進めるということをよくやります。そのツールのひとつとしてユーザーストー
リーというのは強力な武器になるのではないかということを感じました。(平田)
[*1] 第11回すくすくスクラム〜ユーザーストーリーはこう書け！〜
http://kokucheese.com/event/index/1329/
[*2]【オブジェクト倶楽部：2010-12号】
/ml-arch/magazine/330.html
[*3] 公開されている資料。当日の映像もページ内のリンクからいけます。
http://www.slideshare.net/SukusukuScrum/no01101suc3rum20100225
[*4] 対話的ストーリー
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ConversationalStories
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。みなさま、今年はお花見されました
か？私は東京の桜が満開の時期に福井にいて、福井の桜が開くタイミングで東
京に戻ってきたので、まだちゃんとお花見ができていません・・・今年はもう
ムリかなぁ(´；ω；`) 桜は寒いと開花が遅れるし雨が降ると散ってしまうし
で、満開ドンピシャ！の時期にお花見をするのってなかなか難しいですよね。
でも、儚いからこそ魅力があるのも事実ですし、葉桜もまたオツですよね。そ
れに、お花見と言いつつ花より団子、花よりお酒の方も多いのでは？お花見と
いう素敵な文化を大切にし、コミュニケーション促進に役立てるのもいいかも
しれませんね♪(ナガタユウコ)
*** オブラブスタッフ自己紹介 ***
No.07 石橋
こんにちは、石橋です。オブラブのイベントでは、音響などを担当していたり
します。
私は、今年の冬、スキーばかり行っていました。3月末にも福島に行ったんです
が、パウダースノーで、3月末とは思えないほど良いコンディションでした。本
当に今シーズンは天候に恵まれていたと思います。そのせいでだいぶ散財して
しまいましたが・・・。
私は、長板ではなくて、「スキーボード(skiboard)」をやっています。スキー
ボードは、Wikipediaにあるように100cm未満のスキー板で、他にも「ファンス
キー」や「ショートスキー」と呼ぶ人もいるようです。
スキーボードのメリットは、(1)持ち運びが楽、(2)トリックがしやすい、とい
うのが大きいと思います。私の乗っている車はコンパクトカーでスキーキャリ
アも付けていないんですが、スキーボードならトランクに収納できます。(後部
座席を倒して、知り合いのスノーボードを無理やり載せることもありますが。)
私は、スピン(くるくる回る)や、フェイキー(後ろ向きに滑る)などのグランド
トリックを中心に行うのですが、長板より旋回性が高いので、スキーボードの
方がやりやすいです。あと、スキーボードでしか出来ないトリックというのも
あります。
デメリットは、(1)安定性が低い、(2)浮力が小さい、というのが大きいと思い
ます。スキーボードは、板が短い分、どうしても長板に比べて安定性に欠けま
す。私も、最初は重心の位置を誤り後ろに転倒することもありました。
また、長板に比べて浮力が小さいので、長板なら問題なく滑れるような場所(新
雪で非圧雪)でもハマってしまい、脱出するのに苦労したことがあります。
メリット・デメリットがありますが、スキーボードはとても楽しいです。これ
を機会に、スキーボードに興味を持ったという人がいたら嬉しいですね。
以上、自己紹介にはなっていませんが、石橋でした。(石橋)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.