┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.230 2008/04/09
■ I N D E X
┃
┣【Topics】花見勉強会が大阪で開催 オブラブからも参加します(4/12:大阪)
┣【プログラミング】Rubyで進むオブジェクトの道 [28]
┗【PF】たまには仕事に役立つコミュニケーションのヒント [18]
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 花見勉強会が大阪で開催 オブラブからも参加します(4/12)
〇 〇━━━━━━━━━━━━━ ━━・
大阪は本町靱公園にて、業界初!?の野外露天屋外勉強会、それもただの野外
じゃない、お花見勉強会が開催されます！桜が散ってたって関係ない！
お近くの方もそうでない方も、ぜひお越しください。
日時: 4月12日(土) 18:00〜
詳細: http://seminar.genephics.co.jp/fxug/
主催: FlexUserGroup、てら子、WCANなど、コミュニティ合同
オブジェクト倶楽部からは、新著「受託開発の極意」を引っさげて岡島幸男が
参加します。プレゼンもする予定です。お酒を引っさげてやっとむも参加しま
す。プレゼンしないで寝てるかもしれません。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道 [28]
前回から、RSpecのマッチャを紹介しています。マッチャの代表的な例は、
(1 + 1).should eql(2)
のeqlです。acutal[1 + 1] がexpected[2]と同値であることを期待する振る舞
いとして明記し、またRSpec実行時には、同値であるかをテストします。
今回は、changeマッチャを紹介します。changeマッチャは状態の変化を明記す
るのが得意とするマッチャです。
では、早速例を示します。
● changeの例
describe "配列で要素の追加を2回実行した場合" do
before(:each) do
@ids = ["BBB"]
@add_two_times =
lambda {
@ids << "CCC"
@ids << "DDD"
}
end
it "lastの要素は、変わること" do
@add_two_times.should change(@ids, :last)
end
it "firstの要素は、変わらないこと" do
@add_two_times.should_not change(@ids, :first)
end
it "lastの要素は、追加前のlast要素から最後に追加した要素へ変更されること" do
@add_two_times.should change(@ids, :last).from("BBB").to("DDD")
end
it "lastの要素は、最後に追加した要素へ変更されること" do
@add_two_times.should change(@ids, :last).to("DDD")
end
it "sizeは、2つ変わること．" do
@add_two_times.should change(@ids, :size).by(2)
end
end
● SpecCodeの説明
前提条件は、配列に２つの要素を追加した場合です。
「2つの要素を追加した」の変更のシチュエーションを、lambdaで明記してい
ます。changeマッチャを利用する場合、xxx.shouldのxxxの箇所に、lambdaがよ
く利用されます。
今回は、「2つの要素を追加」の記述がくり返し出たため、@add_two_timesに
代入しました。
=== should change(receiver, message)
it "lastの要素は、変わること" do
@add_two_times.should change(@ids, :last)
end
eqlのように同値であることを調べる必要がなく、単に変更されていることだけ
を明記したい場合にchangeが使えます。変わらないことを明記したい場合は、
should_not change 形式で記述します。
Spec対象のreceiverは@ids, messageは:lastになります。
上記の内容は、下記のようにshould change{ xxxx }のblockを使った形式で書
くことも出来ます。
it "lastの要素は、変わること" do
@add_two_times.should change{ @ids.last }
end
=== should change(receiver, message).from(old).to(new)
it "lastの要素は、追加前のlast要素から最後に追加した要素へ変更されること" do
@add_two_times.should change(@ids, :last).from("BBB").to("DDD")
end
oldの値からnewの値への変化を明記したい場合に「from(old).to(new)」を利用
します。
=== should change(receiver, message).to(new)
it "lastの要素は、最後に追加した要素へ変更されること" do
@add_two_times.should change(@ids, :last).to("DDD")
end
変更後の値を単に明記したい場合に「to」を使います。
=== should change(receiver, message).by(value)
it "sizeは、2つ増えること．" do
@add_two_times.should change(@ids, :size).by(2)
end
配列などサイズの変更を明記したい場合に「by」を使います。
changeマッチャ側で下記の内容をチェックしています。
変更前のsize(1) + by(2) == 変更後のsize(3)
● まとめ
changeマッチャを紹介しました。
changeマッチャはSpec対象の状態の変更を明記するのに利用します。
from(old).to(new)やby(value)を使って、Spec対象のpreの状態、postの状態の
変化を明記するのが特徴的です。
changeの詳細は、下記が参考になります。
* Rubyist Magazine - スはスペックのス 【第 1 回】
http://jp.rubyist.net/magazine/?0021-Rspec#l76
* RDoc Module Spec::Matchers
http://rspec.rubyforge.org/rdoc/classes/Spec/Matchers.html
* matcher_rspec.rb
http://rspec.rubyforge.org/svn/trunk/rspec/spec/spec/matchers/change_spec.rb
また、xUnit Patternsの語彙ならDeltaAssertionが関連要素になります。
* DeltaAssertion
http://xunitpatterns.com/Delta%20Assertion.html
(IENAGA)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-27&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-27&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-27&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【PF】たまには仕事に役立つコミュニケーションのヒント [18]
クッション言葉
某証券会社の「新入社員マナー研修」のお仕事をしてきました。
セミナーの後半には、音がするぐらい！彼らは成長を遂げていました。学生か
ら社会人へと顔つきが変わってゆく瞬間に立会い、こちらも感動しました。
さて、今回は新入社員マナー研修にヒントをもらい、みなさんに「クッション
言葉」についてお伝えいたします。接客時や電話応対のマナーとしての言葉と
いうだけではなく、日ごろのお仕事の中でも結構使えるのではないでしょうか？
●クッション言葉とその効果について
クッション言葉には、何かを依頼するときや断るときに伝える言葉の前に置く
ことで、表現を和らげる働きがあります。その結果、相手には受け入れにくい
ようなことにも受け取りやすくする効果があります。また、クッション言葉を
置いて話すことで、聞く側にも聞く準備を整える効果があります。
相手に対する思いやりの表現としても、あちこちで紹介されています。
主なクッション言葉をあげると
・恐れ入りますが
・お手数ではございますが
・申し訳ございませんが
・あいにく（ではございますが）
・差し支えなければ（ございませんでしたら）
・よろしければ
・大変申し上げにくいのですが
・失礼ではございますが
・誠に勝手ではございますが
と、こんな感じです。
コールセンターや受付などの、お客様と直接接点を持つお仕事の皆さんは、よ
く使っていますね。読者の皆さんもお客様としては良く耳にする言葉なのでは
ないでしょうか？
●ズバリ！伝えにくいことを伝えるときに
クッション言葉は主に「伝えにくいことを伝える」「断る」ときと紹介しまし
た。コールセンターや受付のオネエサンほど丁寧ではなくても、皆さんの日常
で伝えにくいことを伝えるシーンがあれば、そこで使うことができます。
伝えにくいことをそのままストレートに「ごめんね」と伝えることができれば
何の気苦労もないのですが、それがお互いに理解してやりとりをしあうまでに
は基本である「人間関係や信頼関係づくり」という土台が必要です。
春を迎え、新しい人たちと仕事をし始めたばかりだと、「人間関係や信頼関係
づくり」に十分な時間を使って土台ができる前に、伝えにくいことでも伝える
必要があるという場面がくるかもしれません。
そんなとき、
「○○さんの気持ちは嬉しいんだけど・・・」
「一所懸命やってもらっているところ悪いんだけど・・・」
「ベテランの○○さんにこういうのも変ですが・・・」
などと言葉を置くことで、聞き手の考えや気持ちを認めたうえで話していると
いうことが伝わるでしょう。
基本は相手を尊重しているという気持ちを伝えているかどうかがポイントです。
ズバリと伝えることも大切ですが、特に相手にとって「大切なことだった」
「一所懸命やっている」などということがらに対して使うと良いでしょう。
●聞き手の準備を整える
クッション言葉を用いることで、聞き手には気持ちの準備を整える効果があり
ます。「伝えにくいことを伝える」「断る」ときに有効です。
「田中さんが作った資料、レビューでは使わなくなったよ。」という文章に、
クッション言葉をつけてみます。
「せっかくなんだけど、田中さんが作った資料、レビューでは使わなくなっ
たよ。」
この「せっかくなんだけど」という言葉の後につづくのは、肯定的な文章では
ありません。「せっかくなんだけど」という言葉を聴いただけで、次に繋がる
「使わない」という事実を連想することができ、気持ちの準備をすることがで
きます。ものごとによってはこんなふうに、相手への思いやりをクッション言
葉で表現することができるのです。
「お忙しいところ恐れ入りますが」というクッション言葉は、忙しい相手に声
をかけるときの配慮の効果もありますし、声をかけるきっかけを作ることがで
きます。忙しい人に声をかけるのが苦手という人は、試してみるのはいかがで
しょうか？
●おわりに
今回ご紹介したクッション言葉は、相手に気持ちよく聴いてもらうためにつけ
る言葉です。どうしても忙しいと「要件を正確に伝える」ということが優先し
てしまいますが、その一方で「気持ち」が行き場をなくしてしまうことが増え
てきています。
この「気持ちの取りこぼし」には、士気を低下したり、寂しさや残念な気持ち
を伴いますので、実際の行動にとても影響がありますよね。
私はいがいがさんがオブラブのイベントでベストトーカーを受賞した「思いや
り駆動開発(ODD)」[*1]を聞き、さらに平鍋さんの「ソフトウェア開発はコミュ
ニケーションでできている。」[*2]という言葉に共感しました。
お互いに気持ちよいコミュニケーションをとるための技術として活用していき
たいですね。(上田雅美)
[1] : いがいがさんのブログ。思いやり駆動開発のコミュニティーも紹介され
ています。
http://igarashikuniaki.net/tdiary/20070620.html#p01
[2] : 平鍋健児さんのブログ。思いやり駆動開発に具体的に触れています。
http://blogs.itmedia.co.jp/hiranabe/2007/06/odd_c08a.html
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-17&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-17&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M003-17&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「新人のころを振り返って、こうしておけばよかったと思うことは？」
のホントのところ。
新人のころというと、毎日がいろいろな意味で精一杯。気がつけば後輩も増え
て・・・という方も多いのではないでしょうか？今回は、先輩から新入社員へ
のメッセージ、これを聞いてみたいと思います。新人のころを振り返って、
こうしておけばよかったということががあるとすればどんなことでしょうか？
ひとつ選んで教えてください。
いろいろな知識を幅広く勉強しておくこと。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=0
現場でもまれて腕を磨くこと。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=1
違う会社や業界の人と出会い、人脈を作ること。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=2
もっと先輩や上司に呑みに連れて行ってもらうんだった。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=3
早めに身を固めて安定した生活をする。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=4
貯金をしておく。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=5
遊んでおく。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=6
たくさん失敗して経験を増やしておくこと。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=7
会社や業界を見ながら、自分で考えて進む道を決めること。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=8
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=195&choice=9
ちょっと語らせて！
詳細をこのメールに返信ください！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「新入社員は来ましたか？」の結果は公開中。ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol194/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。健康保険法が改定となり、メタボリック・シンド
ロームの検診が2008年より義務付けられるそうです。その動きに便乗してか、
健康器具や健康食品の市場が活性化しているように見えますね。もう既に、
診断を受けたという読者の方はいらっしゃるでしょうか？
メタボリック・シンドロームは、主に生活習慣病を招く要因を意識した考えだ
と聞きましたが、健康ってなにものにも代えがたいですよね。
これを機に、ちょっとはビールの量を減らそうと(いまのところ)心に誓う今日
このごろです。
参考 : 財団法人 循環器病研究振興財団ホームページ
http://www-bm.mhlw.go.jp/bunya/kenkou/metabo02/index.html
(上田雅美)
今週の強引な一言
*** 「ジオンとの戦いがまだまだ困難を極めるというときに、
我々は、学ぶべき人を続々と失っていく…。寒い時代だと思わんか？」
ワッケイン ***
得てしてトラブルプロジェクトに限って人の出入りが激いもので、重要なメン
バーが体調不良や配置換えで突然居なくなったりした経験はありませんか？トラ
ブル時にはどうしても感覚が麻痺してしまうところもあって、人月換算ベースで
スケジュールを考えがちですが、チームが安定したアウトプットを出すために必
要なのは単なる頭数ではなくて、知識や技術そしてハートを持ったメンバーであ
り、そう簡単に取り替えがきくものではないんですよね。(dot.)
出典 : 機動戦士ガンダム 第4話
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/ Copyright (c)2003-2008 オブジェクト倶楽部.All Rights Reserved.
powered by Eiwa System Management, Inc.