もりはやメモφ(・ω・ )

インフラなエンジニアからSREへ

Team-Geekを読んだ感想

twitterでオススメされたのがきっかけでこの本を読みました。@xinolinxさん、ありがとうございますm( _ _ )m

読んでひとこと

端的に言って素晴らしい本です。本当に読んで良かった。 世の中には人に勧めたい本とそうじゃない本がありますけど、圧倒的に前者の勧めたい本ですよこれ。

HRT(ハート)については、けものフレンズの関連で知っていたものの、そもそも「えっちあーるてぃー」と読んでいたくらいでした。 本書では三本柱であるHRTを中心にして人、チーム、組織、ユーザとのより良い関係性の構築についてウィットに飛んだ文章とあるあるな事例で学ぶことができます。

HRTの全てに通じる感

HRTとは以下の頭文字を組み合わせたものです。「痛みを和らげるからハートって読む」とありますが、とてもイカした呼び方ですね。

  • Humility(謙虚)
  • Respect(尊敬)
  • Trust(信頼)

本書では人間関係の基盤、あらゆるコミュニケーションの基盤としてHRTが非常に大切であること、そしてその実践が難しいことが冒頭の一章で記述されます。 そして「あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ」と定義し、ではどうやってHRTを実践して衝突を無くしていくのかを様々な場面を通して提示してくれます。

読み進めるうちに自分の中で拡大していくHRT

章の構成も秀逸で個人から徐々に組織へとHRTの適用範囲を広げていくため、「全部HRTでいけるね!?」というHRTの重要性がどんどん自分の中で高まっていき、だからそこ常にHRTを意識した行動を取るということが難しいという理解と、意図的に実践していかねばならないという意気込みが芽生えていきます。 参考までに全体の流れを書くと以下のような形です。

  • 一章:HRTについて個人での実践方法
  • 二章:良いチーム文化の作り方
  • 三章:良いリーダとしてのあり方
  • 四章:困った人への対応
  • 五章:組織の動かし方(下から上を効果的に利用する)
  • 六章:ユーザとの良いつきあいかた

僕の立場はいわゆる平社員で、リーダなんかとんでもない(と今のリーダのハードワークな状況を見て)思っていたけれど、チームが良くなるための行動は惜しみなく実践しようという意気込みは持っているつもりです。だから二章と三章を読んでリーダにとって良いメンバでありたいし、良いチームの文化を作るメンバになりたいと思えました。 そこへ四、五、六章がチームだけの事を考えてはいけない、チームの外にも目を向けてHRTを実践すべしと語りかけてくるので、目からウロコとなりました。

特に刺さったエピソード

読んでいて特に記憶に残ったエピーソードを備忘として取り上げます。

1.3 隠したらダメになる

「バス係数」この用語にやられました。プロジェクトのメンバーがバスに轢かれたとして、どれだけ耐えられるか?というブラックな係数ですが。ちゃんと共有することの大切さがストレートに伝わってきましたし、語感のやわらかさと意味のハードさのギャップがとても印象的です。

1.7 批判の配分と対応を学ぶ

ちょうど最近は業務の引き継ぎを行うことが多くなっていて、しかも相手が不慣れなメンバだったこともあり、ついつい批判しがちなコメントをしてしまう場面がありました。 この項では「相手に対する疑問ではなく、自分の疑問として謙虚に聞く」という文章が出てきて、なるほどこれはスマートだと得心しました。 これまで「本当にこれで合ってる?大丈夫?問題ないの?」と言っていたところを「僕はこれではXXXの場合に上手くいかないと思いますがどうでしょうか?」と置き換えるだけで、HRTをやれている感が出てくる気がします。これはすごい。ちゃんとやるように自分。

2.3 文化と人々

「チームのエゴはいいことだ、しかし個人のエゴは大惨事につながる」からの「(本書についての批判、レビューを無視したら)もっとひどかったと思う」で思わず笑いがでました。 僕としても批判やレビューをチームから貰うことがちょくちょくあり、その度にとても感謝しています(心が折れそうになることもありますけど)

3.5.6 正直になる

アンチパターンとして「褒め言葉のサンドイッチ」が上げられていて、自分が正にやっていたことだったので大反省した。これまで相手に伝わりきっていない感があったのはこのアンチパターンのせいだった可能性が高い。 要するに相手に注意とか改善点を伝える時に耳に心地よい言葉で挟むのはダメだということ。僕がやりがちだったのは

  • 褒める「なるほど、そういうやり方も良いですね」
  • 注意「でもxxxxの方法が早いし分かりやすいですよ」
  • そして褒める「とは言え、あなたのやり方も面白いといえば面白いですけど」

という言い方で、最終的に相手に残るのは「これは面白いやり方」ということになってしまっていたということ。だから今後は

  • 褒める「なるほど、そういうやり方も良いですね」
  • 注意「でもxxxxの方法が早いし分かりやすいですよ」

だけで止める。絶対止める。ついフォローしたくなるけど我慢しようと思います。

5.2.1 理想的なマネージャー

武士道なんてカッコいいものではないものの、僕はダメな意味での忠実さを表面的に持っていて、上司がXと決めたら多少不満があってもXを支持するスタンスでやってきていた。(そして我慢できなくなればその組織を去る覚悟でもいた) 上司というか誰もがそうだけど、納得いかないことに関してはちゃんと質問すべきだし、相手に察することを求める前にこちらから伝えにいくべきだって思えました。

5.4.3 上司の管理方法を学ぶ

この項は読んでいて少しショックを受けました。自分が上手くやっていることをキチンと上司に伝えるべしとあり、そこは納得できたのだけど、防御的な仕事に時間をかけても評価されないとあるからです。 僕はインフラエンジニアなので、プロダクト開発のような攻撃的な仕事はそうそう無いって思ってしまった。 なぜなら"運用"ってサービスができている正常な状態を守り続けることなので、もう完全に防御的なわけで、評価されないとかツラいとなったんです。 が、2度読み直して、そこは考え方の問題で、新プロダクトのためのインフラ設計とか、既存プロダクトの運用の中でもツール導入によるデプロイ時間短縮とか、要は見せ方が大事なんだなと思い直します。 この項で伝えたいことは「自分がうまくやっていることをちゃんと上司に伝える」ことですから。

6.1.2 小さく約束して、大きく届ける

リリース日を事前に発表するのではなくて、できてから発表することでユーザに驚きを提供するという話。 これ日本の会社も実践するだけで、デスマーチとか減るんじゃないですかね...(前職のSier仲間を思い出しながら)

6.2.1 観客を選ぶ

この項は他とは違って、少々苦々しいというか複雑な気分で読みました。というのも著者の二人がsubversion開発者だったこともあり、ちょくちょくsubversionのエピソードがでてくるのだけれど、この項はGitの複雑さに焦点をあてて反面的に使いやすさの大事さを説いています。でもほら、世の中のVCSデファクトはGitでほぼ決まりですよね。そういう意味でも味わい深い項でした。

6.2.4 速度重視

サービスのレスポンスが早いことは良いことだし、実際に利用ユーザ数への効果もあったというエピソード。 前の部分で「リファクタリングのような防御的な仕事は評価されない」とあったけど、リファクタリングによってアプリケーションの速度が上がるなら、それは攻撃的な仕事なんだってことだと思いました。

6.3.1 見下さない

とても分かりやすいHRTですね。僕は車の内部構造とかさっぱりな人間なので、自動車整備工の例えがとても分かりやすかったです。

6.3.2 我慢する

拷問にあっていたおばあちゃんのMacの話が最高すぎて他が吹っ飛ぶ勢いでした。

まとめ

改めてTeam-Geekという本に出会えたことを感謝します。HRTという言葉の深みを学ぶことができましたし、今この瞬間から意識的にHRT実践を開始したいと思っています。 特に得たものとして大きいと感じているのは、HRTという指標が自分の中にできたという点です。 今後も人なりチームなり会社なりと衝突することはあるでしょうが、険悪になったり傷ついた時に「こんな状態になっているのはHRTが欠如していたということだ、何が悪かったのだろうか?」という振り返りができるはずで、必要ならこのTeam-Geekを読み直すことができるのって最高ですよね(すべての答えが載っているわけないけど、振り返りの大きな助けになるはず)。 このような将来また読み直したいと思える本に出会えたことは本当に幸福なことです。勧めてくれた@xinolinxに改めて感謝です!

追伸

訳者の角 征典(かど まさのり)さんにも感謝したいです。全体を通してユーモアとウィットに飛んだ本だと思いましたけど、これ翻訳本なんですよ、すごいですよね!! で著書一覧を見たらあのリーダブルコードの訳もされている!やっぱりすごい人でした。他の本も機会をみて読ませて頂こうと思いました。