トーク

概要

「若手の育成」
若手エンジニアを対象に実施している、「事業成長×自己成長」を軸としたキャリア支援の取り組みについてお話しします。
意志ある目標設定を促すため、マネージャーとの対話を通して深掘りができるキャリア支援シートを作成しました。
・メンバー自身の持つ特性や強みのタネを見つける自己分析
・会社が求めるエンジニア像のインプット
・事業の向かいたい先
まで、このシートを用いて、1年後、2年後の未来を想像して目標に落とし込むという取り組みです。
当日の発表では具体的なシートについて一部紹介をしながら、現場の若手エンジニアのキャリアに対するモチベーションの変化や、解像度がどう変わっていったのかの
数値的振り返りについても可能な限りシェアしたいと思います。

「トップラインを伸ばす育成」
中堅以上のプレイヤーを対象に実施している、「事業成長リードを狙う領域特化の育成プログラム」の取り組みについてお話しします。
組織が強めていきたい領域のプロフェッショナルを育成していくための取り組みとして、領域特化育成制度を立ち上げました。
・抜擢メンバーに領域特化の目標、ミッションをセットする
・該当領域の成長支援のメンターと並走してミッションを遂行
・最終的には事業成長をリードする事例を作り出すことを目指した視点で本人がロードマップを描く
という流れで、中堅以上のプレイヤーへのミッションセットと成果追求の考え方をお話しします。
ミッションセット〜育成まで実際に取り組む中での試行錯誤のリアルを伝えられたらと思います。

Learning Outcome

「若手の育成」
若手プレイヤーの立ち上げに関わるEMの方に特に聞いていただきたい内容になります。
・スキル成長についてマネージャーと本人で共通認識を持つこと
・そこから強みや伸び代ポイントを明確にしてキャリアに繋げる会話
・本人の自己成長のモチベーションを引き出しつつ、事業成果と掛け合わせる環境づくり
この辺りを参考にしていただけるかと思います。

「トップラインを伸ばす育成」
若手の育成のその後について、中堅以上への求め方という角度で育成の参考にしていただきたいです。
・事業✖️技術の視点でメンバーの強みを伸ばすとは
・取り組む中でうまくいったこと、いかなかったこと
この辺りを参考にしていただけるかと思います。

概要

あなたのチームでは、開発プロセスの中で作業の重複やお見合いが発生することはありませんか？

プロジェクトの進捗を妨げる要因の一つに、PM（プロダクトマネージャー/プロジェクトマネージャー）、EM（エンジニアリングマネージャー）、TL（テックリード）、Eng （エンジニア）の役割が曖昧で、無駄なコミュニケーションやボールが落ちたままの状態になることが挙げられます。

弊社 PIVOT では、「誰が何をいつ行うべきか」が不明確であるが故に、開発プロセスが停滞することがありました。本セッションでは、RACIマトリックスを活用して役割と責任を明確化し、開発プロセスと成果物を整理したことでスループットが向上した具体的な取り組みを紹介します。

また、現在の課題はサービス品質の維持と向上。現在取り組んでいる QA プロセスの改善や今後の展望についてもお話しします。

Learning Outcome

• 役割の曖昧さと重複やボールが落ちたままの状態を解消する具体的な方法
  • PM、EM、TL（テックリード）、Eng の役割を具体的に定義し、重複や曖昧さを解消した実践的な方法
  • 開発プロセスにおける「お見合い」や「人任せ」の状況を改善し、スループットが向上した具体的な手法
• チームメンバー間の信頼と自主性を高める方法
  • メンバーが自分の役割に自信を持ち、「ここは任せとけ！」という主体的な意識を醸成するアプローチとチーム作り
• 継続的なプロセス改善と新たな課題への取り組み方
  • チーム全体でプロセス改善に取り組み、変化に柔軟に対応できる文化の育て方
  • 新たに発生する課題やQAプロセスの改善に対して、どのようにアプローチし解決していくかの方法を紹介

概要

急成長スタートアップにおいて、エンジニアリングマネージャー（EM）からTech Recruiterへとキャリアをシフトすることで、組織にどのような価値をもたらすのか？
このトークでは、EMとしての経験を活かし、エンジニア候補者の視点に立った採用プロセスの設計や、チームにフィットする人材の見極め方について実践的な事例とともに紹介します。また、エンジニアリングチームが事業へ集中する時間を確保しながら、採用を成功させ続けるためのメリハリの付け方とトレードオフについても触れます。採用に多くの時間を割かざるを得ないEMの方々にとって、採用業務と他の責務のバランスを取るためのヒントになると幸いです。

Learning Outcome

• EMからTech Recruiterに転向することで得られる独自の視点と強みを理解する
• エンジニアリングチームが事業へ集中する時間を確保しつつ、採用を成功させ続けるためのメリハリの付け方とトレードオフを学ぶ
• 採用に多くのリソースが割かれる状況で、採用業務と他の責務をチーム全体でバランスよく管理するための実践的なヒントを得る

概要

エンジニアとEMは異なる道と思われがちですが、EMの経験は意外にもエンジニアとしての視野を大きく広げてくれます。
本セッションでは、スタートアップのエンジニアがEMになって半年で経験した、インフラコスト削減、採用面接の効率化、メンバーの退職対応といった具体的な取り組みを通じて得た学びを共有します。
マネージャーの意思決定の背景を理解し、チームメイトを技術面と文化面から評価し、組織が重視する指標を把握する。さらに、評価者としての1on1を通じて効果的なフィードバックの方法を学ぶ。これらの経験は、実はエンジニアとして働く上でも大きな価値を持つことが分かってきました。
EMの視点を得ることで、組織やチームをより深く理解し、エンジニアとしてもより効果的に活動できるようになる。そんな可能性が広がる瞬間を、具体的な事例とともにお伝えします。

Learning Outcome

• EMの視点を知ることで、エンジニアとしての活躍の幅を広げるヒントを得る
• EMとして直面する課題と、それを乗り越えるためのアプローチを学ぶ
• チームの一員として、より効果的に活動するための視点を理解する

対象：

• キャリアの次のステップを模索しているエンジニア
• チームや組織の課題に関心のある方
• これから誰かにEMを任せてみよう、という方

概要

エンジニアリング組織のトップとして外部から新任のCTOを迎える際、Engineering ManagerやVPoEとしてその移行をサポートすることは非常に重要です。このトークでは、CTOのオンボーディングプロセスをどのように設計し、組織のスムーズな移行を支援するかについて、外部採用の視点から具体的な事例とともに紹介します。特に、周囲が「お手並み拝見」となりがちな雰囲気の中で、建設的なチームワークを促進する工夫や、新任CTOへの過度なサポートを避けつつ、自主性を尊重しながらも適切な支援を提供するバランスの取り方について触れます。また、オンボーディングにより得られる組織全体の成長や信頼関係の構築についても考察します。

Learning Outcome

• 外部から採用されたCTOを迎え入れるための効果的なオンボーディングプロセスの設計方法を学ぶ
• 新しいCTOとのコミュニケーションと信頼関係の築き方を理解する
• 周囲の「お手並み拝見」ムードを建設的なものへと導く方法や、サポートと自主性の尊重のバランスについて知る

概要

タイトルの「お手並み拝見をしない」はよく言われるフレーズだと思います。

新しいメンバーをチームが受け入れるにあたって、まずは力試しだとばかりに不十分なサポートで難しい仕事をやらせてみるやり方・周囲のそういう姿勢は百害あって一利なしである、壁際で腕組みして「どれどれ」とするのはいけないのだと。

新しくチームに参画する人が、「チームから受け入れられていない、このチームでは必要な支援が受けられない、仕事の成功ではなくストレス耐性を要求されている、減点方式で評価されそうだ」と思ってしまうのは、ふつう、その人のパフォーマンスによい影響を与えません。オンボーディングにおけるそれはアンチパターンだという認識は世に広まっていると思います。

しかし実際のところ、同様の有害さを含むお手並み拝見モードのコミュニケーションというのは、新メンバー受け入れ場面でも、またそうでない場面でも容易に発生してしまいます。相手が仕事を達成することよりも、できるかどうか確かめることを優先してしまう。単にそれが形式的に悪いことだと線を引いてしまうことも難しいものですし、振り返って自身の振る舞いにそのようなかたちを見出してしまって「自分、矛盾しているのでは?　自分の中では一貫していても周囲から読み取れないのでは?」と悩むこともあります。

ここでは、経験ベースとはなりますが、「お手並み拝見」について少し掘り下げ、普段から生じているその姿勢の影響について向き合う事例についてお話しします。

Learning Outcome

以下のような方を対象としています。具体は異なっても悩みの形は相似であると思いますので、一緒に悩みましょう。

• たとえばオンボーディング時の「お手並み拝見」モードについて考えている方
• 有益そうなアイディアをチームに取り入れるときに、影響範囲や射程について悩むことが多い方

概要

EMとしての大きな仕事の一つは、メンバーやチームを成長させていくことだと思います。しかし、アジャイルやDevOpsなど社内で新しい取り組みを進める際には、成長の目標となる先達の個人やチームが存在しない、という課題に直面します。

私が新人時代にそれを補ったのは、社外のコミュニティとの繋がりでした。コミュニティに参加・登壇することで、様々な刺激や目標とすべき同志や先輩に出会い、自分なりの成長につなげてきました。そして、そのコミュニティとのつながりのきっかけは、身近な先輩がつなげてくれたものでした。

このリレーをつなぐべく、チームを任されてからは、メンバーに積極的にコミュニティやカンファレンスへの参加を呼びかけてきました。また、自身もカンファレンスへの参加や登壇を積極的にこなし、そこで繋がった人たちとチームとの間で対話会を設けるなど、チームと外部をつなぐ活動も積極的に行ってきました。

そういった地道な活動を1年以上続けた結果、現在では年間で10回以上の登壇機会をチーム内で持つようになり、それがきっかけとなって社内外でのつながりも生まれてきました。

このように、外部登壇を通じてチームの成長を駆動してきた取り組みについてお話しします。

Learning Outcome

1. 外部発信を通じて開発組織の成長を促進させた事例
2. メンバーの外部活動を促すための具体的なアプローチや戦略
3. 社内に先達が少ない場合でも、外部リソースを活用して新しい取り組みを推進する方法
4. 継続的な外部活動が組織文化やチームのモチベーションに与える長期的な効果の事例

概要

エンジニアやリーダーからエンジニアリングマネージャー（以下EM）への役割転換で直面する課題の一つにプログラミングスキルの低下が挙げられます。
プレイングマネージャーとしてコードを書きながらマネジメントを担うという選択肢もありましたが、私は大企業とベンチャー企業の双方でEMを務めた際、ある程度の期間が経った後、コードを書く業務から退くことを周囲に宣言しました。
初めは、プログラミングから離れることで技術的なスキルが衰えるのではないかという恐れや不安を抱いていました。
しかし、その決断を通して、マネージャーとしての役割に専念し、エンジニアリング組織の成長を促進することに注力できるようになったと感じています。

本セッションでは、当時を振り返りながら不安に対してどう向き合ったか、向き合った結果どうなったかを実体験をもとにお話します。
具体的には以下を紹介します。
・不安の正体と深掘り: プログラミングスキルが低下することの不安を様々な観点から分析し、自身の感情や思考整理につなげます
・EMへの登用・周りから求められていることの理解: EMとして求められる役割を理解し、周囲から期待されることを把握し、自身の新たな価値を見出すことを期待します
・不安を和らげるテクニック・理論の紹介: 不安を和らげる実践的な理論やテクニックについて具体的な事例を交えて紹介します。これにより、自分自身の状況に応じた対処法を持つことができます

このセッションを聞いて、コードを書かなくてもエンジニアリングマネージャーとして新たな役割に適応し、不安ではなく自信を増幅して業務に取り組めるような処方箋になれば幸いです。

Learning Outcome

対象聴衆
・EMに興味があるエンジニアの方
・自身の役割や価値を見直したいEMの方
・業務負荷からコードを書く時間が減っているEMの方
得られること
・EMとしての新たな価値の見直しやふりかえりの機会提供
・プログラミングスキル低下やキャリアへの漠然とした不安の解消

概要

初めて挑戦することには失敗はつきもの。でも挑戦し、失敗を乗り越える過程で人は成長できます。それはEMも同じ。

EMをやる前は、「EMって何をする人なの？」とか「いつも忙しそうだけど何に時間が取られてるの？」といった、自身に経験がないことによる理解不足から「何をフォローすればいいのかわからない」とか「なんとかしてくれるんだろう」と良くも悪くもEMを近づきにくい人として扱ってしまいがちかなと思います。

このセッションでは、そんなことを考えていたチームメンバーの一人だった私が、EMに挑戦して経験した失敗とそこから得た知見、そして今後どういったEMを目指していこうと考えているかをお伝えします。

例えば以下のような取り組みについてお伝えします。

• 他人の意思決定にそのまま従わない
• 重要度・緊急度でタスク分類する
• TODOリストは頭に入れない

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

対象の聴衆：

• いまはチームメンバーで、これからEMに挑戦してみたいと考えている人
• EMがどんなことをするのかわからないので知りたい人

得られるもの：

• EMに求められることと経験することで得られる知見
• EMに挑戦してもいいかなという心持ち

概要

マネジメントの課題はスキルを持って超えられる「技術的課題」だけではなく、各人の自己認識や他者認識、関係性など人の課題=「適応課題」が多くの比重を占めています
メンバー同士やマネージャー自身の適応課題を、深い本音を伝え合う対話によって乗り越える方法について大企業でのコーチング・システムコーチングなどの事例を用いて説明します

Learning Outcome

・適応課題と技術的課題の違いがわかる
・深い対話によってどんな変化がマネージャーやメンバーに起きうるのかがわかる
・システムコーチングの概要についてわかる
・スタートアップでのシステムコーチングの実体験に基づいた学びや大企業でのマネージャーの変貌によるチームの変化の事例について理解できる

※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

概要

大小さまざまな企業で1万人のマネージャーとコーチングで伴走してきた実例から、あるあるなマネジメント課題の乗り越え方について話します
・マネージャーが任せられず忙しすぎる
・1on1が難しい。業務の話になってしまう
・急なマネージャー登用で自信が持てない
etc...

それらの実例と、私がCTOとしてそれらの課題にどう向き合っているのかをお伝えします

「管理職支援」をサービス提供しているmentoだからこそできる、リアルの話をしたいと思っています。

Learning Outcome

・マネージャーが忙しい問題への対処方法について学べる
・1on1のやり方や相互理解の方法が学べる
・急な登用で自信がない状態からどのようにチームをエンパワーしていくことができるかを学べる

概要

どんなマネージャーも、生産的なチームづくりを目指しています
しかし生産性を測る指標の難しさはソフトウエア開発において永遠のテーマです
一方でチームが楽しく没頭して働いている=ウェルビーイングな状態を作ることができれば生産的であることに疑問がある人はいないのではないでしょうか？

このトークでは
・なぜ知らず知らずのうちにお互いがストレスを抱えてしまうのか
・意外と知らないことが多い、他者の「楽しい」「没頭している」瞬間を知ることがなぜ大事か
・生産性を測る指標としての「ウェルビーイングかどうか」がなぜ大事か
・それを相互理解することによってどんなコミュニケーションが生まれるか
を実体験を交えて話します

Learning Outcome

・相互理解によってどうチームの生産性が上がるかがわかります
・相互理解の手法についてスクラムイベントの中に取り組む簡単な方法やシステムコーチングのような深い理解の手法を含め理解することができます

※システムコーチング® は、CRR Global Japan 合同会社の登録商標です。http://www.crrglobaljapan.com

概要

IT業界では長らく開発プロセスに着目したマネージメント手法が中心で、人や目的に着目したマネジメントとしてはほとんど浸透していませんでした
アジャイルの流れでEMが注目されてきていることがとても良い流れではないかと思います
EMを目指したいという方も増えており、ぜひ応援していきたいと思っています

しかし現代的なEMのカバーする範囲は広く、また、環境によるケース・バイ・ケースなことも多く一概にこれができれば良いという方法論に落とし込むことが困難です

そこで少し抽象的なEMとしての考え方に着目したお話ができればと思います
　・目的、目標、手段に切り分けて考えるクセをつける
　・事実と仮説を切り分けて考えるクセをつける
　・チームの仕組みづくりは、自分で考えて行動した結果から学べるようにすること

つまり、ここを押さえておけばきっとEMとして応用が効くと思われるポイントのお話となります
ふわっとしたEMを目指すのではなく、こういう考え方で行動している人を目指しましょう

Learning Outcome

EMとしてどのように成長をしていけばよいか、イメージができるようになる

概要

みなさん、こんにちは！

私からはリリースから4年経ち、利用者も増え、複雑度も高いプロダクトに対し、
プロダクト戦略策定からチーム一丸となって取り組むことを決めたチームの奮闘記を紹介したいと思います。

まずカミナシではプロダクト毎にサービスチームという
PdM/PD/Eng/EMが所属する仮想的な職能横断チームを作り、サービス開発を行っています。
職能横断チームを組成することでプロダクトのオーナーシップを持ち自律的に価値提供を行える仕組みです。

プロダクトごとにチームがあることから、プロダクト戦略策定から関わりやすい組織構成ですが、プロダクトが大きくなると顧客数も増え、さらには利用ユーザの業種も増えることから、扱う情報がどんどん多くなり意思決定は複雑化します。カミナシレポートもリリースから4年が経ち顧客数も増え、業種も多種にわたり扱う情報量が非常に多くなっていました。

またサービスチームではiOSアプリをPWAへ移行するという、比較的長期に開発が必要なリリースを進めており、開発に集中する必要もありました。こういった状況もあり、PWA移行後のプロダクト戦略についてはPdMチームに任せっきりになっていました。

本来とは違うこの状況を変えようと、9月末PWAアプリのリリースを機に、
戦略策定から全てにエンジニア含めて関わると決めて、サービスチームを再組成しています。

いざ始めてみると、扱う情報量や意思決定の数が一気に増えるだけでなく、カミナシレポート以外のプロダクトがリリースされたことから、プロダクト間の連携も並行で検討したいタイミングにあり、ステークホルダーも急激に増え、一筋縄ではいかない状況の中奮闘しています。

この荒波を乗り越えるため、多くの失敗と学びから改善を繰り返し進めている様を、カミナシのバリューである「全開オープン」でお話したいと思います。

Learning Outcome

▼想定聴者
プロダクトと開発チームの関わり方に興味がある方

▼得られるもの
プロダクト戦略とチームの関わり方
プロダクト開発とのバランスの取り方
失敗と学び試行錯誤の数々

概要

この一年間、50名規模のエンジニア組織のマネジメントに挑戦し、組織の成長を支えるための戦略を模索してきました。その中で、部門間のサイロ化、文化や価値観の共有不足、期待値のすれ違いといった問題が浮き彫りになり、組織全体の一体感や業務効率に悪影響を及ぼしていることが明らかになりました。

これらの課題を解決するために取り組んだのが、「文章を書くこと」を通じた組織の明文化です。暗黙知に頼りがちな文化や価値観を言語化し、期待値を明確にすることで、メンバー間の認識を揃え、曖昧さを排除していきました。

本セッションでは、これらの取り組みを通じて得た知見を基に、具体的な手法とその効果について、以下のトピックを中心に共有します。

• 体制の再編とコミュニケーションパスの再設計
• 情報共有と浸透のための文章化
• 共に実践するマネジメントプロセスの強化
• 技術戦略と文化醸成への投資

Learning Outcome

• 50名規模のエンジニア組織を運営する上での主要課題とその解決アプローチ
• 組織文化や戦略の浸透を促すための「文章化」の実践方法
• マネージャーが押さえるべきマネジメントプロセスの改善ポイント

このトークは、組織のマネジメントについて新たなインスピレーションを得たい、エンジニアリングマネージャー、リーダー、及びマネジメントに興味のあるエンジニアに適しています。

概要

私はこれまでのITエンジニアとしてのキャリアの大半を一技術者として過ごしてきました。
しかし、自分なりの『理想のエンジニアリング』を追求し、一歩一歩進んでいく中で、いつの間にか様々な組織に働きかけるようになりました。
ダイキン工業という巨大な百年企業の中で色々もがいた結果、現在ではアジャイルやDevOps、Platform Engineeringなどの考え方を社内で推進していく、EMとして働いています。

どのような経緯をへて、大企業の中で今のような取り組みをするに至ったのか、その転換点となったエピソードなども交えながら、一つのキャリアパスの事例としてお話させていただければと思います。

トークアウトライン

1. DevOpsエンジニア時代: 小さな改善を積み重ねる
2. アーキテクト時代: 大規模な設計変更やOSS活用を含めたリアーキテクティングの実践
3. AWSガイドライン制定: 最適化を目指した一つのきっかけ
4. ガイドライン普及の苦労と工夫: 広げるためのマインドチェンジ
5. 複数チームをまとめるマネージャーへ: アジャイル開発チームの成長
6. コミュニティを通じた全社展開: 様々なチームを有機的につなぎ、ようやく「EM」へ

Learning Outcome

1. 技術者からエンジニアリングマネージャー（EM）へのキャリアパスの具体例
2. 大企業内でのDevOps、アジャイル、プラットフォームエンジニアリング推進の実践事例と課題
3. ガイドライン策定やコミュニティ活動を通じ、組織の壁を越えて影響力を拡大するための戦略やアプローチ
4. 個人のビジョンと大規模組織の目標を調和させるためのアプローチやその過程での学び

概要

マネージャーの仕事は意思決定の連続であり、もちろんエンジニアリングマネージャー（EM）も例外ではありません。そして、意思決定のアプローチとしてよく用いられるのが「仮説検証」です。

この方法では、現場の問題に対して解決策の仮説を立て、それを検証して評価することでより良い意思決定を目指します。特に不確実性の高い状況では有効とされ、リーン・スタートアップの根幹を成すメソッドでもあります。

一方で、この手法には落とし穴があります。定性的なアプローチに依存しがちのため、個人やチームのバイアスの影響を受けやすいのです。

本セッションでは仮説検証アプローチの一般的なプロセスに沿って、各ステップで生じがちな認知バイアスとその影響を紹介し、対策について考察していきます。例えば、以下のようなポイントです。

• 仮説の選択：ヒューリスティックによって、特定の選択肢を過大評価してしまう
• 検証方法の検討：確証バイアスによって、仮説を裏付けるデータのみを集めてしまう
• 検証結果の評価と意思決定：メンバーへの伝え方によって特定の判断に誘導してしまう

これらをできるだけ回避して、よりもっともらしいアプローチを行うためにマネージャーが取るべき行動を検討します。また、仮説検証において何を担保すべきなのかを再確認していきます。

Learning Outcome

対象

仮説検証と意思決定が求められるすべての人

得られるもの

仮説検証による意思決定に関する以下の知識とノウハウ

• 主要な認知バイアスの種類と、それを補正する方法
• チームで意思決定をする際、より公平に意見を集めるための質問方法
• 仮説検証プロセスにおいて重要視すべきポイント

概要

EMが関わる人や組織は様々で、それに応じるマネジメントスタイルもまた多様なのではないでしょうか。このトークでは数年来のマネジメント経験の中で見出した一つのスタイルを紹介します。

エンジニアリングマネジメントにはピープル、テクノロジー、プロジェクト、プロダクトの4つの領域があるという見方があります。それぞれに細分化された専門家もいる程に深い関心事であり、個人のケイパビリティを超えるのは必然です。このように無茶とも思えるような期待に応えるには様々なスキルが求められるわけですが、とりわけ重要なのが適切に助けを求める力ないし助けを引き出す力なのではないでしょうか。

ところでチームで成果をあげるには、構成員それぞれが練度を高めることに加えてコラボレーションが不可欠です。助けを求め、それに応えるということはコラボレーションの起点になります。チームのメンバーやマネージャーは”助け”というものを軸にチームのパワーを増幅させる力を持っていますが、必ずしもその使い方、使い時に気づいているわけではありません。

助けを求めるのは簡単な事に思えるかもしれません。しかし、必ずしもそうではありません。助けを求め、支援あるいはコラボが生まれるまでには、いくつかのハードルがあると考えられます。例えば、助けを求めるという発想を持てるか否か、求めるべきか自力で解決すべきかの判断、助けが必要であると周囲に気づいてもらうことやアクションを起こしてもらうハードルなどです。

このトークでは、そのようなハードルにEM目線ないしメンバー目線から、如何に立ち向かうことができるのか、立ち向かってきたのかを話します。
仕組みや環境づくり、コミュニケーションの流儀、心構え、物事を見る視点といった観点から、試行錯誤してきた事例、うまくいった、いかなかった経験を共有したいと思います。

Learning Outcome

• 対象
  • リソース不足、力不足に悩むEM
  • おそらく主にはEMになりたての方
  • EMと共に働く方
• 得られるもの
  • コラボレーションの促すためのヒント
  • チームの力を増幅させるためのヒント
  • 触媒たるEMのふるまい方のヒント

概要

クライアントワーク企業でのエンジニアやPjM経験を10年以上積んだのち、SaaSスタートアップで初めてEM（エンジニアリングマネージャー）として挑戦することになった私の、約半年間の奮闘記をご紹介します。EMとしての役割を「プロジェクトマネージャー（PjM）の延長」程度に考えていた私が、実際にはその想定を大きく裏切られる形で、1on1やOKR、スクラムイベントの運営に深く関わりながら「エンジニアリングマネージャーとは？」を試行錯誤の中で理解していくことになりました。

EMの役割は単なるリソース管理やタスクの進捗管理にとどまりません。チームとメンバーのバリューを最大化するため、目標の設定や達成に向けたサポート、採用、そして会社全体に対しても貢献することが求められます。シリーズBの資金調達を経て急成長を目指すスタートアップでは、定量的な目標への貢献が問われ、私もOKRに基づく目標達成に日々向き合っています。加えて、入社から今までの約7か月の途中で育休を取得した際には、引き継ぎやメンバーのサポートに際しても様々な気づきが得られました。

また、日々のチーム作りの中で考えた「強いチームとは何か？」というテーマに基づき、開発生産性やコードの変動係数導入など、仮説検証を重ねてきました。さらに、社内ポッドキャストの配信や昼休みのLT会（社内勉強会）の主催も行い、チーム外でもEMとしての価値を模索しています。

本セッションでは、各自が相互にコラボレーションすることで成長を続ける「自立型組織」を目指して、EMとしての意義を問い続けた私のリアルな試行錯誤の過程をお話しします。EMとしての役割や在り方に悩む方々に少しでも何かを持ち帰っていただければ幸いです。

Learning Outcome

▼想定聴者
EMとしての経験を積み始めたエンジニアや、これからEMを目指そうと思っている方々

▼得られるもの

• スタートアップにおけるEMのリアルな役割と課題、「チームの価値を引き出す」ための具体的な事例と実践ノウハウ
• チームメンバーが自立して活躍するために、EMが行う支援や介入のヒント
• チームの成長に向けた実践と強いチームの仮説
• チーム外への貢献
• メンバーがパフォーマンスを最大化できる目標設定のサポート、経営目標達成へのアイデア

概要

私は、前職ではじめてのマネジメント業を経験したあと、現職にエンジニアとして転職しました。
まさに「エンジニアとマネージャの振り子」の2周目が始まったところです。
前職ではマネージャとして1on1や評価、採用、組織改善といった業務を行っていました。
これらの経験は、現職のエンジニア業務でとても活きています。特に、1on1と評価に関するものです。

1on1は、会社が個人に提供できる成長機会の中で最重要かつ代替不能なものです。
技術研鑽は個人でも出来ますが、「自分の成長に責任を持ち全力で支援する人と過ごす時間」は代替不能です。
マネージャとして、メンバーの成長角度を最大化するため、自責で考え成長につながるアクションを共に見出すことが必要です。

メンバーが納得感を持ち、成長につなげられる評価をするには、関係づくりとマネージャとして説明責任を果たすことが重要です。
日々のコミュニケーションの中で信頼関係や期待値調整が出来ていないと、メンバーにフィードバックを受け入れてはもらえません。
またマネージャとして「なぜその評価なのか」「より上の評価を取るには」といった疑問に答える準備も必要です。

マネージャとして上記を経験してみると、その反対側であるメンバーとしての向き合い方にも変化が現れました。
かつては受け入れがたかったフィードバックに対してオープンなマインドで向き合い、自身の成長につなげることができるように、
また高くなりがちだった自己評価も上長とのブレが少なく、成長のための会話を出来るようになりました。
マネジメント経験が、メンバーとしての振る舞いにも良い影響を与えていたのです。

このトークでは私の1on1や評価への向き合い方の変化を実例として、マネジメント経験がメンバーとしての振る舞いに良い影響を与えるという話をします。

Learning Outcome

想定聴者

• 次のキャリアについて模索しているエンジニアの方
• マネジメントに興味はあるがまだその一歩を踏み出せていないエンジニアの方

得られるもの

• 「エンジニアとマネージャの振り子」という概念とその経験談
• マネージャ経験がメンバーとしての振る舞いに良い影響を与えるという実例
• マネジメントへの一歩を踏み出す勇気