エンジニアが他人とうまく開発するコツが書いてある本「TeamGeek」を読んで
Googleのギークな人達がいかにしてチームを作り上げていくのかを紹介した本。
著者はSubversionなどのオープンソースにも関わっているため、そういうコミュニティでのチームの作り上げかたも記載されている。
いろいろ思う部分があったので簡単に紹介。
隠したらだめになる
1人のときにどれだけ学習できるだろうか？どれだけ速く進めるだろうか？
ウェブには大量の意見や情報が集まっているが、自分の体験の代わりにはならない。
誰かと一緒に仕事をすることで、みんなの知恵が集まっていく。
しょーもないことに1人でつまづいたら、どれだけ時間が無駄になるだろうか？
一緒に仕事をする人たちが君の仕事を見てくれて、間違いや解決方法を指摘してくれるとしたらどれだけ違うだろうか？
これがまさにソフトウェア会社にチームがある理由だ。
チームで開発する一番のメリットってまさにこれだと思う。
一緒に開発している方々の知識や経験がどれほど開発のスピードを向上させるか知らない人はいない。
早い段階で失敗・学習・反復する
失敗は選択肢の一つ。
過ちから学ぶには失敗を文章化することである。学習した結果と何を変更するかを記述する。
失敗を適切に文書化しておけば(現在と未来の)他人がそれを読んで学習し、歴史を繰り返さずに済む
リスクの取れる文化を育てるには、失敗していいこともチームに知らせればいい。
同じ失敗を繰り返さない限り、失敗によって多くのことを学べる。
失敗を学習の機会と考えることが重要だ
失敗に対して寛容な環境ほどリスクをとれて挑戦できます。
大事なのは同じ誤りを繰り返さないことなんじゃないかなぁと。
エンジニアとコミュニケーション
エンジニアはコミュニケーションをできるだけ排除してコードを書かなければいけないと考えている。
しかし、情報を伝わっていなかったりすると、君が正しいコードを書いているという保証はない。
コミュニケーションの原則は同期コミュニケーション(ミーティング)の人数を減らし、
非同期コミュニケーション(メールなど)の人数を増やすこと。
できるだけ多くの人、プロジェクトの文章からすべての情報を取得できることが重要だ。
エンジニアはミーティングに出るのは仕事ではなく、プログラムを完成させることが仕事である以上、ミーティングは極力減らしたいと思ってる。
ただ、同じ現場で働いている以上は対面のコミュニケーションが疎かにするのは良くない気がするのでその辺のバランスは難しい。
マネージャーになりたがらない理由
マネージャーになりたがらない大きな理由はコードを書く時間が少なくなるというものだ。
コードを書く仕事であれば、１日の終わりに今日はこれだけやったと言える。
このような生産性の指標を使うと、マネジメントは何もできなかったということになる。
チームの幸せと生産性を高めることがマネジメントの仕事の指標になる。
これはトレードオフの関係なので割り切るしかないと思うが、難しい問題。
あとで紹介するが、コードを全く書かなくなるわけじゃない(少なくとも自分の場合)
攻撃的な仕事と防御的な仕事
チームの生産性は技術的負債の山で押しつぶされていた。チームに優先度で最も高いのは、その負債を返済することだった。
上司に計画を承認してもらったが、なかなかうまくいかず、上司がどうして何もできないのかとイライラしながら聞いてきた。
チームの生産性は非常に高く、膨大な負債を返済していると説明しようとしたが、うまく伝える方法がなかった。
このような経験から、仕事を攻撃的と防御的に分けることにした。
攻撃的な仕事はユーザーから見えるものである。
防御的な仕事はプロダクトを長期的に健全にするためのものである。
だが、政治的な信頼性を獲得することはできない。防御的な仕事ばかりしていてはプロダクトが動いてないと思われる
ぼくたちは技術的な負債がどれだけあっても防御的な仕事に時間や労力の1/3 - 1/2をかけないというルールを作っている。
それ以上は政治的な自殺行為につながるからだ
自分自身、マネージャーっぽい仕事をしているけど、ここで書かれている攻撃的な仕事はやる機会は間違いなく減った。
しかし、チームの生産性をあげる＆技術的負債を返すために防御的な仕事のためにコードを書いている。確かにコードを書く機会は減る。でも、防御的な仕事で書いたコードがチームの人に喜ばれるならそれはそれでいいと感じてる。
チームの成長について
チームメンバーがアドバイスを求めてきたら、問題解決のチャンスだ
問題解決ならリーダーになる前に何年もやってきたので、すぐに問題解決モードに突入
それはだめだ。エンジニアが相談を持ちかけるのは、君に問題解決をして欲しいからではない。
彼が問題解決するのを手伝って欲しいからだ。そのためには彼に質問すればいい。
問題を整理したり調査したりすることで彼が自分で問題解決できるように支援するのである。
君が答えを持っている必要はない。答えを持っているかどうかに関係なく、エンジニアには君の印象が残る
昨日、ちょうどこのブログを読んだ。
このバランスってすごい難しい。納期などの時間の制約がある以上はどうしてもこれ通りに進めることはできない。
でもなるべく、チームの成長を促すために自分自身で解決することはやめたほうがいいかもしれない
(まぁまだまだペーペーなので、もっと問題解決したい)
上司の管理方法を学ぶ
マネージャーであってもそうでなくでも上司を管理する時間を作る必要がある。
君のやっていることだけでなく、君がうまくやっていることをチームの外部にいる人達に知らせる必要があるということだ。
自分を売り込むようで嫌だというエンジニアもいる。確かにそうかもしれないが効果は絶大だ。
しかし、エンジニアとしては何よりもプロダクトのローンチにエネルギーを注ぐべきだ。
はい、おっしゃるとおり。
とある人に上司に売り込めと怒られました。
正しいことをして、解雇されるのを待とう
Googleの新しい従業員からどうすれば仕事をうまくやれるのかとよく聞かれる。
私はGoogleと世界にとって「正しいこと」をしている。あとは座って解雇されるのを待つだけだ。
解雇されなければ「正しいこと」ができたことになる。解雇されたら雇用主を間違えたのだ。
いずれにしても私は正しいことをしている。これが私のキャリア戦略だ。
名言。
ユーザーのことを忘れない
プログラマの仕事には中断がいっぱいだ。コードレビュー・設計レビュー・制作トラブル対応・バグ…。
そうなるとソフトウェアを書く理由を簡単に忘れてしまう。
そのソフトウェアは君のためではない。チームのためではない。会社のためではない。
ユーザーの生活を豊かにするためである。
ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、すべて自分に返ってくる。
最終的な目的はここ。
忘れないよう、自戒を込めて書き留めておく。
まとめ
他にも有害な人に対してのアンチパターンや組織への立ち振舞などここには紹介しきれなかったところがたくさんあります。
エンジニアとチームとして共に働く人であれば読んで損はない。管理する側も管理される側も共感できることばかりが記載されてる良書でした。
気になった人は是非読んでみてください。
独り言
今、読んでこのタイミングで読めてよかったと思える。
本文で引用してないが、ソフトウェア開発でもっとも難しいのは人間だということが書かれているが、人間は本当に難しい。
