┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.202 2007/09/19
■ I N D E X
┃
┣【Topics】モデリングワークショップ モデル公開
┣【プログラミング】Rubyで進むオブジェクトの道[24]
┣【ＰＦ】たまには仕事に役立つコミュニケーションのヒント[12]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 モデリングワークショップ モデル公開
〇 〇━━━━━━━━━━━━━ ━━・
モデリングフォーラム2007でオブジェクト倶楽部がお手伝いしたワークショッ
プのモデルを公開しました。
当日のお題や、道場主らによるサンプルモデルも公開しています。
http://www.ObjectClub.jp/community/modeling/modeling_forum_2007/
ご参加いただいた皆さん、ありがとうございました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道[24]
■はじめに
前回、RSpec[*1]でのMockについて記述すると予告しましたが、今回は予定変更
です。
私が最近読んだUser Stories Applied[*2]から連想して、ユーザストーリーと
RSpecの関係性について思ったことを述べてみます。
■ユーザストーリーって？
下記は、User Stories Applied[*2]のChapter1のSummaryのから抜粋です。
* A story card contains a short description of user- or
customer-valued functionality
* A story card is the visible part of a story, but the important part
are the conversations between the customer and developers about
the story.
ユーザストーリーは、ユーザ価値に結びつく機能を簡潔に記述します。
ストーリーは、カードに書くことが多いようです。
アジャイル開発(とくにXP)で、一部によく知られるようになっています。
ユースケース記述とユーザストーリーを比較すると、ユースケース記述では、
仕様の詳細記述の方法についてアドバイスしているのに対し、ユーザストー
リーでは、仕様の詳細記述についてのアドバイスをしていません。
代わりにユーザストーリーでは、customerとuserとdeveloperとの直接的な会話
の重要性を指摘し、ユーザストーリーの会話ための指針をいくつか提供してい
ます。
その会話の指針には、仕様の詳細化についてだけではなく、見積もり、
リリース／イテレーション計画、そして受け入れテストなども含まれています。
RSpecと会話と受け入れテストが関係しそうですね。
■Goodなユーザストーリーの特徴
User Stories Applied[*2]のChapter 2では、Goodなストーリーの6つの特徴を
上げています。
* Independent
* Negotiable
* Valuable to users or customers
* Estimatable
* Small
* Testable
RSpecとTestableが関係しそうですね。
■ユーザストーリーとRSpecの関係性
■■会話の語彙としてのRSpec
RSpecの語彙(describe， it shouldなど)は、customerとdeveloperの会話を通
じて、Goodなユーザストーリー（特にTestableなストーリー)をつくるのに役立
つと思われます。
BDD[*3]やRSpecが自然言語を強調しているのは理由の一つに、
customerとdeveloperと会話をファシリテート(促進)することにあります。
■■仕様詳細記述としてのRSpec
「会話の結果の仕様をいかに記述する？」というクエスチョンがあります。
１つは、詳細の仕様書としてドキュメントに記述することです。
一般的ですね。
もう１つの方法は、受け入れテストで仕様を記述することです。
RSpecの仕様の語彙を使って会話した内容を、RSpecの仕様の語彙を使って受け
入れテストに記述することは、比較的に障害が少ないと思われます。
RSpecで記述した場合、完全な自然言語で記述された仕様書ほど、
user/customer readableは、期待できないかもしれませんが、それでもRSpecが
自然言語に近い形でまとめられるのは魅力的です。
RSpecで記述した場合、computer readableです。ここは完全な自然言語で記述
した仕様書よりも、大きなアドバンンテージがあると思われます。
（例えば、ストーリー完了がより明確化できる、仕様と実装の乖離を早期に発
見しやすい、などなど）
■まとめ
今回は、少し視野を広げて、ユーザストーリーの観点からRSpecについて思うと
ころを述べてみました。
* customerとdepveloperとのストーリーに関する会話の促進としてのRSpec
* 会話の結果をまとめる受け入れテストとしてのRSpec
customer/userとの対話を考慮すると、RSpecの特徴が見えてきますね。
(IENAGA)
[1] : RSpec:
http://rspec.rubyforge.org/
http://www.objectclub.jp/ml-arch/magazine/197.html (過去の記事)
[2] : User Stories Applied:
http://www.amazon.co.jp/ASIN/dp/0321205685/xpjp-22
[3] : BDD (Behavior Driven Development)：
かなり大雑把に説明すると、TDDと仕様を足して2で割ったようなもの。
私自身は、user/customerとdeveloperとcomputerの共通の語彙を
つくってよいソフトウェアをつくる習慣を得るためのパタン活動の変種
だと、勝手に思い込んでいる。
http://en.wikipedia.org/wiki/Behavior_driven_development
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-23&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-23&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-23&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＰＦ】たまには仕事に役立つコミュニケーションのヒント[12]
- 「コミュニケーションは、受け止めたことがすべて」
だんだんと秋が深まってきましたね。私は秋の味覚のひとつ「さんま」を食べ
ました。脂がのっていて、とてもおいしい！季節によって食べるものが変わって
も、飲むのはもっぱらビールか焼酎かワインの上田雅美です。
●えっ！？どうしてそうなるの！
セミナーのあとの懇親会の席で参加者の人といろいろ話しをしていると、「伝
えることが苦手」とおっしゃる方はたくさんいらっしゃいます。
実のところをいうと、私もとても苦手です(笑)
私も経験がありますが、「急いでお願いします。」とお願いしたのにもかかわ
らず、頼んだ相手は一向に急いでいる様子もなく、お願いしたことをやってい
る気配すらない。
業を煮やして「急いでってお願いしたつもりだったんだけど。」と伝えると、
相手の顔が「えっ！？そんなに急いでたの？」という表情になり、あわててお
願いしたことに取り組んでいただけるというようなそんな経験をお持ちの方も
多いはず。
こういうときに相手の様子を気にしつつ、「いやなやつだと思われないかな？」
などと気を使いながら声をかけるのは、ちょっと勇気が必要ですよね。
●相手が受け止めたことがすべて
残念ながらコミュニケーションは「相手が受け止めたことがすべて」です。
先ほどのシーンを例にたとえると、私が「急いで」と言ったとしても、相手が
「今すぐか？」「なるべく急ぐのか？」「だいたい明日までぐらいなのか？」
といったような受け止め方ひとつでで行動が左右されてしまいます。
受け止めた相手の「急ぐというのはどのぐらいなのか？」で量ることになりが
ちで、こういったことが積み重なると、「コミュニケーションのすれ違い」と
いうことになってしまいます。
先ほどの「急ぐ」の例は、日常的によくある出来事です。こういう体験をして
しまうと、「自分は伝え方が良くないのではないか？」と考えるようになり、
「やっぱり伝え方は難しいな。」と、どんどんコミュニケーションを取ること
に苦手意識を抱きやすくなってしまいますね。
それでは、そうならないためにはどうしたら良いのか考えてみましょう。
念頭に「相手が受け止めたことがすべて」ということを置きつつ、まだまだお
つき合いくださいね。
●見えないからこそ
では、どんな風にすれ違いを防ぐのかについて考えてみましょう。
すれ違いは、あいまいなものを対話によってわかりやすい状態にすることで、
ずいぶん解消されます。
まず最初に、伝える側が意識するポイントです。
(1) 数値化する
「17時までにお願い」「10時までに見せてね」などと、数値化すること
により、相手には伝わりやすくなります。
(2) 説明を求める
話した後、「どんな順序でやろうと思うか？」「ポイントだと思ったこ
と」など、相手に伝わったことを話してもらいます。その場で何かの行
き違いがあった場合には、その場で訂正することができます。
(3) 見える化する
読者の皆さんにはおなじみだと思いますが、図で書く、流れを示すなど
図式化することによってイメージや順序が共有されやすくなります。
(4) 例を出す
「例えば、○○のように」と例を出すことによって、お互いに共有してい
る情報を元に話し合うことができます。ここでは、なるべく具体的な例
であることのほうが望ましいとされています。
(5) 共通の言語を使う
「テスト」といってもどの範囲のテストを指すのかは、開発するチームが
属する組織によって少し違う場合があります。このように、人によって、
または組織によって同じ言葉でも使われている内容に少し差があったり
することがあります。また、専門用語や英語を使いすぎると、解らなく
なることもあるようです。誰にでもわかりやすい言葉を選びましょう。
コミュニケーションは送り手だけでは成り立ちません。受け手もどのように伝
わったかを確認する努力をするとコミュニケーションはより円滑になります。
それでは、受けて側が意識するポイントをご紹介しましょう。
(1) 質問する
「急ぐ」「たくさん」「明るい感じ」などというように、日本語の中には曖昧
な表現がたくさんあります。もしも皆さんが会話の中で気がついたら、
「どのぐらい○○ですか？」と質問することによって、曖昧さを少なくす
ることができるようになります。
また、「5W2H」の質問などを使って、具体的にすることもお勧めです。
(2) どう伝わっているか、相手に伝える・確認する（フィードバック）
「私には〜と伝わっているけど」と、私を主語にしたＩ(アイ)メッセージ
で伝えることにより、伝わり方にギャップがあった場合にさらにそれを
対話で埋めることができます。アイメッセージを使うと、「私が感じたこ
と」を強調することができます。聞き手である「私」が感じたことなので、
正解や不正解がなく、共通の目的のために使えば、言われた側にも不快
感がありません。
(3) 先入観を持たない
「どうせ○○のことを言うのだろう」と思ったとたんに、不思議なぐらい
相手の話を聞かなくなります。なるべく先入観を持たずに、素直に聴く
ことを心がけましょう。
●まとめ
コミュニケーションの定義はいろいろあると思いますが、対話でもメールの文
章でも、残念ながらすれ違ってしまうことは良くあることです。
「コミュニケーションは、受け止めたことがすべて」なのです。
そこで、大切なのが「対話の量」と「目的の共有」だと私は思っています。
忙しさや距離、または今までの失敗から、どうしても億劫になりがちなことも
あると思います。しかし、うまくいっているプロジェクトや人間関係には必ず
「対話の量」と「目的の共有」があります。
相手の受け止め方を確認することをはじめると、ぐっとすれ違いがなくなりま
すよ。(上田雅美)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-11&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-11&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-11&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「政治は仕事に影響ある？」のホントのところ。
テレビでは連日次期自民党総裁のポストをめぐり、数多くの情報が飛び交って
います。さて、これからどうなるんでしょうか？
今日は読者の皆さんのお仕事に、政治が影響あるのかどうかについて聞いてみ
たいと思います。IT業界と社会基盤は切っても切れない関係になりましたが、
みなさんのお仕事はどうですか？
かなり影響を受ける見込みです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=0
直接は影響ありません。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=1
よく解らない。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=2
考えてもみませんでした。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=3
クライアント次第。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=4
そんなの関係ねぇ！
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=5
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=168&choice=6
ちょっと語らせて！
詳細をこのメールに返信ください！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「コミュニティーのイベントや勉強会に初めて参加するときに気に
なることは？」」の結果は公開中。ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol167/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。「Mac買わないの？」と毎週オブラブメンバーに聞かれ
ています。確かに欲しいんですが、パソコンの買い替え時ってどんなときでしょ
うか？ちなみに、今使っているのは買ってから約1年半。さすがに贅沢ですよね。
いいものはどんどん出てきますが、お金が追いつきません(涙)。お金の使い道
には、その人の価値観が出ると聞きました。私の場合は飲み代が多いので、つ
まり人を大切にしてるんだって自分勝手にまとめてみました。Macを買ったら、
読者の皆さんにも報告しますからね。
今週の強引な一言
*** 夜郎自大(ことわざ)***
自分の力量も考えず、幅を利かせ反省のないことのたとえ。
*** 野郎時代(ことわざ)***
いろいろな諸事情により、女性がすべていなくなってしまったプロジェクトの
こと。ジョークですってば！ジョーク。
出典参考：故事ことわざ辞典 東京堂出版
(上田雅美)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2007 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.