エンジニアマネージャーの職務で気をつけていること

はじめに

フューチャー Advent Calendar 2022 の1日目です。明日は@NikkelyさんのSAMを利用したLambda(Function URLs)デプロイの記事です

フューチャーに入って13年目くらいになると、複数チームをマネジメントするような職務を期待されることも増えてきました（ジュニアが多い別チームのメンターも買って出るなども含めて、立ち位置が変わりますよね）。

設計コードレビューを除き、実務的にコードを書くのは2,3割といった具合で、2,3チーム兼務で必要に応じてマネジメントする時の気をつけていることをまとめます。

ビジネスレベルのディレクションレベルで戦略/方針を考えることは稀で、開発現場のマネジメントが中心といった具合です。3~6人チーム×2とか、3~6人チーム×3とかの規模感の話で、どれもカッチリと要件定義して固めに開発というよりは、トライ＆エラーで課題や要望をドリブンに探索的に試行錯誤しながらエンハンスしていくようなフェーズが前提です。

エンジニアマネージャーとは

エンジニアリングマネージャーのしごと | O'Reillyによれば、エンジニアマネージャーの成果は以下の式で測れるそうで、開発チームにおいてそういった職務職責にある人がエンジニアマネージャーにあると思います。

マネージャーのアウトプット = 
  あなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット

マネージャー全般に言えることだと思いますが、マネジメントの役割はチームの生み出す成果、価値を最大化することで、この記事ではこれを行う人をエンジニアマネージャーとします。

個人的成果、成長を至上命題とせず、チームにフォーカスを当てる、ジュニアエンジニアから徐々にステップアップして、マネジメントロールに入った人が戸惑う（不安になる）最初のポイントがこれだと思っています。

気をつけていること

1. 1on1はがんばる一択

• ありとあらゆるマネジメント系の書籍に言及がある気がしますが、特にリモートワークの場合は、1on1をやらない選択肢はもはや無い気がします
  • 30分/回。メンバーからするとマネージャーが自分のために時間を確保して、実施すること自体に意味がある
  • 間隔はオンボーディング期間（新規参画から2~3ヶ月）は1週間単位
  • 言うことが無くなってきたら、隔週～3週間ごと、月次などに変える
• 延べ20回/月 くらいから別次元でしんどくなってきます
  • 階層化しても良いと思いますが、それでも月次は守った方が良いかと
  • 逆に評価ルート外の人は間隔を空けるなど、調整しても良いかもしれません
• よく行う質問事項例
  • 「今、私に話したいこと、モヤモヤしていること、考えていることってありますか？」
  • 「業務やプライベートでもなんでも、困っていることとか、ヘルプしてほしいことってありますか？」
  • 「最近、成長実感があるタスクを抱えていますか？」
  • 「コンフォータブルゾーン、ラーニングゾーン、パニックゾーンの3つの立ち位置があったとすると、今どこにいますか？」
• 1on1を行うことはマネージャーにとっても成長
  • おそらくメンバーの方がフレッシュな感性を持っているので、精神的に大人になります（大人にならざるをえないというか..）
  • 人は1on1を通してリーダーとして磨かれるかなと思います
  • 扱う対象がヒトなので、愚直に深く、数をこなすと器が広がります

私は1on1を週次で行う是非については当初否定的でしたが、新規参画者向けにはやったほうが良いという心境に変わりました。チームやプロダクトの過去の経緯や、暗黙的になっている規則などをあぶり出すことにも繋がりますし、その時間で講義的な事を行うこともあります。これを怠ると結局メンバーレベルでの助け合いになってしまい、それ自体はどんどん推進したいことですが、スケジューリング的には不安定要素になります。

2. 採用

• 会社全体への採用活動へのコミットは超重要ですので、自分、チームメンバーともに最優先させます
• チームへジョインさせるかどうかも、必ず面談します
  • その時、直接業務で関わるメンバーは必ず入れるようにします（断っても良い旨や、他の新規参画の候補者もどれくらい出てきそうかも、言える範囲で伝えます）
  • カルチャーフィット、スキルセットのマッチ度は重要です
    • 主体的に学べるか、口だけではなく実行力はあるかなど、現在のスキルセットよりは潜在能力を見ると良いかと思います
  • 妥協して良かったことは無いです（同じ会社かつ別チームからの移籍であれば、前チームの評判も聞くのが良いでしょう）
• 最初は誰であろうと1,2ヶ月はパフォーマンスが出ない覚悟で、後悔しないようにします
• エンジニアリングマネージャーのしごと | O'Reillyによれば、50%の時間を採用に使うそうです。まじかよ

3. タスクの進捗を上げたい時

• 開発チームでうまく回っているようで、進捗が上がっていないと思ったときは観察、原因分析します
• スコープ調整がうまくデキていないとき
  • 踏み込んで調整を巻き取る（特に要件調整は慣れた人がやるほうが早いことがあります）
• 開発方針や設計仕様が決めきれない
  • エンジニアマネージャーがここを抑えられていないとまずい（説明責任を果たせない）ので、一緒になって進めます
  • たたき台を作り、有識者、利害関係者を集めガット決めます。生煮えの場合は、まず前提条件、制約、データパターンなどファクト整理から支援します
• メンバーのモチベーションが下がってきている
  • 1stリリースが終わり安定稼働してくる＋保守運用モードになると、特に技術的な好奇心が強いメンバーがマンネリしてきます
  • 技術面においては、どこかでオーバーエンジニアリングして、新しい風を入れる工夫を入れます
    • ランタイムのアプリの技術要素を変えるのはかなり大きな判断だと思いますが、運用可視化ツール、自動化、自動生成、CI/CDなど、監視運用リリース周りは変えられる面も多いはず
  • 既存のリファクタリング
    • ある程度うまく回っているので、中途半端に構成を変えないで欲しいと思っていても、若いメンバーの視点からみるとツマラナイ仕事と映ることも多いです
    • ある程度ではなく、もっと良い設計手法を考えて（一緒に15分でも考えるとなお良い）、徐々に進めていけると、そのコードベースのオーナーシップが高まります

4. なんだかヤバそうな空気を察し、放置せず、深掘りして、調整する

• 直感が大事である
• なんかヤバそうな空気の例
  • 「仕様を詰めていないのに、開発に入っている」
  • 「開発が落ち着いていないのに、テストしようとして言る」
  • 「機能追加でスイッチ用のフラグが安易に追加されようとしている」
  • 「システムテストされていないものがリリースされようとしている」
  • 「データ移行、業務移行が考慮されていなさそう」
  • 「本番データを一部のメンバーの判断で更新しようとしている」
  • 「差し込みタスクがあったはずだが、開発スケジュールの調整が無い」
• 今の状況を把握して、やるべきことをやれていない場合は対応し、必要があれば自らスケジュールや優先度を調整します

5. 評価

• 例えば、Pull Requestやコミットしたコード量で把握することは困難です（明らかに突出していたら別かもですが）
  • 困っているメンバーのヘルプは非常に重要ですし、1stペンギン的なタスク、予測困難な技術検証など、比較できないタスクが多いです
• 基本的には1on1で相互に合意すること次第。どういうことを目標にするか話し合い、期待値のすり合わせで決めます
  • 何ならできるか、どこまでやれそうか、やって欲しいことと、やりたいことの集合を部分をなるべく大きく取ります

6. 気になることは起票する

• チームメンバーへ移譲するとしても、気になる荒い点は色々見えてきます
  • アレコレ、口だけ出すのはダサいので、ドキュメント修正やtypo修正やら、構成変更などできる範囲は自分でやってしまうのが良いでしょう
  • それすら時間が取れなさそうなら、Slackでコメントするだけではなく、Backlog（GitHub Issueでもなんでも）にとりあえず起票することがおすすめです
  • やるべきリストがスタックしていると、ジュニア向けの良い教材タスクになります
    • 数週間～週ヶ月以上先に効果が出てきます
  • タスクを認識できているかが重要です
  • メンバーにとって、目の前のタスク以外のTODOを追加すると、情報過多でパフォーマンスが落ちるので、後で見返しやすい状態を作ってあげるほうが、パフォーマンスを維持しやすいです
  • 起票するときは、なるべく内容を丁寧に書きましょう（Slackのコメントやスレッドのリンクを貼るのも良いでしょう）
• 思ったより自分の発言を重く受け取られる ので注意する
  • （もしかすると、1周り年齢が違う？ 自分が入社したばかりのときの年次差を想像してみる）
  • 「これは無視しても良いですが～」とか、「これは意見の1つですが～」などの枕詞はかなり大事。言わなくても伝わるだろうという、ハイコンテキストに頼るのはダメ

6. リーダーを増やす

• 自分の分身を増やす（xxxさんの分身を増やしてください） というフィードバックは最悪だと思っていた
  • コレ自体は未だにアンチパターンだと思います
• これは、 任せる ということ
  • 簡単そうだけど、難しい
  • ガイダンスして、1on1でコーチングし、質問に答え、フォローする（メンバーの進め方が悪いとこっそり教えたり、ヤバそうなら巻き取ったり）、エグゼクティブ向けの報告はまだ早そうなら代替して、できる部分のみを任せる
  • 丸投げとは違う
• 「エンジニアマネージャーの仕事」に丸投げと移譲について言及がある
  • 説明責任と実行責任の差
    • 説明責任は、タスクが求められる品質で完了させる責任を持つということ
  • 実行責任は、実際に行うこと

7. プロブレムマネジメント

• プロジェクト・マネジャーが知るべき97のことに、プロジェクトマネジメントはプロブレムマネジメントとあります
  • 全くもって、そのとおりだと思う。最低ラインの話ですが
• 基本的には、予防・防火に務める
  • 「4. なんだかヤバそうな空気を察し、放置せず、深掘りして、調整する」もプロブレムマネジメントの枠組み
  • 放っておくと、大体のケースで火が吹くので、チケット起票状況やミーティングに参加し、嫌な空気があったら解きほぐす
  • 1on1もそれらを検知する手段の一つです

8. ダメージコントロール

出火がゼロに越したことはないですが、完璧な現場は存在しないもの。大なり小なり何かしら問題が出ると思います。

• 焦らず、二次災害にしない
• 被害は受け止める（名誉、信頼を犠牲にするかもですが、受け止める）
• ピンチはチャンスだと思う
• エスカレーションする。悪い報告を最初にする。どうするしか無いか伝える。どう復旧させようとしているか伝える
  • 時系列で伝える。文章。図をなるべく利用する
• 怒らず。冷静に。焦らず、でも急ぐ
• ホットな状態なのかどうか。ほっとすぎると冷却が必要。後々もっとホットになりそうなら急ぐ
• 反応はすぐ返す（チャットの場合は不安になる

ダメージコントロールという言葉を使うと、被害ゼロにはできないという意識に切り替わるのでお勧めです。何か悪いことが起こったときに、これを隠せないかな？といった思考を潰せます。

9. 埋まるカレンダー

• 前日（朝）に空いていたはずのカレンダーがあったとしても、気がついたら埋まっていくものです
  • 飛び入りの認識合わせ会議、レビュー依頼、どうしても今日までに要件を決めたい会議の延長、課題対応、外部調整の巻取、不穏な空気を感じたので調査、ヒアリング、etc.
• 仕方ない..レバレッジを効かせるために工夫をするしかない
  • 飛び入りの認識合わせは仮説を用意してスピードアップ
  • レビューはサンプリングする
  • 要件については骨子を渡して移譲できないか
  • 課題対応は、、仕方ないでしょう
  • 外部調整の巻取は、、、レールを整えて（ジャブうちだけして）あとは任せるなど
  • 不穏な空気を感じたときの踏み込みも、、仕方ない

10. 会議の決定事項サマリメモは自分から

• 会議で話したことのサマリメモは自分から（も）共有します
  • 箇条書きレベルでOK
• 定例などは、議事録をジュニアメンバーの教育に任せていることも多いと思いますが、スポットの方針ぎめ会議などはそうでないケースが多いと思います
• メンバーに書いって頼むのも良いでしょうが、自分で共有すると認識齟齬が減りますし、何よりリーダー自身の記憶定着に有効です
  • 話した内容を毎回忘れてくるので、毎週（毎月？）、会議が始まると議論がゼロスタートになる人、嫌ですよね
  • 記憶力、結構大事です
  • 書くと忘れにくいです（当社比）
  • ついでに、チケット起票までやると喜ばれます（他のマネージャーと差別化にもなるかも）
• 無論、何かしら課題があるメンバーに、教育目的で書いてもらうのはありです

11. めっちゃ褒める

• 良いことをしてくれたとか、メンバーが成長したなと感じたら褒めます
  • タイムリーに、気がついたらすぐ褒めることがポイント
    • マネジメントが褒める≒チームとして目指すことのカルチャーになる
  • この仕事が向いていると感じてもらう
    • 適切な成長実感を持ってもらう
  • 逆に厳しいことばかり言うと、向いていないと思われる
• 自分が助かったら褒める
  • xxさんのコードがきれいで助かった。xxさんの書いた手順で助かった、xxxの理解を深めることがデキたなど
  • 具体的に、細かく褒める。良いことは良いこと

12. 改善点は素直に伝える

• 1on1の場でも良いが、ホットなうちに伝えたほうが個人的には良いと思います
  • チームの外との会議での立ち振舞のアドバイスはすぐに伝えましょう
• 重い話であれば、1on1など他のメンバーがいない、しっかり話せる場で話しましょう

13. 自分のエネルギーをマネジメントする

• 会議続きで疲弊することも多いと思います
  • 無理せず
  • 常に自分がベストパフォーマンスを出せるように、休む。休む
  • 休めるように、パフォーマンスが出せるように、タスクやスコープは調整する
    • そのためにも、タスクの移譲は自分に余力があったとしても常にどんどん進められる範囲で進める
• エネルギーは一定である
  • やるき（MP)の総量は残念ながら増えないと思う
    • 回復手段は時間しかないと思う
  • 1日24時間は変えられないので、どううまく配分するかの戦いだと思う
  • やることと、やらないことの判断が大事で、特にこれはやらない！って決めることは大事
    • やらないことが間違っていたら、すぐ間違いを認め軌道修正する

14. 健康第一

• この記事を書いている週は4,5日くらい体調が悪く、ちょっとした風邪ですらパフォーマンスが出にくい
• マネージャーに閉じず普遍的な内容ですが、安定した勤怠が第一
• 食事、運動、規則正しい生活（特に入眠）
  • 最近、禁酒してます
  • 22時以降、PCは開かないなど（入眠に悪影響）

まとめ

マネージャーロールで気にしていることをまとめました。

マネジメントの業務をやればやるほど、個人タスクの時間が取れず、すなわち自分のスキルアップができないように感じ、当初は悩みました。

もちろんこれはある側面では真ではあると思いますが、基本的にはチームのパフォーマンスを第一に考えながら、タスクは移譲していくことが重要。防火的に問題を発生の前から潰し込んでいくことと、いざ何か課題が出たときにはダメージコントロールをクイックに行います。

防火、移譲がうまく行えればマネージャーの力量もついたと実感できますし、余暇時間を作れれば自分の成長に繋がるような時間を取得することができ、成長実感も持てる気がします。

なにかの参考になればと思います。

明日は@NikkelyさんのSAMを利用したLambda(Function URLs)デプロイの記事です。