https://ozaki25.hatenadiary.jp/entry/2026/03/04/175136

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

安斎勇樹さん(株式会社MIMIGURI)

ビジネスは戦争である
- 戦略/戦術/軍の統率/領地の独占
- 経営論は軍事的な世界観(1940年代)
キャリア観の変化
- 会社中心で自分の人生がその中にある
- 自分中心で人生の中に会社がある
軍事的世界観 -> 冒険的世界観
- 戦略計画の遂行
  - そのための管理/調達/育成
- 社会のミッションの探求
  - ひとりひとりの自己実現の探求
組織文化の型
- 外部志向 - 内部志向
- 統率正(権力) - 柔軟性(感情)
- 軍事的文化/完了的文化/冒険的文化/家族的文化
半径5mからできるマネジメント
- 目標のマネジメント
- 会議のマネジメント
- 興味のマネジメント
- 文化のマネジメント
目標のマネジメント
- 集団のパフォーマンスへの影響
  - 個人やチームにどのような目標がせていされてるか
  - それをメンバーがどう受け止めてるか
- 軍事的マネジメントは視野を狭窄させて目の前のことだけをやらせる
- 目標はSMARTの法則で
  - これは管理側の都合で整理されることが多い
- ALICEの法則も(Adaptive/Learningful/Interesting/Visionary/Experimental)
  - 意味づけして内発的動機付けになるように
- 目標設定の前と後のコミュニケーションが大切
  - 前：メンバーの意見を踏まえる/対話しながら考える
  - 後：前提や意図を丁寧に語る/取り組む意味をチームで対話する
  - 内発的動機を持てるように
興味のマネジメント
- 興味格差の時代
- 興味のツボに刺さると目標がALIVEになる
- 個別のX年後の目標を起点に育成するのが困難な時代
  - やりたいことを聞かれても将来のビジョンは難しい
  - willハラ
- 眠ってる興味や好奇心を手掛かりに
  - これを把握し言語化出来てる人は少ない
  - ヒト寄りかとコト寄りか
- 興味スタイル
  - 想像/解明/介入/運用とヒト/コトの掛け算
会議のマネジメント
- マネージャーが問いかけても反応の薄い会議
  - 何かないですか？を聞くだけじゃなにも聞き出せない
- 問いかけの工夫がされるだけで変化がある
- 「特にないですね」を誘発する問いかけに注意
- オープンクエスチョンは答えるのが難しい
  - 点数をつけるとか選択肢があると具体的な回答が得られやすい
文化のマネジメント
- 風土
  - 集団の雰囲気やイメージ
  - メンバーがどう感じてるか
- 文化/カルチャー
  - 他の組織には見られない
  - その組織固有の価値基準
  - 価値基準の集合体
- 風土の改善だけでなく文化を耕す

「事業目線」の正体

sotarokさん
https://speakerdeck.com/sotarok/shi-ye-mu-xian-nozheng-ti-3tunohuezunoctojing-yan-karajian-etekita-emgachi-tubekishi-dian-at-emconf-jp-2026

マネジメント
- 自組織のアウトプットを最大化する
エンジニアリングマネージャー
- エンジニアの専門性との掛け合わせ
- 事業を成功に導くためのマネージャー
- 事業目線は必要
事業目線
- 経営目線
  - 売上/利益/コスト/戦略
- お客さま目線
  - 価値/体験/使いやすさ
- 事業
  - 営業マーケ/CS運用/管理部門/事業開発/プロダクト/・・・
  - エンジニアリングはプロダクトが主に関わるところ
- 事業目線を持っていると自分の視点と他の立場の視点が接続できて関係性を理解できる
レベル1：数字を知る
- 自組織に関わる数字を知る
  - トラフィック/売上/ユーザ数/登録数
  - 見えないものは考えられない
- 事業予算の構造を知る
  - 売上目標 - 実現するための施策 - 各部門の役割
  - 自分の部門はどこに作用してるのか
- 今日見てる数字は過去の意思決定の結果
  - 明日の問題を解決するために今日何をするべきか
レベル2：お客さまと隣接組織を知る
- 数字が教えてくれるのは結果
- お客さまを知る
  - 数字の裏にあるなぜの理解を深める
  - エンジニアとしてどう解決できるか
  - 出来ない時はそれがなぜなのか
- 隣接組織を知る
  - 組織によってフローも力学も違う
  - ものを作るだけでなく組織運営も見えるようになる
レベル3：戦略に反映する
- 知ったことを自組織の戦略に反映
- ソフトウェアが事業に与える影響
- 何を作っているかを理解したうえでの体制づくり
- 自分の組織のアウトプットを高めたい
  - 自分だけが事業目線を持っていてもダメ
- 仕組み化が必要
  - ダッシュボードなど数字が常に見える仕組み
  - CS研修を組み込む
事業目線の正体
- 自分の立場から事業の全体像へ接続できている状態
- 全部出来なくても自分のチームにとって重要なところから
- 全体像を理解した上でどこからやるか

ストレッチゾーンに挑戦し続ける

ぎーにょさん(Sansan)
https://speakerdeck.com/sansantech/20260304-1

ストレッチゾーンへの着目
- 複数のエンジニアがキャリアの停滞感から退職申し出
- 停滞感をうまないこともマネージャーの責務
ストレッチゾーン
- コンフォートゾーンとパニックゾーンの間
- もっとも成長しやすい領域

ストレッチゾーンがない時適なチャレンジが分からない

  - Will/Can/Mustを言語化
  - Willをうまく言語化できるとは限らない
  - Willを言語化できないとMustと噛み合わずアクションできない
  - 具体と抽象のリフレーミング

中で自然消滅しそう

  - 目標を立てる
  - 本当にストレッチなら不安がつきまとう
  - コンフォートゾーンの誘惑を断ち切るための武器になる
  - SMARTにたてる
      - 野心の低い設定にならないように
      - 忙しくて取り組めなかったにならないように
  - FASTにたてる
      - SMARTでカバーできない要素

外部要因が阻害しないか
- 実行を支援する
- 権限移譲を明確に
- 自分で決めていいのかわからないがアクションを阻害する

スケールさせるために
- マネージャーがボトルネックになってしまう
- そうならない仕組み作りは難しい
- システム思考

守る「だけ」の優しいEMを抜けて

mitsuiさん
https://speakerdeck.com/maroon8021/shou-ru-dake-noyou-siiemwoba-kete-shi-ye-totimuwoliang-fang-jian-rushi-dian-woshen-nituketahua

崩壊寸前のチーム
- 入社してすぐ、退職や異動でチームが不安定に
- 社歴長いメンバーが不在で日々のオペレーションで精一杯
- 生存するための盾
  - 外部からの依頼を絞り込む
  - WIPを極限まで絞る
  - 対話とモブプロで知識共有
- その間にヒトも増やして立て直し
- 守りがうまくきいた
転換点の時代
- 新規プロダクト
  - 過酷なロードマップ
  - 急造体制
  - ドメイン知識のかたより
- じっくりチーム組成したくても待ってくれない
- 信じていたEM像
  - サーバントリーダーシップ
  - ビープルマネジメントの徹底
  - ボトムアップの組織
- 特定領域だけにこだわった弱めのEMだった
- 支援が停滞に変わる
- 変えたこと
  - 合意形成から即断へ
  - 采配と調整を一手に
  - 設計の初動を引き取る
- 変えなかったこと
  - スクラムイベントのリズム
  - 1on1と毎日のチーム相談会
  - 重要昨日の実装はメンバーに
守るところと攻めるところのトレードオフ
- 事業の推進とチームの健全さ/負債の解消
- その意思決定に企業価値があるかどうかで判断するといい
- DCF法
- リスクが積み重なると企業価値を削っていく

「開発生産性」ではなく「事業生産性」こそが本質

江副廉人さん(株式会社ワンキャリア)
https://speakerdeck.com/onecareer_tech/kai-fa-sheng-chan-xing-dehanaku-shi-ye-sheng-chan-xing-kosogaben-zhi-roicdeniu-jie-ku-kai-fa-no-jia-guli-nozui-da-hua

働く意義
- 株式会社で働くこということ
- 投資家から資本を集めて事業活動を通じて価値を最大化する
- そのサイクルを回す
- 投資家による資本で周ってる
- 投資家の求めるリターン
  - キャピタルゲイン
  - インカムゲイン
- キャピタルゲイン
  - これを生むのは
  - 企業価値の向上 - 株価上昇 - キャピタルゲイン
  - 将来生み出されるフリーキャッシュフロー
- フリーキャッシュフロー
  - 利益によって会社が自由に使えるお金
- DCF法
  - 将来のFCFを現在の価値に割引いて企業価値を算出
- ROIC
  - FCFは結果に過ぎない
  - それだけだと現場がどう動いていいかは難しい
  - 投下資本に対する利益率
  - 事業生産性
開発生産性の罠
- 開発生産性のレベルは順に上がるわけではない
  - 仕事量の生産性 - 期待付加価値の生産性 - 実現付加価値の生産性
  - 開発チーム - プロダクト開発組織 - 事業部門全体
- AIで生産性が上がっているのか
  - 生産量は増えている
  - でもそれは事業の生産性/ROICに直接つながるわけではない
- 開発者としてROICをどう高めるか
  - 開発/運用コストを下げる
  - 雨天資本や固定資産を下げる
ROICを意識した取り組み
- ソフトウェア資産に計上する開発の管理
  - エンジニアが投資対効果を説明
  - 作る活動にとどめず事業成果と結びつける視点を強化
- 財務知識の向上
  - マネージャー対象に隔週で財務勉強会
  - DCF/ROE/ROA/ROICなどの指標の理解
  - 投資家目線/経営者目線の事業や開発の捉え方
- 開発スピードの向上
  - 全工程にAI活用
  - 品質を維持しながらリードタイム削減

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

松山勇輝さん(株式会社mento)

AI時代
- アウトプットは激増
- アウトカムは微増
エンジニアリングの現状
- 全職種が直面する未来の予告
- 「スタートアップ x エンジニアリング」が最前線
- 非エンジニアやエンタープライズは少し遅れて来る
次世代のマネジメント
- AIエージェントをロングランできる工夫
- セキュアにするためのサンドボックス環境
- skillやCLAUDE.mdでの振る舞いコントロール
- -> これらは本質的に自律化の支援でチームマネジメントと同じ構造
グローバルトレンド
- スパンオブコントロールの拡張
- 人の意思決定がボトルネックになる構造で階層を減らしてフラット化
- グローバル企業では進んでる
- フラット化はマネージャーを追い詰める
  - マネージャーのエンゲージメントは過去最低
  - 仕事の中断頻度は2分に1回という調査
EMは全社を救う先行事例
- 最前線でAIによる高速な意思決定の渋滞を体感している
  - 全マネージャーにいかしていくことができる
- 戦略的に余白を作り出して時間の使い方を変える
  - メンバーが自律的に行動する支援
  - マネージャーの労働力がボトルネックにならないように
- 組織に意図のデータを落とす
  - マネージャーのコーチングスキルに依存していたところ
  - 動機のデータを落としていく
- わがごと化された目標
  - 自律性につながる
  - フラットな組織になっていくとマネージャーが全員と向き合うことが現実的じゃなくなる
  - メンバー自身が目標に継続的に向き合ってフィードバックサイクルを回す
- マネージャー自身が時代に合わせて行動を変える

組織崩壊と向き合う技術

山元亮典さん

組織の変遷
- 従業員が半数になるような崩壊が2回
組織崩壊1
- 資金調達で採用拡大
  - ハレーションで31名が14名に
  - 評価制度が整ってなかったりマネジメントが機能してなかったり
- 制度設計やエントリーのマネジメントを改善
  - 評価制度刷新
  - 現状を理解して入社してもらう
  - 選考でオフィスに来てもらって現場の人と交流してもらう
組織崩壊2
- 新規事業の立ち上げで失敗
  - 55名が27名に
  - 権限移譲が機能せずコミュニケーション不全
  - 失敗後の改善も回せてなかった
- 社長がトップダウンな体制を変えることを決意
  - プロダクト中心の執行
  - 経営陣の採用
  - これまでとシナジーの高い新規事業に注力
  - 売上は過去最高に
学び
- 組織は教科書通りにやることが大事
- その中でも組織崩壊は起きる
- 30人の壁50人の壁
- 上手く言ってる時はいいが上手く言ってないと小さな違和感が積み重なって崩壊につながる

EMからVPoEを経てCTOへ：マネジメントキャリアパスにおける葛藤と成長

yunon_physさん(カケハシ)
https://speakerdeck.com/kakehashi/emtocto

経歴
- EM -> VPoE -> CTO
- チーム -> 組織 -> 経営
- 抽象度が高い問題を解決する場面が増える
- 役割が変わると無能感が出てしまう
- その正体は問の変化
EM
- 目の前のチーム課題にどう向き合う
- Product/Project/People/Tech
- 課題解決から仕組み作り
- 目の前の課題解決 -> 課題解決の再現性 -> 新しい課題に対しこのチームで解くべきか考える
VPoE
- どのチームでどの課題を取り組むか
- 組織のルールやガイドライン
- 新陳代謝をどう促す
- 組織の崩壊を守る面
CTO
- 2年後に売上を最大化するためにどこに投資するか
- 3ヶ月でプロジェクトを立ち上げるために何を許容するか
- どんなリスクを許容すると成功率があがるか
- 自分の後ろには誰もいない
- 責任の重さ
向き合った課題
- インシデント対応関連に20%使っていた
- どこまで仕組み作って対処すればいいか分からない
  - チェックリスト増やしてもスピードが犠牲になる
役割の変化
- 体系的な知識をつける
  - MBA
  - 受託者責任
- 小さくリスクを取る
  - プラスは見えづらくマイナスは見えやすい

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

藤倉成太さん(キャディ株式会社)

ソフトウェアの価値
- SaaS is dead
- AIがどれだけ進化してもグラデーションの間を埋めることは必要
革新的な技術
- まずは人間の作業を代替
  - この段階ではマクロ経済では大きなインパクトはない
- 新しい技術を前提にした何かしら
  - これが出ると革新的に変わる
開発チーム
- チームのサイズは小さくなっていく
- 能力が一緒であれば人はたくさんいた方がいい
- エンジニアに求められる能力が変わるから小さい方がいい
- エージェントを管理して判断し責任をとる仕事
  - しんどい仕事
  - 1人のエンジニアに負わせるのは重い
  - できるだけ複数人がいい
- 2,3人くらいになっていくのが妥当
- いろんな職種でワンチームだった
  - 意思決定するだけになっていくから役割分担する意味が減ってくる
エンジニアリングマネジメント
- プロジェクトマネジメントは相対的に重要性は下がる
- 技術のマネジメントは一定のレベルでみんなかけるようになってくる
- 人のマネジメントは重要なまま
- 開発のスループットをいかにあげていくか
- 向き合うべきチームのサイズ
  - 人数が減るから複数チーム見ることになる？でもその負荷は今までよりも大きい
責任を引き受けるマネジメント
- 未来を予想することに意味があるのか
- アンテナ高くはって取り込んでいく