Kikuchy's Second Memory

つくる楽しさをもっと伝えたい。プログラムを書いていて、わからなかったこと・気付いた事を書き留めています。

会社の人間関係をエンジニアリングする『Team Geek』

会社で上司さんに勧められたので読んでみたら面白い本でした。

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

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


どんな本か

ギークが気にしない(意図的に気にしたがらない)ことがらとその対応策を、ギーク向けに解説した本です。

「ソース中にコメントを残す意味」などテクニカルに近い話題も書かれていましたが、主に解説されているのは人間関係のアドバイスでした。

コンピューターのエンジニアリングよりはるかに難しい人間関係…
それを「避けて通れない課題」とした上で、ギークのような精神構造を持った人間がどうすれば課題に対処できるのか、を論じています(そしてこれこそが、この本のコアバリューではないかと感じています)。


一般的なオライリーの技術書、といった感じで(読みやすいかどうかはともかく)読みなれた読み味ですので、エンジニアの方ならあまり時間をかけずに読み終えることができると思います。

学ぶところは多かったのですが、特に記憶に残った以下の三つについて、詳しく書かせてください。


君 != 君のコード

http://www.flickr.com/photos/45289135@N00/4257452167
photo by Camera Slayer


明日からでも役にたつことだと思いまして。

初めてのコードレビューでコメントをもらった時に、自分のコードを否定されたような気がして
「私の書いたコードのどこが悪いんじゃい!」
とすこし泣きたくなったことを今でも覚えています。

もちろん、当時の私の態度がまちがっているわけです。
結局は変にプライドが高いだけのへっぽこエンジニアだった、ということ。

Team Geekでは、自分のコードは自分自身ではないので、指摘されたところで自分が傷つく必要はどこにもない、と書かれています。
当然その通りで、指摘をもらったところは学んで、わざわざ自分の代わりにミスを見つけてくれたレビューワーさんをありがたく思いながらコードを直せば良いわけです。

また、同じく紹介されているHRTの原則を理解していれば、「コードは君自身じゃない」と言われるまでもなく、謙虚に指摘を受け入れることができるのでしょう。

サーバントリーダー

http://www.flickr.com/photos/23478852@N00/4413594329
photo by theloushe


将来的に役にたつのかも知れないと思いまして。

この本では、マネージャーという呼称の代わりに「リーダー」と呼ぶことを提案しています。
なぜなら、マネージャーという言葉に染み付いた「頭ごなしに仕事の指示をする人」というイメージを払拭するため。

(サーバント)リーダーは、チームのメンバーが最高のパフォーマンスを発揮できるように気を遣って行動を起こす人だそうです。

思い返してみると、(学生時代の)バイト先リーダーも、今のチームのリーダーも、メンバーが仕事を進められるように気を遣ってくださっていて、とても頼もしい限りでした。

「自分にはみんなみたいな仕事はできないから、みんなが仕事に集中できるように、僕が掃除でもなんでもやりますよ」
確かバイト先のリーダーはそんなことをおっしゃっていました。
ああ、上に立つ人の言葉だなぁ、と感じたのを覚えています。

コードを書いていたい私にそんな機会が訪れるかは知りませんが、マネジメント職につくことがあれば、そんなリーダーでありたいと思ったのでした。

上司の管理方法を学ぶ

http://www.flickr.com/photos/20654194@N07/9328169940
photo by brizzle born and bred


こんなことまで書くのかと妙に感心してしまったので。

この本では、上司(やチーム外の人々)に対して「自分はできるエンジニアである」とアピールする必要があると書いています。

以前、Jenkinsを使ったCI環境を整えるなどの仕事をしていたとき、当時の上司から
「君はどんな仕事をやっているのか見えない。評価して欲しいならあざとい仕事もやる必要がある」
と言われたことがあります。
当時はネームバリューの大きいアプリの開発が行われていて、そちらに新機能を追加した、など目立つ成果の方が好評だったようです。

言われた当時は猛烈な反発感を抱いたものですが(当時は「仕事に対しての評価」が欲しかったのであって、「評価のための仕事」をしたくなかったとか色々あったので)、
今にして思えば頷くことはできます。

書かれている通り、「小さく約束して大きく届ける」、つまり(当初の)期待以上のインパクトを与えるのが大切なのでしょう。
約束を守り、好印象を与え続ければ、確かにエンジニアとしても誠実に仕事ができますし、周りからの印象も(仕事の評価も!)良くなりそうです。


自分の役にたつことを得るために読んでも良いですし、今の自分・自分のチームと照らし合わせてどうかを確かめるために読んでも面白いと思います。

現在の私がいるチームについて、HRT原則に当てはまっているかを考えると、ほとんどあてはまることがわかりました。
道理で居心地がいいわけだ!

明日からもお仕事がんばるぞい。

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

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

広告を非表示にする