『Team Geek』読んだ ~HRT(謙虚/尊敬/信頼)の精神を知り会社でサバイブしていく方法~

かの有名なHRTの精神の原典になっている本ということで読んでみた。

内容紹介

読む前の印象としてはHRT精神ということでどんなエモい内容が書かれているんだろう…と期待していたのだがとんでもない、めちゃくちゃ実践的で（誤解を恐れずに言うと）、狡猾な内容が書かれていた。

本書では「人間は複雑でありバグの塊」という身も蓋もない前提事項を明確にした上で、「ではそんなバグバグでダメな人間とどう向き合っていけばよいか」を具体的に記載している。

また本書の面白い点は、会社内でうまく立ち回るためにときに社内政治・ソーシャルエンジニアリングさえも行う必要があると説かれている点だ。こういった活動はおよそソフトウェアエンジニアとは程遠いスキルのように思われるが、本書ではしっかりと言及され社内でどううまく立ち回っていけばよいか説明されている。

HRT

HRTとは謙虚（Humility）、尊敬（Respect）、信頼（Trust）のそれぞれの頭文字三文字をとった言葉だ。読み方は「ハート(heart)」というらしい。それぞれの用語を解説する。

謙虚（Humility）

世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善しよう。

尊敬（Respect）

一緒に働く人のことを心から思いやろう。相手を一人の人間として扱い、その能力や功績を高く評価しよう。

信頼（Trust）

自分以外の人は有能であり、正しいことをすると信じよう。そうすれば仕事を自分以外の誰かに任せることができる（ただし無能な人には任せるのは難しい）。

あらゆる人間関係の衝突はHRTの欠如によるもの

そして本書では下記のように言い切っている。

あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ

つまり人間関係が悪化している場合、それはあなたもしくは誰かが「謙虚ではない・尊敬の念を持っていない・信頼していない」ことから生じていると考えてよい。

コードレビューとHRT

私見だが特にエンジニアのコードレビューの場面においてこのHRTの精神は大事にすべきだと考えている。

GitHubなどのコードレビューツールの台頭によりコードレビューが圧倒的にしやすくなった反面、文章によるコードレビューは容易に人の心を傷つける。具体的にはコードに対する批判を人に対する批判（人格否定）だと受け取ったり、文章だと感情が伝わりづらく何気ないレビューコメントが「怒ってそう」「高圧的で怖い」などと受け取られたり…。

コードレビュー時には上述したようなすれ違いが起きないように、なるべく気をつけてHRTな振る舞いをするようにしたい。僕がレビューのときに気をつけていることとしては下記のことだ。

• 絵文字を使う😃
  • 絵文字を駆使して感情を伝える。フレンドリーさを演出する
  • その結果感情の誤読は減り、コミュニケーションはより活発になる
• 断定口調は使わない
  • 「〜のほうが良い」「〜はダメ」という断定は自分が間違っている可能性を否定しているので 謙虚さ に欠ける
  • 「〜のほうが良いと思っているのですがどうでしょうか」などと相手の反論の余地を残してやるべき
  • なにか断定したいのであれば少なくともレビュイーが納得できるに足る理由を上げるべき
• 命令ではなく提案
  • 「〜に変更してください」という命令は相手のコードを 尊敬 していないし 信頼 していないように聞こえる
  • 命令でなく「〜と書いてみるのはいかがでしょう？」という提案に形式を変えてみるとよい
  • 断定同様にきちんと理由も述べる
• 強い言葉を使わない（弱くみえるぞ？）
  • 「クソコード」などの強い言葉は使わない。相手への 尊敬 が全くないのでNG
  • 強い言葉を使いたくなるような場面だとコードレビューでのすれ違いが起きる可能性が高いので口頭でカバーするのが吉

有害な人間と付き合う

第四章のトピックは 有害な人に対処する だ。本章では「チームの文化を破壊するアウトサイダーから身を守る方法」について説明される。

有害な人への対策

下記のような手段でチームの文化を強固にしておけば、有害な人の有害な振る舞いを受け入れにくくなる。

• ミッション・ステートメント の作成
  • チームの目標を明確にする
• メールで議論するときの マナー を決める
  • OSSでいうCode of Conduct的なもの
• すべての 履歴を文書化
  • 新参者が履歴を追えるように
• バグ修正・テスト・リリースについて 明確なポリシー・手続き を策定
• 合意ベースの決定 を信頼する
  • あわせて合意できなかったときの衝突解消のプロセスも定義する

有害な人のパターン

有害な人のパターンとしては下記のパターンが存在する。

• 他人の時間を尊重しない人
  • プロジェクトの文書、READMEを読めばわかることを何度も質問して邪魔する
• エゴが強い人
  • 合意を受け入れられない人・異なる視点の意見に耳を傾けない人・妥協できない人
• 何かを要求する人
  • ソフトウェアに対して不満はいうが、貢献する気のない人の可能性がある
• 未熟なコミュニケーションをする人
  • 草を生やしまくったり(wを多用すること)、大文字や記号を多用する
• パラノイアな人
  • 被害妄想を持ち、陰謀論を唱えるような人
• 完璧主義な人
  • ソフトウェアの設計に時間をかけすぎる人
  • チームの進捗を停滞させてしまう

有害な人を追い出す

本書では最終的に有害な人は追い出してよいと述べている。もちろん最初からではなくきちんとコミュニケーションをとった上でそれでも問題が解消されないようであれば、最後の手段としての＜追い出し＞だ。

社内政治、ソーシャルエンジニアリング

5章は組織的操作の技法がトピックであり、「仕事を効率的に進めるための小手先のテクニックが必要」だと述べられている。小手先のテクニックとはつまり 社内政治、ソーシャルエンジニアリング のことである。

社内政治という言葉はエンジニアの対極にある慣習のように思えるし、あなたがエンジニアであれば「社内政治なんてとんでもない！」と思うかもしれない。しかしときにそういう手段も必要だとハッキリ説いているのが本書の面白いところと言える。

自分の価値を高める

自分の価値を高める振る舞いとして下記のような振る舞いが紹介されている。

• 自分の責任範囲を広げる
  • マネージャーの作業負担軽減になる
  • 自分自身の能力を示すことができる
• リスクをとる
  • すばやく失敗してすばやく学習する
  • 失敗したら何が起きたかを文書化して再発防止策に努める
• 大人らしく振る舞う
  • マネージャーから子供扱いを受けないために
• 質問する
  • 納得できないことがあれば根拠について質問したり議論する
• マネージャーはエスパーではない
  • 自分が何をしているかをマネージャーに報告する
  • マイクロマネジメントの回避策にもなる

自分が居心地のいい場所を作る

平たくいうと「組織がクソなこともある。組織に期待せず自分でよい組織を作るという意識を持て」ということが書いてある。

会社にはルールがある。曲げてもいいものもあれば、ぶち壊していいものある。組織のなかで振る舞うべきことばかりに集中していると、不満や失望を感じるだけだ。組織はそういうものだと認めよう。組織を動かして自分の仕事に利用できる仕組みを見つけよう。自分が居心地のいい場所を作り出すのである。

自分を売り込む

自分を売り込むという行為もまたエンジニアらしからぬ行為のようにも思えるが時には必要だ。つまりうまくやっていることを上司やチームの外部にいる人たちに知らせるということだ。

それを演出するために＜できるだけ約束を小さくして、届けるものは大きくする＞という手法が紹介されている。大きな約束をしてしまうとその締切を守れなかったときや、機能を落としたときの信用損失が大きくなってしまうからだ。

またエンジニアはプロダクトのローンチにエネルギーを注ぐべきだとも説かれている。なぜならプロダクトローンチというイベントが何かを成し遂げたことを伝える一番わかりやすいイベントだからだ。リファクタリングをもっとやりたいと考えるかもしれないがそれだけではダメで、そこに半分以上時間を割いたりしたら何も評価されないし最悪プロジェクト中止さえありえる。

逃げるという選択肢

「すべてやっているけど改善されないしうまくいかない」そんな状況に陥ったとしたらさっさと逃げてしまうことが得策だと言う。

システムを変更できなければいくらエネルギーを注いでもムダだ。そこから逃げ出すことにエネルギーを注ごう

ある程度やって無理なものは無理、ダメなものはダメ、さっさと逃げる！と割り切っている点も本書の潔くて良い点である。

チームはパンのようなもの

本書ではチームはパンであるという比喩が使われる。

チームの文化はサワードウパンのようなものだ。スターター（創業者）がパン生地（新来者）に菌（文化）を植え付ける。イースト菌と乳酸菌（チームメンバー）が発酵（成長）すると、おいしいパン（チーム）のできあがりだ。

強い文化を持つチームを作る必要がある。さもないと新来者が持ち込む文化に負けてしまう。チームが文化を大切にできなければ、チームのアイデンティティや仕事の誇りを失ってしまう。

この話は日本風の喩えでいうと＜腐ったみかん＞の話に通ずるものがある。一つ腐ったみかんがあると他のみかんも腐ってしまうという事象である。そうならないために腐ったみかんを紛れ込ませない、あるいは多少腐ってしてもそれが伝播しないような強いみかん（チーム）である必要がある。

強い文化を作るには時間・労力がかかる。会社においては応募者がカルチャーフィットするかを面接のプロセスにおいてチームのメンバーが評価・判断し決める。採用を妥協してはいけない。

マネジメントについて

本書はマネージャーのためのマネジメント本ではなく、なんとなくリーダーになってしまったエンジニアのための本だと位置付けられている。

マネージャーになるべき！？

本書では「エンジニアはマネージャーになるべきだ」と主張しているのは興味深い。

一般的に言ってエンジニアはマネージャーになりたがらない。一番の理由はコードを書く時間が少なくなるからである。そして無能なマネージャーの下に就いたことのあるエンジニアもまたマネージャーになることを拒む。しかし本書では下記のように説く。

マネージャーになるべき大きな理由がある。まずは自分自身をスケールできるからだ。コードを書くのが得意だとしても、一人で書けるコード量には限界がある。自分がリーダーになって、優秀なエンジニアのチームにコードを書いてもらえば、どれだけのコード量になるかを想像してみてほしい！

サーバントリーダーの役割

マネージャーになるのであれば サーバントリーダーになるべき だという。つまり執事や召使いのようにチームに奉仕するのだ。サーバントリーダーのやるべきことの例は下記だ。

• HRTの雰囲気を作り出す
• エンジニアでは対処できない社内の障害物を除去
• チームの合意形成を支援
• 問題解決を支援する
  • アドバイスを求めてきたらリーダー自身が問題解決してはダメ、あくまでもサポートのみ
• マイクロマネジメントをしない
• 夜遅くなったときに差し入れ
• チームが順調に進めるように穴を埋める
  • ときには自らの手を汚す
• 技術的な側面とチームの人間関係を管理する（後者が難しい！）
  • 技術畑出身のリーダーは後者を無視しがちだがそれはNG、きちんとチームの人間的側面に目を向ける
  • みんなのお友達になるのもNG、あくまでも仕事の関係を保つ

リーダーはパーフェクトではない

リーダーはパーフェクトでなければならないという強迫観念があるかもしれないが、それを本書は否定する。

リーダーはなんでも正しくやって、すべてを把握して、あらゆる質問に答える責任があると思っている。すべてを正しくやる必要はないし、あらゆる質問に答える必要もないし、そんなことをしていたら逆にチームの信頼を失ってしまう。

質問を歓迎してチームからのフィードバックと批判をオープンに受け止めよう。そして何かを失敗したときは心から謝罪しよう。

またリーダーが適切な答えを知っている必要はない。適切な答えを持っている人を知っていて、その人を紹介できさえすればよいのだ。多くの場合、適切な答えを知るより、適切な人を知るほうが価値がある。

参考資料 (Podcast): Engineering Managerをスーパーマンだと思わないで by EM . FM #EMFM • A podcast on Anchor

（ネガティブ）フィードバックを正しく伝える

正直になるのもリーダーをやる上で重要だ。

1on1などの場面において共有できないことをメンバーから質問されたら「知っているけど伝えられない」と答えれば良い。自分がわからないことを聞かれたら素直に「わからない」といえばいい。

ネガティブ・フィードバックを伝えるのは難しい。フィードバックや批判を伝えるときはメッセージが正しく相手に伝わっているかが重要だ。しかし直截的な伝え方だと相手に受け入れてもらえない場合があるので、きちんと適切な言い方を考えてから伝えよう。

一方でチームメンバーの欠点ばかりを気にしていいところを十分にフィードバックできていないケースも気をつけよう。素晴らしいところは積極的に知らせてあげるべきだ。

リーダーの行動指針

その他にもリーダーが取るべき行動指針として下記のものが紹介されている。

• チームの幸せを追い求める
• 委譲せよ、ただし手は汚せ
  • たとえ自分がやったほうが早くてもチームメンバーに任せる
• 自分自身を置き換えるくらいの優秀な人を採用する
  • チームメンバーに代わりをしてほしいのであれば自分より優秀な人を採用する
• 事を荒立てるときを知る
  • 状況は自然とは良くはならない、きちんと指摘する
• カオス（不確実性）からチームを守る
  • リーダーになるとメンバーの頃には見えなかったカオスが見える。メンバーをそのカオスから守ろう
• チームを空中援護する
  • 会社の上空（上層部）で何が起きているかをチームに知らせる
  • できるだけ多くの情報をチームに共有すべきだが、チームに無関係の組織の話はする必要がない
• どのエンジニアが何を必要としているかを把握してそれを与える
  • エンジニアが何を欲しているかは一人ひとり異なる

まとめ

HRT（謙虚・尊敬・信頼）の精神を知るためにまずは手にとって読むべき本が本書である。

HRTの精神に加えて、本書には「有害な人に対処する方法」「社内でうまく立ち回る方法」など会社で＜サバイブ＞していくための極めて実践的な内容が書かれていた。HRTだけでなくそういったスキルもときに必要であり重要であるということを認識するのに、本書はすべてのエンジニアにオススメの一冊に仕上がっている。