Engineering Manager として大事にしている7つの事

この記事は、Magic Moment Advent Calendar 2023 21 日目の記事です。

こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている 木村 (@ryurock) です。

4日目では、SRE Engineering Manager Role として「SRE を立ち上げた4ヶ月後の世界」を投稿させていただきましたが、本日は Senior Engineering Manager として大事にしている7つの事。
というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ

Engineering Manager として意識している7つの事 その1 「エンジニアとしてよりも前に人として見る」

マネジメント職になるとエンジニアとしてどうなるべきか？のキャリアプランに頭が向きがちになると思いますが、エンジニアとしてよりも前に人として、Magic Moment の社員として見ます。

• その人が Magic Moment の社員として正しい行いができているか？
• その人が Magic Moment の社員として素敵なのか?
• その人が Magic Moment の社員として成長できているか？

等です。

Magic Moment では Impact Level という社内の評価基準があるのですが、名前の通りで、人や部署、その他の部署にどれだけ Impact が与えられるか？
という評価基準があります。

そこには人としての振る舞い等も記載されており、この Impact という言葉が今までの評価基準の名前の中で一番しっくりきています。
仕事は影響力が大きい人ほど、仕事の価値が高いと思っています。

人として輝いている人は、エンジニアであろうとなかろうとやっぱり素敵です。
Engineering Manager というと特別なマネジメント職のような錯覚に陥ったりしますが、人を育てる。

という文脈の最終形態は人として素敵な人材になること。
だと思っていますし、私はそんな人と一緒に楽しく働きたいな。とも思っています。

Engineering の前に人として素敵になること。これをとても大切にしています。

Engineering Manager として意識している7つの事 その2 「人をなるべくマネジメントしない」

マネジメントの最終形態は、マネジメントをしない事だと思っています。
自発的、能動的に動ける人材を大量に育てられる Engineering Manager は最強だと思っています。

だからと言ってメンバーを放置している。という話ではなくて、権限移譲を意識しています。

Magic Moment では、開発チームは基本 スクラムの Framework を利用して開発をしていますが、スクラムの理論の適応にも権限移譲が触れられています。

プロセスのいずれかの側⾯が許容範囲を逸脱や成果となるプロダクトが受け⼊れられなかったときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。
それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。
関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。
スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。

つまり、権限移譲を意識的に行わないと、スクラムの目指す最終的な姿の「自己管理」ができなくなるからです。

育成という観点で Magic Moment の開発チームでは 5 つの軸で見ています。

• Project Management
  • プロジェクトを遂行するにあたっての必要最低限の能力
• Product Management
  • プロダクト価値判断を見極める為の必要最低限の能力
• People Management
  • 人を育てる為の必要最低限の能力
• Engineering Management
  • 技能・技工の必要最低限の能力
• Human Management
  • エンジニア組織外とコミュニケーションを行うための必要最低限の能力

この 5 つの指標を元に、デリゲーションポーカー の権限移譲レベルを意識しながら、普段の 1 on 1 等で会話をしています。

1. 指示する ：管理者として意思決定を行う
2. 売り込む ：意思決定についての人々を納得させる
3. 相談する ：決定する前に、チームからの意見を得る
4. 同意する ：チームと一緒に決定を下す
5. アドバイスする ：チームによる意思決定に影響を及ぼす
6. 問い合わせる ：チームの決定後のフィードバックを求める
7. 移譲する ：特に影響を及ぼさずチームに任せる

Engineering Manager として意識している7つの事 その3 「空気をマネジメントする」

上で人をマネジメントしない。と記載しましたが、空気の違和感を感じ取り、マネジメントとして違和感の正体を探ることを意識しています。

だいぶ前になりますが、スクラムマスター研修で Odd-e の江端一将さんの研修で今でも心に残っている言葉

スクラムは組織論と集団心理学に基づく方法論でありプラクティスではない

この言葉が今でも強く残っています。

私の解釈ですと、集団心理というのは、その場の空気に出てきます。
その空気の違和感というのは、中々思っていても言えない事が多いです。

特に大人数がいる中で、嫌な空気を感じ取って素直に言うことは難しいものです。
一方で、マネジメントとして敢えて、嫌な事を言わなくてはいけない事もあります。

空気、雰囲気を放っておくと、やがてその空気が淀みます。
嫌な空気は誰も吸いたくありません。

一方で良い空気に見えて実は悪い影響を与えていることがあったりします。

この空気という見えないものを嗅覚で感じ取り、マネジメントすることを意識しています。

Engineering Manager として意識している7つの事 その4 「How になるべく介入しない」

自立心を阻害する要因として、How に対する介入があると考えています。これをすると、やがてその人の自尊心が失われ、能動的な行動から、お伺いを立てるようになります。
いわゆるマイクロマネジメントというものです。

• なにかをやりきった
• なにかに失敗した

この達成感や学びが経験として反映されると思います。

この時に、失敗させないように良かれと思って、How に対して細かく口を出すのではなく、リスクマネジメントの視点で見ることを意識しています。

大きな失敗は、当人へのダメージも大きいですし、また組織としてもダメージが大きいです。
一方で、失敗の積み重ねが成功への一番の近道だと思っています。

重要なのは、眼の前にある石ころが大きいか？小さいか？ダメージが大きいか？小さいか？で小さい石ころは、どんどん背中を押して転ばせることです。

皆さんもあると思いますが、その石ころに転んでいる時の記憶が一番残ります。
ですが、時間が経つと「あの時は大変だったけども、面白かったな」みたいな感覚があるはずです。
一方で大きい石ころ、いわば壁のようなものは「あんな事は二度と経験をしたくない」と。

どうやるか？はなるべく口を出さずに、その時のチームやメンバーの状況を鑑みて、転んだ時にかすり傷で済むか？骨折になってしまうか？
かすり傷ならば背中を押してあげる。という事を意識しています。

Engineering Manager として意識している7つの事 その5 「ピンチはチャンス」

プロダクト開発をしていると、様々な問題が発生します。

• 仕様が間違っていた
• 納期に遅れそう
• etc........

こんな時に思わずチームも下に向きがちになります。
しかし、上記でも言及しているとおり、痛みは一番記憶に残ります。つまり、痛い時が一番色々な状態や物事の本当のボトルネックを改善するチャンスでもあるのです。

失敗は反省する必要がありますが、後ろを常に向いても状況は変わりません。
最終的には前を向くしかないのです。

この本当にヤバい時に私は、口癖のように呟きます。
「ピンチはチャンス」、「ピンチはチャンス」と。

この魔法の言葉は、チームが転んだ時に立ち上がらせてくれる魔法の言葉です。

ピンチになった時は、この言葉で自分に暗示をかけて全力でチャンスに変換するように心がけています。

Engineering Manager として意識している7つの事 その6 「良い守備から良い攻撃ができる」

これはサッカー日本代表の森保監督の言葉から拝借しています。

キャリア的に SRE という守備ポジションの仕事を長くやってきた経緯もあると思いますが、考え方としては良い運用・保守で手離れの良いシステムを構築することで、新規施策等に安定的にデリバリーができると思っています。
ただ、DF を多く配置すると、攻撃の部分がおざなりになるので、組織としては、新規ビジネスチャンスを掴む事ができません。

なので、ボールを取られたら、すぐに奪い返せる状態 = リカバリー対応パターンを増やして、攻めにすぐ戻れる状態を維持する。
今は守るべきか？攻めるべきか？

今、運用・保守にコストがかかっていて、ボールが自ゴール前付近で停滞していないか？
一方で攻めなくては行けないのに、リスクを警戒してパス回しをして、時間をムダに消費していないか？

という「攻めと守備のバランス」を意識しています。
エンジニアリングにおいて良い攻撃のサッカーは、ショートパスの連続(小さくデリバリーをして)でゴール(スプリントを達成する)出来る事だと思っています。
(サッカーわからない人には伝わりにくい表現かもしれなくてすみません)

Engineering Manager として意識している7つの事 その7 「楽しめる環境を提供できているか？」

仕事においての楽しみ方は千差万別です。

• 自分のペースで成長を感じて楽しみたい
• もっともっと厳しい環境下で成長を加速させて楽しみたい
• Enginnering をガッツリやりたい
• グロースハックに燃えたい

どの意見も良い・悪いで括ることはできず、正しいです。

相反するような楽しみ方をそれぞれの人に提供できているか？二項対立で物事を考えないようにする事を大切にしています。

マネジメントをやっていて常に思うことは、マネジメントに答えを求めても答えがなくて、その状況と状態だけがあること。
状況・状態・人によって

• Engineering Manager としての引き出しをどれだけ多くもっているか？
• Engineering Manager としての引き出しを増やす努力をしているか？

これがご機嫌で楽しめる環境を提供する責任があるマネジメントの責務ではないだろうか？と思っています。

仕事において楽しさは必要なのか？という考え方もあると思いますが、人間の本質は感情で動くものであり、私達が提供しているサービスも感動したり、嬉しい。という感情的な要因でご利用していただけると思うと
サービスの作る側にも楽しさを求めても良いのではないか？と思っています。

最後に

いかがでしたでしょうか？
書いている内にポエム感が出てきてしまいました。(笑)

Engineering Manager 難しいですが、楽しいですよ。
という雰囲気を感じ取っていただければ幸いです。

明日のアドベントカレンダーは <Sh00_U>> の 「開発健全性(生産性ではないよ)のメトリクスを設計して運用してみた」 です。