DoorKeeper
http://sukusuku-scrum.doorkeeper.jp/events/5847
以下の書籍をターゲットとした勉強会？なのです。
 | Team Geek ―Googleのギークたちはいかにしてチームを作るのか (2013/07/20) Brian W. Fitzpatrick、Ben Collins-Sussman 他 商品詳細を見る |
場所は新宿のグロースエクスパートナーズ株式会社さんです。
参加者は30人くらいでしょうか。
この書籍、もともと興味あったんですよね～
あと、継続的デリバリーやDevOpsについての社内WGに参加しているんですが、そこのリーダーも読んでました。
明日のイベントに備え「Team Geak」を読書中。 ちなみに先日、一緒にWGに参加してる事業部長クラスのリーダーが、「俺、今コレ読んでるんだけどさ～」と差し出してきたのがこの書籍だった。 幹部クラスのくせにやたら技術に強い所以は、こーゆうトコにあるのかもしれない、と思ったり。
— makopi23 (@makopi23) October 9, 2013
今年のJolt Awardsを受賞した書籍でもあり、読まずにはいられない！
ということで、当日取った個人メモからダラダラと書き起こしてみる。
■本日のタイトル「Team Geek Into Darkness」
タイトルにある「Into Darkness」は、やはりあの作品からでした。
映画『スター・トレック イントゥ・ダークネス』！
わたしもちょうど夏休み、公開初日に観てきました。面白かった！
角さんのスライド曰く、「すべてはスター・トレックにつながるのである」だそうなｗ
「日本の "ジョジョ" とかと同じで、海外では "スター・トレック" は常識」らしい！
そういやSQLアンチパターン読書会でも @t_wada さんが同じこと言ってたなぁ。
スター・トレック、恐るべし・・・
■Team Geekとアジャイル
・「スクラムガイド2013」の翻訳をやった。
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf
・Team Geekはアジャイルの本じゃないけどアジャイルっぽい
■アジャイルまでの歴史
・IBM System/360 (1974)
→ コンピュータが世に広がる
・ソフトウェアの危機 (1968)
→ ソフトウェアの供給と需要のバランスが崩れ、需要が増えた。
→ これを受けて構造化プログラミングが登場した。
・構造化プログラミング (1970s)
・同時期に Winston W. Royceによる論文 「Managing the Development of Large Software Systems」が発表。
→ イテレーションのあるウォーターフォール。
・オブジェクト指向設計 (1990s)
→ ２つのパラダイムがある。
①アラン・ケイのオブジェクト指向
②C++のオブジェクト指向
→ 今回は①が対象。
■オブジェクト指向からアジャイルへ
・「オブジェクト」を「人」に置き換えたのがアジャイル開発である。
・お互いにメッセージを遣り取りしながら仕事をしていく。
・「オブジェクト」のメッセージを「人」のメッセージに置き換えて考える。
・【結論】：「アジャイルは、オブジェクト指向を組織的に再現したもの」
■ハッカーとアジャイル
・ハッカーとは、誰に頼まれるわけでもなく、好きなものを作る人たちのこと。
・UNIXができた70s以降に登場してきた。
■ハッカーとアジャイルの関係
・「伽藍とバザール」の著者であるエリック・レイモンドの言葉：
→ 「ハァ？そんなの当たり前じゃん！でも、よくまとまっている・・・（妙訳）」
http://www.artima.com/weblogs/viewpost.jsp?thread=5342
・ハッカーから見たアジャイルの感想↑
・マーチンファウラーが上手く纏め、「リファクタリング」と命名した。
・アジャイルに繋がる流れの１つにハッカー文化がある。
・纏めると、「アジャイルはオープンソースハッカーの振る舞いを再現したもの」
■アジャイルなチームの作り方
(1) アラン・ケイの「オブジェクト指向」のような自己組織化した緩やかなつながりをしてもらいたい。
(2) ハッカーがオープンソースプロジェクトで見せるような「流儀」を踏襲してもらいたい。
→ そこで「Team Geek」を読んでもらいたい！
■ソフトウェア開発はチームスポーツである
・Subversionの開発者でもあるTeam Geekの著者からの言葉。
■三本柱（HRT）
１．謙虚（Humility）
２．尊敬（Respect）
３．信頼（Trust）
・結局これが大事なんだよね、と「ハッカー」が言っている点がポイント。説得力がある。
■HRTという３本柱のワークショップ
■(1) 運
・運、ってなかなか難しい。良いチームが作れないのは、運が悪いから？
・でも、書籍の5.4.4節には、「運は鍛えることができる」 と書いてある。
→ ワークショップでやってみよう！
■ワークショップ「幸運のスコア」
以下の問に対し、自分に点数を付ける。
・Q1. レジや銀行の列に並んでいて、知らない人に話しかけるときがある。
・Q2. 人生にあまり不安を感じない。
・Q3. 初めての料理や飲物に挑戦するなど、新しい経験が好きだ。
→ 点数が良い人ほど、「運のいい人」らしい！
ちなみに私は15点満点中、ロースコアで「運が悪い人」に分類された・・・
■運が良い人の傾向
・運のいい人は、知らな人に積極的に話しかけて、新しい経験を喜んで受け入れる。
・とはいえ、それができれば苦労しない・・・
・新しいことした方が運よくなるっていう仮説は、ほんとう？
■「運」の話をし続けるワークショップ
ということで、次に参加者でチームを作って、自己紹介せずに「運」の話をし続けるワークショップをやりました。
いろんな意見が出て面白かったです。
「レジや銀行の列では話しかけないけど、秋葉原でゲーム買うための列とかにいると、話しかけたりするよね」
「共通の目的で並んでいる人たちの列だと、話題も共有しやすいから話しかけやすいよね」
「たしかに知らない人に話かけた方が、思っても見ない新しい知識を得られたりというチャンスはあるよね」
個人的にも、たしかにQ1～Q3のスコアと運には関係性があるなぁ、と感じました。
■(2) 信頼
・「信頼」も結構、難しいよね。
・例えば「納期を守る」とか、良いことをして「信頼貯金を増やす」というのがよく言われる。
・Team Geekでは、「弱点のある人は信頼デキル！」と言っている。
→ チームなんだから、弱いところを見せた方がいいよ。
・弱点がないのは危険
→ 「もう全部あいつ一人でいいんじゃないかな」と思われる。
■根本的な帰属の誤り
・例えば鍵が見つからないと、自分の場合だと環境のせいにする。
・でもそれが他人だと、「アイツはバカだな、注意力がないな」などと、内面に帰属してしまう。
・そうじゃなく、「根本的な帰属の誤り」を前提にすることが大事。
・見せた弱点を克服する必要はない。チームで補完すればよい。
・なぜか怪我の話は盛り上がる。
→ 格好悪い話は会話のきっかけとして最適。弱点を言い合うのは、チームビルディングとしていいのでは。
■ワークショップ：「みなさんの自己紹介」
・テーブル毎に「最近失敗した嫌な思い出」を絡めた自己紹介をしました。
・実際やってみて、「格好悪い話は会話のきっかけとして最適」というのを実感した。
→ やっぱ、和むんですよね～。人間らしさが出るというか。クスッと笑いあったりとかｗ
■フード理論
・ご飯を食べている人は、良い人。
・例えばTVで、家族で食事とかしてる場面は和むよね。それだけで家族団欒というか。
・Team Geekでは「チームで昼食を食べればいい」と書いている。
・飲み会に時々行くより、定期的に昼食を食べるようにした方が上手くいく。
---
この「フード理論」っていう概念、私、初めて知りました。とても納得。
たしかに、笑顔で美味しそうにご飯食べているシーン見るだけで、暖かい気持ちになれるというか。
ご飯を美味しそうに食べている人に悪人はいない、とまで思えてくる。
それが家族で団欒しながら、となると、なおさら。
■(3) 尊敬
・「respect」を「尊敬」と訳しているが、「尊重」のほうがしっくりくるかも。
・モノとか価値観も含まれる。
・「尊敬」がなぜ重要かというと、Team Geekでは「チーム文化は自己選択的である」と言っている。
・著者がSubversionのチームをいったん離れ、数年後に戻ってきても同じ文化だった。
→ 文化が長続きしているのは、自己選択的にチームは作り上げられていくからなんだ。
→ これは、自分たちのチームが何を尊重するのかを最初に挙げておかなければできない
■ハッカーから尊敬されるためにできる５つのこと
１．オープンソースソフトウェアを書く
２．フリーソフトウェアのテストやデバッグを手伝う
３．有用な情報を公開する
４．インフラが機能し続けるように手伝う
５．ハッカー文化そのものに貢献する
■技術的スキルよりも文化の適合
・技術的スキルは学習できる。
・でも、文化が合っていない人がいると、生産性がマイナスになる。
・リコーUCSの事例：
→ 「プロジェクト大原則」を最初に作ることで、チームで尊重することをチームでわかってもらって、すごく便利だった。
■ワークショップ「尊敬できる人」
・このチームで一緒に働きたいのはどんな人か？「技術的なこと＋文化的なこと」の両面で考えてみる。
・付箋紙に列挙してみましょう。
■付箋紙の正しい貼り方
・自分の意見を１つずつ、付箋紙に書いて、声に出してから貼る。
■付箋紙の正しい剥がし方
・めくるのは素人。めくって貼ると、付箋が反り返る。
・達人は引っ張る！
・この貼り方を間違えると、付箋を頻繁に使うアジャイル開発では「アジャイルの素人」と思われるｗ
・あと、付箋を横から剥がすのは「古い」アジャイルの人ｗ
ということでチームで書き出し、バックログ形式に優先順位をつけて並べ替えをやりました。
ウチのチームでは、「一緒に働きたい人」の上位10位は以下のとおりでした。
１．楽しそうに仕事をする人
２．やさしくて明るい人
３．価値の高いものからつくる人
４．理想を語れる人
５．自分が知らないことでも積極的にやろうとする人
６．抱え込まず「みんなで」解決しようとする人
７．一緒に悩んでくれる人
８．ソフトウェアをつくる人
９．プログラミングが好きな人
１０．反対意見を言ってくれる人
ちなみに一位の「楽しそうに仕事をする人」は、私が書いた付箋でした。
みんなもそう思っているようで、ヨカッタ！
並び替えをやったあと、優先順位の上位にあるものの傾向をチームで考えたんですが、ここで気付いたのは
「技術スキルよりも人間的な要素を重要視している」という点でした。
また、これらの分析の後にチームでミッションステートメントを作成しました。
ウチのチームは、「我々のチームは、ポジティブな行動に価値を置く」と定義しました。
他のチームのミッションステートメントとしては、以下のようなものが挙がりました。
・我々のチームは、ギークになることに価値を置く
・我々のチームは、未知なことの学習に価値をく
・我々のチームは、より良く楽しく目指すところに到達することに価値を置く
・我々のチームは、オープンに価値を置く
■(4) 謙虚
・Team Geekでは、謙虚とは何か、という点にあまり触れていない。
・サーバントリーダーという考え方が大事なのではないか。
■サーバントリーダー
・キリストが弟子の足を洗っている絵がある。
→ だからといって、玄関マットになるわけじゃない。自分の意見は言ってもいい。
・自分のエゴじゃなく、チームに貢献することなら言っても構わない。
■謙虚でも自分の意見は言う！
・チームのためなら衝突も健全。衝突のないチームは不健全。
・謙虚であるけど、スクラムマスターは「悪魔の代弁者」となって衝突を作り出す。
悪魔の代弁者：http://ja.wikipedia.org/wiki/%E6%82%AA%E9%AD%94%E3%81%AE%E4%BB%A3%E5%BC%81%E8%80%85
・衝突後に後腐れがないように、これまで培ってきた信頼とかが重要となる。
■トーマス＝キルマン衝突モデル
・衝突をどう解消するかを考えるためのモデル。
・4象限のうち「協調的」が目指すべき場所だが、そこに行くまでに時間がかかる。
・どれが良い/悪いかは状況によって違う。必ずしも「協調的」がいいわけではない。
■ワークショップ「衝突を解決する対立解消図」
・LinuxのMLでは、リーナスは「感情を忠実に」表現するために、あえて厳しい意見を厳しい口調で言う。
・Team Geekの著者が所属するSubversionのMLでは、「謙虚を大切に」意見を出し合う。
・互いの共通目的は「チームを良くする」という点。
・これを解決するための対立解消図を作成してみましょう。
①対立を協調的に解決しようとすると時間がかる。
②妥協すると簡単に回答は出るが、それが良いとは限らない。
③まず、「共通目的は一緒だよね？対立してないよね？」と確認してください。
ということで、チームで対立解消図を作成しました。いわゆるTOCとかクラウド図という奴ですかね。
私、これやったの今回が初めてでして、お勉強になりました～
(5) 有害な人に対処する
最後に、「有害な人」をチームから追放せざるを得ない場合の対処についてワークショップを行いました。
ウチのチームで出た意見を上位から並べると、以下のようなカンジ。
１．その人が役に立つプロジェクトを見つける
２．上司の力を借りて、それらしい理由をつけて異動させる
３．ヘッドハンターにプロフを渡す
４．その人が何を大事にしているか聞く
５．人でなく行動を指摘する
６．逆恨みされないようにする
他のチームからは以下のような意見が出ました。
・辞めさせる人をケアする。
・ローテーションでシステム的に追い出す。
・「有害な人を追放すればいい」という空気がチームで当たり前にならないようにする。
・その人が「辞めたい」と言った瞬間を見逃さない。
ローテーションで追い出す、というのは面白いですね。これだと自然に追い出せるのかも・・・
■まとめ
(1) 運は鍛えられる
(2) 信頼は弱点を見せて獲得する
(3) 尊敬できるものを決めておく
(4) 謙虚であっても衝突セヨ
(5) 有害な人にはしかるべき対処をセヨ
■最後に
物事はシンプルに考えよう。他のことは忘れても、HRT（謙虚・尊敬・信頼）だけは覚えて欲しい。
Team Geekで大事なのは「HRT」（ハート）！あの角さんの紹介スライドのおかげでHRTが頭から離れない・・・ #suc3rum / http://t.co/4WErpqNATO
— makopi23 (@makopi23) October 10, 2013
ハート様は偉大だと再認識いたしました。
★感想：
この書籍にもともと興味があったこと、講演者が角さんということで高いクオリティが期待できることからこのイベントに参加しましたが、とても勉強になりました。
特に、以下の概念に感銘を受けた。
・運のいい人は知らな人に積極的に話しかけて、新しい経験を喜んで受け入れる
・フード理論
・格好悪い話は会話のきっかけとして最適
・衝突を解決する対立解消図
ワークショップも、とても考えさせられる内容で、とても勉強になりました。
まだ書籍、全部読んでないので、引き続き読み進めたいと強く思いました。
惜しむらくは、著作権の関係で、スライドが一般公開されてないことｗ
ハート様、残念です・・・
あと休憩時間に流れていたBGM、あれ、FF6ですよねー。私が大好きな作品です。
「子供のころ一番好きだったテレビゲームは？」と聞かれたら、迷いなくFF6と答えるであろう！
今でも実家にSFCが残ってて、去年かな、帰省したときに8周目をクリアした。
今でもFF6の曲はMP3プレイヤーに入れて聞いてます。
SFC時代のFFは神だと思っているが、FF6のインパクトは今でも忘れない。
最後に主催の角さん関さん、参加者、関係者のみなさん、ありがとうございました。
- 関連記事
-
- SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
- 「第４１回 すくすくスクラム Team Geek Into Darkness」に参加しました
- 「TDD Boot Camp 横浜 3rd」に参加しました
