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

EMConf JP 2026 で発表させていただいた内容です!

https://fortee.jp/emconf-2026/proposal/2239eaef-c6db-43fb-9324-6ab821be253b

Transcript

1. 「事業目線」の正体 〜3つのフェーズのCTO経験から見えてきた、EMが持つべき視 点 Sotaro Karasawa / 柄沢聡太郎 / @sotarok EMConf JP 2026.03.04
2. 「もっと事業目線を持って」
3. 自己紹介「CTO x クラフトビールといえば sotarok」 会社のフェーズ 自分のフェーズ 7人共同創業→30人ほど 事業立ち上げ、あらゆるこ とを自分たちで、買収後は 大企業の子会社 初めてのCTO ほとんど「開発リーダー」 開発頑張る、強い組織を作 る、自分が意思決定する 創業2年目くらい 　80人→500人 事業の急成長、海外への チャレンジ、IPO、組織の 急拡大 2回目のCTO マネジメントとは、を知る 自分自身の成長とチームの 強い執行能力、組織カル チャー作り レイターステージ ３代目CTO 事業成長、黒字化、コロナ 対策、リモート環境 3回目のCTO これまでの全てを出し切る 経営・取締役としての目 線、組織カルチャーの再構 築、事業作り 💻Almoha 共同創業者CEO兼CTO / 🍺P2B Haus オーナー
4. なぜ、EMが 事業を知る必要があるのか?
5. 「エンジニアリングマネージャーお悩み相談室 日々の課題を解決するための17のアドバイス」 @ar_tamaさん著 https://www.shoeisha.co.jp/book/detail/9784798189840 「もっと事業目線を持って」は、自分だけじゃなかった
6. • ピープルマネジメント? 人事評価・採用 • 申請の... 承認係...? 雑用係? • なんか大変なことをやる人 • 事業活動を成功に導く、成果を出す • そのために 自組織のアウトプットを最大化する そもそも「マネジメント」とは
7. エンジニアならではの専門性を掛け合わせて「成果」につなげる • 良い組織、良いプロダクト、良い開発環境、良い技術選定... ◦ これら全ては 手段 • 目的はあくまで「事業の成功」 「エンジニアリングマネジメント」とは • 事業活動を成功に導く、成果を出す • そのために自組織のアウトプットを最大化する ✖ エンジニアリング
8. EMとは... エンジニアリングという専門領域を用いて、 事業を成功に導く (またはその支えとなる) ためのマネージャー 「エンジニアリングマネジメント」とは 事業の成功のためにマネジメントしているのだから、事業を知ることは必然 …では「事業目線」とは具体的に何なのか
9. 「事業目線」の正体
10. 経営の目線 「事業目線」 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ エンジニアリング 売上・利益・コスト・戦略... 価値・体験・使い勝手...
11. 経営の目線 EM初期の目線 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ 価値・体験・使い勝手... 売上・利益・コスト・戦略... エンジニアリング
12. 経営の目線 「事業目線」 自分の立場（エンジニアリング）から、事業の全体像への接続ができている状態 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ エンジニアリング 売上・利益・コスト・戦略... 価値・体験・使い勝手...
13. Lv.1 数字を知る
14. 「自組織に関わる数字、言えますか?」 Lv.1 数字を知る
15. 具体的なアクション: • クエリを叩く (SQL? BigQuery? etc.) • ダッシュボード作り (Redash? etc.) • 定例会議などで必ず確認 Lv.1 数字を知る / 自組織に関わる数字を知る • トラフィック、売上、ユーザー数、登録数... ◦ 決済に関わるチームなら? ▪ クレジットカード登録リクエスト数、お客さまあたりの決済額・頻度、失敗数... • 見えないものは考えられない まず、自組織に関わる数字を見える状態にする
16. 副次効果の実例: • SMS認証リクエストのスパイク • クレジットカード登録リクエストのスパイク セキュリティ施策のための工数をどれくらい取るか? • プロダクトロードマップに影響 ◦ 組織における「エンジニアリング目線」での工数の捻出戦略 数字を知ると... 「エンジニアリング」に響く副次効果の実例
17. 事業予算の構造を知る 具体的なアクション: • 数字の因数分解 ◦ 「売上」を要素に分解していく ▪ ECサイトなら? • 売上 = お客さま当たりの決済額 x MAU ◦ MAU = 前月MAU x 継続率 ▪ 継続率 = … Lv.1 数字を知る / 事業予算の構造を知る • 売上目標 → 実現するための施策 → 各部門の役割分担 ◦ 自分のエンジニアリング部門は、この構造のどこに作用しているのか → これがわかっていないと「言われたものを作る」になっちゃうよね...
18. 具体的なアクション: • 数字の因数分解 ◦ 「売上」を要素に分解していく ▪ ECサイトなら? • 売上 = お客さま当たりの決済額 x MAU ◦ MAU = 前月MAU x 継続率 ▪ 継続率 = … 例えば、この辺自組織の関わり … 自組織の活動と事業予算の接続 事業予算の構造を知る Lv.1 数字を知る / 事業予算の構造を知る • 売上目標 → 実現するための施策 → 各部門の役割分担 ◦ 自分のエンジニアリング部門は、この構造のどこに作用しているのか → これがわかっていないと「言われたものを作る」になっちゃうよね...
19. 経営の目線 Lv.1 数字を通じた事業目線の獲得 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ 価値・体験・使い勝手... 売上・利益・コスト・戦略... エンジニアリング
20. ただし... 数字を見ることで「今日のギャップ」には気づける。それだけでも大きな一歩 しかし本質的には「明日の問題を今日解く」ことが求められる 今日のギャップを認識してそれを埋めるために、懸命に意思決定しよう としている人々があまりにも多い。 しかし、今日のギャップは、過去のいつかの時点での計画の失敗を表し ている。 … "明日" の問題を解決するために "今日" 何をすべきか 「HIGH OUTPUT MANAGEMENT」 アンディ・グローブ著 日経BP社 https://bookplus.nikkei.com/atcl/catalog/17/P55010/
21. Lv.2 お客さまと隣接組織を知る
22. Lv.2 お客さまと隣接組織を知る 結果を生み出しているもの... • お客さまの行動 • 複数部門の連携によるオペレーション 数字、見るようになったぞ! 意識上がったぞ! ばんざーい! 結果
23. CS や PdM とは違う気づきが生まれる Lv.2 お客さまと隣接組織を知る / お客さまを知る 「何が起きたか」がわかる 数字 お客さま 「なぜそうなっているか」がわかる ✖ エンジニアリング
24. カスタマーサポートの研修での気づき 実例: • CSは「〇〇の問い合わせが来たら、こう返信する」というルー ルで対応していた • その返信は間違いではない、CSとしては正しい対応。 エンジニアの目で見ると • 「この声が毎月こんなに来ているなら、プロダクト側を変更すれ ばこの悩み自体が消える。UXも良くなるし、問い合わせ数も減 る」
25. 具体的なアクション: • お客さまに会いに行こう: ◦ ユーザーインタビュー、営業同行、ユーザビリティテストを観察、展示会・イベントで のブース対応、導入支援・オンサイトサポート、etc. • お客さまの声を聞こう: ◦ カスタマーサポート対応、アプリストアのレビューを読む、NPS・アンケートの自由記 述 (集計結果ではなく生の声) を読む、解約理由・失注理由を見る、ユーザーコミュニ ティ、etc. Lv.2 お客さまと隣接組織を知る / お客さまを知る お客さまを知る • 数字の裏側にある「なぜ」の理解を深める • エンジニアならどう解決できるのか? ◦ あるいは、自組織や他部署がその解決法を取らないのはなぜか?
26. Lv.2 お客さまと隣接組織を知る / 隣接組織の構造と力学を知る なぜ隣接組織を知る必要がある? → 組織によって、業務フローも、力学も異なるから 例: • 経理: 毎月ちゃんと数字が締まることが重要 • 営業: 数字をとってくることが最も重要 • CS: お客さまの問題を迅速に解決すること • 法務: リスクを最小化、法令遵守すること • etc.
27. 例えば... 新しく課金機能を実装する 開発: UI と決済方法の実装を考える しかし影響はそこで閉じない： • 経理・税務: 売上計上のタイミング、消費税処理、請求書フォーマット • CS: 問い合わせ対応、返金オペレーション、マニュアル更新 • 営業: 料金プランの説明、既存顧客への案内 • 法務: 利用規約の改訂、新機能の法令遵守 etc. これらを前提とした... • 設計・実装・業務フロー構築... • 隣接組織との協力・コミュニケーション 自組織のアウトプットも変わる
28. 具体的なアクション: • 隣接組織の構造を知ろう: ◦ 他部署の業務フロー・マニュアルを読む、他部署のSlackチャンネルを見る、他部 署の定例をオブザーブする、自チームの開発の影響範囲をマッピングする、etc. • 隣接組織とつながろう: ◦ 他部署のマネージャーと1on1する、横断プロジェクトに参加する、etc. Lv.2 お客さまと隣接組織を知る / 隣接組織を知る 隣接組織を知る • 「エンジニアリング」「プロダクト」と、「事業」の違いの理解 • マネジメントに「なめらかさ」がでる
29. 経営の目線 Lv.2 お客さまと隣接組織を知った事業目線の獲得 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ 価値・体験・使い勝手... 売上・利益・コスト・戦略... エンジニアリング 事業
30. Lv.3 戦略に反映する
31. Lv.3 戦略に反映する • 数字を知り、お客さまを知り、 • 隣接部門の構造と力学を知る あとは、ここで知ったことを、 自組織の活動や戦略に反映させるだけ
32. Lv.3 戦略に反映する / エンジニアリング戦略としての事業理解 • ソフトウェアが事業に与える影響を理解する • 「我々は一体何を作っているのか？」を理解した上での体制づくり • 仕様策定から関わる体制、受け入れテスト・QAの融合、技術選定 "明日" の問題を解決するために "今日" 何をすべきか 戦略に反映する: 予算策定、事業ロードマップ、組織ロードマップ、採用計画、etc.
33. Lv.3 戦略に反映する / マネージャーのアウトプットを最大化する マネージャーのアウトプット ＝ 　自分の組織のアウトプット ＋ 自分の影響力が及ぶ隣接諸組織のアウトプット 「HIGH OUTPUT MANAGEMENT」 アンディ・グローブ著 日経BP社 https://bookplus.nikkei.com/atcl/catalog/17/P55010/
34. 具体的例: • ダッシュボードを通じて、お客さまの動き・数字を常に見える状態にし、チーム全員が日常的 に意識できるようにする • オンボーディングにカスタマーサポート研修を組み込み、実際のお客さまからの問い合わせに 返信する体験をさせる ◦ メルカリ時代に全エンジニアの入社時に義務付けた Lv.3 戦略に反映する / 「自分の組織」のアウトプット … 仕組み化 マネージャーのアウトプット ＝ 　自分の組織のアウトプット ＋ 自分の影響力が及ぶ隣接諸組織のアウトプット 自分だけが事業目線を持っていてもダメ でして... ↓ 仕組み化
35. 「事業目線」の正体
36. 経営の目線 「事業目線」 自分の立場（エンジニアリング）から、事業の全体像への接続ができている状態 お客さまの目線 事業 営業・マーケ CS・運用 管理部門 事業開発 プロダクト ・・・ エンジニアリング 売上・利益・コスト・戦略... 価値・体験・使い勝手...
37. やれるとこまでやってみて、CTO目指してみてもいいし? いや、それもうCTOじゃね? • 全部やる必要はない、自分のチームにとって重要なところから • これらの「事業目線」の全体像を理解した上でどこからやるか
38. 明日からのアクション Step 1：自組織に関連する数字を把握する(すぐできる) • 自分のチームに関わるトラフィック、売上、お客さまの数…まず言えるようにする Step 2：数字の範囲を広げ、事業計画と自組織の活動をつなぐ • 事業計画・予算の構造を知り、自分の組織の活動がそのどこに作用しているかを理解し ていく Step 3：お客さまを知る活動を仕組み化する • 自分だけでなく、チームのみんなでお客さまを知る仕組みを作る Step 4：隣接組織を知り、コミュニケーションを取る • 自チームの開発が影響する他部署の構造・業務フローを把握する • 特別なことではなく、意識して関係性を築いていくこと Step 5：戦略・ロードマップ・各種計画に関わる • 自分自身で、あるいは上長と一緒に、事業ロードマップや開発計画の策定に踏み込んで いく
39. 🔚