チームでの開発が続く中で、自分の振る舞いやチームの在り方にふと疑問を感じることが増えてきたので、オライリーの名著『Team Geek』を手に取ってみました。
本書は、単なる技術書ではなく、プロダクトやサービスを提供する「最高のチーム」を作っていくための心構えが詰まった一冊。大まかに6つの項目でまとめられていて、だらだらと長くないため非常に読みやすかったです。
今回は、個人的に刺さったトピックや日々の反省点を中心に、備忘録も兼ねてつらつらとまとめてみます。
1. コードは自分自身ではない：HRTとエゴからの脱却
まず出てくるのが、エンジニア個々人としてのあり方です。そこで掲げられている基本原則が以下の3つ。
- コードを隠さない
- HRT（謙虚・尊敬・信頼）を意識する
- 批判を恐れない
なかでも「大事なことなので何度でも言うが、君は君の書いたコードではない」という一文はちょっと響きました。自分の価値とコードを同一視してはいけないということです。エンジニアをやっていると、どうしても自分の書いたコードと自身の価値を重ね合わせてしまいがち。レビューでコードを批判されただけで自分自身を否定されたように感じて落ち込んでしまうのは、ちょっとコードに感情を込めすぎだったかもと。
さらに「人間関係の力を過小評価してはいけない」というのも痛いところを突きます。人間関係は確実にプロジェクトよりも長続きするからです。コードの議論で正論を振りかざしても、その後の出社で少しギクシャクしまうという経験、覚えがあります。
言うのは簡単ですが、実践するのは微妙に難しい。何でも個人プレーでどうにかしようとしてしまうきらいがあるので、ここは本当に襟を正したいところ。相手を尊重するということは、時には自分のエゴを捨てて考えを曲げる必要があるということ。頑固になりがちな自分には、なかなか耳が痛い話でした。
2. チーム文化の醸成：コミュニケーションと失敗への向き合い方
共通の文化を築くことで、同じ価値観を持ったエンジニアが集まり定着しやすくなります。だからこそ、採用の時点でも同じような性格を持ったエンジニアを厳格に選ぶべきだそうです。
素晴らしい文化を作る要素として、失敗への向き合い方も言及されていました。
- 「早い段階で、高速に、何度も失敗せよ」：失敗を適切に文書化（ポストモーテム）しておけば自分や他人が学習し、歴史を繰り返さずに済む。
心理的安全性を保ちながら失敗から学ぶこうした文化こそが、強いチームの土台になります。
そして「集中するには、やらないことを決めるべきだ」というのも見逃せません。ミッションステートメントを決めてスコープを制限することが重要だと語られています。これはdesign-docの考え方にも出てきますね、scope内と外を定めることで、設計や実装が進むべき道を示してくれ、さらにスコープが肥大化して収拾がつかなくなることを防ぐことができます。そしてそのチーム版がミッションステートメントということです。
これに関連して個人的に面白かったのが、コミュニケーション戦略についてです。
- 同期コミュニケーション（MTGなど）の人数を減らす
- 非同期コミュニケーション（チャット・メールなど）の人数を増やす
「とりあえず関係者全員呼ぶかと設定されたMTG」は、結局内職する人が増えるだけでシンプルに無駄。必要な人だけでMTGを行い、決定事項はチャットで大々的に告知する。オープンな情報共有こそが、各エンジニアが状況を把握して自律的に判断するために不可欠ということです。論理としてはすごく納得がいきますが、多分そういったMTGを開きたい人も偉い人の中に一定数いると思うので、難しいところもあるのでしょう。こういうところはトップダウンでどうにかしてください。お願いします。
3. マイクロマネジメントからの脱却：リーダーの役割
本書では、伝統的なマネージャーの役割はもはや時代遅れであり、チームに奉仕する「サーバントリーダー（執事や召使いのような存在）」であるべきだと強調されています。リーダーが管理すべきなのは技術的な側面とチームの人間関係であり、自らの手を汚して障害を取り除くのが仕事だと言うのです。
伝統的なマネージャーは「どうやって仕事を完了させるか」を考えますが、真のリーダーは「何ができるか」を考え、チーム自身に完了への道筋を考えさせます。リーダー自身がすべてを知っている必要はなく、障害を取り除ける「適切な人」を知っているほうがずっと価値があるんですよね。
マネージャーが陥りがちな罠として、明確な「アンチパターン」と「グッドパターン」が言語化されていました。
【やってはいけないアンチパターン】
- 自分の言いなりになる人を採用する：自分の役割への不安から、自分より身の丈に合った人を採用してしまうパターン。結果的にリーダーの指示待ちになり、リーダー自身が休暇すら取れなくなります。自分より優秀で、自分の代わりになる人を採用すべきです。
- パフォーマンスの低い人を無視する：「奇跡的に成長してくれないかな」と放置するのは最悪の対応。優秀なメンバーの時間を奪って士気を下げ、最終的には優秀な人がチームを去ってしまいます。早期対応が必要です。
- チームを子どものように扱う：これは「信頼していない」というメッセージを最もわかりやすく伝えてしまう行為です。信頼できる大人を採用したのなら、細かい干渉（マイクロマネジメント）は避けるべき。
【リーダーが目指すべき姿】
- エゴを捨て「禅マスター」になる：リーダーだからといって全知全能である必要はありません。ミスを素直に謝ることが尊敬を生みます。相談されたときはすぐに答えを教えるのではなく、「どう思う？」と質問で導き、メンバー自身に解決策を考えさせます。
- 触媒になり、目標を明確にする：プロダクト開発は「みんなで大きなトラックを引っ張る」ようなもの。全員がバラバラに引っ張らないよう明確なミッションステートメントを示し、組織の壁を取り除いて、リスクを取って失敗できる文化を作る「触媒」になります。
- 正直になり、幸せを追い求める：批判を和らげる「褒め言葉のサンドイッチ」は真意が伝わらないためNG。事実をもとに率直に、しかし思いやりを持って伝えます。そして「何か必要なものはある？」と質問し、個人のキャリアや幸福感を支援していくことが長期的な生産性に繋がります。
また、クリエイティブなエンジニアの生産性を高めるには、お金などの「外発的動機」ではなく、**「内発的動機」**を引き出すことが不可欠だと語られています。
- 自律性：細かく管理されるのではなく、大まかな方向性だけを与えられ「どうやってたどり着くか」を自分で考えて行動できること。
- 熟達：エンジニアのスキルはナイフのようなもの。定期的に研ぐ（学ぶ）機会がないと錆びついてしまいます。
- 目的：自分の書くコードが世界や会社にどう役立っているのかを実感できること。ユーザーからの感謝の声などを共有し、仕事の目的を示すのがリーダーの役割です。
「人は自分が扱われるように行動する」という言葉の通り、チームを子ども扱いすればそう振る舞うもの。だからこそ信頼して大人として扱うことが重要なんですね。これらは深く頷けました。
4. 悪意を見出すな：有害な人への対処
チームの文化を壊す「有害な人」に対処する章もあります。これもまた生々しい。意図的に文化を破壊しようとする悪人は稀で、多くは無知や誤解が原因だといいます。
具体的な対処法も簡単にできるかは置いておいて、実用的に見えます。列挙はしますが、説明はしにくいので具体的なエピソードトークは本を読んでみてください。
- 完璧主義者には別の方向性を示す：レビューなどの別タスクを任せて、感情を傷つけずに貢献させる。
- トロルにはエサを与えない：とにかく怒らせようとする相手には、ひたすら黙殺する。
- 不機嫌の真実を探る：トゲのある言葉の裏にも「有用な知恵」が隠れていることがある。感情をスルーし事実だけを抽出する。
一種のサバイバル術として覚えておきたいところです。
5. 理想と現実のギャップ：組織を操作する技法
もう一つ面白かったのが、巨大な組織を動かすテクニック。理想は全員が責任範囲を広げてマネージャーの負担を減らすことですが、現実は情報を出し惜しみする人やオフィス政治がはびこっています。
ここで飛び出す「許可を求めるより寛容を求めるほうが簡単」というフレーズが最高です。いちいち許可をもらうと「ダメ」と言われがちですが、会社にとって正しいことなら事後報告で進めろというわけです。
さらに「認知した者勝ち」という現実的なアドバイスも。防御的な仕事（リファクタリングなど）ばかりでは評価されないため、攻撃的な仕事と上手くバランスを取るべきだそうです。リファクタリングしがちな自分は少し反省します。悪いことではないですが、不利なことをしていたのかもしれません。
こうした現実を乗り越えるための実践的なハックも多数紹介されています。
- 親切の経済を回す：他人の仕事を手伝って「信頼貯金」を作っておく。
- コネクタと管理スタッフを味方にする：キーマンを絶対に怒らせてはいけない。
- 経営者へのお願いは短く：「3つの箇条書きと1つの行動要請」で徹底的に短縮する。
- いざとなったら逃げる準備（プランB）：強力な「選択肢」がある事実が、精神的な自由をもたらす。
割と実用的な考え方で、参考になりました。
6. すべてはユーザーのために：ユーザーファースト
最後の章ではユーザーとの関係性が語られています。端的に言えば「ユーザーに集中すれば、他のことはすべてついてくる」というユーザーファーストの精神です。
単なる精神論ではなく、以下のような具体的な指針が示されています。
- ユーザーではなく「利用」を計測する：ただのダウンロード数ではなく、実際に使っている「アクティブ数」こそが本物の指標。
- マーケティングの基本：「小さく約束して大きく届ける」こと。
- ユーザビリティと速度：システムにおける「遅さ（レイテンシー）」は致命的である。
ユーザーを見下さず、人間として接することで信頼貯金を積み重ねる。結局、システムを作るのも使うのも人間なんだと思い知らされます。
まとめ：やはり最後はHRTに帰結する
「最高のプロダクト」を作るためには、優れたコードを書くだけでは到底足りません。チーム内の人間関係や組織との立ち回り、そしてユーザーへの向き合い方すべてが不可欠だと思い知らされました。
特に「自分のコードと自分を同一視しない」ことや、HRT（謙虚、尊敬、信頼）の原則は、すぐにでも意識していきたいです。頑固になりがちな自分を戒めつつ、読了の勢いそのままに明日からの仕事に取り組みたいと思います。
