トーク

概要

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

戦略は、わたしたちが「どうしたいか=意思」を持たない限り、生まれません。
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になったときに何に悩むか
• その悩みをどのように解決していけばいいか、など

概要

筆者は現職に1人目EMとして転職し、入社3ヶ月後にDesign Managerを兼務することになりました。
それまでエンジニア組織以外のマネジメントをしたことがなくデザインに関する専門性もなかったため、Design Managerとして何をすればわからない状態でのスタートでした。

手探りの状態から試行錯誤を繰り返しながら1年が経過し、それまで行ってきた組織マネジメントの成果やEMとDesign Managerを兼務することのメリット・デメリットが言語化できる状態になりました。

小さな組織ではマネージャーの数が少ないためタイミングによってはEMがエンジニア以外のマネジメントを兼務することも十分にありえますが、そうなった場合にどのようにEMとしてのスキルを活かせるのか、自身の経験を踏まえてお話しします。

トーク全体を通して、EMのスキルを抽象化して考えることであらためて自身のスキルを認識・言語化する機会を提供します。
「EMとして自分が成長しているかわからない」「自分のスキルが別の環境でも通用するかわからない」といった悩みを持つEMが、トークの後には自身のスキルに自信を持ち、スッキリとした気持ちで明日からの業務に取り組めるような内容にします。

Learning Outcome

• EMのスキルを抽象化して考えることができるようになる
  • 日頃のマネジメント業務で発揮しているスキルの棚卸しをする機会を得る
  • EMで培ったスキルをエンジニア以外の職種のマネジメントで発揮する方法がわかる
  • EMのマネジメントスキルを「プロダクト開発組織のマネジメント」と1段階抽象化して考えることで、より広く組織に影響力を発揮する方法がわかる
• 規模の小さな開発組織でEMとDesign Managerを兼務することのメリット・デメリットがわかる
• ある日突然エンジニア以外のマネジメントを任されたときの心構えができる

概要

急成長する組織が抱える課題の一つに、"マネージャー不足"があります。

新たにチームを組成しなければならないのにマネジメントロールのアサインができない、チームのマネージャーのサクセッション対象がいないなど、時としてマネジメントロールのスケールは組織の成長のボトルネックになります。
マネージャーが不足すると、「複数のチームを兼務」や「条件を満たさない人物がアサインされる」ことになり、中長期的に見ると生産性が落ち、競合優位性に影響します。

特にプレイングマネージャーは、業務負荷や認知負荷が高く、誰もやりたがらない仕事になっていないでしょうか。
どうしてマネージャーは増えないのでしょうか。
組織に何が起きているのでしょうか。

本セッションでは、マクロ環境から私の所属する企業の事例まで含め、組織のスケールに合わせてマネジメントロールをどうスケールさせていくかの考えをお話します。

Learning Outcome

想定聴者

• 経営層、成長期にある組織の人事部門担当者、及びマネージャー層

アウトカム

• マネジメントの業務負荷の解像度を上げる
• 成長期の組織におけるマネジメントの負荷軽減対策

概要

組織形成において、最も重要なこととして採用活動が挙げられます。EMの仕事の1つとして日々採用活動を行っている方も多いのではないでしょうか。
私自身2回の起業経験の中でエンジニアが自分1人の所から、数十人規模の組織に至るまで組織を拡大させ、その中で母集団の形成や、選考フローの構築、面接など幅広く採用業務を行ってきました。

多くの企業が採用活動を行う中で、エンジニアの採用市場は苛烈し、難易度があがってきていると感じます。
そんな中で、皆さんの会社はどんなエンジニアに入社して欲しいか、採用に関わる全員が正しく把握できていますでしょうか。
また、選考フローではどんな採用基準を用いて選考を実施し、候補者の評価を行なっているでしょうか。

私は採用を進める上で、EMの方々が組織の現状や開発文化、求める技術水準をしっかりと把握し、採用フローや選考内容、評価基準を設定するべきだと思っています。
本発表では、組織をグロースさせていくために、自社に合った人材を見極め、どのようなアプローチで採用していくか、各選考ステップでの考えや、それに基づいた採用の実践・改善方法を、私が所属するスマートバンク社の事例をもとにお話しします。

CTO / VPoEの方がどんな方針で採用フローを組み上げ、メンバーを巻き込みながら実践していくのがいいか？既に採用プロセスに関わるEMが、どう面接をブラッシュアップしていけばいいか？そういった部分で示唆のある内容を提供します。

具体的な発表トピック
・会社の文化や行動基盤、コアバリューに即した面接方法の構築方法
・構造化面接の導入による、ブレのない一貫した基準での面接評価の方法
・選考フローや面接内容のブラッシュアップなど、採用自体のPDCAサイクルを上手く回す方法

Learning Outcome

対象聴者

• エンジニア組織拡大を行う上で、採用戦略や選考フロー / 基準の策定に関わっている方
• 既にエンジニア採用に関わり、面接等を実践している方

得られる学び

• エンジニア採用や選考ステップを作る上での考え方
• 選考フローや面接内容の構築方法、その具体事例
• 選考基準を設定し、計測、フィードバックループを回していく方法

概要

近年さまざまな組織で採用されている 1on1。
そのスタイルはさまざまで、組織の数だけベストプラクティスと悩みがあると思います。
このトークでは、1on1の目的を「組織にとって好ましい、良い習慣をメンバーに根付かせること」と定義します。
キーワードは「行動変容」。
保険医療の「動機づけ面接」などで実際に使われる、生活習慣改善の手法をヒントにして、
「良い習慣をメンバーに根付かせる」ために必要な考え方や、アンチパターンについて掘り下げていきます。

Learning Outcome

• 行動変容についての基礎的な考え方を知ることができる
  • そもそも人間の思考意思決定はどのように行われるのか
  • 自動的で処理が速いがバイアスの強い「システム 1」と、意識的で処理の遅い「システム 2」について
  • 習慣とはなにかと、それを改善するインパクトについて
  • 行動変容を促すために見極める 5 つのステージについて
• 保健医療の「動機づけ面接」から、 1on1 のベストプラクティスとアンチパターンについて知ることができる
  • 傾聴するときに相手を見るポイント
  • なぜ人はネガティブフィードバックを無視するのか
  • 自分を「1 人の人間」として認識させ、相手のシステム 1 に訴えかける方法
• 1on1 を実施する上で、その設計の指針やヒントになる切り口を知ることができる
  • 1on1 が「動機づけ面接」に似ている箇所と、そのまま利用できない箇所について
  • 心理学のあやふやさと、それでもEMが心理学を知っておくといい理由
  • 人間の「リファレンスガイド」としての心理学活用方法

概要

エンジニアリングマネージャー（以下、EM）が役割をまっとうするために重要なのが、周囲からの信頼貯金です。

メンバーから見た場合。
　この人なら、技術的な意思決定について任せることができる。
　厳しいスケジュールだけれども、この人が大切な案件だというなら、それを信じてコミットメントできる。

チーム外から見た場合。
　この人なら、チームが今やるべきことを期待通りに遂行してくれる。
　開発者体験というものはよくわからないけれども、このEMが大切だというなら今やっておいたほうがいいんだろう。

初めてEMになるタイミングでは、知らず知らずこの信頼貯金をもっているものです。（少なくとも、エンジニアが自分の所属しているチームのEMを任される場合。）
なぜなら、その組織で一定の成果を上げたからこそEMに任命されているはずです。
チームの技術スタックはよくわかっているし、チームに求められていること、そしてチームメンバーの特性だってよくわかっています。少なくとも、周囲はあなたがそういった状況にあると信頼しています。

EMがキャリアを積み重ねる中で、そういった信頼貯金がない状態に身を置くタイミングがやってきます。
組織内の他のチームに異動することになったり、新しいチャレンジを求めて転職したりーー。
特に後者の場合は、基本的に社内に自分のことを知っている人があまりいない状態からスタートするわけですから大変です。
そういった、積み上げでの信頼貯金がない状態でEMはどうやって信頼を獲得していけばよいのでしょうか。

10年以上マネジメント業を経験していく中で、私は何度か「信頼貯金がない状態でEMになる」という経験をし、信頼を勝ち得るために有効なパターンがある程度見えてきました。

• チームメンバーの人となりを知る
• 仕事「ではない」メンバーのパーソナリティに興味を持つ
• チームのミッションを知る
• チームの技術を知る
• チームと過ごす時間をたくさんとる
• 成果を出す

上記のパターンについて、実例を交えながらご紹介できればと存じます。

Learning Outcome

• EMにとってなぜ信頼を勝ち得ることが大切か知る
• ゼロベースで信頼を獲得する方法を学ぶ