Posts Tagged ‘agile’

まとまっていないアジャイル・チームビルディングのまとめ

1月 29, 2011

先々週のことになるだろうか、アジャイルチームビルディングというイベントに参加してきた。
無料で行われたイベントとしては大変、豪華で、ジョハンナ・ロスマンやエスター・ダービー、角征典さん、平鍋健児さんと日本のアジャイル界隈の人間なら知らぬ人はいない人たちが参加したイベントだった。

そもそも、良い仕事は優秀なチームによって行われる、というのは、開発手法はもとより業界の別を問わない考え方だ。
むしろ共通的な思想と言っていい。

そして、「どうやって優秀で素晴らしいチームを作るか」というのもまた、業界の別を問わない永遠に取り組むべき問題の1つだ。

今回のイベントの名前はアジャイルチームビルディングとなっているが、
講演者の話は、良い仕事をするために、「どのようにしたら良いチームが作れるか?」という疑問に答えようとするものだったと思う。

ジョハンナ・ロスマンは、個人の能力をどのように評価するか、すなわち、優秀な個人をどのように集めるか、のための6つの判断方法を提示した。

一方、エスター・ダービーは、チームがはまりがちな罠を紹介して、優れたチームをまとめあげるための方法を示した。

良いチームをつくるためには優秀な個人が必要なことに加え、優秀な個人をチームとした形作るのはまた別の作業だ。
ジョハンナとエスターの話は、まさにチームビルディングについて包括的な説明をしてくれた。

ジョハンナは、アジャイル開発に適した能力もつ人材を見抜くための6の判断方法を示した。
・共同作業が出来る人か
・助けを求めることが出来る人か
・自らすすんで、小さく作業をして頻繁なフィードバックを得られる人か
・自らすすんで、現状に適して十分な行動を取れる人か
・順応性のある人(Adaptable people)か
・自らすすんで、専門外の仕事ができる人か

英語が苦手なので不正確な情報になるかもなぁ、と悩んでいたら、どなたかのTwitterのTLに発表に使われたと思われるの資料のURLが流れてきた。
正確な情報は下記を参照してほしい。
http://www.slideshare.net/johannarothman/six-behaviors-for-agile-team

ジョハンナが与えてくれた重要な示唆は、practice(プラクティス)とbehavior(行動)は違う、というものだ。

たとえば、「TDDをやっています」、「ScrumのDailyMeetingをやっています」といったところで、「実際にどのような行動を指しているか」は異なる。

TDDならRed→Green→Refactorのサイクルを愚直に回しているか。
DailyMeetingなら3つのこと、昨日やったこと、今日やること、抱えている問題、を話せているか。
こうした行動は、プラクティスを使ったことがあります、といわれても確認はできない。

僕のチームでもDailyMeeting、朝会をやっているが、3つのことを言うことを徹底できていない。
でも、その会は「朝会」と呼ばれているので、参加者全員にとっては朝会、だ。

このように、プラクティスを使用した経験を尋ねると、文脈に違いによるミスマッチが発生する、ということだ。
なので、単純に「そのプラクティスをつかっています」という言葉はあまり意味が無い。

そのプラクティスを「どのように使ったか」という行動に注目する必要がある。
また、たとえプラクティスを使ったことがない人でも、プラクティスが目的とする結果、実績を残す行動をとれてれば良い。

TDDをしらなくても、Red→Green→Refactorのサイクルを愚直に回していれば良いわけだし、DailyMeetingについてもしかりだ。

ジョハンナのいうことをシンプルに言ってしまうと、その人の実績に注目する、ということだ。

こうした視点は、自分が「誰をチームに受け入れるか」というのにはもちろん、自分自身の力量を図るにも使える。
「実際に自分はどのように行動しているのか」が、すなわち自分の技量、才能の明確な判断基準になるはずだ。

エスターは、チームビルディングではまりがちな罠として、以下の項目をあげた。
箇条書きではわかりにくい、と思われるものは若干、補足した。
が、これも英語だったので、かなり不正確なのをご承知いただきたい。

・チームがチームじゃない
権限者などによって「チームになれ!」と言ってもチームになるわけではない。
固定的で、協調的に仕事をしているのが良いチームだが、そのようなチームばかりではない。

・チームに境界がない
チームにどのような権限や責任が付与されているかわからない。チームとその他をわける境界が低い状態。
もしくは、チームの外部から情報が入ってこない。チームとその他の分ける境界が高すぎる状態。

・リーダーが不在、もしくは支配的
決断ができない。もしくは、決断を特定の人物に依存する。

・言い合いが全く存在しない

・ひとつのアイデアしか持たない

・情報のシェアがない

・役割への信頼が無視される
文章と文章の意味合いともに不明確。すみません。

エスターが示した罠を知っても、「この罠にはまらないようにしよう」と身構えるためにしか使えないと思う。
どんな優秀な個人でも、優秀なチームでも多種多様な状況の変化にさらされれば、好調な状態を保つのは難しい。
むしろ、どんなチームであれ、罠にはまることは前提としたほうが現実的だ。

なので、自分たちのチームが「罠にはまっている」ということに素早く気づくために使える。
なんとなくチームがうまくいっていない、と思ったときに、「ぼくたちはこの罠にはまっていないか」と眺めるとよいかもしれない。

なお、話のなかでは罠にはまったら、どうやって対処するか、についてもエスターは言及していたが、ここでは割愛した。

ジョハンナとエスターの後に、角さんが紹介してくれたDevOpsという考えがとても印象に残った。
ジョハンナ、エスターの話を実践した後にたどり着く、1つの理想のチームの形を提示だと思う。

アジャイル、WFに関係なく、ワン・チームといったところで、システムを作る「開発」とシステムを動かす「運用」はわかれがちだ。
僕が務めている会社は小さいので、開発・運用をわける、というのあまり進んでいない。
が、チームの実情としては、システムの詳しい人に運用面を依存しがちだ。

チームとしては分かれていないが、人のレベルでは、開発と運用は分けられている。

角さんは、ご自身を開発者の視点におき、「運用」という仕事を「見えないゴリラ」として紹介し、開発と運用が分かれている現状に問題を提起した。
ちなみに、「見えないゴリラ」は下記の動画が語源になっている。
「白い人が何回パスをしているか?」に注目して動画を見ていると、ゴリラの意味がわかる。

DevOpsという考えは、開発が運用というゴリラの存在を認め、開発と運用を1つのチームとしてとらえようという考え方だ。

顧客から頻繁なフィードバックを得ようとすれば、開発者に運用を任せるというのは決して悪い考え方ではない。
顧客のクレームは、アイデアを得るという形でもプラスであろうし、品質の高いシステムをつくるという面でもプラスだ。
的を射た意見はシステムを洗練されせるのに役立つだろうし、品質の悪いシステムへのクレームは良いプレッシャーになると期待できる。

ただ、過ぎたるは及ばざるが如しで、あまりにも顧客にかかわっていると、開発の速度が落ちてゆく。
これを懸念して、どうしても運用と開発を分けたくなる。

また、運用面は顧客にかかわるだけでない。
むしろ、システムの安定稼働させるために、ネットワークやサーバー負荷などに対処するなど、俗にいうインフラ周りの仕事が運用の真骨頂といえる。
運用業務は、高度な専門的な知識が必要とされるため、知識自体が壁になって開発と運用がわかれてしまう。

開発と運用を運用を分けない、というのは耳心地のよい言葉なのだけど、タスクと知識が壁となって実現は難しいだろう。
が、たしかに理想のチームの姿だと思った。

最後に平鍋さんと松本さんがおはなししてくれたのだけれど、力尽きてメモが取れなった。

それにしても、こんなにためになる豪華なイベントが無料とは。
企画をしていただいた方には感謝。
日本は、良い国だ。

ちょっと追記:
外国の人の名前を書くときには、Mr.とかMs.などと付けるのは違和感がある。
しかし、日本の人の名前を書くときには、敬称として「さん」をつけたくなる。
ジョハンナとエスターの敬称は省いていますが、ちゃんと尊敬はしております。

広告