2.5 ハイレベ丿レの同期ー 41 できることが重要だ。チームでソフトウェアを作るときに必要なコミュニケー ションを網羅しよう。すでに明確なものもあるが、合意のための調査が必要な ものもある。いすれにしても、積極的にコミュニケーションをとろうとしなけれ ば、不要な仕事やすでに他の誰かが終わらせた仕事にムダな労力をかけること 2.5 に従う必要がある。 チームは高いレベルで共通の目標を持ち、進捗を伝えるベストプラクティス 2.5 ハイレベルの同期 になる。 生み出すこどで、顧客の生活を豊かにし、ビジネスを成功させるこ で便利なコミュニケーションサービスを市場に出し、株主の価値を 我々は世界で最も素晴らしい価値のある会社を目指します。刺激的 ミッションステートメントの例を見せよう。 ケティング用語と思うかもしれない。名前は伏せておくが、大手通信会社の 「ミッションステートメント」なんて聞くと、大企業が使う退屈で過剰なマー ミッションステートメント ( いや、マジで ) どが我々の目標です。 おかしい。この会社を褒めている人に出会ったことがない ! 見てみよう。 別の会社の例を 顧客のニーズにあわせてリアルタイムでソリューションを提供します。

日本語版まえがき一 どんな人間のもとにも平等に 1 日 24 時間しか割り当てられていない。それをど のように使うかを決めるのは個人である。個人の生産性と創造性を第一に考え ーティングの必要性やあり方を真剣に考え、その進め方 るチームであれば、 も必然的に工夫されたものとなるはすだ。あなたのスケジュール表にある、そ の「定例」ミーティングが本当に必要なものなのか、是非チームで話し合ってみ て欲しい。 リモートオフィスでの勤務の仕方でも解説されているが、顔を突き合わせ ての「フェーストウフェース」での対話は重要だ。たまに、メールやテキスト チャット、ビデオチャットなどのオンラインツールを使いこなしているのだか ら、海外出張なんてもう必要ないでしようと聞かれることもあるが、それが必 要なのである。 ひとつには、いくら技術が発展しても、時差ばかりは解決できないからだ。 同じタイムゾーンで作業していれば、約 8 時間近くはほかのチームメートと共 同で作業ができる。また、人の息吹というか、五感の部分まではオンラインで 感じることができない。チームとして信頼しあう関係であるためには、たまに は同じ空気を吸う時間と場所を共有することが必要である。 オンラインとオフラインの絶妙の組み合わせがチームでの開発の妙であるが、 唯一の正解というものは存在しない。人を中心に考えて、常に改良を試みる。 工ンジニアリングの手法がここでも生きてくるだろう。 「 3 章船にはキャプテンが必要」は現在すでに管理職である人すにも、昇 進して管理職になることを望んでいる人”にも、管理職なんてまっぴらごめ んと考えている一般工ンジニアの人にも是非じっくり読んでもらいたい。本書 の中では少し違う形で表現されているが、マネージャーというのはちっとも偉 す そのような方で本書を読んでいる時点で、すでにあなたのチームはかなり優れたチー になっているか、そうなる可能性が非常に高いと思われる。 そんな人がいるのか甚だ疑問だが。 ム

86 ー 3 章船にはキャプテンが必要 ドイッチ」が使われていた。 Fi レは Tim をチームに迎え入れるときに、このチー ムで一緒に働くからには変えてほしいところがあると明確に伝えた。オプラー トに包んだ褒め言葉を使わずに、それでいて失礼のないように説明したのであ る。前のチームでの Tim のパフォーマンスを見て、事実だけを注意した。驚い たことに、数週間足らすで ( それから数回の「リフレッシュ」ミーティングで ) 、 Tim のパフォーマンスは劇的に向上した。 Tim には明確なフィードバックと指 示が必要だったのだ。 フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかど うかが重要だ。相手を防御的にするような伝え方では、どうすれば改善できる かを考えることができないし、逆にこちらが間違っていると反論されてしまう。 Ben があるエンジニアのマネジメントをしていたときのことだ。 こでは Dean と呼ばう。 Dean は自己主張が強くて、チームメンバーとどんなことでも言い 争っていた。チームのミッションのように大きなものから、ウエプページのウイ ジットの配置のような小さなものまで、 Dean は確信と熱意を持って自分の意見 を主張した。途中で話題を変えることさえも拒否していた。数か月後、 Ben は Dean を呼び出して注意することにした。 「 Dean 、君は強引すぎるよ」 こんな言い方では Dean に聞き入れてもらえないだろう。彼の行動がチームに 悪影響を与えていることをどうすれば理解してもらえるだろうか。 Ben は必死 に考えて、以下のようなたとえ話を思いついた。 意思決定のタイミングは、街を通過する電車のようなものだ。君が 立ちはだかるど、電車が遅れてしまう。運転手のエンジニアもイラ イラするだろう。新しい電車は 15 分おきにやってくる。すべての電 車の前に立ちはだかっているど、君の時間がもったいない。運転手 だって君を避けて通るようになるだろう。電車の前に立ちはだかっ ても構わないが、本当に重要な電車かどうかをよく考えてほしい。

3.5 リーダーシップバターン一 人は特に自力で学ぶことが重要だ。チームの技術やコードだけでなく、チー の文化や想定される責任レベルについても学ぶ必要がある。 83 ム 多くのエンジニアはメンターに志願しない。チームリーダーが新人のメン ターを任命するのである。メンターになるための教育や準備は必要ない。以下 の 3 つがあればいい。それは、チームのプロセスとシステムの経験、誰かに教 える能力、相手がどれだけ支援を必要としているかを把握する能力だ。最後の 項目が最も重要である。メンターには、必要十分な情報を与えることが期待さ れている。メンターが話しすぎたり説明しすぎたりすると、追い返されてしまう だろう。 3.5.5 目標を明確にする 当たり前だと思うかもしれないが、これは多くのリーダーが無視しているパ ターンの 1 つである。チームの方向性を決めたら、それを理解して合意してい るかをチームに確認しなければいけない。たとえば、プロダクトが大きなトラッ クだったとしよう ( チュープの連続ではないす ) 。チームメンバーはトラックに結 ばれたロープを握って、ある方向にトラックを引っ張っている。トラック ( プロ 図 3-6 みんなで同じ方向に引っ張ってる ? す訳注 2g6 年に米国上院議員が「インターネットは大きなトラックではなく、チュー プの連続である」と言ったことに由来する (http://en.wikipedia.org/wiki/Series_of_ tubes ) 。

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

37 内発的動機と外発的動機ー 93 チームメンバー全員を「スイートスポット」に入れるには、「マンネリ」にいる 工ンジニアのモチベーションを高める必要がある。「見て ! リスだ ! 」にいる工 ンジニアには方向性を示す必要がある。「漂流」にいるエンジニアにはモチベー ションと方向性が必要だ。したがって、エンジニアを幸せで生産的にするには、 ( 水と日光ではなく ) モチベーションと方向性を与えることになる。ただし、与 えすぎはよくない。必要ないのに与えてしまうと、逆にイライラさせてしまう。 方向性を示すのは簡単だ。何をすべきかを理解して、構造化のスキルを身に つけて、管理可能なタスクに分解すればいい。これで方向性が必要なエンジニ アに道筋を与えることができる ( 他にもあると思うが、本章ではすでにさまざま なことを説明してきた ) 。ただし、モチベーションについては、もっと説明した ほうがいいだろう。 37 内発的動機と外発的動機 モチベーションには 2 種類ある。外発的動機と内発的動機だ。外発的動機は 外からのカ ( 対価など ) で生まれるものであり、内発的動機は自発的なものであ る。ダニエル・ピンクは『モチベーション 3.0 』 ( 講談社 ) すのなかで、人を幸せで 生産的にするのは外部的動機 ( たとえば札東 ) ではなく、内発的動機を高めるこ とであると言っている。そして、内発的動機には、自律性・熟達・目的の 3 っ すす の要素が必要だと言っている 工ンジニアであれば、誰かがマイクロマネジメントするのではなく、自分で 考えて行動できるときに自律性があると言える 自律性のあるエンジニアは、 こちらからプロダクトの大まかな方向性を示せば、あとはどうやってそこに行 くかを自分で決められる。これがモチベーションにつながるのは、プロダクト す TED の素晴らしい講演も聴いてみよう ( 訳注 URL はこちら。 http://www.ted.com/ talks/lang/ja/dan—pink—on motivation. html) 。 給料に不満がないという前提だ。 マイクロマネジメントが不要という前提だ

ー 3 章船にはキャプテンが必要 90 しまう。こうした罠にハマらないでほしい。今は事を荒立てる必要があるのだ。 彼らは自分たちで問題解決できない。そのことを指摘せずにいると、チームに 悪影響を与えるし、夜も眠れなくなってしまう。それは被害を遅延させている だけだ。いつやるか。今でしよ。 図 3-8 やりたくなくても、やらなきやいけないことがある カオスからチームを守る。リーダーになったときに最初に発見するのは、 チームの外側はカオスと不確実 ( と狂気 ) の世界であることだ。メンバーだった 頃には見えなかった光景がそこに広がっている。 1990 年代に Fi レが最初にマネー ジャーになったとき ( メンバーに戻る前の話だ ) 、大量の不確実性と組織的なカ オスに驚愕したことがある。平穏な会社がどうして突然こんなことになったの かと他のマネージャーに質問したところ、 Fitz が何も知らないことを笑いながら、 会社はいつもカオス状態であり、前任のマネージャーが Fi レたちを守っていた ことを教えてくれた。 チームを空中援護する。不確実性や外部の無用な要求からチームを守ること も大切だが、会社の「上空」で何が起きているかをチームに知らせることもリー ダーの重要な役割である。できるだけ多くの情報をチームに共有すべきだが、 チームに関係のない組織の話でわすらわせる必要もない。

日本語版まえがき一 ことを肝に銘じておいて欲しい。技術者は時として頑固であり、考え方もそれ ぞれ異なる。優秀な人間ほど自分を曲げなかったりするものだ。だが、良い製 品を完成させるというゴールのためには、同じ価値観を持っ必要がある。価値 観と言っても、必すしもまったく同一のものである必要はない。ただ、技術へ の愛、技術の持つ可能性への夢、そのような価値観は共通であるべきだ。チー ムをまとめるリーダーも同じだ。 工ンジニアリングにおいて「人間」は非常に重要な要素である。開発者にとっ て、チームというのはもっとも身近な集団だ。その集団を良くするのも悪くす るのも、構成員である自分自身である。本書で解説されるさまざまなパターン、 アンチパターン、事例などを参考に、あなたのチームを最高のものにし、優れ た製品を産みだして欲しい。 Google シー ー - 「ア、工 - ンシ、 ニアリングマネージャー 及川卓也 2013 年 6 月

ー 3 章船にはキャプテンが必要 としても、チームはその存在を無視することはできない。割を食うのは自分た ちだからだ。 パフォーマンスの低い人を無視するということは、パフォーマンスの高い人 を新しくチームに入れないということでもある。そして、チームにいるパフォー マンスの高い人たちが流出していく。最終的にチームはパフォーマンスの低 い人だけになる。自分の意思でどこかへ行けない人たちだからだ。それにバ フォーマンスの低い人をチームに残すことは、その人のためにもならない。そ のチームで仕事ができなくても、他の場所で役に立っことが多いからだ。 パフォーマンスの低い人には早めに対応しよう。そうすれば、成長させるか または退席させるかを判断できる。早めに対応できれば、その人には指示や支 援が必要なことがわかるかもしれない。対応に時間がかかると、チームとの関 係性が険悪になり、君にもフラストレーションがたまり、彼を助けることができ なくなってしまう。 パフォーマンスの低い人をコーチングするにはどうすればいいだろう ? そ の分野については、ほくたち 2 人は ( 残念ながら ) 苦痛なトライアンドエラーか ら学んだ経験が豊富にある。たとえば、足を痛めた人がリハビリをして、再び チームと一緒に走り出すことを想像してみてほしい。そのときには一時的なマ イクロマネジメントが必要になるはずだ。ただし、 HRT ( 特に「尊敬」 ) がある前 提だ。期限 ( たとえば 2 ~ 3 か月 ) を設定して、達成してもらいたい目標を決め よう。最初の目標は小さくして、少しすつ大きくできるといい。小さな成功を 何度も経験するためだ。そのエンジニアには毎週会って進捗を確認する。成功 か失敗かを判断できるように、マイルストーンには明確な期待を設定する。続 けられないようなら、早い段階でそのことが 2 人にわかる。うまくいかなけれ ばその時点で中止するかもしれないし、期待に応えられるように「ゲームを続け る」かもしれない。いずれにしても、パフォーマンスの低い人に直接働きかける ことで、必要かつ重要な変化の触媒となるのである。 72

5.4 組織を操作する一 5.42 道がないなら道を作る 会社でチャンスを作るもうひとつの戦略は、草の根レベルでアイデアを受け 入れてもらうことだ。多くの人にアイデアを受け入れてもらったり、プロダクト を使ってもらったりすれば、たとえ官僚組織であってもつぶすことはできない。 マネジメントもそのことに気づかざるを得ないので、受け入れるか抵抗するか になるだろう ( 抵抗すると政治資本が必要になる ! ) 。これは多くのエンジニア が長年使ってきた戦略だ。たとえば、毎日の仕事が楽しくなるように、オープ ンソースツールをこっそり取り入れるのである。 —NOTE 隹かを説得するときには、あらかじめ賛同してくれる人を探しておい て、対象となる相手との会話のなかでアイデアについて触れてもらう ( 提 案や要求を出してもらう ) と成功率が上がる。相手がその作戦に気づいた としても、複数の人から話を聞いていると、人間の心理として重要だと思 うのである。 二二ロ アイデアはクレジットを考えなければうまくいく ! どういうことかというと、 たまに自分の功績にならないアイデアは広めたくないという人がいる。そのと きは、君の功績になることが重要なのか、それともアイデアが広まることが重 要なことなのかを考える必要がある。自分のアイデアが自分以外の ( おそらく嫌 な ) 人の口から出てくるのを耳にするのは苦痛かもしれない。でも、それがアイ デアを広める唯一の方法だったりする。会社の規模に関係なく、何度もそうい う光景を目にしてきた。経営者の口から出てくる高尚なコンセプトやアイデア は、組織の誰かが発案したものだ。そういうときは、アイデアが ( 無視されす に ) 多くの顧客に届けられると思えばいい !