トーク

概要

本セッションは、エンジニア組織のマネジメントを経験した方、これから挑戦しようとしている方、組織開発に携わる幅広い方々を対象としたセッションです。

私はこれまで、スタートアップ企業でエンジニア組織の事業部長を務め、大手企業ではテックリードやリーダーとしてマネジメントに携わってきました。現在はVPoEとしてエンジニア組織開発に取り組んでいます。その中で、エンジニア組織の立ち上げ、評価制度の策定、採用プロセスの設計、等級制度の構築など、多岐にわたる組織開発を実施してきました。立ち上げてから3年間で組織は大きく成長し、現在は正社員、業務委託、インターンを含めたテックチーム全体の規模が70名を超えるまでに至っています。

しかし、この成長の過程では、多くの挑戦や課題に直面し、数々の失敗を経験しました。
その中で得られた学びや教訓をもとに、EMとVPoEそれぞれの役割が組織にどのような影響を与えるのか、さらに両者の違いが現れる具体的な場面や課題についてお話します。

Learning Outcome

・EMとVPoEの役割の違い
・組織開発における成功と失敗の事例

概要

マネージャーは「面倒なことをやってくれる人」なのか

これまでマネージャーな方が「面倒なことをやってくれる人」として認識されている場面にでくわしたことがありました
マネージャー自身が「そう思っていますーハハハ」と言っていることもありますし、「マネージャーって開発に関係のない面倒なことをやる役割でしょ？」って言われることもあります
なんなら「面倒なことはマネージャーが全部やるからさ」とメンバーに言っている場に居合わせたこともあります
マネージャーは「面倒なことをやってくれる人」なのでしょうか

「面倒なことをやってくれる人」と思われる背景と影響

「面倒なことをやってくれる人」として扱われているマネージャーの共通点を自分なりにまとめたところ、自身の業務を明示していないのではないかな？と思いました

自身がやっている業務を自身で説明できない or しないため、その専門性やキャリアを示すことができない状態です
結果としてメンバーから見たときに、定期的に発生する「ステークホルダーとの調整」、「企業内の報連相（の窓口）」や「打刻修正や稟議申請を管理・承認する」などの業務の印象が残ります
その後マネージャーもとい面倒なことをしてくれる人は、

その存在にありがたみを感じられることはあるものの、メンバーが目指すキャリアとして焦点から外れていきます

マネージャーが「面倒なことをやってくれる人」で終わらず、組織の中で「この人でなければならない」「この人のようになりたい」と思われる存在になるためにどうすれば良いでしょうか

本登壇ではマネージャーが「面倒なことをやってくれる人」と思われないためにできることをお話ししようと思います

Learning Outcome

• 組織内のメンバーがマネージャーの活動内容がわかる状態になる
• 組織内のメンバーがマネージャーキャリアを目指すことに寄与できる

概要

2023年1月に VP of Enginnering というロールを引き受けた時、経営/プロダクトともに難しい状況下にあり、エンジニアも5人退職することが決まっていました。

そのようなサバイバルモード状態から今まで、事業や組織に対してやっていったこと、うまくいったこと/いかなかったことを振り返ります。
どちらかというとうまくいかなかったことの方が多く、かつ実は今もまだサバイバルモードから完全に脱しているかというと怪しいところではありますが、少しずつ少しずつよい方向に進めてきています。

この発表では、本やブログではあまり聞けないような厳しい状況下でのエンジニアリングマネジメントを、なるべく疑似体験できるように話していきます。
自分自身の振り返りの機会にすることはもちろん、皆さんが今後同じような状況になった場合にどうするか想像しながら聞いてもらい、血肉としていただけるような内容を目指します。

以下のような内容を盛り込んでお話する予定です。

• 自分自身も納得がいかないような経営/プロダクトの方針が伝えられた場合にどうするか
• 新規の採用活動を一時的に止めることになった時の動き方
• あの時知っておきたかったPLと予算、投資の考え方
• エンジニアリング組織以外の隣接領域に根っこの課題があると感じた時にやったこと、やるべきだったこと
• キーマンに退職を切り出されたらどうするか
• 今最初に戻れるならやっておくべきこと、今からでもすぐに取り組んでいくこと

Learning Outcome

• サバイバルモード下で半ばパニックになりつつ踏ん張っているマネージャー、チームリードに対して、N=1の体験談と勇気を提供します
• マネージャーロールを担っている方に対して、実体験せずに済むに越したことがないようなナレッジと疑似体験を提供します
• エンジニアリング組織以外に根っこの課題を感じているがどうすればいいかわからない無力感でつらくなっている人に対して、引き出しの一つとなるような動き方を提供します
• 他社のうまくいったマネジメントエピソードを見聞きして凹んでいる人に対して、たぶん皆そんなことばかりじゃないよと思えるような愚直でリアルな話を提供します

概要

遡ること1年半前、私は組織の中でEngineering Managementの立ち上げを行いました。
立ち上げてから約半年間の学びは以下のqiitaに記しております。
https://qiita.com/jinbeeee/items/e6e69ff0a68329f39308
当時はピープルマネジメントに着目し、Engineering Managementをスタートしました。

そこから更に1年が経ち、自分の中でのEngineering Managementが発揮する事業価値についても変化をしていきます。
単なるピープルマネジメントではなく、それを主軸にチームを率いてアウトプットの総和を最大化する存在へ。
単にチームを率いるだけではなく、個々人の信念をより深く理解しチームのビジョンを形成する存在へ。
そしてチームのビジョンと会社のミッションを連結する存在へ。

そうした自分自身の変化も起こしながら、また組織拡大に伴い後続のEMを複数人育成する中で一定のマネジメントポリシーが形成されてきました。

このセッションでは、そうした変化の過程を述べた後に、形成されたマネジメントポリシーについて解説を行います。
マネジメントポリシーは、以下の4つの章立てで構成されています。

1. マネジメントの目的
2. マネジメントのマインドセット
3. マネジメントに必要なインプット
4. マネジメントのアクション

Learning Outcome

以下のように幅広い方々へと知見の提供を行います。

• マネジメントがまだ確立されていない組織に所属するEM・EM候補の方 ... マネジメントをどう立ち上げたら良いのか、マネジメントを成立されるのに最低限必要なことを理解することができます。
• マネジメントが途上の組織に所属するEM・人事の方 ... 私のセッションの成長過程と照らし合わせて相対的な位置関係を理解し、次にどんなアクションを取ったら良いのか参考にすることができます。
• マネジメントが成熟した組織に所属するEM・VP・人事の方 ... 登壇者自身の経験や外部のマネジメント研修による認知心理学への理解から形成されてきたマネジメントポリシーの実例を自社のマネジメントポリシーと比較することで、マネジメントポリシーを更にブラッシュアップすることができます。

概要

テクノロジー企業が事業を成長させる上で必要なエンジニア組織を構築するためには、エンジニアの採用からオンボーディング、アクセラレーションによる個々の生産性の向上だけでなく、チームの編成とマネージャーの育成・強化が必須になってきます。
その中で一貫したオンボーディングプログラムによる早期の立ち上がりから、現場のファクトの集約と生産性やチームケイパビリティの定量的データ、そしてエンジニアのキャリア設計を軸にフェーズごとに開発組織を設計し、中長期目線で事業戦略に合わせた確度の高いエンジニア組織を運営するためのノウハウを公開できればと思います。

• 具体的には、以下のことをお話しいたします
  エンジニア一人一人の生産性向上
  エンジニアのチーム組成の方法
  チームの生産性向上に向けたプロセス
  事業成長を見据えた組織編成とスムーズな移行プロセス

Learning Outcome

• 想定する聴者
  既にVPoEやEMをやっており、生産性の高いエンジニア組織の構築に悩んでいる方
  リーダーやマネジメントレイヤーの育成に悩んでいる方
  経営目線で開発組織の設計が必要な方
  今後EMを目指すプレイヤー、プレイングマネージャーの方

得られる学び
経営目線、事業戦略目線での開発組織の設計プロセスと運用
エンジニアの採用からオンボーディング、組織構築まで体系化した戦略
エンジニア組織のコミュニケーションパスの設計とフェーズに合わせた段階

概要

エンジニアリングマネージャーとして、日々のチーム運営や意思決定において、メンバーの行動や思考に影響を与えながら、よりよいパフォーマンスやチームの協調を目指すことは重要な役割です。そこで「行動経済学」の視点を取り入れることは、エンジニアリングマネージャーがより戦略的にチームを導き、個々の生産性とチーム全体の活力を最大化するうえで大きな武器となります。

行動経済学とは、人々がどのように意思決定をし、どのような心理的な要因が行動に影響を与えるかについての理論です。これを理解することで、エンジニアリングマネージャーはメンバーの動機づけ、リスクの取り方、プロジェクトへの関与度を向上させるための具体的なアプローチを習得できます。また、プロジェクトが進行する中で、リスクの認知や新しい目標への挑戦といったチームの行動変化を、どのように促進し、サポートすればよいかも見えてきます。

このセッションでは、行動経済学の基本概念と、エンジニアリングチームの運営に応用できるノウハウを実践的にお伝えします。たとえば、メンバーの思い込みやバイアスに対するアプローチ、行動を変えるための「ナッジ」の使い方、意思決定のサポート方法など、日常的なチームマネジメントに組み込めるヒントを具体例を交えてご紹介します。さらに、行動経済学を活用して、より良い意思決定プロセスやチームへの影響力を高める方法についても解説します。

エンジニアリングマネージャーにとって初めての行動経済学の知識でも、すぐに現場で活用できるよう、専門的な概念をわかりやすく噛み砕き、ステップごとに解説します。チームの心理や意思決定に働きかけるための新たな視点を手に入れる登壇にします。

Learning Outcome

• チームメンバーの動機づけや関与度を高めるためのナッジの使い方
• 意思決定の質を高め、リスク管理に有効なマネジメント手法

概要

エンジニアリングマネージャーの役割には、開発チームの生産性を最大化し、プロジェクトを効率よく推進することが求められます。近年、開発生産性は「Four Keys」や「SPACE」など、生産性が高いチームに共通する指標によって語られることが多いですが、「インプットに対するアウトプットの大きさ」という生産性の本質的な意味に踏み込んで論じられる機会は限られています。

生産性を真に最大化するためには、インプットに対して最適なアウトプットを生み出すための戦略的なリソース配分が不可欠です。そこで鍵を握るのが「管理会計」の視点です。管理会計とは、組織内でのコスト構造やパフォーマンスを把握し、データに基づいて最適なリソースを配分するための会計手法で、エンジニアリングマネージャーの戦略的な意思決定に役立ちます。たとえば、機能ごとの工数配分や機能開発と運用・リファクタリングのどちらを優先するかなど、決められたインプットに対して効果的なアウトプットを実現するための戦略が見えてきます。

このセッションでは、管理会計の基本的な概念から実践的な応用方法までをエンジニアリングマネージャーの視点で紹介します。具体的には、各プロジェクトの進行状況をコストやパフォーマンスの観点で評価し、必要に応じてリソースを見直す方法や、インプットに見合ったアウトプットを確保するための戦略を、自身の実体験をもとに解説します。また、アウトプットを最大化するためのKPI設定や、コスト削減と生産性向上のバランスをとるためのノウハウもお伝えします。

会計知識のないエンジニアリングマネージャーでもすぐに理解・実践できる内容となっており、初心者にもわかりやすい言葉と具体的な事例で説明します。この機会に、戦略的リソース配分の知見を身につけ、チームのアウトプットを最大化する新たな視点を獲得してください。

Learning Outcome

• 管理会計をもとにした戦略構築能力の向上

概要

弊社合同会社エンジニアリングマネージメントでは、レンタルEMとしてスタートアップから日系大手企業、自社サービスからクライアントワークまで十数社に対して開発組織構築や再構築の伴走を行っています。そしてその前には見込み顧客として更に多くの企業問い合わせがあります。セミナーでよく頂く質問も取り上げながら、多くの開発組織が直面している「お悩みトレンド」と、2025年度に向けて出てくるであろう「組織の壁」についてお話します。

Learning Outcome

概要

今年で3期目となるスタートアップの弊社開発チームは今年、Findy Team Awardという開発生産性に関して優れた企業を表彰するAwardの一部門で、数ある企業の中から選出いただきました。

サービスリリース当初は数人の名もなき小さな小さなチームだったところから、どのように個人が、チームが成長していったかを失敗や成功を振り返りながらお話しします。自分自身耳の痛い話や、反省は多くありつつ、等身大であ...ありのまま起こったことを話すぜ！

Outline(仮)

・プロローグ 〜プロジェクトスタート、神が突然降りてきた〜
・第1章 〜リリースはしたものの...〜
・第2章 〜マネージャーがボトルネックになった日〜
・第3章 〜キセキの出会い〜
・最終章 〜チームのみんなと笑うために〜

Learning Outcome

・同じようにチームを率いる立場になって悩んでいる人を勇気つけられる
・スタートアップのEM/CTOという一見キラキラしたキャリアの裏側を知ることができる

概要

Platform Engineeringチームのマネージャーは、技術的な意思決定と組織的な価値提供の橋渡し役として重要な役割を担っています。本セッションでは、Platform Engineering組織におけるマネジメントの特殊性と、効果的なリーダーシップを発揮するためのアプローチについて、実践的な知見を共有します。

以下のポイントを中心に、具体的な事例とともにお話しします：

• プラットフォームチームならではのマネジメントの特徴と求められる素養
• 事業部門（ステークホルダー）と開発者の間に立つマネージャーの役割
• チームの技術的な方向性と組織のニーズのバランスの取り方
• プラットフォーム戦略の策定とロードマップの作成プロセス
• インナーソース文化の醸成とコミュニティマネジメント
• チーム編成と人材育成における特徴的なアプローチ

Learning Outcome

対象となる聴衆：

• Platform Engineering組織のマネージャー、またはその候補者
• 技術組織全体の生産性向上に関心のあるEngineering Manager
• プラットフォームチームの立ち上げや運営に携わる方
• 開発者体験の向上に取り組むリーダー

得られるもの：

• Platform組織特有のマネジメントスキルと実践的なテクニック
• ステークホルダーマネジメントの具体的な方法論
• プラットフォーム戦略の立案と実行におけるリーダーシップの発揮方法
• メトリクスに基づいた意思決定と成果測定の手法
• エンジニアの成長支援とモチベーション維持のための施策
• 組織横断的な影響力の築き方と合意形成の進め方

このセッションを通じて、参加者はPlatform Engineeringにおけるマネジメントの本質的な役割を理解し、自身の組織で実践するための具体的な知見を得ることができます。

概要

Engineerがフランスで生まれてから約400年、Managerがアメリカで生まれて約100年、プログラムの主戦場がSoftwareに移って約70年、そして、Software Engineering Managerが生まれてX年…。長いようで短い歴史の中の最先端に私達はいます。

トレンドが常に変わり、業務も目まぐるしく、日々忙しく生きている私達は自分を見失うことが多々あります。ましてや、まだ短い歴史の中にいる私達はしっかりとした土台があるわけではないです。

私達は今一度、より長いスパンの歴史とより多角的な思想とを触媒として、私達は今どこにいるのか、どこに行くのか、どこから来たのか、というのを見直し、それによって我々の活動とアウトカムを増幅させねばならない時に来ているのかもしれません。

本発表では、働く哲学者(Gentleman Philosopher)として生きることを選んだ人間として、マネジメントという思想史、計算機科学の哲学と歴史、そして、EMとしての実践、これらを踏まえて、「Software Engineering Managementの哲学」についての青写真を描きます。

Learning Outcome

対象の聴衆：

• EMになって年数が経ち慣れてきた人
• マネジメントを無意味な仕事だと疑うことがある人
• 哲学に興味がある人

得られるもの：

• EMの存在理由
• EMの倫理的土台
• 計算機科学の哲学と歴史
• マネジメントの思想史
• シーシュポスになっても苦しまないマインド

概要

株式会社kubell（7月にChatwork株式会社から会社名を変更しました）に在籍して11年、EMになって（たぶん）9年目の私が、弊社のEMの歴史をお伝えします。
EMはその職域の広さから、フェーズによって求められるものが刻一刻と変化していきます。
弊社でもスタートアップフェーズ、上場前、上場後、現在と、トライアンドエラーを繰り返しながらEMの形を変化させ続け、適応してきた歴史があります。
その歴史を振り返り、今後成長していく企業の中で陥りやすい罠や、その罠に嵌らずに乗り越える考え方について共有させていただきます。

特にスタートアップフェーズでこれから成長してく組織であったり、今後上場を目指している企業の方々に参考になる内容だと考えています。
また、kubell（旧Chatwork）という会社に興味がある方も、ぜひ聞いていただきたいセッションになります。

Learning Outcome

【対象の聴衆】

• スタートアップ会社にて、今後開発組織をスケールしていきたい方
• 現在、EMの役割について悩みがある方、役割をどう定義するか悩んでいる方

【得られるもの】

• EMに対する役割定義の参考例
• 開発組織スケールフェーズにおける陥りやすいポイントとその乗り越え方

概要

チームやプロダクト、事業、会社が成長すると、エンジニアリングマネージャ、リーダーが交代しないといけない日がいつか必ずやってきます。
そして、マネージャの交代は引き継ぐ側にとっても、引き継がれる側にとっても決して簡単なものではありません。

私は株式会社マネーフォワードでエンジニアリングマネージャを担当しています。
幸いなことに、チームもプロダクトもグロースし、複数のプロダクトチームをマネジメント範囲とさせていただいています。

開発組織のフェーズが移っていく中で、マネージャを引き継ぐことが必要な状況になり、後任のマネージャに託す経験をしてきました。
正直に言って、0からチームを作ってきたエンジアリングマネージャが、次のマネージャにバトンを渡すことの難しさを当時の自分はわかっていませんでした。
失敗したことも、成功したこともありました。

このセッションでは、私がマネージャを交代する上で持っていた仮説と、実際に引き継いでみて、その結果がどうであったかを振り返り、学びについて共有します。
また、引き継ぐにあたって私たちのチームにとって、エンジニアリングマネージャとして果たすべき責任と実施すべきアクティビティも見える化した結果もシェアしたいと考えています。

そして、この登壇では引き継ぎに成功した事例について、解像度高くお伝えするために引き継がれた側のエンジニアリングマネージャも一緒に登壇し、お互いの視点から当時どういう思いでやっていたか、そしてどうやって課題を解決していったかを対談形式でシェアしたいと考えています。
実務的な課題と、その時のお互いの感情がどうだったのか、といったリアルをお届けしたいです。

Learning Outcome

・エンジニアリングマネージャとして後任をどう育て、抜擢し、サポートするか、のヒントが得られます
・今後、エンジニアリングマネージャにチャレンジしたい人にとって、どのような課題が待っているかヒントが得られます

概要

私は5年弱に渡ってスタートアップ企業のVPoEをやらせて頂きました。
しかし、私はEMという職種は未経験でVPoEになり、VPoEとしてEMを何人も採用しました。
採用した人は皆様優秀だったのですが、彼らの能力を活かせたか？というとそうではなかったのではないかと自問自答しています。
現在ではVPoEではなく、二つのチームのEMとして活動をさせて頂いているのですが、
EMに戻って感じた事を皆様にお伝えできればなと思っています。

話したい内容

• VPoEとしての失敗事例と、EMになって気付いた改善点
• EMの成長を支援するためにVPoEができること
• 組織規模による課題の違いと対応方法
• EMとVPoEの効果的なコミュニケーション方法

Learning Outcome

■ 対象者

• 現役のEM、またはEM志望者
• VPoEとして活動されている方
• エンジニアリング組織づくりに関心のある方

■ 得られる気づき

• VPoEとEMの相互理解を深めるためのポイント
• EMの成長を阻害する要因とその対処法
• 組織全体のエンジニアリング品質向上につながる協業のコツ

概要　

従業員数約1000人/売上高100億円程度だった頃に入社した企業が、グループ連結で従業員数約1.4万人/売上高1100億円を超えるまでに成長。
領域もソフトウェアテストと品質保証だけだったところから、開発、ERP、セキュリティへと広げてきました。

このセッションでは、その激動の渦中に7年間いた自分が、VPoEになるまでの歴史とこれから挑戦したいことについて語ります。
段階的に多くのエンジニアを配下に抱えるにつれて、エンジニアのキャリアを支援する方法を考え、エンジニアが輝ける制度の設計をするようになりました。

現在、私の企業ではこれらが実現しています。
・スキル/成果重視の絶対評価制度
・年間昇給率平均11％ 　
・年間2000人の採用と退職率6%
・職級の細分化と定義の整備
・キャリアマップ
・フェロー制度
・検定/研修/勉強会/イベント
これらの詳細とその効果を共有します。

そして次に挑戦しようと思っていることは、活躍するエンジニアに提供する新しいポジションの設定です。「スタッフエンジニア」などを参考に、考えられるポジションをアメリカの事例などを元に洗い出し、まだ構想段階の内容を紹介することで、参加者とのディスカッションへ繋げられれば幸いです。

Learning Outcome

• スキルと成果に応じたエンジニアの評価制度とその効果
• エンジニアのロールやポジションの設計
• メンバーのキャリアを明るくするために制度設計から考えるVPoEの目線
• 事業会社にはない、SIerのジレンマ

参考

『エンジニアのキャリアパス。管理者以外の選択肢をつくる意義』
https://recruit.shiftinc.jp/career/library/id1295/
『トップエンジニアが輝ける制度の導入と障壁（エンジニア組織の未来 vol.1） 』
https://recruit.shiftinc.jp/career/library/id1343/
https://www.youtube.com/watch?v=m6oPRUwON_Q

概要

株式会社ExaMDは2024年に設立された医療ドメインに特化したエクサウィザーズのグループ会社です。私は新会社の技術開発部の部長として組織立ち上げを担いました。
新会社の組織立ち上げにおいてはやらなければならないことがたくさんあります。部長として部のメンバーが同じ方向を向き、事業を進めていくために必要と考える対応を行ってきました。
本セッションでは新会社の組織立ち上げにあたって、どのようなことを行なったか、その結果どうなったか、今後どうしていこうと考えているか、をお話しします。

どのようなことを行なったか
・組織のMission, Vision, Value策定
・メンバーとのコミュニケーション機会創出
・現状の整理と主要技術の決定
・ソフトウェアエンジニアの役割の明確化
・etc

今後どうしていこうと考えているか
・会社・部署を超えた交流機会の形成
・組織としての品質水準の策定
・etc

Learning Outcome

対象聴講者
・新組織立ち上げ時の動き方に興味がある方
・スタートアップの立ち上げに携わられている方
・いきなり部長を任されて困っている方

得られるもの
・組織立ち上げ期における動き方の事例

概要

私が所属するオープンロジは昨年、創業10周年を迎えた物流テック企業です。ビジネスは順調に成長し、現在は社員数が約200名の規模に拡大しました。私が入社してからの3年間で、エンジニア組織は2倍の規模に成長しましたが、多様なバックグラウンドを持つエンジニアが集まり、特に多くが最近入社したメンバーで構成されています。

エンジニア組織には多様な信念を持つメンバーが集まっており、オープンロジのエンジニア組織のカルチャーとは何なのかが共通認識化できていないことで、組織内の意思決定のスピードが遅くなってしまったり、採用時の候補者への印象が不明瞭になってしまっています。

私は3年前にオープンロジのVPoEに就任し、エンジニア組織のカルチャーを醸成するプロジェクトを立ち上げました。その中で得た理論と実践の知見を、お話ししたいと思います。

企業全体のカルチャーやバリューについては、多くの書籍や記事が存在しますが、エンジニア組織に特化したバリューやカルチャーに関する情報はあまり見かけません。
この登壇が、今後CTOやVPoE、EMがエンジニア組織のカルチャーに向き合う際の道しるべとなることを願っています。

Learning Outcome

本セッションではCTO・VPoE・EMがエンジニア組織のカルチャーの課題について取り組むための理論と実践的アプローチを提供します。具体的には下記が得られます。

・エンジニア組織のカルチャーについて体系的な理解
・カルチャー醸成に向けた具体的な取り組み
・エンジニア組織のバリュー策定の進め方と注意点
・全社のバリュー、事業・プロダクトとエンジニア組織のカルチャーとの関係性
・創業10年を経た企業での実体験から得た教訓

概要

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

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

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

Learning Outcome

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

概要

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

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

トークアウトライン

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

Learning Outcome

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

概要

皆さんは普段、どんなチームをマネージしていますか？そしてそのチームは今、どのような状況にありますか？
成果は出ているけどなんとなく雰囲気がよくない、あるいは雰囲気はいいけど成果に直結していない……などなど、いいところはそのままに、「もっとこうしたいのに！」と日々葛藤を抱える方も多いのではないでしょうか。

最大最速で成果を出すプロダクト開発チームには、「チームメンバー同士がお互いに認め合いながらも、遠慮せずにより期待し合う・求め合う」ことが不可欠です。私はその状態を目指すために、日々のチーム内コミュニケーションのみならず、ワークショップによる非日常性を活用して（言わば「劇薬」のように作用させて）います。

このトークでは、そんなチームのよいところは増幅させながら、更に各々の行動変容を促すための「ワークショップ」というツールの使い所、ファシリテーターとしての振る舞い方、気をつけるべきことなどについて、経験を通して学んだことをギュッと凝縮してお伝えします。

Learning Outcome

• ワークショップというアプローチは、チームがどんな状態のときに特に有効なのか、そのためにどのようにチームの状態を診断したらよいのかが分かる
• 目的に即したワークショップ手法の選び方をざっくりと理解できる（ワークショップ手法そのものについては詳しくは触れません）
• ワークショップの実施にあたり、どのような事前準備（含メンバーへの宿題）が必要かが分かる
• ワークショップ当日の振る舞い方、気をつけるべきポイントが分かる
• ワークショップ後、その効果を最大化させるためのアプローチを知れる