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

ソフトウェアを書くスキルがあれば、職を失うことはないだろう。しかし、他人とうまく付き合う能力を組み合わせれば、世界を変えることが出来る。本書は優れたプログラマになるための本ではない。最高のプログラマになるための本だ。Clay Johnson

ミーティングは「必要悪」だとよく言われるが、「悪」になっている段階で何かが間違っている。チームの健全性を図る意味で、ミーティングはリトマス試験紙のような役割を果たすとも言えるだろう。時間は有限だ。

マネージャーはチームのエンジニアに最高のパフォーマンスを発揮させることが使命である。チームが自律的に機能するようになれば、不要にさえなるポジションである。一方、リーダーは全てのエンジニアに要求される役割である。・・・どのようなエンジニアであっても、オーナーシップをもって、製品開発をリードすることが求められる。シニアなエンジニアであれば、製品全体の方向性を決めることも求められる。

人間は断続的なバグの大きな塊だ

プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。

リーナスはUnixライクなカーネルが出来るというコンセプトを実証して、それをメーリングリストに投稿しただけだ。・・・リーナスの本当の功績は、そういう人たちをリードして上手く調整したことだ。Linuxは共同作業の輝かしい成果である。

天才の神話は不安の裏返しなんだと思う。多くのプログラマは、開始したばかりの作業を共有したいとは思わない。誰かが間違いを見つけて、このコードを書いたやつは天才じゃないなと思うかもしれないからだ。 ・・・完成していないものを見られたら、何か言われるんじゃないかと本当に不安だ。細かいところまで見られて、馬鹿だと思われないだろうか。

素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのは、リスクの高い大きな賭けだ。早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、誰かと協力するメリットが失われる。・・・検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにしよう。

邪魔されない時間があったとしても、間違ったことをしていたら時間のムダだ。

プロジェクトのバス係数・・・君がバスに轢かれたらプロジェクトが終わる・・・友達と一緒に作業していたら、バス係数は2倍だ。

「アイデアを胸にしまい込む」問題は、残念ながらソフトウェアエンジニアリングに限ったものではない。あらゆる領域に普遍的に存在するものだ。たとえば、科学の分野では、情報を自由にオープンに交換することになっている。だが、「論文を書かない学者は消滅せよ」と言われているし、補助金を獲得する必要があるので、情報を積極的に公開しないのである。多くの思想家はアイデアを共有しない。アイデアに執拗にしがみつき、こっそりと研究を行い、途中のミスを隠し、最終的にすべてのプロセスが簡単で明確であったかのような論文を発表する。その結果、誰かの論文とかぶったり、早い段階でミスを犯したり、今となっては無用なものを作り出したりするという悲劇が起こる。

  1. Humility 謙虚 世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
  2. Respect 尊敬 一緒に働く人のことを心から思いやろう。
  3. Trust 信頼 自分以外の人は有能であり、正しいことをすると信じよう。

この3つを合わせてHRT(ハート)と呼びたい。・・・あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。

批判を耳にする側としては、それを受け入れる方法を学ばなければいけない。・・・プログラミングはスキルなので、練習すれば向上する。ジャグリングのカイゼンを指摘された時に、自分の性格や人間としての価値が攻撃されたと思うだろうか?そんなことはないはずだ。・・・君は君の書いたコードではない。

失敗は選択肢の一つ・・・過去に失敗したことがなかったら、それは革新的でないか、リスクを取っていない証拠である。失敗は次回のために学習して改善する絶好のチャンスだ。

Googleは「完璧になるまで洞窟に隠れない」の考えに従っている。何となく使えるようになったら、生煮えでもリリースして公開する。Google Labsがコレだった。成功や失敗がすぐに分かるので、プログラミングチームは学習・反復が可能になり、できるだけ早い段階で新しいバージョンをリリースできるようになる。欠点としては、Gmailのように4年以上も「ベータ」なものが有ると、馬鹿にされてしまうことだ。・・・必要なのは、不完全なソフトウェアを見せてもかまわないという謙虚と、ユーザーがその対応を賞賛し、迅速な改善を望んでいるという信頼だ。 

失敗を文書化(ポストモーテム(postmortem)を書く)・・・失敗を適切に文書化しておけば、(現在と未来の)他人がそれを呼んで学習し、歴史を繰り返さぜに済む。後に続く人たちの滑走路となるように、君の奇跡を消さないでもらいたい。

チームの中で局所最適化してしまうと、学ぶのをやめてしまうことだ。学習をやめると退屈になる。知らないうちに時代遅れになってしまう。

正直と謙虚はクリプトナイトではない。

スーパーマン (架空の人物) - Wikipedia

文化は偶然に生まれるものではなく、創業者や初期の従業員が継続的に作り出すものなのだ。

優秀なエンジニアは優秀なチームリーダーを求める。アホなリーダーは優秀なエンジニアの扱い方が下手だし、偉そうに命令してくるからだ。

チームがエゴを持つのはいいことだ。しかし、個人のエゴは大惨事につながる。

エンジニアはコミュニケーションを重視していない。午後はずっと(予測可能で論理的な)コンパイラとやり取りをしているのに、(予測不能で感情的な)人間とは3分も話をしない。・・・コミュニーケーションの原則は、同期コミュニーケーション(ミーティングなど)の人数を減らし、非同期コミュニケーション(メールなど)の人数を増やすことである。できるだけ多くの人が、プロジェクトの文書からすべての情報を取得できることが重要だ。

ミッションステートメントを書くには時間や手間がかかるが、やること・やらないことを明確にしておけば、年単位で仕事の節約になる可能性もある。(ここは超重要。集中するにはやらないことを決めるべきだ。)

ミーティングは作業時間の邪魔になる。

  1. 絶対に必要な人だけを呼ぶ。
  2. アジェンダを作ってミーティング開始前に配布する。
  3. ミーティングのゴールを達成したら時間前でも終了する。
  4. ミーティングを順調に進める。
  5. ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する。

「うるさいマイノリティ」とは、1つのスレッドに何度もレスをする人たちだ。意見が合わなければ、あらゆることに反論してくる。不満を持ったわずか数人の意見しかなくても、活発に意見交換がされているように見えてしまう。

 マネージャーは労働者を荷車のラバのように扱った。ニンジンとムチを交互に使って、モチベーションを高めていたのである。ニンジンとムチによるマネジメント手法は、仕事が工場からオフィスに移行したあとも続いた。20世紀中頃になるとラバのように扱うマネージャー(クソ野郎)が蔓延した。当時の労働者は何年も同じ仕事を続けていた(大抵は年金が目当てだ)。

現在でもその状況が続いている業界が存在する。そこには創造的な考えや問題解決が必要な業界も含まれる(エンジニアリングとかね!)。時代錯誤なニンジンとムチの手法には全く効果がない。そのことは多くの研究結果が示している。さらにはエンジニアの生産性も落ちてしまう。組立ラインの労働者は何年働いたとしても、数日間の研修を受けた労働者と交換可能だ。しかし、エンジニアは数ヶ月間かけて新しいチームに追いつく。組立ラインの労働者の機械的な生産性とは違い、エンジニアには考えたり想像したりするための育成・時間・空間が必要なのだ。


 階層的な組織に属する人間は、必ずその人の無能レベルまで昇進するという有名なピーターの法則・・・ほとんどの人は無能なマネージャーの下についた経験がある。むな王なマネージャーしかいないというエンジニアもいる。無能なマネージャーしか知らないのであれば、どうしてマネージャーになりたいと思うだろうか?

ピーターの法則 - Wikipedia

 マネジメント職をキャリアパスにしない方がいいもう一つの理由は、マネジメントに興味のない優秀なエンジニアをマネジメント職にしてしまうと、優秀なエンジニアがいなくなって、無能なマネージャーが増えるだけだからだ。あまりいい考えとはいえないし、むしろ有害である。

パフォーマンスの低い人を無視するということは、パフォーマンスの高い人を新しくチームに入れないということでもある。そして、チームにいるパフォーマンスの高い人たちが流出していく。最終的にチームはパフォーマンスの低い人だけになる。自分の意思でどこかへ行けない人たちだからだ。それにパフォーマンスの低い人をチームに残すことは、その人のためにもならない。・・・パフォーマンスの低い人には早めに対応しよう。そうすれば、成長させるかまたは退席させるかを判断できる。

 スティーブ・ジョブズ「Aランクの人はAランクの人を採用する。Bランクの人はCランクの人を採用する」・・・適切な人を見つけるには、リクルーターを雇うにせよ、広告を出すにせよ、リファレンスを取得するにせよ、何らかのコストがかかる。しかし、採用すべきではない人を採用するコストに比べたらかわいいものだ。

リーダーは、生涯を取り除くための答えをしる必要はない。取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。

チームに変化を引き起こすもう一つの方法は、安心感を与えてリスクを取れるようにすることだ。リスクは悩ましいものである。多くの人はリスクに恐怖し、会社はコストを掛けてリスクを排除しようとする。リスクを取れば成功の確率が上がるのに、保守的に小さな成功を目指そうとする。僕たちはGoogleで以下の様なことをよく言っている。不可能な目標を達成しようとすると、失敗する可能性が高くなる。だけど、簡単にできそうなことをするよりも、できそうもないことに挑戦して失敗するほうが道が開けるはずだ。リスクの取れる文化を育てるには、失敗してもいいことをチームに知らせればいい。

なんとかしてやってみよう(失敗してもいい)。同じ失敗を繰り返さない限り、失敗によって多くのことをすばやく学べる。犯人捜しや責任のなすりつけをするのではなく、失敗を学習の機会と考えることが重要だ。失敗はできるだけ早い方がいい。それだけリスクが低いからだ。


あとで失敗しても教訓は得られるが、リスクは高くなるし失われるものも多い(大部分はエンジニアリングの時間だ)。ユーザーに影響をあたえるところは好ましくないが、そこから学べることが一番多い。Google

で失敗したときには、ポストモーテムと呼ばれるものを開催している。これは、失敗につながった出来事を文書化して、同じ失敗を繰り返さないための手続きだ。批判するところでもないし、官僚的なチェックを入れるところでもない。問題の中心部に集中して、再発を防止するものである。難しいこともあるが、とても効果的だ(達成感もある!)。

個人の成功と失敗は少し違う。個人の成功は称えてもいいが、失敗の責任を追求するようならチームは分裂し、リスクを取らなくなる。チームとして失敗し、その失敗から学んでいけばいい。個人の成功はチームの前で称えよう。個人の失敗はプライベートで建設的な批判をしよう。いずれの場合もHRTをうまく使い、チームが失敗から学べるように支援しよう。(みんなの前で個人を批判してはいけない。それは惨めで残酷な行為だ。チームは既に失敗したことをわかっている。傷口に塩を塗る必要はない。)

 ネガティブの海に飲み込まれるのは健全ではない。長期的に見れば時間の無駄だし、余計な衝突が生まれてしまう。「有害な人」と胃う言葉は乱暴だし、私たち(善人)とあの人たち(悪人)の境界線を引いてしまう。この問題について考えるにはもっといい方法が有る。普通の人たちを排除するようなエリート志向のフラタニティではなく、ネガティブな振る舞いを拒否するような文化を作るほうが健全だ。排除するのはあくまでも振る舞いであり、特定の個人ではない。

 文化が長続きしているのは、高い基準を設けているからではなく、その文化が自己選択的だからだ。素晴らしい人達は、素晴らしいコミュニティに引きつけられるのである。
意図的に意地悪をする(目的があって攻撃する)人はなかなか姿を現さない。そういう人を「トロル」と呼んでいるが、大抵は見落としてしまう。好ましくない振る舞いをする人は、それが悪いことだと気づいていない。あるいは、そもそも木にしていない。無知や無関心は悪意よりもタチが悪い。

プロジェクトの文書・ミッションステートメント・FAQ・メールの議論を読めば分かるようなことを何度も質問して、チームを邪魔するのである。

訪問者が何かを要求してきたら、アラームを作動させたほうがいい。ソフトウェアに対して不満は言うが、貢献するつもりはない人たちである。

権利を与えすぎるとプロジェクトに敵意を抱かれることがある。そして、それがパラノイア(被害妄想)に発展するのを何度も目にしてきた。チームと意見が合わない場合、有害な人は「陰謀論」を唱え始める。・・・既にオープンで透明なコミュニケーション文化があれば、すべてのやり取りが後悔されているので、陰謀論なんてアホかという話になる。ここでおすすめしたいのは無視だ。有害な人には何を言ってもムダ。相手にする価値があるだろうか?その時間でコードを書いたほうがいいだろう。

完璧主義は問題なさそうに思える。・・・何が問題なんだろう?それは停滞だ。

有害な振る舞いを排除すれば、頭がいい(けど人付き合いの苦手な)人は生産性の高いメンバーになる。数年前、ある優秀なエンジニアがいた。彼の欠点は、意図せずにチームメンバーを攻撃するところだった。・・・これからは振る舞いを穏やかにすると約束してくれた。これで全てがまるく収まったのである。結末は必ずしも追放ではない。
嵐が意図的なものでないとしても、過剰に防御的になってしまうことがある。設計がダメだとか陰謀だとか言われたり、わかりきったことを質問されたりすると、すぐに頭にきてしまう。忘れないでほしいのは、君の仕事は優れたソフトウェアを書くことであって、訪問者の機嫌を取ったり、自分のやってきたことを何度も正当化したりすることではないということだ。

 

有害な人の放つ辛辣な言葉の中にも、有用な知恵が埋もれているのである。常に技術的な議論に戻すことを心がけよう。

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks)

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks)

 

 

有名なオープンソースコミュニティのリーダーからメールを頂いたことがある。バグレポートだったが、むしろチームの知性に対する悪口のような内容だった。バグを修正してほしいのではなく、チームを刺激したいだけなのだろう。チームメンバーの1人がバグに関する質問をした。すると、詳細なバグレポートが帰ってきた。今度も敵意むき出しだ。僕たちは悪口の部分を無視して、「バグの報告ありがとうございました。問題の修正方法がわかりました。まもなく修正したものをリリースします」とだけ返信した。

ハンロンの剃刀
Never attribute to malice that which is adequately explained by stupidity.
無能で十分説明されることに悪意を見出すな。

ハンロンの剃刀 - Wikipedia

失敗に対する不安。これが悪いマネージャーに共通する特性だ。この不安によって保守的になる。典型的なエンジニアの働き方とは正反対だ。マネージャーにリスクを回避するように言われたら、君はプロダクトに新しいアイデアを注入できなくなる。その結果、誰かが設計したプロダクトを(機会的に)実装することになってしまう。(こういうやり方もあるかもしれないが、一流のエンジニアは面白くないと思う。)

不安なマネージャーは、チームの外部とのやり取りに口を出してくる。つまり、指揮命令系統を超えて外部と直接話すことが出来ないのだ。チームの外部のエンジニアやマネージャーと連絡を取ることは、反乱や不服従だと考えているのである。

学校では「知識は力なり」という言葉をよく耳にした。悪いマネージャーはこのことを強く意識している。ただし、間違った解釈をしている。この力を自分で保持するだけで、君と共有するつもりはないのである。

情報を貯め込んで、コミュニケーションの通路となることによって、悪いマネージャーは君の成功を自分の手柄にできる。そして、君の失敗を責める(たまにマネージャーの失敗も含まれる)。

オフィスの政治家はひと目見ただけではわからない。最初はとても有効的だからだ。人間関係を巧みに扱うのである。上司の扱いが特に上手く、自分の昇進のために同僚や部下を活用する。すぐに他人のせいにするし、好きあらばすべてを自分の手柄にしようとする。攻撃的な感じはしない。印象を良くするために、こちらの聞きたいことを教えてくれる。しかし、君を利用すしたり操作したり出来ないと分かったら、脅威とみなして無視したり攻撃を仕掛けてきたりする。しばらく一緒に働いていると、オフィスの政治家であることが分かる。影響力のある人になろうとしているのではなく、影響力のある人を探そうとしているからだ。

君のやっていることだけでなく、君が「うまく」やっていることを上司やチームの外部にいる人達に知らせる必要があるということだ。「自分を売り込む」ようで嫌だというエンジニアもいる。だしかにそうかもしれないが、その効果は絶大だ。

攻撃的な仕事は、ユーザーに見えるものである。見た目の輝かしいものであったり、興奮してもらえるものであったり、プロダクトのセクシーさを伝えるものであったりする(UIの改善・スピード・相互運用性など)。防御的な仕事は、プロダクトを長期的に健全にするためのものである(リファクタリング・機能の書き換え・スキーマの変更・データマイグレーション・モニタリングの改善など)。防御的な仕事によって、プロダクトの保守性・安定性・信頼性は高まる。だが、政治的な信頼性を獲得することは出来ない。防御的な仕事ばかりしていては、プロダクトが動いていないと思われる。古いことわざの言葉遊びをすると「認知した者勝ち」だ。
ぼくたちは、技術負債がどれだけあっても、防御的な仕事に時間や労力の1/3-1/2をかけないというルールを作っている。それ以上は政治的自殺行為につながるからだ。

マーケティングの人のことを考えるとゾッとするのは何故だろうか?それは、エンジニアリング文化と相容れないからだ。僕達の文化は事実に満ち溢れている。コードはコンパイル「できる」と「できない」しかない。ソフトウェアは機能を「持つ」と「持たない」しかない。問題は解決「できる」と「できない」しかない。説明を「引き伸ばす」ことはしない。事実だけを話す。そして、事実を変えるために働く。マーケティングの人間は嘘ばかりついている。僕たちは嘘をつきたくない。意思決定をするときには、秩序・予測・正確な説明が必要だ。マーケティングは事実を歪めると思っているので、エンジニアの実力主義の本能に反するのである。エンジニアは優れたプロダクトが常に勝利すると信じている。「最高」というのは、客観的に高品質で効果的なことであり、テレビの広告の宣伝文句ではない。

プログラマは論理的な思考が発達しすぎているが、多くの人間は論理と感情を同じだけ使う。そして、マーケティングの人間は感情操作に精通している。

Gitがアルファギークに大人気なのは、UnixライクなOSと同じ理由だ。学習は難しいが、絶大な力が手に入る。アルファギークの好むトレードオフだ。・・・こうしたソフトウェアは、右端にいる技術系の人達の要望に応えることを誇りとしている。

多くのプログラマPerlPythonRubyのほうがPHPよりも「優れている」と言うだろう。プログラムが読みやすいので、長い目で見れば保守もしやすい。成熟したライブラリもある。ウェブに公開したときにも安全でセキュアだ。でも、PHPのほうが人気がある(少なくともウェブ開発においてはそうだ)。なぜだろう?・・・高校生は友達からコピーできるという理由で、なんとなくPHPを選んでいる。本を読まなくてもいいし、膨大なチュートリアルをやる必要もない。真面目なプログラミングパターンを覚えなくてもいい。自分で手を加えるにはそのほうが便利なのだ。・・・プロダクトは最初の体験が超重要なのだ。

成功しているソフトウェアというのは、問題を限定してそれを上手く解決したものだ。あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題を上手く解決しているのである。

ユーザーと遣り取りをする時に重要なのは、絶対に空いてを見下さないということだ。コンピュータを扱う能力が高ければ、一般的知能が優れているわけではない。頭のいい人であっても、コンピュータを単なる道具として使う人は多い。デバッグした理化学的手法で問題と調査したりすることに関心はないのである。・・・ユーザーのことを馬鹿だと思うのは、トランスミッションの修理や問題の診断ができない君のことを自動車工が馬鹿だと思うのと一緒だ。

Googleの検索サービスのことを魔法だと思っている人は多い。しかも、自分のコンピューターの一部だと思っている。・・・お婆ちゃんの友達が、Googleが会社でスキー旅行に行くという話を聞いて怒っていたこともある(まだ会社が小さかった頃の話だ)。それはひどい! 

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

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