下林明正のブログ

個人的かつ雑多なブログです。

トップ > ソフトウェア開発 > エンジニアリングマネージャーの私的解釈と実践

エンジニアリングマネージャーの私的解釈と実践

ソフトウェア開発

エンジニアリングマネージャーに関する以下のアウトプットを見かけて、現時点での自分の思考のスナップショットも取っておこうという気持ちになりました。

ウェブ業界でしか働いたことがないので、ウェブ業界に限定したことを書きます。

状況認識

エンジニアリングマネージャーとは何なのかというと、業界としての具体的な合意はまだ形成されておらず模索中という認識です。 なので一人一派のエンジニアリングマネージャー像を持っており、個人によって理解に大きなブレがある状態と思います。

そうした前提の中での最大公約数的な理解に関してはやはり エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita にまとめられたアンケート結果が役立ちます。ここに

このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。

と書かれていることからも、やはり一人一派という理解で合っていそうです。

また、様々な企業の出しているエンジニアリングマネージャーの募集要項を読んだり、実際に数社とお話させていただいた印象としては主に「エンジニアのマネージャー」として取り扱われていることが多いように感じました。

私的解釈

そうした一人一派の状況下で自分が参照したいと思ったエンジニアリングマネージャー像は、Engineering Managerをエンジニアのマネージャーとするのはやめませんか？ - Unknown Errorにまとめられたものです。

組織のボトルネックを見定め、組織を構造化して捉えて最善な方向に導くのが、EMの役割とも言える。

ここで自分はエンジニアリングマネージャーを「エンジニアのマネージャー」ではなく「エンジニアリングのマネージャー」なのだと捉えました。 その心は、例えばシステムエンジニアがシステムのエンジニアリングをする役割なら、エンジニアリングマネージャーはエンジニアリングの対象をシステムのみに限らず組織体制や開発プロセス、開発計画などなどプロダクト開発に関わるおおよそすべてを対象としており、必要に応じて自身が直接手を加えることもあれば、他の専門家と協働することもある役割と捉えたからです。

そして、こうした働きを実現するために主として必要とされるスキルが エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita などでまとめられている

  • ピープルマネジメント
  • テクノロジーマネジメント
  • プロジェクトマネジメント
  • プロダクトマネジメント

の4つのスキルなのだと受け止めています。

実践(あるいは自分語り)

エンジニアリングマネージャーという言葉を知るずっと前から、ウェブエンジニアとして働く傍らでプロジェクトマネジメントスキルを中心としてボトルネックを解消する活動をしてきました。 そうしようと思った経緯は、

というものでした。

それから、そうした活動をより推し進めるために当時はウェブエンジニアというポジションよりはウェブディレクターというポジションの方がやりやすいだろうと考えキャリアチェンジをしました。 そうしてウェブディレクターとしてプロダクトマネジメントスキルやピープルマネジメントスキルを5年ほどかけて身につけながらも、エンジニアリングマネージャーという言葉の広まりとともに自分がやりたかったのはエンジニアリングマネージャーなのではという思いが強くなり、(エンジニアリングマネージャーというポジションは存在しなかったので比較的近しいと判断し)ウェブエンジニアとして再度キャリアチェンジをしました。

しかし、そうした過程で自分のテクノロジーマネジメントスキルが全く時代についていけていない・そのことでエンジニアリングマネージャーとしての働きを実践できないと痛感する出来事があり、改めてウェブエンジニアとして学び直さなければならないと考えました。その時に勉強した内容が 現代のWebアプリケーションエンジニアとして最低限の常識TODO - shimobayashiパブリック に書かれていることです(フロントエンド回りはまだ自分の中の及第点に達していないので、何かしらの材料を見つけて勉強しなければならないのですが……それはまた別の話)。 今ではその甲斐もあって、なんとかそれなりのウェブエンジニアとして働くことはできていると思います。

前置きが長くなりましたが、ここで先ず学んだことは(少なくとも自分は)「テクノロジーマネジメントスキルの維持を怠ると、ドッグイヤーのこの世界では通用しなくなる」ということでした。このことでエンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイドにも書いてあるとおり、マネージャーになったとしてもテクノロジーマネジメントスキルを維持するための継続的な取り組みは必要だと考えるようになりました( エンジニアのためのマネジメントキャリアパス を読んだ - 下林明正のブログ には全然そんな感想を書いていませんでしたが……)。

次に、大きなボトルネックを解消しようと思ったらボトルネックを見定めるだけではなく、自分の考えや計画を共有して周囲を巻き込んで段階的に解消していく必要性に遅まきながら気が付きました。それでまとめたものが 開発プロセスの変遷モデル - shimobayashiパブリック です(つまり、今の自分は開発プロセスが自分の取り組むべきボトルネックだと考えているわけです)。 巨大な開発プロジェクトだったらすぐに取れるような行動が、案外ちょっと性質が違うというだけで気づけなくなるものですね……。

そして、上司として部下に指示したり育成したりするような種類のピープルマネジメントスキルはウェブディレクターとしての経験の中である程度培うことができていると自認しているのですが、一方でメンバーとして周囲を巻き込んで変革を促していくような種類のピープルマネジメントスキルに関してはあまり身につけられていないという問題にも気づきました。 そう考える理由の1つとして、これまで自分が取り組んできたアジャイルソフトウェア開発の普及活動について自分の中にあった期待ほどは根付かせられていないということがあります。これは、自分自身がプロジェクトマネージャー的に振る舞うあまりメンバーにスキルを引き継げておらず、文化として醸成できなかった問題と捉えています。 そのため最近はそうした分野に関心をもって勉強しながらまとめていたものが 組織変革の進め方 - shimobayashiパブリック なのでした。

長くなってしまったのでまとめると、今後は以下のようにエンジニアリングマネージャーとして実践していきたいと(今は)考えています。

自分はあまり要領が良くないのでこれからも時間はかかるでしょうし、これまで何度か心が折れそうになったこともあるのでどこまで行けるかも分かりませんが、とにかく今はこう考えています。

そしてここまで読んでくれた奇特な方へ向けてついでに言っておくと、開発プロセス以外にも解消するべき大きなボトルネックとして(ありがちですが)組織にエンジニアが足りていないというものもあります。 もしこのエントリーを読んで一緒に働くことに興味を持ってもらえたら、Twitterのメンションでもメールでも何でも良いので一度コンタクトを取っていただけるとうれしく思います。