Qiitaで期間限定開催中の、「エンジニアによるマネジメント」に関する記事を投稿するイベントへの参加記事です。
マネジメントを始めて悩んだこと
約1年前、アシスタントマネージャーという役職をいただき、エンジニアリングマネージャー（以下、EM）としての業務を開始しました。EMになると1on1やメンバーの目標設定、チームづくり、チームの代表として事業部リーダーズミーティングへの参加などの新しい業務をしながら、それまでのプレイヤーとしての業務も行い、目の前の業務をこなすのにいっぱいいっぱいでした。
そんな中で常に「自分がマネージャーとしてきちんとできているのかが分からない」という不安を持っていました。また、どんなスキルをつけて、どうなれたら正解なのかというイメージが見つからず悩んでいました。
ある時、先輩との1on1で、「（メンバーとの1on1やメンバーの育成を）どうしてそれをやるのか」と問われて初めて、自分が目の前の業務をこなすことに精一杯で、何のためにマネジメントをしているのかを意識できていなかったことに気づきました。そして、EMの役割について改めて考え、マネジメントを通して何を達成したいのか、そのためにどのようなことをするのかという、EMの役割の全体像を理解することが大事だと気づきました。
■ EMとしてやるべきことを俯瞰する
この記事では、日々やっているEMとしての業務が、どんなゴールに、どのようにつながっているのかという部分を逆算しながらまとめました。ただし、ここに書いてあることすべてを完璧にやらなくてはいけないというものではないです。
ゆのんさんの記事でも書かれていますが、EMの役割は理想に対してどこが課題・ボトルネックなのかを見つけ、そこを解決することだと考えています。今回この記事に書いていることの中で、今のチームにとってどこが課題で、自分がどこに取り組むことが最も効果的かを考えて、まずはその課題にフォーカスして取り組んでいただきたいです。
この記事では具体的なやり方までは説明しないので、その課題の解決策を見つける方法はまた別途探していただきたいのですが、この記事を読んで、全体的に俯瞰できるようになればと思います。
EMに興味を持っている人だけでなく、プレイヤーとして活躍する人にも普段の業務に関連して、何か得ることがあるようにと思い書きました。
自己紹介
(2021年6月現在) 3年ほどWebエンジニアとして開発に携わった後、10ヶ月前にマネージャーの一歩前のアシスタントマネージャーになりました。組織は事業部制でその中のエンジニアチームのマネジメントをしており、メンバーは初めは2人でしたが、今は4人となっています。同じ組織に、プロダクトマネージャーやプロジェクトマネージャー、エンジニアリングマネージャーという役職はなく、比較的柔軟に幅広く色々な役割をさせていただいています。
この記事は、EMになってから、会社のマネジメント研修や先輩との1on1を通して教わったことや、最初の半年で20冊以上の本を読んだり、EM . FMを聞いたり、ネット上にあげていただいている大量の記事を読み漁って取り入れた知識を活用し、1年間のマネジメントを通して学んだことをまとめています。
目次
- マネジメントを始めて悩んだこと
- 自己紹介
- 目次
- EMとして自分に求められていることを知る
- マネジメントの4分野
- まとめ
- 参考
EMとして自分に求められていることを知る
はじめに注意事項ですが、EMとして求められることは、組織の状態、事業状況などによって異なるので、常に同じではないです。また一時的にはプレイヤーとしての成果も求められることもあると思います。そのため、幅広くすべての領域において完璧なスキルをつけようとしなくて大丈夫です。
私もつい最初からすべてを完璧にやろうとして、どれも中途半端になってしまったり、元々の自分の良さが失われていると言われたりしたこともあります。
しかし大事なことは、今の事業の課題・ボトルネックとなっているものは何か、自分が求められていることは何かを知り、状況に合わせて順番に成長していくことで、自分ひとりですべてをやろうとするのではなく、時にはチームみんなで補い合うことも大事です。
■ チームの成果を最大化するという役割
EMの役割について、色々な記事や本で「チームの成果を最大化すること」と書かれているのを見たことがあります。（こちらの記事など）
◯ 自分ひとりの成果ではなく、チームの成果
EMになることで、自分だけでなく、チームの成果を追うことが求められるようになりますがどうしてでしょうか。まず大前提として、企業には、企業としてのビジョン・ミッションがあり、それを達成するために事業戦略があります。そしてその事業戦略を達成するために、ヒト・モノ・カネの経営資源があります。
EMは自分がマネジメントするチームのヒト・モノ・カネを采配する権限が一部渡されて、ミッション達成の責任を持っています。つまりEMが責任を持っている「ヒト」は、今までの「自分」というリソースだけでなく、「チーム」へと範囲が広がっているのです。
◯ 成果を最大化する
最大化するというのは、その同じ「インプット / リソース」でも生み出す「アウトプット / 付加価値」を大きくするということです。そのために、アウトプットを増やすためのボトルネックとなっている部分を解消し、高い生産性を出す働きを行います。また、状況に応じて、採用などを通してチームの「インプット / リソース」を増やす活動も行います。
■ 上司が求めていることを把握する
マネジメントを任されたときに、あなたの上司が自分に期待していることと、自分の考えをすり合わせることが大切です。あなたの上司はあなたにマネジメントを権限移譲することで、何を達成したいと考えているのでしょうか。上司が思っている、「移譲した権限と責任の範囲」、「どの範囲までを意思決定すべきと考えているか」の認識を揃えることが必要です。
その上で、その実行責任・説明責任を果たしながら、抽象的な方針に対して、より具体的な戦略に落として成果につなげていきます。
マネジメントの4分野
マネジメントといっても複数分野がありますが、「エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド」の記事を参考に4つに分けて説明していきます。
この各分野を幅広く習得するのではなく、まずはどこかに自分の強みを持つことを目指す方がいいと思います。ただし、各分野はお互いに関係しあっているので、各分野の繋がりを知ることは大事だと考えています。この記事では、それぞれの分野に対する詳しい理解というよりも、EMとして知っておきたい繋がりを意識して説明します。
■ 1. プロダクトマネジメント
プロダクトマネジメントは、プロダクトを成功に導くためのマネジメントで、主に、「何を作るのか」「なぜ作るのか」を考えプロダクトを導きます。EMとしてマネジメントをすることは「儲けること」、「ユーザーに価値を届けること」に繋がるように、プロダクトが何を達成したいのかをまずは理解した上で、方向がずれないようにすることが大事です。
プロダクトマネジメントのすべてにはプロダクトを網羅的に検討するための4階層として「Core, Why, What, How」に分けて考慮すべきポイントが説明されています。プロダクトを通して何を実現したいのか、「誰」を「どんな状態にしたいか」、なぜ自社がするのか、どんな体験を実現するのかなど様々な観点から考えるヒントが得られます。
後述するプロジェクトやチームなども、このプロダクトの目指すビジョンと方向性がずれてしまっていると、プロダクトの成功から遠ざかってしまいます。逆にプロダクトのビジョンに対し、チーム全員が認識を揃えられていると、プロダクトの成長を加速させることができます。
◯ リーダーシップを発揮する
EMとしてリーダーシップを発揮するために、プロダクトのビジョン、ミッションは最も重要です。ひとりひとりが情熱を持って自発的に働くためには、リーダーがより熱い想いを持ってビジョンを語り、それを実現したいと思えることが必要不可欠です。
また、実現のための作戦を考え・示すことでリーダーシップを発揮します。そのためにプロダクトと組織の両面から、理想と現状のギャップを把握し、課題を特定します。課題解決のための解決策を考え、計画を立てます。エンジニアとしては、特にHowの「どのように実現するのか」という部分は特に重要で、まずはこの部分において価値発揮をすることが近道だと感じています。
■ 2. テクノロジーマネジメント
事業計画実現のために必要な技術的戦略を立てます。1年後、3年後の事業・市場の状態を想像し、そのときにプロダクトがどうあるべきかを考え、ソフトウェア・アーキテクチャを設計する役割です。具体的な要素としてはアーキテクチャ、品質、開発プロセス、SRE、技術選定などが関係してきます。
技術的な観点での資産の成長と負債の返済のバランスを取り、どこにレバレッジをかけると事業成長が加速されるかを設計していきます。（CTOの頭の中：技術投資を最適化するの記事はとても分かりやすく、いつも参考にさせていただいています）
◯ マネジメントチームの一員としての心構え
EM は事業部のマネジメントチームにおいて、エンジニアの代表です。事業の中で、技術的な選択などの権限を与えられている一方で、技術戦略が事業に対してどのような影響があるのかを説明する責任があります。
特に技術的負債の返済と言われるような、短期的な売上につながらない施策についても理解してもらえるように説明する責任があります。
◯ 技術に対する理解も不可欠
マネジメントに関する時間が増え、自分が直接手を動かして何かを作る機会が減っていきますが、その中でも技術的な意思決定をするために、技術の理解を高めるための学習は常に必要になってきます。
より一層重要になってくるのは、一つの分野を突き詰める知識の深さではなく、技術の変化に対し広くキャッチアップをし、各分野の最低限のリテラシーを持つといったような、知識の広さにシフトしてくると感じています。
■ 3. プロジェクトマネジメント
事業戦略に紐づく作戦であるプロジェクトをマネジメントします。プロジェクトはプロダクトや技術に紐づく課題を解決するために行うもので、「ある目的」に対して、「ある期限」までに成果を出すという、終わりが存在しているものです。
もちろんプロジェクトを成功させることも重要ですが、プロジェクトが終了した後に戦略達成につながることが大事です。
◯ 全員の目線を合わせて連携する
プロジェクトチームは普段の組織とは異なる期間限定の組織になります。そのため、スタート時には十分な信頼関係が築けていないことがありますが、問題を早期に発見して連携し合うには、信頼関係が必要です。
メンバーが問題も含めて率直に議論できるような信頼関係を築き、同じゴールを目指して自発的に連携し合いながら進められるように、チームのコミュニケーションを設計します。
◯ 制約条件のバランスを取り続ける
QCDなどと言われますが、プロジェクトには様々な制約条件やステークホルダーからの様々な要望が存在します。この様々な条件の中で、常に共通認識を持ちながらプロジェクトを進めていきます。
特にプロジェクトのスコープは大きくなりがちなので、本当に届けたい価値は何なのか、必要最小単位を見つけて提供することが大事です。ときに要求のコンフリクトが起きるなど、困難がたくさん訪れますが、プロジェクトを成功させるという熱い想いを持ち、コンフリクトを解消しながら進めていきます。
PMBOKには10の知識エリアが定義されていたりと、考慮することは多岐にわたります。適切な開発手法の選択をしたり、プロジェクトの進め方に関する知識も取り入れたりしながらプロジェクトを成功に導きましょう。
■ 4. ピープルマネジメント
事業戦略、技術的戦略、各プロジェクトを達成するためには、どんなチームである必要があるのか、その時のメンバーはどのような状態であるのかを考え、その理想状態と、現在とのギャップを埋める働きかけを行います。チームとしての組織的課題の解決や、メンバーひとりひとりの育成が必要になります。
EMになった瞬間にメンバーとの間に上下関係が生まれるわけではなく、メンバーにとってEMはチームの最適化をするという役割を持っているパートナーであるということを意識します。気を抜くと権威勾配によって、メンバーが発言しにくくなる恐れがあります。
◯ チームマネジメント
戦略達成のために、心理的安全性があり、相互に信頼関係があり、ゴールに対してみんながワクワクして自律的に働けるチームを作ります。楽しく働けるだけでなく、ひとりひとりが意欲的でパフォーマンスの高いチームにすることも必要です。
また、組織として大切にする共通の価値観を言語化できるととても良いです。私の組織にはグループとして大切にしている価値観を言語化したものがありますので、価値観の部分で大きな問題が発生していません。
Google re:WorkやTHE TEAM 5つの法則など、いいチームに必要な要素は色々なところで知ることができるので、様々な意見を知りながらみんなでマッチするものを取り入れて、いいチームを作っていきます。
◯ メンバーマネジメント
メンバーの育成はEMにとってとても重要な役割です。プロダクトのビジョン達成のためにはメンバーが成長し、より高いパフォーマンスを発揮することが必要になるでしょう。
しかし、人は他人を変えられるわけではないので、EMはメンバーが成長できるように後押しをすることになります。
● メンバーのWillを知り、 能力、要望のバランスを取ること （Will, Can, Must）
メンバーがモチベーション高く働けることが成長のための近道です。そのためにEMはメンバーに動機づけを行いますが、このとき内発的動機づけができるとより高いモチベーションで、高いパフォーマンス発揮することに繋がります。そのためにまずはメンバーのWillを知ることがとても重要になります。
ただし、事業として達成したいことがあるので、すべてがメンバーのWillありきで進めることはできません。メンバーのCanをもとに適度なチャレンジも見込んで、戦略からメンバーに対するミッション（Must）に落とし込んで提示します。そしてメンバーのWillとの紐付けを一緒に寄り添いながら考えます。
チャレンジの難易度は、成長を見込んでギリギリ達成できると思えるレベルが適切です。Will, Can, Mustを踏まえてメンバーに目標を設定してもらい、自発的に追える状態にしていきます。
● 機会、支援、評価、承認、報酬のループ
また、その上で内発的動機を高めるために必要なことは「機会、支援、評価、承認、報酬」のループだと無理・無意味から職場を救うマネジメントの基礎理論の中で言われています。これを繰り返すことで成長実感、達成感を感じられるようになります。
少し背伸びをしたチャレンジングな機会を与え、課題にぶつかりながらも乗り越えていけるように支援をします。達成できたら正当に評価し、承認・感謝を伝え、見合った報酬を与えます。機会の提供と支援するときに、EMは細かいやり方まで指示するのではなく、なぜそれが必要なのかを伝えながら、やり方については裁量を持たせることが大事です。
● メンバーとの信頼関係
大前提として、メンバーとの信頼関係が必要です。そのために、EM自身も弱みを隠さず開示し、適切にメンバーに頼ることが大事です。
またEM自身の想いや考えをストレートに伝え、まずはEMの方からメンバーのことを心から信頼し、メンバーの言葉をしっかり聞くことが大事です。ここでEMがメンバーの成長を疑っていたりすると信頼関係は築けません。EMはメンバーにとっての最高の味方になることを常に意識しましょう。
上長が何を考えているのかわからないという状態は信頼を損なってしまうので、適切な情報を開示することも必要です。
● 自分の考えを押し付けない
つい無意識に自分の考えを押し付けてしまうことがありますが、しっかりとメンバーの話を聞き、意見を聞くことが大事です。
「こうすべき」というものを押し付けてしまうと、自分の想像以下の成果にしか繋がりません。うまく行かないことを恐れて考えを言いたくなってしまいますが、メンバーにとっては自分で考えながらやる方がより高いやりがいを持てますし、そうやったほうがより高い成果につながることもあります。もしもうまく行かなかったとしても、その経験を通してより納得感のある学びとなり、次のチャレンジに繋げられるようになるので、むしろ小さな失敗ができるような環境を作ることの方が大事です。
◯ さまざまなイベントに対してEM自身も改善を繰り返す
1on1やふりかえり、朝会、ミーティングなどたくさんメンバーと関わる機会がありますが、より効果的な機会を作れるようにGROW、ロジカルシンキング、権限移譲、ファシリテーションなどEM自身も学習を続け、改善し続けることが重要です。特に目標設定と、評価については最も頭を悩ませるものですが、考えに考え尽くしてその時の最適と思える答えを出し、常に改善していくことが必要です。
その他にもチームの拡大のためにも採用・オンボーディング等も重要な役割の一つです。
まとめ
EMとしての役割についてプロダクトのビジョンからブレイクダウンする流れで説明しましたが、初めからこの順番で考えられるわけではないと思います。ピープルマネジメントをしながらプロジェクトの計画を見直したり、ビジョンを見直したりすることで、徐々に一連の流れを自分の言葉で言語化できるようになっていきます。
また、マネジメントの難しいところは、分かっていてもできるわけではないというところにあると思います。とはいえ前提となる知識は大きな助けになるので、常に勉強・実践・改善し、自身が最も成長するように心がけていきます。
参考
本
- エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング
- プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
- できるリーダーは、「これ」しかやらない メンバーが自ら動き出す「任せ方」のコツ
- THE TEAM 5つの法則
- 無理・無意味から職場を救うマネジメントの基礎理論
ポッドキャスト
Web
- Google re:Work
- エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
- Engineering Managerをエンジニアのマネージャーとするのはやめませんか？
- CTOの頭の中：技術投資を最適化する｜Shin Takeuchi｜note
- Engineering Managerの役割 - 組織と成果の視点から
- エンジニアリングマネージャーの成果とは
- エンジニアリング組織の仕事を考えることで、EMが学ぶべきことを体系化してみた
- なぜエンジニアリングマネージャー含む全マネージャーが権限委譲に苦しむのかを２０年間考え続けてどう組織を再設計およびエンジニアリングしたかの方法まとめ【前編：苦悩分析編】