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

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

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

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

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

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

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

Learning Outcome:

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

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

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

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

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

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

トークの流れ

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

Learning Outcome

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

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

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

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

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

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

得られるもの:

• 「構造化思考」をEM業務（特に組織変革）に活かす具体的なヒント
• チームやステークホルダーとの共通理解を形成する実践的アプローチ
• 「EM → 専門職 → EM」というキャリアの往復から得られる学びと、それを次の挑戦に繋げる視点
• エンジニアリングの隣接領域への越境学習が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活用）が、経営にどう影響するかを説明できるようになる。

概要

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

想定リスナー

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

Learning Outcome

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

話さないこと

• 詳細な財務会計の知識

本セッションでは、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