はじめに
LITALICOの亀田です。執行役員VPoEとしてプロダクト開発や組織づくりに携わっています。
- Qiita: @kamesennin
- X(Twitter): ka_me_sen_nin
この記事は、LITALICO Engineers Advent Calendar 2023 の19日目の記事です。
来期に向けて色々考えていたら、いろんな効率性とシナジーを考えると、タイトルの内容でもう一記事書いちゃおうと思い、今年のアドベントカレンダーは3記事目です。
も是非ご覧ください。
本記事の前提0. エンジニアリングマネージャーとは
本記事での「エンジニアリングマネージャー」は、「担当プロダクトや開発組織の責任を負う」役割とします。（詳細の定義や役割は後述します。）
自社で運営する中で、いろいろ考えてこの定義で今取り組んでいるので、こちらを前提とします。
他にも異なる「エンジニアリングマネージャー」の定義はあることを観測しています。大切な視点なので一番初めに書きました。
本記事の前提1. 弊社の状況
会社の状況（事業、プロダクト、組織）には本記事の内容に影響を与えると思うため、先に記載します。
事業・プロダクトの概要
LITALICOの事業はかなり多種多様です。以下事業全体のポートフォリオです。
参考： 2024年3月期第２四半期 決算説明資料 株式会社 LITALICO
上記表を別視点で分解し、提供先観点で、様々なプロダクトが運営されていることを示す表が以下です。
このように、多種多様な様々なプロダクトがあります。 「専任のエンジニアリングマネージャーが必要なある程度独立した単位」を1プロダクトとした時に、20ほどのプロダクトが存在しています。
事業-プロダクトの特徴
上記にも表現されている通り、 「多くの問題を解決する1つのプロダクトを皆で磨き上げる」方針ではなく、「様々な領域にある課題を、様々な事業・プロダクトで解決していくこと」が、業界の特徴として求められます。
よって、事業種別にあわせ、プロダクト組織の規模、プロダクトの運用年数、システムの種類、なども多種多様になっていきます。（以下は、その状態を表現する図）
組織の概要
プロダクト開発やIT投資を推進する専門組織はざっくり以下のような人数規模です。
- エンジニア: 約200名
- デザイナー: 約30名
- プロダクトマネージャー: 約20名
外注はほぼなしの内製型の組織です。
エンジニアリングマネージャー中心に見た組織の構成は以下です。
また、エンジニア、プロダクトマネージャー、デザイナー、マーケター、ビジネスとの関係性は以下です。
エンジニアリングマネージャーの補足
1プロダクト辺り、1エンジニアリングマネージャー辺りのマネジメント規模は5〜10名ほどが大半です。あまり規模が大きくならないマネジメントを重視しています。
※たまにより大きな組織もありますが、サブマネージャーを付けた分担は意識しています。全てその通り上手くいってはいないので、組織課題です。（というか私の課題です。）
また
「1つのプロダクトを皆で磨き上げる」方針ではなく、「様々な領域にある課題を、様々な事業・プロダクトで解決していくこと」が、業界の特徴として求められます。
このような背景があるので、1つ1つのチームは出来るだけ小さく、軽く、立ち上げて運用が出来る組織である必要性が高いです。
そういった背景があるので、エンジニアリングマネージャーの役割は「担当プロダクトや開発組織の責任を負う人」と集約する方針に振り切っています。
これは事業ドメインから判断している組織戦略の結果です。大変な面もありますが、いろいろ試行錯誤した結果、この方針を良しとしています。
本記事の前提2. 役割の定義について
役割を考える記事なので、役割への考え方を少し書きます。
正解がないということ
企業のビジョン、ステップとなる目標や成果、達成に必要な戦略、戦略を実行する機能・手段、そういった機能や手段を実行するために役割の定義がなされると考えています。
手段・機能や役割は様々な組み合わせがあって、倣うべきスタンダードな手法はありますが、細部にわたって明確にこれという正解はなさそうです。
また役割が担う機能は、「チームにいるメンバーのスキル、事業上の戦略の中心やそれを実行する手段、過去の成功事例や失敗事例、マーケットの変化」などで変動するかまと思います。
エンジニアリングマネージャーにおける難しさ
「エンジニアリングマネージャー」も、組織ごとに様々な定義があると考えています。
そういった役割を定義していない企業様もあります。LITALICOも初期はありませんでした。
「エンジニア」と「デザイナー」という役割はまだ分かりやすいと思います。
なぜなら有する専門性がある程度異なるためです。
ただし、エンジニアリングマネージャーはエンジニアの中における役割です。
エンジニアという共通の専門性の中から、「エンジニアリングマネージャー」の役割を定義することは難しくなります。
前提0にも書いた通り、本記事においては「エンジニアリングマネージャー」は、「プロダクトや開発組織の責任を負う」役割です。
よって、抽象的な問題解決や広い視点での動きが求められます。
そんな曖昧性に向き合う中で、役割の定義も曖昧であることで、本人の認識と組織の期待値がずれます。そうするとチームのボールが落ちる、責任の所在が曖昧になる、チームに必要な専門性が不足する、などが発生します。
よって、重要な定義であるが、使い方を誤ると組織に混乱をもたらすこともあるのではと考えます。
本記事の目的
目的
上記前提を踏まえて、「世界に共通化して言える一般化されたエンジニアリングマネージャーの定義」はあまり世の中に示す提案としては最適ではないと考えて
- 「エンジニアリングマネージャーの役割は、どう定義し・運用すると良いのか」
を整理してみます。
補足
LITALICOでは本記事初めにも書いた通り、エンジニアリングマネージャーは欠かせない重要な役割です。
ただ多様な事業があるため、多様な企業から多様な技術や経験をされてきた方々が集まっているLITALICOだからこそ、組織内外でも、どういった役割なのかが分かりづらいという混乱は一定発生している認識です。
そういった問題解決にも繋がえれば良いと思い、本題の記事を書くことにしました。
本記事の目標
- エンジニアリングマネージャーという役割を定義する方法（周辺の機能）を言語化し、どのように考えると良いのか、1つの手法が提案できている状態
- 社内外でLITALICOに関わる皆さまがLITALICOでのエンジニアリングマネージャーの役割に納得感と安心感を持てている、大きなも迷いが大凡解消できる情報が提供できている状態
本題1. プロダクト開発に必要な機能
前提
まずプロダクト開発に必要な機能を整理します。
ビジョン、目指す目標・成果は組織ごとに異なります。
「戦略」と「戦略を実行する機能・手段としてのプロダクト開発に必要な機能」は一定一般化しやすいのではと考えているため、そこから切り出して考え出します。
必要な機能
まず、ビジョン-目標を実現するために、必要な機能を大雑把に整理します。
これらの機能を組織（複数名）で実行する場合が多いと思います。
組織で行うということは、上記機能を果たすために、他の機能（組織運営の機能）が必要となります。
そちらを追加した機能一覧を以下に表現しています。
以上の整理をまとめると、以下のような機能が必要なのではという整理が出来ました。
本題2. 必要な機能の実行者を分類
どんな場合であれ、大切と考える前提
- エンジニアリングマネージャーの定義の前にエンジニアはどこを担うかから始める、なぜならエンジニアリング領域に責任を負う立場なので、どの領域かの明確化は必須と考える
- 「戦略」にはその専門性に特化した責任者が出来るだけ必要である。なぜなら専門性なくして実効性高く適切な戦略を立てることは難しいと考えるため
- 各機能を十分な品質で実行するために必要な専門性は、ある程度は定義ができる
3職種でベースの分類を行う
プロダクト開発に携わる3職種を定義して、どの機能を一般的に実現できそうかを定義します。
- プロダクトマネージャー
- プロダクトマネジメントに関する知見を持つ
- デザイナー
- UXデザイン、UIデザインに関する知見を持つ
- エンジニア
- コンピューター、システム開発に関する知見を持つ
※実際は異なることもありますが、ベースがあると役割の設定の議論しやすいので、ベースを定めます。
具体的な運用での注意点
- 各職種の人が、一般的に言われている専門性をきれいに持つことは基本的にはありません
- なぜなら沢山の知識と経験が必要になるためです、凸凹が発生することは自然です
- また個々の今までの経験により、職種をはみだした経験や専門性を有することもあります
よってベースを持ちながら、それに固執しすぎずに、各チーム運営の時には、誰がどこを担うかは皆で議論して定めておくこと、特に1枚絵での可視化は重要と考えます。
担当範囲を定義する
場合によっては、「判断をする人、判断のサポートをする人、情報の共有を受ける人」などの定義もあるかと思いますが、そこまで書くと長くなるのと、本件とは異なるので割愛します。
出来るだけ役割が被らないように、誰がどこに責任を持つのかの明文化は大切です。チームメンバーが変わったり、成長したりで、最適な定義は変動するものとして、定期的にアップデートを検討すべきと考えています。
※仮に定義しただけです。社内運用の実態でもないです。
本題3. エンジニアリングマネージャーの定義
上記で定められたエンジニアの役割の中でエンジニアリングマネージャーをようやく考え出します。
3-1. マネージャーの役割とはから考える
何をするか
まずは、エンジニアに限らず、マネージャーの定義を自社で設定するのが良いです。
マネージャーへの期待値は共通であることで、より職種間をまたがった連携が分かりやすくなるためです。
ちなみに、私が考えるマネージャーの役割
以下3つです。
- 1.チームの成果に責任を持つこと
- 2.組織の成長と幸福に責任を持つこと
- 3.上記2点に関する説明の責任を持つこと
3-2. エンジニアリングマネージャーに落とし込む
何をするか
今まで整理してきた
- 「エンジニアの役割」 × 「マネージャーの役割」
でエンジニアリングマネージャーの役割を生成します。
ちなみに、私が考えるエンジニアリングマネージャの役割
以下3つです。
- 1.チームの成果に責任を持つこと
- ビジョンに必要な自組織が持つ目標の達成に責任を持ちます。
- 特にシステムと開発組織の2点はエンジニアならではのため、そもそも「何が成果」の定義も重要です。
- さらに「どういった戦略で」「どのような戦術や組織で進めるか」も定め、その実行にも最終責任を負います。
- 2.組織の成長と幸福に責任を持つこと
- チームの成果だけでなく、そこで働くみなの自己実現にも責任を持ちたいです。
- エンジニア特有の専門性や働き方の考え方があると思いますので、みながどんな成長がしたいか、どんな働き方がしたいかなどを理解することは大切です。
- 3.上記2点に関する説明の責任を持つこと
- 1と2がどんな状況か、どんな進捗でどのような対応をするかを会社に説明する責任を持ちます。特にシステムはブラックボックスになりがちです、上手く抽象化して周りへ説明することはエンジニアリングマネージャーだからこその重要な責務です。
- また「1.チームの成果」「2.組織の成長と幸福」は100%全て叶えられることは難しい場合が多いです。そのためどのようなバランスで進めるかを「判断し、チームの納得感を得ること」も大変重要な仕事です。
本題4. エンジニアリングマネージャーの定義を実行に落とす
上記で定めた、定義を実際に活用し、運用に載せるまでにも幾つか論点はあります。
企業によって異なるかと思いますが、社内でも議論してきたことを幾つか述べます。
技術スキルへの要求 => 全部が全部完璧に出来る必要はない
- エンジニアの役割と定義した機能へのスキルの不足は皆ある、1人が満たさなくて良い
- このように考えた方がスケーラビリティある、属人性が低い組織になります。
- 各種専門性は誰が持つかは重要ではなく、チームで満たせば良い
- 専門性の不足には注意すべき、足りないと上手く進まなくなる事が多いためです。チームでその専門性が補填されていれば良いです。
- 自身の得意と苦手を理解し、必要なチーム体制を定義できれば良い
- 機能で定義したように、人や組織、プロジェクト運営、技術的判断など幾つか視点はありますがどこが苦手でも良いです。
- 一方何かしら得意な部分は大切です。専門性なくして専門組織を率いることはチームの心情的にも中々大変であると思うからです
- ここなら成果を出すために自らの手で十分自信を持って率いることが出来るくらいが良さそうです。
採用や登用要件が大変厳しい => 組織全体でフォロー&やりながら成長
- エンジニアリングマネージャーの上長によるフォロー体制をつくる
- チームでのフォローと理想を書きましたが、機能も多様なので全チームでそのようなフォロー体制は組みづらい場合が多そうです。
- そこでCTO、VPoE、開発部門長などトップマネジメントがフォローに入ることはある程度必要な前提に立っておいた方が安全と考えます。
- 気軽に相談できる関係性があるかも大事そうに思っています。
- エンジニアマネージャーの責務は1-2年のスパンである程度果たせれば良い
- 上記フォローを通して、徐々に出来るイメージが湧き、経験が詰めれば十分という期待値くらいが心理的安全性が高いし、スケールしやすいと思います。
- ただ表に立って「責任を果たす（説明なり検討なり）」ことはややストレスもかかり大変ではあります。
どういったキャリアになるか => 幾つものキャリアが描ける
- 事業会社（あるいはその中の1つの事業）のCTOやVPoEなど技術経営者
- 事業戦略を理解しながら、システムの戦略面から組織面やプロジェクト面など責任を負う立場なので、いわゆる会社の広い範囲からの技術組織を考える訓練が存分に出来ると考えます。
- テックリードやソフトウェアエンジニア
- 非公式でも、責任を負う機会を通すことで、最終責任を負う人が何を大切に取り組むのかの視点をもつテックリードやソフトウェアエンジニアは、大変心強いパートナーかつ強い個になりそうです。
- 正式にエンジニアリングマネージャーをやらずとも責任を負って考えてみるという経験は良い経験と思います。
- プロダクトマネージャーやプロジェクトマネージャー
- 技術戦略や開発組織を理解したプロダクトマネージャーやプロジェクトマネージャーは大変強みになる点が多いと実感しています。
- なぜならプロダクトの成功要因の多くをエンジニアリングが占めるため、そこの解像度（コスト、規模、品質、難易度、などなど）が高ければ高いほど、多くの変数の中で判断する役割に生きると考えます。
- 戦略を考え、成果に責任を負う経験もしているので、プロダクトやプロジェクトに責任を負う、戦略を考えることにも直結しやすそうです。
- エンジニアのHR組織
- エンジニアの実務としての業務、組織やPJの進み方、技術についてある程度網羅的に触れることになるのはHR組織における強みです。
- 採用活動や組織づくりを行う際に、どれだけ現場の解像度高く持てているかは、適切な課題・施策策定、組織への納得感ある説明と実行に効果的な要素となるためです。
- エンジニアという職種上、特有の働き方、採用、制度設計は多くあると思うので、HRの専門性と技術の専門性の両軸を有することは大切と考えます。
最後に
「丁寧」に考えたら、大変長くなっていしまいましたが、ここまで丁寧に毎回考える必要もないです。理由は変化が多いと、わざわざ毎回考えるコストが高くなりすぎるからです。
ただし、曖昧になりやすい部分なので、一度はある程度のフレームを持って考えきること。今はどこを欠けていて、どこを強化すべきかを理解しておくことは、特にエンジニアリングマネージャーを定義する領域においても重要と考えるため整理しました。
組織とは、ちょっとしたことで大きく働く人達の幸せや社会へのインパクトが変わるものと日々感じます。
さらには、変化の速度も激しくなっている中で、誠実に素直にあるべき状態と自分たちの変化すべきポイントに向き合いながら、みなで成長しあっていけるチームをつくりたいです。
こんな考え方も大事にしている私でありますが、興味もって下さったら方、ぜひご連絡をください。
X(旧Twitter): @ka_me_sen_nin
それでは、明日のLITALICOのアドベントカレンダーは20日目です。
- 新卒内定者の @ryunosuke_sako さん
- 介護プロダクトのテックリード @qtakechan さん
- QAチームのボスの1人 @abekyo さん
です。
まだまだまだまだ、弊社のことを発信していきますので、引き続きご覧くださいませ！
前回（マトリクス型のIT組織(250名)かつ多様な事業がある企業でIT投資戦略を策定する10のステップ）の記事の最後に
僕はこれで今年のアドベントカレンダーも終わりです。
少し早いですが、来年も引き続き、LITALICOをよろしくお願いいたします！
のように書きましたが、本記事が書けてしまったので誤りでした。
しかし、今度こそ、ほんというに今年もありがとうございました。
来年も引き続き、LITALICOをよろしくお願いいたします。