3.1 自然は真空を嫌う一 63 母親の墓の前で宣言しても「マネージャー」にはなれない。でも、キャリアの どこかでリーダーの立場になってしまうときがある。本章では、 こうしたときに 何をすればいいかを説明しよう。 マネージャーのためのマネジメントの本はすでにたくさんある。本章はなん となくリーダーになってしまったエンジニアのためのものだ。工ンジニアはさ まざまな理由からマネージャーになりたがらない。だけど、リーダーのいない チームは機能しない。別にマネージャーになれって言いたいわけじゃない ( ばく たちはエンジニアリングマネージャーだけどね ! ) 。なぜチームにはリーダーが 必要なのか、なぜ工ンジニアはマネージャーになりたがらないのか、なぜ優秀 なリーダーは謙虚・尊敬・信頼の原則を使ってチームに貢献するのかを教えて あげたいと思う。そのあとは、リーダーシップのパターンとアンチパターン、そ れからモチベーションについて掘り下げていくことにしよう。 ソフトウェアの方向性に影響を与えるには、エンジニアリングリーダーシッ プを隅々まで理解しなければいけない。プロダクト開発に参加するだけでなく、 舵取りをしたいと考えているのであれば、その操縦方法を学ぶ必要がある。あ るいは、実際に浅瀬で試してみる必要がある。 3 自然は真空を嫌う キャプテンのいない船は浮かんでいるだけだ。誰かが舵を手に取って、エン ジンを始動しなければ、あてもなく漂流してしまう。ソフトウェアプロジェクト も同じだ。誰かが舵を取らなければ、何かが起きるのを座って待っているギー クの集団にすぎない。 プロジェクトを進めるには、誰かが運転席に座らなければいけない。公式に 任命されたかどうかは関係ない。おそらくやる気があって我慢のできないタイ プが座るのだろう。もしかすると君かもしれない。すでにチームの衝突の解消・ 意思決定・人間関係の調整をしていないだろうか。こうしたことは常に頻繁に 発生する。「リーダー」になろうと思っていないのに、なぜかリーダーになって

3.5 3.5.8 その他のヒントやトリック リーターシップバターン一 89 委譲せよ。ただし手は汚せ。メンバーからリーダーに移行するときのバラン よくなる」と自分に言い聞かせてしまう。「自然とよくなる」と自分を納得させて 30 時間しか働かないエンジニアがいたのかもしれない。こんなときは「もうすぐ もしれない。電車の前に立ちはだかるエンジニアがいたのかもしれない。週に ( 必然的かっ頻繁に ) 発生する。工ンジニアの技術レベルが期待以下だったのか 事を荒立てるときを知る。全身の細胞が何もするなと訴えかけてくる状況が 能なマネージャーが増えるだけだ。 ネジメント職にするほうがどうかと思う。優秀なエンジニアがいなくなって、無 なりたがらないこともあるが、それはそれで構わない。その人の意に反してマ にリーダーの適正があるのかがすぐにわかる。優秀なエンジニアはリーダーに ば、どのエンジニアがリーダーになりたいと思っているのか、どのエンジニア てもらう機会を作り、ときにはチームをリードしてもらう必要がある。そうすれ 用」する必要がある。自分の代わりになるエンジニアがいれば、責任を引き受け たが、チームメンバーに代わりをしてもらいたければ、「自分より優秀な人を採 できるだけ自分自身を置き換えるようにしよう。採用プロセスのところでも述べ 自分自身を置き換えようとする。これまでと同じ仕事をしたいなら別だが、 以外にチームに自分のスキルや献身 ( や謙虚 ) を伝える術はない。 いいだろう。これまでの経歴や実績があるかもしれないが、実際に仕事をする し、仕事のペースが上がるからだ。特に誰もやらないような仕事を担当すると であれば、自分で手を汚したほうがいい。チームの尊敬を集めることができる くチームをリードしたあとであれば、あるいは新しいチームと打ち解ける段階 リーダーが正気を保つ唯一の方法だ。チームが学習する機会でもある。しばら やったほうが早くても、できるだけチームに仕事を任せたほうがいい。これは 何もしなくなってしまう。リーダーになって間もない頃であれば、たとえ自分で スは難しい。最初は何でも自分でやりたいと思っているが、リーダーになると

ー 3 章船にはキャプテンが必要 サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であれば チームが順調に進めるように穴を埋める。自らの手を汚すのがサーバントリー ダーだ。サーバントリーダーが管理するのは、技術的な側面とチームの人間関 70 係である。両方やらなくっちゃあならないってのが「サーバントリーダー」のっ 3.4.1 したものた 見ていくことにしよう。過去に遭遇したリーダーとばくたち自身の経験をもとに リーダーのための「パターン」を説明する前に、参考にしたくないパターンを 3.4 アンチバターン らいところだな ( 人間関係のほうが難しい ! ) 。 す 2 章の失敗に関する部分を参照。 ときに率直に言ってくる ) 。だが、そのような人たちはいつも驚かせてくれるし、 したほうがいい。そのような人は君に挑戦してくるかもしれない ( 君が失敗した そんなことをするよりも、君よりも頭がよくて、代わりになるような人を採用 も、安心感を得るには安いもんだろう ? 暇がとれなくなるだろう。君が部屋を出るとチームの生産性は急下降する。で ながれた大のようだ。自分の言いなりになる人しかいないチームでは、君は休 えることになる。君がリードしなければチームは行動しない。まるでひもにつ リーダーや意思決定者としての立場は強くなるかもしれないが、君の仕事は増 ないか、野望を持っていないか、君の立場を脅かさないような人だ。ただし、 じているなら、君の言いなりになる人を採用すればいい。君のように頭がよく 君がマネージャーだったとして、 ( 理由が何であれ ) 自分の役割に不安を感 アンチバターン : 自分の言いなりになる人を採用する

3.2 @Deprecated マネージャーー 申し出た。 Fitz は彼を見て笑い、「 1 週間に 75 時間す働いたら、何時に退社し てもいいよ」と言った。 Jerry はしばらく Fitz の顔をほんやりと眺め、「あ、そ れはいいですね。前職よりも自由な時間が増えます ! 」と笑顔で答えた。 Fitz は Jerry を大人として扱ったのである。 Jerry は常にその期待に応えた。 Fitz は Jerry が机にいるかどうかを気にしなかった。 Jerry にベビーシッターは不要だ からだ。 「リーダー」はあらゆることに最終的な責任を持つわけではない。 にも種類がある。技術的なリーダーと人間的なリーダーだ。 GoogIe では、チー ムリーダーは 2 つの役割 ( 肩書き ) に分かれている。 TL ( チームリード ) と TLM ( テ クニカルリードマネージャー ) だすす。 TL は、プロダクトのすべて ( あるいは一部 ) の技術的な方向性に責任を持つ。 TLM は、それに加えてチームにいるエンジニ アのキャリアや幸せにも責任を持つ。したがって、ソフトウェアプロダクトの リーダーは、必要であれば人の管理を任せることができるのだ。 3.2.2 1 つだけ怖いのは・・・・・・まあ、全部だ マネージャーという言葉を耳にしたときにエンジニアが不安になる問題はさ ておき、エンジニアがマネージャーになりたがらない理由はたくさんある。ば くたちが耳にした最も大きな理由は、コードを書く時間が少なくなるというもの だ。人間的リーダーであっても、技術的リーダーであっても、コードを書く時 間は確かに減ってしまう。 コードを書くことが仕事であれば、 1 日の終わりにコードや設計文書やクロー ズしたバグを指して「今日はこれだけやった」と言える。このような生産性の指 標を使うと、「マネジメント」は「何もできなかった」ということになる。バナナ す フォグホーン・レッグホーンは「ジョークだよ、お前」と言った。 GoogIe のマネージャーという言葉には「部下がいる」以上の意味はない。

3.5 リーダーシップパターン一 81 こともあれば、穏やかに方向性を示すだけのこともある。合意形成はリーダー シップのスキルであり、特に権力を必要としないことから非公式のリーダーも よく使っている。権力があれば方向性を示すこともできるが、それほど効果は 期待できない。チームに時間がないときは、リーダーの権力や指示を自発的に 認めることもある。独裁制や寡頭政治のように見えるかもしれないが、自発的 に行われるのであれば、それも合意の形成の一種である。 すでに合意形成はできているが、妨害や障害があって前に進めないことが ある。そこに飛び込んでチームを助けるのもリーダーシップだ。障害には技術 的なものもあれば、組織的なものもある。チームには難しいかもしれないが、 リーダーであればうまく対応できるかもしれない。 リーダーはチームに貢献す ることが嬉しい ( 貢献することが可能である ) ことをチームに理解してもらおう。 Fi レのチームが、法務部と一緒に数週間かけて障害を回避しようとしたこと がある。最終的にはどうにもならなくなり、 リーダーである Fi レに相談を持ち かけてきた。 Fi レは 2 時間でその問題を解決した。適任者の連絡先を知ってい たからである。別の話では、 Ben のチームに必要なサーバー資源が割り当てら れていなかったことがある。 Ben は他のチームに相談して、その日の午後にサー バーを調達したことがある。また別の話では、 Fi レのチームが難解な Java の問 題に遭遇した。 Fi レは Java の達人ではなかったので、そのことをよく知るエン ジニアを紹介した。リーダーは、障害を取り除くための答えを知る必要はない。 取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよリも、適切 な人を知るほうが価値がある。 チームに変化を引き起こすもう 1 つの方法は、安心感を与えてリスクをとれ るようにすることだ。リスクは悩ましいものである。多くの人はリスクに恐怖 し、会社はコストをかけてリスクを排除しようとする。リスクをとれば成功の確 率が上がるのに、保守的に小さな成功を目指そうとする。ばくたちは Google で 以下のようなことをよく言っている。不可能な目標を達成しようとすると、失敗 する可能性が高くなる。だけど、簡単にできそうなことをするよりも、できそう もないことに挑戦して失敗するほうが道が開けるはずだ。リスクのとれる文化

3.5 リーターシップバターン一 87 このたとえ話はユーモアが効いている。それでいて、 Dean が「電車停止問題」 に時間をかけていることも、それがチームに悪影響を与えていることについて も議論できるようになっている。 3.57 幸せを追い求める リーダーとしてチームを長期にわたって生産的に ( そして離脱者を少なく ) す るには、時間を作ってチームの幸せを計測すればいい。かって一緒に働いたこ とのある優秀なリーダーたちは、誰もがアマチュアの心理学者だった。チーム メンバーの幸せを調べて、やるべきことを理解しているかを確認し、その仕事 に満足できるようにしていた。あるリーダーは、誰かがやらなくてはいけない 面倒で報われないタスクをまとめて表にして、チームに均等に割り当てていた。 また別のリーダーは、チームの労働時間を調べて、レクリエーションなどを開 催し、燃え尽き状態を回避していた。また別のリーダーは、チームメンバーと 1 対 1 で面接するときに、最初は技術的な話をして打ち解けてから、仕事に必要 なことについて話していた。場があたたまったら、現在の仕事に満足している のか、次に何をしたいかについて話すようにしていた。 チームの幸せを追い求めるには、 1 対 1 のミーティングのあとに「何か必要な ものはある ? 」と質問するといいだろう。詳細を知るにはもっと調査が必要だ が、チームメンバーが生産的で幸せになるために必要なものを簡単に把握でき る。 1 対 1 の面接のあとに必すこの質問をするようにしておけば、いずれ長いリ ストを持参するようになるだろう。

3.5 リーダーシップバターン一 77 「エゴをなくす」方法の一部についてはすでに説明した。チームを信頼するこ とである。新来者であっても、その能力や成果を尊重するという意味だ。 チームのマイクロマネジメントをしなくなれば、前線で働く人たちのほうが リーダーよりも仕事に詳しくなる。つまり、 リーダーの仕事はチームの合意形 成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る 人が決定すべきことだ。こうすることで、プロダクトの当事者意識を植えつけ るだけでなく、成功 ( と失敗 ! ) の説明責任と最終責任を与えることができる。 優秀なチームがいて、仕事の品質や評価に高い基準を設ければ、ニンジンとム チを使って監督するよりもはるかに多くのことを成し遂げられるのだ。 多くのエンジニアはリーダーシップの役割に慣れていないので、リーダーは 何でも正しくやって、すべてを把握して、あらゆる質問に答える責任があると 思っている。すべてを正しくやる必要はないし、あらゆる質問に答える必要も ないし、そんなことをしていたら逆にチームの信頼を失ってしまう。リーダー としての立場に安心感を持ちたくてそう思うのだろう。工ンジニアの頃を思い 返してみると、はるか遠くにある危険でも察知することができたはすだ。工ン ジニアからの質問を歓迎しよう。君の意思決定や意見に対して質問してきたら、 その人は君のことをもっとよく理解しようと思っているのである。質問を歓迎す れば、優れたリーダーになるための建設的な意見が手に入る。建設的な意見を 言ってくれる人を見つけるのは難しい。君の「下で働く」人から意見をもらうの はもっと難しい。チームとして何を達成したいかを考えよう。フィードバックと 批判をオープンに受け止めよう。縄張り意識は避けなければいけない。 最後に説明する部分は簡単だ。でも、多くのエンジニアができていない。 スをしたときに謝るということだ。ポップコーンにかかった塩のように「ごめん なさい」を会話に散りばめればいいわけではない。心から謝罪するということ だ。君は確実にミスをする。自分でそれを認めなくても、チームは君がミスを したことを知るはすだ。君が伝えなくてもいずれチームの耳には届く ( それから みんなでそのことを話すだろう ) 。謝罪にお金はかからない。失敗したときに謝 罪できるリーダーは尊敬される。予想に反するかもしれないが、それで攻撃を

76 ー 3 章船にはキャプテンが必要 に勝手に使ってもいいことになっている。 IT 部門には「 TechSt 叩 s 」と呼ばれる セルフサービスがいくつもある。そこには、コンピュータのアクセサリ ( 電源・ ケープル・マウス・ USB ドライプなど ) が大量に用意されていて、小さな電気 店のようになっている。これも適当につかんで持ち帰っていい。ただし、在庫 の管理は自分たちに任されているので、「正しいこと」をやる責任を持っている。 典型的な会社にいる人たちは、そういうものを用意すると「盗まれる」ので、損 をするだけだと言ってくる。その可能性がないわけではないが、子どものよう に扱ったときのコストはどうなるだろうか ? おそらくべンや USB ドライプの値 段よりも高くっくはずだ。 3 リーダーシップバターン リーダーシップパターンとは、成功するリーダーの振る舞いを集めたものだ。 ほくたちの経験から学んだこと、他のリーダーを観察して学んだこと、師匠か ら教わったことをまとめている。これらのパターンは実際に活用しているだけ でなく、ばくたちがリーダーシップにおいて最も重視しているパターンである。 3.5.1 工ゴをなくす 1 章で HRT の説明をしたときにも「エゴをなくす」話をしたが、サーバント リーダーにとっては特に重要なパターンである。リーダーが玄関マットになっ て、チームメンバーがその上を歩くことだとよく誤解されるが、そういうことで はない。確かに謙虚になることと犠牲になることの境界線はあいまいだ。しか し、謙虚は自信がないこととは違う。ェゴがなくても自信を持って意見を主張 することはできる。個人のエゴはチームでは対応しきれない。チームリーダー のエゴは特にそうだ。個人のエゴではなく、チーム全体のエゴやアイデンティ ティを育むべきである。

74 ー 3 章船にはキャプテンが必要 にしても、ちょっとした共感で Jake は幸せになったはずだ。 3. 生 4 アンチバターン : みんなの友達になる 工ンジニアがリーダーになるときは、今までいたチームのリーダーになること が多い。これまでに築いた関係を壊したくないので、リーダーになったあとも 友人関係を続けようとする。これが間違いの原因だ。それによって友人関係も 失うことになる。友人関係とチームをリードすることを混同してはいけない。上 下関係があると相手は人工的な友人関係を作り出してしまう可能性がある。 友人にならなくても、チーム ( や面倒なャッ ) のリードや合意形成は可能だ。 友人関係を投げ捨てなくても、強いリーダーになれる。不安を感じさせずに仲 良くなるには、チームと一緒に昼食を食べればいい。そこでは仕事ではない非 公式の会話ができる。 友人や同僚だった人をマネジメントするのは変な感じだ。相手が仕事のでき ない人だったら、誰にとってもストレスになる。できるだけこのような状況は避 けたい。 3. 生 5 アンチバターン : 採用を妥協する スティープ・ジョブズは「 A ランクの人は A ランクの人を採用する。 B ランク の人は ( ランクの人を採用する」と言った。この格言はなかなか守れない。採 用を急いでいるときはなおさらだ。チームに 5 人のエンジニアを採用するとき 適切な人を見つけるには、リクルーターを雇うにせよ、広告を出すにせよ、 り方だ。 採用基準と関係なく採用することが多い。これは最速でダメなチームを作るや は、大量の応募者をふるいにかけてから、 40 ~ 50 人に面接して、上位 5 人を

XVI 一日本語版まえがき くない。むしろ「サーバント」、すなわち執事のような存在だ , 。芸能人のマネー ジャーがタレントの活動をサポートするために黒子に徹するのと同じように マネージャーはチームのエンジニアに最高のパフォーマンスを発揮させること が使命である。チームが自律的に機能するようになれば、不要にさえなるポジ ションた、。 一方、リーダーはすべてのエンジニアに要求される役割である。ある特定 の機能や、ある一定の期間という限定した形でかもしれないが、どのような工 ンジニアであっても、オーナーシップを持って、製品開発をリードすることが 求められる。シニアなエンジニアであれば、製品全体の方向性を決めることも 求められる。マネージャーは同時にリーダーであることが期待されるが、リー ダーは必すしもマネージャーである必要はない。 会社以外の組織でチームを組む場合、マネージャーでないリーダーの存在 を強く意識することになるだろう。私も社外の開発コミュニティにいくつか属 しているが、そこで見られるのは人事権も指揮命令系統もない中での強いチー ムワークだ。金銭でのインセンテイプを持たないつながりであるため、何かを 成し遂げたいというメンバーの思いがすべてであり、それが自発的なリーダー シップを育む。たとえば、 2011 年 3 月 11 日の東日本大震災以降、 IT による震 災復興を目指して組織された「 HackForJapan 」というコミュニティにはいくつ かの活動の柱があるが、それぞれの活動ごとにリードする主担当者がおり、コ ミュニティ全体としては大きなディレクションでつながる。ボランティアとし ての限界も見えることがあるが、このような自発的な動きはある意味理想的な チームのあり方を示しているのではないかと思うことも多い。 最後に私が本書において一番重要と感じたことを挙げよう。それは、技術集 団を率いる人間は技術に対しての深い愛と造詣が必要ということである。たと えば、社内でさまざまな経験を積ませるという理由だけのために、この間まで 開発とは無関係な部署にいた管理しか興味のない人間を急に開発のトップにつ かせたりしてはいけない。もし、あなたが人事権を持つ人であるならば、この