年末なにか本を読もうと思って、Team Geakを読んだ。
リーダー（マネージャー）になるエンジニア向けの内容が多い。
以下、メモ。
ソフトウェア開発はチームスポーツである
コードを隠さない
コードや作業を隠してもいいことはない（≒ アイデア/意見を隠さない）。
適切なフィードバックをもらったほうが、結果としていい仕事ができる。
作業を隠したいという欲求は、批判に対する不安からうまれる。
途中の作業を隠すよりも、フィードバックをもらった方がいいし、フィードバックをもらうことに慣れよう。
ひとりで作業して、しょうもないことで止まったりすると、時間がもったいない。
作業を隠したほうが、失敗に対するリスクは大きくなる。
また作業を隠すとプロジェクトのバス係数も大きくなる。
プロジェクトの詳細を知っているのが自分だけなら、自分がバスに轢かれてしまったら、その時点でプロジェクトも死んでしまう。
もし他にひとりでも詳細を知っていれば、プロジェクトは（たぶん）生き残る。
このときバス係数は２倍。
チームで働くための三本柱
謙虚（Humility）・・・自分が正しいとは限らない。常に自分を改善していく。
尊敬（Respect）・・・一緒に働く人を思いやる。
信頼（Trust）・・・自分以外の人は有能で、正しいことをすると考える。そうすれば、仕事を任せることができる。
合わせて HRT と呼ぶ。ハートと読む。
コード批判について
「自分は、自分の書いたコードではない」
この言葉を自分だけきちんと認識していたところで意味は無い。
チーム共通の認識になっていなければ意味がない。
「このコードは間違っています。○○パターンを使うべきです」
→「この部分がわからないのですが、○○パターンなら読みやすくなるでしょうか」
相手への疑問でなく、自分の疑問として謙虚に聞く。
注意深く、相手を不快にさせないように。
過去の失敗をドキュメント化する
Googleでは「ポストモーテム（検死解剖）を書く」という。
謝罪ではなく「何を学んだか」「何を変更したか」を書く。
そして、みんなが読める場所に置く。ドキュメント化する。
早い段階で失敗・学習・反復しよう。
コミュニケーションの原則
同期コミュニケーションを減らし、非同期コミュニケーションを増やす。
この本ではメーリングリストを推している。自分はグループチャットがいいのではと思った。
ミッションステートメント
目指すこと・目指さないことを明確に決める。
エンジニアがひと目で理解できるように。
「価値のある会社を目指します」「株主への価値を生み出す」→全然具体的でなく意味わからないからダメ。
チーム内での認識の違いを明らかにして、プロダクトの方向性を導く。
技術的な方向性も含む。
コミュニケーション手段
・メーリングリスト（→ちょっと時代遅れと思っていたが、まだまだ現役らしい）
・オンラインチャット・・・プライベートチャットでなくグループチャットを使おう！
・バグ管理ツール・・・優先順位をつける。掲示板と同じ。衆目に晒す。
・コードコメント・・・何を書かない。なぜを書く。 →リーダブルコードあたりを読むといいかも？
・コードレビュー・・・第３者の目。
船にはキャプテンが必要
「マネージャー」ではなく「リーダー」と呼ぼう。
※ Googleではマネージャーは「部下がいる」という意味でしかないらしい。
・Googleでのリーダーの種類
TL（チームリード）・・・プロダクトの技術的方向に責任を持つ
TLM(テクニカルリードマネージャー)・・・TLに加え、チームにいるエンジニアのキャリアや幸せに責任を持つ。
マネージャーの評価軸
エンジニアの評価軸をコードのような制作物でみなすと、マネージャーの評価軸がゼロになってしまう。
ピーターの法則
「階層的な組織に属する人間は、必ずその人の無能レベルまで昇進する」
結果を出せなくなる役職まで昇進し続ける（結果が出る役職ならば昇進できる）。
採用
「Aランクの人はAランクの人を採用する。Bランクの人はCランクの人を採用する」
触媒になる
多くの場合、適切な答えを知るよりも、適切な人を知る方が価値がある。
注意散漫→自発的
エンジニアが注意散漫なら、方向性が必要。
何をすべきかを理解して、構造化スキルを身につけて、管理可能なタスクに分割する。
退屈→興奮
エンジニアが退屈しているならば、モチベーションが必要。
モチベーションは外発的動機と内発的動機の２種類ある。
外発的動機・・・金
内発的動機・・・
・自律性・・・プロダクトにオーナーシップを感じる
・熟達・・・新しいスキルを学んだり、すきるを向上させる。
・目的・・・顧客からの役に立ったメールなど
組織を操作する
悪い習慣をやめることはできない。良い習慣と置き換えなければいけない。
悪い悪いというだけでなく、代案を出して悪い習慣を良い習慣に置き換えていこう。
感想
ついついコードなどを隠しがちだが、積極的に作業を表に出すようにする。
これはオープンソースがどうという話でなく、チームとして仕事に取り組む上で、
コードを隠すとフィードバックをもらえなくなてしまって損だよ、ということ。
仕事では進捗報告が遅れがちになることもあるので、肝に命じようと思った。
リーダー（マネージャー）レベルの話が多く、自分はいまその立場にないのだが、
エンジニアのモチベーションの話などは自己分析に役立つと感じた。
エンジニアはエンジニアらしく、積極的に会社に良い習慣を植え付けていこう。
