の、雑なメモ。
- Keynote 冒険する組織の作り方
- 事業目標の正体
- マネージャ版”提案のレベル”を上げる
- スーパーマンに頼らない”分権型組織”で作る強い開発チーム
- マルチロールEMが実践する組織のレジリエンス
- 経営と会計のエンジニアリング
- EMからVoOEを経てCTOへ: 葛藤と成長
- AI Codingの先にある、Engineering Managerの本当の仕事
Keynote 冒険する組織の作り方
あんざいゆうきさん 株式会社MIMIGURI
English summary: This keynote argues that management has long been rooted in military and factory paradigms (strategy, control, resource optimization) and that a shift to an "adventure" worldview is needed: purpose-driven work, self-actualization, and adaptability. The speaker introduces four management levers you can change "within a 5m radius": (1) Goals—balance SMART with ALIVE (Adaptable, Learning, Intrigue, Vision, Experimental) and co-create goals with members; (2) Interest—use people’s curiosity and interests (not just "future goals") as levers for motivation, and watch for "Things vs. People" interest mismatches (e.g. managers who prefer "Things"); (3) Meetings—improve question quality (avoid vague open questions; use concrete, low-friction prompts); (4) Culture—distinguish climate (how it feels) from culture (shared values) and deliberately reinforce culture through rituals, rules, and role models. The talk emphasizes moving from a control-oriented to an adventure-oriented organization.
経営論の課題
- ビジネスとは戦争である
- マネジメントは軍事背景をベースにしてきた
- 戦略、CEOなどの用語も
- 研修は戦争で育成に使われていたフレームワークが多く活用されている
- 工場のラインが安定しない課題に対してマネジメントという概念が
- 奴隷の労働管理方法を参考にしたり
人間と社会の価値観の大きな変化
- キャリア感
- 会社中心から人生中心に
- 1980年代の組織論では必ず「危機感を煽れ」
- パラダイムシフト
- 軍事的世界観
- 戦略の遂行、管理、リソースとしての育成
- 冒険的世界観
- 社会的ミッション、自己実現探求
- ビール業界の例
- ビールを飲まなくなっていくトレンドが自明
- 前は少しでも多く売るマーケティング
- 今はビールの存在意義って何だろう
- 軍事的から冒険的への過渡期
- 軍事的世界観
- 学校教育も同様
- 同じ空間、時間割、スケジュール、慣習で教育することによる教育
- 組織文化の類型
- 統率性と柔軟性、外部志向と内部志向の4象限
- 大企業病により統率ｘ内部で官僚的文化、そこからの脱却に悩む
4つのマネジメント、半径5mからの変革
目標のマネジメント
- 人と組織の創造性に影響を与えるのは、個人／チームにどのような目標が設定されているか、それをメンバーがどううけとめているか
- 軍事的には、目標に対する視野狭窄を作ることがゴールだった
- これまでの基本原則「SMART」
- 管理する側の論理、期限に間に合ったかなどをFeedbackしやすい
- 対抗策はALIVEの法則
- A: 変化に適応
- 目まぐるしいAIの変化
- 将来Tiktokでトップになりたい→ない可能性が高い
- L: 学びの機会
- I: 好奇心
- V: 未来を見据える
- E: 実験的
- この目標をALIVEに受け止めているかが重要
- これができたらつぶしが効く
- A: 変化に適応
- 目標の前と後
- 設定するまで
- メンバーの意見を踏まえる（ヒアリング）
- 対話しながら一緒に考える（参加型デザイン）
- 設定した後
- 前提や意図をリーダーが丁寧に語る（ストーリーテリング）
- 取り組む意味をチームで対話する（ダイアログ）
- 内発的動機と、達成すべき目標をMeetさせる
- 設定するまで
- SMARTとALIVEを両立する
興味のマネジメント
- 興味は技術的に深められる
- 好奇心は「わからん知りたい」、好き嫌いは関係ない、瞬発的
- 散漫な状態から、一定期間同じ対象に好奇心が向き続けると興味に
- 興味のツボに刺さると目標がALIVEになる
- 内発的動機は人によって多様
- 定石の「将来やりたいことは」を起点に育成することは困難な時代
- 何を面白いと思っているか、興味を持っているかを育成の手掛かりにする
- が、それをメタ認知できてない人が多い
- 生成AIにはみんな興味がある、なぜ面白いと思うかは意外とそれぞれ違う
- 共生社会とは、働き方の変化、ビジネスチャンス、などなど
- ヒトに興味、コトに興味で分類される
- ヒト, コト x 創造、解明、介入、運用
- MGRが罰ゲームになるのは、コトに興味がある人がなってるケース
- 処方箋
- ヒトのことを構造などコトのフレームワークに切り替えたり
- ヒトに興味がある人と組んでマネジメントしたり
- 処方箋
会議のマネジメント
- MTGでリアクションが無い悩み
- 問いの質
- ×なんかいいアイディアないですか、この企画にFBないですか食べたい
- どこか一つだけ変えるとしたら
- 自分がユーザーだったら何点ですか、その点数つけたのはなぜ
- いま頭の中にぱっと浮かんだことがあれば
- ×この会社でやりたいことは
- 最近取り組んだ仕事で何が一番面白かった？
- ×夜何食べたい？
- 中華と和食とイタリアンならどの気分？
- オープンクエスチョンは答える難易度が高い
- 書籍「問いかけの作法」
- ×なんかいいアイディアないですか、この企画にFBないですか食べたい
文化のマネジメント
- Climate: 風土
- その集団の雰囲気やイメージ、メンバーがどう感じているか
- 風通しが良い、仲が良い、など
- Culture: 文化
- 他の組織には見られない、その組織に独自の価値規範
- 効率より遊びを重視、打ち上げは吐くまでやる、など
- MGRの仕事は風土の改善だけじゃなく、文化を耕す（刷り込み続けるこ）こと
- 価値基準はAよりもBを重視する、の集合
- ハレの場で投資する、習慣・ルールに組み込む、繰り返し使える、体現メンバーを賞賛する
書籍
- 冒険する組織の作り方
- 新刊：静かな時間の使い方
- 自分の解像度を上げるひとり思考
事業目標の正体
- 登壇者: sotarok
- 関連書籍: HIGH OUTPUT MANGEMENT
English summary: This session clarifies why EMs need "business perspective" and how to build it in three levels. Level 1—Know the numbers: Make metrics that matter to your org visible (traffic, revenue, payments, etc.) via SQL, dashboards, and regular reviews; understand budget structure and how your team’s work ties to AOV, MAU, retention, etc. Level 2—Know customers and adjacent teams: Use numbers to ask "why"; learn from CS, sales, NPS, and user research so you can propose engineering solutions; understand adjacent functions (finance, legal, sales) so design and collaboration improve. Level 3—Reflect and engage in strategy: Participate in budget, roadmap, hiring, and org design; spread business perspective via onboarding (e.g. CS training, dashboards) so it’s not only you. The core idea: management exists to maximize output toward business success; EMs combine that with engineering expertise, so understanding the business is essential.
事業目線
- もっと事業目線をもって、って言ったり言われたり
- なぜEMが事業を知る必要があるのか
- そもそもマネジメントとは
- 事業活動を成功に導く、成果を出す
- そのために自組織のアウトプットを最大化する
- EMとは
- そのマネジメントにエンジニアリングの専門性を掛け合わせて事業を成功に導く
- なので事業を知ることは必然
- 事業目線の正体
- 経営の目線 → 事業（営業、プロダクト、マーケ、CS・・・） ← お客様の目線
- 初期の目線は自分が見ているプロダクト周辺、そこから広げる
Lv. 1 数字を知る
- 自組織に関わる数字を見える状態にする
- トラフィック、売上、ユーザー数、決済に関わるチームなら決済成功数・失敗数など
- 見えないものは考えられない
- SQL叩く、ダッシュボード作る、定例で確認する
- エンジニアリングにおける副次的な効果
- 特定の数字のスパイクで攻撃の検知、そこから対策の工数をどのくらいかけるかの判断
- 事業予算の構造を知る
- 売り上げ目標、そのための施策、各部門の役割分担
- AOV x MAU x Retension、Retensionは…、と分解していくと自分のチームの活動と関連する要素が見える
- ただし、今日のGAPは過去のいつかの計画の失敗。明日の問題を今日解くことが求められる
Lv.2 お客様と隣接組織を知る
- 数字は結果、何が起きたかがわかる
- なぜそうなっているか、を理解する
- CSのオペレーション、こういう問い合わせが来たらこう返信するというルールでの運用
- エンジニア目線だと、こう改善すれば問合せが減ってUXもよくなる、という気付き
- 数字の裏側にあるなぜを理解し、エンジニアならどう解決できるかを考える
- お客様を知る、声を聴く
- ユーザーインタビュー、営業動向、CSの対応、NPS、アンケート
- 隣接組織をなぜ知るのか
- 組織によって、業務フローも力学も違うから
- 経理は毎月数字が締まること、営業は数字を取ってくること、法務は、とそれぞれ重要なことがある
- これらを前提とした設計実装、協業で自組織のアウトプットが変わる
Lv.3 戦略に反映する、関わる
- 予算策定、事業ロードマップ、組織ロードマップ、採用計画、など
- MGRのアウトプット＝自組織のアウトプット＋自分の影響力が及ぶ隣接初組織のアウトプット
- 自分だけが事業目線を持っていても駄目で、仕組み化が必要
- オンボーディングにCS研修、ダッシュボードを常設して数字を見る習慣作り
まとめ
- 自分のチームにとって重要なところから
- 事業目線の全体像を理解した上でどこからやるか
マネージャ版”提案のレベル”を上げる
- 登壇者: Kyash こにふぁー
English summary: The session defines five "levels" of proposals for managers: Lv0 "What should we do?", Lv1 "Which option?", Lv2 "I think this is best", Lv3 "Shall we do this?" (with a clear recommendation), and Lv4 (full ownership). Many new managers feel their proposal level "resets" because scope, time horizon, and options all expand. To adapt: (1) Understand roles and decision-making—learn org structure, goals, meeting design, and budget so you know who decides what and how; (2) Learn by talking—review org charts, have meals with other managers, request 1on1s; (3) Avoid classic failures—e.g. taking only problems to execs without linking to goals, or over-preparing ROI for things the other side already treats as necessary spend; (4) Commit and iterate—accept that not every proposal will be perfect; build in reflection and course correction. Use different proposal levels depending on context and how much you've already aligned with stakeholders.
提案のレベル
- Lv0. どうすればいいですか
- 定例会議ってこれからもこのまま続けます？
- Lv1. どれにしましょうか
- アンケートとるといいかも、振り返りして決めてもいいかも
- Lv2. 自分はこれがいいと思います
- 明日ふりかえりもあるし、そこで話してみるのがいいかもと思うんですがどうでしょう
- Lv3. これでいいですか
- 課題感揃ってそうだったので明日の振り返りで決定しましょう、待った方が良ければ行ってください
- Lv4. メンバーからMGRになると提案のレベルがリセットされたような感覚に
- MGRのレベルはまた上げていけばいい
なぜ難しく感じるか
- 広がりによる変化
- 関わる範囲
- 考える時間軸
- 取りうる選択肢
どう適応していくか
- 役割と意思決定プロセスを理解する
- 自他チームの役割、目標、価値観
- 組織図: 組織や職務規定は意思をもって実装されたもの
- 目標: 事業計画やチーム目標、知ると価値観や考慮すべきことが見えてくる
- 会議体: 協議と意思決定の会議体の設計、知ると誰と何を話していけばいいか見えてくる
- 予算: 予算の全体感と決定プロセス、知るとコントロールできる選択肢が見えてくる
- 物事を決めて遂行されていくプロセス
- 理解するには話しに行くのが一番
- 組織図を見る、MGRとご飯食べに行く、1on1をお願いする、など
- 理解が足りない場合の失敗
- 経営にスライド持って行って課題感を伝えた
- が、嫌なことしか書いてなかった、施策が短期的など
- 今見ると、経営目標との粗いんや意思決定プロセスも理解しておらず意見をぶつけただけ
- 今なら、経営目標へ到達するにはという整理をして、意思決定前の会議体で話して
- インフラコストの削減
- 年間予算の中で、自分のチームがいくら固定費、変動費をかけているか意識していなかった
- AIツール投資
- 予算を意識して動いてなかった
- やってみないとわからないものに対して、過度に費用対効果の説明準備をしていた
- 相手は、予算は減らせばいいものではなく必要な予算は確保する、という考えを持っていた
- 経営にスライド持って行って課題感を伝えた
- 自他チームの役割、目標、価値観
- 覚悟、決めてやり切る
- 一発でスマートに提案できることばかりではない
- 不確実で正解のない課題に取り組んでいるということを認識する
- 振り返りと軌道修正を前提とした提案をする
じゃあどうするか
- 巻き込んで意思決定するためにレベルを使い分ける
- 広がりによる変化を自覚する
- 組織図、目標、会議体、予算あたりから組織の役割と意思決定プロセスを使うんで、最初に持って行く提案のレベルを使い分ける
スーパーマンに頼らない”分権型組織”で作る強い開発チーム
- 登壇者：みたにくん スマートバンク
- 人が増えたのに楽にならない、辛みが増えた、うまく回り続ける組織を作るには
- 2024年にMission Team制度
- それまでプロジェクト型チーム、PMFを優先して柔軟な体制
- 拡大に合わせて長期固定されたチームへ、ナレッジの蓄積、中長期を見据えた活動ができるように
- カードの決裁管理アプリから家計簿アプリへ、ブランディングを変える規模のリリースができるように
English summary: SmartBank moved from project-based to fixed Mission Teams in 2024, then faced gaps: work that didn't fit any mission (maintenance, ops, cross-cutting concerns), unclear ownership, and "all-hands" meetings that slowed decisions. They introduced a committee system—small, empowered teams that tackle specific priorities (e.g. SLOs, CI speed, AI tooling, runbooks, blog/events), with EMs aggregating and prioritizing topics. Committees run in half-year cycles, use RACI, and are explicitly subordinate to Mission Teams. Principles: set abstract challenges and let members decide 5W1H; decentralize so people closest to the problem decide; use committees to grow people and reduce dependence on "supermen." Outcomes included DB/CI improvements, runbooks, AI adoption, and a data-analysis agent. Takeaways: don't over-rely on autonomy or heroes; create deliberate structures (committees, budget tracking) so the whole org can contribute; keep showing how committee work benefits Mission Teams.
組織課題の顕在化
- Mission Teamに当てはまらない課題の対応
- Missionには位置付けられないが重要な課題もある
- 既存機能の保守運用、負荷対応
- マトリクス型組織で対応
- 1年ほど続けて課題が出てきた
- 運用の仕組み不全
- ルールの周知漏れ、品質差異
- オーナー不明確での対応の遅れ
- 以前は問題中合った作業で障害
- 保守運用課題の優先順位問題
- 8：2で、とあいうものの判断が困難
- 重要だけど緊急ではない横断タスクの後回し
- 自主性に任せすぎるマネジメントの限界を感じた
- 全員野球の限界
- 全員参加MTGで、発言機会が減り、聞いてるだけ、意思決定のスピードも落ちた
- ちぐはぐな人員配置
- マトリクスの横の人数が増えてることへの対応ができていなかった
- 少人数の良し何やる、暗黙知、主体性だより、の限界
- 目指したい組織
- 人数像を味方につける
- 3つの”したい”
- 本当に重要な課題を見極めて先手を打ちたい
- 任せるところは任せて
- 問題の追われるのではなく楽しくエンジニアリングしたい
- 新しく始めた委員会制度
- 重要課題に取り組む少人数チーム、実行と結果に責任を持つ
- 何に取り組むかは委員会の中で決める
- いったん自組織・部の中で組成
- コンセプト
- Mission Teamのはざまの課題を継続的に拾う
- 権限委譲と解決スピード
- 人材育成、横断課題でスキルアップ
- EMで集まって徹底的に議論、課題を洗い出し優先度をつけて集約
- SLOの設定と監視、CIの高速化
- AI環境整備
- ブログ・登壇・スポンサー
- 保守運用の手順の整備・アサイン
- あくまでMission Teamが経営の最重要
- それと関連性をもって委員会を設置
- 4つの委員会が成果を出すことでMission Teamに貢献
- 活動のサイクルは半年
- 変化に適応、やりたいことも変わる
- 委員会を継続、分割、統合、新設
- RACIで役割を明確に
- 興味好奇心が持てる課題を設定
- 課題は抽象度高く設定、細部を指示しない
- 5W1Hは自分たちで決める
- 自分たちで決めたことをやるのだから業務調整もメンバーが行う
- 分権型
- EMがすべてを把握することは不可能
- 問題に近い人の方が解像度が高い
- 育成
- 意思決定の機会を増やす、そのための調整も必要
- 意思決定をしてその結果を見ることを学びに
- Mission Teamを超えて交流
- 運用の仕組み不全
他社事例
- Spotify: ギルド
- ピクシブ: エンジニアギルド
- 運用スタイルは各社多様
- 自由な設立・参加か
- レポートラインの整備
- ボトムアップかトップダウンか、スマートバンクはトップダウン
成果
- DBのスロークエリ改善、リードレプリカ導入
- やばいよやばいよメトリクス
- 長時間化バッチの危険水準を超えるバッチの検出、これによって対応の要否の判断
- Runbook
- 保守運用業務の手順書、実施内容・時間の蓄積、次回のインプットに
- GitHub Self Hosted RunnerによるCI高速化
- PCを購入してそこで動かすように
- 10分以上かかるCIの改善、GHAの運用費も1/3に削減
- AI推進
- ガイドライン整備、予算策定、Devinの浸透
- データ分析Agent
- 自然言語でデータを問合せ、社内の75%以上が利用
- 登壇支援、ブログ発信
- ブログ駅伝、スポンサーなど
工夫
- 社内で積極アピール、エンジニア以外の仲間も増やした
- 部の課題を共有し、活動意義や重要性を知ってもらった
- 解決の進捗を示し信頼してもらった
- Mission Teamへの貢献重要性を示す
- CIが改善したら、AIが活用で来たら、Mssionの生産性が上がる
- グレード年次に関係なく委員長に抜擢
- Mission Teamだと役割が固定されがちなので、経験の幅を増やす
- 予算管理を徹底し、何にいくら使えるかを把握
- 予算をやらない理由にしないように
- エンジニアリングMoneyジャー
- 予算トラッキング用シートを作成し、予実を見える化
- 委員会の活動が個人のキャリアを伸ばすことにつながるように
- 新しい技術を試したい人の背中を押す
EMとしての学び
- 委員会という強制的な遊び場から多くのものが生まれた
- 課題解決を自主性の高さに任せすぎない、一部のスーパーマンに
- 力を合わせるための強制的な仕掛けが必要
- 任せられるというのは幸せなこと
- 信頼できるメンバーがいる
- MTと委員会のタスク調整は引き続き難しさがある
EMのやりがい
- ヒトや組織がうまく回っていないところを見つけて、治水工事のように流れを整えていく楽しさ
- みんなが楽しくやってる姿をみる楽しさ
マルチロールEMが実践する組織のレジリエンス
- 登壇者: ココナラ 川崎さん
- 少人数で複数サービス横断で見ている組織
- SRE、情シス、セキュリティのEM
English summary: The speaker leads SRE, IT, and security across multiple services with a small team. Multi-role EM brings synergy and flexible staffing but also role overlap, personal single-point-of-failure risk, and complex decisions. To build resilience (adaptability, recovery, sustainability), they applied three principles. (1) Will-first staffing: Assign by Will 50%, Skill 25%, org need 25%; avoid top-down "we need you here." Track and review Will quarterly to catch mismatches. (2) Fair, transparent evaluation: Different roles contribute differently (availability, speed, satisfaction, risk); use role-weighted evaluation axes and a clear 5-step process with evidence; add 360° feedback so invisible contributions are recognized. (3) Gradual delegation to remove SPOF: Use a staged handover (observe → consult-then-act → report-then-act → after-the-fact report → full delegation) and quarterly checks on judgment, risk assessment, escalation criteria (scope, urgency, uncertainty), and feedback receptivity. Measure resilience via engagement, attrition, bus factor, recovery time, and decision speed.
- メリット
- チーム間シナジー
- 横断的な人材配置
- リソースの柔軟な最適化
- デメリット
- 役割の重複衝突
- 属人化（自分）
- 意思決定の複雑さ
- その中で試行錯誤した話
組織のレジリエンスとマルチロールEMの設計哲学
- レジリエンス
- 適応力: 環境変化に柔軟に
- 回復力: トラブル発生時に素早く
- 持続可能性
- 構造的な脆弱性
- 属人化、バス係数
- 組織構造の硬直性
- SPOF、意思決定のボトルネック
- マルチロールの課題
- 自分の役割の重複・衝突
- 評価基準の不統一
- 自分のリソース配分の複雑さ
- レジリエンスを高める設計原則
- Will起点の組織設計
- 実はこれやりたかったを拾う、離脱のしにくさ
- 透明性: 配置理由、評価基準、意思決定
- 納得感、組織への信頼性、意思決定へのフィードバックの得やすさ
- ゆるやかに権限移譲、組織変更を
- 徐々に複数人が意思決定できるように、失敗しても学ぶ文化、ハレーション防止
- Will起点の組織設計
Will起点の横断人材配置
- 失敗ケース
- 上の方針で優先度変更になったから、以上
- 人が足りないからここよろしく
- 結果、エンゲージメントスコアがダウン
- 起きたこと
- 主体性の低下し適応力低下、回復力低下、離職率が上がり持続可能性低下
- なぜ
- 急速な組織拡大で配置を急いだ
- Willを正しく認識することからスタート
- 評価と分離、現在・過去・未来のWillを聞いて振り返って、記録と共有を四半期ごとに
- 配置とWill不一致や希望を見つける
- マッチングの3要素
- Will 50%, Skill 25% 組織のニーズ 25% というアサインになると良い
- 横断配置例
- SREのプラクティスで社内システム効率化したい、自分がユーザーでもあるので何とかしたい
- セキュリティの知識を深めたい
- セキュリティとインフラの知識を身に着けてセキュリティアーキテクトになりたい
評価
- 失敗ケース
- 作業手順書整備したけど評価されずデモチ
- コードを書く人が評価される
- 不平不満
- チャレンジが評価されない、失敗を共有しない、ロール間の不公平感、離職リスク
- ロールごとに貢献の種類が異なる
- 評価基準が技術力のみだと不公平感
- 可用性向上、対応速度、従業員満足度、リスク低減など様々
- やったこと
- ロールの違いを吸収する評価軸を設けた
- 5つの評価軸、ロール別重みづけ
- ５つの評価ステップ
- 目標設定、中間FB、自己評価、上司評価、評価面談
- 透明性
- 評価基準公開、エビデンス・理由の明示
- ロールの違いを吸収する評価軸を設けた
- マネジメント層で導入中
- 360度FB
- 上司の主観に依存しない、見えにくい貢献を発見
- 360度FB
権限移譲、SPOFの解消
- 失敗ケース
- いい感じにやっておいて、よろしく
- 急な権限移譲と丸投げ、サポート体制なし
- 判断ミス、メンバー疲弊、SPOFは解消されず新しいボトルネックを作る
- なぜ
- 段階を無視、SPOFを解消したいという焦り
- オンボーディングプロセス
- 観察・学習
- 相談後実行
- 報告後実行
- 事後報告のみ
- 完全委譲
- チェックプロセス
- 判断基準の理解
- リスク評価能力
- エスカレーション判断
- 影響範囲（自チーム、他チーム、全社）
- 緊急度（1週間＋、三日以内、即時）
- 不確実性の3つの基準
- 基準を設けて、どれか一つでも一番右に当てはまった即エスカレーション、など
- 実行能力
- フィードバック受容
- を、4半期ごとにチェック
判断フレームワーク
- レジリエンスを測定する5つの指標
- エンゲージメント
- 離職率
- バス係数
- 組織回復時間
- 意思決定スピード
- 判断の型化
- なんでこの評価なの？と聞かれたら透明性が不足
- など
経営と会計のエンジニアリング
- 登壇者 atama+ Maeda Kazuki
English summary: Even logically sound proposals (e.g. infra optimization with payback) often fail because they ignore cash flow (CF) and company phase. The session stresses: "Profit is opinion, cash is fact." It introduces CF patterns and matching tech strategy: Healthy (positive operating CF, reinvesting)—focus on growth bets (architecture, new products, DevEx); Startup (negative operating CF, funded)—prioritize speed to PMF and fast experimentation; Restructuring (selling assets to survive)—cut cost and focus on revenue, but avoid zeroing all future-oriented investment. For proposals: state current CF pattern, cost of delay, and a CF-improvement scenario in the language of finance. AI-era implications: investment options and cost structure (e.g. variable AI usage) change, but CF remains the foundation; review allocation and roadmap quarterly. The speaker’s path to financial literacy: study public numbers, join large deals, talk to execs and business leaders, and connect CF patterns to tech strategy so investment decisions align with the company’s real priorities.
- インフラ最適化の提案を経営に提案するシチュエーション
- どんなストーリーで提案するか
- 初期投資、月次コスト、投資回収期間を揃えて提案
- 通りそうだが通らないことも、ロジックは正しいのに
- なぜ正しい提案が通らないのか
- 財務情報を理解すれば提案の戦略が見えてくる
技術戦略って何
- 書籍「エンジニアリング統括責任者の手引き」
- 財務計画こそがすべての会社の計画の基礎
- 財務情報ってどうやって手に入れる？
- 理想：CEO/CFOからの方針（来期は投資、効率化）
- 現実：方針が技術戦略まで結びつかない
- EM/VPが自ら結びつける必要がある
- 財務三表
- PL: 稼げているか
- BS: どれだけ余裕があるか
- CS: お金が回っているか
- 特にこれに注目、PLで利益出ていても黒字倒産があり得る
- エンジニアの事業貢献
- 事業貢献というとPLをイメージしやすい
- 一方、会社が真に追っているのは企業価値の最大化≒将来生み出すキャッシュフローの総和
- なのでCFを理解することが真の事業貢献の起点に
- 利益は意見、キャッシュは事実
- 利益は解釈の余地がある、会計方針で変わる
- キャッシュは変わらない
- Amazonの赤字経営の実態
- PLは赤字から薄利
- 営業CFは一貫してプラス、年々成長、稼いだキャッシュを即時に再投資していた
- CFの理解
- 営業CF：本業での現金創出
- 投資CF：設備投資・資産売却
- 財務CF：借入・返済・資金調達
- CFパターン
- 優良型
- 本業で現金＋、それを投資に回している状態
- 技術戦略は将来のキャッシュを生む攻めの投資に注力
- 次世代アーキテクチャへの刷新、新規プロダクト、DevEx向上や採用への投資
- 創業期型
- 営業CFがマイナス、資金調達で得た現金を事業に回している
- 時間との勝負、限られたキャッシュでPMFに到達できるか
- 技術戦略は負債を許容し早く正しく進む、高速に仮説検証
- リストラ型
- 営業CF／財務CFマイナス、資産売却でしのぎ
- 生存が最優先
- 技術戦略は優先順位がすべて変わる
- インフラコスト最適化、不要なマイクロサービスの統廃合、売り上げに直決する機能開発
- だだし、次の世代のCFを生む種まき・投資を0にするのは高リスク
- 優良型
- 冒頭のインフラ最適化提案
- 優良型の場合
- コスト削減より価値の創出を優先したい状態
- 優良型の場合
- 財務リテラシーの第一歩
- VPoEになって最初は経営の話が理解できなかった
- やったこと
- 公開されている会社の数字を眺め、事業ごとに可視化
- 大型の商談に同行して実際にキャッシュを生まれる現場を理解
- 経営や事業部長の対話で事業戦略と財務戦略を理解
- 知りたければ近い現場へ
- CFパターンと技術戦略の接続
- 技術戦略の土台にできるように
- 投資計画はミクロな合理性ではなく、マクロな経営の目で
先行投資と財務のジレンマ
- リストラ型なら次の投資を止めるべき？0にするのはリスク
- 研究開発やCoding Agentのツール費削減→競争力低下→営業CFの低下、の悪循環
- 長期投資のジレンマ
- 短期PL悪化
- 短期CF悪化
- 長期CF：将来CFの源泉
- Netflixの事例
- 営業CFの伸びが鈍化するたびに次の投資に踏み切ってきた
- DVD事業鈍化でストリーミング、ライセンス事業鈍化でオリジナル、国内鈍化でグローバルへ
- 踊り場で種まきを絶やさなかった話
- 2024年、事業は踊り場にあった、次の成長曲線が見えず、新しい技術投資を提案しづらい空気
- 有志で小さく非公式に、生成AIを使った新しい機能に挑戦
- 小さな成果だったが投資する価値があるという自信につながった
- 経営として技術シーズ探索のための組織投資を認める判断に
- 学び：技術投資を経営に提案するには
- CFの言葉に変えて、投資の必要性を提言する
- 現状のCFパターンを示す
- 先送り時の損失を示す
- CF改善シナリオを示す
- CFの言葉に変えて、投資の必要性を提言する
これをAI投資に適用する
- AIにより技術投資の中身が変わりつつある
- 投資の選択肢：採用・外注費に加えて第三の選択肢に
- コスト構造は固定費に加え、AI利用量という変動費が増える
- 配分調整の頻度はボトルネックが移動（Codingが早くなって別の個所に）し続けるため配分見直しを高速化
- 四半期ごとの見直し
- CFパターンを更新
- 配分見直し
- ロードマップ反映
- AIネイティブ組織への転換が必要な理由
- 同じ人数でより多くの事業に打席を作れる組織構造が必要
- どこに工数がかかっているかのアンケート
- 計測の仕組みで移行を動的にモニタリングする
- 計測の目的は問題を早期に検出し、素早く対策を打つこと
- Four Keysだとちょっと合わないので同計測しようか考え中
- 早くなっているか
- 壊れていないか
- 軽くなっているか
- AIに任せられているか
- AI時代に変わるのは選択肢、コスト構造、配分頻度
- 変わらないのはCF
まとめ
- CFパターンを読めばEMとして取るべき技術戦略が見える
- CFパターンを理解する
- 先行投資の重要性を知る
- 経営の言葉で提案する
- 次のCFを生む活動を
EMからVoOEを経てCTOへ: 葛藤と成長
- 登壇者: ゆのんさん カケハシ
- 日本CTO協会、EM.FM
- 今でも悩み向き合ってる問題について共有
English summary: The speaker reflects on the shift from EM → VPoE → CTO: decisions feel heavier, "right answers" disappear, and it’s easy to feel less effective—but this is a change in the kind of question, not a loss of ability. EM solves team problems and builds systems to solve them efficiently; the key question is "should this team solve this now?" VPoE chooses which teams tackle which org-level issues and how to improve ways of working; the question is "how should this org solve it?" CTO defines strategic and trade-off questions: where to invest for growth, what pain and risk to accept, under time and financial constraints—VPoE reduces uncertainty with logic and repeatability; CTO rewrites it with judgment. Practical advice: learn the language of management (e.g. fiduciary duty); take small, declared risks; treat exec meetings as practice; use AI for low-ego feedback on proposals. Conclusion: the management career is not only about solving bigger problems but also about accepting discontinuous, judgment-based decisions—and that ambiguity can be the most rewarding part.
直面する問題
- 判断が重くなった、正解がわからない、前より成果が出ていない、この仕事向いてないんじゃ
- チーム→組織→経営と、問題の抽象度・不確実性が上がっていった
- 書籍：なぜ弱さを見せあえる組織が強いのか
- 新しい役職について、これまで有能だったが故の変化、これは退化ではない
- 実際は、能力の限界ではなく、問いの変化
EMはチーム課題を解く世界
- Product, Project, People....
- 課題解決から仕組みづくりへ
- どうやったらもっと効率的に解決できるか、深い専門性を密にけられるか、属人性を排除できるか
- 時間的・キャパシティ的な制約が存在
- どう解くか？→今このチームで解くべきか
- 10年前
- 多くの要望が来る、POがタスクを切る、チームを3並列にして量産
- 結果、検証しきれないことが増え、不具合も増え、誰も幸せにならなかった
- ただ課題解決をすればよいのではない
- 課題に対する向き合い方
- 目の前の課題解決→再現性を高める→今このチームで解くべきか
VPoEは組織課題を選ぶ世界
- どのチームでこの課題に取り組むか
- 組織のルール・ガイドラインをどう整備するか
- どうやったらもっと働きやすく
- 新陳代謝をどう促すか
- 今、この組織でどう解くべきかを考える
- 当時
- 良い組織が良いプロダクトを作る、が自分のビジョンだった
- ふりかえってみると、実は組織を壊すかもしれない変化から守っていることでもあった
CTOは経営課題を定義する世界
- 組織から経営に
- 2年後に売上最大化するためにはどこに優先的に投資をすべきか
- どんな痛み、リスクを許容するのか
- 時間と財務の制限で、答えのない問いが増える
- VPoEとCTOの違い
- VPoE: 不確実性を論理で収束させ再現性
- CTO: 不確実性を意思で書き換え
- EM/VPoEのときはいつもうしろにCTOがいてくれた
向き合った課題
- CTOになりたてだった頃
- 不具合の解消に追われる日々、月20％使ってるチームも
- 課題を分類し、何に影響するかを言語化した
- 組織感情としての不安
- どこまで対策すれば問題が防げるのか誰もわからない
- チェックリストやレビュー増やせば増やすほどリリーススピードが犠牲に
- やりすぎないことが重要である全逓を全社ですり合わせ
- 保守コストを計測し、開発生産性と保守コストの認識合わせ
- OKRとして不具合を自分たちが先に発見することを80%に
- 正しさは事後的にしかわからない、と腹をくくる
- CTOとして、リスクを取って組織を変化させる
どう役割の変化を乗り切るか
- 体系的な知識を身に着ける
- 経営者同士で話される言語は最低限理解
- MBAを取得、受託者責任という言葉が経営思想の核になった
- 受託者責任：プロとして託されたものの価値を最大化する義務
- 投資家からすると組織の中は見えない中で、期待に応える責任
- 小さくリスクとを取る
- プラスは見えづらく、マイナスは見えやすいのが思考と行動を制限する
- これはリスクを取る、と宣言して行動すると意外と何とかなる
- 経営会議で新しい方向性を上程する
- 突っ込まれまくるが修行だと思う
- 発信するだけで100点だと思って
- AI経営者・AI投資家によるアウトプットのレビュー
- 人間よりは不思議と傷つかない
終わりに
- マネジメントキャリアとは、解く能力を拡張することだけではない
- 合理的連続変化の世界から、非連続の意思決定を引き受ける世界に
- 模索している時が一番楽しい
AI Codingの先にある、Engineering Managerの本当の仕事
- 登壇者 キャディ 藤倉さん
English summary: AI changes what we build and how we work. Historically, breakthrough tech first replaces tasks, then reshapes work and society; the same is happening with AI—knowledge and implementation become more commoditized, while judgment and accountability remain human and become the main differentiator. Team size may shrink (e.g. 2–3 people who think, decide, and take responsibility together), and role boundaries (PdM, design, dev) may blur. Engineering management: project management and "making everyone similarly good at execution" matter less; people management stays central—but the focus shifts from "how to code/design" to "how to judge and take responsibility," which is harder. EMs may not span more teams; rather, fewer reports but heavier 1on1s. In uncertain times, the role is to stay alert, adapt quickly, and keep choosing what you believe is best. The talk closes by acknowledging that EM is tough but encourages embracing the uniqueness of this moment of change.
AIは私たちの仕事の何を変えるのか？
- 観点は2つ
- AIが世の中をどう変えるのか、それに伴って作るものがどう変わるのか
- 仕事の在り方がどう変わるか
ソフトウェアの価値
- AIで価値は減ってしまう？SaaS is deadなどと言われたり。
- 過去、革新的な技術が出てきたときに世の中はどう動いたか
- 1950年ごろ、電子計算機の誕生
- うまく使える業界、使えない業界のグラデーション
- うまく使えないところを補完する役割としてソフトウェア、生まれる不確実性に対しそうとウェアエンジニアリングが
- グラデーションがある上ではその間を埋める役割がいる
- 革新的な技術が生まれると、まず人間の作業を代替する
- 職を奪われる人たちも
- ただこの段階ではマクロ経済視点では小さな変化
- 大きな影響を与えるのは、それを前提とした働き方や工夫、世の流れができてきたとき
- 電気の発明→蒸気機関を置き換え→小型などにより工場ラインが置き換わり→サプライチェーンの変化、まで行って大きな影響に
- AIに置き換えると
- ヒトの置き換えは起きるがそれだけじゃなく、法律、経済などが変わっていく
- 1950年ごろ、電子計算機の誕生
ソフトウェアエンジニアの仕事
- AIが質の高いコードが書けるようなテクニックが生まれ、ボトルネックになったレビューを工夫するようになり、と一般的に人がやってきた作業を代替するだけなく、優秀な人がやってた仕事もAIに
- 当時1999年ごろ
- Googleの検索精度が低かった時代
- ソフトウェアの専門知識をどれだけ持っているかがエンジニアに必要な要素
- インターネットにより知識だけを持っていることの価値が下がった
- AI以後のエンジニアの仕事の価値
- 知識、経験、設計スキル、コードの明瞭さなどはAIにより代替
- 判断、結果に責任を持つことはまだ人間、これは元々持っていた要素だがOne of themだった、それが他の要素がなくなったことにより重要に
開発チーム
- だいたい4～5人で、とかのパターンが一般的、それは小さくなる？
- 一人ユニコーン企業は可能かみたいな話もでたり。（相対比較の中でのユニコーンなので1人は難しいと思うが）
- AIがいるからエンジニア少なくてもよいのか
- 相対的な規模勝負の世界ではそうではないだろう。同じAIを使うチームであれば10人より100人の方がアウトプットが多く
- ただ活躍できるためのスキルを持っているかどうかは重要
- 結果として組織は小さくなるだろうと考えている
- エンジニアの仕事
- 考えて判断して責任を取るところまでが仕事になるが、それはしんどい仕事
- そのタフな仕事を1人に、というのは難しい
- なので複数人でお互いにチェックしたり判断したりという形がいいだろう、そうすると2～3人のチームに
- PdM、デザイナーも考えて判断して責任を取る仕事になるのは同じ
- それだけ役割分担する意味はなくなる
- PdM兼UX、兼デザイナーと境界線は無くなっていくだろう
- そういった複数役割を持った人たちによる数人のチーム、という形になるのではないか
エンジニアリングマネジメント
- PjMの重要性は下がるだろう
- 先人たちが技術をコンポーネント化しブラックボックス化し、難易度を下げ再利用性を上げ組み合わせで作れるようにしてくれた
- AIの登場で、そういった形でプロジェクトの不確実性が下がってくるのではないか
- 技術マネジメントの領域
- マインドシェアは変わらないがある程度同じレベルで作っていけるようになっていくと？
- ピープルマネジメント
- ヒトがいるうちは必要だろう
- 設計が苦手、コード書くのが遅い、といった相談は無くなっていく
- どう判断したらいいか、どう責任取ったらいいか、という相談になり、MGRは大変になりそう
- 開発のスループットを上げていくことは当面考える必要がある
- 1チームあたりの人数が減ると、EMは複数チーム見るようになるのか？
- 1チームあたりの責任は重く、時間軸は短くなるのでそれは難しいのでは
- 1on1する人数は減るが、内容が重くなる、のようなことがあるのではないか
責任を引き受けるマネジメント
- どうなるかわからない、変化が速すぎる中、未来を想像することに意味があるのか
- 常にアンテナ感度を高めて多方にアンテナを張って、素早く順応していくしかない、それでいいんじゃないか
- 考えて考えて、自分としてこれがベストだと思うことをやっていく、それは変わらない
この瞬間を楽しもう
- 人や事業に向き合うのはしんどい、EMの仕事は難しい
- けど難しいのはわかってるので楽しもう
- この変化はなかなかないレベル、何十年後かに「あの時はやばかった」と。
