日: 2026年3月4日

聴講メモ：EMConf JP 2026

はじめてEMConfに参加してきた。マネジメントから離れて今はいちメンバー（IC）として業務している。マネジメントへのやりがいを感じ始めつつも、ICに戻る（そのための転職）決断をしたのは、筆者の経歴が、超少人数チームでの開発経験か、超上流〜上流の業務あるいはマネジメント（それも受託開発事業で営業寄りの業務が中心）と偏っていることが悩みで、まともなチーム開発の業務・現場を知らないことには、今後どちらのキャリアにも立てないと思ったからだった。なので、いずれまたマネジメント業務に携わりたい意欲もあるし、その時は「エンジニアリング・マネージャー」を名乗れる経験・知見を積みたいと思っていた。

その背景もあって、EMConf にはいつか参加したいと思っていたが、去年はチケット完売していて参加できず、ようやく今年その願いが叶った。

普段参加しているカンファレンスや勉強会とは一味も二味も違うテーマ主体のカンファレンスで非常に学び甲斐があった。特にキーノートセッションの「冒険する組織のつくりかた」は、SMARTでなくALIVE、というまさに筆者自身も感じていた当たり前とされていた目標設定のありかたへの違和感が言語化されていて目から鱗だった。内発的動機を引き出すための対話のヒントも得られた。

他のセッションでは、マネージャーとしての「しくじり」のシェアが多くて、過去の経験や今の行動を振り返っては、自分だけでなかったんだと背中を押された感覚があった。開発の失敗談は勉強会やソーシャルメディア上で頻繁に共有されているものの、組織やピープルマネジメント、経営層とのコミュニケーションに関する失敗談に触れられる貴重な機会だった。

また他にも共通して感じたことは、事業目線の築き方としての数字との向き合い方、ROICの話が非常に面白かったのだが、「数字は結果」としてその裏にある顧客・組織・人にどう自ら接続していくかというヒントがたくさん転がっていて、自分は全然ここが足りていないなと反省した。

イベントページ：https://2026.emconf.jp

冒険する組織のつくりかた

株式会社MIMIGURI 安斎 勇樹 さん

  • 問いのクオリティが「3人寄れば文殊の知恵」に影響を与える
  • 20世紀ビジネス経営論の課題：ビジネスとは「戦争」
    • 軍事的世界観に基づいて構築されてきた（戦略、戦術、顧客を「刈り取る」、マーケットを「制圧する」、研修、フィードバック）
  • この20-30年での価値観の変化：会社中心から人生中心、中心地の変化
    • 会社に隷属↑自己実現の探求
  • 冒険的世界観にシフトしている過渡期（不確実の中で自分の好奇心を資源にしながら）
    • マネジメントの世界観も変化：
      • 軍事的：戦略、計画の遂行と管理
        • 不確実な時代では価値観の定義が難しい（数字を追う→なぜ売るのか？探究し続ける必要性）
        • 学校教育にも変化（ソルジャーを育てる世界観）
      • 冒険的：社会的ミッションの探究と個々の自己実現との共鳴両立
  • 組織のカルチャーの4象限
    • 外向き・内向き、合理・感情（軍事的官僚的、冒険的、家族的）
    • 軍事的文化が、大企業病で官僚的になり、（メガベンチャーが陥りやすい官僚的文化による硬直化）
    • 上に戻そうと、外向きだが感情的な冒険的文化に向かう
  • 半径5mから出来る手触りのあるマネジメントの突破口
    • 目標、会議、興味、文化
  • 目標のマネジメント
    • 目標にテンションが上がってない、形骸化している、目標がない、覚えてない（機能していないってどういうこと？）
    • 人と組織の創造性に最も影響を与えるのは結局、目標（個人チームに設定されているもの、それをメンバーがどう受け止めているか？）
      • 納得していない、内発的動機がない、みんなでやる意味を感じていない、であれば、組織作りは無理ゲー
      • なぜ疎かになる？：旧来の軍事的なマネジメントにより、目標への視野狭窄を作ることが背景にあった（目の前のことだけをやって全体を回す仕組みづくり）
      • これまでの目標設定の基本原則「SMART」→それがないままマネジメントすると言い訳するからあったほうがいい、という管理側の論理（やる側はSMARTだからといってテンション上がらない→BOTになる）
    • 対抗策として、ALIVEの法則
      • Adaptive/Learningful/Interesting/Visionary/Experimental
        • Adaptiveが一番重要：外部環境、未来がどう変わろうが「潰しが効く」意味のある手段（e.g. サッカー選手 vs TikTok）これできるようになると、こんな/あんなキャリアにも効くよね
        • 誰がやっても同じ、でなく、どうやろうか？実験要素の余白があること
      • 目標がALIVEであるかでなく、みんなが「ALIVE」に受け止めているか、意味付け出来ているかが重要
    • テンション上がる目標を立てるだけでなく目標を立てる前後のコミュニケーションが重要→ヒアリングと参加型デザインでALIVEにしていく
      • 設定前に動機の芽生えを収集しておく→どう伝えると前向きに接続するか？ストーリーテリングで、メンバーの内発的動機と達成すべき目標をうまくミートさせる（ヒアリング）
      • チームの中でも、対話しながら一緒に考えつつ、上から降ってくる目標もうまく溶け込ませる（参加型デザイン）
      • ALIVEの点数付、どこを上げていきたいかは人によって違う（Learning? Interesting? を1on1で相談したり、チーム定例で話したりするとうまくいったケースも）
  • 興味のマネジメント
    • 生成AI時代に大事なキーワード：興味拡散
      • 興味を深く持っているか？興味の深掘りは「技術的」に行える
      • 好奇心と興味の違い：好奇心は好き嫌い含むが、ある好奇心が一定期間特定のものに当たり続けている→好きに定着する状態
      • 散漫なまま集中させられない、興味拡散する状態は、生成AI時代にマッチしない
    • 人には興味のツボがある、ここに刺さることで目標がALIVEになる：ツボは人によって驚くほど違う
      • 内発的動機の多様性を活かすのがマネジメントのカギ
      • 旧来のキャリア支援の定石が機能しなくなってきている：やりたいことは？将来のビジョンがわからない（X年後の目標を起点にした目標逆算できない、WILLハラスメント）
    • 今何を面白いと思っている、何に興味が向きがちなのか？を育成の手がかりにする
      • 結構これをメタ認知、言語化できていないケースが多い
      • 「生成AIに興味がある」は一緒でも、なぜ？はそれぞれ違う
      • ヒト or コト　で別れる、このグラデーション（ヒトがどうなる？どんなビジネスが生み出される？）
      • 興味の活動スタイルの8タイプ（想像、解明、介入、運用とのマトリックス）で、チームメンバーの興味傾向を把握しておくことで、マネジメントコストを下げられる
      • マネジメントは罰ゲーム？従来はコト寄りが多かったが、現代はヒト寄り
        • 「人間の心理的なメカニズム」もコト寄り
      • メンバーの興味のレンズがわかるとマネジメントが楽になる（興味=レンズx対象）
  • 会議のマネジメント
    • 何かアイデアないですか？遠慮なく意見ください→「全然リアクションがない」画面オフ、ミュート状態
      • 問いが悪い、オープンクエスチョン：ひとつだけ変えるとしたら？もし客だったら難点をつける？あとXX点上げるとしたら？今パッと頭に浮かんだことがあれば、など
      • 「特にないですね」を誘発する問いかけ→人間はゼロイチは難しい
        • → 3年後やりたいこと？
      • 具体的な回答が得られやすい問いかけにする：選択肢や点数は疲れていてもやる気がなくてもできる最小単位の主体性
        • この1年の仕事を振り返って、どれがおもしろかった？
  • 文化のマネジメント
    • 目標設定をどうするか、受け止め方をどうするか
    • 半径5mを飛び出しているように見えるが、カルチャーを作ったほうが良い
    • 風土(climate)と文化(culture)の違い
      • 風土：その集団の雰囲気やイメージ、メンバーがどう感じているか（オープン、風通し、仲良し、雑談の多さ）
      • 文化：秋葉原や渋谷のように、他の組織には見られない固有の価値基準、効率よりも遊び重視、打ち上げたくさんやる
    • 良い組織：風土改善だけでなく、文化を耕すこと（刷り込み続ける）ことでマネジメントコストを下げて良いチームづくりができる
      • ハレ（キックオフや打ち上げ）の場での投資、習慣、ルールに組み込み、価値規範を繰り返し伝える、体現したメンバーを称賛

「事業目線」の正体 〜3つのフェーズのCTO経験から見えてきた、EMが持つべき視点

sotarok さん

  • 「もっと事業目線を持って」
    • 言った、言われた
    • 「事業目線」を体系化、言語化した
  • なぜEMが事業を知る必要があるのか
    • 書籍：エンジニアリングマネージャーお悩み相談室
    • そもそもマネジメントとは？
      • ピープルマネジメント（評価、採用）、承認とかではなく、
      • 事業活動を成功に導くために、自組織のアウトプットを最大化する
    • EMは、これにエンジニアリングの専門性の掛け合わせ：専門領域を用いて事業を成功に導く（支えになる）マネージャー＝事業を知ることが必然
  • 事業目線とは
    • 事業は、関連部署が取り巻き、経営目線とお客様目線に挟まれている
    • EM初期は、プロダクト以外は見えていない：お客様目線、経営目線、他部署が見えていない
    • 事業目線を持つと、、：自分の立場と経営目線、顧客目線、関連部署とが接続できていて、関係性が構築、理解できている
  • これを獲得するためのステップ3段階
  • Lv.1 数字を知る
    • 自組織に関わる数字を自信を持って言えるか（トラフィック、売上、ユーザー数、登録数、、事業KPI/KGIから一歩ブレイクダウンする）
      • e.g. 決済に関わるチームなら、カード登録リクエスト数、一人当たり決済額、頻度、失敗数
      • 見える状態にする：見えないものは考えられない
      • 具体的なアクション：クエリを叩く、ダッシュボードを作る、定例会議をする
      • 副次効果の実例、SMS認証のスパイク、クレカ登録リクエストのスパイク
        • こうしたセキュリティ施策のための工数確保
        • プロダクトロードマップに影響、リスクをエンジニア目線から説明し工数の捻出戦略
    • 事業予算の構造を知る
      • 売上目標→実現するための施策→各部門の役割分担（自分の部門がこの構造のどこに作用しているのか）
      • 具体的なアクション：数字の因数分解、売上を要素に分解、どこかのポイントに自組織に接続する部分が出てくる（e.g. 売上=決済額xMAU→MAU=前月MAUx継続率→継続率=…、画面UI/UXなど、活動の意味付）
    • 今日のギャップは過去の計画の失敗：今日のギャップを知ること
  • Lv 2. 顧客との隣接組織を知る／顧客を知る
    • 数字：過去の結果の積み上げ
    • 数字の裏にある人と仕組みを見る必要がある
      • 数字：何が起きたか
      • 顧客：なぜそうなっているか？ エンジニア視点でCS, PdMと違う気づき
    • CSがマニュアル通りに返答（CSの正解）→これだけの問い合わせがあるならプロダクトをこう改善するべき
      • 自組織や他部署がその解決法を取らないのはなぜか？
    • 具体的なアクション：ユーザーインタビュー、営業動向、展示会イベントのブース対応、CS対応、レビューを読む、NPS
    • なぜ隣接組織を知る？組織によって、それぞれの業務フローや力学があるから
      • e.g. CS、営業、法務、経理、、
      • e.g. 他部署の日報を読む、Slackチャンネルを見る、定例をオブザーブ、自チームの影響範囲をマッピング、他部署マネージャーと1on1
  • Lv 3 戦略に反映する
    • 数字、顧客、隣接部門の構造と力学を知る
    • ソフトウェアが事業に与える影響を理解し、何を作っているのか？を理解した上で体制づくりをする
    • 戦略に反映する：予算策定、事業ロードマップ、組織ロードマップ、採用計画
    • マネージャーのアウトプット＝自組織のアウトプット＋隣接組織のアウトプット
      • 自分だけが事業目線を持っても、自組織のアウトプットにつながりにくい：仕組み化してチームの活動に組み込んでいく
        • e.g. チーム全員が見れるところにダッシュボード、仕組みで違和感に気づける
        • e.g. エンジニアオンボーディングにCS研修を組み込む
  • 全部やるとCTOでは？全体像を把握した上で、自チームに重要なところから
  • 数字の見える化はすぐ効果が出る：頑張って作ったXXXの機能が使われているか、、

提案のレベルを上げる

こにふぁー さん

  • ブログがベース
  • 叩き台を作ると提案のスピード上がるが、誰でもできるわけではない、そこをレベルで分けてみた
  • 指摘→整理→意見→意思決定の促し
  • こうしたコミュニケーションは意識的無意識的にやってると思うが、マネージャーになった後はどうか？
  • マネージャーになったら、何を整理、提案したら良いかわからない状態
  • リセットされてしまった感覚
  • なぜ難しく感じるのか？
    • 広がりの変化が起きる：関わる範囲、考える時間軸、取りうる選択肢
  • どう適応していくか？
    • 理解と覚悟、理解してやり切る
    • 理解：役割と意思決定プロセス、自チームと他チームの役割、目標、価値観を説明できるか？
      • 組織図、目標、会議体、予算を抑えると理解しやすい
      • 予算権限がないからコントロールできない、ではなく、予算の全体感と予算の決定プロセスを知っておくと、そこに介入できる
    • どう把握するのか：話して把握するのが早い（組織図を眺める、マネージャーと飯、1on1、冗長に聞く、隣接マネージャーに目標を聞く、、）
    • 理解ない状態での失敗例
      • 開発組織の立て直しの経営コミットメントの提案：経営目標とのアラインや意思決定プロセスを理解せず、ただ意見をぶつけただけ状態
        • 経営目標を確認し、そこに行き着くにはという視点で、今なら、協議相談の会議体を移管して、意思決定をリードする
      • インフラコストの削減：自チームの固定費変動費を意識していなかった、
        • 継続的にコストを見直すべきだった
      • AIコーディング予算確保
        • 予算への考え方が足りなかった、必要だからという説明。時間がかかったのは、経営への説明のための説明準備、脇を固めまくったが、拍子抜けするくらいポジティブに捉えられた、もっと早く言ってよ。予算に対する考え方の理解が足りなかった（お試し、レポーティングすれば予算出すと言われた）
    • 覚悟
      • 一発でスマートに提案できることばかりではない、いきなりLv2, 3 で持っていけることの方が少なく、不確実で不明確な課題である事実を認識し、Lv0で持っていく、誰と話すか、初手で持っていくレベルの引き出しを増やすのが重要
      • 提案時、未来永劫これで行く、と捉えられることがあるが、
        • 振り返りと軌道修正のプロセスを前提とするのが大事：提案Lv2
  • 提案レベルを上げるには？
    • 一人でいきなり高いレベルを目指さず、周囲を巻き込んで意思決定するためにレベルを使い分ける
    • 自分で何度も繰り返す自己体験、他者の提案を観察する擬似体験の数を重ねる

トップマネジメントとコンピテンシーから考えるエンジニアマネジメント

zigorou さん

  • EM向けドラッカー入門
    • 企業とは何か？利益ではなく、顧客の創造
      • 顧客が価値を認めて初めて事業が成立する
    • 顧客を作る基本機能：マーケティングとイノベーション
      • 顧客の要求から出発し提供を合わせて自然に売れる
      • 顧客の創造には資源が必要、それが投資、投資効率を上げるにはコスト削減ではなく生産性に注目
      • 利益は原因ではなく結果、次の再成長への原資
      • 事業とは
        • 会社の内側からではなく、顧客と市場から始める
        • 顧客が満たそうとする欲求は何か？
      • 顧客とは？一種類とは限らない、支払う人、使う人、選ぶ人
      • 顧客が買っているのは製品ではなく効用、感じる成果や体験は何か？
      • イノベーションとは
        • 変化を踏まえて次の価値を設計、過去の延長ではなく新しい機会を創造
    • 8つの目標
      • マーケティングの目標：最適なマーケットポジションを担う（最大ではなく）
      • イノベーションの目標：失敗を前提として、成功が全体を回収するつもりで設計
      • 人的資源、資金、物的資源、生産性、社会的責任の目標、、
      • 利益の目標：利益は目的ではなく条件、再投資への原資
    • マネジメントとは？
      • 使命の達成、人の活用、社会的責任
      • 時間の統合：現在（マーケティング）と未来（イノベーション）
      • 管理的活動（マーケ）と起業家活動（イノベ）
      • マネージャーとは、命令する権限ではなく、組織の成果に対して貢献する責任
        • 部分ではなく大きな全体を作る
        • 5つの基本作業
  • マネジメントをEMに落とし込む
    • 顧客は誰？開発チームのリーダー、開発チーム、エンジニア、事業部門、エンドユーザー
    • EMによる価値提供、提供するソリューションと創出されるアウトカムのテーブル
    • マーケティングの目標とEM
      • マーケの目標における問いを翻訳する
        • どこに集中するか→どの顧客価値に寄せるか
          • 戦略的意図を開発の言葉に翻訳し、投資配分を運用可能にする
        • どのポジションを狙うか→選ばれる理由を成立させる運営能力をどう作るか？
          • マーケットポジションをサービスレベルに落とす
    • イノベーションとEM
      • 次の顧客価値を定義、事業は何であるか
      • 新しい満足を作り、古いものを捨てる
      • 仮説実装計測学習のループを短く、意思決定の精度を上げる、その基盤
      • 失敗を前提に、探索投資の枠を確保、主要な賭けに十分な厚み
      • 活動量で評価
    • 生産性の目標
      • 人の頑張りでなく、投入資源を成果に繋げる仕組み
      • 価値提供への変換効率
      • DORA capability
      • ソーシャルダイナミズムが高い状態だと生産性が高い
  • Engineering Ladders
    • EMがメンバーと期待値をすり合わせ、キャリアプランを検討するためのフレームワーク
    • 4つのロール：Developer/Tech Lead/Tech Program Manager/Engineering Manager
    • 5つの軸：Tech, System, People, Process, Influence
    • 各軸ごとに5段階の要求水準がある（ルールを決める側かリードする側か）
    • EMのラダー
      • 一貫したデリバリー、メンバーのキャリア成長や幸福度に責任を持つ（ソーシャルダイナミズム）
      • Tech LeadがSystemを主に担い、EMはPeopleを主に担う
    • 他職種との対比
      • 影響範囲(Influence)を固定して役割差分を見てみる：
        • Team Lv2 で固定すると、他の部分で上回っている必要がある。Tech Leadがいない場合は、TLの役割に介入する必要がある
        • Multiple Teams Lv 3で固定すると、ほぼ下回っている、
  • EMのアウトカム
    • 組織ニーズと個人のキャリアがマッチするアサインを意図的に
    • 自律的なチーム構築
    • 多角的なステークホルダーマネジメント
  • 評価は、うまく管理できているか、ではなく、出せているアウトカムで決まる

守る「だけ」の優しいEMを抜けて、事業とチームを両方見る視点を身につけた話

mitsui さん

  • 崩壊寸前のチームを生存させるまで
    • 退職異動でチーム崩壊寸前
      • 組織コンテクスト、ナレッジの断絶
      • 対象ドメインが複雑かつ膨大→インシデント
    • 守り、盾の戦略：外部からの依頼を徹底的に整理、チーム内でも同時進行を減らし、一つずつやり切りスイッチングコストを排除、そこにモブプロや対話で知識共有（4人全員で動ける状態）
    • 採用異動でチーム体制の回復とデリバリー安定
  • 新規プロジェクトで前に進める振り切った話
    • 転換点、槍の時代
    • 別プロジェクトでロードマップ的にも体制的にもハード
      • ドメイン知識が自分にはあるが他メンバーにはない偏り
    • 少人数、知識差の状況は崩壊時に似ているが、生存ではなく、成果を出し続けることがミッション
    • それまでのリーダー像：サーバント、ピープルマネジメント徹底でボトムアップ
      • 「弱めのEM」
      • 守る姿勢、支援が、前に進めたいフェーズだと停滞に変わる
        • ピープルマネジメントが厳しい意思決定における免罪符に
    • 「細かいことは後で考え、今は自分が決めて進める（覚悟を持つ）」
      • 合意形成→即断
      • 采配と調整を一手に引き取り、分散させるより判断速度を上げる
      • ゼロベースの設計の初動を引き取り、詰まったら即介入する
    • ただ、全員で回す仕組みは残した（スクラム、毎日1時間の相談会での対話）
    • 重要機能の実装はできるメンバーに任せ、貢献実感を感じてもらう
    • しかし、しわよせが生まれた：透明性、合意形成、自律性（これからしっかり作っていく）
  • 守りと攻め、どういうバランスにする？
    • 事業推進と、チームの健全さ／負債解消　これらはトレードオフなのか？
    • 「その意思決定が企業価値にどう影響するのか、で考えれば良い」
    • DCF法、事業価値の計算式（を企業価値に置き換え）
      • EMの判断は、CF(cash flow)とr(risk)を通じて企業価値に影響
      • 事業貢献とは、キャッシュフローを上げていくこと
      • 反対に、リスク（リスクを取り続ける、リスクが大きい）が企業価値を削る
  • 結論：事業貢献だけでもピープルマネジメントだけでもなく、企業価値への影響を考える

「開発生産性」ではなく「事業生産性」こそが本質 ～ ROICで紐解く、開発の「稼ぐ力」の最大化 ～

江副 廉人 さん

  • EMという型にハマろうとしていないか？（経営との接続、開発生産性、ピープルマネジメント、、）
    • 本質的には事業成長とステークホルダーへの還元
  • 我々が働く意義
    • 株式会社＝投資家からの資本を集め事業活動を通じて得た価値を最大化する→投資家に還元し、さらに投資を呼び込む好循環
    • 投資家は、キャピタルゲインかインカムゲインとして利益を得る
      • 開発成果が直結するのはキャピタルゲインのほう（売却益）
      • 企業価値の向上に伴う、株価向上：企業価値は将来的なフリーキャッシュフローへの期待によって形成
        • FCFは本業のCFから事業に必要な設備投資（投資CF）を引いたもの
        • 企業価値の算出方法：DCF法
      • FCFはあくまで結果、EMとしては遠い
      • 稼ぐ力として、投下資本とFCFの間にあるROIC（投下資本利益率）＝稼ぐ力（事業生産性）
        • 「ROIC経営」
  • 開発生産性の罠
    • 開発生産性の向上はROIC（事業生産性）に直結するのか？→NO
    • 開発生産性のレベルは順に上がる、という思い込み
      • LV1: 仕事量
      • LV2: 期待付加価値
      • LV3: 実現付加価値
    • 生成AIで生産性が上がっているという思い込み
      • 生産量は確かに増えるが、事業価値にどれだけ転換できるかが重要（ユーザーにどれだけ使われるか）、見せかけの生産性
    • 開発生産性を高めることが目的になってはいけない、本質は、事業生産性(ROIC)の向上
  • ROICを意識した取り組み
    • ROICを高めるメカニズム
      • ROIC＝税引後営業利益／投下資本
      • 投下資本を運用視点で整理すると、運転資本と固定資産
      • 開発と関連が深い項目
        • 無形固定資産：ソフトウェア
        • 売上原価：開発費、インフラ費
        • 販管費：減価償却費など（ソフトウェア資産が減価償却される）
      • 何が言いたいか：日頃の意思決定はBS/PLに反映されている
    • CAPEXとOPEX
      • CAPEX：ソフトウェア資産への投資（将来にわたって価値を生む前提で投資するもの e.g. 建物、ソフトウェアも同様）＝未来への投資、積み上がるもの
      • OPEX：インフラ費などの事業運営費（人件費、インフラ）＝今かかっているコスト、ワンショット
    • 開発者が知っておくべきROICを高める視点
      • 分母の投下資本を最適化するか、分子のNOPATを上げていくか
      • 利益を高める開発なのか、資本を効率的に活用するに資する開発なのか
        • SpeakerDeck参照
    • ROICを意識した取り組み
      • 1: ソフトウェア資産に計上する開発の管理：エンジニア自身が投資対効果への説明責任を担う（開発開始申請から予実報告）
        • リターンがいつ生まれるかにより、減価償却がいつ始まるのか
        • ワークフロー申請をエンジニアが行い、毎週チームリーダーが予実管理を報告
      • 2: 財務知識向上のための勉強会
        • マネージャーを対象、投資家目線、経営者目線の双方から事業や開発をとらえる視座を身につける
      • 3: 開発スピードの向上
        • AIによるレビュー効率化、設計テストも含むAI活用など、リードタイムの短縮
        • コード品質、体験品質だけでなく、開発開始時に宣言したリターンの品質も
  • EMの存在価値
    • エンジニアが事業に徹底的に向き合わない「正当な理由」は多くある
      • 事業フェーズ上その状況でない、job description にない
    • そのなかでどう組織に浸透させるか？
      • 気合い：根性論ではなく、「意識の高い人」をマジョリティにする
      • 全員にとって当たり前の状態にしていく
    • EMの役割の枠組みにとらわれたままで、成長事業が作れるか？
      • ヒト・モノ・カネを戦略的に活用、他事業部とコミュニケーションし事業推進
      • 事業成功のためにあらゆる手段を尽くす

AI時代、mentoが考えるマネジメントサクセスとその実践

matsumatsu202 さん

  • AIの登場でマネジメントの仕事楽になったか？
  • エンジニアリング領域はAGI水準に近づいている
  • アウトプットはめちゃくちゃ増えたがアウトカムは微増
    • 情報が爆増する中人の意思決定がボトルネック
  • エンジニアリングの現状は、全職種が直面する未来の予告編
    • AIによる生産性革命は、スタートアップエンジニアリング
    • ここから非エンジニアやエンプラへ
  • EMはすでに未来のマネジメントを実践している：AIのロングラン、dangerous modeの利用、そのためのセキュアなサンドボックス環境、Skills, CLAUDE.mdによる振る舞いのコントロール
    • これらは自律化の支援、チームマネジメントと同じ構造
  • グローバルなトレンド
    • span of control の拡張、階層を減らしたフラット化（組織階層を減らす、チームの人数を15-20人に増やす）
    • 間違いなく日本にも来る
    • フラット化はしんどい、マネージャーのエンゲージメントは過去最低
  • 誰がこのマネジメントを変えるのか？
    • EMが全社を救う先行事例
  • どうマネジメントのOSを変えていく？その仕組みとソリューションについて
  • 管理職に戦略的余白を作り、時間の使い方を変える
    • 1: 余白を作るのにマネージャーが頑張るのではなく、メンバーレイヤーが自律的に行動する（セルフマネジメントの）支援が必要
    • 2: 評価、1on1といった業務支援も必要
    • 3: 空いた時間で、マネージャー自身が時間の使い方を内省する
  • 実践1 組織に意図のデータを落としていく
    • 情報処理コストは上がっても、Whyの情報は落ちていない→メンバーが一人一人がどんなモチベーションを持ち、どんな意図を持って、何に困って、というところをデータ化していく：日報文化ではこれが大事
    • AIがメンバー全員とコーチングする
  • 実践 2 AI対話型の目標設定
    • どれだけ目標をわがごと化できるか？が自律化の鍵、15-20人規模で全員に向き合うのは無理、Continuous Management Systemで、日々一人ひとりが目標に向き合って、そこにフィードバックをしたのが評価になる、という考え方を海外では導入されている
    • メンバーが上位の目標をブレイクダウンし、対話形式で自分の目標に落としていく（ドラッカーの言う、自己管理化された目標設定）
  • 実践 3: マネージャー自身が自らの行動を変えていく
    • カレンダーの情報を読み込ませて、こう言う時間の使い方をしたい、ありかたでいたいが、それに沿っているか？をAIからフィードバックもらう
    • マネージャーが変えていけるかが大事：自分がこうありたい、部下からこうして欲しい、上司からこうして欲しい、と言ういろんな期待にマッチしているかどうかのギャップを把握すること
    • 修正サイクルで可視化しながら継続的にチューニングしていく

AI Coding の先にある、Engineering Manager の本当の仕事

藤倉 成太 さん

  • AIは我々が作るもの、仕事のありかたをどう変えるのか？
  • ソフトウェアの価値の変化について
    • AIが高度に発達すると、一般的なソフトウェアの価値は減っていく、存在意義がなくなってしまうのでは？SaaS is dead?
    • NO： 過去革新的技術の誕生時を紐解く
      • 電子計算機：業界によってすぐに活用できる、まだできないグラデーションがあった→補完するためにソフトウェアが作られ、複雑化していき、SWEが発達していった
        • 革新的技術誕生時に人類はグラデーションの「間を埋める」ことをしてきた
      • 蒸気機関、内燃機関、インターネット、、
        • まずは人間の作業を代替してきた
        • この段階はマクロ経済へのインパクトはあまりない（人間の工数を機械が奪うだけ）
        • 人を置き換えるだけでなく、新しい技術を前提とした変化があったとき人マクロレベルの影響がある（e.g. 蒸気機関→電力：配線の自由さや小型化で工場ラインやサプライチェーンのあり方が変わった）
      • AI時代にSWEの仕事が置き換わった後、AIを前提とした法律、組織、収支計算の考えが変わって初めて、経済的インパクトを持つのでは
  • SWEの仕事の変化について
    • 一般的にとどまらずごく一部に限られたエンジニアの知見すらAIが代替している
    • Google検索以前：ソフトウェア開発の知識をどれだけ「持っているか」が重要（専門書籍で学習して）
      • 検索技術の発達で知識を「持っている」ことが重要でなくなった
      • 経験による知識（検索でヒットしない）には価値があり続けた
      • AIの台頭によってそれすらに意味がなくなってきた
    • AI時代に、エンジニアの持っている能力の何を発揮するべきか？
      • 従来的には、設計がうまくできる、コーディングが速い、綺麗、、
      • 今後も大事になるのは、何を作るべきかを考える、作るかどうかを判断する、技術選定をする、そして結果に責任を持つ・責任を取る
      • 結果への責任は従来もあったが、他が多くあってone of themだった
  • SWEの仕事が変わると開発チームはどうなる？
    • 4-5人のチームにリーダーがいて、というパターンが多かった
    • サイズは小さくなる？大きくなる？ひとりユニコーン企業？
    • エンジニア組織は小さくなっていくという感覚
      • 必ずしも少なくて良い、ではない（ミッションの壮大さに対しては数が多い方が良いに決まっている）
      • が、結果的に小さくなるだろう（必要なスキルセットが少なくなり、そこにマッチしないと活躍ができないから）
    • 「考えて、判断して、責任を取る」だけだとタフ過ぎ、ひとりのエンジニアだけに任せるのは難しい：チームやマネージャーで複数人責任分担する（2、3人）かたちになるのでは
    • 従来的ないろんな職種でワンチーム（e.g. PdM、デザイナー、エンジニア、、）は、役割分担に意味が薄れ職種の境界線が解ける（PdM兼UXデザインみたいな）
  • エンジニアリングマネジメントはどうなる？
    • エンジニアそれぞれがエージェントをマネージする時代に必要なくなる？NO
    • 仕事のやり方や注意の向き先は変わってくるだろう
      • PMは相対的に重要性が下がる
      • ソフトウェアの複雑さはラップされて減っていき、再利用可能なものの組み合わせになっていく→技術的な不確実性は下がってきたし、AIの登場でさらに向き合う必要性が下がっていく
    • 技術マネジメントの重要性：技術の何を管理する？が変わってくる
      • 設計の良し悪しもコモディティ化されていくだろう
      • How 実現方法よりも、どの技術を使うべき／使わないべき　の判断が最重要の部分になってくる
    • 相対的に需要が高まるのは、組織、人のマネジメント（仕事を人間としている以上なくなることはない）
      • メンバーが「考えて、判断して、責任を取る」をマネージしてあげる必要がある
      • 従来ジュニアの「設計ができない」「実装が遅い」がなくなる→「どういうプロダクトをマーケットに当てるのが勝ち筋か？」「どう責任を取ったら良いか？」に変わる
    • 開発のスループットの向上は当面向き合う必要がある
      • スループットの大小は、人やプロジェクトやアーキテクチャによって違う現状
    • 向き合うべきチームサイズ：人数減ると、見るべきチーム数が増えるか？NO
      • エンジニア一人一人が見るべき責任範囲が広くなり、意思決定のスピード、支援、環境整備も伴って速くなっていき、厳しくなるのでは
  • 責任を引き受けるマネジメント
    • 未来を予想する、想像することに意味があるのか？
    • インターネットやSaaSの登場、トレンドごとに意見を持つが、あまり当たらない：今回も当たらなくても仕事は続いている
      • 常にアンテナを貼り、プラクティスを取り込み、トレンドに順応していく、でよくないか？
    • プラクティスが出てくる前も、自分なりに考えて、仮説を持って、今考えうるベストを実行し、その結果に向き合い責任を持つことがEMに残り続けるやるべきこと
  • この瞬間を楽しもう