エンジニアリングマネージャーとしてやっていること2023

はじめに

年末なので、振り返りを兼ねてエンジニアリングマネージャー（EM）としてやっていること（、やろうとしていること）と意識していることチェックリストを書き出してみました。
※追記: 書いている途中で年を越しました。すみません
私は自社向け/他社向けにML基盤を開発するMLOpsチームのEMなので、一部一般的ではない要素もあるかもしれませんがご容赦ください。（※MLOpsの話は記載していません。マネジメントとしてやっていることを書いています。）

参考にしている書籍

私は基本的には書籍に書かれている内容を根拠にマネジメントをするようにしています。
自分の経験や発想に（のみ）基づくよりも、納得感・再現性があると思うからです。

• エンジニアリングマネジメント全般

  • エンジニアリング組織論への招待

    • 「エンジニアリングとは」から始まり、エンジニアリング組織を運営していく上での基礎的な考え方が書かれたバイブルです
    

• ピープルマネジメント

  • エンジニアリングマネージャーのしごと

    • 特にピープルマネジメントについて、エンジニアリングマネージャーのやるべきことが具体例を豊富に交えて詳しく解説されている本です
    

  • GitLabに学ぶ 世界最先端のリモート組織のつくりかた

    • リモートで組織を運営していく上で考えるべきこと
    

• プロジェクトマネジメント

  • 図解入門 よくわかる 最新 PMBOK第7版の活用

    • プロジェクトマネジメントといえばPMBOK
    

  • アジャイルプラクティスガイドブック

    • アジャイルに進める場合はこの本の通りに進めるようにしています
    

• プロダクトマネジメント

  • プロダクトマネジメントのすべて

    • プロダクトマネジメントの教科書として参照しています
    

• リーダーシップ

  • 採用基準
    • 「採用基準」というタイトルですが、具体的なあるべきリーダーシップ像を提示してくれる本です

  　

EMの目的

なぜエンジニアリングマネジメントをするのか。
そもそも「エンジニアリング」とは「実現する」こと。
「実現する」とは、「曖昧さ」を減らして「具体性・明確さ」を増やす行為。例えば、誰かの曖昧な要求からスタートして、具体的なシステムに落としていくこと。
「曖昧さ」とは「不確実性」。どうすれば効率よく不確実性を減らしていけるか。
「不確実性」は大別すると、他人=通信不確実性と、未来=環境不確実性-方法不確実性・目的不確実性があり、それらに対応するべくピープルマネジメント・プロジェクトマネジメント・プロダクトマネジメントをしていく。
（エンジニアリング組織論への招待参照）

EMとしてやっていること・意識していること

※エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイドを参考に4分類に分けて記載していきます

1. ピープルマネジメント

採用

一緒に苦楽を共にしたいか

やっていること

• 広報活動・ブランディング
• 採用選考活動
  • 自己紹介
  • 会社・チーム紹介
  • これまで何をやってきたか（技術/マネジメント）
    • 対立をどう解決してきたか
  • これから何をやっていきたいか（技術/マネジメント）
    • 転職を考えた理由は
  • 逆質問

意識していること

• 自分が求めるものを徹底して具体的に描くことで、最高の人材を紹介してもらう
• チームではなく自分の成果は何か。どの役割で何を考えていたかを聞く
• 「仲間」を探す。助け合えそうな人か
• メンバーであってもリーダーシップは必要
• 候補者の立場になって考えることを忘れない。何をされたら嬉しいか・嫌か
• 魅力付けの場でもある。採用候補者に入社すべき理由を伝える。その場でフィードバックを伝える

アサイン

案件目線とメンバ目線、両面で考える

やっていること

• 案件情報とメンバ情報を事前に整理した上で、アサイン面談をする
  • メンバ情報: プロジェクト経験、スキルセット、成長の方向性

意識していること

• メンバのキャリア・プロジェクトに必要なピースや収益を総合的に考慮して決めていく
• アサインで成長の方向性と幅がある程度決まることを認識して考える
• なぜあなたが必要なのかを説明する
• その案件での成長イメージのすり合わせ（提示）までする。その案件で何を得られるか

チームビルディング

なぜ自分たちはここにいるのか・どこに向かうべきかを伝える

やっていること

• チーム憲章の作成
  • ミッションと目的
    • 課題、背景
    • ミッション・ビジョン・バリュー
  • 役割と責任
    • 事業推進体制と競争力
  • 中期方向性、注力ポイント
  • 数値目標
    • パフォーマンス評価
  • 基本戦略
  • 作業プロセス
  • コミュニケーションルール

参考: チーム憲章テンプレート: チームを成功に導くロードマップ (実例付)

意識していること

• 自己組織化されたチーム、抽象的で自由度のある指示をする組織であり続けるために整える。繰り返し伝える
• チーム外へのブランディングも継続的に取り組む
• 心理的安全性の高いチーム
  • 1. 何を言っても許される
  • 2. 困ったときはお互い様
  • 3. とりあえずやってみよう
  • 4. 異能どんとこい
  • リーダの心理的柔軟性が大切。正論ではなく、役に立つことをする。変えられるもの:「行動」にフォーカスする
• OKR: インスピレーションを促し、チームを鼓舞するO、野心的なKR

育成

成長する気になる舞台を用意する

やっていること

• 権限の委譲とモニタリング
  • メンバーのタイプとステージを考慮してタスクを振る
    • 目的
    • 役割
    • 対象を絞る
    • 基準と納期
    • 方法
• コーチング
  • ネガティブフィードバック
    • 事実を確認する
      • 状況、振る舞い、影響
    • → 自分の気持ちを伝える
      • 相手をよくしたい心情をのせる
    • → 相手の言い分を確認する（理解を示す）
    • → 自分の責任でもあることを伝える
    • → 具体的な改善策を提案する

意識していること

• 裏方としてフォローする。主役はメンバ
• ストレッチした目標にすると、組織の成果をあげること・メンバーが成長すること・成長を支援することが同時に達成できる
• ラーニングゾーンに置いてあげる（パニックゾーンでもコンフォートゾーンでもなく）
• 移譲はしても説明責任は放棄しない

参考: 組織マネジメントのあれこれ

メンタリング

スッキリしてもらう

やっていること

• 1on1
  • 体調確認
  • 前回のおさらい
  • 担当業務の目標と目標の進捗状況
  • 困っていること
  • 今後の目標
  • フィードバック
  • 雑談

意識していること

• 成長に助力する、エンゲージメントを向上する
• 話したいことを準備しておく。ただし、メンティーが話したいことがあればそれを優先する
• 何か私にできることがないか？を聞く。聞いたならすぐに動く。小さな約束を破らない。信頼を積み上げるチャンス
• 具体的に褒める・感謝する。普段から見てくれている人の言葉だから聞く気になる。360度評価を利用する
• 気付きを与える。視座を上げてもらう
• 期待・目標は明確にシンプルに伝える
• 雑談は例えば、最近何を勉強しているか？面白い記事があったか？
• その前に、なんでも相談してもらえる関係になっているか？感謝と自己開示

評価

評価面談でびっくりされないように

やっていること

• 目標と評価ラインの事前すり合わせ（アサイン面談、1on1）
• 評価
• 評価面談

意識していること

• 明確でシンプルな評価基準を示す。双方納得するまで会話する
• 短期の目標や評価ラインは、会話しながら適宜修正していく（業務に応じて）
• 達成度合いはこまめに確認し合う

コミュニケーション計画

「情報の非対称性」と「限定合理性」を防ぐ仕組み作り

やっていること

• 会議体設計
  • チーム内
    • 全体会: チームの戦略を共有する（、チーム憲章の再共有）。四半期ごとなど
    • 定例: 直近のタスクの話ではない、少し広い・先の話をする（人、技術、プロジェクト、プロダクト）。週次/月次など
    • 進捗確認会: 進捗のモニタリングをする。課題の芽を早期にキャッチする。日次など
    • 1on1
  • チーム外
    • 各種ステークホルダとの会議。クロスファンクショナルな協力の促進
• コミュニケーションツール設計
  • チャットツール、同期と非同期の使い分け
• ドキュメント管理方針立て

意識していること

• コミュニケーションの促進と衝突の解決
• 雑談から生まれるイノベーションがある。インフォーマルコミュニケーションも重要
• 全ての会議はプロポーザルのレビューであるべき
• 必要十分な会議を設定する。目的から逆算する。状況はすぐに変わる。だれにいつ何を共有すべきかを考える
• 社内政治で悪いものを遠ざける
• サポートを受けたいのであれば、普段からコミュニケーションを取っておく
• ストック情報とフロー情報を分けて考える
• 会議通知にはアジェンダと共同編集できるリンクを貼る、録画を取る
• バリューを浸透させる仕組み作り
• ドキュメントを腐らせないようにする設計をする。参照と更新の導線を考える

2. テクノロジーマネジメント

技術戦略の策定

ワクワクする、自分たちだからこそな世界を描く

やっていること

• 技術戦略の策定
  • 技術ロードマップ作成と技術選定
  • これから来る技術と組織のビジョンをどう調和させるかを明確に示していく
  • 深化と探索の両面を考える
• 技術スタックの管理
  • 過去・現在のナレッジ活用

意識していること

• Big Thinker　/ Technology Visionary and Operations Manager
• 探索と深化を共存させるには、リーダーの包括的で感情に訴えるビジョン、戦略、基本的価値観、幹部チームの強い結束力が重要
• 常に最新をキャッチアップし、引き出しを作っておく。本質を捉える
• チーム横断・中長期目線でのアーキテクチャ設計と実装の推進
• トレードオフを見極める
• はじめから登壇を意識しておく

参考: 両利きの経営

開発環境の最適化

高速で石橋を叩いて渡る開発環境

やっていること

• 開発環境の最適化
  • 開発チームが高い生産性を発揮できるような効率的な作業環境とプロセスを構築する
  • CI、CD、チケット、バージョン管理、テスト駆動開発、リファクタリング、開発規約（ブランチ戦略、コミットメッセージ、etc）

意識していること

• 重要だが緊急でないタスクを巻き取っていく

品質管理の徹底

品質の番人

やっていること

• レビュー
  • 理由、案、温度感を記載する
• ドキュメント管理
  • Design Docs
• リスク管理とコンプライアンスの確保
  • 技術的なリスクを評価し、リスク軽減策を実施する。また、法規制や業界標準に準拠するためのコンプライアンスプロセスを確立する
• 横串での支援・課題解決

意識していること

• 何かあった時に説明がつくか（次に活かすことができるか）

技術コミュニケーションの推進

成長・アピール・楽しい

やっていること

• 対外発表
  • 組織の技術的な成果や知見を外部に向けて積極的に発信し、ブランド価値の向上に貢献する
• チーム内勉強会
  • チームメンバーが最新の技術トレンドやスキルを習得できるように学習機会を提供し、技術的な成長を促進する

意識していること

• 登壇駆動学習
• 最初から登壇を見据えて業務に着手する
• 無理せず楽しく続く仕組み作り

3. プロジェクトマネジメント

営業、リレーション構築

顧客から頼もしいかつ相談しやすい人と思われる

やっていること

• 営業、リレーション構築
  • 事前準備
    • 事前に調査し、基本情報・最新のニュースをおさえておく+仮説を持っておく
  • 背景・状況確認
    • どういう経緯で話を聞いてくれることになった？既存・他ベンダは？
  • 会社・事例紹介
  • ディスカッション
    • いいと思ったところはあるか？
    • 誰のどのペインを解決したい？何か手伝えそうなことはあるか？
  • ネクストアクション
    • 意思決定者をおさえる
    • 予算取りはいつ？必要な情報は？

意識していること

• 自分が・会社が・プロジェクトが、今どう見えているか・どう思われているかを把握してから全てのアクションを組み立てる
• 会議はいい雰囲気で進める。つかみで人となりを伝える+空気をつかむ
• 売り込むのではなく共感、共同
• 自分の色を出す。選ぶ理由を与える。
• 相手を選ぶ。情報が欲しいだけの人か、意思決定権があって交渉する価値がある人かどうかを見極める
• 「顧客が本当に求めているもの」を対話を通じて早期に汲み取って、具現化してあげる
• 2回同じことを話したら、かなり気にしているということ。きちんと拾ってあげる
• いい人で終わらない。顧客の無茶な要望を飲むでも突っぱねるでもなく、Win-Winになるアイデアを即興で考えて返す
• 好感度は、接触回数に比例する

計画とスケジューリング

何かあったときに立ち戻ってくるスナップショット

やっていること

• 計画とスケジューリングを立てて、ステークホルダと合意する
  • 提案の要旨
    • 背景、現状認識、課題認識→ゴール、期待される効果
  • スコープ
  • 作業と役割分担
  • 成果物
  • スケジュール
    • 次のステップに進めるかを判定するタイミング
    • プロジェクトの進め方（ウォーターフォール、アジャイル等）
  • 体制
    • 役割、カウンター、意思決定者を明確に
  • 会議体、コミュニケーションツール
  • 前提条件
    • リスク
      • 追加工数が発生するケース、スケジュールがずれ込むケース
  • 見積もり
  • Appendix: 自社の強み

参考: 外資ITトップセールスが考えた提案書テンプレートを配布します!!

• ステークホルダーマネジメント
  • 特定→理解→分析→優先順位付け→エンゲージメント→監視

意識していること

• 基本は5W1H。why→what→how→who/when
• やらないことをまず決める
• 松竹梅をみせていく。やらないことを明確にするためにも
• 品質基準、セキュリティ基準を確認しておく
• 測定の方法とタイミングを明確にしておく
• コンティンジェンシープランも用意しておく
• 遊びがないと変化に対応できない
• 役割は明確にする。"アドバイザ"は危険。アウトプットとその粒度感のレベルで認識を合わせておく
• エグゼクティブサマリを先に作ってしまう

デリバリ、進捗監視とリスク管理

濃淡をつけて管理していく

やっていること

• QCD管理
• 立ち上げ→計画→実行→集結+監視・コントロール
  • プロジェクト計画立てと共有
    • ドキュメント管理方針含む
  • チームビルディング
    • 役割分担の明確化と共有
  • スケジュール管理
    • 進捗管理
    • 変更管理
  • 顧客折衝・外部調整
    • 外部連携インターフェース
    • テスト、リリース
  • 品質管理、レビュー
  • 技術アドバイザ
  • 運用リード
  • トラブル対応
  • 雑務
  • 会議体の設計とファシリテーション
    • キックオフMT
    • 定例（進捗報告、相談・ディスカッション）
    • フェーズレビュー、中間報告、最終報告
    • ステコミ
  • スクラムイベントのリード
    • スプリントプランニング
    • デイリースクラム
    • スプリントレビュー
    • スプリントレトロスペクティブ

意識していること

顧客折衝

• クライアントファースト。クライアントの立場で考える。顧客を不安にさせない
• 苦労も適宜上手く見せていく
• 顧客が質問してくるときは、不安か怒りが背景にあるので注視する
• 断るべきときは断る。ぶっちゃける。言い方と準備が大切。逆に信頼できると思わせることもできる
• 資料の細部にこだわる、即レスする

チームマネジメント

• 最初に、プロジェクトの意義と、メンバー個人として参加するメリットを伝える
• はやめに、リーダとしての力を示す（統率力があるところ、細部まで・先まで見据えていること、個のエンジニアとして手が動くところ、etc）
• 批評家にならない。一緒に前向きに手を動かす
• レビューは、文面での指摘はきつく見えるので慎重に。口頭でフォローする
• インクリメンタルなタスクか、割り込みタスクか区別して扱う。割り込みタスクを振られると、ストレスがたまる

デリバリ

• プロジェクトの始めにスコープ決め（スコープ記述書作成）→WBSに落とし、懸念点の洗い出しと共有までスピーディに実施する。WBSは作成物ベースで。
• 物事を動かすには、最初に力をかける

進捗管理

• できたことではなく、抱えている課題・やってみてどうだったかについてシェアしてもらうようにする（対顧客も対内部も）
• 刻一刻と変わるプロジェクトの状況をタイムリーに同期していく。ただし過剰に会議は開かない。各メンバーの責務から逆算して、必要十分に共有していく
• 油断せずにリスクの早期発見・早期潰し込みをし続ける。ボトルネックを潰して全体のスループットを上げる
• 進捗報告は、温度感を正しく伝える。ぱっと分かるように
• 上がってくる数字を追うだけなら誰でもできる。経験から、判断を入れる、濃淡をつける
• 常に、コストとリターンのベクトルを即答できるようにしておく

トラブル対応

• バッドニュースこそこちらからすぐに伝える。変な形で伝わらないように
• 顧客との関係が悪化したときにどうするか、がリーダーの仕事。だいたいのプロジェクトは上手くいかない瞬間がある
• 基本的に権限を委譲するが、ボヤが出たら入る。だが、途中で一度は手を動かして情熱とスキルを見せる
• トラブルが発生したときは、まず手を動かさない。計画を引き直し、報告する
• トラブルが発生したときに、雰囲気よくできるか。ピンチはチャンスだが、メンバーの気持ちに気を付ける
• トラブルが発生したときに、「それはちょーどよかった」と唱える
• QCDのどれかを調整しないといけないときは、まずスコープを調整する（品質、人員での調整難しい）
• 当事者意識を醸成する。特にうまくいっていないとき

4. プロダクトマネジメント

※プロダクト=ML基盤を開発したときにやったこと

プロダクトを育てる

プロダクトの未来について答えられる人

やっていること

• プロダクトのCore
  • プロダクトの世界観
    • ミッション
    • ビジョン
  • 企業への貢献
    • 事業戦略
• プロダクトのWhy
  • 「誰」を「どんな状態にしたいか」
    • ターゲットユーザ
    • ペイントゲイン
  • なぜ自社がするのか
    • 市場分析
    • 競合分析
  • ← ペインとゲインを仮説検証するインタビュー
• プロダクトのWhat
  • ユーザー体験
    • メンタルモデル
    • カスタマージャーニー
  • ビジネスモデル
    • コスト構造
    • 収益モデル
  • ロードマップ
    • 指標
    • マイルストーン
  • ← ソリューションを仮説検証するインタビュー
• プロダクトのHow
  • どのように実現するのか
    • ユーザーインターフェース
    • 設計と実装
    • Go To Market
  • ← リリース&フィードバック

参考: プロダクトマネジメントのすべて

意識していること

• 究極的なミッションは「曖昧さ解消に努め、人とモノを繋げることを通じてプロダクトとビジネスのアウトカム最大化にコミットすること」
• プロダクトマネージャーはステークホルダーとのコミュニケーション、チームの組織化、ユーザのニーズとゴールのリサーチ、そして、プロダクトチームがゴールに到達するためのタスクを実行する必要がある（ソフトスキルに対する比重が大きい）
• 非公式な力関係や情報資源を持って様々なステークホルダーに働きかけることでバリューを発揮する
• 間違えるよりも過剰なコミュニケーションを選ぶ
• 関わる人たちの仕事に対して、素直に純粋な好奇心をもつ
• 機能、機能性を引き算(削除)することがユーザーやビジネスにとって付加価値になる場合もある

参考: プロダクトマネージャーのしごと

ステークホルダーをまとめ、プロダクトチームを率いる

プロジェクトマネジメントと同様

0. リーダーシップ

他者を導く

次またあの人と仕事したい、と思ってもらう

やっていること

• 目標を掲げる
  • 成果目標を自分で定義、そしてメンバーに理解させる
• 先頭を走る
  • 方向性を決める、切り開く、最初に踏む
• 決める
  • 情報は揃わない。そうするとリスクが生まれる。それでも決める。それを全員が理解する
• 伝える
  • 繰り返し粘り強く同じことを語る

意識していること

目標を掲げる

• 心に火をつける。熱量をくべる
• 解像度と哲学
• 安心と興奮を同時にくれる存在である

先頭を走る

• 「旅の途中で賛同者が現れ目標に向かって共に歩む結果、当初行動を起こした人はリーダーと呼ばれるようになり、リーダーシップという現象が生じるのだ」
• 「あなた」ではなく「我々」、「やって」ではなく「やろう」
• 熱を生む
• チャームが必要、挨拶を大切にする
• 外への影響力も大事
• 失敗の乗り越え方をメンバーはみてる。誇らしくなる乗り越え方をする

決める

• データ収集フェーズか、意思決定フェーズかをきっちり分ける
• ポジションを取る
• ロジックと心中する
• 暇でいる。忙しいと受け身になる
• 「上に立つ者は下の者の気持ちは汲んでも顔色は伺ったらあかん」

伝える

• 常に目的を考える・説明する
• いつでも元気に、前向きに
• 大船に乗ったつもりになってもらう

（補足）サーバントリーダーシップ

• リーダはビジョンとＫＰＩは示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく
• 謙虚、敬意、信頼。個人商店の集まりとして考える
• 「互いが知識をシェアして高め合うことを助け合い、エンジョイすることに集中する環境」を作る
• アンブロックすることがリーダの仕事

おわりに

改めて文字に起こしてみると、やはり一つ一つは至極当たり前のことだなと思いました。ただ、マネジメントは当たり前のことを当たり前にやることが重要だと思っているので、これからもアップデートを続けながら凡事徹底の意識で取り組んでいこうと思います。