エンジニアリングマネージャーとして意識していること
これは CAMPFIRE Advent Calendar 2022 1日目の記事です。
はじめに
こんにちは、岩崎です。もう12月ですね、年々一年が早くなっていきます。
気づけば、私がエンジニアリングマネージャーになってから2年以上が経ちました。エンジニアリングマネージャーになった当初は、自分には向いていないけど良いチャレンジになる、他にやりたい人がいないのなら、チームのために新しい人が来るまでの繋ぎで頑張ろうという気持ちだったのですが、最近は意外と向いているかもしれないと思い始めています。もちろん大変なことも多いですが、エンジニアリングマネージャーという職種はそれだけ魅力の多い仕事でもあります。
一方で、エンジニアリングマネージャーに関する情報はネット上にあまり多くはありません。マネジメントは人間同士の話なので、きっと技術の話と違って軽々しくネット上に書きづらいのだと思います。それはとてもその通りだと思います。
これがマネジメントについて書くことのジレンマでもあります。人間が相手の仕事なのであまり具体的なことは書けない一方で、かといって抽象的な一般論に終始してしまうと、面白みがなく特に得るものもない文章になってしまいます。だったら始めから何も書かなくてもよいということになります。
けれど、今回思い切って自分なりのエンジニアリングマネージャー論について書いてみようと思います。もちろん一定の配慮は必要ですが、もしかしたら新米エンジニアリングマネージャーの役に立つかもしれないと思うからです。私自身まだまだマネージャーとして修行中の身なので、偉そうに自らのマネジメント論を書くのはおこがましいのですが、年に一度のアドベントカレンダーということでご容赦ください。
エンジニアリングマネージャーのしごと
ちょうど同じタイトルの書籍がありますが、エンジニアリングマネージャーの仕事は多岐にわたります。一例を挙げると、メンバーとの日々の1on1や評価、採用、組織づくりなどです。そしてこれらのアプローチに正解はありません。なぜなら人間には正解がないからです。今回書く内容も、あくまで私という非常に限られた人間にとっての良いと思われる振る舞いにすぎません。
水を運ぶ人
私はエンジニアリングマネージャーとは「水を運ぶ人」であると考えています。今はちょうどワールドカップの時期ですが、この「水を運ぶ人」というのは元サッカー日本代表監督のイビチャ・オシム氏の言葉で、「あまり目立たないが、献身的に守備を行い、相手からボールを奪って味方（水を飲む人）をサポートする人」を指します。いわばチームにとってなくてはならない黒子のプレーヤーです。
エンジニアリングマネージャーは普段あまり目立つ存在ではありません。チームがうまくいけばメンバーのおかげ、うまくいっていないとしたらマネージャーの責任です。エンジニアリングマネージャーが目立っておらず、常にメンバーにスポットが当たっているとしたらそれは良い状態といえます。逆になんらかのインシデントが発生したときは、矢面に立ってチームを守り、解決に向かって取り組む必要があります。
嫌われ役になる
エンジニアリングマネージャーは時には言いにくいことも言わないといけません。もし短納期の案件が急に差し込まれることが日常化していたら、しっかり文句を言って改善してもらいましょう（なぜそうなるのか教えてもらい、一緒に解決策を考えるのも吉です）。それによって一部の人たちから嫌われてしまったとしても、メンバーの代わりに言いづらいことを言うのも大事な仕事です。モウリーニョのように過剰に外部に対して攻撃的な物言いをすることでチームの結束を高めるのはやりすぎですが、上司や他のチーム、そして時にはメンバーに対しても言うべきことは言う勇気が大切です。
ミーティング
エンジニアリングマネージャーはメンバーに代わって様々な調整役を引き受けるため、常に多くのミーティングに出ています。それに加えて、メンバーとの信頼関係を構築するため、メンバーに対しても時間を割いて丁寧にコミュニケーションを取ります。一見ミーティングばかりで全く生産性のない仕事のように見えますが、もちろんそんなことはありません。エンジニアリングマネージャーが常に多くのミーティングをこなしているからこそ、メンバーはエンジニアリングに集中でき、またメンバーに時間を割いているからこそ、いつも見ている人に気軽に相談することができるのです。そしてマネージャーにとって重要なミーティングの最たるものが1on1です。
1on1
1on1はエンジニアリングマネージャーにとって非常に重要な活動です。私は最重要と言っても過言ではないと思っています。前述の「エンジニアリングマネージャーのしごと」にも「1on1は、マネージャーとしていちばん重要な定期活動の1つです。どのくらい重要かというと、1つの章全体を割くほどです。」とあります。
私は初めてメンバーと1on1する時は、以下のように伝えることにしています。
「この1on1の目的は、あなたに幸せになってもらうことです。会社としてあなたに長く働いてもらいたいと思っていますし、もちろん私もそう思っています。もし気持ち良く働く上で不安なことがあれば、どうしたら良いか一緒に考えさせてください。また、この1on1は100%あなたのための時間です。マネージャーのための時間ではないので、進捗確認などは行いません。あなたが話したいことを話す時間として使ってください。」
マネジメントが人間活動である以上、1on1にももちろん正解はありませんが、私は上記のようなスタンスで行っています。
アンチパターン
よくあるアンチパターンとして、1on1がメンバーではなくマネージャーのための時間になっているケースがあります。この場合、1on1は主にマネージャーが進捗を確認するための時間に使われ、もしマネージャーの想定と外れていた場合はメンバーに弁明が求められます。もちろん進捗確認は大事な作業ですが、これではメンバーは気軽になんでも話せなくなってしまうでしょう。もし困っていることがあればいつでも打ち明けられるように、メンバーのケアのための1on1と、進捗確認や評価面談は分けることが重要です。
また、マネージャーが好きなテーマについて雑談して終わりという1on1も私はアンチパターンだと思っています。同様に、1on1はメンバーのための時間だからです。マネージャーが好き勝手話して「あー、楽しかった」というのは少し違うのではないかと感じます。メンバー主体でマネージャーも楽しく会話することができたなら、それはもちろんOKです。
1on1と信頼関係
私が1on1でよく使っているテンプレートは以下の通りです。
前回の振り返り
最近どうですか？
不安なこと、気になること
50%は成長できる仕事にあてられているか（SREのみ）
将来のキャリアについて
今の仕事で改善できそうなところはありますか
私に期待することはありますか
最初の3つ（SREの場合は4つ）は毎回話しますが、残りについては様子を見ながら取り上げて話しています。また、テーマについては私の方で用意しつつ、メンバーにも自由に記載してもらっています。「50%は成長できる仕事にあてられているか」というのはSREでいうトイルの考え方ですが、SRE以外でもトピックとして取り上げても良いのではないかと感じています。
1on1はメンバーのケアが目的なので、基本的に非難や説教はしない、常に寄り添って一緒に考えるというスタンスを大切にしています。せっかく勇気を出して相談してもらっても、否定してばかりだと相談されなくなってしまうからです。
私はきちんとした信頼関係さえあれば、究極的には1on1はなくてもいいと思っています。相談したい時に適切に相談できることが重要なのであって、日常的にSlackなどで気軽に相談できる関係性が築けているのであれば、定期的な1on1の必要性はそれほどないともいえます。それでも1on1を行う理由は、時間を割いて1on1を行う行為が「メンバーのケアが最も重要である」というメッセージになるからです。
逆に言うといくら毎週1on1していても、信頼関係がない状態で行う1on1はメンバーにとって苦痛でしかないでしょう。
評価
1on1がエンジニアリングマネージャーにとって最も重要な仕事だとすれば、評価は最も困難な仕事であるといえるでしょう。評価とはメンバーに対して強制的に線を引く行為であり、非常にセンシティブな問題です。仮にマネージャーがメンバーのことを評価していたとしても、評価結果をメンバーが評価されていないと受け取れば、メンバーとマネージャー、ひいては会社との間に亀裂が入る可能性だってあります。例えば、素晴らしいパフォーマンスを出している優秀なエンジニアが、月に数千円の昇給を評価されていると受け取るかは人によって異なるでしょう。
私は評価と昇給は表裏一体であり、同時に別の文脈で語られるべきものであると思っています。もし評価していると言いながら、市場価値と乖離した年収状態が続けば、メンバーとしては評価されていないと感じてしまうでしょう。一方で仮に評価していたとしても、様々な事情により昇給が実現されないケースだってありえます。
私が評価面談の時に大切にしていることは、メンバーに対してしっかり向き合うことと、感謝を伝えることです。
メンバーと向き合う
私はエンジニアなので、メンバーと評価面談する際は、基本的にメンバーが実装した全てのプルリクエストに目を通すようにしています。こうすることでメンバーの成果をコードレベルで把握できますし、成長も感じることができます。同じエンジニアのレビューが入った評価は、メンバーにとっても納得感があるはずです。
また、一見目立たない取り組みも同等に評価するようにしています。これは例えば、当初の目標設定時にはなかった差し込み業務や、他のメンバーのサポート、運用業務などが該当します。こうした仕事は一見地味ですが、チームにとっては非常に重要な仕事だからです。
感謝を伝える
評価面談で過去数ヶ月を振り返った時に、良い結果を残せた人もいれば、残念ながらうまくいかなかった人もいます。しかし、たとえ良い結果を残せなかったとしても、彼らの努力に対して敬意を払わなくてよい理由にはなりません。もし目標を達成できなかったメンバーがいたとすれば、それはうまく導くことのできなかったマネージャーの責任でもあるからです。その場合、彼らの日々の仕事に対して感謝しつつ、マネージャーも一緒になってどうすれば改善できるかを考える必要があります。
逆に自他ともに認める良い結果を出したメンバーに対しては、マネージャーは昇給できるように努力しなくてはなりません。マネージャーはメンバーの代表なので、マネージャーの上司に対して、なぜ昇給が必要かを真摯に伝える義務があります。そして仮に希望通りの昇給が叶わなかった場合は、なぜ実現できなかったかをメンバーに対して説明する責任があります。
アジャイル型評価
私は、今の時代は、例えば半年に一回の面談で全てを評価するウォーターフォール的な評価より、より短くイテレーションを回し、日々コミュニケーションを取りながら目標に対して軌道修正していくアジャイル的な評価の方が適切であると考えます。昨今の変化のスピードが速い環境に対して、従来の枠組みで評価することは難しいからです。今は半年の間に取り組むべき重要な問題が変わることは普通ですし、またメンバーにしてみても、半年ぶりに出てくるよくわからないお偉いさんより、日々コミュニケーションを取っている人に評価してもらいたいと思うでしょう。
採用
採用もエンジニアリングマネージャーの仕事としてイメージされるものの一つです。会社やチームが必要としている人員をリファラルや市場から獲得します。
採用において私が重視しているのは技術力とチームフィットです。たとえどんなに技術力があったとしても、チームメンバーをリスペクトすることができない人は残念ながら縁がなかったと思っています。もちろん逆も然りで、いくらカルチャーマッチしていたとしても、技術者としてチームが求める水準に達していなければ受け入れることは難しいかもしれません。
とはいえ、多くの場合私たちはそれほど偉い立場にあるわけではありません。Googleのようなビッグテックでない限り、採用の場は基本的に対等であり、会社も候補者もお互いに選び選ばれることになります。私は採用面談において大切なのはこの対等であるという意識と、仲良くなることだと思っています。
採用面談において大切なこと
もし採用する側が自分たちを上位だと見なしていたら、きっと候補者の粗探しをするために一方的な質問に終始してしまうでしょう。仕事をしながら嫌々対応する面接官だっているでしょうし、カジュアル面談を選考と勘違いしてうっかり志望理由を質問してしまうかもしれません（残念ですが、このような振る舞いは候補者にとってもラッキーです。ありがとうございました。それではさようなら）。
当たり前ですが、私たちは対等なのです。お互いにリスペクトを持って、誠実に接することが大切です。こちらから質問したら向こうにも質問してもらいましょう。アイスブレークで雑談から始めるのもいいかもしれません。候補者になるべくリラックスして打ち解けてもらうのも面接官の仕事です。常に逆に自分が候補者だったらどういう面談がいいだろうと想像しながら話してみてください。
候補者が話しているときは真剣に耳を傾け、共感し、仮に耳の痛い質問があったとしても誠実に答えます。逆にこちらが話すときは会社やチームの魅力を思う存分自分の言葉で話しましょう。私はカジュアル面談はアトラクトの場であり、候補者に自身の言動から社内を想像してもらう場であると考えています。責任重大ですし、いつもうまくいくわけではありませんが、上記のような気持ちを心掛けていると案外うまくいったりします。
私はカジュアル面談がうまくいったかどうかは最後に仲良くなれたかどうかだと思っています。会社関係なく、一人の人間として友達になれたと思ったならきっとその面談は成功です。
もう一つの採用フィールド
採用というとついつい外ばかりに目がいってしまいますが、同じくらい中で働いているメンバーのことも大切です。
採用あるあるですが、新しく外から採るメンバーには簡単に高給を出す一方で、中で働いているメンバーはなかなか給与が上がらず、会社やチームのことが好きなのに給与が理由で退職してしまうケースがあります。
これはお互いにとって不幸でしかないですし、仮に中の優秀なエンジニアに辞められてしまっては昇給させる以上の採用コストがかかってしまうため、不必要な退職は未然に防ぐほうが理にかなっています。
もし本当は退職してしまうはずだった優秀なエンジニアを運よく引き止めることができたなら、それは外から優秀なエンジニアを一人採用するのと同じことになります。
組織づくり
組織を作るとは、同時に文化を作ることです。組織を作る際に一定のカタはあっても良いですが、いきなり外から独自の文化を持ってきてもなかなかチームには浸透しないでしょう。無理に文化を移植した結果、チームが崩壊する危険性もあります。文化づくりは一朝一夕にはいかないため、時間をかけることが大切です。
私が組織を作る時に意識しているのは、自分のスタイルを持ちつつも、チームに合わせて柔軟に運用することです。なぜなら、チームはマネージャーのものではなく、チームのものだからです。例えば、頻繁にミーティングを行うことがマッチしているチームとそうでないチームはあります。前はこれでうまくいったからと、そうでないチームに対して高頻度のミーティングを強制すれば、結果としてチームメンバーのパフォーマンスを損ねる可能性もあります。チームを作る時は、チームメンバーの特性を見極め、どうしたらこのメンバーで最高のパフォーマンスが出せるかを考えます。
大切にしていること
チームを作る上では自発性とHRT（謙虚、尊敬、信頼）を大切にします。マネージャーがトップダウンで指示を出すスタイルよりも、メンバー自らが主体的に課題を見つけて行動し、支え合うチームの方がスケールすると考えるからです。そのためには、常に発言しやすい雰囲気作りと非難しない文化が重要です。適切な批判や議論は歓迎ですが、過度な非難はチームを萎縮させ、挑戦しないことを是としてしまいます。
私の例を挙げると、発言しやすい雰囲気を作るために分報や朝会を活用しています。分報は本来その時々の作業進捗を記載するチャンネルですが、Twitterのような個人チャンネルとして活用している組織も多いのではないでしょうか。大勢の人間がいるチームチャンネルで発言するのはハードルが高いですが、自分の分報なら発言しやすいケースは多いと思います。特にリモートが一般的になり雑談の機会が減った今、積極的に分報で雑談するようにしています。
また、朝会も発言する場として有効に活用しています。スタイルとしては一人一人が「昨日やったこと」、「今日やること」、「困っていること」、「良かったこと」などを話し合う、よくあるアジャイルの朝会形式ですが、一人一人が毎日発言する習慣をつけることで、ちょっとした相談をしやすくしています。
非難しない文化については、障害発生時のポストモーテムが代表的な例として挙げられます。これは元々はSREのカルチャーですが、ポストモーテム以外にもSREの組織論から学ぶことのできるプラクティスは多いです。
委譲！委譲！委譲！
プレイヤーからマネージャーになると、意識的に仕事を任せていかないと自分自身がボトルネックになってしまいがちです。もし自分がボトルネックになっていると思ったら、コードを書きたい気持ちをグッと堪えて自分にしかできない仕事をしましょう。コードを書くことは他のエンジニアでもできますが、メンバーをケアすることができるのはマネージャーであるあなただけです。
仕事を任せる時は放り投げるのではなく、まずある程度カタを作ってから権限ごと委譲します。その際にもし自分のやり方を変えられたとしても、気にせず信頼して任せましょう。そして助けが必要な時はいつでもサポートしてあげてください。仮に権限や仕事が委譲されても、ある種の責任は残り続けます。
振る舞いとメッセージ
私はチームメンバーと接する時、この振る舞いはどういうメッセージとして伝わるだろうかとよく考えます。マネージャーはどうしても一つ一つの言葉が重くなってしまうので、マネージャー自身が意図しない振る舞いになっていないかを定期的に確認することが大切です。ジャストアイデアで言ったことをやらないといけないと思われたり、気軽に飲みに誘ったつもりでもメンバーにとってはプレッシャーになってしまうこともあります。
例えば、既にリーダーのような働きをしてくれているエンジニアがいる状況で何の相談もなくリードエンジニアを募集したら、彼（彼女）は傷ついてしまうかもしれません。こちらが全く意図しないところで「私は評価されていないから新しいリーダーを募集するのか。なら退職しよう」と思われてしまう可能性があります。
別の例で退職者の情報はネガティブなので、退職直前までチームには秘密にしていたとします（実際に、私は同じチームで働いていた同僚の退職を当日に知らされた経験があります）。そのような振る舞いをすると、「引き継ぎもあるのに、私たちには共有する価値がないと思っているから共有しないのか。仲間として信頼されていないのかな」と思われてしまうでしょう。
私は体調が悪いときは正直に言い、無理せず休むようにしているのですが、これは同時に皆さんも辛いときは正直に言って休んでくださいねというメッセージでもあります。
もしチームメンバーにしてほしい振る舞いがあるのであれば、まずはマネージャーが率先して行う必要があります。他人に対して優しく振る舞ってほしいと思えば、まずマネージャーがそうするべきですし、感謝してほしいと思ったら自分から感謝しましょう。個人的に日々の挨拶や感謝には特に気をつけています。間違ってもスルーしたり、冷たい印象にならないように！
おわりに
以上、自分なりのエンジニアリングマネージャー論をつらつらと書いていたら思いのほか長くなってしまいました。
自分がここに書いたことを全て実践できているかというと、正直至らない部分もあるとは思うのですが、こうありたいという気持ちも込めて改めてまとめてみました。少しでも誰かの参考になれば幸いです。
今年も無事アドベントカレンダーが始まり、明日からクリスマスまで素晴らしいメンバーたち（とCEOひとり）による記事のリレーがスタートします。ここからは私も一読者になって純粋に楽しみたいと思います。最後まで読んでいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？