トーク

概要

エンジニアリングマネージャー(EM)の役割は多岐にわたり、プレイヤーとしてのエンジニアからEMへ役割を変えることは大きな挑戦を伴います。キャリアが連続的なものではないが故に、そしてEMとしての理想的な姿を体現することの難しさから、EMへの役割転換に対して積極的なエンジニアの数は決して多くはありません。一方で、優秀なEMを採用することの困難さはemconf参加者のみなさんならば説明は不要かと思います。

私が所属するestieでは、EMという役割に興味をもったエンジニアに対して、EMへの成長の機会を提供する制度として「Potential EM」という役割を定義し、約2年前に運用を開始しました。この制度は、マネジメント経験のあるメンターEMと壁打ちをすることを通して、チームメンバーの能力を最大限に引き出す能力を獲得することを促します。自身にEMとしての適性があるかどうか、やってみる前に判断するのではなく、EMとしてチャレンジする過程を経て、続けるかどうかを意思決定してもらいたいという意図が込められています。結果として、約2年間で5名がPotential EMを経て正式にEMとなり、今も活躍をしています。

このように組織や事業の成長に大きな貢献があったPotential EM制度ですが、実は最近になって私たちはこの制度の廃止を決定しました。

本セッションでは、2年ほどPotential EMという制度を試行錯誤しながら運用する中で感じたメリット・デメリットや、最終的に廃止という意思決定をした背景、どのような組織であれば適用をオススメできるかなどを共有します。

Learning Outcome

組織拡大にあたってEMの仲間を増やすという選択肢を検討しているみなさんへ、実践的なアプローチのひとつをお伝えします。また、試行錯誤のプロセスを共有することを通して、いくつかのエッセンスを持ち帰っていただきたいと思います。

概要

株式会社スタンバイで VPoE（など）をさせていただいている高原です。
この場に集まられたみなさんですので、なにかしら現場で「もっとこうしたい」「もっとできるんじゃ？」と考えられているのではと思います。
もちろん私（私たち）もそうで、メンバー1人1人の個性に向き合って業務とキャリアを接続するとか、チームの開発プロセスに障害を見つけて取り除くとか、具体を見て→考えて→取り組むを繰り返しています。
そんななか、チームを横断して「開発組織全体」を見て→考え→取り組んでいることがあるのでご紹介したいと思いました。

具体も大切だが、抽象へのアプローチも必要かもしれない、という問いや議論の種にできればと思います。

我らがプロダクト部門のマネージャー全員で、今年度の上半期に「マネジメントポリシー」を作成し、部門内に宣言しました。
その背景には、事業のアジリティを高めたいという渇望と危機感から逆説的に得た「チーム横断で組織運営に取り組む必要性」への気づきがあり、あらためて組織ビジョンを見直し、リストーリーを行い、各マネージャーが実現したい組織状態を表す言葉を示し合い、それらを結集したマネジメントポリシーを作り上げました。
そして「作っただけ」で終わらないよう、このポリシーをちゃんと実践して、実際に良くなった！変わった！（そもそもの目的である）アジリティが高まった！という状態を実現するために、マネジメントポリシーの実行や効果を評価する仕組みを定めて、自分たちに課すことにしました。
（もちろん、その仕組みも経験学習によってカイゼンするという宣言込みで）
Pace Layering モデルの深いところにある「カルチャー」を動かそうとする挑戦の経緯とエピソードを共有させていただければと思います。

Learning Outcome

• マネジメントポリシーの具体的な内容や作成手順を知れる
• マネージャー達がこういうことを一丸となって行った背景や経緯を知れる
• マネジメントポリシーのようなものにちゃんと実効性を伴わせるべく、評価する仕掛けを考えた議論の経緯をリアルに追体験できる
• 議論を突き詰められた理由が、アジャイルな“Go See”の姿勢であることを知れる
• 今後の展開について共に議論させていただくベースの話題を共有できる（発表者のアウトカム??）

概要

こんにちは、新米VPoEです。

エンジニアリングをマネジメントする立場として、技術そのもの、あるいはチームやメンバーを向いた方法不確実性に向き合っていくだけでなく、経営との対話を通じた技術組織の価値を最大化するための目的不確実性に対して解を探し、戦略を立てていくことも重要です。

方法不確実性が指す技術戦略には、技術ロードマップや負債管理などテクニカルなもの、プロダクト戦略やバリューストリームなどユーザー価値にフォーカスしたもの、従業員エンゲージメントや採用プレゼンスなど組織的なもの、などが複雑に関連します。目的不確実性は、それらの戦略をなぜ志向するのか、どういった効果を狙うのかに関する説明責任などを指します。

その際、ハーバードビジネススクールで提唱された「バリューベース戦略」の考え方に基づき、開発組織が出す価値の最大化を目指し、組織全体のエンジニアリング価値を黒字化する戦略フレームワークに基づいた戦略の立て方について紹介します。
また、弊組織においてその戦略を適用させてきた実践過程について紹介します。

Learning Outcome

• 技術戦略と経営戦略を接続する一つの方法論として、バリューベース戦略というフレームを当て嵌めてみた事例
  • そもそもの技術戦略ってなに？
    • プロダクト価値の戦略：ユーザーへの提供価値、バリューストリーム、、
    • テクノロジーの戦略：技術投資、負債管理、、
    • 組織の戦略：エンゲージメント、採用プレゼンス、、
  • バリューベース戦略ってなに？
    • 顧客の支払い意思額と従業員の売却意思額の差分を価値とする、という戦略フレームワーク
    • ざっくりいうと売上ー原価＝利益と同じ構造
  • 技術戦略とバリューベース戦略がどう関連するの？
    • ★ここがコア
• 開発組織全体見て欲しいと言われてから戦略と実行をどのように模索してきたかの追体験

概要　

従業員数約1000人/売上高100億円程度だった頃に入社した企業が、グループ連結で従業員数約1.4万人/売上高1100億円を超えるまでに成長。
領域もソフトウェアテストと品質保証だけだったところから、開発、ERP、セキュリティへと広げてきました。

このセッションでは、その激動の渦中に7年間いた自分が、VPoEになるまでの歴史とこれから挑戦したいことについて語ります。
段階的に多くのエンジニアを配下に抱えるにつれて、エンジニアのキャリアを支援する方法を考え、エンジニアが輝ける制度の設計をするようになりました。

現在、私の企業ではこれらが実現しています。
・スキル/成果重視の絶対評価制度
・年間昇給率平均11％ 　
・年間2000人の採用と退職率6%
・職級の細分化と定義の整備
・キャリアマップ
・フェロー制度
・検定/研修/勉強会/イベント
これらの詳細とその効果を共有します。

そして次に挑戦しようと思っていることは、活躍するエンジニアに提供する新しいポジションの設定です。「スタッフエンジニア」などを参考に、考えられるポジションをアメリカの事例などを元に洗い出し、まだ構想段階の内容を紹介することで、参加者とのディスカッションへ繋げられれば幸いです。

Learning Outcome

• スキルと成果に応じたエンジニアの評価制度とその効果
• エンジニアのロールやポジションの設計
• メンバーのキャリアを明るくするために制度設計から考えるVPoEの目線
• 事業会社にはない、SIerのジレンマ

参考

『エンジニアのキャリアパス。管理者以外の選択肢をつくる意義』
https://recruit.shiftinc.jp/career/library/id1295/
『トップエンジニアが輝ける制度の導入と障壁（エンジニア組織の未来 vol.1） 』
https://recruit.shiftinc.jp/career/library/id1343/
https://www.youtube.com/watch?v=m6oPRUwON_Q

概要

エンジニアリングにおける開発生産性の追求から始まり、事業価値、そしてその先の社会的価値(インパクト)への思いを馳せながら、インパクトスタートアップにおける価値創造のプロセスと、それを支えるエンジニアリング組織の文化醸成について、具体的な実践知を共有します。

▼ 具体的な内容 

• ① 事業軸：企業価値からエンジニアリングの開発生産性まで、その方程式を紐解く。EMに求められる事業視点や戦略定義、構造分解について解説
• ② 技術軸：開発指標（FourKeys）と組織能力（DORAケイパビリティ）を活用した生産性向上の取り組み。定量的な可視化から改善施策の実装まで、具体的な学びを共有
• ③ 組織軸：EMが向き合う3つのマネジメントサイクルの解説。継続的な目的達成とモチベーションの関係性を構造化し、エンジニア組織の課題発見と文化醸成への取り組みを紹介

▼ INDEX

① 事業軸

1. 突如、EMに求められる事業視点！？
2. エンジニアリングにおける「戦略」とは？
3. エンジニアリングと事業価値、社会的価値の方程式
4. 開発生産性の方程式の構造分解

② 技術軸

1. 「開発生産性」を掲げた背景
2. ケイパビリティの課題を発見する ( 定性軸での課題発見 )
3. 開発指標の現状把握と普及推進 ( 定量軸での課題発見 )
4. FourKeysの導入を振り返る
5. コードと価値を中心に据える

③ 組織軸

1. EMが意識する３つのマネジメントサイクル
2. マネージャーの役割を明確にする
3. 事業成長の源泉となる文化醸成を根幹に据える
4. エンジニアリングに意義と楽しさを見出す
5. 組織課題を構造化して整理する

Learning Outcome

▼ 対象者

• 事業価値とエンジニアリングの接点に悩むEM
• インパクトスタートアップや中規模企業でエンジニアリングマネジメントを担当する方々
• 組織の成長と技術的な進化の両立を目指すエンジニアリング組織のマネージャーや責任者

▼ 得られるもの

• エンジニアリングと事業価値、社会的価値を接合する方程式
• 開発生産性向上に向けた方針策定とケイパビリティの課題整理、効果測定の視点
• エンジニアリング組織の文化醸成と成長を促進するための構造

概要

Engineering Management（以降EM）を調べてみると思うこと…「役割多すぎっ！」
エンジニアリングマネジメントトライアングルを見ても「こんなにできるかよっ！」と思ってしまいます。
「EMを任されたけど私は何をしたら良いんだ！？」と悩ましい気持ちになってしまう方もいるかもしれません。
何を隠そう私も一瞬悩みました！が、悩んでもやれることは増えないのですぐに悩むのをやめました。

それからはEMの役割を拡張するのをパズルのように捉え、ジョジョに拡張することにしました。
このセッションでは、EMとしてやれることを増やしていくためのEM拡張パズルの流れ・ポイントを私の実例を交えながら紹介します。

EM拡張パズルの流れ

1. 今できていることを認識する（現在のパズルの形をイメージ）
2. 組織やチームの課題の中で一番重要なものを突き止める（次にピースをはめたい所を考える）
3. 一番重要な課題を解決するために自分がやれそうな事を考える（どんな形のピースがいいか考える）
4. 自分がやれそうな事をやれるようにする（ピースを作ってはめる）
5. 1.に戻る

例えば…（受託アジャイルのコンテキスト）

1. チームメンバーのエンジニアリングスキルは十分にある
2. 顧客からの評価が高くない。顧客が作って欲しいと言ったものは作れているがビジネス面で効果が出ていない
3. プリセールスの時点で、顧客をより理解するヒアリングをする（顧客の現状や達成したいことなど）
4. 作りたいものではなく、顧客を理解するためのヒアリングの流れを考えて脳内シミュレーションしまくる。そして実践！

これで私たちは顧客のニーズを捉えたエンジニアリングができるようになりました！
小さいパズルのピースがカチッとハマり、EMである自分自身としてもできることが増えました！

EM拡張パズルのポイント

• 出来ないこと全てを一気に相手にしない
• 組織やチームの課題からフォーカスするところを１つだけ決める
• やれることが増えたことを噛み締め1人でも嬉しがる

ターゲット

• EM任されたけどそんなに色んなことできないよと悩んでいる方

Learning Outcome

• EMに対する数多ある期待に対して、ジョジョに小さいステップで対応していく方法、ポイント

概要

エンジニアからマネジャーへの転身は、転職に例えられるほど異なる世界への参入といわれます。
マネジメント業務に没頭する中でエンジニアリングスキルの低下を懸念する方や、その不安からEMへのキャリアを躊躇するエンジニアも少なくありません。

そんな葛藤を打ち砕くため、私はエンジニアかマネジャーかという二者択一ではなく、"二刀流"という選択肢を提案します。

本講演では、過去10年でエンジニアとEMを各2回経験した講演者の実践知を共有し、キャリア論・認知科学・マネジメント論を織り交ぜた二刀流キャリアの有効性と再現性について考察します。
実践の道半ばではありますが、同じ葛藤を持つ方の心に火を灯せる講演を目指します。

対象者

• エンジニアリングとマネジメントの両立に悩むEM
• EMをキャリアとして検討しているエンジニア

話そうと考えていること

1. 講演者が二刀流を意識して実践してきたこと
   • 横断的な組織課題の発見と解決、1on1や採用を通じた技術理解の深化、大型技術カンファレンス登壇機会の創出
   • Engineering Manager Meetupの立ち上げによるコミュニティ活用
2. 二刀流キャリアの可能性・再現性の考察とヒント
   • 柔軟なキャリア形成の可能性を提示する振り子モデル・キャリアラティス・計画的偶発性理論
   • 学習の転移、抽象と具体の行き来（意味波）によるスキルの同時向上

この講演を検討すべき理由

2019年の拙稿「EMになってから技術力が伸びるパターン」の少なからぬ反響を通じ、冒頭で述べた不安や葛藤が現実にあることだけでなく、提案するキャリア像に関する議論が不十分であることを私は感じました。

そして、その状況は2024年において依然として存在するとおり、本講演を通じてさらなる議論の土台を提供したいと考えています。

Learning Outcome

EMの役割を活かしながら技術力を伸ばすこと、あるいはエンジニアとしての経験をEMとして活かすための具体的な方法論を提供します。
また、振り子モデル等の柔軟なキャリア形成の視点を紹介しつつ、聴講者がキャリアの不安や葛藤と戦うために実践できる具体的なアドバイスを提供します。

概要

あなたはEMとして憧れの会社に採用されました。これから、輝かしい新しい仕事がはじまります。
しかしあなたは不安もたくさん抱えています。メンバーは自分を受け入れてくれるだろうか。うまく仕事を軌道に乗せることはできるだろうか。

EMのような、比較的ハイレイヤーな人が外部からやってくることを「パラシュート人事」と呼ぶことがあります。これは一般的にネガティブな使われ方をする例が多い言葉ですが、マネージャーを受け入れるメンバーからすれば、得体のしれない恐怖の大王のような、強い権力を持った人が突然空から降ってくるようなものです。

組織のカルチャーをまだ深く理解していない。人間関係が構築できていない。なのにマネージャーとして成果を出さないといけない！！そんな状況に置かれたEMにとって最も重要な最初の100日をどう過ごせばいいのか。

前職でEMとして採用されて3年を過ごし、今また2024年の5月に別の会社でEMとしての仕事をスタートさせたわたしが過ごした「最初の100日」の様子をご紹介して、この問題を以下のトピックに沿って一緒に考えていきましょう。

• 「最初の100日」のもっと前
  • 入社後の期待値調整
  • 入社前に以下のことをすりあわせる
    • 入社直後の最初の動き方
    • 組織の課題と、それをまずはどう扱っていくか
    • 自身の中期的なキャリア
• 入社直後
  • 慌てて所信表明をしない
  • 観察！観察！観察！
  • 100人との1on1
  • 改善に手を付ける前にバックログを作る

• どうなってから具体的に手を動かしていくのか

  • 人間関係ができている
  • 組織のカルチャーや歴史を理解している
  • 過去の人たちが成してきた仕事やつくってきた仕事に敬意を持てている

  Learning Outcome

• EMとして新しい組織に入った最初の行動のイメージを持つことができる
• 他のEMがどのように組織に入っていくのかの一例を知ることができる

概要

エンジニアリングマネージャー（以下EM）の役割は、自チームの成果を最大化するだけでなく、他チームの成果にも貢献することです。EMのアウトプットは、「自チームのアウトプット＋影響を与えた他チームのアウトプット」と言って良いでしょう。これを最大化するためには、適切な権限委譲とマネジメント範囲のコントロールが不可欠です。
しかし、多くの組織ではチーム横断的な意思決定が後回しになり、チーム内課題に注力しがちです。結果、チーム間の局所最適化・CxO/VPoEなど上層部の意図とEM間の認識ズレ・EM間のサイロ化などの問題が生じます。

これらの課題に対応するため、我々の会社では「エンジニアリングマネジメント部」を組成しました。従来の階層型組織構造から脱却し、より柔軟で効果的な「共創型リーダーシップ」を採用しています。各EMが組織全体の戦略立案と実行に積極的に参加し、相互に影響を与え合いながら意思決定を行います。

このあり方は以下の特徴があります
・権限の分散: 各EMに重要な決定権を委譲し、状況に応じ委譲のレベルを調整
・集団的意思決定: 最終判断はEM全員とVPoEの合意で形成
・戦略的一体感: 全社の方針と各チームの活動の整合性を確保
・フラットなマネジメント組織構造: 従来の階層を緩和し、柔軟な連携を促進

個々のEMのビジョンや専門知識が組織変革の触媒となり、全員で議論を重ね、そのアイデアがさらに磨かれ、増幅されます。各EMの独自の視点が、組織全体のイノベーションと成長を加速させる原動力となるのです。
本セッションでは、我々の会社のマネジメント・組織体制の変遷を紹介しながら、現在の組織のあり方について説明します。また、この取り組みによる成功事例と直面した課題、そしてその解決策についても共有します。

Learning Outcome

対象聴衆
・広い影響力を持つEMを目指す方
・マネージャー層育成に課題を感じるEM
・EM中心の組織設計に興味がある方
・サイロ化や局所最適化に直面している方
・チーム間連携強化を目指す方

得られる学び
・広範囲なEMへの成長プロセスと必要スキル
・EM中心の組織設計の実践例と導入プロセス
・チーム間連携強化とサイロ化防止の具体策
・CxOの意思決定とEMの実行をつなぐ効果的方法やアイディア

概要

エンジニアリングマネージャー(EM)の役割において、「プレイングマネージャー」は従来、アンチパターンとして扱われることが多く、多くの組織で避けるべき実践とされてきました。
その背景には、マネジメント業務の軽視や、組織の俯瞰的視点の欠如、プレイヤーとしてのボトルネック化といった懸念が存在します。

しかし、スタートアップをはじめとする小規模組織や、サービスの垂直立ち上げフェーズにおいては、プレイングマネージャーが組織に独自の価値をもたらす可能性があります。

また、多くのエンジニアが通る、インディビジュアルコントリビューター(IC)からEMへのキャリアトランジションにおいて、
自身の強みを活かしながら、EMとしての役割を段階的にシフトさせていくことを可能にする重要な選択肢となりえます。

本プロポーザルでは、カミナシでの新規事業開発において、EMとして約半年間実践してきた経験をもとに、
「意思を持って選択的にプレイングマネージャーを実践する」という新しい可能性を提案します。

単なる状況への対応として結果的にプレイヤーとなるのではなく、戦略的な選択としてのプレイングマネージャーを位置づけ、EMとして実践してきた取り組みと、そこから得られた具体的な知見を共有します。

プレイングマネージャーという選択肢を、単なるアンチパターンとしてではなく、組織とキャリアの文脈に応じた戦略的な選択として、改めて捉え直すため機会になれば幸いです。

Learning Outcome

対象の聴衆

• 今、実質的にプレイングマネージャーのような動きになってしまっているEMの方
• ICからEMになったが、いまいち自分の強みを発揮できてないと感じているEMの方
• 今後EMにチャレンジしようと思っているが、自分の役割をイメージできない方
• サービス立ち上げを牽引するEM不足にお悩みのCXOの方

得られる（かもしれない）もの

• EMとしての役割を能動的に選択していく意義と、自身のEMとしての振る舞いを再考する機会
• アンチパターンとされるプレイングマネージャーがワークするための制約
• プレイングマネージャーがキャリアパスに与える価値
• サーバント型EMとプレイング型EMの相補的な関係

概要

2023年1月に VP of Enginnering というロールを引き受けた時、経営/プロダクトともに難しい状況下にあり、エンジニアも5人退職することが決まっていました。

そのようなサバイバルモード状態から今まで、事業や組織に対してやっていったこと、うまくいったこと/いかなかったことを振り返ります。
どちらかというとうまくいかなかったことの方が多く、かつ実は今もまだサバイバルモードから完全に脱しているかというと怪しいところではありますが、少しずつ少しずつよい方向に進めてきています。

この発表では、本やブログではあまり聞けないような厳しい状況下でのエンジニアリングマネジメントを、なるべく疑似体験できるように話していきます。
自分自身の振り返りの機会にすることはもちろん、皆さんが今後同じような状況になった場合にどうするか想像しながら聞いてもらい、血肉としていただけるような内容を目指します。

以下のような内容を盛り込んでお話する予定です。

• 自分自身も納得がいかないような経営/プロダクトの方針が伝えられた場合にどうするか
• 新規の採用活動を一時的に止めることになった時の動き方
• あの時知っておきたかったPLと予算、投資の考え方
• エンジニアリング組織以外の隣接領域に根っこの課題があると感じた時にやったこと、やるべきだったこと
• キーマンに退職を切り出されたらどうするか
• 今最初に戻れるならやっておくべきこと、今からでもすぐに取り組んでいくこと

Learning Outcome

• サバイバルモード下で半ばパニックになりつつ踏ん張っているマネージャー、チームリードに対して、N=1の体験談と勇気を提供します
• マネージャーロールを担っている方に対して、実体験せずに済むに越したことがないようなナレッジと疑似体験を提供します
• エンジニアリング組織以外に根っこの課題を感じているがどうすればいいかわからない無力感でつらくなっている人に対して、引き出しの一つとなるような動き方を提供します
• 他社のうまくいったマネジメントエピソードを見聞きして凹んでいる人に対して、たぶん皆そんなことばかりじゃないよと思えるような愚直でリアルな話を提供します

概要

製品の開発・運用を通じて価値を提供し、事業を成長させる企業にとって、エンジニアリングマネージャー（EM）は極めて重要な役割を担っています。これまで、以下のような環境でマネジメント経験を積んできました。

• 会社規模：大企業、ベンチャー、GAFA
• 製品属性：SIer、toB、toC
• マネジメント規模：5名～40名
• マネージャーの役割：エンジニアリング、プロダクト、プロジェクト、技術サポート、バックオフィス、役員

この経験を通じて学んだ以下の点についてお話できればと思います。

• マネージャーが果たすべき4つの仕事
  ・これを怠るとどうなるのか、どのような経験からこの重要性に気づいたのか

• それに必要な4つの力
  ・「言語・資料化」「共感力」「推進力」「知識」はどういった内容で、どうマネージャーの仕事に紐づくか

株式会社ラクスでは、「思考力」「行動力」「人間関係力」「組織推進力」の「コンピテンシー」を大切にしています。
また、開発本部では製品づくりをするエンジニアが顧客に成り代わり課題を認識し、「顧客志向」で製品開発をしています。

これらをふまえEMに求められる「コンピテンシー」の具体的な中身とこれを実際にどのように実践しているかについてもご説明します。

Learning Outcome

• マネージャーにおいての大切な仕事の理解
• そのために必要な能力の理解
• EMとしてその能力を身に着ける・発揮するためのコンピテンシーの理解
• どう実践すると成果につなげられるか

目次

　１．マネージャーの仕事とは？
　２．自分の経歴の変遷の紹介
　３．マネージャーでの成功/失敗体験
　４．マネージャーの仕事に必要な力とは？
　５．EMに必要なコンピテンシーとは？
　６．現在、実践していること