第1回は、JAWS DAYSとかぶってて参加できなかったため、今回が初参戦です。
今回は、Team Geek ―Googleのギークたちはいかにしてチームを作るのか
単純に本を読むだけなら一人で読んだほうが早いのだろうけど、色々な人と一緒に読むと、各自のバックボーンから感じ方が違うので、色々な感想が聞けたり面白いディスカッションが出来て良いですな。
そんな色々なディスカッションや、本（今回の範囲の3章と4章）を読んだ感想をつらつらと。。
最近の若い人は本を読まない
本から脱線した話し合いから出てきた話かもしれないけど、最近の（若い）人は本を読まない・索引を引かない、という話が出てきた。本に出てきた単語の意味を調べるのに、索引も引かない人がいるらしい。
たまたまそういう事例があったからって、それが全てってことはもちろんないんだろうけど、確かに現在はwebの検索で色々な事が簡単に調べられるから、そういう風になっても不思議じゃないかも？
僕自身はというと、大学院の学生時代、大学の図書館やちょっと離れた図書館にこもって、片っ端から本を調べてた記憶があります。調べたい情報が、専門性が高い情報だったりすると、やはりweb上にはないので、必然的に書籍に情報を求めるわけです。
研究室の先生には、「その専門のこともそうだけど、大学院の研究では研究の仕方を学びなさい」とすごい言われました。「本の索引が引ける」なんていう低レベルな意味ではもちろんないけれど、そういうことも含んでの事だったのかも？とちょっと思いました。
さらにちょっと脱線した話になるけど、web上から無料で得られる情報のレベルと、お金を払って購入する本から得られる情報のレベルとは、やっぱり差があると思う。
広告収入だったり、企業がお金を出して記事を書いてもらったりしているところもあるけど、お金を出して買ってもらう対象である「本」にまとめよう！という気合のもとに書かれた本の方が、やっぱり情報の質は高いんじゃないかと思う。もちろん、web上にも素晴らしい記事はたくさんありますけどね！
さらにさらに脱線するけど、こういうことを考えると、オープンソースってすごいなーと思ってしまう。
チームメンバーや同僚の評価・給与の話
チームメンバーや同僚の評価の話から、給与の話が出てきました。
参加メンバの一人から、「明らかに仕事が出来てないような人も、自分たちと同じ給料をもらってる、というのが納得行かない」という意見が出ました。それに対して、別のメンバーから「自分の仕事に対して与えられる給料に自分が納得できてればそれで良くて、他人のことはどうでもいいのではないか」という意見がありました。
実は僕も最近、ちょっと違うけど、本質的には似たようなことを考えたことがあって、ある人とその件について話し合ったところ、同じような返答をもらっていました。
その時は、「確かに他の人がどうしていようと、自分には関係ないじゃないか！」と自分に言い聞かせようと思ったのですが。。。自分の考え方や受け止め方を変える、というのももちろんアリだと思うし、それが大事なこともあると思うけど、今現在、上記のことでもやもやしている、というのも事実としてあるわけなので、それからももうちょっと考えを進めていました。
僕の現在の結論は、チームメンバーだからやっぱり気になる！ということです。
他の会社や他の国の人が、どれくらい働いてどれくらいもらっているか、だったらそれほど気にならないです。親がお金持ちで生まれながらに財産収入で生きて行ける人もいると思うけど、別にそれはそれほど気になりません。でも、同じチームだったり同じ会社だったりしたら、やっぱり気になっちゃいます。
同じチームだったら、チームメンバー全員の結果としてチームの成果が構成されるわけですが、その成果を作り出すために、同じ給料で各メンバー間で成果に差があったら、やっぱりもやもやするんじゃないかなー。同じ会社、というレベルで考えたら、各人の働きから会社の売上が構成されて、そこから各人に給料として返ってくるわけですが、その売上を構成するための各人の働きに差があるのに、給料が同じだったら、やっぱりもやもやするんじゃないかなー、というのが最近の僕の結論です。とは言え、これを解決する給与システムっていうのを考えるのは難しいんだろうなぁと思いますが。。基本給の割合を下げて、出来高で決まる割合を増やすとかかなぁ。
ただ、別件でも最近思っていることですが、何事も受け止め方は十人十色ということ。僕は上のように思っていますが、人は人、自分は自分、と割り切れる人ももちろんいるんだろうと思います。一方で、他の会社や他の国の人のことも気になっちゃう人もいると思います。なので、リーダーやマネージャーとか、組織をマネジメントする人は、一つの考え方をただ押し付けるのではなくて、メンバーそれぞれの考え方を一旦は受け止めて欲しいなぁと思います。いつか自分がそういう立場になることがあったら、気をつけなきゃなぁ。
次は本文3章から：
あるリーダーは、誰かがやらなくてはいけない面倒で報われないタスクをまとめて表にして、チームに均等に割り当てていた。
当たり前のことのような気もするけど、これって結構大事だと思う。誰々が得意だから、とか、たまたま誰々の手が空いてるから、という理由でこういう仕事を割り振ってしまったら、割り振られた人はたまらないと思う。そういう仕事ばっかりになってしまいそうだし。
特に本書では明示されていなかったけど、どういう報われないタスクがあって、誰にどう割り振ったか、というところは全てオープンにしておいたらいいと思う。どうしても今忙しいから誰かかわりに頼む！という交渉はもちろんあると思うけど、報われる仕事でいつも忙しい、という人と、報われない仕事でいつも忙しい、という偏りは作り出してはいけないと思う。かといって、リーダーがそれらを全て引き受けてしまったら、負荷もすごいことになると思うので、オープンに均等に割り振るってのはとてもいいと思う。
次は本文4章から：
誰が正しいか間違っているかではなく、結論にたどり着くかどうかが重要だ。いずれかの時点で損切りをして、前へ進まなければいけないのである。このことを肝に銘じて欲しい。
業務で、他モジュールの仕様が決まらない影響で、自分の上流設計の一部がなかなか決まらなくてどうしようかなーと思っていた時、チームリーダに「全ての条件が完璧に決まって始められる開発ってなかなかないから、どこかのタイミングで始めちゃうしか無いよ」と言われたことがあった。
これは割りとすんなり納得できていたんだけど、一方で、研修や本に書かれている「上流設計で作りこみをしてバグ/手戻りを減らそう」みたいなこととの矛盾にちょっともやもやしてました。
本文でこの話が出てきた流れとはちょっと話が違うけど、なんとなくだましだましでスタートしちゃった、と妥協したように考えるより、「損切り」と明示した方がけじめをつけて前に進んでる感じで良さそう。
自分の弱点の一つに完璧主義気味なところがあると思っていて、自分がそういう思考に陥り気味なときに思い出す言葉として、自分のすごく好きな小説に出てくる「完璧な人間などいない」というものがあります。
開発でも、ミクロな観点での「完璧」を求めるのではなく、開発中の製品や、チームや会社の長期的な視点での利益を最大限にすることを考えなきゃいけないんだろうと思う。
詳しいことはまだ全然知らないけれど、この辺て、ゲーム理論を勉強したら面白いのかな？
他にも面白いことが色々ありましたが、とりあえずこれくらいに。。
まだ5章までしか読んでませんが、Team Geek
