トーク

概要

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

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

概要

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

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

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

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

Learning Outcome

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

概要

転職が一般的になりつつある今の時代ですが、「1つのサービスに長年携わることでこそ、システム設計における深い学びが得られる」という意見も増えています。私は飲食予約サービス「Retty」に関わって6年、その間にEMおよびVPoEとして大小さまざまな課題と向き合い、改善を重ねてきました。

本講演では、以下の具体的な事例を通して、各局面でどのような判断や実装を行い、何を学んだか、そして今どのようにその経験を振り返っているかを共有します。

• スクラムと大規模スクラム（LeSS）の導入：アジャイルを拡張して適用する中での成功と失敗
• マイクロサービスアーキテクチャへの移行：モノリシックからの脱却と、その後のシステムの柔軟性向上
• ライブラリやフレームワークの選定プロセス：技術選択の重要性とチームへの影響
• 内製システムのマネージドサービスへの置き換え：効率化とスケーラビリティを実現するための決断

この6年間で積み上げた知見をもとに、長期的な視点でのシステム改善や技術選定、チームマネジメントに関する実践的な学びを紹介します。

Learning Outcome

継続的な改善に関心があるEMや技術リーダー・意思決定者が下記の内容を学ぶことができます。

• 同一サービスへの長期関与で学んだシステム設計と改善の学び
• 技術選定やサービス移行を通じた効率化と成長戦略
• 持続的改善のためのチームマネジメントと意思決定のヒント

概要

Engineering Management に関するグローバルなサーベイである 2024 State of Engineering Management Report 、国内外論文、国内外カンファレンスの概要とトレンドを知れるセッションになります。

Engineering Managementを実践する時のエントリーポイントおよび自分のアウトプット場所の目安にもなります。Engineering Managementの基本用語を知っている前提になるかとおもいますが、全て参照先を明記するようなスライドになりますので、多くの方に見ていただきやすいセッションになるかと思います。

Learning Outcome

• Engineering Managementの国内外のイベントで発表してみようと思える
• 社内の改善に対して客観的に観察できるようになる

参考スライド

• プロダクトマネジメントのグローバルトレンド #pmconf2023

Outline

• 2024 State of Engineering Management Reportの紹介
  • 世界的なトレンド
  • 各トレンドに関連する論文
• Engineering Manager Conference Japan2025のセッションとの比較
• 海外Engineering Managementカンファレンスのセッションとの比較
• Engineering Manager Conference Japan2025と海外カンファレンスの相違

概要

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

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

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

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

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

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

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

概要

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

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

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

Learning Outcome

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

概要

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

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

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

Learning Outcome

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

概要

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

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

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

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

Learning Outcome

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