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 日はオフィスに来るように調整することもできただろう。いずれ
す 136 こと Ben が最初にマネージャーになったとき、チームの生産性は技術的負債 「攻撃的」な仕事と「防御的」な仕事 ー 5 章組織的操作の技法 力の 1 / 3 ~ 1 / 2 をかけないというルールを作っている。それ以上は政治的 ばくたちは、技術的負債がどれだけあっても、防御的な仕事に時間や労 勝ちす」だ。 動いていないと思われる。古いことわざの言葉遊びをすると「認知した者 得することはできない。防御的な仕事ばかりしていては、プロダクトが ダクトの保守性・安定性・信頼性は高まる。だが、政治的な信頼性を獲 グレーション・モニタリングの改善など ) 。防御的な仕事によって、プロ ある ( リファクタリング・機能の書き換え・スキーマの変更・データマイ など ) 。防御的な仕事は、プロダクトを長期的に健全にするためのもので クシーさを伝えるものであったりする ()I の改善・スピード・相互運用性 しいものであったり、興奮してもらえるものであったり、プロダクトのセ にした。攻撃的な仕事は、ユーザーに見えるものである。見た目の輝か このような経験から、 Ben は仕事を「攻撃的」と「防御的」に分けること 屈なものだったのだ。 した。しかし、うまく伝える方法が見つからなかった。こうした仕事は退 の生産性は非常に高く、膨大な負債を返済していると Ben は説明しようと どうして「何もできない」のか ? とイライラしながら聞いてきた。チーム うまくいかなかった。数か月後、上司は事前に承認したにもかかわらす、 返済することだった。上司に計画を承認してもらった。しかし、なかなか の山で押しつぶされていた。チームに優先度で最も高いのは、その負債を 自殺行為につながるからだ。 訳注元ネタは「所有した者勝ち (Possession is nine tenths of the law) 」という わざ。
VIII ー推薦の言葉 ソフトウェア開発はチームスポーツである。高いパフォーマンスを出したけれ は、開発者としてのスキルを伸ばす本が数多く存在する。優れたマネージャーに なるための本もある。本書はそこに新境地を切り開いた。ソフトウェア開発者が チームメイトと一緒に働き、優れたチームメイトになるための大切な教訓を提示 している。本書のような本がずっと必要とされていた。ついに登場だ。 Peter Novig 優れたソフトウェアを届けるチームを作りたいなら、本書を読むべきだ。 Ben と Fitz は、感覚的なテーマ ( 謙虚・尊敬・信頼 ) を具体的な戦術にうまく翻訳し ている。これなら懐疑的な開発者も納得だ。 Eric Lunt 素晴らしい本だ。コンピュータブログラミングにおいて、最も難しい問題を 扱っている。他のコンピュータブログラマとどう付き合うかという問題だ : ー ) 。 Samba チームのみんなに配りたい。 Jeremy AIIison トッププログラマは平均的なプログラマの IO 倍の生産性があるという話を聞い たことがあるだろう。大きな影響を与えるには、経験と技術力が必要になる。だ が、同僚やユーザーへの共感も必要だ。それは頭のよさや知識ではカバーできな い。本書を読めば、ソフトスキルを磨ける。そして、世界に貢献できる。 Bob Lee Fitz と Ben は、謙虚・尊敬・信頼という信条を作り、豊富な例と話を交えて説 明している。彼らが共有してくれた経験と知恵によって、チームで仕事をするソ フトウェア工ンジ二ア ( みんなそうだろう ) は、効果的で生産的に仕事ができる。 Greg 」 . Badros
ー 1 章天才プログラマの神話 1 次のステップ 以上のことをやり遂げれば、「他人とうまくやる」までもうすぐだ。自分自身 の行動をふりかえって考えてみよう。これらの戦略を日々の生活に取り入れる ことで、コラボレーションは自然になり、エンジニアリングの生産性が大きく向 上するだろう。 重要な変化は君から始まる。そこから他の人に広がっていく。次の章では、 君のチームに HRT の文化を作り出す方法について説明しよう。
37 内発的動機と外発的動機ー 93 チームメンバー全員を「スイートスポット」に入れるには、「マンネリ」にいる 工ンジニアのモチベーションを高める必要がある。「見て ! リスだ ! 」にいる工 ンジニアには方向性を示す必要がある。「漂流」にいるエンジニアにはモチベー ションと方向性が必要だ。したがって、エンジニアを幸せで生産的にするには、 ( 水と日光ではなく ) モチベーションと方向性を与えることになる。ただし、与 えすぎはよくない。必要ないのに与えてしまうと、逆にイライラさせてしまう。 方向性を示すのは簡単だ。何をすべきかを理解して、構造化のスキルを身に つけて、管理可能なタスクに分解すればいい。これで方向性が必要なエンジニ アに道筋を与えることができる ( 他にもあると思うが、本章ではすでにさまざま なことを説明してきた ) 。ただし、モチベーションについては、もっと説明した ほうがいいだろう。 37 内発的動機と外発的動機 モチベーションには 2 種類ある。外発的動機と内発的動機だ。外発的動機は 外からのカ ( 対価など ) で生まれるものであり、内発的動機は自発的なものであ る。ダニエル・ピンクは『モチベーション 3.0 』 ( 講談社 ) すのなかで、人を幸せで 生産的にするのは外部的動機 ( たとえば札東 ) ではなく、内発的動機を高めるこ とであると言っている。そして、内発的動機には、自律性・熟達・目的の 3 っ すす の要素が必要だと言っている 工ンジニアであれば、誰かがマイクロマネジメントするのではなく、自分で 考えて行動できるときに自律性があると言える 自律性のあるエンジニアは、 こちらからプロダクトの大まかな方向性を示せば、あとはどうやってそこに行 くかを自分で決められる。これがモチベーションにつながるのは、プロダクト す TED の素晴らしい講演も聴いてみよう ( 訳注 URL はこちら。 http://www.ted.com/ talks/lang/ja/dan—pink—on motivation. html) 。 給料に不満がないという前提だ。 マイクロマネジメントが不要という前提だ
3.2 @Deprecated マネージャー こうした手法は何年も マネージャーは労働者を荷車のラバのように扱った。ニンジンとムチを交互 有効だった。 うかもしれないが、労働者が決まった作業を行う限り、 からだ。マネージャーが親のように振る舞えばすす、エンジニアは子どものように ジャーの存在そのものが、報告書を管理する新しいマネージャーを必要とする に正しくないというつもりはないが、マネージャーはもう禁句だろう。マネー ている。マネージャーじゃなくてリーダーにしたほうがいいと思う。政治的 工ンジニアリングの世界でも時代遅れの「マネージャー」という肩書きを使っ 「リーダー」は新しい「マネージャー」 3.2.1 間・空間が必要なのだ。 的な生産性とは違い、エンジニアには考えたり創造したりするための育成・時 ジニアは数か月間かけて新しいチームに追いつく。組立ラインの労働者の機械 年働いたとしても、数日間の研修を受けた労働者と交換可能だ。しかし、エン るす。さらには、エンジニアの生産性も落ちてしまう。組立ラインの労働者は何 ジンとムチの手法には全く効果がない。そのことは多くの研究結果が示してい 題解決が必要な業界も含まれる ( 工ンジニアリングとかね ! ) 。時代錯誤なニン 現在でもその状況が続いている業界が存在する。そこには創造的な考えや問 働者は何年も同じ仕事を続けていた ( たいていは年金が目当てだ ) 。 中頃になるとラバのように扱うマネージャー ( クソ野郎 ) が蔓延した。当時の労 ネジメント手法は、仕事が工場からオフィスに移行したあとも続いた。 20 世紀 に使って、モチベーションを高めていたのである。「ニンジンとムチ」によるマ す http://www.ted.com/talks/dan—pink_on—motivation.html 子どもを注意しているときに「母親と同じようなことをしている」とビックリしたことが あるはすだ。
ー 2 章素晴しいチーム文化を作る ていた。列車 ( すげーうるさい ) が通るたびにみんなで立ち上がって、ナーフ を撃ち合った。こうしたことがチームの文化を作り、チームの生産性やメン バーの定着に影響をなえるのである。 成功しているソフトウェア会社 (GoogIe ・ AppIe ・ Microsoft ・ OracIe) を見る と、どの会社も全く異なる文化を持っていることがわかる。それは、創業者や 初期の従業員が作った文化がルーツとなっているが、会社が成長・成熟するな かで、その文化も進化・変化している。しかし、そのアイデンティティは失わ れることなく、プロダクトの開発方法・社員への接し方・竸合との戦い方など のように、あらゆる側面に浸透しているのである。 22 なせ気にかける必要があるのか ? 手短に言えば、君が文化に気を配っていないからである。強烈な個性を持っ 新来者が現れると、彼の文化がチームに根付いてしまう。優れたコードを生産 的に生み出すような健全な文化になるかもしれないが、おそらくそうならないだ ろう。そして、これまでは設計やコーディングに使っていた時間が、口論やも め事に使われるようになる。チームが大切にしている文化を守ることが重要だ。 チームが文化を大切にできなければ、チームのアイデンティテイや仕事の誇り を作り出せないだけでなく、新来者がクソみたいな文化に簡単に変えてしまう。 工ンジニアは、チームリーダーがチームの文化を作ると勘違いしている。 れは真実とはほど遠い。創業者やリーダーも「文化が健全かどうか」に気を配っ ているが、チームの文化の定義・維持・防御に責任を持つのはチームメンバー だ。誰かが新しくチームに参加したときは、チームリーダーから文化を教え てもらうのではなく、チームメンバーから学ぶのである。たとえば、コードレ ビューのときに理由も添えてチームの書き方を説明してもらえば、チームがど 34 す 訳注タカラトミーのサイトより引用 : 「ナーフは、アメリカで生まれた本格シューティ ングトイです」。 Fi レは Google ピッツバーグオフィスに来たときに震え上がった
ー 2 章素晴しいチーム文化を作る いなかったり、情報が伝わっていなかったりすると、君が正しいコードを書い ているという保証はない。 40 図 2-3 工ンジ二アは予測可能で論理的な人間を好む こうした手間は生産性の向上とチームの幸せのために必要な 要となる。だが、 がチームの方向性に合意して、すべてを正確に理解するには、相当な手間が必 などの多数のコミュニケーションチャネルを使っていることがわかる。みんな 計文書・ミッションステートメント・コードコメント・プロダクションノウハウ うまくいっている効率的なエンジニアリング文化では、メーリングリスト・設 投資だ。 である。できるだけ多くの人が、プロジェクトの文書からすべての情報を取得 の人数を減らし、非同期コミュニケーション ( メールなど ) の人数を増やすこと コミュニケーションの原則は、同期コミュニケーション ( ミーティングなど )
3.5 リーターシップバターン一 87 このたとえ話はユーモアが効いている。それでいて、 Dean が「電車停止問題」 に時間をかけていることも、それがチームに悪影響を与えていることについて も議論できるようになっている。 3.57 幸せを追い求める リーダーとしてチームを長期にわたって生産的に ( そして離脱者を少なく ) す るには、時間を作ってチームの幸せを計測すればいい。かって一緒に働いたこ とのある優秀なリーダーたちは、誰もがアマチュアの心理学者だった。チーム メンバーの幸せを調べて、やるべきことを理解しているかを確認し、その仕事 に満足できるようにしていた。あるリーダーは、誰かがやらなくてはいけない 面倒で報われないタスクをまとめて表にして、チームに均等に割り当てていた。 また別のリーダーは、チームの労働時間を調べて、レクリエーションなどを開 催し、燃え尽き状態を回避していた。また別のリーダーは、チームメンバーと 1 対 1 で面接するときに、最初は技術的な話をして打ち解けてから、仕事に必要 なことについて話していた。場があたたまったら、現在の仕事に満足している のか、次に何をしたいかについて話すようにしていた。 チームの幸せを追い求めるには、 1 対 1 のミーティングのあとに「何か必要な ものはある ? 」と質問するといいだろう。詳細を知るにはもっと調査が必要だ が、チームメンバーが生産的で幸せになるために必要なものを簡単に把握でき る。 1 対 1 の面接のあとに必すこの質問をするようにしておけば、いずれ長いリ ストを持参するようになるだろう。
5.4 組織を操作する一 145 きなければいけない。とりとめもなく書いたり、 4 つ以上のことに触れたりする と、精神的なオーバーヘッドが高くなって、読ますに捨てられてしまう。箇条 書きは短い文章にすること ( 改行なしで 1 行にまとめること ) 。行動要請もでき るだけ短くすることす。メールには HRT を込めること。丁寧に敬意を持って文 ・ボニーがいると生産 しいです。 ・ボニーがいないと悲 ・ボニーがいません。 図 5-8 す 性が向上します。 ボニーが欲しいです。 以上 Jim ポ二一の依頼文 通のメールで 1 つの質問に限定したほうがいい。 複数の質問を書いてはいけない。 1 つの段落に 1 つの質問を心がけよう。できれば、 1 返事が欲しいのであれば、インラインで返信できるようにしよう。また、 1 つの段落に