エンジニア向け名著を読み解いていく当企画。第4回に取り上げるのは『Team Geek—Googleのギークたちはいかにしてチームを作るのか』。Googleのエンジニア2名によって書かれた「チーム開発を進めるうえで、エンジニアはどう振る舞えばいいのか」にフォーカスした一冊です。
著：Brian W. Fitzpatrick、Ben Collins-Sussman 訳：角 征典 刊：オライリー・ジャパン 初出：2013年7月
今回は同書を翻訳した角 征典さんにお話をうかがい、この本の見どころや若手エンジニアが活かせるエッセンスを探っていきます。聞き手はアプリエンジニアの池田です。
- 角 征典（かど・まさのり）
@kdmsnr （写真・右）
- ワイクル株式会社代表取締役。東京工業大学 環境・社会理工学院 特任講師。アジャイル開発やリーンスタートアップに関する書籍の翻訳を数多く手がけ、それらの手法を企業に導入するコンサルティングに従事。翻訳書に『リーダブルコード』『Running Lean』『エクストリームプログラミング』『メタプログラミングRuby』などがある。
- 池田 惇（いけだ・じゅん）
@jun_ikd （写真・左）
- スマートフォンアプリエンジニア。iOS・Androidのアプリ開発を行いながらPMや開発チームリーダーを経験。エンジニアとして技術を学び続け、プロダクトマネジメントや人材育成でも活躍したい。アジャイル開発とオープンソースソフトウェアの活用を好む。
- 『Team Geek』は、技術だけじゃなく人間やチームに気を配る大切さを説く
- HRTって、全員ができるもの？
- 天才以外は何でもオープンに。うまくやるコツは？
- パフォーマンスの低い人にどう対応する？
- 個人の幸せとチームの幸せをどう重ねていくかが、リーダーやマネージャーの腕の見せ所
- 会社以外のコミュニティでオーナーになろう
- 【今こそ読み解きたい名著】バックナンバー
『Team Geek』は、技術だけじゃなく人間やチームに気を配る大切さを説く
池田 僕がこの本を初めて読んだのは2013年の10月で、本が出てから3ヶ月後くらいでした。活躍しているマネージャーが、この本をすごく良いと言っていて。その頃、僕はまだエンジニア3年目で「ふむふむ、こうやっていけばいいんだな」と読んで思った記憶があります。
角 本の「日本語版まえがき」を書いてくれた及川卓也（@takoratta）さんや、Kaizen Platformさん、アプレッソ社長の小野和俊（@lalha2）さんが、ブログとかいろんなところで触れてくれて、発売してから少しずつ認知度が高まっていったのかなと感じています。
特に、Qiitaを運営しているインクリメンツさんがこの本のキーワードであるHRT（ハート）を社内のガイドラインに入れてくれて、それがバズったのもありますね。そのあと及川さんがインクリメンツに入社した（現在は同社から独立）ので、より注目度が高まったと思います。
Incrementsついて - Increments株式会社
池田 自分がマネージャーを経験したあとで今回読み返してみると、改めていろんな気づきがあるなと感じました。まずは若手エンジニアに向けて、この本をどのように読めばいいのか、というところからうかがいたいです。
角 技術が好きでエンジニアになった人は、やっぱり技術力を高めたいっていう意欲も強いし、流れの速いIT業界の中でキャッチアップするために一生懸命やっていると思います。この本はそんな人たちに向けて、技術だけじゃなくて人間とかチームとかに、ちょっとでもいいから気を配ってほしいという内容なんですよね。
ぼくたちが強調したいのは、孤高のプログラミング職人はいないということだ。たとえいたとしても、1人で超人的な偉業を達成できるわけではない。世界を変えるような功績は、インスピレーションの閃きとチームの努力の結果である。
『Team Geek』p.13より
といっても若い人はSNSネイティブの世代なので、人とのコミュニケーションにはすでに慣れている気もしています。逆に僕みたいな40歳前後の人の方が、コミュニケーションに対する苦手意識は強いかもしれない（笑）。
ただ、SNSとかLINEでの短いやりとりとは違って、仕事のプロジェクトではうまくいかないこともたくさん出てくるでしょうから、そういうときのヒントにしてもらえればと思います。
独自の開発現場に、若手がどう適合していくか？を知る
池田 学生だと自分と近い考え方を持った人どうしで集まったりしますが、会社に入ると年齢やバックグラウンド、考え方も違う人たちが一緒に働くわけですからね。
角 会社での働き方は、必ずしもオープンソース文化とフィットするわけではありません。使いたいライブラリやOSSが自由に使えなかったり、社内独特のコミュニケーション方法に悩んだりすることもあるでしょう。『Team Geek』を通じて、チームコミュニケーションの方法や考え方を学ぶ、というのも良さそうです。
池田 大きい会社に何も知らない状態でいきなり入って、そこの「開発現場が普通」というように思ってしまうと、ひとつの価値観しか知れず、一般的な感覚とズレるという怖さがありますね。
角 大きい会社は社内開発ルールを持っていることも少なくありません。自分の会社独自の環境に従ってしまうと、オープンソースの活動と会社の活動に齟齬（そご）があって苦しんでしまうでしょう。先日聞いた話ですが、会社のGitHubにプルリクを送るのに上司に申請書を提出する会社もあるみたいですよ。
池田 それはすごいですね（笑）。
角 「勤務中に書いたコードは資産なので会社に著作権があり、それをプルリクするということは、外部に公開するということなので上長のサインがいる」ということらしいです。そういうのとオープンソースの文化って、当然ですけど全く合わないのでつらいですよね。
池田 なるほど。私はリーダーを目指す人のステップアップにも役立つかなと思ったのですが、どうでしょうか。
角 後半はそうですね。エンジニアからマネージャーやリーダーになるというと、人間力とかスキルが全方位的に上がっていくイメージがあると思うんですが、この本は「そうじゃなくていいよ」って言ってるんですよね。全てのことに気を配って、プロジェクトを成功させるために全力で立ち向かう、みたいなことがたぶん幻想で（笑）。
天才やパーフェクトな人はいないという前提に立って、自分が高められないところはチームで補完すればいいんだよっていうところも、若手に読んでほしい点ですね。
HRTって、全員ができるもの？
池田 チームで働くときの三本柱として紹介されているのがHRT、謙虚（Humility）、尊敬（Respect）、信頼（Trust）です。
コラボレーションの涅槃に到達するには、ソーシャルスキルの「三本柱」を身につける必要がある。この三本柱は、人間関係を円滑にするだけでなく、健全な対話とコミュニケーションの基盤となるものだ。
謙虚（Humility）
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善していこう。
尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手を1人の人間として扱い、その能力や功績を高く評価しよう。
信頼（Trust）
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば、仕事を任せることができる。この3つを合わせて「HRT」と呼びたい。読み方は「ハート」だ。痛みを軽減するものだから、苦痛の「hurt」ではなく、心の「heart」である。ぼくたちの主張は、この三本柱で成り立っている。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。
『Team Geek』p.15より
本の中では、HRTはテクニックとして誰でも身につけられるから、そう振る舞おうと書いてあります。でも僕はどうしても、もともとの性格もあるし全員が全員そう簡単にはできないのでは……と疑問に感じてしまうところがあって。
角 この本を読んでいただいた感想の中に「合理的だ」というのがあったんです。
本書で述べられているのは、自分がどう思おうが関係なく、インターフェイスとしてHRTをやりましょう、ということなんですよね。HRTはスキルのひとつ。たとえ苦手だとしても、相手のことを信頼できないとしても、できないなんて言ってる場合じゃない（笑）。そのステップは本には書かれていないのですが、仕事なんだから社会人として身につけるしかない、というのが答えでしょうか。
HRTをやらずに成功することもあるでしょうが、それはごく一部の天才に限った話だと思います。天才じゃない凡人は、チームでうまくやるためにHRTをしないと孤独になっていくし、孤独になると死んでしまう。だからHRTを頑張るしかない。
この原則は本当に重要なので、本書はこれを中心に構成している。
まずは、君がHRTを受け入れて、内面化するところから始まる。つまり、コミュニケーションの中心にHRTを置くということだ。
『Team Geek』p.16より
池田 自分は苦手かも、と思うよりも「当然身につけるべきスキルなんだ、やるしかない」と思ったほうが楽ということですね。どう思うかは自由で、「振る舞いだけ気をつける」と割り切れば苦しむこともなさそうです。
角 はい。もし相手を信頼できなかったとしても、それをそのまま口に出して言う必要はないですよね。心の中で思うのは自由だけど、仕事としては割り切ってHRTやりましょうっていうことだと思います。このHRTが、この本の8割を占めるくらいのキーワードなんですよね。
天才以外は何でもオープンに。うまくやるコツは？
池田 1章では、天才以外は何でもオープンにしよう、隠したらダメになるよという話も出てきますが、私が自然にオープンにできるようになってきたのは5年目くらいでした。それまでは自分のスキルに自信がなくて、見せるのが恥ずかしいというのがあって。自分に自信がなくても隠さない、というふうにうまく考え方を切り替える方法やコツがあればお聞きしたいです。
隣の人に相談することから始めよう
角 いきなりグローバルに公開しちゃうのって、結構心理的なハードルが高いんですよね。世の中には、人のアラを見つけてはケチをつける人ってやっぱりいるので。
なので、最初は仲間内から始めるのがいいと思います。会社だったらチームや部署レベルで公開してフィードバックをもらって、という経験を積んで、最終的にGitHubに公開するくらいのイメージ。苦手な人は、小さく、小さく、スタートする。
素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのは、リスクの高い大きな賭けだ。早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、誰かと協力するメリットが失われる。
（中略）水に飛び込む前に、つま先を水につけるのはそのためだ。自分が正しいことに取り組んでいるのか、それがうまくできているのか、すでに完成していないかを確認する必要がある。早い段階で失敗する可能性は高い。しかし、その段階でフィードバックを求めれば、それだけリスクは下がる。検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神を忘れないようにしよう。
『Team Geek』p.9より
池田 できないと思っている人ほど小さいうちに見せられず、ひとりで抱え込んでしまうような気もします。
角 最初は隣の席の人に見てもらうことから始めて、徐々に増やしていくしかないですよね。どれだけ早い段階で公開できるかというのはすごく重要だと思います。みんな天才ではないので、天才以外はみんなで回していかないと無理、だからオープンにする、ということを早く身につけないといけない。
マネージャーはメンバーの困り事を直接聞いていい
池田 早く身につけるには人数を減らすなど、できるだけ公開のハードルを下げるというのが大事なんでしょうか。
角 そうですね。チームメンバーにとって居心地のいい環境を、リーダーやマネージャーがデザインしておく必要もあると思います。隣に話しかけるにも許可がいるんだったら、話しかけられないですもんね（笑）。
たしか『Clean Coder』に書かれていたと思うのですが、「ヘッドフォンをつけるな」という話があって。ヘッドフォンをつけると集中できる反面、話しかけにくいからダメだと。このように隣の人が話しかけやすいようなルールを作るのも、ひとつの案かもしれません。
池田 若手の人ほどそういった細かい振る舞いが気になるでしょうし、少し変わるだけで、安心して話しかけたりオープンにできるようになったりするのかなと感じます。
角 あとは、当事者だとメンバーやチームの状況を客観視できないので、誰かがチームの外部から調整していかないといけないですね。若手でも隣のチームの指摘はできると思うので、チーム同士で「〇〇さんが話しにくそうにしている」と伝えあうのも、ありかもしれません。基本的にはリーダーがいなくても、自律的に回るのが最高。そのチームをどうやって作るかは、責任を持つ人の腕の見せどころだと思います。
池田 ただ、初めてチームを持つ人間にはかなり難しい技術に感じます。リーダーやマネージャーには、メンバーの技術面も非技術面も客観的に見て、チームに足りない部分を判断できる力が必要ということでしょうか。
角 チームに足りない部分を見極め、足りない部分を補完する、いわば適材適所を考えるということですよね。本の中でも触れられていますが、チームが必要だと思っていることは普通にメンバーに聞けばいいんです。「今、何に困ってる？」とかね。
チームの幸せを追い求めるには、1対1のミーティングのあとに「何か必要なものはある？」と質問するといいだろう。（中略）チームメンバーが生産的で幸せになるために必要なものを簡単に把握できる。
『Team Geek』p.87より
池田 「察知する」とかじゃなくて、普通に聞けばいいというのは、すごく明解ですね。
角 根拠がないのに下手に推測しても外れちゃいますし、的外れなことをしていると、周囲から「何やってんの？」みたいに思われちゃいます。『Team Geek』はアジャイルやスクラムという言葉を使わずに、チームを作りましょうっていう本なんですよね。型やスタイルにはめることなく、普通に改善していくというスタンスで書かれているので、すごく参考になると思います。
パフォーマンスの低い人にどう対応する？
池田 自分がマネージャーをやっていたときに一番難しいなと思ったのが、3章に書かれている「パフォーマンスの低い人に早めに対処する」のところです。何かを任せてもうまくいかないし、差はどんどん広がっちゃうし、もうどうしたらいいんだろうみたいな感じでした。
角 パフォーマンスの低い人には、技術的に卓越しているマネージャーが一緒に伴走してあげる必要があると思います。たとえば「技術力のない、環境を整えるだけ」みたいなスクラムマスターが対処しても、この問題は解決が難しいでしょう。
アジャイル開発が流行ってくると、技術力はさておき人間力の高い人とか、コーチングやファシリテーションのスキルばかり目立ってしまいがちです。ですが、チームをマネジメントする立場にいたとしても、技術スキルがゼロでいいというわけじゃないんですよね。
たとえば、足を痛めた人がリハビリをして、再びチームと一緒に走り出すことを想像してほしい。そのときには一時的なマイクロマネジメントが必要になるはずだ。ただし、HRT（特に「尊敬」）がある前提だ。期限（たとえば2〜3か月）を設定して、達成してもらいたい目標を決めよう。最初の目標は小さくして、少しずつ大きくできるといい。小さな成功を何度も経験するためだ。そのエンジニアには毎週会って進捗を確認する。
（中略）パフォーマンスの低い人に直接働きかけることで、必要かつ重要な変化の触媒となるのである。
『Team Geek』p.72より
角 個人的に、この本のすごくいいなと思っているところは4章「有害な人に対処する」があること。普通はなかなかここまで言わないですからね（笑）。4章にあるような対処方法や、最終手段をオプションとして持った上で、付き合う気があるのならずっと付き合っていかないといけないですね。
4.4 有害な人を追い出す
礼儀がなってなかったり、社交的ではなかったりするだけで、その人を追い出すようなことをしてはいけない。（中略）ぼくたちはPatrickを追い出すようなことはしなかった。彼の振る舞いを追い出そうとしたのである。好ましくない振る舞いは受け入れられない。何度も警告しても振る舞いが改善されなかったら、そのときは正式に追い出すことを検討してもいいだろう。
『Team Geek』p.108より
みんな天才じゃない。複数の評価軸を持って、局地的でも評価する
池田 自分がリーダーとしてチームメンバーと伴走できればいいんですけど、伴走できる状況でなかったり、そもそも自分に伴走する能力がなかったり、と感じたこともあります。こうした「リーダーやマネージャーに向いていないのでは？」という悩みは、結構多くの方が共有しているように思いますが、どう解消するべきでしょうか？
角 難しい問題ですが、ひとりで悩まずに、チームに相談しながらマネジメントするのが一番いい方法だと思います。
それから大前提として、人はだれでも成長できるし、成長したいと思っていると、認識すべきです。教えたら伸びるはずだし、本人も伸びたいと思っているという前提があれば、プロジェクトの中で成長していくことは十分に可能です。
池田 半年、1年仕事をしても全然活躍できない人が、ちょっと違う業務をするといった些細なきっかけで急に活躍をしだす、みたいなこともありますよね。
角 プロジェクトの開始前後を比較して、その人のスキルが少しでも伸びたら成功だといっていい。超人と比べるのではなく、本人が伸びていれば、それでいいんですよ。
池田 やっぱり周りと比べるというのはアンチパターンですね。僕も、Twitterで流れてくる世の中のイケてそうなエンジニアと自分を比べてしまって不安になるとか、いまだにあります。
角 ソーシャル上ですごい人を見かけるとビビりますよね。わかる（笑）。でも、『Team Geek』が言っているのは、みんな天才じゃない、だったら局地戦で勝とうということなんです。
「フロントエンドのこのライブラリのことについては詳しい」って範囲を狭めるとか、社内でかわいがられている、とか。どんなに狭くてもいいので、評価軸をたくさん持つといいんじゃないでしょうか。
池田 自戒の意味もあるんですけど、エンジニアだと、「新しい技術をよく知っていて使いこなせること」みたいなのが評価軸になりがちです。その軸だけで自己評価してしまうのは、『Team Geek』でいう「局地戦で勝つ」考え方とは真逆なので、よくないなと反省する面もありますね。
角 みんな天才じゃないよって1章に書いてあって、さらりと読み飛ばしがちなんですがそこが超重要。天才と比べると萎えちゃうので。
現実的に考えてみよう。君は天才じゃない。 （中略）でも、仮に君が天才だったとしても、それだけでは不十分なんだ。天才だってミスをする。優れたアイデアやプログラミングスキルがあっても、開発したソフトウェアが必ずしも成功するとは限らない。今後のキャリアがうまくいくかどうかは、同僚たちとうまく協力できるかにかかっている。
『Team Geek』p.7より
池田 他のいろんな本だと、スキルアップや将来のためにOSSにコントリビュートしようとか、ブログは毎日書こうとかありますよね。だからその解釈にはすごく救われる感じがしました。
角 天才じゃなくてもいいんだっていうのは、翻訳している最中に自分にもすごく刺さった言葉です。著者たちもSubversion作っているくらいのエンジニアだから、決して凡人じゃないんですけど、「天才ではない多くの人たち」のために書いているという感じはしました。「凡人でもチームで勝つには」みたいなサブタイトルにしたらよかったかも（笑）。
個人の幸せとチームの幸せをどう重ねていくかが、リーダーやマネージャーの腕の見せ所
池田 リーダーとして「チームの幸せを計測する」「オフィスの外にあるチームの幸せにも注意を向ける」という内容がありました。ちょうど最近子供が産まれたこともあって、エンジニアのワークライフバランスも気になっています。
角 チームって人間が集まっているので、当たり前のことですが人間一人ひとりに目を向けないとダメだということですよね。個人の幸せとチームの幸せって、100%重ならないんですけど、どうやって重ねていくかがリーダーとかマネージャーの役割になる。
近年、メンバー一人ひとりに目を向ける重要性が認識され、「1on1」という言葉も登場していますが、翻訳当時*1はそんなにメジャーな言葉ではなかった気がしています。ですから「1対1のミーティング」というように訳していますけど、これが重要であることに変わりはないですね。
また別のリーダーは、チームメンバーと1対1で面接するときに、最初は技術的な話をして打ち解けてから、仕事に必要なことについて話していた。場があたたまったら、現在の仕事に満足しているのか、次に何をしたいかについて話すようにしていた。
『Team Geek』p.87より
今は多様性をどう確保するかということを考えなきゃいけない時代になっていると思います。女性を入れればいい、年齢がばらければいいなどの属性の話だけではなく、家庭事情とか、どうやって生きていきたいかという心情を含めた多様性の話。みんながハッピーになるためにはどうすればいいかっていうのを、考え続けないといけないですよね。
池田 僕も今後、より多様性が大事にされるようになっていくのかなと感じていて。エンジニアは遅くまで働いていて、ひとり暮らしで、若くて、みたいなステレオタイプがあると思うんですが、年齢を重ねると結婚したり子供ができたりするし、今後いろんな人が増えてくるのかなと思っています。
角 現時点では、IT業界の働き方やチームのあり方が、他の業界のモデルケースになっていると思います。「AppleやGoogleがこんな働き方を採用した」というと、みんなその方法を採り入れるとか。そういう意味では、IT業界はまだワークスタイルの更新がなされている、という気はします。
会社以外のコミュニティでオーナーになろう
池田 エンジニア中心じゃない会社だったり、下請けだったり、いろんな環境で働いているエンジニアがいますよね。今のチームや環境がつらいなと思っているときに、ライトに環境を変えちゃっていいのか、この本に書いてあるような自身の情報公開やHRTといったことを十分に実践しないと逃げになっちゃうのか、どう思われますか？
角 すごく難しい問題ですね（笑）。チームや会社がうれしくなることと、自分がうれしくなることの共通項をどれだけ大きくできるかという話だと思うんですよね。共通項がゼロなのであれば逃げちゃえばいいと思うし、これから広げていけると覚悟を決めたら、広げる方向に動くのもいいと思います。
本当に自分の人生をかける価値のあるチームや会社なのかっていうのは、簡単にはわからないんですよね。価値があると自分が思えばやればいい。別に定年まで勤めあげることが重要な社会ではないですしね。本のなかに「正しいことをして、解雇されるのを待とう」という話が出てくるんですけど、例えば「宝くじで6億円が当たってもその仕事をやるか」と考えてみるといいのではないでしょうか。「6億円あるならやらない」と思うことは、やらなくていいんじゃないかな（笑）。
もうひとつ、会社というコミュニティだけに所属すると、どうしても閉じた世界になりがちので、オープンソースのコミュニティでも勉強会でも何でもいいので、会社以外の軸を複数持っておくと、世界が広がっていいのかなと思います。
特に、プロジェクトのコミッターになったり、コミュニティの主催者になったりすると、マネジメントする側とメンバー側の両方の気持ちがわかるようになるから、ちょっと大変なことがあっても「わかるわかる、しょうがないよね」と、おおらかに過ごせるようになる気がします。
池田 自分も以前、会社以外の軸が全くなくて、会社のチームが全てみたいになっていました。「会社で失敗しちゃったら人生が終わってしまう！」という強迫観念があって、今思うとつらかったですね。私自身、異動や社外での記事執筆など、別のコミュニティを知ってから自分が活躍できる機会が増えたと実感しています。
角 ソフトウェアだけじゃなくて、同人誌を作ったりとかもいいと思います。「技術書典」のような場もありますからね。本を作るって、すごくソフトウェア開発と似ているところがあるんです。私もRe:VIEWという出版システムの開発に携わっていて、これまでの翻訳書は『Team Geek』も含めて、だいたいこのシステムを使って書いています。あとは、コミケとかメーカーフェアとかに、自分が作ったプロダクトを出すのもいいでしょう。
池田 世に出してフィードバックがもらえるし、その意見をふまえて学んだり、また世に出そうというモチベーションも上がったり、というループができてすごくよさそうですね。
最後に、若手エンジニアに向けてメッセージがあればお願いします。
角 新しい時代を作っていくのは若い人たちなので、年上の人に臆さず、自分たちが正しいと思うことをやっていってほしいです。ただ、ひとりではできないことも出てくると思うので、チームでパフォーマンスを出すスキルを早いうちから身につけておくといいと思います。『Team Geek』を読んで、HRTを身につけて、幸せなエンジニアライフを送ってください。
【今こそ読み解きたい名著】バックナンバー
取材：薄井千春（ZINE）／執筆：工藤有里（ZINE）
*1:日本語版の初版は2013年7月発行