dskst's diary

Life and Tech Blog

【EM必読】エンジニアリングマネジメントトライアングルの考察:序

エンジニアリングマネジメントトライアングル

エンジニアリングの話をする前に

プロダクトマネジメントトライアングルという言葉と聞いたことがあるでしょうか?

それは、プロダクトマネジメントという言葉の定義、責任をまとめたグラフィックモデルのことです。これはプロダクトマネジメントを探求するために作られました。

かたやエンジニアリングマネジメントも組織やフェーズによって役割が違う、責任もさまざまということから、プロダクトマネジメントトライアングルと同じように思考を整理できるのではないかと考えました。*1

では、このトライアングルをエンジニアリングマネジメントで作るとどうなるのか。Engineering Manager Meetup のみんなと作ってみたので紹介します。

 

f:id:dskst9:20190703005645p:plain

エンジニアリングマネジメントトライアングル

中心にエンジニアリングを置いて、テクノロジー、プロダクト、チームでトライアングルを構成しています。

※最新のトライアングルは Github で管理しています。本ブログの内容は古い可能性がありますので、 Github で最新のトライアングルを確認してください。

github.com

トライアングルの軸

エンジニアリングマネジメントの3つの軸から見ていきましょう。

  • Technology
    プロダクトを形成する技術から、組織の全体の技術を広く扱います。
  • Product
    エンジニアリングは不確実なものをプロダクトにします。
  • Team
    チーム、そして組織というものにフォーカスをします。

これら3つの軸とその間を埋める空白領域こそが、エンジニアリングマネージャーの役割になるのではないかと考えています。

エンジニアリングマネジメントの役割

空白領域に役割を埋めてみましょう。*2 各デルタを繋ぐ領域ごとに役割を説明します。

f:id:dskst9:20190714115349j:plain

エンジニアリングマネジメントの役割

Product - Technology

プロダクトとテクノロジーの間にある空白には、プロダクトを作るための技術、そして技術からプロダクトアウトする過程、プロダクト運用が含まれます。

 

Product Design

プロダクトのビジュアル的なデザインだけではなく、技術のデザインも含まれる。

Architecuture

プロダクトを構成するアーキテクチャ全般。

Technical Leadership

技術的側面からプロダクトをリードする。*3

Process Management

サービスインに至るまでのプロセスそのものをマネジメントする。

Quality Assurance

ニーズ、期待、要求にプロダクトが適合していることを保証する。

DevOps

運用と開発を親和させて、プロダクトをより良くしていく。

 

Technology - Team

テクノロジーとチームの間にあるものを見てみましょう。開発チームを最適化していき、チームの生産性を上げ、エンジニアリング組織を作っていきます。

 

Team Building

チームビルディングを行い機能するチームを作る。

People Development

メンバーのキャリア開発を行い成長を促す。

Recruting

採用活動、面接担当などを行い組織を拡大していく。

People Evaluation

メンバーの成長目標に対しての評価、フィードバックを行う。

Technology Selection

技術的な意思決定、あるいは技術選定を行う。

DevRel

社内外にマーケティング、広報活動を行う。

 

Team - Product

チームとプロダクトの間にあるものは、チームが作るプロダクトそのものからプロダクトと関係する組織まで多岐にわたります。

 

Vision

組織のビジョン、プロダクトのビジョンを語る。

Team Design

プロダクト組織を設計、構築する。

Product Roadmap

プロダクトの方向を明確にする。

Team Development

プロダクト組織改善、開発を行っていく。

Resource Management

ヒト、モノ、カネなどの資源を管理する。

Stakeholder Engagement

ステークホルダーのエンゲージメントを高める。

エンジニアリングマネージャーは何をするのか 

トライアングルでどんな役割があるのか少し整理できたかと思います。当然ながら、これらすべてをやっている人というのはいないと思います。

各領域の空白になっているところに対して、エンジニアリングマネージャーの役割が入ってくるのです。しかし、1つの組織でも組織のフェーズや戦略によって空白領域は異なるため、エンジニアリングマネージャーが何をするか明文化することができないということになります。

エンジニアリングマネージャーは、これら全てをやるのではありません。これらの役割を完璧にこなせる必要もありません。このトライアングルの空白があったときに、その空白を埋める糊のような存在こそエンジニアリングマネージャーなのです。

 

フィードバックを求めています

Engineering Manager Meetup のコミュニティでは、エンジニアリングマネジメントトライアングルがエンジニアリングマネージャーをやる人たちの役に立ってほしいと思っています。そのためには、エンジニアリングマネジメントトライアングルについて広くフィードバックを集めてより良いものにしたい考えています。

ぜひ、Twitterなどで気軽にコメントをいただけると嬉しい限りです。(追記: Githubに移行しましたのでissueを作成いただけると幸いです https://github.com/dskst/engineering-management-triangle

さいごに

このトライアングルを見ながら自身の組織での役割を考えてみるとおもしろいものが見えてきます。例えば、3年前はどの領域をやっていたのか、1年前はどうなのか、ふりかえるとさまざまな領域を移ってきたのだなと気付かされます。

トライアングルがもう少し形になったら、次は空白領域の具体化を進めていきたいですね。

コミュニティのみなさまの紹介

本記事を公開するにあたり、Engineering Manager Meetup の @aki85135 さん、@gim_kondo さん、 @qluto さん、 @yunon_phys さん、@_tweeeety_ さん(*4)と一緒に、トライアングルについて熱くディスカッションをしてきました。

一緒に悩みながらディスカッションができて、コミュニティのアウトプットとしておもしろいものができたのではないかと思います。ありがとうございます!

また、 Developer Summit 2019 Summer にて @yunon_phys さんがエンジニアリングマネージャーは何者か、エンジニアリングマネジメントトライアングルのお話もしてくれました。

これからも Engineering Manager Meetup は精力的に活動していきますので、EMに興味がある方はぜひご参加ください!

engineering-manager-meetup.connpass.com

2019.7.14更新

 

*1:下記のエントリーにて概念というものを探索dskst9.hatenablog.com

*2:役割は例として記載

*3:テックリードの領域に近い

*4:アルファベット順