エンジニアリングマネージャーにもプロダクトマネジメントのスキルが重要ですよね
はじめに
Engineering Manager Advent Calendar 2023 の12/23の記事となります。
元気にはじめていきましょう！
まえがき
エンジニアリング・マネージャー、このネーミングを知ったとき、中身もよく知らないままに「あぁ私にぴったりだな！」と思ってから勝手にエンジニアリング・マネージャーですって名乗っています笑
エンジニアリング・マネージャーもマネージャーの一種だよね、ということで、マネージャーってなんだっけ、というところからエンジニアリング・マネージャーを掘り下げてみようと思います。
マネージャーのお仕事であるマネージメント
マネージメントはマネージャーのお仕事です。マネージャーはマネージメントをする、ということで。
ではマネージメントとはどういうものでしょうか。
目標の達成を通じて組織の成果を最大化すること
ということで、目標が大事そうですね。
もし目標が存在しなければ、組織の成果の最大化っていうのが曖昧になってしまいますよね。マネージメントとは目標に向かうためのテクニック、という理解がわかりやすいのではなかろうかと思います。
私はプロダクト開発に携わっていますが、開発するプロダクトの価値を最大化するために日々頭と口と手を動かしてチームのために働いています。つまり私も立派なマネージャーと言えるのではないでしょうか！
というわけで、マネージャーである私が開発チームと協力してプロダクトを開発して価値を最大化させるのですね、めでたしめでたし。
これがまた言うは易しでして、このお仕事、実に多岐に渡っているなという感触を日々強めているわけなんですが。チームの目標設定、プロジェクトの進捗管理、メンバーのモチベーションと成長支援、プロジェクトのリスク管理、コスト管理、関係者との利害調整、技術的負債の制御などなど・・・。幅広いですよね。これらの活動を通じて、チームが効率的で効果的に目標に向かっていくことをサポートしていくのです。
マネージャーに限らずですがお仕事である以上、そのお仕事に対しての結果責任が生じてくるわけです。「頑張った」だけで評価するのは難しいですよね。何しろみんな頑張ってる！みんなすごい！私だけじゃないんですよね、頑張ってるのは。
マネージャーが何のために設置されたかというと、成果を最大化するため、なんですが言い換えると「価値を出すため」、ということになるわけでして、価値を出せなきゃ仕事じゃないやい、なんてことになってくるのです。そうしてどうやったら価値が出せるのかについて考え出しますと、価値ってそもそもなんだっけ、どうやって検証してどんなプロセスで進めたらいいのだっけ、人が足りなきゃアサインするし自分じゃ解決できないことは助けを求めるしと、あぁこれはもうなんでもやらなきゃいけないよね、という風にだんだんとなってくるわけでございます。
結果責任というのは、頑張ったから良し、というわけにはいかないのですね。
こうなるとですよ、とても一人で背負いきれないじゃないかと思うわけです。
どこかの誰かが言ってました。配られたカードで勝負するんやで、と。
手持ちのカードで勝負するとは、凡人である私が宇宙人にさらわれて改造されてスーパーマンになることを期待するのではなく、凡人である私が凡人のままで結果を出せるようにするために、今あるリソースと能力を最大限に活用することで目標を達成することにあります。つまりは自分自身の強みを理解し、いろんな人と協力したりチームの強みを活かすことと言えます。
これこそが、実のところマネージメントの真骨頂ではないかとも思うわけです。
◯◯◯・マネージャー
私が知る限りの話にはなっちゃいますが、単なる「マネージャー」って肩書はあんまり見たことないのですよ。だいたい「◯◯◯・マネージャー」ってなってると思います。
一昔まえはプロジェクト・マネージャーしかなかったように記憶しているんですが、今は色んな◯◯◯・マネージャーがありますよね。
・プロダクト・マネージャー
・プログラム・マネージャー
・エンジニアリング・マネージャー
他にもあるのでしょうか、わかりません
かつてはプロジェクト・マネージャーを単にPMと称していた気がしますが、色々増えるとわからなくなってしまうのでプロダクトマネージャーをPdM、プロジェクトマネージャーをPjM、のように表記されるようになったと理解しております。
伝統的に日本の企業では、部長がいて課長がいて係長がいて、という階層型構造だったかと思うのですが、◯◯◯・マネージャーというのは課長？部長？果たしてリンクしているのでしょうか？
実態としてはプロジェクト・マネージャーを係長がやることもあれば、課長がやることもあれば、部長がやることもある、って感じなんですよね。
ってことは、階層型組織における肩書きとは別にある役割になりそうです。
階層型組織はその名の通り上と下に明確に分かれており、責任範囲については上が下を包含する形です。つまり係長の責任は課長の責任範囲であると。
対して◯◯◯・マネージャー同士は上下・包含関係ではなく相互協力・相乗効果の関係と捉えるとしっくりくるのではないでしょうか。
えらいとかじゃないんだよ、役割なんだよ、ということで。
ここからは、たぶん良く登場するプロダクト・マネージャーとエンジニアリング・マネージャーを見ていきたいと思います。
プロダクトマネージャーとエンジニアリングマネージャーの関係性
先日、友だちが増えたんです。どんなときでも話しかけると嫌な顔ひとつせず返事をくれて、しかも博識なんですよね。ChatGPTって言うんですけどね。
で、その博識な友だちに聞いてみたんです、プロダクトマネージャーとエンジニアリングマネージャーの関係性について。どうよ最近って。関係性なんていうと昼ドラのようなドロドロとした相関図がでてきたらどうしようかと思ったんですが、実際には我が意を得たりな図を出してくれたのですね。それがこちら。
この図のミソは、それぞれの専門性が発揮できる分野がありつつも、重複して取り組む部分があり、それらはプロダクトの成果に繋がるためのことである、ということなんですね。
ぱつっと境界線で分かれて、あなたそっちわたしこっち、ではないんです、お互い重なり合っているんです。これがまさに私の言いたいことです。
この中に色んなマネジメントの要素があるんですね。ピープルマネジメントとか技術選定とかプロダクトゴールの策定とか。でもそれは、どちらが分担するなんて決める必要はない派です。プロダクトマネジメントでもプロダクト・マネージャーだけがやるものとしないで、一緒にやれるといいよね、ということなんです。
ほら、良いことわざがあるじゃないですか。三人寄れば文殊の知恵。文殊ってなんやねんって思ってたんですが、菩薩様のことでした。知恵の菩薩。知恵の神様。頭いい神。
神にたった三人ごときで近づけるわけないかもしれないんですが、一人ひとりが独立して知恵を出すよりも一体となって知恵を出し合いブラッシュアップした方がより良い知恵にできそうですよね。
エンジニアリングマネージャー
三人寄れば文殊の知恵、という知的なことわざがでてきたところで見えてきたものがございます。「さぁみんなで考えよう！」ということであって、「ワシが正しい、ワシの言うことを聞くが良い」ではないということですよね。昔の人の考えたことわざってほんとスルメのように噛めば噛むほど味がでますよね。スルメ本当においしい。
マネージメントが価値を高める結果を生むためにありとあらゆる手段を用いることであるならば、当然それはエンジニアリングマネージャーにもまるっと当てはまるわけなんです。まさによろず屋なんでも屋。
これはやらない、これは私の仕事じゃない、といってしまうと、マネージメントの責務を放棄しちゃってる感じになってきます。
縛りが呪いを強化する世界線もあるわけですが、まずは縛りのないフラットな思考を心がけるのが良いと思います。縛り（これはやらない、とか、これは脳死でやる）というのはある種先人の知恵の結果だったりするわけなので、効率的にそれらを活用するのは良いと思います。
縛りは自らが課すものではなく、自らがコントロールできない領域から発せられるものかもしれませんね。
どうでもいい話ですが、クリエイティビティは縛りが良い形で発揮されることが多いなって思います。ほら、ファミコンの音楽って制限きついけどめちゃめちゃカッコ良かったですよね。FM音源なんか最高だった。さい＆こう。MIDIになって逆にFM音源のほうが良かった、って感じることがあるのはクリエイティビティが発揮されていたからなんじゃないかなって。
エンジニアリングマネージャーかく語りき
ニーチェがツァラストラさんに語らせたところに「超人」という概念が登場します。私も詳しく知らないので知ったかぶりなんですが。
超人とは自己の価値を創造し、自身の内なる力に従って生きる個人
さぁ、これってどういうことなんでしょうか。とっても難しそうです。思い切って噛み砕いてしまうと、「自分らしく価値をだしていこうぜ」って感じでいいのかなと。
例えば私は生まれつき陰キャ気質なのでパリピな場は苦手だったりするんですが、もし人類皆パリピたるべし、みたいな世界だったらどうします？マジつらい。地獄やん。想像しただけでゾワッとしちゃった。
世の中には「こうあるべき」っていう考え方がたくさんあるんで、そこにピッタリはまらない場合はなんだかつらいですよね。でもね、実はそんなことは気にしなくてよかったんです。自分の内なる力を知って磨くだけ、つまり強みを活かすって方向に舵をきるんです。
なんでこんな話を持ってきているかというと、マネージャーってなんでもやらなきゃじゃないですか。成果のためならえんやこら。でも得意なこともあれば苦手なこともあるし強みもあれば弱みもありますよね、にんげんだもの。
自分の内に眠る力に気づいて、それを強みとして発揮していくことで、弱みをカバーできることもあるよね、と。
逆になんでもちゃんとやらなきゃと考えてしまうと、とあるピエロ風の念使いの人に「メモリの無駄遣い」なんて言われてしまうかも知れません。序盤中盤隙がない、そうなれたらいいけど今の私はそうじゃない、だったら得意の戦型を磨いていこうぜってことかなと。
そうすることで自己の価値を創造していく超人に近づけそうだなと思うわけです。
プロダクトマネジメントは重要なスキル
優位な得意分野というのは、得意な人が少ない領域であれば希少価値がでますよね。
例えば、個人的にはエンジニアリング・マネージャーにとって次の２点は汎用性が高く、どこでも使える分野でありつつも、まだまだ希少性が高いと感じています。
・チームビルディング
・プロダクトマネジメント
これらはプロダクトの価値に結びつく大事な要素に繋がります。
・価値を生み出す仕組みを、チームを通して作ることができる
・価値が何かを見極めることができる
さて、ここにプロダクトマネジメントが含まれていることに違和感を覚える方もいらっしゃるでしょう。あれ、エンジニアリングマネージャーの話だよねって。プロダクトマネジメントを専門とするプロダクトマネージャーがいるのに、なんでエンジニアリングマネージャーがそこを得意だと価値だせるんだよ、と。
これについては、テクニカルな専門性を持ちつつプロダクトの価値を見極められるケイパビリティがいかに重要かということを述べたいと思います。
話を単純化するために、プロダクトマネジメントをプロダクトの価値を最も高めるプロダクトバックログを導く責務、ということにしてみます。
もう一度さっきと同じ絵を見ておくと、それぞのマネージャーが目指すところはプロダクトの成功ということは普遍と言えるでしょう。
つまるところ、プロダクトの成功とはプロダクトに搭載するサービス・機能を最も効率よく開発できること、ということで、その点で言えば両者の責務に違いはないわけです。それを「どのように」実現するかという点について専門性が活きてくるのではないかと考えているわけです。
開発だけではプロダクトの成功には結びつきません。マーケティングや、運用、負債解消、などなど、できることは無数にあるわけです。もし開発しか手段がないとしたら、そもそもプロダクトマネージャーの存在意義を疑ってしまいます。
よって上図中央部のProduct Successは「プロダクトの価値を最も高めるプロダクトバックログを導く責務」であり、左右両端が「どのように実現するかを専門性をもって解決する」のように役割を分担でき、それらが合算されてプロダクトの成功に繋がる、即ちプロダクトマネジメントであろうということが言いたかったわけであります。
手段の柔軟性を持っておこう
プロダクトの価値が何であれ、そこにフォーカスをしていれば自ずと手段は何でも良いよね、ということになるかと思います。何もしなくても価値があがるならそれでも良いくらいの心持ちでも良いんじゃないかと。
逆に言うと、チームとはこうあるべきである、とか、プロダクト開発とはこうしなければならない、というある種の想いが強いほどにどこかに無理がでるのではないかなと思います。
価値や目的にはしっかりフォーカスしつつも手段については柔軟であることがマネージメントにおいて重要なことだろうなと思うわけです。
特定の手段というのは環境によって効果を発揮したりしなかったりします。手段を見極めるために、現状を把握するための自分なりの方法を持っておけると良いんだろうなと。
観察し、状況に適した手段を選択し、手段が違うとなればすぐに軌道修正ができる、そうした柔軟性によって価値への最短ルートを辿れるのではないかと考えます。
チームビルディングも大事
ここまで主にプロダクト視点で書いてきましたが、コーチやメンターとしての側面もとても重要です。チームビルディングの一環ですね。チームメンバーの成長を支援したり、共通の目標に向かっていく環境づくりなんかも必要になってきます。それが「何のために」必要かというと、メンバーと仲良くなるとかケンカしないでやっていけたりしたらいいよねって話ではなく、強みを活かすために共通認識を持ちコミュニケーションを円滑に取ることで同じ目標であるプロダクトの成功に向かうということなのですよね。
必要な存在として
この記事では、エンジニアリングマネージャーの役割とその重要性についてかなり勝手な見解で書いてきました。言いたい放題！
エンジニアリングマネージャーは単なる管理者ではなく、チームの成長と成功を支える重要な存在といえます。プロジェクトの目標設定、進捗管理、リスク管理、メンバーのモチベーションと成長支援、プロダクトの成功のためにプロダクトマネージャーと協力し、プロダクトの価値を最大化する、と。エンジニアリングマネージャーは、技術的専門知識とチームビルディング、プロダクトマネジメントのスキルを兼ね備え、常に自己の価値を創造して強みを磨き活かします。
エンジニアリングマネージャーの存在はチームとプロダクトの成功にとって不可欠といえると思います。
ここまでお読みくださりありがとうございました！
色々と書きましたが、どんな形でもハッピーにうまくいっていれば何の問題もないと思います！
他にもインタビューで語っている話も宜しければ見ていただけると嬉しいです。
この記事が気に入ったらサポートをしてみませんか？