トーク

概要

みなさん、元気ですか！！
採用活動、頑張ってますか！？

僕たちカミナシの採用チームも毎日モリモリ頑張っています。

このセッションでは、カミナシが行っている現場"連携"の採用スタイルとその中でEMが果たす価値について話します。
EMは吉永( @satossi )、HRはリクルーターの木村（ @kimkimniyans ）の2名でのセッションとなります。

現場"主導"での採用スタイルが広まってきていますが、カミナシではあえて現場"連携"での採用スタイルであるということにこだわっています。
Hiring Managerを務めることになる EM と、リクルーターを務めることになる HR。どのような役割分担や連携があると、採用活動がスムーズに進むのでしょうか。
EMとHRでは異なるバックグラウンドを持つことも当然あり、採用に対する考えやスタンスの違いから、意見の衝突が発生する、なんてことも少なくありません。
実際に僕たちも、これまでに幾つもの衝突があり、葛藤を乗り越えて、採用活動における成果に繋げることができました。
笑いあり、涙あり、感動ありのエンジニア採用のリアルをお届けします。

Learning Outcome

採用活動におけるノウハウやスタンスも学べますが、一番の Outcome は採用活動に対する情熱です！
みなさんのハートに火を点ける自信アリのコンビです、乞うご期待〜〜

概要

現代のソフトウェアエンジニアリングにおけるマネジメントは、多様なバックグラウンドやスキルを持つ人々が協力する場として、ますます複雑さを増しています。
本セッションでは、コンピュータアーキテクチャの歴史に着目し、その進化や課題をマネジメントの視点から読み解きます。
たとえば、過去に注目されたヘテロジニアスプロセッサが抱えた困難や課題、その試みが辿った歴史を振り返り、これを多様なメンバーで構成されるチームのマネジメントに重ね合わせます。
この歴史的事例を通じて、チームの特性や構造に応じた柔軟で戦略的なマネジメントの重要性を考察します。
発展のスピードが速いコンピュータアーキテクチャの事例から、マネジメントにおける試行錯誤の価値を学ぶというユニークなアプローチをお楽しみください。
また、エンジニアにマネジメントの重要性を理解してもらうのは一筋縄ではいきません。
しかし、彼らが日々扱うコンピュータそのものの歴史を材料にすることで、説得力のある議論を展開できるはずです。
このセッションでは、コンピュータアーキテクチャの歴史を通じて、エンジニアとマネジメントの共通言語を構築する試みも提供します。

Learning Outcome

• 発展が著しく、進化の速いコンピュータアーキテクチャの歴史を通じて、マネジメントを抽象的かつ俯瞰的に捉える視点を得る。
• 異なるバックグラウンドやスキルを持つメンバーで構成されるチームが抱えがちな問題を構造的に理解し、効果的な対策を検討できるようになる。
• 技術への深い関心を持つギークなエンジニアにも、マネジメントに対する理解や関心を深めるための具体的な話題や視点を持ち帰ることができる。

概要

私がCTOを務めるmentoでは企業の管理職向けに「コーチング」を提供しています。
こう聞くと「エンジニアいなさそう」「プロダクトあるの？」そう思われるのではないでしょうか？
事実、まだまだ労働集約的な側面は残っておりエンジニアリングやプロダクトの外側でサービス提供や売上が発生するモデルになっています。
しかし、それでも弊社はテクノロジー活用を企業の中心だと思っており、今までの5年間「コーチング」のデジタライゼーションを進めてきました。

必ずしもプロダクトが会社の中心にならない業態はたくさんあると思っています。そういった場合に、自社のテクノロジー投資をどう位置づけるのか、目標管理をどうするのか、どうやってテックカンパニーへと進化させていくのか、それらを思考し、実行に移していくのはCTOやEM等の上級職の非常に重要な仕事だと捉えています。
私が今までコーチングの会社のCTOとして、何を葛藤し、どういうトライをし、結果今どうなっているのか。それをつまびらかにお話することが世の中のスタートアップのCTOやEMの方のエンパワメントに少しでもつながるかも知れないと思っています。

Learning Outcome

• シード~シリーズAフェーズのCTOの仕事や葛藤について知れる
• プロダクト以外で売上が上がるモデルのビジネスのエンジニア組織の位置づけやあり方について知れる

概要

スタートアップでのエンジニアリングマネージャーとして、最高のチームをつくろう！と意気込んで失敗...、気づきを得てからの挑戦と、
転職をはさんで再びエンジニア、人事、VPoE、アジャイルコーチなどを経て、大企業で社内のさまざまな組織の課題解消を伴走しながら目指す仕事をしている今にいたるお話しです。

各職種のタイミングで、どのようなきっかけや機会、気づきがあったのかを共有し、話を聞いていただいた方の今後のキャリアを考えるための事例を提供できたらと考えています。

(仮)ですが、以下のようなお話しができます。

• EMとして最高のチームをつくることが間違いだと言われた話
• エンジニアリングマネージャーからエンジニアに戻って、うまくいかなかった話
• 大企業の中で、同じ会社の人たちに自組織の広報、営業活動をがんばる話

Learning Outcome

• EMからVPoEに、"昇進"するのではないキャリアの参考事例を知る
• EMでありながら、その枠を広げる考え方を知る

概要

本セッションは、組織文化が曖昧な言葉になってしまっているとメンバーに思われていないか懸念しているマネージャーに向けて、組織の質を明確に制御可能にする方法を解説します。

観察や実行、評価することが困難な「文化」に介入するのではなく、観察/実行/評価が明確な行動(プラクティス)の集合を対象にすることで、ふるまいをエンジニアリングを可能にし、結果として上質な組織文化を構築します。

様々なメンバーがよりよく働ける状況を整え、顧客に優れたプロダクトを提供するために、組織文化というコンセプトがよく使われます。しかし、この組織文化は観察が難しく、よくするための方法や、評価も簡単ではありません。

下記に答えることは容易ではありません。
・何が組織文化で、何が組織文化ではないのか(観察)
・どのように質を上げるのか(文化としての実行方法)
・その質の良し悪しをどのように評価するのか(評価)

プラクティスというコンセプトがあります。望ましい状態を引き起こす繰り返される行動といえるものです。

たとえば、挨拶は、会社の出退勤や、他部署の人達とのミーティングで行われます。人が境界を通る際に行われるもので、一日当たり少なくとも2回、実施時間としては数秒ほどで行われる行為です。1on1は会社によっても実施は異なりますが、メンターとメンティーの関係にある二人が毎週30分から1時間行われる行為です。

こういった活動の集合が組織のふるまいになります。あいさつといった些細な行為も、人によって気持ちよいものもあれば、そうでないものもあるでしょう。質があるということです。質の良し悪しを理解するとうまくできるようになります。

このように、社内で行われるより良い状況を生み出すために行われる活動を、質的に制御可能なエンジニアリング対象として捉え、その行動の観察/代替策の実行/評価を通すことで、組織集団としてのふるまいを短期間で改善する方法を解説します。

Learning Outcome

　・好ましい状況を引き起こす活動の観察できるようになる
　・さまざまな活動を組織の全体性の観点から整理できる
　・些細な行為を含めて評価できる
　・行為の改善を実行できる

概要

長年テスターやQAエンジニアとして従事してきた私が、初めてエンジニアリングマネージャーとなった経験を振り返ります。この新しい役割でどのような変化や挑戦があったのかを探ります。

Learning Outcome

期待する参加者

• QAエンジニアおよびQAマネージャー
• QAエンジニアをチームに迎えるエンジニアリングマネージャー
• マネージャーになることに躊躇している方、あるいはそれをサポートしたい方
• マネージャーとしてのキャリアに興味がある方

Outline

1. 経歴

   • プログラマー5年、テスター10年、QAエンジニア6年（時折スクラムマスターも担当）、エンジニアマネージャー半年
   • 基本的にリモートでの業務

2. なぜエンジニアリングマネージャーになったのか

   • テストマネジメント全般を担当していたため、メンバー評価が加わる程度と考えていた
   • 今規模の会社でマネージャー経験を積んでみたかった
   • 新しい視点を求めて見えない世界（視座）を探索したいという探究心

3. ピープルマネジメントに関する考えと課題

   • メンバーを最大限に活躍させたい
   • 自分が今より多くのメンバーを管理するには限界を感じている
   • ジュニアメンバーを迎えるための自分のキャパシティに不安がある

4. QAエンジニアとエンジニアリングマネージャーの違い

   • 評価をすること
   • プライベートチャンネルでのコミュニケーション
   • 変わらない点: テストマネジメント全般

5. QAマネージャーとエンジニアリングマネージャーの違い

   • QAエンジニア以外のエンジニアを見る可能性もあると考えている
   • 組織内に閉じた話はせず、エンジニアリング全般の中でQAに関わる
   • Automation、 CI/CD、インシデント などに関することをエンジニアと進めることができる
   • 他職種とのグレードや評価比較が可能

6. エンジニアリングマネージャーとしての気づきと課題

   • 褒める機会や意識が増えた
     　 自分のメンバーに対して
     　 他カンパニーや他職種のメンバーに対して
     　* 専門外の領域の学習が必要

7.QAマネージャーとしての課題

• 手を付けられていない領域への取り組み

概要

昨今のエンジニア組織論の盛り上がりで、リーダーシップ論、マネジメント技術、採用戦略、評価制度など、組織マネジメントにまつわる話が多く語られるようになりました。
一方で、あまりまだ語られていない分野があります。労務です。

私はEMになった頃、知識もなく労働管理、休職、福利厚生の設計などの人事労務オペレーションに関わったり実現する立場になり、戸惑いを覚えました。
労務部門の助けを借りながら経験を積む中で、従業員エンゲージメントを向上させ、組織のパフォーマンスを最大化しするためには、労務の知識と労務部門との協力が必要不可欠であると強く実感しました。

また、Web業界ではここ数年、さまざまな企業が柔軟な働き方や魅力的な福利厚生を打ち出す企業が増えてきました。コロナ禍以降はリモートワークも当たり前になっています。
そういった柔軟な働き方を設計・運用し、実現しているのは企業の労務部門です。
我々ソフトウェアエンジニアが現在、柔軟な労働条件のもとで働けているのは、たくさんの事例を世に送り続けてきてくれた、さまざまな企業の労務部門のおかげなのです。

本トークでは、これまでEMの分野においてあまり語られてこなかった、労務についての基礎知識と私が経験した事例をお話しします。
突然労務オペレーションに関わるようになったEMへの手助けや、我々がより働きやすい社会を実現していくアクションの一つになれば幸いです。

※ 具体的な事例は、内容についてスライドの撮影やSNSでの言及をお断りする可能性があります。ご了承ください。

トピック

• 労務オペレーション
• 制度設計
• 労働時間管理
• 休職
• その他トラブル事例

Learning Outcome

• 基礎的な労務の知識とオペレーションの理解
• 突然労務オペレーションに関わるようになったEMへの手引き
• 柔軟な働き方を実現していくための基礎知識の習得

概要

複雑化する業務システム開発において、如何にチームの知識を効果的に共有・創造していくかが、プロジェクトの成否を分ける重要な要素となっています。
当チームは、障害福祉という高度に専門的なドメインに対し、モブワークを軸とした知識創造の仕組みを5年間にわたって実践してきました。

本セッションでは、2020年からのモブワーク導入・発展の過程で得られた具体的な知見を、実践的なプラクティスとともにご紹介します。

紹介するモブワークの遍歴としては以下の様になります。

• リアル期
• フルリモート期
• 安定期
• プロジェクト立上げ期（暗黙知を人に）
• チームビルディング期
• シン共同開発期
• 知識創造型へ

遍歴にあるプロジェクトの状況やチーム構成に応じて、モブワークの取り組みも変化させてきました。
モブワークには多くのメリットがありますが、プロジェクトの状態やチームの熟練度によって、目的や効果的な方法が異なると感じています。
ナレッジの共有が重要ですが、チーム内にナレッジがない場合でも機能します。
その際、知識創造のサイクルを意識したモブワークが鍵となります。

モブワークと個人ワークを組み合わせ、多様性を活かして知識創造を行う組織を実現します。

複雑なドメインに対応するために、以下の点を中心にお話しします。

• モブワーク実施の具体的なプラクティス
• チーム内での知識共有を促進するファシリテーション手法
• 予想される課題と対応策

Learning Outcome

1. 実践的スキル
   • モブワークに適したタスクの選定方法
   • 効果的なファシリテーション手法
2. マネジメントスキル
   • チームの練度に応じたスタイルの見直し
   • 必要なツールと環境の整備
3. 組織変革の視点
   • 学習する組織への転換方法
   • 持続的な知識創造の仕組み作り

概要

スクラム、アジャイル、XP、etc…それらに関わっている皆さんであれば、人と関わるということが開発においてどれほど重要でどれほどの部分を占めているかおわかりでしょう。

今回の発表では「なぜ私がやさしさが大切であると思っているか」から始まり、今まで個人的に集めた文献の中から仏教・哲学・学術などの観点から『やさしさ』とはなにか？どのようなものなのか？どうしたら身につくのか？に近づいていきたいと思います。

このトークは『Scrum Fest Mikawa 2024』にて【『人にやさしく』するということ】として発表したものの、改訂・増補版になります。
聴講者の方々からは「考えたことなかった」「普段の自分からは触れない領域の話が聞けるのはフェスの醍醐味」「今回聞いた中で一番不思議だった」とのお言葉を頂きました！
今回は前回の発表で分かりにくかったかなと反省した部分を修正し、語れなかったものに関しても増強しています。

そしてEMConfにアジャストして、『やさしさ』をマネージャーとしてどう役立てるかについても話したいと思います。

Learning Outcome

• 明日から人にやさしくしようと思える
• 『やさしさ』とは後天的に身につけることができる技術であると理解できる
  • そして『やさしさ』を身につける努力をしたいと思える
• EMとして『やさしさ』をどう活用するのか一例を知ることができる

概要

自身が2つの会社にて合計で約10年経験したEM役割における
失敗と学びを赤裸々にお話します。

主に以下のような領域について
・ピープルマネジメント
・コンフリクトマネジメント
・採用
・持続可能な学び

Learning Outcome

・事前に知っていれば回避できるアンチパターンが分かる
・同様の経験をした時の立ち直り方の1例を知れる
・EMを未経験の人には、EMに挑戦することのハードルが下がる

概要

エンジニア組織を拡大することは難しいです。ここで指す拡大とは以下の2つを意味します。

• メンバーを増やすこと
• メンバーが成長すること

メンバーが増えるだけでなく個々のメンバーが成長しなければ、組織としての拡大にはつながりません。

メンバーを増やすためには採用をしなければなりません。しかし、中途採用で優秀なエンジニアを採用することは難しいです。

そこで弊社が注力しているのは、新卒採用です。

弊社はスタートアップですが、通常スタートアップでは新卒採用に注力しません。しかし、会社を飛躍させるのは、凡庸な中途人材よりトップレベルの新卒です。聡明で深い思考力があり、学習意欲が高く、あらゆる領域にチャレンジできる新卒を取るべきです。

そして、組織の拡大のためには、採用だけでなく入社後の成長にもフォーカスする必要があります。

例えば、成長のためには、オンボーディングを侮ってはいけません。新しいメンバーがすぐに作業に入れるように開発環境のセットアップを一緒にやってあげていますか？自社のすべてのプロダクトを新しいメンバーに触ってもらっていますか？新しいメンバーをあらゆる部署のメンバーにつないであげていますか？オンボーディングでは、新しいメンバーが走り出すための必要なすべてをするべきです。

弊社では新卒のエンジニアが成長できるためのさまざまな施策を実行してきました。それによって新卒エンジニアが主力メンバーとして成長し、エンジニア組織が拡大してきました。

本トークでは、エンジニア組織拡大のための採用戦略から育成までを紹介します。

目次

• 採用編
  • トップレベルの新卒を取れ
  • 新卒採用もリファラルで取れ
  • 破格のサマーインターンを用意する
• 育成編
  • オンボーディングをなめるな
  • 正社員全員がメンター
  • あらゆる部署に直接つなぐ
  • CEOと議論させる
  • 肩書きを付けない
  • 新卒メンバーに教えを請う
  • 外部メンターの有効性
  • 報酬を惜しまない

Learning Outcome

• エンジニア採用における新しい考え方や戦略
• エンジニアの育成・メンタリング方法

概要

皆さんは間接部門のエンジニアリングマネジメントをどのように行っているでしょうか？
本セッションは間接部門の1つであるQA（品質保証）チームのEMについてのお話です。

間接部門の難しさ

QAは間接部門と言われます。間接部門とは直接売上を生み出すことのない業務を担っている部門であり、評価をしづらい部署といえます。

例えば、開発であれば「機能Xの開発によって、A社の受注に繋がった」といった話ができるでしょう。

一方でQAの場合、「遅延なくリリースできた」と言っても、それが

• QAメンバーが工夫できた
• 開発メンバーが優秀で不具合がほとんど出なかった

のどちらなのか判断が付きづらいです。

評価のしづらさによる悩み

評価のしづらさは以下のような悩みに繋がります。

• 評価面での悩み
  • 自己評価を書けない
  • 評価者が評価を付けづらい
  • 他チームのマネージャーにメンバーのアピールがしづらく、評価のキャリブレーションが難しい
• 日々の業務での悩み
  • 評価軸を作りづらいため、メンバー本人が自信を持って行動できない
  • どのように進めれば良いのか判断がつきづらく、成長を実感しづらい

QAチームのEMになって気付いたこと

そんな中、私はQAチームのEMとして働くようになりました。
EMになって、QAメンバーは成果を出していないのではなく、自分の成果をアピールするのが上手でないことに気付きました。例えば、成果として「機能Aと機能Bと機能Cのテスト設計とテスト実施を行っていました。」としか書かなかったりするのです。

EMとして行動したこと

私は1on1などを通じて、QAメンバーが日々行っている工夫をできるだけ言語化しました。本人は「些細なことなんだけど」と前置きしていても、私からはすごく魅力的に見え、かつ上に書いた悩みを打破する宝の山でした。

本セッションでは、宝の山となる些細な工夫を見つけ出して、メンバーの成長に繋げるためのコツを、具体例を交えてお伝えします。

Learning Outcome

• 間接部門のEMになった際に、成長を促すコツを知れる
• 間接部門かどうか関係なく、1on1で聞き出した些細な工夫をピックアップして成長に繋げる方法を知れる

概要

外部からいきなり役職付きで就任する時に大事なことを話します

Learning Outcome

外部から何らかの役割を持って中途入社する人が対象
パラシュート人事で失敗しやすいポイントと、それに対しての対応の仕方を共有します

基本的にはこの記事に書いた内容を話す予定です
https://note.com/bto/n/ne15a74ff6afe

セッションは20分でも40分でもどちらでも大丈夫です
時間によって内容を合わせます

概要

このセッションでは、アジャイルに親しんできたエンジニアがエンジニアリングマネージャーに挑戦する中で経験した失敗や改善の取り組みについてお伝えします。そして、これからエンジニアリングマネージャーに挑戦しようとしているエンジニアの方々に勇気を、新任のエンジニアリングマネージャーを育成する方々には新たな気づきを得ていただくことを目指しています。

私は若手の頃からアジャイルやスクラムの概念に触れ、その中で「良いマネージャーとは何か」という漠然とした理想像は抱いていました。
そんななか、今のチームで開発責任者にならないかという機会をいただきました。開発責任者はいわゆるエンジニアリングマネージャーのような位置づけで、プロダクトマネジメント・プロジェクトマネジメント・ピープルマネジメントなどの責任を持つロールです。

いざ開発責任者になってみると、多くの困難が待ち受けていました。
日々の業務で「何をやっていいのかわからない」という問題。
徐々に増えてくる会議や緊急対応に追われて「何もできない」という問題。
開発メンバーから「このバックログは本当にやるべきことなのか？」という問いに答えられないという問題。
速く走る方法を知っているだけでは足が速くならないのと同じように、知識としてマネジメントを知っていても、それを実行に移すには大きな壁があることを痛感しました。

しかし、そんな状態の自分を救ってくれたのはこの界隈のコミュニティの方々でした。
社内ゼミの方々への相談、様々な文献に触れる中で勇気をもらい、次第に職場の方々にも自分の状態を素直に伝え、相談できるようになっていきました。

そこで感じたのは、エンジニアとして働くときとマネージャーとして働くときでは頭の使い方が全く異なるということです。
まだまだ失敗ばかりのマネージャー人生ですが、このような自分なりの経験をお伝えすることで、少しでもマネージャーとしての新たな視点や気づきを持ち帰っていただければ幸いです。

Learning Outcome

エンジニアの方が、「エンジニアリングマネージャーになれるかも」という感覚を持っていただける。
エンジニアリングマネージャーを育成する方々に対して、新たな視点とアドバイスの引き出しを増やす。

概要

みなさんの会社では組織を大きくしたいと思ったことはありませんか？

昨今、多くの会社が採用に大きな労力をかけています。その理由は会社によって異なりますが、現状維持の人手不足以上に事業成長のために組織拡大のミッションを負ったマネージャーが多いのではないでしょうか？

このセッションでは事業拡大の戦術として組織拡大を前提としたときに、どうすればうまく組織をスケールさせられるのか？に焦点を当てます。

組織拡大は諸刃の剣です。安易に人員を増やしてもうまくはいきません。
マネージャーがボトルネックにならずに組織を大きくするにはどうしたらいいでしょうか？

それは、エンジニアリング組織における"文化"です。

文化を生み出し、自分の手を離れて文化が進化していくモメンタムを作ることができれば、それがスケールの下地となります。
しかし、ただのモメンタムでは片手落ちです。そこにいかに狂気を込めるかが組織の強さに変わります。

• 文化とは何か？マネージャーはそれにどう関わるか？
• 文化の蒸留と言語化
• マネージャーが楽しそうに仕事をすること
• マネージャーの狂気
• スケールとマネージャーの立ち位置

上記のテーマで拡大する組織の中でEMもといマネージャーがどう振る舞うと良いのか？についてお話しします！

Learning Outcome

• エンジニアリング組織の文化の作り方について知ることができる
• 文化の醸成におけるマネージャーの振る舞い方が時系列でわかる
• マネージャーが発揮すべき狂気について理解できる

概要

転職が一般的になりつつある今の時代ですが、「1つのサービスに長年携わることでこそ、システム設計における深い学びが得られる」という意見も増えています。私は飲食予約サービス「Retty」に関わって6年、その間にEMおよびVPoEとして大小さまざまな課題と向き合い、改善を重ねてきました。

本講演では、以下の具体的な事例を通して、各局面でどのような判断や実装を行い、何を学んだか、そして今どのようにその経験を振り返っているかを共有します。

• スクラムと大規模スクラム（LeSS）の導入：アジャイルを拡張して適用する中での成功と失敗
• マイクロサービスアーキテクチャへの移行：モノリシックからの脱却と、その後のシステムの柔軟性向上
• ライブラリやフレームワークの選定プロセス：技術選択の重要性とチームへの影響
• 内製システムのマネージドサービスへの置き換え：効率化とスケーラビリティを実現するための決断

この6年間で積み上げた知見をもとに、長期的な視点でのシステム改善や技術選定、チームマネジメントに関する実践的な学びを紹介します。

Learning Outcome

継続的な改善に関心があるEMや技術リーダー・意思決定者が下記の内容を学ぶことができます。

• 同一サービスへの長期関与で学んだシステム設計と改善の学び
• 技術選定やサービス移行を通じた効率化と成長戦略
• 持続的改善のためのチームマネジメントと意思決定のヒント

概要

Engineering Management に関するグローバルなサーベイである 2024 State of Engineering Management Report 、国内外論文、国内外カンファレンスの概要とトレンドを知れるセッションになります。

Engineering Managementを実践する時のエントリーポイントおよび自分のアウトプット場所の目安にもなります。Engineering Managementの基本用語を知っている前提になるかとおもいますが、全て参照先を明記するようなスライドになりますので、多くの方に見ていただきやすいセッションになるかと思います。

Learning Outcome

• Engineering Managementの国内外のイベントで発表してみようと思える
• 社内の改善に対して客観的に観察できるようになる

参考スライド

• プロダクトマネジメントのグローバルトレンド #pmconf2023

Outline

• 2024 State of Engineering Management Reportの紹介
  • 世界的なトレンド
  • 各トレンドに関連する論文
• Engineering Manager Conference Japan2025のセッションとの比較
• 海外Engineering Managementカンファレンスのセッションとの比較
• Engineering Manager Conference Japan2025と海外カンファレンスの相違

概要

プロジェクトで設定されている納期を果たせずに、お客様とも社内のステークホルダーとも関係性が良くない。ステークホルダー、ビジネスパートナーを含めて心理的安全性が確保できない。その結果、チームに大きな負荷がかかり、労働時間も長くなりメンバーの健康も損ね、生産性も落ちてしまう。そのようなビハインド状態の開発チームを立て直すために、エンジニアマネージャーとして何をしたら良いでしょうか？

登壇者である私は、リリースが半年延期し、ステークホルダーからの横槍も多く入り、労働時間も超過することが多くなって疲弊し切ったチームに途中からマネージャとしてジョインし、そのチームを立て直した経験があります。

本登壇では、私がエンジニアマネージャーとしてステークホルダーから権限を移譲してもらい、短期でチームと一致団結してリリースをやりきることで信頼を得て、その後チームでの生産性を改善し、最後にはエンジニアマネージャーが居なくてもまわるチームを作った事例をご紹介します。

Learning Outcome

• ビハインド状態を把握し、マネージャとしての取り組みを検討するためのヒント
• 理想的なマネジメントが難しい時に取る段階的なアプローチのヒント
• チームがステークホルダーから信頼を得るための活動
• 見守るだけではどうにもならない状態でのマネージャの振る舞いに対するヒント

概要

事業会社のストリームアラインドチームでEMに従事されているみなさま、こんなこと言われたことありませんか？
『そんなに時間がかかるの？』（あれもこれも全部最優先て言うから、、）
『これバグですよね？いつ直ります？』（それあなたが言った仕様です、、）

事業会社のIT部門では、事業価値向上を至上命題としてチームとテクノロジを磨きます。
EMはプロダクト・チーム・テクノロジのすべての成長に責任を負います。まさに完璧超人。
でも現実ではすべてを完璧にこなせる人など(ほとんど)いません。心ない言葉を投げつけられてしまう場面もあるでしょう。

でも大丈夫。そんなもんです。みんな通ってきた道ですよ。
ポイントを押さえて力を入れるところさえ掴めたら、後は勝手に回っていきます。たぶん。

ポイントは2つだけ。
１つは、事業と技術を繋ぐインターフェースとして機能すること。
事業理解を深め、それを継続的に発展可能な形でアプリケーションに具現化する過程をリードすること。
もう１つは、その過程で得た知見を組織の資産として紡ぎ、持続的な成長を実現する機能です。

このトークでは、事業理解を深めるための実践的アプローチや、チーム成長のステージに応じた具体的な施策を、実例を交えてご紹介します。
明日からの実践に活かせる示唆と共に、長期的な視座に立ったエンジニアリングマネジメントの可能性を提示します。

Learning Outcome

下記のような課題感を持つEMに対して :

• 事業部門との効果的なコミュニケーション方法

  • 要件の本質的な理解をどう深めるか
  • 優先順位の調整をどう行うか

• チームの技術力と業務理解の向上

  • 個々のメンバーの成長をどう支援するか
  • チームとしての総合力をどう高めるか

• 持続可能な開発体制の構築

  • 短期的な成果と長期的な成長のバランス
  • チームの自律性の確立

本セッションでは、以下の3つの視点から具体的な示唆を提供します :

1. 事業理解を深める実践的アプローチと、価値増幅のための具体的な施策（ソフトスキルとDDD）
2. 成長ステージに応じた適切なアプローチと、具体的な成功事例と失敗からの学び（モデリングの実践例）
3. 実践のためのフレームワーク（すぐに実践可能なアクションアイテム）

概要

私が所属するREADYFOR株式会社では4年以上前からフルリモートを導入しており、
開発組織内だけでも沖縄から東北まで様々な地域からエンジニア・PdMがリモートで働いています。
普通に働いていると交流や会話の時間自体が限られてしまう環境の中、

• 生産性を上げながら円滑に（なるべく楽しく）開発を進めたい！
• PdMなど非エンジニアとエンジニアとの間でも活発にコミュニケーションが生まれるようにしたい！
• でもお金はあまりかけたくない！

そのために私たちが行なってきた取り組みをなるべく具体的に紹介します。

目次

• 背景
• ええ感じに盛り上げるとは
• 取り組み集
  • 一斉1on1
  • ゆる飲み
  • 自動勉強会
  • もくもく会
  • MTGの再設計
  • 半年に一回のオフサイトイベント
  • 属人性LT
• 今後考えている取り組み

Learning Outcome

対象の方々

• リモートのエンジニアが属する組織のマネージャー
• 組織内の空気作りに関心のあるマネージャー

得られるもの

• リモートエンジニアを巻き込んだ施策の考え方
• 会議体や組織施策の設計観点とそれを盛り込んだ具体例