トーク

概要

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

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

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

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

トピック

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

Learning Outcome

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

概要

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

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

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

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

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

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

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

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

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で聞き出した些細な工夫をピックアップして成長に繋げる方法を知れる

概要

私はエンジニアとデザイナーのマネージャーを約2年間経験しています。マネージャーになる前は「手を動かせなくなること」に対して強い抵抗感がありました。しかし、実際にマネージャーとして活動してみると、成果やモチベーションが以前とは異なる形で得られるようになりました。

チームや組織の拡大に伴い、私自身も成長を実感し、メンバーが成長し壁を乗り越えた瞬間の達成感を共有することが、マネージャーとしての大きな喜びになりました。また、個人では成し得なかった成果をチームで成し遂げられることの価値にも気づきました。これが私自身のモチベーションとなっています。

マネージャーとしての成長の実感は、努力の成果が少し遅れてやってくる形で得られることが多く、マネージャーになった当初はモチベーションの維持や成果に常に不安を感じていました。

マネージャーという役職に対して迷っている方々に、マネージャーにしか得られない成果やモチベーションの価値をお伝えし、勇気づけられるようなセッションを目指します。

Learning Outcome

対象の聴衆:

・エンジニアリングマネージャー、デザインマネージャー、リーダー層、もしくはこれからマネジメントを目指す方々

聴衆が得られるもの:

1. 手を動かす役割からマネージャーに転向する際の心構えや新たなモチベーションの発見
2. チームの成長と自身の成長を連動させるためのヒントや実践例
3. マネージャーにしか味わえない達成感と、モチベーションに繋がった事例

概要

開発チームの急成長は、多くの企業にとって大きな課題です。コミュニケーション不足や生産性低下など、様々な問題が発生し、チームのパフォーマンス維持に苦労するケースも少なくありません。

本セッションでは、私がEMとして経験した開発チームの急成長と、それを乗り越えるための戦略についてお話します。
シニアメンバーのみで構成されたチームから始まり、ジュニアメンバーの受け入れ、10名を超えるチームでの課題、そして複数回のチーム分割（1→2→3→4→6チーム）に至るまで、様々な局面で直面した問題と、それを解決するために実践した施策を具体的に紹介します。

セッションのテーマ

• チームの変化: シニアメンバーのみのチームから、ジュニアメンバーの受け入れ、10名を超えるチームへと変化していく中で直面した課題と解決策を紹介します。
    - ジュニアメンバー受け入れのためのオンボーディングや育成の仕組みづくり
    - デイリースクラムの形骸化への対策と失敗
    - オーナーシップが発揮しづらい原因の特定と対応
• 複数回のチーム分割: 1→2→3→4→6チームへと分割する過程で得られた知見を共有します。
    - コンウェイの法則、チームトポロジーを考慮したチーム分割の実施
    - チーム分割によるコミュニケーションパス増加への対策
    - 必要十分なチーム間の情報共有や連携の仕組みづくり
    - アラートや問い合わせなど、落ちやすいタスクを確実に処理するための仕組みづくり

本セッションでは、これらの経験を通して得られた、急成長する開発チームを成功に導くための具体的なノウハウをお伝えします。

Learning Outcome

• メンバー構成ごとの開発チームに必要な仕組みづくり
  • シニアメンバーのみで構成されているチーム
  • ジュニアメンバーを含むチーム
• チーム分割のうまくいった事例・うまくいかなかった事例
• 組織全体の開発量を増やすために実践しようとしていること

概要

特に組織が小さいときには、プレイングマネージャーとして効率良く仕事を進めることが求められることも多いと思います。
ただし、組織が成長して業務が増えると、プレイングマネージャーがボトルネックになりがちです。

今回は、一人目の社員エンジニアとして入社し、そこからエンジニアリングマネージャーに移行していった過程についてお話します。

【入社時】

• 社員としては一人目のエンジニア
• エンジニアだけでなく、プロダクト開発全体の責任者
• テックリードとして設計・コーディング・レビューを担当
• QAも行い、最終的なリリース判断も行う

【現在(入社から約1年半後)】

• エンジニアリングマネージャーとしてエンジニア組織全体をサポート
• プロダクトのコア部分のコードは書かない
• たまに気分転換に社内用のスクリプトは書いたりする
• 既存プロダクトの開発〜リリースにおいて、ほぼ意思決定をする必要がない

Learning Outcome

• プレイングマネージャーからエンジニアリングマネージャーに移行していく過程の追体験
• プレイング部分の委譲戦略と、そのための具体的なアプローチ

概要

ベトナムにオフショア開発拠点を立ち上げたが、品質・生産性共に高くなく、日本側からは簡単な仕事しか任せられないという位置づけでした
退職率も高く定着せずに、成長が望めない状態でした。
このままではオフショア拠点の撤収もあり得る状態から
最終的に一番沈んでいた時期から1.6倍の生産性まで高めることができ
今やなくてはならない開発拠点という認識まで成長することができました。

日本開発と協力してどうやって品質・生産性を高めたかの事例をお話したいと思います。

目次

1． なぜオフショア拠点の立ち上げたか

2. オフショア拠点をどう評価する？
3. 生産性指標
4. 低品質。低生産性
5. 現地マネージャーに就任
6. 改善の取り組み
   　クオリティファーストスローガン
   　改善文化の醸成
   　開発フェーズ毎の生産性の分析
7. 生産性の功罪
8. 生産性のこれから

Learning Outcome

・生産性の測り方
・ベトナム人のマネージメント
・ベトナム人をどう成長させるか
・日本側とオフショア拠点の狭間でのどう調整を行うか

概要

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

Learning Outcome

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

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

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

概要

ミッション実現を加速させるための土台として、組織づくりはEMの重要な役割のひとつかと思います。
組織づくりは、組織が存在する間終わることのない、長期的な取り組みです。
長期的に組織に向き合ううえで持続可能なEMでいるために、大事だと思うことを整理してみました。

Learning Outcome

EMとして組織に向き合うことにたまに疲れてしまうかたに、ご自分のEM業の持続可能性を高めるためのヒントとなれば幸いです

概要

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

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

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

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

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

Learning Outcome

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

概要

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

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

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

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

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

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

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

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

Learning Outcome

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