はじめに
この記事は Engineering Manager Advent Calendar 2021 の14日目の記事です。記事作成の作業日がのっぴきならない事情で潰れたため、14日の27時になってしまいました。すみません。
今エンジニアリングマネージャーという職責を持って働いております。今年の自身の仕事のテーマとして「権限委譲」がありました。そこで取り組んでいたことについて描けたらと思っています。
なぜ権限委譲をするのか
自分がいなくても進む状態
エンジニアリングマネージャーになった当初プロダクト開発のスループットを安定させるためにスクラムについて勉強をしていました。スクラムマスターについての理解を進めていく中で「スクラムマスターの最終的な目標は自分が必要なくなることだ」という言葉と出会いました。
スクラムマスターはスクラムが機能するようにいろいろな活動をします。スクラムマスターの活動によってだんだんチームの動きが良くなっていくとスクラムマスターがやらなければいけない仕事は減っていき、やがてスクラムマスターがいなくてもチームが自律的に活動できるようになります。スクラムマスターは自分の仕事がなくなることを目標にチームを改善します。
話が権限委譲から離れてしまいましたがエンジニアリングマネージャーの権限委譲もこれに似たところがあるように感じています。エンジニアリングマネージャーになってからより強く感じるようになったのは「自分がいなくなってもいつもと変わらず動くチーム作り」でした。
より抽象度の高いタスクを取れるように
エンジニアリングマネージャーのお仕事は人との接点が多く、油断するとMTGだらけになったりするのではないでしょうか。何をするにも時間との戦いな側面があります。そして差し込みでやらなければいけない仕事が入り、進捗に乱れが発生してしまう…ということは皆様ご経験済みかと思います。つまりはエンジニアリングマネージャーはいくらか暇であるように配分しないと良いパフォーマンスが出ないのではないかとよく思います。
さらに働いていて気づくことは、上長は更に多忙で難易度・抽象度の高いタスクを抱えている可能性が高くその仕事を委譲してもらい楽にできるのはエンジニアリングマネージャーしかいないのでは？と。したがって、まずは自分の体を空けなければいけない。ぐぬぬ。という感じです。
メンバーに裁量を増やしてもらう
エンジニアリングマネージャーにとって自分の仕事を自分のボールのまま持ち続けてしまうのは、もしかしたらメンバーの経験機会の損失になってしまっているのではないか？とよく考えます。自分が手を出した仕事がメンバーの機会を奪っていないか？というのは自分に対してよく立てる問いです。
環境によって状況は異なるかと思いますが、基本的にはいろいろな仕事をしてもらえる信頼があること、それを実現可能な技能の深さがあることに給与という対価が払われている側面があると思います。
チームメンバーの給与を上げていくことはマネージャーにとって頑張っていきたいトップ項目であるので、担ってもらえるお仕事をお願いし判断や意思決定の幅を広げてもらえることはお仕事を楽しんでもらう意味でも重要と考えています。
エンジニアリングマネージャーの権限委譲
じゃあ実際に権限委譲をどう考えていくかというところですがもう少し自身のことに寄せて書いてみます。自身の仕事の権限委譲を考えるとパターンが分かれます。
権限委譲を考えるときの分類
- 自分がやらなくてもいい
- 自分がやらないといけない
- やらなくていい
マネージャーと言う名前がつく職種に当てはまるかもしれませんが、チームの中では自分と同じ仕事を分担する先がないことがしばしばあります。チーム内では分担できるものと分担できないものがあったり、同じ組織内に他のエンジニアリングマネージャーがいない場合組織的なタスクの分担には苦労するのではないかと思います（幸い近い立ち位置のEMがいるため日々助かっています）。
それぞれの分類について書いていきます。
自分がやらなくてもいい
この分類の仕事はエンジニアリングマネージャーのものではあるが、他の人にお願いしても問題ないものです。ノウハウが個人に蓄積していたり、何らかのコストが高かったりでメンバーにお願いするのが躊躇われる為、エンジニアリングマネージャーの仕事になっている可能性があります。自身の例で一つ上げると結構前のカジュアル面談の担当はこれにたりました。
自分でなくてもできる仕事という分類なので、工夫し他の人でも担えるようにすべきです。一つはあなたが急に何らかの理由で働けなくなったときにこの仕事は宙に浮くか手がつけにくいものになっているはずだからです。
暗黙知であれば共有知にし、負荷が高ければ負荷を下げる工夫をし（型化するなど）分散可能な状態にしておきたいものです。
やったことの例
- カジュアル面談で普段話している内容を動画にして配布した
- カジュアル面談の資料やトークスクリプトをまとめて共有した
自分がやらないといけない
この仕事は職責にたいして依存した情報・権限があるものが該当します。例えば評価・査定などはこれに当たるかもしれません。1on1などもこちらに近いかもしれません。こちらは”自分がやらなくてもいい仕事”のように誰にでもお願い可能なものではありません。自分がこの仕事ができなくなったときのことを考えると「この仕事を変わってもらえる可能性」について考慮する必要があります。
場合によっては共有知にすることが難しいかもしれませんが、例に上げた評価・査定であれば（会社で方法論が確立されていなければ）自身の中で型に落とし込んでいく作業がいつか自分の身を助けるかもしれません。
やらなくていい仕事
こいつは型化したり、やらなくていいように仕組みを作って全力で潰そう…
エンジニアリングマネージャーの輩出
「自分がやらないといけない」をどうするか
自分がやらなくてもいい仕事に関してはうまくパスすることでお仕事としてお願いすることが可能です。問題は自分がやらないといけないものについてです。
ここが権限委譲をどうしていくかの中心課題になると思っていて、端的に言えば新しいエンジニアリングマネージャーを輩出できるかという課題です。これは「なぜ権限委譲をするのか」とつながるテーマと考えています。
適正のある振る舞いのある人
エンジニアリングマネージャーという職は楽しいところもたくさんあると私は感じながら、一方ですべての人に興味を感じてもらえるものでもないのを感じます。逆に苦手意識を感じているという話をしてくれる人もいます。
私が適正を感じる人は
- 俯瞰しながら具体と抽象を行ったり来たりするのが得意
- チームが気持ちよく活動できるような働きかけが得意
- 対立する両者をフラットに傾聴して自身の判断を作れる
- チームのメンバー&一緒に働いている人からの信頼が厚い
という振る舞いをもっている気がします。
しかし書きながらこれは成果を出してくれる開発者にも当てはまるふるまいだな…とおもって難しい…と感じたり。
「チームを後方からサポートして成果があがることに喜びを感じてもらえるか」や「興味がある」っていうのが大事なような気もしてきます。
委譲の階段
上記のような興味を持ってくれるメンバーと出会えた！となっても「じゃあ明日からエンジニアリングマネージャーね！」とはならないので委譲をするときの階段について考えなくてはいけません。
これは進行中の話
自社ではエンジニアリングマネージャーもテックリードも個人開発者もキャリアのパスがあるため、興味を感じてくれている人もコミュニケーションを取りながらキャリアパスを考えています。以下に書くのは興味や必要性を感じてくれている人と一緒に考えている進行中の階段になります。最終結果はどこか機会があれば書いてみたいです。
1段目：チームリード
こちらはエンジニアリングマネージャーの興味に限らず、チーム開発をリードしてくれるとよりスループットが上がりそうな人にお願いをしています。開発のレポートラインを担ってもらったり、プロダクトマネージャーとの会話など必要に応じて開発メンバーを代表してコミュニケーションを取ってもらっています
2段目：チームリード + メンタリング
チームリードの役割にプラスして1on1をしてもらっています。これは現場メンバー同士での対話でチーム開発の改善やコミュニケーション回数上昇による信頼醸成を狙っています。メンバーはこれとは別にマネージャーとも1on1を行っています。
3段目：サブマネージャー + 評価作業サポート
ここからはかなりエンジニアリングマネージャーの仕事を体験してもらう段階になります。実際に体験をしてもらい実際にエンジニアリングマネージャー担ったときのイメージを掴んでもらう意図があります。権限の問題がない部分に関しては開示し段階的にかなり近いところまで体験してほしいと考えています。
上記のような階段を1.5年-2年のスパンで見ながら考えています（場合によっては期間はもっと短かったり長かったり）。このあたりは自身で組み立てているものなので、エンジニアリングマネージャーを排出している経験のある方にぜひ知見をいただきたいと思っているところです。
さいごに
今年のテーマとして取り組んでいた権限の移譲について考えているところを書き出してみました。型化されていたり抽象化されている知見とまでにはまだなっていないのですが、エンジニアリングマネージャー的には結構大事な課題かと思っているのでその課題感の表出と自分の思考整理を兼ねて書き出してみました。
思うところがある方ぜひお話できると嬉しいです。