「小さなチーム、大きな仕事」

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

読書感想文。読め！ってよくおすすめされる本。技術書・ビジネス書大賞 2014らしい。

「会議は有害」とか「文章力のある人を雇う」みたいな助言が200個くらい書いてあって、それについて1ページ以内で説明している感じの本。
わかっているけど… ということに、（言葉を選ばずに言うと）ささやかな諦めをして、より本質的なところに目を向けようとする説得の仕方っぽい。結構好きな説得法。

こういった本は「いや、そんなことないだろ！」って突っ込みを入れたくなるようなこともそれなりにあるのだけれど、読み進めて行くにつれてだんだん読む前になんとなくわかってくるので、agreeできないことはさらっと読み飛ばしてしまって問題ないと思う。

いつも通り、特に気になったポイントをいくつか挙げていくことにします。

「失敗から学ぶこと」は過大評価されている

これは個人的にはむむむという感じだったが、読んでみると、なるほどな、とも思った。
「早めにたくさん失敗しておけ！」みたいなアドバイスをされたことがあるだろう（僕もしたことがある）。

要は失敗から学べるからといって、失敗を目指すようになるのはおかしい！ってこと。成功からの方がたくさんのことを学べるはずだし、データを見ても成功した人の方が失敗した人よりも、次にやることが成功する確率が高い、と。

だから不用意に失敗を煽って、「たくさん失敗しなきゃ…」っていう暗い気分にする必要は確かにないよね。

熱意を優先順位と混同するな

わかっていながら、これは手厳しい指摘。
経験上、何かを作り始めて、作ることに少し慣れてきたときに起こりがち。たくさんのアイデアが浮かんできて、そのすべてがサービスの価値を高めて顧客に大きな価値を提供する素晴らしいもののように思え、今取りかかっている作業はそれと比較するとずいぶん色褪せて見える。こんなことが毎日起こる。 もちろん何かを思いつく度にやっている暇もなければ、思いついたことのために今までやってきたことをぶち壊す余裕もないので、この「素晴らしいアイデア」を棚に上げておこう、という話。

こういうのは棚に上げておくと忘れてしまうので、思いついたときにいかに楽に雑にアウトプットできる環境を作っておくかが重要なポイントだと思う。僕は4年くらいGoogle Keepを使っていて、こういうのを忘れないうちに雑にアウトプットするようにしている。
（でもアウトプットが雑すぎて何のことだかわからないこともあって、そういうのは縁がなかったアイデアだと思って忘れることにしている。←）

無名であることを受け入れる

何かを始めたばかりのとき、もしくは始める前には、当然無名な人物である。無名な人物であることに悲観的にならずに、「失敗できる時間」としてあれこれ言われずにミスする時間として使おう。

真似てはいけない

これも経験があって、何かを作るときにその芯になる部分を真似する（参考にする、でも同じ）と、結局それの後追いになってしまう。
例えば何かを身につけたいとき、「〜のトレース1000本ノックだ！」みたいなことを言われる。無意味ではないと思うのだけど、これで得られるのは「スキル」であって、大事なのは「できるから、何をするのか」の部分だと思う。

顧客を（あなたよりも）成長させよう

「あなたの製品を使っている人よりも、使っていない人の方が常に多く存在する」 「何人かを満足させるために上級者向け機能を追加することは、まだ慣れていない人を怖じ気付かせてしまう」

もうこれは、経験上その通りだと言うしかない。本当にその通りで、とくに「唯一の課金ユーザー」みたいな人のいうことは聞きたくなってしまうもの。
何かを提供するということは、要望との長い戦いだと言えるだろう。客は要望のプロフェッショナルではないので、要望が求めていたものと一致しないことは少なくない。要望の裏側にあるものはいったい何なのか、ちゃんと見つけ出せるようになることが大事。できないなら、要望にはノーと言った方がいいかもしれない。
このあたりの話は、トレタさんのお話が説得力があっていいと思う。併せて読みたい↓

nmi.jp

toreta.blog.jp

さいごに

経験を言葉にしたい人や、右も左もわからないひとには是非おすすめしたい本。 僕は「小さなチーム」が好きで、それしか知らないので、これが「小さなチームだけ」へのアドバイスなのかはわからない。 けど、チームが大きくなると忘れてしまうことがたくさん書いてあるんじゃないかなという感想。

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

2017年1月のアップデート情報

いつもbearfruitsをご利用いただき、ありがとうございます。

2017年1月のアップデート情報です。

• ポートフォリオにGoogle Analytics トラッキングIDをセットできるようになりました

Settingsページからセットしていただけます。

バグ発見のお知らせやご要望などございましたら、 support@bearfruits.net までお気軽にご連絡ください。

今後ともbearfruitsをよろしくお願いいたします。

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

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

読書感想文。いくつか書いてみてわかったけど、人が読むことはあんまり意識していなくて、自分が本を読んだことをかみしめるプロセスのよう。（そのため、何が言いたいのかよくわからない文章だし、読みにくい）

買ったときは気づかなかったがオライリー本だったようで、独特な日本語の言い回しでサクサク読み進められる感じ。

基本的には「チームをうまく機能させること」が書かれている本で、何が有害か、とか、有害な人への対処の仕方とかまで書かれている。

帯や本の中でも語られているとおり、「ギークでなくても読む価値がある」本だと思う。というか、どんなチームにおいてもこの本に書かれていることは当然念頭に置いておくべきで、実際書かれていることの半分くらいは自分のチームでも実践してきたことである。
では、この本のポイントはというと、

• チームを上手に機能させるテクニックをしっかりと言葉にしていること
• エンジニア（ギーク）とうまくやること

が書かれていることである。

今回は中でも特に印象に残った部分をいくつか紹介する。

三本柱

チームで働くときのポイントである。
我々が思い浮かべるチームと言えば、古来よりマネージャが存在していて、マネージャによって細かく管理された仕事をこなすものである。
しかし実際は一人ではできないこと、難しいことを複数人でやるための組織であって、工場の工程のようなひとつの作業ユニットではない。

• 謙虚（自分が常に正しいわけではない）
• 尊敬（相手を一人の人間として扱い、能力や功績を高く評価する）
• 信頼（自分以外の人は正しいことをすると信じれば、仕事を任せられる）

自分で運転できるバスに乗りたい

優秀なエンジニアに優れた仕事をしてもらうには、エンジニアが安全にアイデアを共有できて、意思決定プロセスに口を挟めるような文化を作らなければいけない。

思い通りにさせるということではなく、メンバー全員がチームの成功に責任をもつ状態を作るという意味だ。
確かに自分が決定に関わっていない仕事の責任はとりたくないし、とらなければならない理由も納得がいかない。

建設的な批判

「信頼」とは、フィードバックや批判をしないということではない。
建設的な批判は大変貴重なものであるが、多くの場合は避難したり嘲笑するよりも難しい。また、建設的な批判を頼むことも難しい。
建設的な批判をしてくれる相手を見つけたら、手放さないようにしたい。

アンチパターン：パフォーマンスの低い人を無視する

多くのチームリーダーは、歯を食いしばって目を背け、パフォーマンスの低い人が奇跡的に成長するか、どこかへ行くことを願っているだけだ。いずれの可能性も極端に低い。

パフォーマンスが低い人を放置することは、チームにとってはボトルネックになるので無視できない。「ザ・ゴール」にも書かれていたように、他の人がどれだけ高パフォーマンスを発揮してもチームのパフォーマンスはボトルネックに支配される。それに、パフォーマンスの低い人が高いパフォーマンスを発揮できる場所へ行く機会を奪うことにもなる。

わかるのだが、とは言っても「はいさようなら」とやめさせられることも多くはないので、実際にどうすべきかは悩みどころである。 そこで、特に参考になったのは「ではどうやってパフォーマンスの低い人をコーチングするのか」である。

「三本柱」がちゃんとある前提で、期限を設定して課題を決め、小さな成功を何度も経験させるといいらしい。うまくいかなければ、うまくいかないことが ２人に わかるし、うまくいけばそのまま改善させられるかもしれないということだ。ボトルネックに働きかけるということね。なるほど。

さいごに

この本に書かれているいい話はすごくたくさんあって、まぁすごくたくさんあるので紹介しきれないからこのあたりにしておこうと思う。
「チームをうまくやる」本ではあるが、「チームでうまくやる」ためにも役立つし、本当にギークじゃなくても役に立つと思う。
エンジニアに何も言わずに「リーダブルコード」をおすすめするように、誰でも一度は読んでみてほしい一冊です。

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