┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.123 2006/01/18
■ I N D E X
┃
┣【Topics】プロジェクトファシリテーション プレゼン資料[最新版]公開
┣【Topics】クリスマスイベント主賓講演資料再公開
┣【Topics】オブLOVEもデブサミに参加します。
┣【ＰＦ】ふりかえりガイド[2] - ふりかえりの進め方
┣【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[11]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 プロジェクトファシリテーション プレゼン資料[最新版]公開
〇 〇━━━━━━━━━━━━━ ━━・
プロジェクトファシリテーションのプレゼンテーション資料[最新版]
『見える化によるプロジェクトファシリテーション』
〜モチベーションアップのツールと場つくり〜
を公開いたしました。大好評いただいているプロジェクトファシリテーション
の講演資料です。実際の現場にて、参考にされてはいかがでしょうか。
http://www.ObjectClub.jp/community/pf/#material
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 クリスマスイベント主賓講演資料再公開
〇 〇━━━━━━━━━━━━━ ━━・
クリスマスイベントで大好評でした、前川徹さんによる主賓講演『ソフトウェ
アの生産性と品質を向上させる鍵は何か』の講演資料をカラーバージョンで再
公開しました。既にご覧になられた方も、まだご覧になっていない方も、どう
ぞご覧ください。
http://www.ObjectClub.jp/event/2005christmas/schedule#guest
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 オブLOVEもデブサミに参加します。
〇 〇━━━━━━━━━━━━━ ━━・
オブジェクト倶楽部もデブサミに参加します！
【9-B-7】『エンジニアの生きがいとは？』
〜マインドマップを使ったQoEL探検ワークショップ〜
オブLOVE主催の平鍋も参加！
【10-A-1】『Developer 2.0 への自分探し』
〜キャリアアップのための自己啓発ワークショップ〜
加えてオブLOVEスタッフのかくたにも参加！
【10-A-3】『プロジェクト・オートメーション』
〜コンピュータもチームメンバだ!!〜
技術者コミュニティとの連携から生まれた総合ITコンファレンス
Developers Summit（デブサミ）2006 ◆2月9日（木）・10日（金）開催！
◆会場:目黒雅叙園（東京・目黒）◆主催:株式会社 翔泳社◆後援：IPA SEC◆
▼無料の70セッションは完全事前登録制！お申込はこちら▼
http://www.seshop.com/event/dev/2006/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＰＦ】ふりかえりガイド[2] - ふりかえりの進め方
こんにちは、天野勝です。
前回は、ふりかえりの目的について説明をしました。今回は、この目的にした
がって、どのように進めるか、その概観を説明します。
* * *
■ふりかえりの進め方
ふりかえりの進め方は、大きく分けると以下の8つのステップで構成されます。
(1)思い返す
(2)うまくいった行動を確認する
(3)問題を洗い出す
(4)問題の原因を議論する
(5)解決策を考える
(6)試したいことを考える
(7)試すことを選択する
(8)試すことを合意する
では、それぞれのステップについて解説します。
(1)思い返す
思い返すことからスタートします。
プロジェクトが開始されてから、もしくは前回のふりかえりを行ってからこれ
までのことを思い返します。どのようなできごとがあったでしょうか。つくっ
た成果物、人の出入り、呑み会といったレクリエーションなど、何でもよいで
す、プロジェクトを思い返すためのきっかけも思い返します。
(2)うまくいった行動を確認する
思い返した中で、うまくいった行動を挙げます。プロジェクトに直接的に貢献
する行動だけではなく、目に付きにくい間接的に貢献した行動についても挙げ
ます。そして、この行動について自分たちを褒めます。どんなに悲惨な状況で
も、何か一つは良いことがあるはずです。どんな些細なことでも拾い上げ、ス
ポットを当てましょう。これが自信に結びつき、チームの行動として定着して
いきます。
うまくいったことから始めるのは、「始めよければすべてよし」の原則に則っ
ています。
(3)問題を洗い出す
思い返した中で、問題と感じるところを挙げます。具体的な問題ではなくても、
感じている問題点、今後の問題となりそうなものまで正直に挙げます。自分の
問題だけではなく、チームや他のメンバーの問題も挙げます。
なんとなく思っていることを率直に口にしてみることが重要です。もやもやし
ていることが、実はみんなが思っていることだったりします。率直に言えるよ
うになるには、「気づき」「信頼関係」の価値を共有する必要があります。
(4)問題の原因を議論する
問題を洗い出したら、その原因について議論します。「なぜを5回繰り返す」の
が理想ですが、どうしても時間がかかってしまいます。原因を究明すべき問題
であると判断した場合のみにするとよいでしょう。また、ふりかえりを導入し
はじめた当初は、原因究明にあまり時間をかけなくても、問題を共有するだけ
でも充分にふりかえりの効果があります。
あくまでも、原因について議論するのであり、責任を追求して、特定の人を攻
撃するのではないことに注意しましょう。さもないと、「信頼関係」の価値を
共有できません。これは「Problem vs. Us」の原則に則っています。
(5)解決策を考える
問題に対して、その原因が判明したら解決策を考えます。解決策は、絵に描い
た餅であってはなりません。実行可能な解決策を考える必要があります。また、
自分たちで実行するというのもポイントです。誰かに押し付けるだけの解決策
では、効果がありません。「なぜを5回繰り返す」と、ほとんどの原因が人に由
来することになっていることと思います。この状態まで原因が究明されていれ
ば、解決策を考えるのはそれほど難しいことではないでしょう。
(6)試したいことを考える
問題の解決策は、「試したいこと」になります。それ以外にも「問題があるわ
けではないが試したいこと」があればそれを挙げ、チーム全員で共有します。
(7)試すことを選択する
ここまでの手順で、試したいことが数多く出てきたと思います。その中から実
際に試すことを選択します。欲張って一度に多くのことを試そうとしても、実
際にやりきれないことが多く、改善の効果が薄れてしまいます。確実に自分た
ちで試せることを選択します。
(8)試すことを合意する
選択した試したいことを実行に移すために、一つずつチームで合意していきま
す。何をするのか、何のためにするのか、誰がやるのか、いつまでにするのか
を明確にします。どうやってするのかについては、担当者に任せるのが望まし
いので、ふりかえりの場ではそれほどやり方まで明確にする必要はありません。
しかし、実行するのが難しいと感じられるものについては、実施方法まで明確
にしておくとよいでしょう。
合意とは、「同意＋サポートしますという意思」です。担当が自分ではなくて
も、必要であればサポートすることを含めて「合意」しましょう。
これにより価値である「行動」に結びつきます。
* * *
復習になりますが、ふりかえりの目的は、以下の四つです。
1.チーム全体が、行動可能な改善策を探し、試す勇気を得ること。
2.チーム全体が、これまでの行動を思い返し、そこから新たな気づきを得る
こと。
3.チーム全体が、やってみてうまくいった行動を、チームに定着させること。
4.チーム全体が、参加メンバーの多様性を受け入れ、信頼関係を築くこと。
この目的を忘れないようにしましょう。
次回は、具体的にKPT（Keep/Problem/Try）による、ふりかえりの方法をご紹介
する予定です。(天野勝)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-17&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-17&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-17&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[11]
●はじめに
前回の記事では、DuckTypingについて説明しました。まだご覧になっていない
方は、次のリンクを参照してください。
http://www.ObjectClub.jp/ml-arch/magazine/123.html
今回は、DuckTypingを使ったモックテストについて、触れていきます。
●サンプルプログラム
サンプルは、2つのさいころの和を計算するプログラムです。
--------------
class Game
def initialize(die_a=Die.new, die_b=Die.new)
@die_a = die_a
@die_b = die_b
end
def play
@die_a.roll + @die_b.roll
end
end
class Die
def roll
rand(6) + 1
end
end
--------------
ここで次のような疑問があがります。
●どのようにしてplayメソッドの動作確認するか？
Dieのrollメソッドは１から６のどの数字を返すかは事前に知ることはできませ
ん。どうすれば、Gemeのplayメソッドが2つのさいころの和を行っていることが
テストで確認できるでしょうか？
●「インタフェース」を使ってテストが容易な構造にする方法
Java界隈で一般的に知られたアプローチは、「インタフェース」を導入してテ
スト容易性の高い構造にすることです。
test対象のクラス
↓
┌────┐ ┌─────┐
│ Game │----------> │ IDie │
└────┘ ├─────┤
│ roll │
└─────┘
△
│
┌──┴──┐
│ │
test用のモック ┌──┴─┐ ┌─┴──┐
定数を返す -----> │MockDie │ │ Die │<-----実際に利用するもの
└────┘ └────┘
[図:インタフェースを使ってテスト容易な構造にするアプローチ]
IDieインタフェースを実現したMockDieでは１から6の乱数ではなく定数を返す
ようにします。MockDieを使えば2つのさいころをの和算の確認テストは容易に
できます。
●インタフェースを使った方法の副作用
ただし、playメソッドのテストで動作確認するためは、
(1)IDieインタフェースの導出
(2)DieとMockDieでIDieを継承(実現)
とプログラミングに少々手間が必要です。
筆者は、Javaで開発しているときに、テストしやすくするためにインタフェー
スを導出し続けたら、大量のインタフェースと継承関係が出現して、ちょっと
ブルーになりました。
●DuckTypingの場合の確認方法
DuckTypingでのモックテストのアプローチは少々異なります。テストを行いや
すいモックのさいころを用意する点は同じですが、IDieのようなインタフェー
スは導出、IDieの継承は行いません。
代わりにrollメッセージにレスポンスできるオブジェクトを用意してあげます。
--------------
require 'test/unit'
class GameTest < Test::Unit::TestCase
def setup
mock_die_a = Object.new
def mock_die_a.roll
1
end
mock_die_b = Object.new
def mock_die_b.roll
6
end
@game = Game.new(mock_die_a, mock_die_b)
end
def test_total
assert_equal(7, @game.play)
end
end
--------------
上の方法では、特異メソッドを使ってrollメッセージにレスポンスできるモッ
クオブジェクトを用意し、Gameオブジェクトに差し込みました。
class Game
・・・
def play
@die_a.roll + @die_b.roll
・・・
DuckTypingの場合、@die_a, @die_bのオブジェクトはrollメッセージにレスポン
スさえできれば十分です。そのため、インタフェースと継承は必要ありません。
DuckTypingの場合、インタフェースと継承が減りプログラムがコンパクトにな
る傾向があります。
コンパクトになれば、本質に集中してプログラミングすることができます。
＃「インターフェースを導出して、継承して・・・」って、
＃つくりたいプログラムの本質ではないですよね。
●まとめ
DuckTypingを使ったモックテストについて記しました。
今回はrollメソッドをObjectオブジェクトに特異メソッドで付加しましたが、
レスポンスしてほしいメッセージが「<< 」など一般的なものであれば、既にあ
るStringや配列をモックとして利用できます。(Stringや配列には <<メソッド
があります。)
IO系であればStringIOも便利です。もちろんStringIOとIOに共通するインタ
フェースを導出してなどいません。DuckTypingの場合、メッセージにレスポン
スさえできればいいのですから。
次回はrSpecについて触れようか迷っています。(IENAGA)
●参考
まつもと直伝 プログラミングのオキテ 第4回 日経Linux 2005年8月号
http://itpro.nikkeibp.co.jp/article/COLUMN/20050913/221012/
Programming Ruby
http://www.amazon.co.jp/o/ASIN/0974514055/xpjp-22
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-10&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-10&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-10&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「転職してもシステム業界？」のホントのところ。とあるサイトで、IT
業界が転職したい業種No.1に輝いていました。みなさんは、転職しても、また
このシステム業界に入ってきます？
もちろん！
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=0
どちらかと言えば入りたい。。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=1
お願いされれば入ってあげても。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=2
微妙。。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=3
どちらかと言えば入りたくない。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=4
もうこりごり。。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=5
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=89&choice=6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「今年のオブジェクト倶楽部に何を期待しますか？」の結果は公開
中。ぜひご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/vol88/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。豪雪で大変な思いをされている地域もあるかと思え
ば、東京では雪って何よ？というくらいの青空が広がっていたりしてびっくり
します。同じ日本で、こんなにも違うものなんだなぁと思うと不思議です。空
はつながってるはずなんですけどね。
雪国のみなさん、雪おろしに、雪かきに、重労働ですが頑張ってください。通
勤もとても危険で大変でしょうが、お気をつけください。
今週の強引な一言
*** それでも地球はまわっている(ガリレオ)***
異端裁判で地動説を論じることを禁止されたガリレオは、実はそんなことは言っ
ていないそうです。後世の人が作り出した伝説であるとか。偉大なことを成し
遂げると、周りの人が勝手に尾ひれを付けたり磨きをかけてくれたりして。
(さとみ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2006 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.