2018年に転職したら、エンジニアリングマネージャ的な仕事をするようになったので、振り返りをかねて棚卸し。

何者？

東京本社の会社の、地方拠点で働くエンジニアリングマネージャ
前職は大雑把にいえばメーカー系SI系列子会社
転職前後ともいわゆる受託開発がメイン領域
マネージメント対象は片手から出るくらい
全員が同じプロジェクトではなく、複数のプロジェクトを横断

やっていること

プロジェクトの提案活動
プロジェクトへのメンバーのアサイン
プロジェクトマネージメント（一部）
拠点メンバーの評価面談
中途採用面談
（新卒採用を念頭に置いた）学生向けイベント実施
外部交流活動
余った時間で、ほんの少し手を動かす

やってきたこと

前職がSIだったこともあり、思えば役割や領域は割と定まっていた
......に対して、現在はそこまででもない
自分が入った時点で拠点のエンジニアは全員入社1年以内の中途転職組
お互いに様子見をしつつ、組織の文化とかカラーとかなにそれおいしいの？状態
本社と拠点の関係性の構築からして、手探りではじめる
最終的には、「とりあえずやればいいじゃん、大袈裟だなぁ」

わかったこと

プロジェクトマネージメントでよく引用されるQCDの三角形があるけど
それと類似する形でエンジニアマネージメントにも三角形がありそう

- QCDと同じように相互に関係していて、どれかひとつをいじると他に影響がある - エンジニアリングマネージャの仕事は、この３つを円滑にまわしていくこと - そのために、「組織」「エンジニア」「プロジェクト」それぞれの代弁者となる

たとえば

組織から予算調達してエンジニアの作業関係を改善し、プロジェクトの効率をあげる
エンジニアの進捗を管理してプロジェクトの進行を助け、組織の健全な収支を保つ
営業や提案活動を支援し、エンジニアの適性や志向と一致するプロジェクトを獲得する
（風を吹かせて桶屋を儲けさせる）

こういう話って、どうしても鶏が先か卵が先かの議論になりがちだけど、互いに影響し合っているのだからまわしてみるしかなくて。必ずしも成果が約束されるわけではないので、正のフィードバックを得られそうな方に向けて、小さいところからパラメータを動かしていくしかないというのが体感。
大雑把には３つに分けてはみたけど、もちろんシステムとしてはこんな単純なものじゃないし、結局動かすのはそこにいる人間なので、そこに由来する困難がつきまとう。
とはいえある程度モデル化＝単純化しないと理解も進まないわけで。回してるのが正のループなのか、負のループなのかというところだけは意識したい。

次にやること

最終的には、自分がいなくても大丈夫な体制