トーク

概要

いままで、エンジニアリングマネージャー（EM）とチームリードの役割を行き来してきました。今年入社した職場では、新チームの立ち上げのチームリードを担うことになりました。初期は、チーム基盤やプロダクト基盤を構築し、技術方針やアーキテクチャの意思決定に従事しながら、プロダクトとチームの成長を支えました。しかし、立ち上げ段階からの継続的な「自転車操業」により、組織全体の中長期的な課題に割く時間が不足していることに気付きました。

エンジニアリングマネージャーとして、組織課題に取り組むにはチームの技術リードをメンバーに委譲し、チームが自律的に動ける体制を整えることが重要です。そのため、チーム内での期待役割の明確化と、適切な権限委譲のプロセスが不可欠です。

しかし、チーム内でワークショップを実施した際、多くのメンバーからは技術的なリーダーシップを期待されていることが判明し、自分が組織課題に注力したいという方向性とのギャップに悩みました。

このセッションでは、EM、リーダー職が組織課題に越境して関わるための権限委譲の重要性、期待役割の可視化とギャップ解消に向けて模索した具体例ををお話しします。

• 対象者：
  • 役割を越境し、組織課題の解決に挑むエンジニアリングマネージャーやリーダー職の方
  • 組織全体の課題に取り組む必要を感じており、チームへの権限委譲に悩まれている方
  • チーム全員のオーナーシップを引き上げるための試行錯誤や事例に関心がある方

Learning Outcome

• チームの期待と自身の役割のズレを認識し、解消するための実践的な方法
• EMとして権限委譲を円滑に進め、組織課題に注力するためのプロセス
• 組織全体の成長に貢献するための具体的なアプローチとその成果

概要

複数の部署と協力して活動する横断組織には、一般的な縦割り組織とは異なるマネジメントの難しさがあります。
私も半年前に横断組織のEMとして着任し、日々その課題に直面しています。

横断部門の組織と特定事業を担当する専門組織とでは、同じ開発組織であっても会社から求められる役割に微妙な違いがあります。
そのため、優先順位の付け方や価値観の違いから衝突が起こりやすく、各チーム間でのリソース調整や目標の共有が必要です。
本発表では私の体験談を交えながら、横断組織のマネジメントで直面した課題と、その解決に向けた具体的な対策をご紹介します。

本発表では、以下の3つの観点から、体験した困難とその解決策を共有します。

1. 利害関係の調整：異なるチーム間での目標や価値観の違いから生じた対立やギャップに対して、どのように試行錯誤を重ねて対応したか。
2. リソース管理：限られたリソースを各チームに公平に配分し、全体の効率を上げるために工夫した方法。
3. 情報共有と透明性の確保：組織全体での情報伝達を円滑に進めるために行った取り組みとその成果。

これらの課題に対して、どのようにアプローチし、コミュニケーションの頻度や方法を調整したか、また、各部門のキーパーソンを巻き込み意思決定を促進した方法について、具体的な経験をもとにお話しします。

Learning Outcome

• 横断組織のEMが抱える独特の課題とその解決策
  • 他部署との摩擦や調整方法
  • リソース管理の工夫に関する実践的なアイデア
  • 透明性を重視した情報共有の重要性に関する理解
• 組織横断でのリーダーシップに関心のある方や複数チームと関わる方に向けた共感と実践的な内容

概要

エンジニアリングマネージャーが事業の成長に寄与するための一つの要素としてエンジニアの採用があります。本セッションでは「家族アルバム みてね」の事業の成長を加速させるために、必要なエンジニアをどのようにして採用したかの具体的な取り組みを紹介します。

勉強会やカンファレンスへの登壇、ブログ記事の執筆など、企業やプロダクトの露出を増やすことで、エンジニアの採用に一定の効果があるのは言うまでもありません。実際に多くの企業が採用強化の施策の1つとして取り組んでいると思います。しかし、それだけで採用は成功しづらいのが現実です。採用に必要な要素は他にも多くあります。例えば、求職者が採用プロセスの中で募集企業に求めているものは一体何なのかを知り、情報をわかりやすく提供することや、組織一体で採用活動に取り組むために必要なことな何なのかを考え、実践することが大事です。

本セッションでは、具体的にエンジニア採用においてどのような取り組みをおこなったかを、20分のセッションの中でできる限りわかりやすくシンプルに共有します。エンジニア採用に関わり始めたばかりの方にもお役に立てたらと思っています。

セッションの主なトピックは以下を予定しています（発表時には追加・修正される可能性があります）。

• 求職者にとって有益な情報とは何か
• 採用プロセスでの工夫点
• 実際に効果があった施策の紹介
• 採用は採用決定で終わりではない

Learning Outcome

• 自社の採用プロセス改善のための具体的なヒントを得ること
• 求職者に対してどのような情報が有益かを理解する
• 他社の事例からエンジニア採用のベストプラクティスを学ぶ
• エンジニアリングマネージャーが採用プロセスに効果的に関わる方法を知る

概要

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

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

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

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

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

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

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

  Learning Outcome

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

概要

採用はEMの重要な仕事のひとつです。
組織をつくるための基盤となる業務であり、成果がわかりやすい仕事でもあります。

EMの仕事の多くは、エンジニアがコードを書くことと違って自分の活動の成果が見えづらいことが多いです。一方、採用の仕事は実際に成功した採用人数に現れますから、成果がわかりやすい仕事です。

わたしは、現在EMとして採用業務に多くコミットメントしており、一般的に採用難易度が高いと言われているポジションでの採用に貢献することができました。わたしがここ数年で採用に関わり、うまくいったポジションは以下です。

• EM
• アジャイルコーチ
• SRE部門のマネージャー
• モバイルエンジニア

もちろん採用業務は自分ひとりでできる仕事ではありません。人事部を中心に、関係者の多大な尽力があって成せる仕事ではありますが、EMは採用プロセスの中でも最初の方に関わるケースが多く、やれることがたくさんあります。

採用の成否は行動量に比例します。EMが採用業務で行う仕事は多岐にわたりますが、このセッションでは、EMとして採用にコミットするためにできる「直接的な行動」にスポットをあてて掘り下げてみます

このセッションで扱うトピック

• 採用は自分の主業務であると覚悟を決める
• ジョブディスクリプションの作成
  • どういう人を採用したいのかを言語化する
  • JDを失敗すると候補者は離れていく
    • ex: スクラムマスターの採用なのにPjMのようなJDを書く
• スカウト
  • 読んでもらえるスカウト文
  • スカウト文はできるだけ自分で書く
  • ガツガツしないSNSとの良い付き合い方 (DMでスカウトって送っていいの問題)

• カジュアル面談

  • EMが自分の裁量で好きに活動できる最後がここ
  • カジュアル面談はアトラクトに全振りする
  • 言いづらいことほどちゃんと言う

  EMの業務範囲ではあるがこのセッションで扱わないこと

• 採用プロセスの設計や改善
• 1次面接~オファー面談までの採用活動の後半戦

• エージェントとの関係構築

  Learning Outcome

• 採用の仕事の一部を具体例を伴って知れる

概要

世に溢れるベストプラクティスは多くの場合、自分の組織の課題解決にそのまま当てはめることができません。
その会社のビジネスモデル、組織構造、人の能力・個性などによって、課題の性質・形・大きさが変わるため、課題の背景を知り、戦略を考えるプロセスは避けられません。

戦略は、わたしたちが「どうしたいか=意思」を持たない限り、生まれません。
EMは、様々な技術的な軸において在るべき姿を描き、それを実現するために強い意思を持ち、戦略を描いてリードしていく必要があります。

このセッションでは、以下を掘り下げていきます。

• EMにとって必要な意思をどのように芽生えさせ、増やし、育てていくのか
• エンジニアリング組織におけるどんな場面で意思を役立てることができるのか

さらに、発表者自身の以下の事例をもとに理解を深めていきます。

• 中長期のロードマップや目標を頻度高く伝え、人それぞれの個性を尊重しながら議論を重ねることで、素早く高品質なユーザー向き合い体制を築き、全員が理想のアーキテクチャを理解し、機能や開発プロセスを自発的改善をする開発組織を作り上げた事例
• メンバーのキャリアパス、マイルストーン、今やっている仕事など、するべき情報収集や辿るべき思考プロセスを踏まえ設計した会議体により、部門のEM全員がメンバーの育成戦略を考え実践できるようになった事例

Learning Outcome

• ベストプラクティスに頼らず課題を解決するためのマインドセットを知ることができる
• 自走する組織を築く、EM強い意思をもとにした行動事例を知り、理想のチーム文化の醸成に役立つ

概要

「心理的安全性」という言葉はよく耳にしますが、実際にそれを組織でどう実現するのか？さらに、それがどれだけ組織の成長に影響を与えるのか？
本セッションでは、急成長中の開発組織、約50名を引き継いだエンジニアリングマネージャーが実際に取り組んだ「心理的安全性」の醸成プロセスをリアルにお伝えします。
1on1やサーベイから見えた課題をどう解決したのか、そして組織文化やエンゲージメント向上、離職率低下をどう実現したのかを具体的に解説。
このセッションを通じて、参加者は「明日から使える」実践的なヒントを持ち帰ることができます。

目次

1. 「心理的安全性」を醸成するための3つのカギ
   • 受容
   • 仲介
   • 傾聴
2. チームの現状を見える化する：何を、どうやる？
3. 開発組織を改善するプロセス
   • 課題をどう見つけ、どう優先順位をつけたのか？
   • DevOps風サイクルを活用した改善の仕組み
4. 取り組みの成果と次なるチャレンジ

Learning Outcome

ターゲット

• チームの雰囲気をもっと良くしたいエンジニアリングマネージャー
• 「文化」を武器にしたチーム運営に興味のある開発リーダー
• 組織改善に本気で取り組みたい全ての人

得られるもの

• 心理的安全性を育むための具体的なアクション
• メンバーが安心して挑戦できる環境を作る方法
• エンゲージメントを向上させ、離職率を下げる実践例
• 自分の組織でも試せる改善サイクルの作り方

「こうすれば良くなる」を信じて動き出したとき、組織はどう変わるのか？そのヒントを持ち帰れるセッションです！

概要

みなさんは EM としてうまくやれているという実感を持っていますでしょうか？

わたしは内向的な人間であり、ピープルマネジメントの比重が大きいとされる EM に向いていないと思ってます。エンジニアからリーダー、そしてマネージャーとキャリアが変遷していきましたが、決してマネジメント志向ではありませんでした。

EM といえば、ピープルマネジメントやチームビルディング、目標設定、人事評価。さらに、個人の成果ではなく、チームとしての成果に責任を負わないといけない。EM になることで発生する様々なプレッシャーに負けないよう、目の前の球を打ち返すだけの日々を送っていました。

いつしか「EM をうまくやること」が目的と化していました。

「EM をうまくやること」が目的化していたことに最近まで気づかず、数年もマネジメントしていたのですが、終わりのない悩みの連続でした。

だからこそ得たものも多いと今は考えています。自分には向いていないと思って始めた EM だからこそ、愚直に時間をかけて施策を練り、自分の強みをマネジメントでも発揮できる工夫も考え抜いてきました。それらが血肉となり今の自分があり、自信にもつながってもいます。

また、悩み多き自分の EM としてのモチベーションや熱量、その源泉についても最近つかめてきました。EM になることで、自分の手段がエンジニアリングからピープルマネジメントに変わり、自分の目標が個人目標からチーム目標に変わりました。手段や目標が変遷していく一方で、自分の価値観や目指すべき姿は変わっていないことに気づきました。悩みながらも EM を続けてこれた秘訣は、これらの価値観たちでした。

実際に私が実践してきた施策や工夫を紹介しながら、EM としての悩みが軽くなるヒントを話していきたいと思います。

Learning Outcome

• EM としての悩みが軽くなる考え方のヒントを知る
• なぜ自分が EM をやっているかを再認識する

概要

皆様がエンジニアリングマネージャーとして働き始めた経緯は様々だと思います。自分から望んだ人、周りから推薦された人、成り行きでなった人、キャリアアップの一環としてチャレンジしている人などなど・・・。また、皆様を取り巻く環境や課題も様々であり、時には迷ったり悩んだりすることもあるかと思います。

私自身はというと、電子部品メーカーのエンジニアとして社会人生活をスタートし、リストラに伴う転職、大手電機R&D部門から新規事業開発部門の異動、社員数数万人規模の企業から10人程度のベンチャー＆未経験職種に転職、AIエンジニア、プロジェクトマネージャー、10人程度のEMから80～90人規模のエンジニアリングマネジメントを経て、現在は全社横断的な視点で技術組織を見ています。このような過去を振り返ると、様々な出来事やチャレンジがありました。そして、そのたびに迷い、悩みながら自分なりの答えを模索しつつ、今に至ります。

このように、様々な課題に直面したり環境が変わるような場面を乗り越えるためには、個別具体的な方法論よりも、それを一段～二段程度抽象化した自分なりの「マインドセット」を確立し、それを指針とすることが重要であると私は考えます。

発表では、私が普段どのようなマインドセットを基にマネジメント業務にあたっているか、また、それは過去のどのような経験をもとに形成されたのか、について紹介しようと思います。
皆様の日々の迷いや悩みを乗り越えるための一助になれば幸いです。

Learning Outcome

対象の聴衆

• 新しい環境に置かれ、日々迷いや悩みを抱えている方
• 今後の環境の変化に備えたい方
• 他人のキャリアパスに興味がある方

得られる学び

• 迷いや悩みを乗り越えるための処方箋の一例

概要

バックオフィス向けの大規模BtoB SaaS開発では、一定のまとまりをもって機能提供を行う必要があり、リリースのバッチサイズが大きくなる傾向があります。1つの案件ごとに長期間の開発が必要になることが多いため、リードタイム短縮は常に大きな課題です。

また、バックオフィスというドメインの特性上、要求や要件の精度が上げやすく、リリース後の顧客に対する不確実性も少ないため、基本的にはウォーターフォール開発が適しています。しかし、以下のような課題が生じやすく、改善の必要性を感じていました。

• PJ初期の見積もりの不確実性によりコストをかけて作成したスケジュールの精度が低い
• 開発工程後半のステークホルダーレビューでのフィードバックによる手戻りのリスク

そこで、このセッションでは、これらの課題に対して取り組みを進めている2つの施策について紹介します。

1. 新技術の導入を通じたモバイルアプリ開発リードタイムの短縮
   • 具体的な技術選定の背景や導入プロセス、得られた効果についてお話しします。
2. ウォーターフォールとアジャイルのハイブリッド開発プロセスの導入
   • ウォーターフォールの枠組みの中にアジャイルのプラクティスを組み込み、柔軟かつスピーディーな対応を実現するプロセスについて、その成果と課題も含めてご紹介します。

これにより、開発の柔軟性を保ちつつ、リードタイム短縮と品質向上の両立を目指しています。BtoB SaaSに特化した実践的な内容を通じ、同様の課題に直面している方々への手助けとなれば幸いです。

Learning Outcome

対象聴衆:
・BtoB製品のモバイルエンジニアリングマネージャーおよび技術リーダー

得られるもの:
・リードタイム短縮のためのテクニック
・クロスプラットフォームのモバイルアプリ開発フレームワーク導入事例
・アジャイルプラクティスの実践的導入方法

概要

私は株式会社グッドパッチというデザイン会社でエンジニアリングマネージャーとして働いていますが、これまで長らくプレイヤーとして働いてきました。プレイヤーとして働く中で、デザイナーとエンジニアが共創することには大きな価値があることを実感する一方で、組織やプロセスの問題について課題を感じていました。これらの課題に対処するためにはマネージャーの理解が必要不可欠であり、マネージャーが重要な役割を果たすと考えています。

本セッションでは、デザイナーとエンジニアが共創する価値とは何か、共創するためにマネージャーとして果たすべき役割とは何かについて、私自身の経験や学びをお話しできればと考えています。

Learning Outcome

主に以下のトピックについて共有できればと考えています。

• ソフトウェアにおけるデザイナーとエンジニアの思考性を知る
• デザインとエンジニアリングの分業における組織のサイロ化問題を知る
• デザイナーとエンジニアの組織の壁の超える方法を知る
• デザイナーとエンジニアが共創する価値とは何かを知る
• デザインプロセスにおけるエンジニアの関わり方を知る

概要

3年前、私はマネーフォワードクラウド経費・債務支払の２プロダクトの保守・運用部門の1エンジニアとして配属されました。
「保守・運用って泥臭い？楽しくない？そんなのは嫌だ！」
そういう想いから1エンジニアとして開発だけでなく、チームの環境を良くするために「肥大化するチームの役割を整理する」「無理をしなくて済むプロジェクト管理の徹底」などのミニ EM 業務をこなしてきました。
そこからさらに、1年半後にはグループリーダーとなり、「カスタマーサポート部門や機能開発チームらステークホルダーとの調整」「PdM との目線合わせ」「開発マネージャーとの役割分担やグループの人事」「チームの目標と KPI 設定」「チームマネジメント・育成」と本格的にマネジメント業務をこなすようになりました。
その中でもこだわったのが、「いかにエンジニアとして技術欲と知的好奇心を満たせる楽しい環境を作るか」という点です。
機能開発と比較すると、保守・運用はややそういう色が薄い部門かと思います。でもそんな中でも楽しく仕事するために、「攻めの運用」と「守りの運用」などの施策を推進し、楽しく働く文化形成を行い、結果として単なる保守・運用だけでなく多くの改善ができるチームへと変革しました。
最後に保守・運用部門のリーダーを、育成した後任に引き継ぎ、新たに Technical Enablement 部門のリーダーとして、何を大事にして、チャレンジするのかをお話しします。

Learning Outcome

• Growth - 組織形成と成長
  • 1運用部門の発展と成長の歩み
• Innovation - 組織変革と改善
  • ステークホルダーをどのように巻き込み、改善していったか
• Philosophy - EMとしての生き方
  • 「エンジニアリング」マネジメントなのだから、エンジニアとして楽しい状態を作らないといけない、という想いを現実に折り合わせた一つのケーススタディ
• Challenge - EMの「次の挑戦」
  • 運用部門をリーダーとしてマネジメントし成長させ、そして次の挑戦として Technical Enablement 部門を作るに至った経緯と抱負
• Resilience - 失敗と学び、試行錯誤 -
  • 上記に伴う試行錯誤

概要

「技術的負債の解消」はエンジニアリングマネージャー(EM)にとって悩みのタネになりがちなトピックです。

「どのような点が負債となっているか」を明確に説明するのが難しいため工数確保が難しい一方で、積み重なると開発生産性の低下や開発者体験の悪化を招き、結果的にチーム全体のパフォーマンスを阻害することになってしまうからです。

そこで本セッションでは、我々のチームが独自の取り組みによってどのように技術的負債を継続的に解消しているかを紹介します。

我々は、技術的負債であると思われる箇所をチームで話し合って起票するかどうか判断し、起票されたタスクには優先順位をつけて取り組んでいます。このライフサイクルを他の開発業務を圧迫せずに回していく方法を具体的な事例と共にお話しします。

また、負債解消に際して大幅な設計変更が必要である場合はビジネスサイドと交渉し、工数を確保して内部改善にあたっています。この過程についても触れていきます。

ちなみに我々のチームでは負債解消タスクを「整地タスク」と呼んでおり、セッションタイトルはこれに由来しています。

Learning Outcome

対象

技術的負債に悩むすべてのEM

得られるもの

• 継続的に技術的負債を解消するための具体的なプロセスと方法
• 「その負債はいま解消すべきか」について共通認識を形成し、タスクを起票する方法
• ビジネス側と調整して大規模な内部改善工数を確保する方法

概要

チームに必要十分なドキュメントを準備するのは非常に難易度が高いタスクです。

メンバーが個々に知見を残していくボトムアップのアプローチには、必要な情報が網羅されていることを保証できないという欠点があります。一方でトップダウンのアプローチを取ると、メンバーの工数を確保し参加を促すのが難しいという課題があります。

さらに、ドキュメントの質の担保や作成したドキュメントの陳腐化などはいずれのアプローチを取っても避けられない問題です。

しかし、我々のチームは一定の質を担保しながら必要十分な情報が揃ったドキュメントを企画から1年近くかけて作り上げ、その後も継続的にメンテナンスを行っています。

本セッションでは、ドキュメント構築の過程を追いながら以下の内容について説明していきます：

• ドキュメントの全体構成・文書作成ガイドライン・テンプレートの策定
• ドキュメント作成およびレビューのパイプライン
• 文書の陳腐化を防ぐためのしくみと活動

Learning Outcome

対象

チームにドキュメントの必要性を感じているが、どのように進めればよいか悩んでいる方

得られるもの

組織的なドキュメント作成に関する以下のノウハウ：

• ドキュメントの全体構成をどのような観点から考えるか
• 読まれることを前提にテンプレートをどのように設計するか
• 記事の作成とレビューを行うためのガイドラインをどのように決めるか
• 記事の作成をどのように手分けして進めるか
• 記事の陳腐化をどのように防ぐか

概要

令和トラベルは、2022年に「NEWT（ニュート）」をコアローンチして以来、順調にグロースし、前年比300%超えの成長率を超えるプロダクトに成長しました。
一方で、さらなる進化を遂げるため、プロダクト開発組織を1年間で約2倍に急拡大させる必要が出てきました。
こうした背景をふまえ、組織基盤をあたらしく構築するため、プロダクト開発組織のスクラップアンドビルドに挑みました。

多くのスタートアップでも同様に、非連続な成長や現在の成果を超える大変革を求められると思います。
このセッションでは、組織のスケールをみすえたプロダクト開発進化のために行ったスクラップアンドビルドをエンジニアリングマネージャーとして振り返り、具体的な取り組みや、変化の過程で学んだことをお話しします。また組織再編や変化を起こして、どのような効果が得られたのかについて振り返ります。

主に以下のようなテーマを軸に紹介します。

• 自己組織化を目指す上で考えたこと
• スケールアウトを目指すために設計した目標設定のポイント
  • 目標・指標の力学
  • 期待値調整
  • モニタリングと振り返り
• 権限委譲と組織分割の工夫

Learning Outcome

非連続な成長のための意思決定を求められる方のヒントになるようなセッションにしたいと考えています。

• スケールアウトを目指す上でEMとして意識すべきこと、気をつけるべき観点
• 組織基盤やプロセスを見直す際のポイントや直面した障害から得た教訓
• 目標設定やモニタリング方法のポイント

概要

EMとIC(Individual Contributor)を行き来した経験から、あえて他責思考で問題を捉えることで自責思考では至りにくい、双方に寄り添ったアプローチを考えてみました。
異なる役割を通じて得た新たなリーダーシップの観点や、効果的なチームビルディングの手法、さらに短期間での信頼構築のための具体的なプロセスを具体例を交えながら紹介します。
この変遷を通じて得た成功と失敗の教訓を詳しく解説し、キャリア再設計の理由とその意義について深く掘り下げます。
目次

• ICとしてEMに求めるもの
• EMとしてICに求めるもの
• 詳細をどこまで把握する必要があるか
• キャッチアップの手法
  • 勉強会開催
  • モブプロ
  • 輪読会

Learning Outcome

• エンジニアリングマネージャー（EM）やEMを目指す方は、異なる役割を経験することによって得られる新たなリーダーシップの視点を理解し、それをどのように実践に活かすかを学ぶことができます。
• ICに戻ることを検討しているEMや、新たにEM職を目指す方は、再びEMの役割に戻る際の具体的な課題（例：チームメンバーとの関係構築やリーダーシップスタイルの調整）に対する事例を通じて、どのように克服すればよいかを学ぶことができます。
• 現役のエンジニアリングマネージャーや新たな役割への移行を考えている方は、短期間で信頼を築くための具体的なアプローチを学び、それを実践に結びつける方法を探ります。

概要

我々のチームでは前期、OKR（Objectives and Key Results）のフレームワークを使って目標設定を行いました。

なぜOKRを始めたのか？　それはOKRの導入によって、開発部が抱えていた下記の課題に対処できると考えたためです。

• 開発部目標が事業部目標とリンクしておらず、事業部としての貢献度が見えにくい
• 開発部目標が単なる開発チームのToDoになっており、全くワクワクしない

しかし、会社としてOKRは導入されておらず、導入される予定もありませんでした。
そこで我々は開発部のみで、まずは「小さく」OKR導入に踏み切ることにしました。
初めてのOKRということもあり導入ハードルは高かったものの、結果的にはOKRは機能し、最後はメンバーから「やってよかった」との声も貰うことができました。

そう、小さく始めたOKRは成功したのです。

本発表では我々がどのようにチームにOKRを導入し、どう成功に導くことができたかをご紹介いたします。
この発表を通して、EMのみなさんの目標設定の一助になればと存じます。

コンテンツ

• なぜOKRなのか？
  • OKR導入前の課題
• ゼロからどのようにOKR導入したか
  • OKR研修・マネージャー陣のOKRディスカッション
• やってみてどうだった？　OKR振り返り
  • 良かったこと・課題に感じたこと・改善したいこと
• OKR運営のコツ
• OKRを成功させるためのポイント

Learning Outcome

対象者

• 目標設定が苦手なマネージャー
• 目標設定がマンネリ化しているマネージャー
• 目標にワクワクを感じられず、目標が退屈だと思っている方
• MBOによる目標設定に限界を感じているマネージャー

Outcome

• OKRを小さくスタートできるようになること
• OKRを上手に運用できるようになること
• 目標および目標設定プロセスを、ワクワクする楽しいものにすること
• 目標設定を活性化し、チームのモチベーションを高めること

概要

delyは創業以来、「国内No.1レシピ動画プラットフォーム：クラシル」や「国内No.1お買い物サポートアプリ：クラシルリワード」といった、日々の生活を支えるインターネットサービスを次々と立ち上げ、急速に成長を遂げてきました。しかし、その成長の裏には、開発組織として乗り越えるべき多くの挑戦と学びがありました。

本セッションでは、delyの開発組織がどのように変化し、急成長によって生じた課題とどう向き合ってきたかについて共有します。サービス拡大が開発チームに与えた影響、失敗からの学び、現在取り組んでいる課題とその解決策を掘り下げ、聴衆が自組織の成長に活かせる具体的な知見を提供します。

Learning Outcome

対象の聴衆:

• 開発組織マネジメントに関わる方

得られるもの:

• サービスの急成長が開発組織に与える影響を理解する
• 失敗から学んだ組織改善の方法を知る

概要

開発組織に生じる組織課題に向き合うEMは、事業や開発組織のグロースになくてはならない存在です。
日々組織と向き合い、抽象度の高い課題を解きほぐすことが求められるEMですが、殆どのEMが「コードを書くこと」で事業に貢献するプレイヤーとして、キャリアをスタートさせていることでしょう。

ではプレイヤーは、いかにしてEMへとステップアップするのでしょう？

本セッションでは、私が開発組織専門の人事・DevHRとして、EMの方々と協力しながらエンジニアの採用・育成に取り組む中で見えた、「プレイヤーからEMへのステップアップ条件」についてお話をします。
私自身も、いち開発者からEMと同じマネージャー職であるDevHRへとキャリアチェンジする過程で数多くの失敗をしてきましたが、その経験談も交えながら「(EMを含む)マネージャー職が獲得すべきマインドセットと、それらの獲得過程」を3つ紹介し、EMを目指すプレイヤーのみなさんへステップアップの足がかりとなる知見を共有します。また、EMのみなさんにはマインドセットの獲得過程から「マネージャー層育成の再現性を上げる」ためのヒントを持ち帰っていただければと思います。

マネージャー職が獲得すべきマインドセットと、関連する失敗談

1. 仕事を委譲し、チームを育てる
   → プレイヤー時代に「背中で見せればOK」と1人で突っ走り、メンバーが去ってしまった失敗
2. 役割と想いを言語化して価値を見出し、伝える
   → JD・スカウトメールを曖昧な文言で書いてしまい、面談・選考応募が獲得できない失敗
   → 内定を出した候補者へのアトラクトが上手くいかず、内定承諾が取れなかった失敗
3. なすべきことを自ら定義し、向き合い続ける
   → 採用と組織開発の業務を周囲に頼ることなく抱えすぎてしまい、パンクしかける失敗

Learning Outcome

想定する聴者

• EMへとステップアップしていきたい、プレイヤーやプレイングマネージャーの方
• マネージャー層の育成に苦労している、EMの方

得られる学び

• プレイヤーやプレイングマネージャーからEMへとステップアップする上で、どのようなマインドセットや経験が必要となるか
• マネージャー層の育成の再現性を上げるためのヒント

概要

こんにちは、椎葉です。僕は現在、EM(Engineering Manager)ではなく、IC(Individual Contributor)として仕事をしています。このセッションでは、EMではないメンバーの視点で「こういうふるまいをしてくれるEMだと仕事がしやすいな」と思うことを紹介します。

みなさんは、もともとプレイヤーとして動いていて、そのスキルの高さや責任感の強さ、落ちそうになったボールを積極的に拾う姿勢などが周囲から認められてEMになったのではないでしょうか。そして、EMになったとたんに周囲からの期待があがってプレッシャーを感じていたり、これまでのプレイヤーとしての自分とマネージャとしてチームを育てることのバランスをどこに定めたらいいかを悩んでいたりしないでしょうか。

僕はこれまでたくさんのEMと、いろいろな関わり方で仕事をしてきました。その様々な関わり方の中で、自分の中に「EMがこんなふるまいを見せてくれるとメンバーとしては働きやすいな」ということや、「EMになりたてだとこういうことに悩むんだな。その場合はこういうサポートが役に立つんだな」ということが経験や知識として溜まってきています。

このセッションでは、その経験や知識をみなさんにお伝えします。

EMになってメンバーとどのように接していけばいいか戸惑っている方、ついプレイヤーとして動いてしまってメンバーの育成をどうしたらいいか悩んでいる方、EMとしての経験を積んで当初の悩みは減ってきたけどこれからもう一歩成長するにはどうしようかと考えている方、そんなみなさんに聞いてもらいたいなと思っています。

Learning Outcome

このセッションを聞いてくれたみなさんが、ポジティブな気持ちになって、何か少しでもヒントを得て、明日から前向きに新たな一歩を踏み出す背中を押せるようなセッションにしたいと考えています。

• EMがどんなふるまいをしてくれるとメンバーは動きやすいか
• エンジニアとしてスキルが高く責任感が強い人がEMになったときに何に悩むか
• その悩みをどのように解決していけばいいか、など