「もっと事業目線をもって」
フィードバックでこのようなことを言われたことがあるEMの方、いらっしゃるのではないでしょうか?
私自身も、過去にCTOを務めていた際に強く言われたことがあり、悔しさと同時に "事業目線とは何か" を考えるきっかけになりました。

多くの方に言われているように、
"マネジメント" は、(めちゃくちゃ平たく言うと)「事業を成功に導くための営み」です。
つまり "エンジニアリングマネジメント" とは、
「事業の成功のために、どのようにエンジニアリングするか」を考える営みと言い換えることができます。

と言うことは、やはりEMにとって、"事業を知り、事業目線を持つ" と言うことが必要不可欠ですが、
事業目線とは何か、事業目線の持ち方、と言うのは誰も教えてくれません。たぶん。

私自身も、
共同創業の小さなスタートアップ、IPOにつながるような急成長スタートアップやレイターステージスタートアップなど、
3社のCTOを経験した上で今は自社で事業づくりをしていますが、もともと "事業目線" があったわけではありません。
様々な経験を通じて徐々に獲得されてきた後発的な能力だと感じています。

このセッションでは、
「自分は、どうやって事業目線を獲得していったのか？」
「何ができるようになり、どんな失敗を経て今に至るのか？」

という自分自身の経験をもとに、

• 曖昧な「事業目線」の正体
• EMとしての事業との向き合い方・踏み込み方
• 明日から使える (使えそう) な、考え方・アクションプラン
  などを共有します。

Learning Outcome:

• “事業目線” という曖昧な言葉の正体を理解できる
• EMとしてどこまで事業に踏み込むべきかがわかる
• 今の自分の状況に合わせて、事業理解を深める具体的アクションが持ち帰れる

「もっと事業目線を持って」と言われたことがある EM の方、あるいは「自分はまだ事業に弱いな…」と感じている方が、
明日からもう一歩ビジネスに踏み込むためのヒントを持ち帰れるセッションにしたいと思います!

概要

「自律自走型組織」は理想ですが、単に自由を与えるだけの「甘い自走」は、責任の不明確さや意思決定の停滞といった構造的な問題を引き起こし、最終的にチームの生産性を低下させ、事業の足を引っ張ります。
私自身、この「甘い自走」の失敗により、組織の士気と成果が著しく悪化する危機を経験しました。
その経験から得た最大の教訓は、「自律とは自由ではなく、EMが設計する明確な枠組みと責任がセットで存在して初めて成立する」という真実です。

今回は、この「甘い自走」を捨て、自律型組織を再構築するために組織に導入した独自のマネジメントポリシーをお話しします。
様々な試行錯誤の上での取り組みがもたらした、市場投入速度の向上や開発コスト削減といった具体的な事業成果、そして現場での実践方法を、痛みを伴う失敗例を交えてお話しします。

アジェンダ

1. 「甘い自走」が招いた失敗
   1. 自律型組織における課題と失敗事例（現状確認と課題の分析）
2. 自律型組織の再定義
   1. 自律型組織の課題解決に向けた新たな枠組み（新しい方針や枠組みの共有）
3. 自律型組織を実現する戦略
   1. 成功に導くための具体的アプローチ（具体的な実行計画）
4. 成果
   1. 目指す成果と期待される未来像（期待される成果の明確化と共有）

Learning Outcome

対象の聴衆

• 自律型組織を構築したい、しているエンジニアリングマネージャー（EM）。
• 組織構築に課題を感じているリーダー層。
• チームや組織への関与を強めて事業貢献に繋げたいと考えているプロジェクトマネージャー。

聴衆が得られるもの

• 自律型組織の本質を理解する
  • 「自律」とは単なる自由ではなく、組織の仕組みと責任設計であること
• 独自の戦略的プロトコル
  • 自律を駆動させるための実践的なマネジメントポリシー
• 事業価値への接続
  • 変革が開発リードタイムの短縮や技術的負債解消、開発生産性向上といった具体的な事業成果

概要

開発者体験(DevEx)の改善は、組織の生産性向上に直結する重要な取り組みです。
しかし、現場の声を拾うボトムアップだけでも、経営層からのトップダウンだけでも、持続しません。
本セッションでは、DX(getDX)を活用した四半期ごとのSurvey（参加率ほぼ100%）を基盤に、エンジニア組織全体で取り組む改善サイクルの構築に挑戦している実践例を紹介します。

• 参加率ほぼ100%の重要性: 一部のエンジニアだけでなく、組織全体を巻き込むことで、改善プロセスを定着させ、文化として根付かせる
• 現場からの改善: IC→EMによるチームレベルでの課題特定と改善（一部チームでDeep Workスコア+12〜+13ポイント改善）
• マネジメント層による構造改革: VPoE→Dir/MoM→EMによる組織横断的な構造的課題への対応

一部で成功事例は生まれたものの、全社としての改善はまだ道半ば。
「改善サイクルの定着」と「文化づくり」にフォーカスし、持続的な生産性向上につなげることを目指しています。
データ、成功事例、失敗談、そして試行錯誤の生の姿を率直に共有します。

Learning Outcome

対象:

• DevEx改善を通じた生産性向上に取り組みたい方
• 現場とマネジメント層の連携に悩む方
• 改善サイクルを組織の文化として定着させたい方
• データドリブンな生産性向上の仕組みづくりに関心のある方

得られるもの:

• 組織全体を巻き込むDX改善: ほぼ100%参加率を実現する仕組みづくり
• 現場とマネジメント層の連携設計: 現場からの改善（IC→EM→Org）とマネジメント層の構造改革（VPoE→Dir/MoM→EM）を連携させる仕組み
• 生産性向上への道筋: DevEx改善が生産性向上にどうつながるか
• 改善事例: 一部チームでの改善事例と、その成功要因、構造的課題への向き合い方
• 横展開の難しさ: 成功パターンが他チームに広がらない理由と、その対処への挑戦
• 文化づくりの実践: 一時的な取り組みで終わらせず、持続的な生産性向上につながる改善サイクルの定着アプローチ
• 現在進行形の課題: 全社展開への道半ばの状況と、今後の挑戦

◾️Summary
本トークでは、私がグローバルチームをリードするうえで大切にしてきた視点と、そのプロセスを取りまとめ、
「グローバルを前提としたチームをどのように導き、組織としてのアウトプットをどのように高めていったのか」というテーマを中心にお話しします。
扱うのは特定の理論ではなく、チームの思考や対話の流れが整い、理解と協働が累積していくような“組織の下層構造”をどのように形づくるかという視点です。
リードとしてその流れを支え、チームで育てていったかを共有したいと思っています。

◾️Why
<なぜこのトークを行いたいと思ったか>
グローバルチームを率いるというと、特別な経験や高度なスキルが必要だと捉えられがちです。
しかし私自身、留学や英語圏で在住する経験が特にないですが、グローバルチームのリードを担っています。
実際にチームと向き合う中で強く感じたのは、チームが力を発揮する鍵は、“語学力”や“海外での過ごし方”よりも、組織としての理解と関係性の土台を整えていくことにあるという点でした。
土台が整っていけば、多様なメンバーは自然と協働し、チームとしての動きが育っていきます。これは特定の経歴や能力に依存するものではなく、誰にとっても再現可能な導き方だと感じています。
だからこそ、留学経験がなくても、英語が得意でない方、社会に出てから興味を持ち始めた人でも、グローバルな環境を率いることは十分に可能であるということを伝えたいと思いました。
多様なメンバーと向き合いながらチームを導く人、これからその一歩を踏み出そうとする方に向けて、私が実際に行ってきたリードの視点を共有したいと考えています。

◾️Learning Outcome
<このプロポーザルを聴いてほしい方>
・海外経験があってもなくても、グローバルや多文化チームを率いたい人
・言語・文化の違いでチームの足並みが揃わず困っているEM / リード
・“自走するチーム”の作り方を抽象原則として学びたい人

<得られるもの>
・「経験の差」ではなく「構造」でチームは変わるという視点
・非同期 × 多拠点でも機能するコミュニケーション
・チームが自ら学び、挑戦し、成長し続けるための“越境デザイン”の考え方
・個人の行動をチーム文化へ広げるための、定着・巻き込みのアプローチ

私は物事を前に進める上で、 "提案のレベル" を強く意識しています。
ref: https://speakerdeck.com/konifar/ti-an-noreberuwoshang-geru-number-qiitaconference

メンバーからマネージャーに役割が変わると自分が思い描く動き方ができず、まるで "提案のレベル" がリセットされてしまったように感じるかもしれません。
実際には、これまで培ってきた "提案のレベル" 自体はリセットされたわけではありません。マネージャーとしてのレベルをまた上げていけばよいのです。

このトークでは、自分自身が2021年に VP of Engineering を担って「提案レベル0で全然物事をよくできていない...」と思い悩んだところから4年ほど試行錯誤してきた経験から、マネージャー版の "提案のレベル" の上げ方を話していきます。

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

• 責務の定義と越境のバランス
• マネージャーが知っておくべきPLと予算、投資の考え方
• 経営や他チームへの "提案のレベル" を上げる具体例
• 経営やプロダクト、他部署に根っこの課題があると感じた時にどう動かしていくか

Learning Outcome

• マネージャーとしてプロダクトや組織をよくする提案ができていないと感じる人に、N=1の体験談と具体的な引き出しを提供します
• 経営との接続に課題を感じている人に、具体的なコミュニケーション方法を提供します

概要

組織の成長は、メンバー一人ひとりが「ストレッチゾーン」で挑戦し続けることで生まれます。これは多くのマネジメント理論や、目標管理手法の代表格であるOKRでも示されている考え方です。

一方、「ストレッチゾーンに挑戦し続ける」ことには、様々な難しさが伴います。
例えば、メンバーに「成果を出してほしい」「チームをリードしてほしい」と期待を伝えても、本人がそれを適切な目標として設定できずに悩む、といったことはないでしょうか。
また、わかりやすく「ストレッチ」な技術的難易度や規模のプロジェクトが常に存在するとも限りません。多くの時間は、ユーザーから見えない部分も含めた地味なプロダクトの改善の積み重ねです。

Sansanの300人を超えるエンジニア部門の中で、私はモバイルエンジニア部署のミドルマネージャーとしてこのような難しさに向き合ってきました。
上記に加え、モバイルアプリエンジニアは技術スタックや役割が限定されがちな事などから、キャリアの「ストレッチ」が難しいという構造的な課題を抱えていました。
その結果、シニア層の離職が続く時期もありました。

このような状況下でシステム思考の実践や1on1、チームトポロジーの実装などの試行錯誤を重ね、自部署のエンジニアが『ストレッチゾーン』のチャレンジに挑み続けられるような環境に近づけていきました。
この取り組みの後押しもあってか、メンバーのエンゲージメントが向上し、最終的に離職率を半減させることができました。

ストレッチな取り組みを日常に織り込み、継続できるような取り組みを戦略的に行うことは、メンバーや組織の成長には必要不可欠です。
本セッションでは、私がEMとしてこの問題に取り組んだ経験をもとに、「挑戦が続く組織」をつくるための考え方や知見をお話しします。

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

対象の聴衆

• 停滞期に入っているメンバーや組織を抱えているEMの方
• EMロールにトライして間もない方
• ミドルマネージャーの難しさを感じている方
• EM以外のICやその他ロールで、停滞感を抱えている方

その人たちが得られるもの

• 日々の業務をストレッチゾーンに変え、成果を出すための考え方と実例
• キャリア形成を支援する方法

人が増えただけでは組織の生産性は最大化できない。
私が所属する会社では、事業拡大に向けて採用を強化し、開発チームの人数は2倍に増えました。並列で施策を回せるようになった一方、人が増えることによる新たな問題に直面し、「アウトプットは増えたけど、その分コストも増大しスピード感に欠ける」という現象が起きました。

人が増えることによる問題には様々あります。
たとえば、「昔はみんな知っていた」暗黙知的な運用ノウハウが通用しなくなって予防できたはずの障害が起きたり、「きっと他の人がやってくれるはず」とお見合い状態が続くことで問題が大きくなる前に対処できなかったり、少人数で始めたMTGに全員が参加し続けることでMTGコストが跳ね上がったり——。人の増加に組織が追いつかないことで、生産性が思ったよりも上がらない状況に陥っていました。

この課題を解決するために、私たちは“委員会制度”という分権型の組織運営モデルにチャレンジしました。
品質向上・AI活用・チーム連携・技術広報といった特定テーマごとに、3〜5人で構成される小さな委員会を設け、委員長に大きな裁量と責任を委譲しました。責任範囲と権限をしっかり決めることにより、スピード感を持って問題解決を図れる体制にシフトチェンジしました。

このトークでは、この1年間の取り組みで得られた分権型の組織運営の学びを共有します。

トークの流れ

• 人が増えたことで起きた課題
• EM陣で考案した「委員会制度」の設計と狙い
• 制度をうまく機能させるための仕掛け
• 精度の導入後に得られた成果
  • 自発的な達成文化の定着
  • 次世代リーダー人材の育成
• 学びと今後の展望

Learning Outcome

• スーパーマンからの脱却方法
  • スタートアップ初期にありがちな「なんでも屋」依存から抜け出し、全員が成果にコミットするチームを作る実践的なステップ
• 次世代リーダーの育成方法
  • 主体性や責任感が強くリーダーシップを持った人材を育成するための環境の整備方法
• 権限委譲の進め方
  • 委譲された人が迷わず意思決定でき、かつ必要なときに相談をもらえるように設計した仕組みとプロセス
• 機能開発と保守運用の両立方法
  • 責任の所在を明確にしスピードと安定性を両立させるための分権型チーム運営の実例

■ 概要:
「システム改修に半年かかります」「影響調査に1ヶ月ください」
前職でEMだった私は、あらゆる技術的負債が受肉したような保守コストの高いスパゲティと、品質を顧みる余裕すらない組織構造の壁に直面していました。
内部品質の重要性を説き、新しい開発プロセスの試行を提案しても、日々の運用に疲弊するメンバには響かず、構造的な組織課題を前にEMとして無力感を味わいました。

「事業会社のシステム保守開発を楽にしたい」
その強い課題意識から私はあえてEM職を離れ、モダナイゼーションの現場に飛び込みました。
そこで得たのは、アーキテクトとしての実践知（システムと組織の構造的関連性や、モデリングによる共通理解の形成）と、専門職大学院での学びによって得られた経営戦略的な視座（情報社会学や管理会計 ）でした。
技術的な「構造化思考」と、組織や経営を多角的に分析する「視座」。これらを武器に、私は再びEM（グループ長）として、まさに前職の課題そのものであった「基幹システムの保守開発部門」のモダナイゼーションに取り組んでいます。

本セッションでは、一度EMを挫折した私が、アーキテクトとして得た学びをいかに増幅させ、それを触媒としてレガシーな組織とシステムの変革に活かそうとしているのか。その現在進行形の実践と葛藤を共有します。

■ Learning Outcome（対象の聴衆 / 得られるもの）:
対象の聴衆:

• レガシーシステムや保守開発チームのマネジメントに課題を感じているEM
• 組織構造の壁により、技術的改善が進まないと感じているリーダー
• 専門職とマネジメントのキャリアパスに悩むシニアエンジニア

得られるもの:

• 「構造化思考」をEM業務（特に組織変革）に活かす具体的なヒント
• チームやステークホルダーとの共通理解を形成する実践的アプローチ
• 「EM → 専門職 → EM」というキャリアの往復から得られる学びと、それを次の挑戦に繋げる視点
• エンジニアリングの隣接領域への越境学習がEMとしての「引き出し」を増やす実例

入社後しばらくして、所属していたチームにてPdMと主力エンジニアが短期間で離れる出来事が続き、経験の浅いメンバー中心の体制になっていました。扱っているドメインもコードも難易度が高く、「チームを安定させること」が最初の課題でした。私は外圧を整理し、やることを絞り、問い合わせ対応も含めて一緒に状況を確認しながら進めるなど、「守る」ことに振り切りました。その結果少しずつ不安は減り、チームは安定し、連携も強くなっていきました。
その後、短期での成果が必須となる新規プロダクトを担当することになりました。期限は動かず、不確実性も高い。このタイミングで初めて、「このまま守り中心のままでは事業の期待に間に合わない」と自覚しました。判断が遅れるほどリスクが増える状況だったため、技術判断や優先度判断を自分が一時的に引き受け、プロセスも短いサイクルのカンバン運用へ切り替えました。これはプレイングに戻るというより、プロジェクト全体の不確実性を下げ、チームが動きやすい環境をつくるための“介入”でした。
結果としてプロジェクトは期限に間に合い、チームも状況を理解したうえで前に進むことができました。この経験から、「守る／推進」はどちらが正しいかを選ぶ話ではなく、状況に応じて切り替えるモードだと捉えるようになりました。事業とチームの両方を見て意思決定する視点が、自分にとって大きな転換点になりました。本セッションでは、このモード切替の背景と判断基準、実際に行った介入のプロセスを共有します。

■Structure of the Talk
守りに振り切らざるを得なかった背景と当時のチーム状況
守りフェーズで実際に行ったこと（外圧整理、モブプロ、対話など）
異動した先は「短期成果が必須な新規プロジェクト」
EMが一時的に介入すると判断した理由と、判断のオーナーシップを持つ動き方
スクラムの形式にこだわらず、短サイクルのカンバンに切り替えたプロセス設計
結果として何が起きたかと、「守る／推進」はモード切替だと捉え直した学び

■Learning Outcomes
「守るだけ」のマネジメントがどこで限界にぶつかるかを理解できる
守り／推進を切り替えるべき局面を見極めるための判断基準を学べる
事業とチームの両方を見ながら、EMがどう介入すべきかの具体的なイメージを持ち帰れる

概要

成長企業で「役割の重複・衝突」「特定人物への属人化」「突発的な離職による組織の機能不全」といった、組織のレジリエンスを脅かす課題は避けられません。
特に兼務の多いEMは、限られた工数の中でこれらの構造的な課題に立ち向かう必要があります。

私は複数領域（SRE・情シス・セキュリティ）のEM、グループ会社の執行役員、技術広報を兼任してきました。
この「マルチロールEM」という制約の中で、多様な経験知を活かし、外部環境の変化や予期せぬトラブルにも耐えうる「持続可能で変化に強い組織」を構築するために仕組み化したマネジメント戦略を紹介します。

本セッションでは、実際に私が取り組み、レジリエンス向上に寄与した以下の施策を、成功事例とそこに至るまでの失敗事例・教訓を交えて体系的に解説します。

■成功事例
・Beyond Borderを可能にするWillを活かした人材配置とミッション設定
・組織の公平性と納得感を高める多角的な評価基準の導入
・事業成長フェーズに応じた、組織構造の軽量化と負債化しない権限移譲

■失敗事例
・Willと業務のミスマッチによるエンゲージメントの低下 → 組織構造・ミッションの再設計と評価基準の見直し
・自分がボトルネックとなり、意思決定のスピード低下 → 「やること」「やらないこと」の決断
・早期権限移譲による組織の歪み / ハレーションの発生 → 段階的な権限移譲実施と権限移譲判断チェックリスト化

このセッションは、自社組織の構造的な課題を解決し、明日から使える具体的な示唆を得たい現役EM・リーダー層を対象とします。

対象の聴衆

・工数不足や組織の属人化、構造的な課題に現在進行系で悩んでいる現役EM
・組織のレジリエンスを高め、組織をスケールさせるための具体的な仕組み化のヒントがほしい方。
・他社の「失敗事例とそこからのリカバリー」を学び、自社の「転ばぬ先の杖」としたい方。

得られる学び

・ロール横断型人材配置の具体設計（SRE↔セキュリティのコラボレーションを実現したステップ）
・納得感の高い多角的評価システムの構築方法（他部門EMとの評価会議設計）
・権限移譲の判断チェックリストと早すぎた移譲の失敗からの学び

◼︎ 発表概要
EM（エンジニアリングマネージャー）は、経営陣と現場メンバーの中間に位置し、双方の視点を理解し繋ぐことで、会社全体の利益を最大化する重要な役割を担っています。
しかし、多くの現場で「開発生産性（Four Keysなど）は改善しているが、それがどう事業利益に貢献しているのか」を経営陣に説明することに難しさを感じています。
現場のプロセス改善や日々の活動が、具体的にどう経営貢献に繋がるのか、その接続を説明することは難しいです。

本セッションでは、この経営と現場の断絶を繋ぐ鍵として、「事業生産性」という考え方を紹介します。
私たちはこの「事業生産性」を、企業の本質的な「稼ぐ力」を示す経営指標 ROIC（投下資本利益率）とほぼ同義であると定義しています。
本セッションでは、ROICの構造を「分子（税引後営業利益）」と「分母（投下資本）」に分解し、その上で、Four Keys（d/d/d）の改善、AI活用の推進、資産性開発の管理といった現場の具体的なエンジニアリング活動が、ROICの分子（利益向上・コスト削減）と分母（投下資本の最適化）のどこにインパクトを与えるのかを徹底的に紐解きます。
さらに、この「事業生産性」の視点を開発組織全体に浸透させ、組織全体で事業に効く機能開発を行えるようにするための具体的な取り組みを、ワンキャリアの実例を交えて解説します。

◼︎ 想定リスナー
・ Four Keys（d/d/d）などの開発生産性メトリクスは追っているが、事業貢献度の説明に課題を感じているEM
・ 経営層や事業責任者と、開発投資のROI（投資対効果）について共通言語で議論したいEM
・ 財務諸表（PL/BS）の数字を、自身の技術戦略やチームの目標にどう結びつけるか悩んでいる方
・ AIなどの先端技術活用を、コスト削減や資産価値の観点から戦略的に推進したいマネージャー

◼︎ Learning Outcome (得られる学び)
・ ワンキャリアの実例から、エンジニアリング組織全体で「事業生産性」を意識し、開発投資の質を高めるための具体的なヒントを得る。
・ 日々の開発活動（機能開発、プロセス改善、AI活用）が、経営にどう影響するかを説明できるようになる。

GENDAは「2040年世界一のエンタメ企業に」をVisionに掲げ、積極的なM＆Aを成長戦略の柱としており、2023年7月の上場以降、累計で約40件のM&Aを実施しています。その裏側では、グループイン後の企業統合（PMI）を担える人材が継続的に求められています。しかしPMIは、技術・事業・組織文化が複雑に絡むため属人化しやすい領域です。そこで私は、グループ企業であるカラオケ事業に出向してテクノロジーを中心としたPMIの現場で得た経験をもとに、若手エンジニアをテクノロジーPMI人材へ育てるための再現性ある育成モデルを設計しています。
中心となるのは4つの実践です。第一に、重要会議への早期同席です。グループインした企業の経営会議、技術・DXロードマップ策定、各種ベンダー商談など、通常は若手が関わらない場を開放し、会議の目的共有・議事録作成・事後振り返りをセットで行うことで、意思決定の基準や背景を深く理解してもらいます。
第二に、小規模な組織から始める人員マネジメントです。小規模なプロジェクトのリードを担ってもらうことで、チームのマネジメントや計画・調整・レビューを体験してもらい、「他者と共同して最大限のアウトプットを出す力」を段階的に身につけてもらいます。
第三に、日常の対話を通した組織力学の実地学習です。PMIでは、キーマンの影響力や文化摩擦といった“組織の本音”が結果を左右します。業務外の日々のコミニュケーションにも同席してもらい、会議では見えない統合の本質をWetなコミュニケーションを通して経験してもらいます。
第四に、1on1による継続的な言語化と抽象化です。現場で得た経験を定期的に振り返り、学びを自分の言葉で整理し、次の行動に繋げることで、経験を再現可能な知識へ変換する習慣を育てます。
これらを組み合わせることで、GENDAにジョインしてすぐの段階から技術・事業・組織を横断し、PMIの推進ができるテクノロジー人材となることを目指します。

Learning Outcome

対象となる聴衆

• CTO/VPoE
• 若手育成に携わるマネージャー

このトークから得られる学び

• 属人的になりがちなPMIスキルを再現性ある育成プロセスに転換する方法
• 若手への打席設計
• テクノロジーを強みに事業の中心へ入り込むための伴走アプローチ

「このタスク、自分でやった方が早い」そう思いながらも、メンバーに任せられず抱え込んでしまう。あるいは「この組織課題、誰がいつ解決するんだ?」と思いながら、上にも横にも動かせず立ち往生する。

EMとして、こんな経験はありませんか？

自チームにおける、開発生産性をいかに最大化するか、ロードマップの遂行、メンバーの成長育成、多職種との連携改善。
開発組織全体での、開発組織の体制整備、プロダクトと事業計画のアライン、開発予算の策定、採用計画から評価制度の継続的改善。

EMとして向き合う課題は多く、組織をスケールさせていくためには、権限移譲が不可欠です。

より大きな組織課題を解決しようとすると、VPoEやCTOといった経営層が持つ責務範囲を剥がさないといけない時もあります。一方で、そうした課題を持とうとするほど、自分自身の責務も誰かへ渡していかないといけません。

このセッションでは、組織課題を推進していくための、1人のEMとしての権限移譲の「する側」と「される側」への向き合い方についてお話します。

具体的には、現職でEM全体での組織課題の洗い出しと委員会制度の構築を通じて、採用・広報・評価制度などの改善を加速させた事例をご紹介します。
各委員会はVPoE/CTOと連携しながら、経営層が持つ責任領域の一部を引き取る仕組みです。

一方、より大きな組織課題に取り組むほど自分のキャパシティは限界を迎えます。
そこで自チームでは、OKRベースの目標設定とミッション展開、様々なフレームワークを用いた責務範囲の明確化や意思決定フローの統一を図り、「自己組織化」に取り組んできました。

権限移譲のする側・される側の両面から、EMとして組織を動かすアプローチをお話しします。

Learning Outcome

対象聴衆：

• 自分のキャパシティが限界に達しているEM
• 組織課題に手を出したいが、どう動けばいいか分からないEM

このセッションで得られるもの：

• 経営層から権限を引き出すための、委員会制度などの具体的な仕組みと交渉方法
• 自チーム内で権限移譲を進める際の、期待値の伝え方と可視化、段階的な任せ方のコツ

概要

• 事業活動とエンジニアリングは年々強く関連するようになってきており、エンジニアリングの目的はプロダクトやサービスの開発を通じて事業目標の達成に寄与すること
• 事業目標の達成は経営の目標でもある。経営がやりたいことをどのように理解するか、それをエンジニアリング課題に如何に接続するかがエンジニアリング戦略の根幹となる
• が、実際にP/Lなどの経営指標を見ても、そこからエンジニアリング活動にどのように結びつけるのがいいかイメージするのが難しいEMは多いと思われる（自分もそう）
• そこで本セッションでは、経営の基本は財務・会計であることを念頭に、財務会計 → 事業戦略 → プロダクト戦略/技術戦略の流れを理解し、実際の活動に落とし込むにはどうすればいいか、そのフレームを提案する
• また、実際に社内の経営数値を集めてどのように可視化し、技術戦略を考える際に活用しているかの実践知を提供する

想定リスナー

• 事業や経営の近くで戦略を描く必要があるEM/技術統括
• 事業戦略を理解しながらマネジメントをすることに興味がある人

Learning Outcome

• 財務会計の基本的な考え方を念頭におき、技術戦略の考え方との接続方法を考える枠組みを提供する
  • 特にP/L、C/Fのパターンから経営状況の概況を読み解き、そこからエンジニアリング戦略を考える糸口を見つける
• 実際に経営に携わるようになってから、どのように経営・会計を理解し、エンジニアリング戦略に結びつけていったのかの流れを提供する
  • 獲得できる数値情報だけでなく、事業責任者との対話、商談同行などを行い、経営と事業の解像度を上げ、会計情報とマッピングしていった流れについて追体験
  • 半年かけて理解した内容と、その時の経営・事業課題を踏まえて、どのようなエンジニアリング戦略を描いたかを提供する
• 「将来の事業成長」につながるイノベーションと、「今の経営状態」を示す財務会計とをつなげる方法について考える
  • イノベーション経営のためのシーズ投資は、現在の経営成果の将来費用から支払われる
  • どのようなお金の流れが起きるのかをイメージし、イノベーション戦略に結びつけることを考える

話さないこと

• 詳細な財務会計の知識

概要

組織は突然壊れるように見えますが、実際には静かなズレが積み重なり、外部環境の変化や内部の負荷によって一気に表面化します。私はこれまでに2度の組織崩壊を経験しました。1度目はメンバーとして、25名の会社が翌月16名へ縮小する現場に立ち会い、期待役割の曖昧さや採用基準の揺れが組織を不安定にするプロセスを体感しました。

2度目は開発部門の責任者として、より大規模な構造的揺らぎに直面します。外部環境による事業の見直し、急成長期特有の役割・権限設計の不整合、そして組織が大きくなるにつれて起こりやすい認識ギャップの増幅が集積し、結果として約60名の組織が30名規模へ縮小する変化を経験しました。これは特定の誰かの問題ではなく、成長企業で広く起こり得る構造的課題です。

再建の転換点となったのは、制度の刷新よりもコミュニケーションの再設計でした。1on1・定例・意思決定プロセスの透明化、違和感を安全に共有できる場づくりなど、対話の質と量を変える取り組みが組織の再生を後押ししました。また混乱期には「頭では理解しているのに心がついてこない」瞬間が訪れます。その時に私を支えたのは、正解探しより本音で対話し続ける姿勢でした。

本トークでは、崩壊の予兆、構造的要因、再生プロセス、そして混乱期の心の扱い方まで、普遍的に応用できる組織を立て直す技術を共有します。

アウトライン

静かに進行する組織崩壊
メンバーとして体験した初期崩壊（25名→16名）
責任者として直面した大規模な揺らぎ（60名→30名）
再生の鍵──コミュニケーションの再設計
混乱期のリーダーシップと心の扱い方
再生後の“強い組織”が持つ特徴

Learning Outcome（対象の聴衆と、その人たちが得られるもの）

ターゲット

スタートアップ／成長企業の経営者・VPoE・EM
組織が縮小フェーズに入り不安がある責任者
混乱期で心が揺れているマネージャー

このトークから得られる学び

成長企業で起こりがちな役割・権限設計の落とし穴
規模拡大と認識ギャップが引き起こす構造課題
リーダーの心が揺れる時のメンタルマネジメント
崩壊後の再生プロセスと、強い組織に共通する特徴

本セッションでは、EMからVPoEを経てCTOへと役割を広げていったキャリアパスを歩んできた実体験を通じて、
各役割における視点の違いを理解し、自らの意識や行動を変えながら成長してきたプロセスを共有します。

各役割では、異なる視点とアプローチが求められました。
EMではPeople/Project/Product/Techのマネジメントをフル活用して、チームの成果をいかに最大化することにフォーカスしました。
VPoEではエンジニアリング組織全体の戦略と実行を担い、開発組織視点での人・組織の仕組みづくりや人の配置の最適化により、短期的な成果の最大化をはかりました。
CTOでは技術戦略とビジネス戦略の接続を担い、経営リソースをフルに活用した意思決定を行い、短期〜中長期的な組織的な成果の最大化をはかっています。

役割の変化に応じて、求められる知識やスキルの領域も広がっていくことを実感してきました。
特定領域における深い専門性はコスト効率の高い意思決定を可能にする強力な武器である一方で、
対応領域の広さは経営に近づけば近づくほど重要になってきます。
特に、組織開発・ファイナンス・アカウンティングといった経営の知識を身につけることは、より戦略的な意思決定が可能になる糧となりました。
この広さと深さのバランスをどう取るかは、マネジメントキャリアパスを歩む上で重要な課題だと理解しました。

役割の広がりの過程には、避けて通れない葛藤や悩みも伴いました。
エンジニアとして良しとされているスペシャリスト思考のキャリア観から外れているという感覚に、悩まされる日々。
専門外のスキルが要求されるようになってくることによる無能感、コストに見合わない人材になっていく不安感なども、マネジメントキャリア特有の悩みでした。
自分が一人で抱えることの限界を迎えたときに誰かに業務を渡すことの、その球の重さへの申し訳なさは現在でも良く起こる葛藤です。

本セッションでは、これらの困難や葛藤を乗り越えるために、どのように視点や意識や行動を変えて成長してきたかを、マネジメントキャリアパスの実体験を通じて共有します。

Learning Outcome

• EM/VPoE/CTOの視点の違いと必要とされるスキルセット
• マネジメントキャリアパスを歩んでいく際の心構えとスタンス、考え・行動の変え方

プロポーザル概要

「技術的負債で開発者のあまりにも多くの時間が失われている」―しかし2年間の大規模リライトでは、ビジネス価値創出が止まります。本セッションでは、3-6ヶ月で価値を証明する実践を共有します。AMET、EventStorming、Wardley Mapping、Team Topologiesを活用した方法論をお伝えします。

問題提起

私は2年間のマイクロサービス移行を立ち上げましたが、完了時には設計が陳腐化し、再び技術的負債が蓄積しました。

なぜこの悪循環は起こるのか？モダナイゼーションを「技術的問題」とだけ捉え、組織構造・意思決定・学習文化を軽視するからです。技術者だけで決めた「理想のアーキテクチャ」は根付かず、コンウェイの法則により古い組織構造が新システムを再び複雑にします。

考察と提案

転換点1：AMETという触媒で組織能力を引き出す
Architecture Modernization Enabling Teamは答えを教えず、EventStormingやWardley Mappingで組織がアーキテクチャを議論できるよう支援します。組織が自律的にモダナイゼーションできたら解散する。この自立こそが成功です。

転換点2：Core Domain Chartでビジネスの痛みを可視化
経営層は「技術的負債」を理解しません。Core Domain Chartで差別化度と複雑性を可視化し、変更コストとして定量化する。「年間XX億円の機会損失」というビジネスリスクで語ることで投資を引き出せます。

転換点3：バリューストリームから小さく始める
大規模な計画は実行中に前提が変わります。一つのバリューストリームで3-6ヶ月の学習サイクルを回し、成果を示す。Team Topologiesでチーム再編を進め、技術改善・組織変革・学習文化を同時に実現します。

Learning Outcome

• 技術的負債をビジネスリスクとして可視化する手法
• AMETによる組織能力の育成
• EventStormingとWardley Mappingを活用した学習サイクル
• 失敗から学んだ罠：過度な細分化、技術者のみの意思決定、ビッグバン

対象：レガシーシステムと戦うEM/VPoE/CTO