2018年に転職したら、エンジニアリングマネージャ的な仕事をするようになったので、振り返りをかねて棚卸し。
何者？
- 東京本社の会社の、地方拠点で働くエンジニアリングマネージャ
- 前職は大雑把にいえばメーカー系SI系列子会社
- 転職前後ともいわゆる受託開発がメイン領域
- マネージメント対象は片手から出るくらい
- 全員が同じプロジェクトではなく、複数のプロジェクトを横断
やっていること
- プロジェクトの提案活動
- プロジェクトへのメンバーのアサイン
- プロジェクトマネージメント（一部）
- 拠点メンバーの評価面談
- 中途採用面談
- （新卒採用を念頭に置いた）学生向けイベント実施
- 外部交流活動
- 余った時間で、ほんの少し手を動かす
やってきたこと
- 前職がSIだったこともあり、思えば役割や領域は割と定まっていた
- ......に対して、現在はそこまででもない
- 自分が入った時点で拠点のエンジニアは全員入社1年以内の中途転職組
- お互いに様子見をしつつ、組織の文化とかカラーとかなにそれおいしいの？状態
- 本社と拠点の関係性の構築からして、手探りではじめる
- 最終的には、「とりあえずやればいいじゃん、大袈裟だなぁ」
わかったこと
- プロジェクトマネージメントでよく引用されるQCDの三角形があるけど
- それと類似する形でエンジニアマネージメントにも三角形がありそう
- QCDと同じように相互に関係していて、どれかひとつをいじると他に影響がある
- エンジニアリングマネージャの仕事は、この３つを円滑にまわしていくこと
- そのために、「組織」「エンジニア」「プロジェクト」それぞれの代弁者となる
たとえば
- 組織から予算調達してエンジニアの作業関係を改善し、プロジェクトの効率をあげる
- エンジニアの進捗を管理してプロジェクトの進行を助け、組織の健全な収支を保つ
- 営業や提案活動を支援し、エンジニアの適性や志向と一致するプロジェクトを獲得する
- （風を吹かせて桶屋を儲けさせる）
こういう話って、どうしても鶏が先か卵が先かの議論になりがちだけど、互いに影響し合っているのだからまわしてみるしかなくて。必ずしも成果が約束されるわけではないので、正のフィードバックを得られそうな方に向けて、小さいところからパラメータを動かしていくしかないというのが体感。
大雑把には３つに分けてはみたけど、もちろんシステムとしてはこんな単純なものじゃないし、結局動かすのはそこにいる人間なので、そこに由来する困難がつきまとう。
とはいえある程度モデル化＝単純化しないと理解も進まないわけで。回してるのが正のループなのか、負のループなのかというところだけは意識したい。
次にやること
- 最終的には、自分がいなくても大丈夫な体制