┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.323 2010/04/21
■ I N D E X
┃
┣【PF】現場リーダーの心得 [25]
┣【プログラミング】Let's Try 受入テスト [5]
┗ 編集後記
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【PF】現場リーダーの心得 [25]
オブジェクト倶楽部メルマガ読者のみなさん、こんにちは。
岡島です。
4月に入り、弊社にも新入社員がやってきました。皆緊張の面持ちで、これから
始まる社会人やエンジニアとしての生活に、期待と不安が入り混じっているか
のようです。先輩社員として彼らの成長をサポートしたい。そのような気持ち
に満ちた4月です。
さて、緊張のせいか思い入れのせいか、何事も「初めて」のことはよく覚えて
いるものです。今回は新人歓迎特集として、私が初めての現場リーダーをした
ときの経験を紐解きながら、「新米現場リーダーが陥りがちな心理状態」につ
いてお話しましょう。
● 自分は頑張っているんだから、他人も頑張るべき
リーダーを任されるということは周りから期待されているということです。そ
してそれは本人も自覚していることが多く、その結果、新米リーダーはとても
頑張ることになります。私もそうでしたが、今まで以上の仕事をこなしながら、
リーダーとしてのタスクもこなしていくことになります。緊張感からか、テン
ションも上がり、自分が優秀になった気持ちすらしてきます。
と、ここまでは良いとして、次に気になってくるのは周りのメンバーのことで
す。どうも、自分より頑張っている人が少なく感じます。どうにも成果が足り
ない気がする。よく考えてない気がする。それはそうですよね。今のテンショ
ンのリーダーにかなう人は少ないでしょうから。
だからといって、頑張りが足らないように見えるメンバーに「もっと頑張れ。
なぜできない？」などといったプレッシャーをかけてはいけません。「いくら
リーダーでもそんなことしないでしょ？」と思われるかもしれませんが、実際
にはこのようなプレッシャーを有形無形で発してしまうことがあります。
絶対的な成果は本人の頑張りに単純に比例するものではありません。持ってい
るスキルや知識、さらにはその時に体調や心理状態によっても影響を受けます。
メンバーの時は理解していたこの当たり前のことを、リーダーになると忘れて
しまいがちになります。
● リーダーなんだから全て自分が決めなくてはならない
リーダーには権限と責任が伴います。技術的な決定事項や、スケジュールやタ
スクのアサインといった面に関しても、極論を言えばリーダーが全て決めて構
いませんし、実際にこのようなプロジェクトチームを何度か見たことがありま
す。
これで全てうまくいくのであれば、つまり、チームのメンバーを含めた関係者
が納得し、かつ継続可能な仕組みであれば構いませんが、そんなことは少ない
ものです。自分の意見が反映されないことに対する不満や不安やメンバーから
出始めたり、リーダーの負荷が高くなりすぎ、結果的にチームに迷惑をかけて
しまうことすらあるでしょう。
重要な決定といえども、最終的に自分が責任を負わなくてはならなくても、周
りに相談して決めればよいのです。リーダーといえども万能ではないし、そも
そも万能である必要もありません。
● 弱みは見せてはいけない。
まとめると、「リーダーなんだから弱みをメンバーに見せるわけにはいけない」
という思いが、これらの心理状態の大元にあるような気がします(私の場合はそ
うだった気がしています)。もちろん、この気概は大切にしてほしいのですが、
いつまでも張りつめた状態で働き続ければ、誰だって苦しくなります。
リーダーといえでも一人のエンジニアであり人間です。メンバーにだって、時
にはお客様にだって弱みを見せて構いません。最終的には、チーム全体で成功
すればよいのです。「リーダーの功績」や「リーダーの責任」に目を奪われて
はいけません。あなたより専門知識を持ったメンバーは他にもいます。お客様
の出した困難な課題はクリアできなくても、その重要性を理解し、手助けをし
てくれるメンバーは必ずいます。そのような気持ちでプロジェクトに取り組ん
でみてください。
今回は久々に「現場リーダーの心得」らしい内容となりました。リーダーとい
う役割は心得だけでこなせるものではありませんが、メンバーやお客様という
人間を相手にする仕事である以上、心理面を無視してはいけません。
リーダーシップにも様々なスタイルがあります。性格やプロジェクトの特性に
よって向き不向きもありますが、「メンバーの言うことをよく聴き、求めてい
ることを理解する」という行動だけは欠かせません。新米リーダーにまだその
ような余裕はないかもしれませんが、「なんだか苦しいぞ」と思い当った時に
は、思い出してみてください。(岡島)
■ 永和システムマネジメントの組込みソフトウェア開発
ICTとETのクロスーオーバーを目指します。
http://et.esm.co.jp/site/index.html
■「ソフトウェア開発を成功させるチームビルディング」
現場リーダーの仕事術をチームビルディングの観点から説明しています。
http://www.amazon.co.jp/exec/obidos/ASIN/4797352434/xpjp-22
■ okajima_yukioのtwitter
http://twitter.com/okajima_yukio/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [5]
● はじめに
この連載は、受入テストをテーマに扱っています。今日は、BDD(Behavior
Driven Development)の紹介です。
● BDDとは？
Wikipediaによると次のように書いてあります。
Behavior Driven Development (or BDD) is an Agile software development
technique that encourages collaboration between developers, QA and
non-technical or business participants in a software project.
It was originally named in 2003 by Dan North as a response to Test
Driven Development,and to Framework for Integrated Tests concepts, from
the Customer Test practice in Extreme Programming.
BDDの意図は、開発者、テスター、そしてドメイン専門家(システム要件に深い
理解のあるユーザあるいは顧客)とのコラボレーションを促進させることです。
Test Driven Development、Customer Testの特徴を引き継ぎつつ、仕様(Spec)
をキーワードにして、ビジネス側と開発側とのコラボレーションを
強調するように再構成したのがBDDになります。
● 他の手法と比較
他の手法との共通点／相違点を見ることで、BDDがどんな活動をさすのか、もう
少し説明を加えてみます。
1.TDD(Test Driven Development)とBDD
【共通点】
TDDとBDDどちらも、人がテスティングフレームワークを使ってコンピューター
と対話しながらCodeをつくり込んでいく点で共通します。
【相違点】
テスティングフレームワークで使用している語彙体系(例：assert_equal/should
eq)が異なり、TDD側は「テスト」を強調しているのに対して、BDD側は「仕様
(Spec)」を強調している点で差異が見られます。
また、BDD側はビジネス視点で外側からシステムの期待する振る舞いをクリア
にしていく「アウトサイドイン」を強調している点で違いが見られます。(た
だしXPの文脈では、Customer TestあるいはAcceptance TDDがこの役割を担っ
ていると思われます。)
2.(XPの)Customer TestとBDD
【共通点】
ビジネスサイドの視点でシステム実装の完了条件をクリアし、テストで確認す
るという点で共通します。
Customer Testでテストファーストを視野に入れるとテストを行うことと仕様
を取りまとめることの活動がオーバラップします。
また、BDDが実行可能な仕様を目指していることを考えると、こちらも仕様を
取りまとめることとテストを行うことの活動がオーバラップします。
XPは開発者向けの開発手法という印象が強いようですが、BDDと同様にドメイ
ン専門家との相互作用を重視していることが、顧客プロキシ、ユーザーストー
リーを使った計画ゲームの他に、Customer Testの活動にも見受けられます。
【相違点】
Customer Testは単体テストを対象としていませんが、BDDは単体テストも対象
に含まれる場合があります。
TDDと同様、テストと仕様(Spec)で強調している箇所が異なります。
【補足】
RubyでのBDD系のテスティングフレームワークの代表格にRSpec、Cucumberがあ
ります。
単体テストよりで開発者同士とのコミュニケーションを意識しているのが
RSpec、受入テストよりでドメイン専門家と開発者(テスターを含む)のコミュ
ニケーションを意識しているのがCucumberと、BDDのフレームワークの中でも
方向性が異なっているものがあります。
3.DDD(Domain Driven Design)とBDD
【共通点】
共通の語彙(DDDはユビキタス言語と呼んでいる)を使って、ドメイン専門家と
開発者のコラボレーション(対話)を重視している点で共通します。
【相違点】
DDDは、システム内部の「構造」に視点が向いているのに対して、BDD側は、外
側から見たシステムの期待する「振る舞い」に視点が向かっています。DDDは
モデリング(ビジネスDSL等の実装も含む)が中心的なテーマで、テスティング
フレームワークの利用について深く言及していませんが、BDDは、テスティン
グフレームワークの利用が中心的なテーマの1つです。
その他、User StoriesとBDDの関係も興味深いのですが、ここでは、字数の都合
上、触れないでおきましょう。
User Storiesについては、前回の連載を参照してください
前回の連載 → /ml-arch/magazine/330.html
これらの手法のキー要素を抽出すると、
- ドメイン専門家と開発者(プログラマ／テスター)がシステムについて共通の
語彙を用いて対話を重ね、システムに対する理解(誰向けに何をつくるか。何
故つくるのか)を深めること
- 早期にテスト実行可能な仕様の作成に着手すること。(あるいは、早期に仕様
のようなテスト作成に着手すること。)
でしょうか。
上記については、コミュニケーションを中心に添えた社会システムの座視でBDD
を説明してきました。
BDDはそのほかに、心的システムの座視(自然言語に近い語彙が、自然な思考を
生み出し、それが実行可能なCodeであれば、自然にCodeが・・・)で説明される
ことがありますが、ここでは、深く言及しませんでした。
● 余談
上記の手法らは、人の好みが別れ、論争が発生しがちですが、『こころを落ち
着かせて意見交換』できれば知的にエキサイティングな会話ができるテーマで
もあります。
ソフトウェア開発の醍醐味の1つだと思うので、異なるポジション同士でも不毛
な論争に陥ることなく、有益な意見交換ができるといいですね。
● まとめ
BDDの概要を紹介しました。
次回はBDDの特徴的な語彙(Given When Then, should)等に触れてみたいと思い
ます。(ienaga)
● 参考
BDD
- http://en.wikipedia.org/wiki/Behavior_driven_development
- http://behaviour-driven.org/
DDD
- http://www.amazon.co.jp/exec/obidos/ASIN/0321125215/xpjp-22
RSpec
- http://rspec.info/
Cucumber
- http://cukes.info/
● 過去の連載
1) /ml-arch/magazine/316.html
2) /ml-arch/magazine/321.html
3) /ml-arch/magazine/325.html
4) /ml-arch/magazine/330.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。突然ですが、みなさま、『セグウェ
イ』をご存知でしょうか？写真や詳細はWikipediaを参照していただきたいので
すが、個人的に今一番体験してみたい乗り物なんです。「アクセルもブレーキ
もなく、搭乗者の体重移動による直感的操作で速度調節から前後進、方向転換
を行う」・・・想像しただけで楽しそう！「車両としては遅すぎるし小さすぎ
る、歩行の代わりとしては自転車がある」という意見もあるようですが、今ま
でにない新しい発想と、それを実現してしまう力には、本当に感動します。一
度はセグウェイに乗ってみたい！乗ったらこの編集後記でご報告しますね☆
(ナガタユウコ)
*** オブラブスタッフ自己紹介 ***
No.10 平田
( @m_pixy, http://d.hatena.ne.jp/m_pixy/ )
こんにちは、平田です。
メルマガではふだん、要件定義についてのあれやこれやを書いています。また
オブラブイベントでは、参加者の皆様の緊張をほぐすようなお話を、会場内の
誰よりも緊張しながらやっています。アイスブレイクの時間は生暖かく見守っ
てください！
仕事ではお客様に近いところで、システムに必要なものを一緒に探す仕事をし
ています。最近の仕事の中でのメインのテーマは「業務システムをアジャイル
に作るには」というもので、なかなか答えが出ずに悩み続ける日々です。「い
い業務システム」を作るためにアジャイルに作るべきな予感はしているのだけ
れど、それを実証しきれていないところだったりします。
答えをお持ちの方、一緒に悩んでいただける方募集中です。イベントで声をか
けてください！
趣味らしい趣味は持っていないのですが、最近の休日はカメラ片手に娘の写真
を撮りまくっています。写真の腕は上達しないのですが、被写体がいいので
(←親ばか)なかなかいい写真を撮れてるんじゃないのかなぁと思う日々です。
これからもオブジェクト倶楽部を通じて、多くの人が集える場を作るのに、少
しでもお手伝いしていきたいと思います。よろしくお願いします！(平田)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.