「Team Geek Google のギークたちはいかにしてチームを作るのか」[2013, BrianW．Fitzpatrick/BenCollins‐Sussman]を読みました．
感想
有名なエンジニア系ビジネス書の一つです．
Goole のエンジニアが書いた書籍でエンジニアがどのようにして，チームで円滑に仕事ができるのかについて書かれています．
以前読んだエンジニアリング組織論への招待と比較すると，組織論というよりはメンタル（HRT）のことに焦点をあてています．
しかし，仕事のメンタルについて，エンジニアのみに焦点を当てた本は少ないと思うので，貴重な内容となっています．
本書の大きなテーマは HRT(Humility:謙虚，Respect:尊敬，Trust:信頼) です．
それらを６つの状況を６つの章ごとに，どう適応していくかを書いています．
HRT は，駆け出しエンジニアのときだけでなく，マネージャーやテックリードになったときにも必要な要素になっています．また，エンジニア間の関係だけでなくビジネスや友人関係でも同じように持つべき要素だと思いました．
例えば，人の意見に対して間違いを指摘するときに，正論であっても言い方を間違えれば，その人の人格を否定する（Respect を持っていない）ことになってしまいます．そのような状況になったときには，相手は二度と聞き入れてくれないでしょう． 逆に言えば，人格を否定しなければ，相手に嫌われることを怖がって間違いを指摘しない（Humility は意見を言わないのと違い，相手の意見を素直に受け入れたりすること）のは間違いだということも言えます．また，間違いを指摘された方も人格を否定されたのでなければ Humility を持って意見を聞くべきです．
他には，マネージャーも人間だから間違えたり知らないことがある（むしろ知らないことが増えていく）のにそれを部下に隠そうとすることです．これは部下に対して Trust を持っていないことに他なりません．
これは言葉にするのは簡単ですが，実践するのは難しいことだと思いました．
あと個人的は，正しいことをして解雇を待つという，正しいことをして解雇されたなら，組織とあっていないという考え方も好きでした．
このように，HRT を持たなければ，知らず知らずのうちに悪い方向へ向かってしまう状況がわかりやすく記載された本です．
普段の仕事で HRT を少しでも意識することで他人との関係性が円滑にすすみそうですし，今後のキャリアにおけるアンチパターンについて学ぶことができた本でした．
また，ページ数も少なく簡単に読めるのでおすすめです．
概要
はじめに
"エンジニアリング簡単だ．人間は難しい"．(Bill Coughran)
１章 天才プログラマの神話
一人で広く使われるプロダクトを作成した人はいない．
なのに，リーナス・トーパルズ，リチャート・ストールマン，ビル・ゲイツに憧れる．
確かに天才だけど，それだけでは不十分．
天才の神話は不安の裏返し．
ソースコードを隠したがるのは，天才じゃないなと思われたくないから．
いつも一人でやっていると，失敗のリスクが高くなる．
早い段階から，成果を共有することで，プロジェクトのバス係数を高めることができる．
ソースコードを完成させてからコンパイルを始めないように，間違いをその都度デバッグする必要があるのは，チームでも同じ．
ソフトウェア開発はチームスポーツである．
隠れ家に一人でいたら，才能が開花することもないし，世界を変えることもできない．
誰かと一緒に仕事をしなければならない．
三本柱
「HRT」の原則を守こと．
あらゆる人間関係の衝突は，謙虚・尊敬・信頼の欠如によるもの
謙虚(Humility)
世界の中心は自分ではない，常に改善を続けていく
尊敬(Respect)
一緒に働く人のことを心から思いやる．相手を一人の人間として扱い，その能力や功績を高く評価する
信頼(Trust)
自分以外の人は有能であり，正しいことをすると信じる．そうすることで仕事を任せることができる
実践 HRT
エゴをなくす．どこもかしくも自分の意見を言わないようにする．
「謙虚」は自分の意見を言わずに黙れということではない．
エゴは様々な形であらわれ，生産性を疎外し，速度を落とす．
批判の配分と対応を学ばなければならない．
批判するときは，建設的な批判のみにする．性格を否定するようなことをいってはならない．
そこに尊敬が含まれる．自分のスキルに謙虚になり，相手のことを信頼する．
君は君の書いたコードではない．
早い段階で失敗・学習・反復する
ミスによって損害がうまれても，そこで解雇するのは，同じミスをおかさない人物を解雇するのと同じ
不完全なソフトウェアをみせても良いという謙虚と，改善できるという信頼．
失敗を文書化（ポストモーテム）する．
ポストモーテムによって，何を学んだかと何を変更するかを記述する．
学習のための時間を残す．
最も知識のある人になるのは楽しいが，局所最適化する．
謙虚になって誰かに教えるのと同じぐらい自分でも学ぶようにする
忍耐を学ぶ
HRT によってプロジェクトと友情を助けることができる
影響を受けやすくする
影響を受けやすくなれば，影響を与えやすくなれる．
間違いや能力不足を認めることは，長期的に立場を向上させる．
HRT では，謙虚をみせ，説明と責任をはたし，他人の意見を信頼する．そして，その正直さと強さによって，みんなが尊敬してくれる．
重要な変化は君から始まる．
２章 素晴らしいチーム文化を作る
文化とはなにか
文化(culture)は酵母のように，スターターによっておいしいチーム（パン）が出来上がる．
スターターが弱ければ，新米ものが持ち込む未知の菌（文化）に耐えられない．
文化に合致しない人を採用すると，合致しない人をチームから追い出したり，合意する人を新たに探したりする手間がかかる．
優秀なエンジニアは他の優秀なエンジニアと働きたい．
プロダクトの意思決定プロセスにも参加したいと考えている．
「合意ベースのチーム」よってチーム全体が意思決定プロセスに参加できる．
成功するコミュニケーションパターン
コミュニケーションの原則は，同期コミュニケーションの人数を減らし，非同期コミュニケーションの人数を増やすこと
ハイレベルの同期
ミッションステートメントを書くことで，認識の違いを明らかにし，プロダクトの方向性に合意する
３章 船にはキャプテンが必要
「リーダー」になろうと思っていないのに，なぜかリーダーになってしまう．
こうした苦悩を「マネージャー炎症(manageritis)」と呼ぶ人もいる．
エンジニアは数ヶ月間かけて新しいチームに追いつく（数日間の件数ではだめ），エンジニアには考えたり創造したりするための育成・時間・空間が必要
マネージャーになりたがらないのは，指標があいまい（なにもしていないという評価になったりする）だったり，過去に無能なマネージャーしかしらなかったりするから．
マネージャーになるべき大きな理由の一つめは，自分自身をスケールできるから．一人で書けないコードを，優秀なエンジニアが集まってかくことができる．
二つ目は，マネージャーに向いているかも知れないから．
サーバントマネージャー
自分がマネージャーにうけたひどい仕打ちをやってしまうことがある．
それに対する対処方法は，「サーバントリーダーシップ」を持って，執事や召使のように，チームに奉仕すること．
サーバントリーダーとして，謙虚・尊敬・信頼の雰囲気を作り出す．
アンチパターン
- 自分の言いなりになる人を採用する
- 自分の評価を恐るから．
- パフォーマンスの低い人を無視する
- なにも解決しない．
- 人間の問題を無視する
- 技術面だけを大切にしてはいけない
- みんなの友達になる
- 友人関係とチームをリードすることを混合してはいけない
- 採用を妥協する
- 間違った人材を採用することは，その後のコストが何倍にも嵩む
- チームを子どもとして扱う
- 信頼していない証だ．HRT をもつこと
リーダーシップパターン
- エゴをなくす
- 謙虚は自信がないこととは違う．チーム全体のエゴやアイデンティティをもつ．リーダーも人間なので間違えることを理解する．HRT をもつ
- 禅マスターになる
- 自分の考えを平成に保つ．問題を持ちかけられても，問題解決するのではなく，問題解決できるように支援する
- 触媒になる
- 多くの場合，適切な答えを知るよりも，適切な人を知る方が価値がある
- 先生やメンターになる
- チームのプロセスとシステムの経験，誰かに教える能力，相手がどれだけ支援を必要としているか把握する能力をもつことがメンターの条件．必要十分な情報を与えることが期待される
- 目標を明確にする
- ミッションステートメントを持つことでチームの方向性を明確にし，リーダーは空いた時間で他のタスクを処理できる．チームの効率が劇的に向上する
- 正直になる
- 「褒め言葉のサンドイッチ」を避ける．必要以上に傷つけることを避けて，本質的なことが伝わらいことがあってはならない．
- 幸せを追い求める
- チームの幸せを計画する．1on1 のあとに「何か必要なものはある？」と質問する．チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる
- その他のヒントやトリック
- 委譲せよ．ただし手は汚せ．
- 自分自身を置き換えようとする．
- ことを荒立てるときを知る
- カオスからチームを守
- チームを空中援護する
- チームのいいところをフィードバックする
人は植物
同じ親の子供達の育て方が全く違うように，エンジニアの成長に必要なものはまったく違う．
チームメンバー全員を「スイートスポット」に入れるには，「マンネリ」にいるエンジニアのモチベーションを高める必要がある．
「モチベーション」と「方向」を与える必要がある．
何がすべきかを理解して，構造化のスキルを身に付けて，管理可能なタスクに分離する．
内発的動機と外発的動機
「モチベーション」外発的ではなく，内発的でないといけない．
自律性をもってマイクロマネジメントではなく，自分で考えて行動できるようにならなければいけない
熟達はエンジニアが新しいスキルを学び，既存のスキルを向上させるための機会を作ることである．
自律性と熟達は，理由もなく仕事をしている人のモチベーションにはつながらない．仕事の目的を与えなければならない．
４章 有害な人に対処する
「有害」の定義
チームの文化に含めないことについても議論すべき．
効率的に動きの速いチームを目指しているのならば，やりたくないことも明確にしておいたほうがいい
「有害な人」という言葉は乱暴だし，善人と悪人で簡単に区別すべきではない
排除するべきなのは振る舞い
「有害な人」は説明用で，日常生活でつかってわいけない
チームを強化する
自己選択的な文化に，素晴らしい人は引き疲れる
攻撃的なチームも成し遂げられることはあるが，効率性はあやしい
脅威を特定する
チームの注意と集中に気を付ける
脅威のパターン
- 他人の時間を村長しない
- エゴ
- 権利を与えすぎる
- 未熟なコミュニケーションと複雑なコミュニケーション
- パラノイア
- 完璧主義
有害な人を追い出す
振る舞いを追い出すように対処する
- 完璧主義者には別の方向性を示す
- 生命体にエサを与えない
- 感情的にならない
- 不機嫌の真実を探せ
- 優しく追い出す
- 諦めるときを知る
- 長期的に考える
- 長期的にはプロジェクトにメリットがあるか?
- その衝突は有益な方法で解決できるか?
無能で十分説明されることに悪意を見出すな（ロバート・J・ハンロン）
５章 組織的操作の技法
理想：チームがうまく機能している会社
- 理想的なマネージャー
- 自分の責任範囲を広げる
- リスクをとる
現実：環境が成功の邪魔になっているとき
- 悪いマネージャー
- 失敗に対する不安
- オフィスの政治家
- 影響力のある人になろうとしているのではなく，影響力のある人を探そうとしている
- 悪い組織
5.4 組織を操作する
会社にもルールがある．曲げてもいいものもあれば，ぶち壊していいものもある．
組織のなかで振舞うべきことばかりに集中していると，不満や失望を感じるだけ
- 許可を求めるより寛容を求めるほうが簡単
- 許可はダメといわれることがある．
- 「寛容を求める」道を選ぶ
- 道がないなら道を作る
- 誰かを説得するときには，あらかじめ賛同してくれる人を探しておいて，対象となる相手との会話のなかでアイデアについて触れてもらう
- 悪い習慣をなくすのは難しい，悪い習慣を他の習慣でおきかえるしかない
- 上司の管理方法を学ぶ
- マネージャーであってもそうでなくても，上司を管理する時間を作る必要がある．
- 小さな約束で，大きな成果を届ける
- エンジニアは，プロダクトのローンチにエネルギーを注ぐべき
- 運と親切の経済
- 運は鍛えることができる（「運のいい人の法則」）リチャード・ワイズマン）
- 運のいい人は「チャンスに気が付く」
- 安全なポジションまで昇進する
- 強力な友達を探す
- コネクタは，会社のことをよく知っている人
- 引退選手は，組織に関する知識を豊富に持ている
- 管理スタッフは，組織に協力な権力と影響力を持ている
- 忙しい経営者に（メールで）でお願いする方法
- ３行で問題について説明する
- １行で要望を書く
プラン B：逃げる
- 正しいことをして，解雇されるのを待つ
希望は残されている
仕事を達成するするために何かを変える．
組織を動かすための方法を理解する努力を怠れば，自分の大部分を運に任せることになる
６章 ユーザーも人間
一般認識を管理する
マーケティングという言葉に，あまりいい印象を持たないエンジニアが多い（文化が違うので）
悪いニュースは，マーケティングは無視できない．
いいニュースは，マーケティングとうまくやる方法がある
マーケティングの人間は感情操作に精通している．ユーザーを集めたいのであれば，ソフトウェアに対する感情的な配慮しなければならない．
- 第一印象に注目する
- 第一印象がよくなければ，それ以上はつかわれない
- 小さく約束して，大きく届ける
- 予告しないことで楽しみが生まれる
- 業界のアナリストと付き合う
- 業界のアナリストに対して，優遇するわけでも，服従するわけでもなく付き合わなければならない
ソフトウェアはどれだけ使いやすいだろうか
ユーザーに集中すれば，他のことはすべてついてくる
Google は広告よりも，ユーザーを優先したから成功した
- 顧客を選ぶ
- 最も大事なこと：ユーザーの技術能力を考え，なるべく多くの人が使えることを想定する
- ハードルを下げる
- vim の第一印象が悪いように，プロダクトは最初の体験が重要
- ユーザーではなく利用を計測する
- ユーザー登録数ではなく，利用を考える
- 速度重要
- レイテンシを改善しなければ，ストレスとなりユーザーは離れていく
- いろいろ手を出さない
- いろいろ手を出して，使いづらないものになってはいけない
- 怠けない
- 例えば，全ての機能を表示すれば確かに楽だが，ユーザーにとって使いづらいものになる
- 複雑さを隠す
- 複雑なものを隠して簡単なように見せる
ユーザーとの関係を管理する
ユーザーは自分の意見を聞いて欲しいだけだ．不満を言ってきても認知することに意味がある．
また，ユーザーが増えると技術力の平均がさがり，失望するユーザーが増えることを理解しなければならない
- 見下さない
- IT リテラシーが低いことは知能が低いわけではないことを理解する
- 我慢する
- 信頼と喜びを作る
- 信頼は貯金だが，なくなるときはいっきになくなる．大切にしようとしていることを伝える
ユーザーのことを忘れない
- マーケティング
- ソフトウェアがどのように見えるのか気を配る．ソフトウェアを使ってもらえるかどうかが決まる
- ユーザビリティ
- 使いにくかったらユーザーは去ってしまう
- 顧客サービス
- ユーザーとの長期的な関係構築が，ソフトウェアの進化やユーザーの定着に影響を与える
ソフトウェアは自分のためでもチームのためでも会社のためでもない．
ユーザーがプロダクトについて何を考えているか，何を言っているか，何を体験しているかに注目することが，長期的に重要なことになる
ユーザーはソフトウェアに欠かせない血液だ．自分でやったことは，すべて自分に返ってくる
