Posts Tagged ‘すくすくスクラム’

朝会ワークショップを楽しんだ@すくすくScrum

10月 2, 2011

2011/09/30(金)にすくすくスクラムに参加してきた。

今回はなぜか前説的なLTをやらせてもらえることになっていたので準備していった。
が、開始準備に手間取ったため、LTが割愛されて本編がスタートすることになった。

悔しいので、slideshareにあげた資料をブログで公開する。
http://www.slideshare.net/KeiOgasawara/ss-9509007

経験上、朝会は毎日やることが重要だ。
名前から「朝」を強調しているようだが、朝にやることにこだわるよりは、毎日やることにこだわるものだ。

不勉強なので、朝会がもともとScrumでいうところのDailyScrumを訳したものなのかは知らない。
が、僕は朝会ではなくてDailyScrumと呼ぶほうが好きだ。特に導入時は。

もしもDailyScrumを訳したものならば、朝会という言葉は、「朝やる」というニュアンスが強すぎるかもしれない。

そのために、導入当初では
・フレックスタイムの職場では朝は人が集まらないからやらない
・予定していた朝の時間にメンバーがあつまれなかったからやらない(昼や夕にはやらない)
という状況が引き起こされることもあったので、個人的には、特に導入時の名称は朝会ではなくDailyScrumのほうを使うと良いと思う。

重要なのは、「朝」ではなくて「Daily」であることだ。
毎日、継続的に15分という短い時間を効果的に使って情報共有をすることを訓練し、実践することがDailyScrumだと考えている。
そして、効果的なDailyScrumをつづけることが、チームをつくる基礎になるよ、と言いたかったLTだった。

あと、会社の社員募集もしたかった。(一部の方にはお話できたけど。)

場の進行は、かいちょーが仕切ってくれて助かった。
今回はなにかと準備不足で、発表資料を直前まで見ることができなかったにも関わらず、会を進めながらスライドを先読みして進行してくれた。

まさにアジャイル、とかいうとあらゆる方面から怒られそうだけれども、その場で最善を尽くそうという姿勢は大事だ。

なによりワークショップが盛り上がったのは、参加してくれた人たちが積極的にしてくれるからだ。
毎回、思うことなのだけれどもすくすくScrumに来る人たちは、その場を大事にするというか、その場をよくするために自分で何とかしよう、と考える主体的な方が多い。

だから、少々、進行や場のセッティングが拙くても、良い場ができてしまう。
本当にありがたい事だ。

と同時に、それに甘えないようにしたい。

ビールがなければお菓子をたべればいいじゃない、とおもった@すくすくScrum

7月 27, 2011

昨晩、すくすくScrumに参加してきた。
テーマがファシリテーション入門だった。

発表資料が非常が膨大で、途中、細かい説明が飛ばし飛ばしになってしまったのがもったいないなと思いながら聞いていた。

今回行われたワークショップは、旅行の計画をたてるというものだった。
各々どこに行きたいかを話して、最終的に1つの場所に絞るというものだった。

合計で2回の計画を行い、各々が行先に満足したか、というアンケートをとるものだった。

僕が参加したチームは、協力的な人たちばかりだったうえに、2回共に提案された1つの行先が魅力的だったため、すぐに行先に合意できた上に満足度も高かった。

そのようになった要因は、
・議論の前提を作ったこと
そして、
・その前提にチームが合意できたこと
だと思う。

最初に僕らが決めた行先は「月」だった。
その時に合意した前提は、「自分たちが立ち上げた会社がIPOに成功して、億万長者になったらどこにゆくか」というものだった。

億万長者なったら、お金もあり、時間もある。
だからこそ、チームの全員が「月」という荒唐無稽な目的地に合意できた。

たとえば、今度の夏休みとか、今の仕事をしながらとか、そのような前提にたっていたら、この目的地に決まることはありえない。

2回目に決めた行き先は「シリコンバレー」だった。
これは、「チーム全員が開発者である」というチームのコンテキストを踏まえて、「このチームで行くならどうするか」、という前提をたてたことによって、合意できた目的地だ。

1回目との違いは、自分たちのコンテキストを意識した点だ。

1回目に話してきた感覚から、「みんな、シリコンバレーでの躍進中の企業の見学したいと思うだろう」という推測があっての提案だっと思う。

これは僕たちのチームが開発者が多く、シリコンバレーの動向に興味をもっている人が多い、というチームの背景を感じ取った結果でもあると思う。

そのうえで、「このチームで行くならば」という前提にたって、提案したからこそスムーズに行先に合意できたのだと思う。

たとえば、同じチームの人が言っていたのだけれども、前提が「家族で行く場所」だったら、おそらく合意にはいたらなかったはずだ。

「僕たちチームで行く」という前提に合意し、では僕たちチームの共通の興味や価値を感じる部分は何か、というチームのコンテキストに注目した提案がなされた結果、すんなりと合意できたのだ。

ファシリテーションというのは、合意形成を手助けしてくれるものでもあると思うのだけれど、今回の僕らのチームは合意形成のための仕組み、というのを必要としなかった。

それだけ価値観が近い人達が集まったチームだったのかもしれない。

最後に、本編が終わったあとにスイーツバッシュを行った。
これは、会場の都合上、ビアバッシュのかわりに行ったものだ。

でも、これが個人的にはかなりいいと思った。
お酒が入らないので、必要以上にうるさくないし、話した内容も翌日まで細かく記憶している。
なおかつ、翌日が辛くない。

勉強会後の懇親会でお酒を飲むのは楽しい。
でも、ちょっと疲れてしまうこともある。

スイーツバッシュでは、ソフトドリンクを飲みながら甘いお菓子を食べたのだけれど、疲れがとれて行く感覚だった。

辛党の人にはあまり嬉しくない催しかもしれないけれど、甘いお菓子を食べながら学びについて意見を交換する、という場はお酒を入れた懇親会とは違った魅力がある。

かなりお勧めしたい。

ワークショップによる「驚くべき学びの世界」@すくすくScrum

5月 29, 2011

社会人になると仕事そのものが一番の学習の場になる。
ビジネス書を読んだり、技術書の写経をしたり、勉強会に出席したり、というのは、補完的な行為にすぎない。

なにを補完するのか、といえば、仕事の場で学べないことだ。

同じことに取り組み続けると仕事はルーチン化する。
そうなれば行動はもとより、行動と共に思考もルーチン化する。

行動と思考のルーチン化によって、今までにない問題に直面してもよいアイデアがでず解決できなかったり、解決に時間がかかったりするかもしれない。

新しいことに取り組むための発想や意欲がかれてしまうかもしれない。

補完的な学習の場は、今の仕事では手に入れることのできない情報と発想を手入れるためにある。

だからこそ、一番の学習の場である仕事を離れて、補完的な学習だけの機会をもつことは価値のあることだ。

ただ、本を読んだり、実績のある人の話を聞いたりしても、あまり成長はない。

もちろん、外から情報を取り込むことは無価値ではない。

取り込んだ情報は、次に取り込んだ某かの情報とスパークを起こして、新しいアイデアや思考につながることもあるからだ。

ただ、取り込んだ情報を咀嚼して知識としたり、自身の成長につなげたりするためには、実践が必要だ。

とくに、あるエンジニアの人の事例を聞いた場合は、現場で事例と同じように行動してみることが重要だ。

とはいえ、それは簡単ではない。

仕事の場では、実践する機会がないことも多い。

権限がない、協力してくれる人がいない、という状況では、行動を取りづらい。

また、話を聞いただけで、ブログにまとめただけで満足してしまうこともある。

僕自身も、頭に入れた情報を血肉とするために必要な実践の機会を得られない、という焦りやジレンマのようなものを感じることは多い。

しかし、今回のすくすくScrumに参加して、焦りやジレンマの解決方法として、ワークショップが非常に有効だと感じた。

今回のセッションでは、Scrumのプロセスをお持ちいて、チームで紙飛行機をつくるというワークショップが行われた。

僕自身は参加していなかったのだけど、外から見ていて参加者の人達がすっっっごく楽しそうだった。

われ先にと紙飛行機をつくり、規定の距離を飛ばすために工夫を凝らす。

作った紙飛行機を力いっぱいなげる。走りまわる。

参加者の熱気で会場の温度があがったしまったので、エアコンの気温を1,2度下げる必要があるほど盛り上がっていた。

こうしたワークショップの盛り上がりは場の雰囲気を良くする以上の価値がある。

それこそが、頭にいれた情報を実践を通じて体で学べることだ。

Scrumの理論は非常に理解しやすい。しかし、実践はむずかしい。

それはScrum自体を行うこともそうだし、そもそも今の開発現場の開発プロセスにScrumを持ち込むことにもいえる。

しかし、ワークショップをおこなうと擬似的にでも、実践することが可能だ。

そして、頭で理解した理論を体感できる。

ゲーム中はみんなゲームに真剣すぎて、ワークショップの意味やScrumのプロセスの価値について考えなかったかもしれない。

でもふりかえったら、次のようなことをワークショップから学ぶことができたのではないかと思う。
・自主的に物事にとりくむとおもしろい
・思ってもない成功はオーバーコミットを招きやすい(過剰な成果を約束しやすい)
・ふりかえりによるフィードバックを行うことで同じ失敗をしなくなる

ほかにも、そもそもScrumという技法が自分の性格や自分の現場に合うかどうか、講師が説明しきれない点にも疑問をもったり、自分なりの考えをもったりできたのではないかと思う。

なによりも、現場に持ち帰ったときに擬似的にでも経験していると、体験談として理論の説明ができる。

他人の言葉ではなくて、自分の言葉で説明できる。それは、情報が知識となった証拠の1つだ。

ワークショップは、勉強会を情報収集の場としてだけでなく、知識として咀嚼する場に変貌させてくれる。

ワークショップには主体性と体感、頭だけでなく体を使った理解に到る機会がある。

今回、ワークショップの価値について考えさせられたのは、ワタリウム美術館で開催されている「驚くべき学びの世界」展を見たからだ。

展示が非常に素晴らしく、イタリアのレッジョ・エミリアという場所で子供たちどのように主体的に学習に取り組んでいるか、学びを楽しんでいるかがよく伝わってくる。

主体的に、全身を使って目の前のことに取り組みながら、自力で知識を獲得してゆく学習の過程を見て取れる。

子供のように学ぶことが自分たちに求められているか、それは良くは分からない。

でも、自分が関わる勉強会を、楽しく学ぶ子供たちのように、エンジニアが学べる場にしたいと思う。

その場づくりの有効な手段となる可能性を、ワークショップに感じている。

最後に。
今回、すくすくScrumははじめて日本橋を離れて渋谷での開催でした。
会場を提供いただいたのはECナビさんでした。
会場の素晴らしさにくわえて、社員の皆さんのホスピタリティが素晴らしく非常に助かりました。
ありがとうございました!

なにより講師の@Qooh0 さんありがとうございました!

「ほめられる」の大切さを考えた@すくすくスクラム

2月 6, 2011

先週あたりに、今年初のすくすくスクラムに参加してきた。

モチベーションアップをテーマとしたセッションのなかで、印象に残るワークを体験してきた。
正式な名前を忘れてしまったのだが、1分間、とにかく「ほめ言葉」を浴びせ続けられる、というものだ。

このワークを体験して、ほめられることの大切さを考えさせられた。

そもそも、仕事上で、誰かの行動やアイデアをほめる、というのは難しい。
というのは、誰かをほめるには、それなりに相手のことを観察し、知っている必要がある。

僕が勤めている会社は、ほぼ1フロアの職場だ。
そのため、誰が何をやっているかは比較的分かりやすい。
すくなからず、同じチームで誰が何をやっていて、どういう結果をだそうとしているか、を理解するのはたやすい。

しかし、それが部署をまたぐととわからない。
誰がどんな目的で、何をやっているか、そして、それが達成されたのかがわからないと、ほめることできない。

たしかに何も事情が分からないけれど、「がんばってるね」ということは言える。
しかし、事情を知らないような人間に、表面的にほめられたとしてもうれしくない。

なぜなら、ほめ言葉は、言葉の内容もそうだけれど、それ以上に「誰に」言ってもらえたかも重要だからだ。
そして、その「誰に」ということに関しては、「自分のことを理解している」とほめられた人間が思えることが重要なのだ。

そのため、人をほめるのがうまい人は、相手をよく観察していて、そのことを相手にちゃんと伝えている人に限られる。
職場ともなれば、そんなことが出来る人は稀だと思う。
自分自身の仕事をこなしている状況で、周囲の人の活動に気を配る、ということは並大抵のことではない。

職場で働いてい人を上手にほめられる、というは、卓越したひとつ才能なのだ。

だから、他者をうまくほめられる人は少ない。
他者をうまくほめられる人間が少ない、という状況が生み出しているのが、ほめられベタな人、だ。
ほめられ慣れていないから、いざほめてもらっても、素直に受け取れない。
たとえば、謙遜したり、否定したりする。

謙遜や否定は、謙虚さという美徳を表すものではあるけど、一方で、やはり相手の意見を否定することでもある。
せっかくほめたのに否定されてしまったら、「次も言おう」という人は減ってしまう。
数少ないほめ言葉がもっと少なくなってしまう。

なので、すくすくスクラムでのワークで、ずっと自分がほめ言葉を浴び続けていておもったのは、
「もっとうまくほめられたいなぁ」
「ほめられてうれしい気持ちを、もっとうまく伝えたいなぁ」
ということだった。

損ことを考えるほどのほめられベタな僕は、ほめられる貴重な機会を逃さないために心がけていることがある。
それは、ほめられたら、お礼をしっかり伝えることだ。

相手が誰か、言葉の内容がどうかに関係なく、脊椎反射で「ありがとうございます」と言ってしまうのだ。

「お世辞なのに馬鹿じゃね?」と思われているかもしれない。
でも実際、ほめられたら嬉しいし、「天才だ!」と思われるより馬鹿にされていたほうが気楽だ。

また、脊椎反射で言うから心がこもっていないかもしれないが、少なくとも言葉で否定を表すよりはマシだと思っている。

上述のように的外れなほめ言葉でイラッとしているかもしれない。
でも、ほめ言葉をいわれたほうがマシだ。

それよりも、自分がいる場にほめ言葉が増えてゆくほうが気分が良くなる。
場の雰囲気も良くなると思うからだ。

表面上のほめ言葉よりも、本音の愚痴や悪口よりは、職場の雰囲気作りには役立つだろう。

ひとつだけ、気をつけたいのは、表面上のほめ言葉ばかりが流行ってしまうことだ。
あまりにもほめ言葉だけが蔓延してしまうと、誰かの行動を注意しづらかったり、反論しづらかったりする雰囲気を作ってしまうかもしれない。
その場にいる人たちが、素直に自分の思いをことばにできなくなってしまうかもしれない。

とはいえ、そんなことが気になるほど、ほめ言葉を聞く機会は多くない。
今の職場でも、もっとほめ言葉を聞いていいと思う。
だから、ほめられたら素直にお礼を言う。
自分が耳にする、貴重なほめ言葉にちゃんと感謝の気持ちを表したい。

リーダーって何だ?

1月 28, 2010

<状況対応リーダーシップを学ぶ>
2010/1/25(月)に第8回すくすくスクラムに参加しました。
今回のテーマは、「1人1人がリーダーだ!」ということで、スクラムチームにおいて、ひいてはスクラムを行う/行わない、にかかわらず組織においてのリーダーの振る舞い、を学ぶことが目的でした。
ちなみに、発表に使用されスライドは下記のURLから見られます。
http://www.slideshare.net/SukusukuScrum/no00801suc3rum20100125

この勉強会で学んだこと、そして思ったことは、

とるべきリーダーシップは、状況によって変わりうる
リーダーの立場をとる人が変わっても良い
リーダーと責任者は違う

ということです。

<レディネス・レベルを基準にとるべきリーダーシップを変化させる>
レディネス・レベルとは、ある課題を解決するためにどれほどの準備ができているか、というレベルをあらわすものです。
そして、レディネス・レベル、「意欲」と「能力」の2軸によって、以下のように判定されます。

レベル1:「意欲」が低く、「能力」が低い
レベル2:「意欲」が高く、「能力」が低い
レベル3:「意欲」が低く、「能力」が高い
レベル4:「意欲」が高い、「能力」が高い

このレベルが高いほど、課題を解決するための準備ができており、課題解決の可能性も高いといえます。
リーダーシップは、このレディネス・レベルによって変化させる必要がある、と状況対応リーダーシップは考えます。
すなわち、

レベル1:「意欲」が低く、「能力」が低いチームにたいしては、教示的なかかわり
レベル2:「意欲」が高く、「能力」が低いチームにたいしては、説得的なかかわり
レベル3:「意欲」が低く、「能力」が高いチームにたいしては、参加的なかかわり
レベル4:「意欲」が高い、「能力」が高いチームにたいしては、委任的なかかわり

とリーダーシップのとり方を変化させる必要があるということです。

教示的なかかわり方とはなにか、という細かい説明は、上記に紹介したURLでスライドを見ていただくこととして、重要なことは、チームの状況いかんによってリーダシップを変化させる必要がある、ということです。
リーダーというと、カリスマ性を持ち、確固たる信念を持ち、一貫性のある姿、行動を想像させます。
しかし、状況対応リーダーシップにおいては、一貫性のある姿や行動ではなく、チームの状況に合わせて振る舞いを変えることのできる柔軟性を求めています。

自らの価値や考えを明確に打ち出し「俺について来い」というリーダーシップ。
自らの意思や欲望を抑え「あなたたちを信頼して任せるよ」というリーダーシップ。

どちからといえば、後者の相手に権限や行動を委任する、というリーダーの方が人間的にも、成熟している印象があり、人間的にも優れていると感じます。
しかし、そのようなかかわり方しかできないと、レディネス・レベルがレベル1のチームには良い影響を与えません。
優れたリーダーシップは、チームの状況に合わせて、自らのスタイルを適切に変化させられる、柔軟性をもっているのです。

<リーダーの立場になる人は変わっても良い>
発揮すべきリーダーシップが、チームの状況に変わる、という考え方を少し推し進めると、「状況の変化に応じてリーダになる人が変わっても良いのではないか」という考えが生まれてきます。
状況に応じてリーダーそのものを変えてしまう、という考え方は、欧米の企業の取締役会が、自分たちの解決すべき課題を洗い出し、それに適任の人物をCEOとして向かえいれる、という習慣に似ています。
つまり、リーダーを、その人の「能力」に注目して選択しているのです。もちろん、「意欲」が高いということも前提にしているかもしれません。

しかし、リーダーをこうして選択する方法が、はたして良い結果を生むのか、という疑問はあります。
会社ひとつをとっても、1年間だけで噴出してくる問題は多岐にわたります。
そのたびに会社のトップである社長を交代したり、部の管理責任者である部長を変更したり、と組織をいじってしまうと組織に安定感がなくなってしまいます。
ようるするに、現実的ではありません。
また、上記のように招かれたCEOが実力を発揮し、突出した成果を残した、という話はあまり聞きません。

しかし、私が所属している開発チームにおいては、リーダーの立場になる人は状況において変わる、ということを体験することがあります。
たとえば、

お客様と話すときは交渉や機転が利く○○さんが中心に対策を立てよう
この業務においては、そこに詳しい○○くんの考えを中心に仕様を決めよう
結合テストは、全体的な業務と仕様にくわしい○○さんを中心に運営しよう

というように、チーム内ので作業フェーズや求められる能力によって、中心となる人物が違います。
このことは、リーダーを状況によって変化させている、と捉えてもよいと思います。

また、仕事じゃなく、趣味を考えると、状況によってリーダーが変わる、ということが一般的である、とすら思えます。
たとえば、私の職場には自転車に詳しい人、筋トレに詳しい人、秋葉原事情に詳しい人、PCに詳しい人、音楽に詳しい人、などいろいろな趣味をもった人がいます。
こうした人たちは、その人たちの周囲に大きな影響を与えています。
たとえば、自転車を買おう、と考えれば、自転車に詳しい人に話を聞きに行きます。
上京してきた友人を秋葉原観光に連れてゆこう、と考えれば、秋葉原事情に詳しい人に話を聞きに行きます。
そして、大半の人はその人たちの話を聞いた結果、その善意のアドバイスにしたがって行動するでしょう。
このようなことを続けてゆくと、ある集団において、アドバイスをし続けた人たちは、必然的にその分野において周囲に大きな影響を持つことになります。

教えを請うという状態の人、すなわちレディネス・レベルがレベル1ないしはレベル2の人にたいして、影響を及ぼしているわけですから、そのリーダーシップは、教示的ないしは説得的なものです。
そのため、リーダーシップの種類として、参加的、委任的な態度は含まれていないことになります。
しかし、集団においてある「能力」が不足している状態で、それを補完する優れた「能力」をもつ人が、その状況下で集団に大きな影響を及ぼし始める、というのは、状況対応リーダーシップについての事例のひとつになりうると思います。

<リーダーはリードする、責任者は責任を負う>
状況対応リーダーシップを発揮する人をリーダーというとき、それは人や集団をミスリードする、という可能性を含んでいません。
どのような態度をとっていようとも、リーダーは人や集団を良い方向に導いています。

しかし、ミスリードを行う可能性をリーダー持っているのであれば、リーダーはある状況下で人や集団にたいして一番、影響力をもっている人、と定義できます。
こうしたとき、会社だと課長や部長、そして、社長なども立派にリーダーといえます。
そのような地位にある人たちは、自らの部下と自ら統括している組織が抱える仕事に大きな影響力を持っています。
程度の差はありますが、組織内で人を好きに動かすことができますし、仕事の割り振りについても裁量を持ちます。
とはいえ、そのような立場にある人たちが一様に、リーダーとして周囲に受け入れられているワケではありません。
むしろ、ハゲ課長、バカ部長などと、バカにされていることのほうが多いように思います。

なぜなら、ハゲ課長やバカ部長は、その人にとって単なる組織の責任者に過ぎないからです。
部長や課長という役職をもつ人は、単にそれだけでは、遅刻・欠勤の際に連絡する人、経費清算の際に書類にサインをもらう人、休みの許可を申請する人、でしかないのです。
部下や周囲の人たちから見て、周囲に良い影響を与えていない責任者は、単なる責任者でしかありません。
むしろ、その単なる責任者が、自分の力や立場を勘違いして傍若無人な振る舞いをとると、嫌なやつだとみなされ、ハゲ、バカ、扱いになるのです。

しかし、責任者は、組織としていなければいけない存在でもあります。
責任者がいないと、誰に遅刻や欠勤の理由を伝えるのかも、経費申請をすべきなのかも、わからなくなります。
そして、従来、組織の責任者は、同時にリーダーであることも求められました。
しかし、こうした周囲の期待に責任者が応えるのは、容易なことではありません。
上記のように状況は容易に変化し、チームの「能力」と「意欲」は常に変化するからです。
このときに、責任者は自らのリーダシップを変化させて対応せねばなりませんが、多種多様なリーダーシップをとることは大変むずかしいことです。。

こうした状況下での正解は、リーダーシップを発揮すべき人を他に任命し、責任者は自らの立場と範囲において責任を取る、というものになるのではないでしょうか。
確かにそのようなことをすると、責任者は完全にまな板の上の鯉状態になります。
結果を出すべきチームのハンドリングを他の人に任せてしまい、責任者自らはその成否の責任だけとるわけですから、割に合わないとすらいえます。
しかし、責任者が冷静に判断すべきです。
つまり、自分で権限をもち続けて失敗するか。
それとも、自分の権限をリーダーとなるべき人に、役職も立場も関係なく委譲し、成功することにかけるか。

リーダーシップというと、役職や地位を伴っている人たちにもとめられるものでした。
それゆえに、リーダーとは役職つきの人たちのことを指すことが当然のものともされてきたと思います。
しかし、ある状況下で、人や集団に大きな影響を与える人をリーダーと呼ぶのあれば、その集団にいる人々たちすべてがリーダーになりえます。
重要なことは、そうしたリーダーが入れ替わってゆく状況をいかに受け入れる体制を作れるか、ということではないでしょうか。
組織における責任者は、肩書きどおりに振舞うことに固執しすぎて、状況や現場が生み出すリーダーたちをつぶしてはいけないのだと思います。
むしろ、そうしたリーダーをバックアップすることで、良い組織が出来上がってゆくのではないでしょうか。
少し理想論が過ぎると思います。
しかし、一人の万能型のリーダーが組織を引っ張り続けられる、と考えるよりは、むしろ現実的なものであると私は思っています。

『ひとつ上のチーム。』ってなんだ?!

12月 6, 2009

かなりまえになりますが、『ひとつ上のチーム。』という本を読みました。
コピーライターの眞木準が編集をつとめ、広告業に携わる人たちの理想のチームについての考えを、纏め上げた本です。
編集の眞木準をはじめとして、登場する人々は「見たことある!」、そして、その時代で話題となった広告に携わってきた人たちです。

私が当時この本を手に取ったのは、広告業とソフトウェア開発、はとっても似ているところがあると思っていたからです。。
まずは働く単位がプロジェクトである、というところです。
何か広告を生み出すときには、その期間に人が集められ、広告という成果物を生み出し、チームは解散、となります。
ソフトウェア開発でも、お客様からの依頼があり、いつまでにシステムを納めるかという納期(プロジェクトの期間)を決め、システムという成果物を生み出し、開発チームは解散となります。
次に、肩書きにカタカナが多いことです。
広告業では、クリエイティブディレクター、コピーライター、デザイナー、CMディレクター、フォトグラファー、プロデューサー、マーケティングディレクターなどなど、まだまだたくさんの肩書きがあります。
ちなみにソフトウェア開発では、プログラマー、プログラムマネージャー、プロジェクトリーダー、アーキテクト、コンサルタント、さらにはシニアプログラマーなどなど、です。

2つの共通点をもつ広告業とソフトウェア開発は、日本における立場には天と地ほどの違いがあります。
今、就職活動に励んでいる学生も多いかと思いますが、そのほとんどの人たちは「広告業って面白そう」、と思って採用試験を受けると思います。
一方、ソフトウェア開発については「面白そう」と思って、採用活動を受ける人たちが何人いるでしょうか。
また、広告業のこうしたチーム論の本を出せば広告業以外の人も手に取ることはあるでしょうが、ソフトウェア開発の人たちがこうしたチーム論の本を書いた場合、どれほどの人たちが手にとるでしょうか。
自分が仕事をしている業界を悪く言いたくはありません。
そして、現に今の仕事にはたくさん面白みを感じています。
ただ、一般の人たちはおそらく、現場にあるソフトウェア開発の面白みをまったく知らない。もしかしたら、興味もないかもしれません。
なので、本を読んだ当時は、こうしたチーム論の本を作り売り出せる、という広告業の立場の人たちをうらやましく思いました。

<チームの二論>
今回、私がこの本を取り上げたのは、2009/11/25(木)に「すくすくスクラム」「チームとは何だ?!」という勉強会に参加したからです。

広告業とソフトウェア開発の共通点は、上記に挙げた働く単位、肩書きだけでなく、意識する組織の単位がチームである、という点もあげられます。
もちろん、会社という大きな組織に所属しているのは、他の業界と同じです。
しかし、プロジェクト、という単位で働いて成果をもとられるので、意識する組織の単位は会社ではなく、プロジェクトのチーム、という単位です。

「すくすくスクラム」の勉強会では、スクラムという開発手法をもちいたシステム開発プロジェクトに携わる人たちのチームにとって大切なことはなにか、優れた成果をだす「ひとつ上のチーム」とはなにか、グループワークを交えて学んできました。
講師は、アジャイル開発の導入支援などに携わるodd-e-Japanの代表取締役、エマーソン・ミルズさんです。

・良いチームは統一的な理念、目標をもっている
・人は育てるのではなく、育つ
・失敗は人とチームを育てる
・管理できる失敗を仕掛けることでチームの成長を促すこともできる

など、チームやチームを構成する人についてのさまざな指摘がなされたのですが、私の印象に残っているのは、

・うまくいっているチームを解散させてはいけない

という言葉です。
うまくいっているチームとは、チームのメンバー同士の信頼も高く、成果も出していいるチームです。
こうしたうまくやっているチームの良い部分を、他のチームに波及させるため、うまくいっているチームを解体してしまうことは、プラスがないとミルズさんは言います。
うまくいっているチームとは、仲の良いメンバーで楽しく仕事をし、成果を出している。
にもかかわらず、成果を出したとたんに解体してしまったら、仕事をうまくやるインセンティブはない、というのです。
たしかに、うまくいっているチームほどチームメンバーの仲もよく、楽しくは働いている印象があります。
そして、そのようなチームを解体させることには利点はないのかもしれません。

実際、私が今、所属しているチームもおなじ会社のシステムを10年以上もの間、開発から保守・運用まで携わっているチームです。
そして、長い期間、それほどメンバーが変わることなく、続いているチームです。
私自身も、入社して半年後にそのチームに配属されたから、一貫してそのチームに所属し続けています。
ですから、ミルズさんがおっしゃっている同じチームに所属することの利点を実感しており、共感をもちました。

しかし、仲が良いからといってずっと同じチームで仕事するべきなでしょうか。
ずっと同じメンバーで仕事をすることでチーム内での知識や技術の属人化が進んでしまわないのか。
そして、誰と一緒じゃなきゃダメ、そして、成果が出せない、というのでは、その人にはあまりにも柔軟性がたりないのではないか。
そのような疑問も抱いてしまいました。
仲の良い、やりやすいチームでやることが成果をだすことにつながる、というのは事実でしょう。
一方、現実としては、誰とでも、どのような状況でも成果を出すことを求められます。

『ひとつ上のチーム。』でも以下のような2つの対極の考えが紹介されています。

まずは、チームの人にはこだわりを持つのがプロフェッショナルな仕事をする条件である、という考え方です。

誰と組んでもいい仕事ができるというわけではありませんから、組む相手はおのずと決まってきます。これはやむをえないことだとぼくは思います。
いいかえれば、チームがうまくいくかどうかは、その人が優秀であるかどうかだけで決まるものではないということです。
スターばかりを集めたドリームチームをつくれば、それで何もかもがうまくいくわけではない。仕事の出来を考えれば、嗜好が一致しているかどうかのほうがはるかに大切です。(p.53)

次に、チームの人にこだわりをもつのではなく、誰とでも仕事ができる柔軟性をもとめる、という考え方です。

ときどき、コピーライターは誰で、アートディレクターは誰でなければ、いい仕事ができないといってはばからない人がいますが、その姿勢は本当のプロフェッショナルのものとはいえないとぼくは思う。
そうではなくて、一定以上のレベルのスキルをもったスタッフとならば、誰とでも組める。目的に向かって、誰とでも課題を解決してみせる。
そういう姿勢であらゆる仕事にのぞめるのが、真のプロフェッショナルであり、その哲学のもとで編成されるのが、本当のプロフェッショナルチームではないかとぼくは思います。(p.95)

ひとつは、自分のチームというものをもち、メンバーにこだわりをもちながら仕事をすることで成果を出すことがプロフェッショナルの仕事であり、気心の知れたメンバーで組織されるべきだ、という考え方。
もうひとつは、自分のチームやメンバーにこだわりを持つのではなく、誰とでもプロジェクトの目的を共有しよいチームを築き上げて成果を出すのがプロフェッショナルのしごとであり、特定のメンバーにこだわることは意味がない、という考え方。

ひとつ上のチームにたいする考え方には、こうした対立的な2つの考え方あるようです。

<理想のひとつ上のチームを作るために現実を受け止める>
この対立的な2つの考え方はどちらが正しいのでしょうか。
私は、前者が良いチームとしての理想、後者が良いチームとしての現実、なのではないか、と考えています。

嫌な仕事を嫌なメンバーをやるよりも、好きな仕事を組んでいて楽しいメンバーとやって成果を出すほうが良いほうに決まっています。
よく言われますが、嫌な仕事を嫌なメンバーとするには、人生は短すぎます。
楽しみながら成果を出す、こうしたチームが理想です。
しかし、現実には自分が所属できるチームを選ぶことはほとんどできません。
会社やプロジェクト、お客様といったさまざまな要素によって、自分が所属するチームは決められてしまうことが一般的です。
システム開発においては、システム規模が大きくなればなるほど、自分が所属するチームを選ぶことは難しくなります。
システムのこの部分は自分の会社、この部分はあの会社、ハードウェアの管理はその会社などと、自分の仕事とかかわりをもつチームは大きくなって行きます。
ですので、たとえ自分の会社内でよいチームをつくり、維持することが定着しても、それだけでは理想の良いチームで仕事することはできません。
そのときに必要なのは、

理想のひとつ上のチームを作り上げる行動を起こす

ということなのだと思います。
そして、チームの人にこだわりをもつべきでない、という考え方は、こうしたときに前を向くために必要な考え方なのだと思います。
プロジェクトメンバーのとして集まった自分たちの目標を共有し、自分たちの能力を遺憾なく発揮すること、そうして優れた成果をだすことで、プロジェクト内の人と人との関係も成熟してくるのではないでしょうか。
そのために自分が理想のチームにいないことを嘆かず、理想のひとつ上のチームをつくるために行動すること。
こうしたことの背中を押すために、現実のひとつ上のチーム論が存在するのではないか。
そのように私は考えています。