トーク

概要

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

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

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

Learning Outcome

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

概要

こんにちは、新米VPoEです。

エンジニアリングをマネジメントする立場として、技術そのもの、あるいはチームやメンバーを向いた方法不確実性に向き合っていくだけでなく、経営との対話を通じた技術組織の価値を最大化するための目的不確実性に対して解を探し、戦略を立てていくことも重要です。

方法不確実性が指す技術戦略には、技術ロードマップや負債管理などテクニカルなもの、プロダクト戦略やバリューストリームなどユーザー価値にフォーカスしたもの、従業員エンゲージメントや採用プレゼンスなど組織的なもの、などが複雑に関連します。目的不確実性は、それらの戦略をなぜ志向するのか、どういった効果を狙うのかに関する説明責任などを指します。

その際、ハーバードビジネススクールで提唱された「バリューベース戦略」の考え方に基づき、開発組織が出す価値の最大化を目指し、組織全体のエンジニアリング価値を黒字化する戦略フレームワークに基づいた戦略の立て方について紹介します。
また、弊組織においてその戦略を適用させてきた実践過程について紹介します。

Learning Outcome

• 技術戦略と経営戦略を接続する一つの方法論として、バリューベース戦略というフレームを当て嵌めてみた事例
  • そもそもの技術戦略ってなに？
    • プロダクト価値の戦略：ユーザーへの提供価値、バリューストリーム、、
    • テクノロジーの戦略：技術投資、負債管理、、
    • 組織の戦略：エンゲージメント、採用プレゼンス、、
  • バリューベース戦略ってなに？
    • 顧客の支払い意思額と従業員の売却意思額の差分を価値とする、という戦略フレームワーク
    • ざっくりいうと売上ー原価＝利益と同じ構造
  • 技術戦略とバリューベース戦略がどう関連するの？
    • ★ここがコア
• 開発組織全体見て欲しいと言われてから戦略と実行をどのように模索してきたかの追体験

概要

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

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

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

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

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

Learning Outcome

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

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

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

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

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

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

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

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

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

概要

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

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

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

目次

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

Learning Outcome

対象の方々

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

得られるもの

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

概要

私達エンジニアリングマネージャーとして仕事をしていくなかで、日々様々なことに悩み迷うことが多いと思います。
エンジニアリングマネージャーとしての仕事を分解し、何を考え、何に悩むのか、そしてそれらに対してどのようなに気持ちの持ちようでいたら良いのか、私自身が6年ほどエンジニアリングマネージャーとしての経験から学んだことをお伝えします。
(トークテーマ: Philosophy - EMとしての生き方 -)

Learning Outcome

• 現在エンジニアリングマネージャーをしていて経験が浅く、気持ちの面で悩みがある方
• これからエンジニアリングマネージャーを目指したい方

上記の方をメインの対象として、主にメンタル面でのフォローできることを目指します。
また、エンジニアリングマネージャーの育成に関しても、ヒントとなるものが得られることも目指します。

アジェンダ

• エンジニアリングマネージャーの仕事のテーマ別分解（エンジニアリング、ピープルマネジメント、組織マネジメント、プロダクトマネジメント、プロジェクトマネジメント）
• エンジニアリングに関するポイント
  • 幅広く関心を持つこと
  • 部分的なロールモデル（マネージャーとスタッフエンジニア）
  • リーダーシップとマネジメントの違い、委譲(サーバントリーダーシップ)
• ピープルマネジメントに関するポイント
  • 人となりを知る。知ってもらう。
  • メンバーとの関係性
• 組織マネジメントに関するポイント
  • 組織設計、コミュニケーション設計(チームトポロジー)
  • 非合理的物事との戦い(Disagree and Commit)
• プロダクトマネジメントに関するポイント
• プロジェクトマネジメントに関するポイント
  • コミュニケーションのハブとなる

概要

EMとはどういう存在で、どのような役割を持ち、どのような影響を会社に及ぼすことができるのでしょうか？

EMが組織や事業に与えるインパクトはみなさん気になるテーマの一つだと思います。一方で、既にEMがいる組織ではEMを前提としてチーム組成やマネジメントが行われているため、純粋にEMの存在だけを切り取って会社への影響を測ることは簡単ではないでしょう。このトークでは、ゼロからEMを立ち上げたからこそ見えた、EMが生み出す組織と事業へのインパクトについてお話をします。

私が所属するスマートバンクでは創業から5年が経ち、組織も大きくなって創業者の目が行き届かない所が出るなどの50人の壁を感じるようになりました。例えば開発チーム内で抱えている課題の解像度が創業者たちとズレたり、会社内で起こる様々な課題の責任の所在が不明確になことで課題解決のスピード感を失なっていました。この背景には、権限委譲を進めたい経営陣に対して、その過渡期においてうまく責任と権限が整理しきれていない組織マネジメントの課題がありました。

そのため去年からマトリクス組織とEM制度を取り入れることで問題解決を図ってきました。特にEM制度においては、これまでCTOが抱えていたピープルマネジメントを権限委譲したり、2~3人のチームの育成に責任を持つことで自律的に成長し課題解決ができる開発組織を目指しました。その過程で実践したEMの役割定義やEMを育成していくための仕組みづくり、EMがチームで取り組んだ実践例を紹介しながら、どのように組織が変わっていったのかお話しする予定です。

創業以来の最もシンプルでフラットな組織構造を改革して、事業の加速に取り組んだEMのチャレンジ結果に興味はありませんか？

Learning Outcome

対象聴者

• EMの役割に悩んでる人やうまく価値を発揮できずに悩んでいる人に一つの解を提示する
• 組織デザインや組織のマネジメント手法について学びを得たい人に実践例を提示する

得られる学び

• スタートアップが直面する30人の壁、50人の壁の具体例
• 組織におけるマネジメントの重要性とEMが果たせる役割
• 会社に初めて生まれたEMという役割を定義し定着させるための仕組み
• EMが生み出す組織と事業へのインパクト

概要

エンジニアリングにおける開発生産性の追求から始まり、事業価値、そしてその先の社会的価値(インパクト)への思いを馳せながら、インパクトスタートアップにおける価値創造のプロセスと、それを支えるエンジニアリング組織の文化醸成について、具体的な実践知を共有します。

▼ 具体的な内容 

• ① 事業軸：企業価値からエンジニアリングの開発生産性まで、その方程式を紐解く。EMに求められる事業視点や戦略定義、構造分解について解説
• ② 技術軸：開発指標（FourKeys）と組織能力（DORAケイパビリティ）を活用した生産性向上の取り組み。定量的な可視化から改善施策の実装まで、具体的な学びを共有
• ③ 組織軸：EMが向き合う3つのマネジメントサイクルの解説。継続的な目的達成とモチベーションの関係性を構造化し、エンジニア組織の課題発見と文化醸成への取り組みを紹介

▼ INDEX

① 事業軸

1. 突如、EMに求められる事業視点！？
2. エンジニアリングにおける「戦略」とは？
3. エンジニアリングと事業価値、社会的価値の方程式
4. 開発生産性の方程式の構造分解

② 技術軸

1. 「開発生産性」を掲げた背景
2. ケイパビリティの課題を発見する ( 定性軸での課題発見 )
3. 開発指標の現状把握と普及推進 ( 定量軸での課題発見 )
4. FourKeysの導入を振り返る
5. コードと価値を中心に据える

③ 組織軸

1. EMが意識する３つのマネジメントサイクル
2. マネージャーの役割を明確にする
3. 事業成長の源泉となる文化醸成を根幹に据える
4. エンジニアリングに意義と楽しさを見出す
5. 組織課題を構造化して整理する

Learning Outcome

▼ 対象者

• 事業価値とエンジニアリングの接点に悩むEM
• インパクトスタートアップや中規模企業でエンジニアリングマネジメントを担当する方々
• 組織の成長と技術的な進化の両立を目指すエンジニアリング組織のマネージャーや責任者

▼ 得られるもの

• エンジニアリングと事業価値、社会的価値を接合する方程式
• 開発生産性向上に向けた方針策定とケイパビリティの課題整理、効果測定の視点
• エンジニアリング組織の文化醸成と成長を促進するための構造

概要

本セッションのタイトルに惹かれたということはピープルマネジメントが好きなEMでしょう。
そんな方に聞いていただきたいセッションになります。

私は前職でスクラムマスターからエンジニアリングマネージャー、VPoEとしてキャリアを積んできました。
そして、2024年10月より株式会社ログラスでアジャイルコーチとして新たなキャリアを歩み始めました。

VPoEからアジャイルコーチへの転身、地続きでないように見えるキャリアのように見えます。
しかし、私にはこの歩みは自然な歩みでした。
EMの重要な仕事として1on1があります。私はここでコーチングに興味を持ちました。
個人の支援だけではチームの力を最大化することは難しいと感じた私はチームの力を最大化するためにシステムコーチング®︎を学びました。
VPoEとなった私はプロダクトを価値を顧客に届けるためには、開発組織の力だけではなく、ビジネスサイドも含めた企業全体がアジャイルな組織であることが重要であると理解しました。
私にとって、アジャイルコーチは私にとってはごく自然な流れだったのです。

なぜそんなキャリアを歩むことになったのか、それは「好き」や「興味」といった内発的動機づけにありました。

本セッションでは以下のお話をします。
・ 私のキャリアの変遷
・ キャリアの変遷にあった学びやスキルなど、私を構成する要素
・ 好きこそものの上手なれ、EMだからこそ「EMたるもの」を追求するのではなく、「あなた」を追求していく

Learning Outcome

・ 次なるキャリアに悩むEMの方がご自身の歩みを省みて、明日からの活力を得る

概要

2024年8月28日に EM Fest で「プロダクト志向なエンジニア組織作り」を発表した後、以下のご質問を多数いただきました。
「シェアド・リーダーシップを試してみたいけど、実際どのようにおこなっているんですか？」

本セッションでは、このご質問に対する回答を具体的にお伝えします。

シェアド・リーダーシップ (Shared Leadership) とは、「全員が強みを活かし、リーダーシップを発揮するスタイル」です。
ソフトウェア開発現場での事例が見当たらなかったため、書籍や論文を読み漁り試行錯誤を繰り返しました。

7ヶ月半にわたるトライ＆エラーの結果、私たちのチームでは「部門横断案件を牽引するリーダー」が複数人誕生しました。
そして、リーダー経験者が未経験者を支援することで「新リーダー育成のサイクル」が回り始めています。

私自身も「EM」から「EM of EMs」へと役割が移り、視野・視座が変化しました。
「成熟度の異なる複数のチームに導入した場合、再現性はあるのか。」
「経験者がチームを越境して支援した場合、新たな化学反応を起こせるのか。」

当日は最新の挑戦結果をお届けします。

Outline

• 背景
  • タクシーアプリ『GO』の開発現場
  • 一人のリーダーが牽引することの限界
• シェアド・リーダーシップとは
  • リーダーシップ論の変遷
  • 全員が強みを発揮し、組織のリーダーシップを最大化
  • 互いの強みで補完しあう関係へ
• 実践前の疑問と仮説
• 部門横断案件のリーダーの育成
  • 自己発揮のためのセキュアベース
  • 意思決定基準のファシリテーション
  • 一人ひとりの多面的な強み
  • 仮リーダー体験の日常化
  • 多様なステークホルダーとの関係作り
  • 部門横断案件のリーダーの誕生
• 複数チームへの適用
  • リーダー経験者による言語化
  • 経験者による未経験者への支援
  • チーム間のスイッチング
• EMの役割
  • 3つのリーダーシップの使い分け
  • トップダウンとボトムアップの架け橋
  • 2階層上の視野・視座の獲得

Learning Outcome

• 全員の強みを最大化するプラクティスの獲得
• 部門横断案件を牽引するリーダーの育成フローの把握

概要

現在、私が所属する「Ubie株式会社」は、ホラクラシー組織を採用しています。
ホラクラシー組織には肩書きがなく、全員が役割（ロール）に基づいて活動しており、一般的にマネージャーと呼ばれる人がいません。
しかし、組織の規模が一定以上になると、組織をうまく運営していく上で、マネジメントの仕組み自体は必要となってきます。

本セッションでは、ホラクラシー組織における基本的な仕事の流れを説明します。
そして、ホラクラシー組織において、どのようなマネジメントの仕組みを実現しているのか、一般的な組織とのメリット・デメリットを示しながら解説します。
また、評価についても報酬に紐づかない形となっているため、その内容もお伝えします。

Learning Outcome

• ホラクラシー組織とはどういうものか
• ホラクラシー組織におけるマネジメントの工夫
• 一般的な組織と比較した場合のマネジメントのメリット・デメリット
• 報酬に紐づかない評価の仕組み

概要

エンジニアリングマネージャーには組織貢献のために様々な観点での活動が求められます。その中でもエンジニアがマネージャーになったときに特に困難を感じる取り組みとしてピープルマネジメントが考えられます。これは、多くの人がピープルマネジメントについて初めて明確に職責を負うタイミングがマネージャーへのロールチェンジだからです。

ロールチェンジと同時にメンバーの評価や給与に関する権限が与えられます。メンバーが成果を出し、その過程で学びを得ることで能力の獲得 / 発揮 / 洗練をしていただければ一定の評価をつけることは可能でしょう。では、それを実現するためにマネージャーとして日々の業務の中でどのようにフィードバック（以下FB）をしていけばよいのでしょうか。いざ実践したいと思っても、以下のような疑問や不安を抱える方もいるのではないでしょうか？

• これまで良質なFBを貰ったことがなく、何をどのように伝えればよいのかよくわからない
• 期末のタイミングでしかFBをもらったことがなく、どのように期中に継続してFBすればよいのかわからない
• 我流でFBをしてよいのだろうか

エンジニアの皆さん、定型的な運用作業であれば経験が浅い人でも実行できるような手順書があったらいいなと思いませんか？本セッションでは、FBのプロセスを手順書として整理することで、事業を加速させるマネジメントの強力なツールの1つとしてFBを実践できるようになることを目指します。また、ご自身の現場に合わせて手順書をカスタマイズできるように各手順についてなぜそれが必要なのかのリファレンスを示し、根本的なアイデアの理解の支援に努めます。加えて、セッションの後半では提案する手順で実施したFBの成功事例、失敗事例の振り返りを共有します。

Learning Outcome

対象聴衆

• ピープルマネジメントの責務を負っているエンジニアリングマネージャー
• 育成に責任または関心のあるエンジニア
• フィードバックに関心のある全ての方

得られること

• 定型化されたフィードバックの手順
• 人の学習過程に関する研究事例

話さないこと

• 具体的に何をフィードバックすればよいのか

概要

「なぜ私の評価は低いのだろう？何が足りないのだろう？」と思ったことはありませんか？
もしくは声を聞いたことはありませんか？

多くの企業では、評価制度の不透明さや主観的な評価によってメンバーの揺らぎや不安につながります。
「なぜ彼が評価され、私は評価されないのか？」「私の得意なスキルを活かせていない」と疑問を抱くエンジニアは少なくないでしょう。

納得感を持ってもらい、モチベーションを高いチームを作るために試行錯誤を繰り返しました。
ジョブ型組織とクラウドベンダーである私たちの会社では、これらの問題を解決する新たな評価制度を構築しました。

新たな評価制度の導入により、メンバーが自己のスキルとキャリアパスを意識し、
自己評価と上長評価の差異を確認でき、モチベーションの向上と納得感の醸成につながった事例を紹介します。

Learning Outcome

今回私たちが、皆さんにお伝えしたい内容は、
得意なことを活かしつつ責任感を持たせる新しいジョブ型（コラボ型）を使った組織開発における評価制度です。

約100個からなる可視化された評価基準を用い、自己評価と上司の評価のギャップを数値化することで、
自己投資の方向性や、メンバーが納得感を持った評価制度の仕組みづくりについてお話ししたいと思います。

我々クラウドベンダーのチャレンジをもとに、エンジニアを抱える組織の皆さんにとって、一つのきっかけになれればと思っています。

概要

• これまでスタートアップとしてプロダクトの成長を最優先に開発に取り組んできて事業は成長を続けることができています。その一方でチーム内では「効率化」の名目で属人化や分業化が進み、透明性が失われ課題が意図せず隠され改善しづらく、かつ「楽しい」開発から遠ざかってしまっていました。これを改善するための施策として「イベントストーミング」「BDD」「モブプロ」を組み合わせて取り入れた結果、属人性の低減・チームの自立性向上を実現しより「楽しい」開発ができる土壌を整えることができました。
• 今回は具体的に「何をしたか？」「なぜこの組み合わせがいいのか？」「取り入れるにはどうすれば良いか？」についてお話しします。

Learning Outcome

• 「イベントストーミング」「BDD」「モブプロ」のそれぞれが何か、どんか効果が期待できるかを簡単に知ることができます。
• 「イベントストーミング」「BDD」「モブプロ」を組み合わせることでどのような相乗効果があるか、特に開発チームの自立性を高める点においてこの組み合わせが如何に優れているかを理解することができます。
• これらの組み合わせとビットキーでどのように導入したかの具体的な事例をもとに、ご自身の組織やチームにどのように取り入れることができるか具体的にイメージできるようになります。

概要

Engineering Program Manager（以下EPM）というロールをご存知でしょうか？
EPMとは、ざっくりいうと下記の役割を持ったマネージャーです。

• 開発のリードや開発プロセスの改善
• 設定したリリーススケジュールへの責任とプロダクトのクオリティの担保
• プロジェクト、プロダクトの技術的な阻害要因の排除
• ステークホルダーと適切なコミュニケーションを取り、自身での意思決定や意思決定のエスカレーションの実施

プロダクトのデリバリー、クオリティに責任を持ち、PdMや外部のステークホルダーと開発チームの間に入り、適切に開発のサイクルを回していくために必要な役割です。

EPMはAppleやAmazon、テスラ社などでは正式なロールとして存在しておりますが、まだまだあまり浸透していないロールです。
私が勤めているBASEでは、いくつかの部署でEPMをロールとして採用しており、私自身もEPMを任されています。

本セッションでは前半ではEPMそのものについて説明し、後半では具体例としてBASEのEPMがどんな責務を持っていて、どんな動きや振る舞いをしているかを話します。

Learning Outcome

• 数あるEM像の1つを、具体例とともに言語化できるようになる
• 個人のキャリア / 組織のキャリアラダープランの参考事例の1つになる

概要

エンジニアリングマネージャー（EM）に求められる役割は、技術的な意思決定、組織づくり、ピープルマネジメントなど多岐にわたります。その結果、EMのカレンダーはミーティングで埋め尽くされ、定時内に個人作業を行う時間が確保できないことも珍しくありません。これは長時間労働を誘発し、作業ミスや燃え尽き症候群といった望ましくない状況を引き起こします。しかし、長時間労働に頼らず、効率的に業務を遂行することは可能です。

本セッションでは、アイゼンハワーマトリクスを活用した優先順位づけ、タスクの明確化と適切なデリゲーション、そして定期ミーティングの見直しによる作業時間の創出方法を提案します。これにより、EM自身が健全なワークライフバランスを保ちながら、中長期的視点を見据えたチームワークの最大化を実現することを目指します。

Learning Outcome

• セルフマネジメントが周囲に与える影響への理解
• 効果的なタイムマネジメント手法の習得
• 多忙な中で余白を生み出すための戦略の獲得