さっそく『Team Geek』読みました。200ページ程度と分量が多くなく、わりと気楽にさっくり読めます。しかしこれは面白い。
ソフトウェア開発のチームやプロジェクトなどの運営にかかわるもろもろのエッセイ集、みたいなノリの本。内容はコーディングや実際の開発の細部には立ち入らず、むしろエンジニア同士の（あるいはエンジニアとエンドユーザの）関係のような「人間」にフォーカスを当てている。
いわく、ソフトウェア開発というのはチームプレイである。孤高の天才がひとりで作るようなモンじゃない。ユーザ＝自分みたいなソフトウェアなら別だけれど、世間に広く使われるようなものというのは、一人で作るということはほぼないんじゃないかと思う。だから、個人個人の技量（技術力）とべつに、チームプレイをどうこなすか、という視点がないとうまくまわらないよね、というのが基本的な立脚点になる。
そこで、基本的な原理として、謙虚（Humility）、尊敬（Respect）、信頼（Trust）のみっつ（頭文字を集めてHRTと書き、ハートと読むらしい）が提案され、この原理にもとづいていろんなテーマが語られる。チームの文化について。いいリーダーとだめなリーダーの違い。だめな人をどう排除するか。などなど。
それぞれのテーマについて、ベストプラクティスがあったり、失敗事例が紹介されたりする。著者はGoogleでエンジニアをしているが、いろんな会社も渡り歩いており、また同時にSubversionの作者でもあり、Apache Foundationとも関わりがあるため、オープンソースコミュニティと社内のエンジニアリングチームの双方について、共通して言えるような部分をくくりだし、解説している。これがいちいち面白い。
読んでいるあいだの印象としては、高林さんがWEB+DB PRESSに書いていた連載のうちコーディングのテイストが薄いもの（プログラミングの光景 プログラマについてとか、バッドシグナル通信 チキンレースとか）とちょっと近いかなと思う。ただ、高林さんの文章はそれぞれが独立して読めるエッセイだったのに対して、この本はきちんとテーマ設定をして、構成を練ってあるといった違いがある。
……ところで、artonさんは本書をして「悪の教典」だと書いたけど、どうしてそう読めるのかよくわからないなあ。いや、すっとぼけないで書くと、本当はちょっとわかる。どういうことかというと……
本書の基本的な価値観は、謙虚・尊敬・信頼の HRT がけっきょく大事なんだ、ってこと。自分が一番デキるし頭もいい、とかいうことを内心そう思っていたとしてもそういう態度を取るべきではない、ということになっている。
でも、なぜそうなのか、というところに善であるとか、正義であるとか、そういう価値観や道徳を持ち出さないのだよね。著者の表現はエゴイスティックで、けっきょく自分が一番生産的であるためには、とか、チームがへんなことにならずにちゃんと進むためには、とか、そういう自己の目的達成のための道が、実は HRT なのだ、ということになっている。そのためには、ほんとうは俺が一番アタマいいと思っていても謙虚な態度を取るほうが有益であり合理的だ、ということになる。
HRT を目指すのはそれが善であったり正義であったりするからではないし、そうである必要もない。ほんとうはとても邪悪な人間でも、仕事を進めるためには HRT を実践しよう、という論調になるわけ。そういうふうにとると、まあ邪悪であるのかもしれない。
でもぼくはあんまりそうは思わない。行動心理学的には、内心がどうであるかなんてのはどーでもいいのだ。ふだんの人間がどういう人であっても、一緒に仕事をするときに謙虚であり、仲間を尊敬しているような態度であり、他人を信頼するような言動をしているのであれば、その人は HRT フルな人だ、といっていいのだし、それがきちんと維持できるのであれば、それはナイスなんじゃないかな、と思う。
そして、HRTを主軸にもってきたのは、やっぱり著者の価値判断だろうとぼくは思う。2章では、チームには文化がある、という。そしてHRTをきちんと実践して、変な文化が根付かないようにし、ナイスなチームを構成して物事を進めていこう、という論調になっている。
でもぼくらは、そういう「ナイスなチーム」だけが全てじゃないってことを知っている。Linuxカーネルのコミュニティは、よくリーナスの暴言が話題になっている。リーナスは露悪的に「ダークサイドに来い」とか言ったりするし、彼は暴言を吐くことによって変な奴の蔓延を防いでいる、といったことは真剣に考えているのではないかと思う。それでもLinuxカーネルコミュニティは（たまにトラブルがあるみたいだけど）きちんと回っているし、あれはひとつの文化かなと思う。
文化というのは相対的なものだから、チームの文化をどうするかという選択は当然、チームの構成員に委ねられるわけだし、HRTフルである必然性はない。この手法がベストだという合理的な理由もない。
でも、じゃあ、なんで、著者がその主軸にHRTを選んだのかというと、けっきょくそういうコミュニティがいちばんいいのだ、と思っているからだろう。ただ、その結果を得るにあたって、かならずしも全員に同じ価値観を共有してもらう必要はない。ちゃんとしたエンジニアは合理的なので、合理的に考えてHRTが現在のシチュエーションではベストだ、と判断するだろうし、それによってナイスな組織が達成されるだろう、と考えているのではないだろうか。
---
もうひとつの本書のたのしみは、オープンソースコミュニティ運営に関するものだ。会社とちがって誰でもメーリングリストに参加できるから、オープンソース界隈にはそういう文化衝突というかよくわからない摩擦がしょっちゅう起きている。そういう問題をきちんと取り扱った本というのはぼくはあまり読んだことがなかったし、自分もオープンソースのコードをちょびっと書いたことぐらいはあるから、たいへん面白かった。
おすすめです。
No comments:
Post a Comment