「TeamGeek」を読んだ

はじめに

読んだ。たまたま訪問してカジュアルに面談したとき、とある部長さんが求める人材像のところで、HRTのくだりがでた。「TeamGeak」って読んだことありますか。と問われ、なかったので訪問後即購入。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

章ごとに内容を振り返っていく。

1章 天才プログラマの神話

まずこの章は「チームでうまくやること」の必要性について、いろいろな例をあげて説明されている。

天才は「チームとうまくやる」天才

やはりこの章で印象深い言葉はおそらく多くのひとと同じで以下だと思う。

だが、ちょっと待ってほしい。現実的に考えてみよう。君は天才じゃない。(p7)

天才とまではいかなくても、1人で十分に成果を出せる優秀なプログラマだと思ってるひともいるかもしれない。(僕はまったく思わないが)

仮に君が天才だったとしても、それだけでは不十分なんだ。天才だってミスをする。優れたアイデアやプログラミングスキルがあっても、開発したソフトウェアが必ずしも成功するとは限らない。今後のキャリアがうまくいくかどうかは、同僚たちとうまく協力できるかにかかっている。(p7)

スティーブ・ジョブズ、マイケル・ジョーダンといったスーパースターをあげ、誰もが"天才"というロールモデルを設定したがり、それになろうとする。だが実は彼らは「チームとうまくやる」天才だったのだ。

Linuxカーネルの作者リーナスの功績は偉大だが、何よりLinuxコミュニティを継続して発展させたことがもっとも偉大とされるのも同じだ。

プロジェクトのバス係数を減らせ

最近は「オープン」という価値観が広がってきているように（個人的には）感じるけれど、やっぱりみんな隠すよね。自分が書いたコード。見せたらいいのに。

素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのは、リスクの高い大きな賭けだ。早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、誰かと協力するメリットが失われる。(p9)

トラックナンバーともいうが、プロジェクト内で何人バスに轢かれたらプロジェクトが破綻するかをバス係数という。つまり、自分しか持たない情報を作らないこと、すなわち常にフルオープンにしておき、いつ自分がいなくなってもいいようにしておくことが重要である。これにはとても同意する。なかなかできることではないらしい。自分が心がけていることのひとつ。（仕事はすべてgitにある。）

これに関しては今の職場ではかなりできていると思うし、自分が率先して進めてこれたと思う。mattermostによる個人部屋、分報の導入で悩みや業務内容をクリアにしたし、トラブル調査内容、ノウハウはチケットに記載すること、ツール類はcloneして使えるよう整えてgitに格納、などなど「引き継ぎに一週間必要です」が死ぬほど嫌いな僕が努力し、率先して実践し、勧めてきたのは正しいことだったと思う。

チームがすべて

ここは引用のみで。

ソフトウェア開発はチームスポーツである(p13)

さらに

隠れ家に1人でいたら、才能が開花することもない。秘密の発明をこっそり準備していたら、世界を変えることもできないし、数百万人のユーザーを喜ばせることもできない。誰かと一緒に仕事をしなければないけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして素晴らしいチームを作るんだ。(p13)

三本柱 - HRT

本書の主張はこれに尽きるといっても過言ではないと思う。

• 謙虚(Humility)
• 尊敬(Respect)
• 信頼(Trust)

この3つ。今のチームはこれがあるチームなので本当に恵まれていると思います。

2章 素晴らしいチーム文化を作る

DevOpsのくだりが記憶に久しいですが、「文化を作る」という言葉はちょっと取り扱いが危険です。行動の結果が文化になるので、文化先行だとダメだ、なんて意見も見たことがあります。

パンの喩えがあったので引用しておきます。

スターター(創業者)がパン生地(新来者)に菌(文化)を植え付ける。イースト菌と乳酸菌(チームメンバー)が発酵(成長)すると、おいしいパン(チーム)のできあがりだ。(p32)

パン作りしたことないのでわかりづらい。。。

が、どの会社も独自の文化を持つ。その文化を最初に作るのは、最初にいたメンバー(スターター)だろう。その後も文化は変化/成長し続ける。

チームの文化の定義・維持・防御に責任を持つのはチームメンバーだ。誰かが新しくチームに参加したときは、チームリーダーから文化を教えてもらうのではなく、チームメンバーから学ぶのである。'p34)

文化という言葉は何気なく使っているけどここで意味を再確認しておこう。

www.weblio.jp

① 〔culture〕 社会を構成する人々によって習得・共有・伝達される行動様式ないし生活様式の総体。言語・習俗・道徳・宗教、種々の制度などはその具体例。文化相対主義においては、それぞれの人間集団は個別の文化をもち、個別文化はそれぞれ独自の価値をもっており、その間に高低・優劣の差はないとされる。カルチャー。

ふむ。チームの行動様式ということですね。

その後はよりよいチーム文化の例を、コミュニケーション、議論、コードの観点で紹介されている。

3章 船にはキャプテンが必要

リーダーシップについて語られているのが本章。かなり注意深く「マネージャ」という言葉を使わないようにしている。役職上マネージャーというのは現在でもあるだろうが、そこは話題の外のようだ。実際、人モノ金を管理するマネージャーも、リーダーであるべきだし、それこそ後に出るサーバントリーダーであることが望ましいだろう。

サーバントリーダーとは、従来の「管理」するマネージャー（リーダー）と異なり、チーム全体を謙虚・尊敬・信頼の雰囲気を作り出すリーダーのことだ。

これはエンジニアでは対処できない社内の障害物を排除することかもしれないし、チームの合意形成を支援することかもしれない。あるいは、夜遅くなったときにチームに夜食を買ってくることかもしれない。(p69)

サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であれば　チームが順調に進めるように穴を埋める。自らの手を汚すのがサーバントリーダーだ。サーバントリーダーが管理するのは、技術的な側面とチームの人間関係である。両方やらなくっちゃあならないってのが「サーバントリーダー」のつらいところだな（人間関係のほうが難しい！）(p70)

これもうちの上司はできていて本当にすごいなぁと思います。僕だったらメンバーに僕がいたら僕の仕事を信頼して任せられない（笑）

サーバントリーダーは最近だとマイクロソフトの牛尾さんが、ロッシェル・カップさんと共同でやられているのを見ました。

simplearchitect.hatenablog.com

アンチパターンはそりゃそうだよなーって感じなので目次だけ。

• 自分の言いなりになる人を採用する
• パフォーマンスの低い人を無視する
• 人間の問題を無視する
• みんなの友達になる
• 採用を妥協する
• チームを子どもとして扱う

面白かったのはリーダーシップパターンですね。うちのリーダー/マネージャーは本当に鋼の心というか、まさに「禅マスター」なんですよね。。。すごい。。。

たとえ何が起きても、どんなにひどいことが起きても、どれだけの惨事が起きても、彼は決してパニックにならなかった。彼はいつも片腕を胸に当てて、もう片方の腕でアゴを押さえ、問題の状況をエンジニアに質問した。(p79)

うまく（時にはジョークをまじえて）質問することで、パニックになるエンジニアを落ち着かせる質問をするという。うちのリーダー/メンバーは大規模障害でもとても落ち着いてるので本当にすごいと思います。。。

管理ではなく、"信頼"した上でどんどん委譲していくこと。大事ですよね。

リーダーシップパターンも目次を載せておきます。

• エゴをなくす
• 禅マスターになる
• 触媒になる
• 先生やメンターになる
• 目標を明確にする
• 正直になる
• 幸せを追い求める
• その他ヒントやトリック
  • 委譲せよ。ただしては汚せ。
  • 自分自身に置き換えようとする。
  • 事を新たてるときを知る。
  • カオスからチームを守る。
  • チームを空中擁護する。
  • チームのいいところをフィードバックする。

リーダーシップとして大切なことが詰まってる章です。何度も読みたい。

4章 有害な人に対処する

言葉にウッときそうだが、チームを破壊するような"振る舞い"を排除することをだと、注意深く説明されている。

大切な"良いチーム文化はどのように守られ、継続され、必要に応じて進化していくかというと

文化が長続きしているのは、高い基準を設けているからではなく、その文化が自己選択的だからだ。素晴らしい人たちは、素晴らしいコミュニティに惹きつけられるのである(p101)

有害な振る舞いからチームを守るためには、ミッションステートメントを決めて、文化を強固にしておくことが大切だ。

どんな振る舞いが有害かというと、目次を貼っておく。

• 他人の時間を尊重しない
• エゴ
• 権利を与えすぎる
• 未熟なコミュニケーションと複雑なコミュニケーション
• パラノイヤ
• 完璧主義

そのひとが意図しているしていないに関わらず、プロジェクトの生産性の影響を与えることですね。

このあと追い出し方まで丁寧に書かれています。この章はどちらかというとオープンソースコミュニティの運営に役立ちそうな章だと思いました。

有害な人を追い出す、の目次貼っておきます。

• 完ぺき主義には別の方向性を示す
• 生命体にエサを与えない
• 感情的にならない
• 不機嫌の真実を探せ
• 優しく追い出す
• 諦めるときを知る
• 長期的に考える

最後にも注意があり、多くのひとは望んでプロジェクトに不利益を出しているわけではない。

無能で十分説明されることに悪意を見出すな(p116)

よくわかっていない人をプロジェクトから追い出すことが君の仕事ではない。破壊的な振る舞いを受け入れず、HRTに対する自分の期待を明確にすることが君の仕事だ。そのためには、その違いを理解する頭と実際に行動するスキルが必要である(p116)

継続して健全なチーム文化を守るためには必要なことですね。

5章 組織的操作の技法

この章はチームや、コミュニティから少し枠を超えて、組織という少し大きい単位での悪い例(悪いマネージャ、悪い組織)をあげ、それに対する切り抜け方が乗っている。気になった節のメモだけ。

許可を求めるより寛容を求めるほうが簡単

まずは組織で許されていることを把握しよう。許可を求めると責任を押し付けることができるが、逆に「ダメ」と言われる可能性もある。上司の許可を得なくてもできる範囲を知ることが重要だ。ただし、可能なかぎり会社にとって正しい事をしよう。(p132)

これ本当その通りだと思います。現在は寛容な部なので助かっている。。。

道がないなら道を作る

会社でチャンスを作るもうひとつの戦略は、草の根レベルでアイデアを受け入れてもらうことだ多くの人にアイデアを受け入れてもらったり、プロダクトを使ってもらったりすれば、たとえ官僚組織であってもつぶすことはできない。マネジメントもそのことに気づかざるを得ないので、受け入れるか抵抗するかになるだろう（抵抗すると政治資本が必要になる！）。これは多くのエンジニアが長年使ってきた戦略だ。たとえば、毎日の仕事が楽しくなるように、オープンソースツールをこっそり取り入れるのである。(p133)

これもやってますね、別に戦略的にやってるわけじゃないんですが（笑）

上司の管理方法を学ぶ

「マネージャーをマネージせよ」とはよく言ったもので、自分のためにうまく伝えよということである。

君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要があるということだ。

ここで「攻撃的」な仕事と「防御的」な仕事がでてくる。プロダクトのローンチという政治資本の増加につながる仕事は攻撃的な仕事で、リファクタリングや保守といったものが防御的な仕事。防御的な仕事も大事だが、その割合は全体の1/3〜 1/2になるようにせよとアドバイスがある。とはいえ大きい企業だと「攻撃的」な部と「防御的」な部になってしまいがちだが。。。

運と親切の経済

運は親切によって強化することができるという話、面白いと思いました。

自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、その人から恩返しされる保証はないが（もちろん「しっぺ返し」もないが）、いずれ誰かが喜んで手伝ってくれるようになる。(省略)親切の経済で少しだけ信頼を稼ぐことができる。この信頼は掛け金のようなものだ。

6章 ユーザーも人間

最後に作ったプロダクトを使うユーザーについての章。ユーザーにとって使いやすいソフトウェアを作りましょう、ユーザーに対して良好な関係を築きましょう。ここでもHRTが出てきますね。

マーケティング ソフトウェアがどのように見られるかに気を配ろう。それによって、ソフトウェアを使ってもらえるかどうかが決まる。 ユーザビリティ ソフトウェアが簡単に試用できなかったら、遅かったら、使いにくかったら、アクセスできなかったら、ユーザーは立ち去ってしまうだろう。 顧客サービス ユーザーとの長期的な関係構築が、ソフトウェアの進化やユーザーの定着に影響を与える。(p177)

プログラマの仕事には中断がいっぱいだ。(中略) ソフトウェアを書く理由を簡単に忘れてしまう。そのソフトウェアは君のためではない。チームのためではない。会社のためではない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる。ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、すべては自分に返ってくる。

おわりに

付録でも言っているが、本書で述べられていることはソフトウェアに限った話ではなく、あらゆるコミュニティでHRTが重要であり、あらゆる問題はHRTいずれかの欠如によって起きるものだとしている。その通りだと思う。

その認識をもとに、あとの章で語られているサーバントリーダーシップ、有害なひとの排除、組織を有効に活用すること、ユーザーを大切にすることはそれぞれ適した場面で役にたつだろう。その折に読み返したい。