インフラエンジニア(SRE)がTeam Geekから学んだチームマネジメントについて&所感

概要

読んだ本は、『Team Geek ―Googleのギークたちはいかにしてチームを作るのか (以下本書)』である。
本記事においては、本書を読んで自分なりに解釈し、自分の考え方に落とし込んだことを所感を交えながらまとめる。

この記事における『エンジニア』を、『社会人』や『大人』として置き換えてもなんらエラーなく読み進められるのではないかと思う。そのため、ぜひ 非エンジニア も、本記事だけではなく、本書TeamGeekを読んでいただけるといいかと思う。

HRT

読み方は『ハート』。
そもそもHRTとはなにか。それは

• Humility
• Respect
• Trust

の、それぞれの頭文字を取ったものであり、本書を読むうえで大前提となっている3本柱の概念である。
社内外に関わらず、仕事のコラボレーションにおける大前提でさえあると感じた。

実際、人気な人は、大体愛嬌があったり可愛げがあるのではないだろうか。
そして他人にあまりマウントを取ったり自慢をしないのではないだろうか。
それは謙虚さや尊敬に近いものとともに信頼に結びついていて、人気を得られていると思う。
(余談だが、私の大好きな、YOASOBIのボーカルでもある幾田りらさんは、つい最近まで「ジェットコースター」を「ゼットコースター」と思い込みながら生きてきた。しかも彼女は謙虚で相手を立てるのがうまい。愛嬌モンスター。かわいい。しかも、後に述べるHRTを実は全て達成している。)

Humility(謙虚さ)

エンジニアは、自分はあくまでエンジニアの一人であるわけで、他人よりすごいと思ってはいけない。
つまり天狗になるなということだと解釈した。
エンジニアによくありがちなプライドの高さを捨てることにつながるので、なかなか簡単にできない人も多いと思う。
だが、自分はできるだけ意識するようにしていたし、改めて重要なことだと認識できた。
謙虚さは、新たな技術を受け入れる(それが自分の仕事を奪いかねないものだとしても)ことになる。
それは新たな世代のエンジニア・新たな仕事に触れられるチャンスへとつながる。
実際、社会人をしていて思うのだが、謙虚さは如実にその人の印象や雰囲気に繋がっているものではないかと思う。
誠実に、近づきにくさを与えず、同僚やユーザーとの関わり合いをしていくことが謙虚な仕事への取り組み方であると考える。

Respect(尊敬)

他者の持っている考え方を尊重する。
何度も本書で出てくる『建設的』という言葉からもわかるように、建設的な議論(無駄なやりとりを減らす)ためには、前項の謙虚さに加え、尊敬する必要がある。そうしないとエゴを押し付けてしまうからだ。
ただし、これができるのは、仕事で関わる登場人物の誰もが、謙虚さと尊敬できるようでないと難しいと思う。だからこそ、HRTは組織の中で大前提として持っていないといけない考え方だと思う。
特に、『自分はわかっているからわかっていないお前は劣っている』みたいな考え方を他者にしてしまうとそれはある種のエゴの押し付けになりがちだなと思う。

Trust(信頼)

他人の仕事を受け入れることから始めないと信頼することはできない。
ただし受け入れたから謙虚になりすぎて(押し黙って)指摘できないようではむしろ信頼できているとは言えない。
まずは相手の提案や発言を、一旦受け入れる。
なるべく称賛すべきところで称賛はすべきだ。褒められて嫌な人間なんて聞いたことがないしいるはずがないと思う。
結果的にそれは他人に対する信頼できる部分が明瞭化していき、どういう点でこの人は信頼できるな、と考えられるようになってくると思う。

現場で起こりうる例

現場で起こりうる例

本書を読んで、業務の中でHRTを実践できていなかったことによる事例を思い出した。
それは、とあるツールをチーム全員(当時5人くらい?)で使うにあたり、

「オープンな場でベストプラクティスを謳っている概念であれば、それはエンジニアとして最低限知っている必要があるし、なるべくそれに沿うべきだ。『動けばそれでいい』ではない。」

と、ツール導入に先駆けて動いていた私が、発言してしまったことによるものだ。
それは確かに内容に間違いはなかったかもしれないが、エゴの押し付けのように言うのも違うと思った。上長からも指摘されてしまった。もっと言い方があったと思う。

エゴの押し付けをしてはならないと本書に書いてあるとおり、これではメンバー間で理解してもらうことは難しくなるし、メンバーは(自分自身も)必要以上に感情的になり、建設的な議論からは遠くなる。実際にしょうもない議論が続いてチームメンバーと余計な消耗をした。
そこで反省として、チーム内で小さな勉強会を開いて、そのツールの概念を紹介した。

しかし、参加したメンバーは、そこから自分で勉強をしてくれたようではなかった。その後、ごく一部メンバーだけでプロジェクトが進んだ(私達は口出しも禁止された！)結果、運用に則さない中途半端なアウトプットが量産されてしまった。
これに関してはどうすればよかったのか未だに答えが見つかっていない。
一つ思うところがあるとすれば、チームに『先人に学ぶ』謙虚さが概念としてそもそもなかった気がする。そうでなくとも、私に対しては、『入社したばかりでこいつはまだ信頼できないから』と思ったのだろう。
私を含め、適切にメンバーを信用し、必要なメンバーをそのプロジェクトにジョインさせなかったというのが原因の一つにあったと思う。
ちなみにちゃんと調べて学んで、いい指摘やアウトプットをしてくれていたメンバーが約一名いて、一緒に業務をしていた。だが彼は退職してしまった。

その結果どうなったか

その後、人員不足でペアプロ(プログラミングではないが)もままならなくなり、(次の章に関連するが、)私はほぼ『一人で仕事』するような状況になり、ほぼ一人でプロジェクトに携わり、レビューをもらいにくくなり責任の分散にハードルが生まれ、業務の質が低下した。それまでは自分にとってあり得なかったことだ。
このような環境で増えていったフラストレーションや不信感は、私にとっても退職を検討するきっかけになった。非常に悲惨である。

また、私がメンバーから離れた後に、そのツールで書かれたものを覗きに、そのrepositoryをみにいくと、

『動けばそれでいい』つくり
=『そこまでベストプラクティス遵守する必要はない』つくり
＝『そのツール本来の仕様や理念・概念に反する』つくり
＝『後々に運用がしんどくなる』のが目に見えるつくり

そんな、インフラエンジニア・SREにおいていちばん大事な『安定運用』から外れた状態になってしまっていた。(ベストプラクティスの欠如)

結論

このような実例からわかる通り、HumilityとRespectは、セットでメンバー全員に根付いていないといけない。
そうでないと、信頼関係(Trust)を築くなんて到底不可能だと思う( = 健全なエンジニアリングができる状況ではない)。尊敬と信頼があることで信頼をコツコツ積み上げ、なるべくしてチームの状態が良くなる。
逆に言うと、尊敬と信頼が足りていないと、優秀なエンジニアがその組織から脱落していってしまう。

一人で仕事してはいけない

実はこの『一人で仕事してはいけない』ことは、HRTよりも前の章で書かれており、すなわち、一人で仕事してはいけないというのが大前提として本書では書かれている。
『チームがすべてである』、『チームスポーツである』と本書で書いてあるとおり、チームで仕事をしている以上、他人を思いやらないといけない。
それはwikifyすることで知識のオープン化を図ることが大前提だと思う。(文書化と本書では書いてあるが、そこまで固いものではなく、気軽に書き起こせるべきだと思っている。)
特に社内用語・社内ツールのようなものは、新規joinした人間からするとわかるわけがないからである。極端な話、そういった類のものは赤ちゃんでもわかるように整理したり、わかりやすく使いやすくしてあるべきだ。それがもしされていなかったのなら、それをしようとしてこなかったことを謙虚に認めてアクションに起こし、次からはちゃんと当たり前に整理する。反省を活かして今すぐにでも改める。
当然、エンジニアとして世の常識であるものに関しては、新規joinしたメンバーへの教育課題としてもいいだろうし、調べないと理解できないようにwikifyされていてもいいかもしれない。
一人で何でもしていいならば承認プロセスや稟議なんてものは完全に社内システムから取っ払わないといけないし、責任もその個人に押し付けてしまい、その個人をそれ相応の給与レンジや役職に引き上げるべき。でも、ある程度の大きさの企業で、そんなことを望む企業は(特に事業を営む企業において)、存在しないのではないだろうか。

また、これって結局属人化が絶対悪であることについてもつながる話だと思う。
属人化を一つの美徳になり得ないと主張する人がいるが、それはその属人化させている人を職人化させることであり、触りにくい古い遺跡となったシステムを残すことになる。
作業しながらそれを作業ログとしてwikifyして、最終的にはそれを整理し、一緒に仕事している人(ペアプロしているバディでもいい)にコードレビューとともにもらい、それがプロジェクトのゴールの中に組み込まれているべきだ。

ミーティング

特にアジャイル方式である場合は、一定の周期でデイリースクラムであったり何らかの形でミーティングの機会を作っていると思う。
ミーティングは、不必要な時間をなるべく省くために、ミーティングでしかできないことに集中してやるべきだ。
本書では『デイリースタンドアップMTGは、15分程度のミーティング時間に収める』ように書いてあるが、全くそのとおりだと思う。どうしてもMTGで話すべきことがあるからMTGをするべきで、どうしてもMTGで話すべきということは、話したい内容が整理されているはずだ。だから、自分の話したいことを整理するためにも、アジェンダをちゃんと前日までに用意しておき、配布する。MTGの参加者は、そのアジェンダを元に得ておく知識を準備しておく(更にいうと、個人的には、そこで質問したいこととかが生まれればそれを含めて整理しておけると望ましいと思っている)。

課題管理

バグは必ず生まれる。
そのバグには重要なものから軽微なものまでたくさんある。
だが、それらをトラッキングできないと収拾がつかなくなる。

どこでもKanbanとか使っていると思うが、課題管理は非常に重要だし、それを整理するための時間を、スプリントレビューの一部として(当然のように！)取り込んでいるべきだと思う。
そうしないと、エンジニアの我々は、ただ課題をタスクとして登録するだけのWorkerになってしまうのでなんの意味もない。(仕事をした気になって満足しているだけ！評価されるべきではない！※)
その整理の時間をなるべく短く効率的にするためにも、課題管理をするツールは利便性の高いものであるほうが望ましいと思う。(むしろそういう提案を課題感を持って提案した人が評価されるべき！※)
どこのものとは言わないが、まとめてチケットを削除したり追加ができないが為に、APIを使ってチケット管理するためにフロントエンドを別途開発する羽目になるチケット管理ツールが有る。公式ドキュメントにも、スプレッドシートを利用してまとめて処理するように案内が書いてあって正気かと思った。チケット整理のために多くの時間が消費されて非常にフラストレーションが溜まった。
これでは課題の整理がしにくいし、今抱えている課題がどんどん埋もれてわかりにくくなっていく。
そのため、最近だとAsanaやMonday.comのような別のツールを使うなりなんでもいいが、無駄を減らす工夫をしたほうが良い。
チームメンバーが当事者意識を持ち提案し、その相談を受けるチームリーダーは耳を貸すべきだ。(もちろんチームリーダーもチームメンバーなのだから、チームの様子を見て提案することがあってもいい！)

※: このようなことに関連し、自律性のある動機について、本書の内発的動機・外発的動機として3章7項(3.7)にも記載されているので、もし本書を読むことがあればぜひ抑えておきたいポイント。

(主にリーダー)エゴをなくす

本書ではエゴをなくすことを繰り返し書かれているが、これはリーダーによるチームマネジメントにも言えることだと言える。

部下である他のチームメンバーに、マイクロマネジメントをせず、ある程度仕事を任せてしまうのだ。(信頼)
これによって当事者意識を植え付けることになる。ただし失敗してもいいとちゃんと伝えることで、経験をさせる。

↑まとめるとこのような感じになってしまうが、だからといって『放任主義』になってしまってはいけないと思った。
ちゃんと本人の仕事ぶりを(なるべくバレないように)ちゃんとアンテナを立てて継続的に把握する。ある程度の粒度で。
これによって、本人に対する正当な評価ができるし、正当なフィードバックができる。更にいうと、取り返しのつかない失敗を未然に防げる。(古いシステムならば、絶対に止まったらまずいものとかもあるし…)
質問されたときにはなるべく待ちを生ませないようにもしたいから、チームメンバー全員にメンションとかできると良いと思う。(つまり、誰でもその仕事が理解できている=属人化していないので誰でも答えられるし、知らないメンバーも勉強になる=リーダーも学ぶことが出てくることが多いにあるはず)

有害な人

有害な人とは、

• 意図的に意地悪する(目的があって攻撃する)人
  • 個人的な経験則からすると、属人的な運用で資料化もされていないのに、それに関わっている人間のワタシからの質問を、あえてわかりにくい回答を投げることで、私が理解に時間がかかっているのを見下して楽しむ？ような言い回しをした人がいたけどまさにこれじゃないかな…(＝大人げなさ)
• 他人の時間を尊重しない
  • 一例として、自分で調べることを怠ったりすることで、他人の時間を奪う人
• プロジェクトに自分の思い通りになってほしい願望を押し付けようとする人
  • つまりエゴの押し付けということと認識した
• 権利を与えすぎる
  • 本書では章題にこう書かれているが、内容としては、権限を持つものが、その、持っているその権限を振りかざす『トロル』のことだった
• 完璧主義
  • 要は、自分の完璧主義によって、設計段階等で時間を取ってしまい、周りが仕事にあたれずストレスをためさせてしまう人
  • これはアジャイルプラクティスに則ってリーダーがチームメンバーの状態を全員の共通認識で持てていればいいだけの話では？と思った

リーダーとの向き合い方

大前提としてリーダーだって人間である。エスパーではないのでちゃんとコミュニケーションを取ろう。

理想的なマネージャー

理想的なマネージャーのもとで働くなら、リスクを取ることを恐れるべきではない。
「先を見据えた行動を取ろう。」と書いてあったが、まさにそのとおりだと思う。
とてつもなく工数を要するならともかく、
例えば、先を見据えて運用を楽にするため、
「xxxはより抽象化を図れないか？」「マイクロサービスアーキテクチャにしないか？」
とか、そういう事を考えて一歩踏み込んだ行動に挑戦する人はリーダーから称賛されて後押しされるべきだ。
そのためにコミュニケーションは積極的に取るべきで、コミュニケーションを取りすぎて怒られるなんてことはないはず。(だからといってちょっとも調べないとか、まとめて質問投げかけようとか工夫せず脳死質問はだめだと思うが)
恐れるべきではないし、そこから失敗したり学びを得て次に繋げるべきだ。それを後押ししたり建設的に当事者意識を持って学びあえる(リーダーと部下がともに成長！)ようだと素晴らしいと思う。

逆に、本書の内容からいえば、これらを阻害するマネージャーが悪いマネージャーである。

悪い組織

リーダーの上にも更に上司がいるわけで、それが組織となるのだから、本書では、『悪い組織』について、『リーダーとの向き合い方』と同じ章で書かれている。
具体的にどんなのが悪い組織かというと、

• 経営層が、必要なシステムを支える技術を理解していない
  • その技術者の業務の大変さを理解していない・しようとしないことというのはニアリーイコールだと言える
• ビジネスのために従業員を奴隷のように入れ替えられる構造
  • 故に、優秀な人間は逃げ、無能な人間が残る
  • そういう組織はDX(開発者体験)を軽視しがち(これは私の経験則)

最悪の場合はその組織から逃げるという最終手段を取るべきであるとも本書で書かれている。
自分の人生や時間は有限であるので、そのような組織では、どう工夫して立ち振る舞おうと、十分に成長できない環境であるし、それを変えるのは現実的に不可能。
そう判断できたときは、最終手段を取る(逃げるとき)だと思う。さっさと逃げる。

Joyの追求

本書の最後の方には、信頼と『喜び』ということが書かれている。これをすなわちJoyと呼べると判断した。
HRT(特に信頼！)を踏まえたうえで、自社がお客様(ユーザー)に信頼されるようでないと、ユーザーが離れてしまう。
たとえそれが非常に現実主義的である行為によるものだとしても、顧客から納得を得られないのであればそれは『一時的な不誠実』となってしまう。
それがビジネスチャンスを失うものならば、ビジネスにおいて、(仮に短期的には正解になることがあっても)それは最終的には不正解になってしまう。
これは組織にもいえることで、エンジニアはどうせなら幸せに仕事したい(有意義で前向きに楽しいエンジニアリング = Happy Engineering!)であろう。エンジニアリングをした者が個人であれチームであれ、それは変わらない。
例えば、チーム内で、エンジニアリングと関係ない、いじめなんておきたら最悪。いじめたつもりでなくとも、いじめられたと思われたらそれはいじめである。いじめてしまった側は、HRTを改めて自分に当てはめないといけないときだ。
いじめなんて、精神衛生的にも、組織の健全性的にも、ビジネス的にも、誰も得をしないどころか損しかしない。
色々書いたが、『喜び』とはつまるところ、「エンジニアリングが楽しい！仕事が楽しい！ギーク心を揺すぶられる刺激がたくさんあって幸せ！」みたいな状態が『喜び(Joy)』であると思った。それは後の仕事に従事する『誇り』につながる。

ユーザビリティ

アプリケーションは、果たしてユーザーが使いやすいか？これはチームマネジメントとどう関係あるのか？と最初思ったのだが、
これは、チーム(ひいては会社自体)は、自社のアプリケーションの使い勝手を客観的に判断できていないといけないことを伝えたいのだと思う。
当然アプリケーションのレイテンシの悪化を防ぐべき(Googleが、「速度は機能だ」というくらい)、とかユーザ体験の指標は色々ある。
世のプロダクトを作る会社の中には、ここあたりが意外と忘れがちになって、ユーザビリティが低下したアプリケーションは割とある気がする。

怠惰であってはいけない

ここまで、HRTを意識する、エゴをなくすなど、本書の重要な点と思った点をまとめてきたが、
完璧主義になりすぎるべきじゃないからといって怠惰になって、努力を怠っては行けないと思う。
本書でも怠惰を悪とする書き方がされている。言い換えればスレーブ(奴隷)になるのかワーカー(労働者)になるのかということだと思う。
受け身になってただコピペしたり言われたことをハイハイ言ってやっているだけでは学校と何ら変わらない。ここは仕事場であって、能動的に主体性を持って自律的に業務にあたろうとすべきだ。
楽をすることは怠惰であることとノットイコール。

• 将来的に大きく楽をするために今努力をする
• 今楽をするためにタスク課題達成のためならどんなバッドハックもして良い

こういう違いが楽をしたい努力家か、怠け者かの違いだと思う。

結論

技術力は確かに重要だが、それ以上にチームの一員としてどう振る舞うかが、エンジニアの価値を決める。
『馬の耳に念仏』故に、『宝の持ち腐れ』にしてしまうなんて悲しいことがあってはいけない。
今後、私がチームマネジメントをするときは、一人ひとりがチームの一員として意識を持つことで、技術が真に価値あるものへと変わる。そんなチームにすることを目指していきたい。
チームマネジメントは技術力だけでなくコミュニケーション力も重要なので、将来チームマネージャーやチームリーダー職を志すにあたり、非常に有意義な知見になった。

〆

色々所感を織り交ぜながら自分の考え方に結びつけ、それを所感として書いたが、この記事で書いてあることを、他人に必要以上に押し付けたり(エゴ)するつもりはないし、あくまで本書を読んだうえでの「たしかにな〜」程度の所感を書き綴っただけであることを承知いただきたい。
またあえて、本書を読んだうえでのまとめと、私の所感を分けて記載しなかったが、それはちゃんと本書をぜひ読んでほしいと、読んでいるうちに思ったからである。
少しでも興味が湧いたならば、会社の書籍購入制度などの福利厚生を使うとかして、ぜひTeam Geekを読んでチームをよりよくしてほしい。