128 ー 5 章組織的操作の技法 5.32 オフィスの政治家 ばくたちは人を信頼してほしい ( 少なくとも好意的に解釈してほしい ) と思っ ているが、オフィスの政治家を信頼するとキャリアに制限がかかるだろう。 オフィスの政治家は一目見ただけではわからない。最初はとても友好的だか らだ。人間関係を巧みに扱うのである。上司の扱いが特にうまく、自分の昇進 のために同僚や部下を活用する。すぐに他人のせいにするし、隙あらばすべて を自分の手柄にしようとする。攻撃的な感じはしない。印象をよくするために こちらの聞きたいことを教えてくれる。しかし、君を利用したり操作したりでき ないとわかったら、脅威と見なして無視したり攻撃をしかけてきたりする。し ばらく一緒に働いていると、オフィスの政治家であることがわかる。影響力の ある人になろうとしているのではなく、影響力のある人を探そうとしているか らだ。 オフィスの政治家にはできるだけ近づかないことだ。その人の上司に告げロ をしてもいけない。誰が彼の手にかかっているかわからないからだ。技術に没 頁するのが好きなエンジニアであれば、オフィスの政治家が近づいてきたとき こうした戦略を忘れてしまうかもしれない。「ゲームで遊ぶ」気はないので、 昇進のことにエネルギーを使いたくないと思うかもしれない。しかし、オフィ スの政治家が君より先に昇進したら、オフィスの政治家に加えて悪いマネー ジャーができあがってしまう。このことについては、「 5.4 組織を操作する」を 参照してほしい。 5.33 悪い組織 一口 リスクを減らし、予測性を向上さ 会社が成長していくと、利益を管理して、 せ、大きな組織そのものを維持するために、官僚制や手続きを導入する。そし

3.4 アンチパターン一 3.4.3 アンチバターン : 人間の問題を無視する 73 前にも言ったように、チームリーダーはチームの 2 つの側面を担当している。 技術的側面と人間的側面だ。リーダーは技術職 ( 技術的な問題を解決する仕事 ) から昇進した人がほとんどなので、技術的な側面に強い人が多く、人間的な側 面を無視する傾向にある。リーダーになる前は技術的な問題解決に時間の大半 を費やしてきたので、すべてのエネルギーをチームの技術的な側面に費やした くなるのかもしれない。学生の頃はエンジニアリングの技術的な側面しか教え てもらえない。その結果、リーダーとしてチームの人間的な側面を無視してし まうのだろう。 チームの人間的な側面を無視するリーダーの例を見ていこう。数年前に Fi レ の親しい友人 ( ここでは Jake と呼ばう ) に子どもが生まれた。 Jake と Fi レは何 年も一緒に働いてきた。子どもが生まれた週は、 Jake は自宅で仕事をするこ とにした。そのほうが彼にとっても奥さんにとっても都合がよかったからだ。 Fi レにとってもリモートで Jake と仕事をすることに慣れていたので問題なかっ た。 2 人とも自分たちで生産性を高めていたのである。だが、マネージャーの pablo ( 違うオフィスにいる ) が、 Jake が自宅で働いていることを知ってしまっ た。 Jake の生産性は非常に高く、 Fi レもその状況に納得していたが、 Pab10 は 2 人がオフィスで一緒に働いていないことに腹を立てた。 Jake は pablo に対して、 オフィスにいるのと変わらない生産性で働いていると説明した。そして、自分 と奥さんのためにも数週間は家で仕事をさせてほしいと伝えた。 Pab10 の答えは こうだ。「おいおい、子どもなんていつでもいるんだぞ。いいからオフィスに来 い」。 Jake ( いつもは温厚なエンジニア ) は激高して、 Pab10 への尊敬を失った。 pablo にはもっと違ったやり方があったはすだ。 Jake が家族のために家にい たいという気持ちに理解を示すこともできた。そのことで彼の生産性やチーム が影響を受けたとしても、しばらくはそのまま続けさせてもよかった。あるい は、週に 1 ~ 2 日はオフィスに来るように調整することもできただろう。いずれ

22 ー 1 章天才プログラマの神話 いのですが、 z コードバターンを使えば読みやすくなるでしようか ? 」にす ればいい。相手に対する疑問ではなく、自分の疑問として謙虚に聞くのである。 相手が間違っているのではなく、自分が理解できないだけであることを強調す る。あくまでも可哀想な自分が理解できるようにするための提案であり、場合 によってはプロジェクトの長期的で持続可能な目標のためにもなることを伝え る。こでは何も要求していない。提案が断られてもいいようにしている。議 論しているのはコードのことであり、誰かの価値やコーディングスキルのこと ではない。 早い段階で失敗・学習・反復する ビジネスの世界には、ミスをして 1 , 000 万ドルを失ったマネージャーの有名 な ( 使い古された ) 都市伝説がある。翌日、落胆してオフィスにやって来た彼は、 自分の荷物をまとめ始めた。「 CEO がオフィスでお待ちです」という呼び出しが あり、重い足取りで CEO のオフィスに向かった。そして、静かに 1 枚の紙を CEO の机に差し出した。 雇されるからですよね」。 「退職届です」マネージャーが答えた。「ここに呼び出されたのは、解 「これは何だね ? 」 CEO が聞いた。 を解雇するのかね。 1 , 000 万ドルかけて君をトレーニングしたのだ 「解雇だって ? 」 CEO は信じられない様子で答えた。「なぜ私が君 す ウエプで検索すれば、いろんなバージョンが見つかる。

88 ー 3 章船にはキャプテンが必要 —NOTE GoogIe に入社した直後に、 Fi レは当時の CEO であるエリック・シュミッ トとミーティングをする機会があった。ミーティングの終わりにエリック から「何か必要なものはある ? 」と聞かれた。 Fi レは準備を完ぺきにして ーティングに臨んでいたが、その質問にだけは何も答えを用意していな かった。座ったまま口がきけなかったくらいだ。次のミーティングまでに 答えを用意したのは言うまでもない。 オフィスの外にあるチームの幸せにも注意を向けたほうがいい。オフィスの 外に生活がないと考えてはいけない。労働時間内では実現できないような非現 実的な期待をかけると、リーダーへの尊敬が失われてしまうし、もっと言えば 燃え尽きてしまう。プライバシーを詮索しろと言っているわけではなく、プライ べートな状況にまで目を向ければ、どうして生産性が高いのか / 低いのかがわ かるかもしれない。家庭が大変な時期に余裕を与えておくと、納期が迫ったと きに長時間労働をしてくれたりするものだ。 チームメンバーの幸せを追い求めるということは、チームメンバーのキャリア を追い求めるということもである。これから 5 年間のキャリアについて質問す ると、肩をすくめて浮かない顔をする人が多い。だが、誰もがやりたいことを 持っている。昇進。新しいことを学ぶ。すごいものをローンチする。頭のいい 人と仕事する。口に出さなくてもエンジニアはさまざまなことを考えている。有 能なリーダーになりたければ、こうしたことをどうすれば実現できるかを考える べきだ。そして、きちんと考えていることをチームに知らせるべきだ ーで重 要なのは、暗黙的な目標を明確化することである。そうすれば、現実的なキャ リアのアドバイスができるようになる。 チームメンバーの幸せを追い求めれば、今後のキャリアだけでなく、現在の 自分を改善してもらえる機会ができる。メンバーの仕事を把握できる。それは きっと楽しいはずだ。

3.4 アンチバターン一 75 リファレンスを取得するにせよ、何らかのコストがかかる。しかし、採用すべ きではない人を採用するコストに比べたらかわいいものだ。このときの「コス ト」には、チームの生産性やストレス、成長か退席かのマネジメント、解雇のた めの書類作業やストレスなどが含まれる。もちろんチームから切り離すことも コストになる。チームの採用に口を挟めないのであれば、腕のいいエンジニア が必要だと主張しよう。それでも標準的なエンジニアしか採用しないなら、職 場を変えたほうがいい。優れたチームの原料がなければ絶望的だ。 3.4.6 アンチバターン : チームを子どもとして扱う 信頼していないことをチームに伝えるには、子どものように扱えばいい。人 は自分が扱われるように行動する。つまり、子どもや囚人のように扱えば、そ のように振る舞うのである。マイクロマネジメントしたり、その人の能力をけな したり、仕事の責任を与えなかったりすればすぐに伝わる。信頼できないから こそマイクロマネジメントが必要だと考えているのだとしたら、そもそもそれは 採用を失敗しているのである。残りの人生をチームの子守に使う気はないだろ う。 ( 前述の採用の原則に従って ) 信頼できる人を採用し、信頼していることを 伝えれば、相手は普段は見せないような力を発揮してくれる。 Fitz はシカゴでカンファレンスを開催している。会場は地元の施設を借りてい る。はじめて会場を訪れたとき、管理人が会場を案内してくれた。そして、 Fi レ に鍵を渡して、翌週には戻してほしいと言った。「これをやれ」や「あれはダメ」 といったリストはなかった。イベントを監視する人もいなかった。 Fitz と彼の チームは、自分たちの施設のように扱う責任を感じた。そして、散らかさずに 清潔に会場を使った。 その結果、信頼レベルは鍵だけでなく、建物やオフィスやコンピュータ備品 にまで及んだ。もう 1 つの例としては、 Google にはオフィス用品 ( ペンやノー トといった「レガシー」な創作道具 ) の入ったキャビネットがある。必要なとき

ー 2 章素晴しいチーム文化を作る 2.5.3 「地理的障害」のあるチームで働く 分散チームの一員だったり、リモートで働いたりすることがあれば、いつもと は違ったコミュニケーション方法が必要になるだけでなく、コミュニケーション そのものが難しくなる。以上。リモート作業者のいるチームであれば、決定事 項を文書化してメールで伝えることになるだろう。チャット・ IM ・立ち話で情 報交換することもあるが、関係者に内容をプロードキャストする手段も必要だ ( メーリングリストであれば過去ログが文書になる ) 。ビデオチャットを使った会 話も便利だ。最近はウエプカムを使って、安価に実現できるようになっている。 Subversion プロジェクトのモットーは、「メーリングリストで議論がなかった ら何も起きていない」だった。いつもはチャットルームでアイデアの議論をして いたが、その場にいない人のことを考えて、最終決定は「リアル」にしていた。 チャットの内容をメーリングリストに再投稿することで、分散チームにも意思決 定の流れを把握してもらうのだ ( 必要ならロを挟んでもらった ) 。合意べースの チーム文化では特に重要だ。 リモートから話しかけるときには、机に向かって歩いていくかのように自然な 感じにしなければいけない。リモートで働くときには、さまざまな媒体 ( チャッ ト・ IM ・メール・ビデオチャット・電話など ) を使い、積極的にチームとコミュ ニケーションをとるようにして、自分の存在を知らせるだけでなく、こちらの仕 事を知ってもらうようにしよう。ただし、フェイスツーフェイスの帯域を過小 平価してはいけない。どんなにメール・チャット・電話で話していても、定期 的に飛行機に乗ってチームに会いに行くべきだ。このことはリモート社員・リ モートチーム・リモートオフィスにも当てはまる。自宅オフィスを出て、積極的 に人と話をする時間を作ろう。

IO ー 1 章天才プログラマの神話 工ンジニアとオフィス 工ンジニアの生産性を高めるには、 20 年前の常識だとドアの閉まった個 まった時間が必要だ。だが、それ以上にチームとの高帯域かつ高速な接続 誤解しないでほしいのだが、エンジニアにはコードに集中できるまと チームもある。 ないようにする合図として、トークンやぬいぐるみをモニタの上に置く な」という意思表示になるからだ。あるいは、緊急時以外は話しかけられ 対処しようとするチームもある。ヘッドフォンを装着すると「邪魔をする ノイズキャンセリングへッドフォンをエンジニアに配布して、ノイズに てくれるので、彼女の仕事が終わるまで他のことをして待つ。 ら、椅子をこちらに向けて話を聞いてくれる。忙しかったら「 ACK 」と答え ろには話しかけたい相手の名前を入れる ) 。 Mary が作業を中断できそうな 話しかけたいときは「プレイクポイント、 Mary 」と言うのだ (Mary のとこ 作っていた。合言葉を使うチームと一緒に仕事をしたこともある。誰かに てきたチームの多くは、今は忙しいので邪魔しないでほしいという合図を もちろんノイズや邪魔は遮断したほうがいい。ばくたちがこれまでに見 使っていることがわかる。個室に引きこもっている人は誰もいない。 ると、エンジニアが同じキュービクル ( 別名「プルペン」 ) やデスクエリアを 間のムダだ。 21 世紀にスタートしたハイテク急成長企業のオフィスに入 る。邪魔されない時間があったとしても、間違ったことをしていたら時 の広帯域かつ高速な接続のほうが、インターネット接続よりも価値があ のソフトウェアは個人ではなくチームで開発するので、チームメンバーと 工ンジニアに個室は必要ないし、そもそも危険なことだと思うす。現在 しか方法がなかったのだろう。 室が必要だった。邪魔されないまとまった時間を作るには、おそらくこれ が必要なのである。 す本当に内向的な人には、安心・静寂・自分の時間が必要なことはわかっている。その場 合は、個室とは言わないまでも、より静かな環境のほうがいいかもしれない。

4.2 4.3 4.4 4.5 5 章 5.1 5.2 5.3 目次 ニケーーション・・ 脅威を特定する・・ チームを強化する ~ 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 他人の時間を尊重しない・ 完ぺき主義・・・ パラノイア .. 権利を与えすぎる・・ ェゴ… 未熟なコミュニケーションと複雑なコミュ 有害な人を追い出す・・・ 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 最後に 完ぺき主義者には別の方向性を示す・・・ 生命体にエサを与えない・ 感情的にならない 不機嫌の真実を探せ・・ 優しく追い出す・・・ 諦めるときを知る・・ 長期的に考える・・ 組織的操作の技法 悪い組織・ オフィスの政治家・・・ 悪いマネージャー 現実 : 環境が成功の邪魔になっているとき・・ 理想的なマネージャー 理想 : チームがうまく機能している会社・・ 善玉、悪玉、戦略漢・・・ 5.3.3 5.3.2 5.3.1 5.2.1 ・・・・ 100 ・・・・ 103 ・・・・ 104 ・・・・ 105 ・・・・ 106 ・・・・ 106 ・・・・ 107 ・・・・ 107 ・・・・ 108 ・・・・ 108 ・・・・ 109 ・・・・ 110 ・・・・ 111 ・・・・ 112 ・・・・ 113 ・・・・ 114 ・・・・ 116 1 19 ・・・・ 121 ・・・・ 122 ・・・・ 122 ・・・・ 125 ・・・・ 125 ・・・・ 128 ・・・ 128

2.1 文化とは何カ日 チーム メンバー チーム 図 2-2 優れたスターターは新来者に菌を植えつける が弱ければ、新来者が持ち込む未知の菌 ( 文化 ) に耐えられない。未知の菌 ( 文 化 ) は予測できない結果をもたらすので、既知のスターターから始めるといいだ ろう。 チームの文化とは、チームメンバーでコードを書いたり、コミュニケーション したりする様子のことだけではない。ばくたちの知る限り、それはエンジニアリ ングチームが共有する経験・価値・目標のことである。チームの文化の基礎を 作るのは、チームや会社に最初からいるメンバーたちだ。ただし、チームが続 く限り、その文化は変化・発展し続けるのである。 チームの文化を作る要素はさまざまだ。コードレビュー・テスト駆動開発・ 事前の設計書のようにソフトウェアに関係するものもあれば、毎週木曜日のラ ンチには決まったレストランに行ったり、金曜日には行きつけのバーに飲みに 行ったりするような、人間関係にまつわるものもある。部外者にはアホみたい に思えたり、意味不明だったりするものもあるかもしれない。ピッツバーグにあ る GoogIe のエンジニアリングオフィスは、以前は貨物列車の線路の横に位置し

XIII 2 人の共著者だけでなく、編集に関わる人間など複数人のチームによる共同作 を共有するために必須のものであり、本書もその例外ではないためだ。執筆は らかにされる。 ミッションステートメントは、チームとして作り上げていくもの われるかもしれないが、その理由は「 2 章すばらしいチーム文化を作る」で明 本書の冒頭でミッションステートメントが提示される。この掲示は唐突に思 当てたところである。 重要な要素であるにも関わらす、忘れられがちな存在であった「人間」に焦点を いくような内容ばかりだろう。本書の素晴らしいところは、エンジニアリングの る。同じ会社に勤務しているからと書いたが、おそらく読者の多くの方も納得 に同じ会社で働いているだけあり、書かれていることはどれも極めて腑に落ち シカゴオフィスにいる Brian と Ben とは直接話したことはないのだが、さすが チームとして優れた製品を開発するための手法が詳しく解説されている。 薦めすることとしよう。私が話したいと思うことはすべて網羅されているし、 お断りしている。その度に心苦しさを感じていたのだが、これからは本書をお いし、お受けしていると際限なく自分の時間を取られてしまうので、ほとんど 社員の前で講演してくれないかと言われることも多い。話すことが仕事ではな よく社外の人から Go 。 gle の製品開発の手法について聞かれる。自社に来て、 日本語版まえがき