今年は「組織変革」「組織マネジメント」「育成」あたりをテーマにした発表をしたり，ポッドキャストで話をしているので，最近は「マネジメント関連」で相談や質問を受ける機会が増えている．一言で表現すると？みたいに聞かれたときは 「愛情のある無茶振り」 って答えてはいるけど，そもそも一言で表現できるようなものじゃない．
44 engineering management lessons
今まで紹介したことはなかったけど，マネジメントの参考にしている “44 engineering management lessons” という記事がある．本当に大好きな記事で，記事の存在を知った2年前ぐらいから定期的に読み直すようにしている．タイトルの通り，44種類の原則が紹介されていて，大きく7種類に分類されている．どの原則も参考になるけど，その中でも特に好きなものをコメントを添えて紹介したいと思う（翻訳するわけではない）．
- Do
- Don’t
- Motivation and culture
- Emotions and people
- Tiebreaking and conflict
- Difficult conversations
- Rough edge
Do
メンバーの得意な部分を伸ばし，苦手な部分にも挑戦させることで，常に成長できるように意識している．そのときに明確な上下関係を作らず「お互いに高め合う」雰囲気になるように工夫している．また，メンバーと話して成長が鈍化している原因がある場合は，それを取り除いてあげられるようなアクションをする．
1 . Attract, nurture, coach, and retain talent. Talk to engineers to tease out concerns early, then fix them if you can.
ファシリテーターとして，議論を活性化させるのもマネージャーの役割かなと思っているけど，議論が白熱し，全員の合意が得られず収束してしまうような場合は，別の視点の質問をして収束を打破させるようにしている．それでも合意が得られない場合は，最終的な意思決定をする．それを記事では「タイブレーカー」と表現していた．そのためには議論を客観的に俯瞰するスキルも必要になるし，マネージャーが決めたなら信じよう！と思ってもらえるような信頼をメンバーから勝ち得ておく必要もある．
3 . Be the tiebreaker when the development team can’t reach consensus.
様々な情報のハブになることを意識している．特に人脈のハブになることを目指していて「この技術を導入するならこの人にアドバイスをもらおう」など，技術的な情報交換が迅速にできるように工夫している．まさにこれは「トランザクティブ・メモリー」だと思っていて，組織が「ガラパゴス化」しないためにも重要だと考えている．
4 . Be the information hub. Know what every engineer is working on, and help connect the dots that wouldn’t otherwise get connected.
Don’t
マネージャーだからということはなく，ポジションの問題だとは思うけど，マネージャーをメインで担当していると，コードを書く機会がどんどん減り，そこに危機感を持った結果，優先順位の低いまま残っているバグ修正をしてしまうという経験は誰しもあるのではないだろうか？絶対にダメだとは思わないけど，それでコードを書いた気になってしまうのも良くないので，僕は意識的に気を付けている．むしろ，コードを書かないとしても，品質を高く維持できるようなコードレビューをしたり，バグ修正に着手する前の実装デザインを一緒に議論したり，インパクトを残せるアクションを選ぶようにしている．
7 . Personally fix bugs and ship features. You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end.
Motivation and culture
信頼残高を勝ち得るには，中長期的に成功し続ける必要がある．目の前のことに一喜一憂するのではなく，粘り強くアクションを起こすようにしている．
11 . Authority isn’t bestowed freely. It’s earned by making good decisions over time.
僕のチームは特に感じていると思うが，とにかく課題解決に対するアイデアは，メンバーに考えてもらうようにしている．考える機会はメンバー全員に平等に与えるべきだと思っているし，決定権もメンバーに与えている．そのときに個人的に意識しているのは「誰かアイデアありませんか？」と全員に問いかけるのではなく「○○さん，何かアイデアありませんか？」と期待値を込めて，名指しで聞くようにしている．そうすると，主体性を持ってアイデアを創出できるようになる．
12 . Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own.
Emotions and people
とにかく重要なのは「雑談」だというのは僕も同意で，世間話のような雑談でも，技術的な雑談でも，日頃から何でも話せる雰囲気を作るのはマネージャーの役割だと思っている．雑談の良いところは，論理的に話す必要がなく，思っていることを何でも気軽に話せるところにあると思う．また1人と雑談するのと，複数人と雑談するのでも意図が違うので，うまく使い分けられると良さそう．
20 . Most people won’t easily share their emotions. Have frequent informal conversations, and tease out everything that might be wrong. Then fix it if you can.
組織的な課題（ボトルネック）を常に客観的に探し，勇気を持って伝えるようにしている．メンバーが誰かしら気付いているのに言いにくいような課題もあるだろうし，メンバーが誰も気付いていないような課題もあると思う．さらに，多くの課題は価値観の違いによって気付かれないことがあるため，前提となる価値観を伝えて認識を合わせるのも必要だと思う．
22 . You’re paid to discover and fix cultural problems your team may not be aware of. Have the courage to say what everyone should know but doesn’t.
Tiebreaking and conflict
これは非常に重要なことだと思う．同じ結論になるとしても，マネージャーが決めるのと，メンバーが提案したアイデアを採用して決めるのでは，大きな差がある．実際にはメンバーが提案する方がインパクトが大きくなる．そのためにも，別の視点の質問をして議論を盛り上げる必要がある．何でもすぐに決めて進めてしまうと，結局メンバーは主体性を持てなくなってしまう．
25 . Don’t judge too quickly; you’re right less often than you think. Even if you’re sure you’re right in any given case, wait until everyone’s opinion is heard.
正直に言って，今までに経験してきたどの組織でも「あの人は苦手だから，あの人のアイデアは全て反対だ」という状況を見たことがある．人間はそもそも感情的なので，完全になくすことは難しいと思うが，頻度が高くなると，組織として何も機能しなくなってしまうので，チームを分割したり，辞めてもらったり，何かしらのアクションを起こすように気を付けている．また，好き嫌いだけではなく「技術的な信頼残高」に依存することも多いと思う．「あの人はバグを多く出すし，適当な性格だから，このアイデアはダメなのでは？」など．マネージャーは常に冷静に本質を見抜く必要があると思う．
29 . When disagreement gets personal or people don’t accept well-reasoned decisions, it turns into conflict.
Difficult conversations
難しい話を後回しにしてしまうというのは非常に良くわかる．ただし，状況をさらに悪化させる可能性もあるため，可能な限り早めに話すようにしている．また，そういうときに Slack や GitHub を使うのではなく，口頭で話すようにしている．日頃から雑談をしていれば，実は容易なことだが，雑談ができていないと，あえて Slack で情報を流してしまったりすると思う．
32 . Have difficult conversations as soon as possible. Waiting will only make a bad situation worse.
Rough edge
“Disagree & Commit” と表現することもあるが，個人的には「意志を表明すること」を重要視していて，さらにもし自分が反対したアイデアが採用された場合も，チームとして合意したのであれば，フルコミットで進めて欲しいと伝えるようにしている．議論の参加者が多いと「発言なし = 賛成」となるのに，ミーティングが終わって席に戻りながら不満を漏らしているメンバーがいたりもする．それでは議論の意味が全くないため，反対ならちゃんと意志表明をしてもらいたいし，どうしても言えなさそうなら，雑談を活用する．
39 . A firm “I’m not ok with that” is usually enough.
これも「意志を表明する」と似ていると思うが，常にニコニコする必要はなく，言うときは言う，感情を表に出すことは良いことだという雰囲気を作るようにしている．空気に流される必要はないと思う．関連して，よくある勘違いとして「チームの意思決定は多数決で行われる」というものがある．議論が本質的ではないと思ったら，空気に流されず「それは違うのでは？」と切り込む勇気を大切にしたいと思っている．
40 . Don’t laugh things off if you don’t feel like laughing them off. Have the courage to show your true emotions.
まとめ
“44 engineering management lessons” は，本当に参考になるマネジメントのバイブルで，定期的に読み直すようにしている．全部で44種類の原則があり，今回紹介しなかったものも多いため，是非一度読んでみてもらいたい．この記事はもっともっと有名になるべきだと思うし，僕の記事をキッカケに少しでも多くの人に届けば嬉しい．
（再掲する）
関連記事
前の部署で僕のメンターをして頂いた @waysaku の記事もとにかく最高で，定期的に読んで「あー，ここ全然できてないなー」と反省をしつつ，改善をしている．特に「喋りすぎなマネージャー」と「条件反射」は今もまだ完全に直せてなくて，司会をメンバーに任せたり，突っ込みたくなるのを5秒我慢したり工夫はしているけど，まだまだという感じ．頑張る！
