トーク

概要

筆者は現職に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にとってなぜ信頼を勝ち得ることが大切か知る
• ゼロベースで信頼を獲得する方法を学ぶ

概要

私はエンジニアとデザイナーのマネージャーを約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

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

概要

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

Learning Outcome

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

概要

エンジニアの生産性やモチベーションを低下させる一要素として「割り込みタスク」があります。
割り込みタスクはできる限り避けたいものですが、全く発生しない組織はないでしょう。

エンジニア組織やエンジニアをマネジメントする上で避けては通れないこの問題に対して、
"あなたがメンバーから「割り込みタスクが多くて困ってます」と相談された"
というシチュエーションを仮定して、どのように問題解決するかを話します。

このテーマについて、過去にエンジニア・デザイナーのマネージャーとしてブログ記事を書き、400ブクマをいただきました。
https://naopr.hatenablog.com/entry/2024/08/18/094343

このセッションでは、ブログで紹介した「個人」「チーム」に加えて「組織」観点から解決を試みるアプローチを紹介するほか、
エンジニアに特化したより具体的な対策についても話します。

Learning Outcome

• メンバーから抽象的な相談をされた際にヒアリングを通じて課題を明確化し解決するアプローチ
• エンジニアが受ける割り込みタスク多すぎ問題を解決するための実践的な方法
  • エンジニア個人の問題として解決する方法
  • エンジニアが所属するチームの問題として解決する方法
  • エンジニア組織として解決する方法
  • プロダクト組織全体で解決する方法
  • プロダクト組織以外も巻き込んで解決する方法

概要

某動画配信サービスの某相撲ドラマを見た時に組織のあり方として非常に理想的だなとビビッときました。
組織が一丸となって成長している姿は、相撲に限らず全ての組織に通ずるものがあり、私もあんな組織づくりをしてみたいものだなぁと思いました。

私なりに上記の組織の状態を分析し言語化したものが下記になります。

• 個人それぞれがなりたい姿が明確になっている
• オーナーシップを持って組織を引っ張る存在がいる
• オーナーシップを発揮するのは特定の一人ではなく、状況によって様々な人が発揮する
• オーナーシップのみだけでなく、その周りのフォロワーシップが発揮されている
• それらを発揮するための心理的安全がある

これは、ドラマだから特別だとは全く思いません。
「なりたい姿」、「オーナーシップ」、「フォロワーシップ」、「心理的安全」をキーワードとして、
私の考える理想的な組織づくりである「個人のなりたい姿をチームで支える」を
どのように工夫し奮闘しているかをお話ししたいと考えています。

特に「オーナーシップ」、「フォロワーシップ」、「心理的安全」は人により様々解釈が異なると思いますので、
それぞれをより細分化し、どのような取り組みをしているかをお話ししていきたいです。

Learning Outcome

• 理想の組織像を検討中の方の一助となれば幸いです。
  • 理想の組織像は様々な形があり、こちらは飽くまでも1例としてお聞きいただければと思います。
• 「オーナーシップ」、「フォロワーシップ」、「心理的安全」を細分化しますので、それらにご興味のある方に聞いていただきたいです。
• マネジメント領域の中でも、ピープルマネジメントの色が強いのでそちらにご興味のある方に聞いていただきたいです。

概要

フリー株式会社で EM をしている sentokun と申します。このセッションでは、フリーが行っているメンバー成長・キャリアパスに対するアプローチの実例を元に、「現場」と「組織」それぞれから生まれた活動が合わさり、新たな価値を産み出した話をします。

現場では、「エンジニア波瀾万丈伝」というキャリア共有イベントを通じ、メンバーがなりたい姿を考える支援を行っていました (https://developers.freee.co.jp/entry/eng-haranbanjo) 。
一方、組織課題の専任チームは、多様化しはじめた開発者への期待値を明らかにするため「役割とそのラダーの明文化」に取り組んでいました(https://speakerdeck.com/freee/vpoe-talks-about-the-real-story-of-building-freees-development-organization?slide=26) 。
それらの活動が絡み合い、社内でのキャリアパスの具体的イメージ形成という相乗効果を産み出しました。

セッション内では、これらの活動内容と相乗効果を産んだ経緯を解説し、そこから得た学びを紹介します。

アウトライン

1. 現場から発生した活動「エンジニア波瀾万丈伝」
   • 活動内容
   • きっかけ
   • 広がり
2. 組織から発生した活動「役割とそのラダーの明文化」
   • 組織課題
   • 解決のアプローチ
   • 役割の明文化とその狙い
3. 相乗効果
   • 活動を進めて見えてきた価値
   • 更なる進化
4. 学びとまとめ
   • 効果に繋がった要因を紹介

Learning Outcome

• 現場と組織課題から発生した活動のコラボレーション例が知れる
  • 結果、以下の方が学びを得られる
  • 自チームが行っている改善の取り組みを組織に広げたい方
  • 他チームが行っている改善の取り組みとコラボレーションしたい方
  • 活動を広げるのっておもろいよね！という方
• 実例内容を通して、メンバー成長・キャリアパスに対するアプローチを知れる
  • 結果、以下の方が学びを得られる
  • メンバー成長・キャリアパスについて悩んでいる方

概要

本セッションでは、急速にスケールするチームが直面する多様な課題を解決し、持続可能な開発体制と高いモチベーションを維持するために、Less (Large-Scale Scrum) を応用した「機能別のチーム編成」と、それに合わせた「エンジニアのロール分担」について詳しく解説します。

チームや組織がスケールする過程では、オーナーシップの欠如、協力体制の崩壊、個人プロジェクト化、プラットフォーム間の断絶といった複雑に絡み合った問題が顕在化します。これらの課題を解消するため、メンバーとの対話を通じて各エンジニアの適性を見極め、「機能開発」と「技術課題の改善」に特化したチームを再編成します。また、リーダーシップを発揮できる開発者には、プロダクトリード（PL）、テックリード（TL）、および個別貢献者（IC）など、明確なロールを背負ってもらうことで、プロダクト開発と技術課題の検証に集中できる環境を整えます。

このアプローチにより、チームのスケールを契機に、パフォーマンスの最適化・加速、モチベーションの向上、そしてチームの一体感を徐々に取り戻すことができました。

本セッションでは、具体的な施策とその効果について実際の事例を交えながら紹介し、参加者が自身のチームに応用できる実践的な知見を共有します。

Learning Outcome

• 中規模チームにおける、持続可能な開発環境の構築:
  • 機能別チームとロール分担を導入し、開発効率を最大化しつつ、メンバーが疲弊せずに持続的に成果を上げていく具体的な事例を共有します。
• チーム間コラボレーションの設計見直しによる生産性の向上:
  • 具体的ないくつかのプロセス改善を通じて、チーム間のコミュニケーションコストを最適化し、機能横断などで生産性を向上させる具体策をお話しします。
• 開発者の役割と評価基準の最適化:
  • 対話を通じ、適正に合わせた役割設定と評価方法を明確にし、成長を支援するアプローチをお話します。

対象

• チームのスケーリングに伴う課題解決、メンバーのモチベーション向上に取り組むリーダー層

概要

エンジニアリングマネージャー（EM）は、チームの成長と成功を導くために、技術的な知識だけでなく、ピープルマネジメント、プロジェクトマネジメント、チームビルディングなど、多岐にわたるスキルが求められます。

しかし、これらのスキルは実務経験の積み重ねに依存しがちで、その向上には時間がかかり、即効性に欠けるという課題があります。

この課題に対して、私たちは社内でEM向けの勉強会を立ち上げ、スキル向上を図る新たな取り組みを始めました。

本セッションでは、勉強会の始め方、進め方、工夫、無理なく継続する方法を詳しく紹介します。
この勉強会の特徴は、単なる座学ではなく、自分たちの経験を共有し合うことで、マネジャーが自分自身の経験の意味を理解する手助けをおこなうスタイルを採用しています。
具体的には、目標設定の悩みやメンバー評価の難しさ、プロジェクトマネジメントでの成功例や失敗談を持ち寄り、「みんなはどう感じたか？」「今の組織ではどうしたら良いか？」と互いに意見を交換します。これにより、各自が自分の経験を客観的に捉え、新たな視点や解決策を見出すことができました。

また、勉強会で得られた知見や成果を社内の他部門へどのように還元したかについてもお話しします。

Learning Outcome

対象の聴衆：

• EMとしてスキル向上に課題を感じている方
• EM育成のための具体的な施策を探している方

得られるもの：

• 実務経験以外でEMスキルを向上させる具体的な方法
• 無理なく継続できる社内勉強会の設計・運用ノウハウ
• EM育成の取り組みを組織全体に還元する方法

概要

これまで私は様々なEMのイベントに参加してきましたが、そこで参加者の方と立ち話をしていると
「1on1のやり方に困っている」
「1on1で話す話題がない」
「1on1は1ヶ月に1度しかできていないが良くないと思っている」
など1on1に関する悩みが多くあることに気づきました。

また、私自身もかつてマネジメントラインのメンバーとの1on1の際に
「今日話したい内容はありますか？」
とよく聞いていたのですが、ほぼ毎回のように
「今日は...特にないですね...」
という回答で困っていた経験があります。

このような状態から私なりに改善を重ね現在では上記のような悩みがなくなり、毎週30分の1on1を話題に困ることなく実施できています。

その結果、私の1on1のやり方が社内でも取り上げられ、他のマネージャー陣の参考にもなるようになりました。

このセッションでは私が具体的に行なっている1on1に関して、
・1on1の目的
・1on1に向けた準備
・効果的な1on1のやり方
・1on1で扱うべき話題
など"今日から使える"をコンセプトに話していきます。

Learning Outcome

聴衆の皆さんは、この講演を通じて以下のようなことを学ぶことができます。
・トークテーマに困らない効果的な1on1のやり方
・"Growth - 組織形成と成長 -"のための1on1のやり方
・メンバーによって1on1はカスタマイズしていく必要があるということ
・傾聴だけではなく、マネージャーも自身も話す必要があるということ
・1on1で話すべき話題の具体的な例

概要

チーム内に各分野のスペシャリストを抱え、業務を進めるうえで
・スペシャリストの業務内容を把握できない
・スペシャリストが思ったような成果物を作成できない
・スペシャリストが周囲の技術レベルを引き上げられない
などの壁にぶつかることがあるかもしれません。

単純にスペシャリストとしてのスキルが不足している、
または、活躍できる土壌が組織の中で整っていないなどの可能性もありますが、
総じてエンジニアリングマネージャが貢献できる領域といえそうです。

今回、viviONが定義するスペシャリスト像とともに、
マネジメントとの役割分担や、活躍しやすい環境の構築について、
スペシャリストの成熟度に合わせたアプローチの中で
効果があった事例を紹介させてもらえればと思います。

Learning Outcome

新しくスペシャリストの職位を設定したい、採用を進めたい、
または、スペシャリストの働き方に違和感を抱えるエンジニアリングマネージャの方を対象に、
スペシャリストとの関わり方の一例を知ることで
アウトプットの最大化に役立てていただければと思います。

概要

多くのテック企業において、プロダクト開発の生産性を底上げするべく、社内開発基盤を支えるプラットフォームチームを組成することがあります。
この社内プラットフォームは黎明期を乗り越えて、社内の開発者という顧客を獲得して盤石になった時、場合によっては方向性に迷うことがあると思います。
安定顧客が存在することによる慢心の発生、プロダクト開発チームとの距離による情報流通量の低下、守りに走りすぎて開発組織のボトルネックになるなどです。

医療系スタートアップ Ubie のデータプラットフォームは 2024 年の夏頃、まさにこの手合いの課題に直面していました。
技術的には理にかなっているものの、利用者にとって取り掛かりにくく生産性が低下してしまう。しかしデータ分析をする上で使うことが必須で避けられない。利用者がその状態に耐えて利用し続けてしまうと、それが組織を取り巻く変えられない制約として根づいてしまう。
この状況を打破すべく、 Ubie データプラットフォームチームでは社内ユーザのヒアリングや課題の収集、今までに無かったリスクテイク可能にする機構の導入など様々な施策を回すことで、利用時に必要な作業の一部リードタイムを 1/8 に短縮、ヘビーユーザからのポジティブな反応を獲得するに至りました。

本セッションではこの Ubie データプラットフォームチームで行った生産性改善プロジェクトのマネジメントと、より一般化した社内プラットフォームのマネジメントの考え方について紹介します。

Learning Outcome

• 社内プラットフォームチームが黎明期を超えた先で陥る可能性がある課題と解決策の一例の把握
• 社内プラットフォームチームのマネジメントの困難と緩和策の一例の理解

概要

ミドルステージのスタートアップが、どのようにグローバルチームを構築して組織拡大にトライしていったかと、段階的に発生する課題とアプローチを紹介します。
進出国の選定の考え方、日本との採用方法違い、リモートワーク体制、コミュニケーション設計、文化の醸成などを具体的な事例を用いて紹介します。

Learning Outcome

• グローバルチーム構築の具体的なステップを理解
• 各段階で必要なリソースと準備を把握

概要

事業会社(自社プロダクト企業)で1年間「プロジェクトG」の開発リードとして走った実体験から抽出した、エンジニアリングマネジメントの哲学を共有します。

急造チーム・タイトスケジュール・仕様ふわふわ というある種お約束の属性で始まった「プロジェクトG」。
EM(Engineering Manager)という名前を与えられていたわけでもなければ、自分でそれを意識していたわけでもありませんでしたが、
振り返ってみれば、私が取り組んだことは一種の「エンジニアリングマネジメント」だった と言えるだろうと感じています。
良かったこと・悪かったこと・今後挑戦したいことなどを交えながら、ご参加の皆様と共にEMのミッションやバリューに目を向けていく２０分です。

Learning Outcome

• 対象の聴衆
  →EMを目指す者
  →EMとなったが、どうバリューを発揮すべきか、迷いを抱える者

• その人たちが得られるもの
  既知でないケースで得られた観点からの哲学を「触媒」とし、
  EMが持つミッションや解き放つべきバリューへの気づきを手にすることで
  事業(プロダクト)や組織の成長へのコミットを「増幅」させる道筋を得る