Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
エンジニアとマネジメントの距離/Engineering and Management
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
小田中育生
January 25, 2026
Technology
1
140
エンジニアとマネジメントの距離/Engineering and Management
エンジニア向けにマネージャーの意義を解説した資料です。
作者の個人的経験を踏まえ、エンジニアだからこそできるマネジメントについて論じています。
小田中育生
January 25, 2026
Tweet
Share
More Decks by 小田中育生
See All by 小田中育生
飛び出していけ 地球の彼方/A Beginner's Guide to Attending International Conferences
ikuodanaka
0
480
ビギナーであり続ける/beginning
ikuodanaka
3
3k
顧客とユーザーと私/Dancing with customers and users
ikuodanaka
2
1.9k
「アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ」のOKR/The OKR of OKR Guidebook
ikuodanaka
10
1.6k
初学者のためのアジャイルスターターキット/Agile starter kit for beginners
ikuodanaka
21
3.6k
アジャイルトランスフォーメーションが現場にもたらす価値と超えるべきいくつかの壁/Agile transformation and some impediments
ikuodanaka
6
2.6k
Be Agile アジャイルマインドセットでいきいきと働く / be agile and work with a iki-iki spirit
ikuodanaka
6
6.8k
Other Decks in Technology
See All in Technology
エンジニアとして長く走るために気づいた2つのこと_大賀愛一郎
nanaism
0
220
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
12k
2026/01/16_実体験から学ぶ 2025年の失敗と対策_Progate Bar
teba_eleven
1
220
書籍執筆での生成AIの活用
sat
PRO
1
170
Security Hub と出会ってから 1年半が過ぎました
rch850
0
170
困ったCSVファイルの話
mottyzzz
1
350
AI開発の落とし穴 〜馬には乗ってみよAIには添うてみよ〜
sansantech
PRO
2
110
ファインディにおけるフロントエンド技術選定の歴史
puku0x
2
1.6k
SwiftDataを覗き見る
akidon0000
0
300
AI時代にあわせたQA組織戦略
masamiyajiri
1
700
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
6
64k
AWS Network Firewall Proxyで脱Squid運用⁈
nnydtmg
1
160
Featured
See All Featured
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
290
AI: The stuff that nobody shows you
jnunemaker
PRO
2
190
Designing Powerful Visuals for Engaging Learning
tmiket
0
210
Code Review Best Practice
trishagee
74
19k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
430
Scaling GitHub
holman
464
140k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
200
How Software Deployment tools have changed in the past 20 years
geshan
0
31k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
110
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
150
Joys of Absence: A Defence of Solitary Play
codingconduct
1
270
Transcript
©Growth and Living
©Growth and Living 自己紹介 小田中 育生(おだなか いくお) / 株式会社カケハシ SCM
Domain Head of Engineering 株式会社ナビタイムジャパンでVP of Engineeringを務め、2023年10 月にエンジニアリングマネージャーとして株式会社カケハシにジョイ ン。2025年3月よりHead of Engineeringを務め、「しなやかな医療体 験」を実現するべくチームマネジメント、組織開発などに奔走してい る。 Developers Summit 2024 Summer ベストスピーカー賞(2位) Developers CAREER Boost 2024 ベストスピーカー賞(1位) Developers Summit 2025 Summer ベストスピーカー賞(2位, 5位)
©Growth and Living アジェンダ • エンジニアのキャリア分岐点 • マネージャーという選択肢 • マネージャーとしてのキャリア
• エンジニアリングとマネジメント • 見たことのない景色を見にいこう
©Growth and Living エンジニアのキャリア分岐点
©Growth and Living エンジニアのキャリアに存在する大きな分岐 スペシャリストか? マネージャーか? 技術力を高めていき、 直接的な価値創出に貢献するか。 組織・仕組みづくりにコミットし、 影響範囲を拡大していくか。
©Growth and Living かつて存在していた、プログラマ 35歳定年説 管理職になることがほぼ唯一のキャリアアップの選択肢
©Growth and Living 手を動かし続けられる時代になった 2025年現在、組織のフラット化やエンジニア職の地位 確立などの要因により、IC(Individual Contributor)とし てのキャリアも確立。 マネージャーは「昇進」ではなく、数ある役割の中の「機 能の一つ」になりました。
©Growth and Living 多様化するエンジニアの選択肢 https://codezine.jp/ エンジニアキャリア図鑑より テックリード、アーキテクト。 マネージャー以外のキャリアの選択肢。
©Growth and Living マネージャーという選択肢
©Growth and Living 避けられる管理職 一般社員の約 77%が 「管理職になりたくない」 出典: 77%が「管理職になりたくない」【調査レポート】ポジティブな管理職を育てるために人事が押さえたいポイントとは? https://www.jmam.co.jp/hrm/column/0095-kanrishokuchousa.html
©Growth and Living エンジニアの世界でも傾向は同じ IC志望 多くのエンジニアが集まる マネージャー志望 圧倒的に少ない
©Growth and Living なぜマネージャーが選択されないのか 1. 専門性を磨きたい 技術が好きで、もっと深く掘り下げたい 技術者として影響力を広げたい 2. 何をするか不明瞭
仕事の魅力が見えない 会議ばかりに見える エンジニア職でもスキルアップすることで給与が上がるようになった中で、 「何をしているのかわからない」「でも、どうやら大変らしい」マネージャー職に 転身する意義を感じづらい時代になってきている
©Growth and Living では、マネージャーという存在は不要か? 意思決定する。 育成・評価を行う。 チームビルディングしゴールに向かう。 現場と事業を接続する。 マネージャーの仕事は、見えづらいけれども 重要なものです。
©Growth and Living マネージャーとしてのキャリア
©Growth and Living 私の場合 かつて私自身も、 マネージャーになる気はゼロでした。
©Growth and Living 外資系半導体企業での経験 一人で開発するのがとにかく好きだった キャリアのスタートは研究開発。 誰にも邪魔されず、一人で黙々とコードを書き、 システムを作り上げることに没頭。
©Growth and Living テストケース削減のおもしろさ 愚直にテストすると・・・ 9¹⁶ ≈ 1.85 x 10¹⁵
の組合せ 依存関係に着目しテストケース数を圧縮し・・・ 2,000-3,000 の組合せ
©Growth and Living 転職し、カーナビ関連システムの開発へ マップマッチング、並列処理 …… GPS衛星データと道路ネットワークのマッチング。 並列処理によるパフォーマンスチューニング。 難しい技術課題に挑むことが、日々の楽しみ。
©Growth and Living そんなある日のこと
©Growth and Living 10年もののレガシーシステムをリファクタリングする ある時、長年の増改築で複雑化したシステムと対峙。 いわゆる「スパゲッティコード」の解消がミッションに。
©Growth and Living ひるむ私に先輩がかけてくれた言葉 「僕もなんとかしたいと 思ってたんです。 一緒にやりましょう」
©Growth and Living 協働する楽しさ 設計する私と、知見のある先輩 一人では解決できない歴史的経緯も、知識豊富な先 輩とのペア作業で解き明かしていきました。 これが初めて「チームで働く強さ」を感じた瞬間。
©Growth and Living マネージャーへの道が開かれる 「マネージャーにならないか?」
©Growth and Living 自分の中にあった葛藤 協働する中で、人と連携する楽しさ、醍醐味は感じていた。 一方、まだエンジニアとして「やりきった」感覚はない。コードを書くことを手放していいのか? エンジニアリングを 手放すべきか? 自分に 向いているのか?
©Growth and Living 迷ったら、 Go オファーしてもらうこと自体が、貴重な体験。 せっかくだからマネジメントの世界に飛び込む
©Growth and Living たくさんの失敗 チームメンバーの声に耳を傾けようーーと、チームにそもそも何が 期待されているのか?を脇において内向きになりすぎた、 エセ・サーバントリーダーシップ メンバーの Willを汲み取ることができずコンフリクトした経験
©Growth and Living 少しばかりの成功 「一人では成し遂げられない」成果を生み出したとき メンバーが大きく成長を遂げたとき
©Growth and Living
©Growth and Living 一方で 手を動かして、自分で書いたコードが動く喜びからは遠ざかった GASでちょっとした Scriptを作り「作りたい欲」を満たす日々
©Growth and Living エンジニアリングとマネジメント
©Growth and Living これらは全く別の役割なのか (Manager != Engineer) はtrue? false?
©Growth and Living 私はこう考える マネージャーだからこそできる エンジニアリングがある
©Growth and Living 設計のねじれ システムが大きくなっていく中で 大なり小なり設計がねじれていきます
©Growth and Living 設計のねじれ エンジニアとしては、あるべき姿に 設計しなおしたい。
©Growth and Living 設計のねじれ けれども、今のねじれた設計は理由があってそうなっている その理由に向き合わず直しても、またねじれていく
©Growth and Living TO BEだけではなく、 AS ISへもまなざしを持つ AS IS(現状)と TO
BE(あるべき姿)の橋渡し 現状のスキルセットで現実的な解に落とし込むか。 組織を変えて理想に近づけるか。
©Growth and Living 時間軸のエンジニアリング 過去の経緯(ねじれ)を理解し、解消へのロードマップを引く エンジニアとしての経験、ドメインへの理解、そしてマネージャーとしての権限が あるからこそできるアプローチ 過去 負債の発生 現在
背景への理解 解消プラン 未来 あるべき姿 根本解決
©Growth and Living マネージャーとして、構造から設計にアプローチする
©Growth and Living 最大の武器、「翻訳」 Tech Biz
©Growth and Living 翻訳ケーススタディ 1: システムの老朽化とニーズ増加 開発スピード低下 システムが限界を迎えているが、ビジネスニーズは高まっている。 機能追加を強行すると不具合が頻発する、負荷が耐えられないところまできているなどの理由で リアーキテクチャ・リファクタリングを実施する必要がある。
ニーズ増加
©Growth and Living どう伝える? リファクタリングしたいんです これでは、「機能追加を優先して」と返されるだけです。 なぜかというと、リファクタリングにより創出されるビジネス的価値が 伝わらないためです。 6ヶ月後をターゲットにした機能開発ですが、 1ヶ月リアーキテクチャ・リファク
タに集中することで遅延リスクを大幅に低減できます なぜリファクタリングをするのか、その効果は何か どれくらいの期間を要するのかが盛り込まれているため、 機能開発で得られるメリットと天秤にかけて判断しやすくなります
©Growth and Living 翻訳ケーススタディ 2: リリース作業の負担増 リリース作業に時間がかかり、エンジニアが疲弊している。 開発生産性が向上しているためリリース頻度を高めたいが、この状況で頻度だけ上げると 現場の負担が上昇してしまう。 これはバーンアウト、作業ミスによるインシデント発生リスク向上につながる。
©Growth and Living どう伝える? 開発者体験をよくしたいので、リリースフローを省力化したい 開発者体験の向上は重要ですが、エンジニア組織以外の人がこの 言葉を聞くと「エンジニアが楽をしたいだけなのでは?」と誤解するお それがあります。 品質を保った上でリリース頻度を向上させる、開発生産性を向上させるため にはリリース作業を自動化していくことが必要です
品質、リリース頻度、開発生産性といったエンジニア以外にもわかる言葉で 自動化の効果を伝えることで、目指す姿に対して必要なアクションであるということが 伝わります。
©Growth and Living Value Stream Mappingは強力な翻訳ツール
©Growth and Living エンジニア出身のマネージャーだからできること Tech Biz Techの言葉も、 Bizの言葉もわかる。 TechがBizにスムーズに伝わることは、中長期的な価値創出に効く。 Bizの言葉がTechに伝わることで、モチベーション高く目の前の要望に応えられる。
©Growth and Living 見たことのない景色を 見にいこう
©Growth and Living あらためて (Manager != Engineer) はtrue? false?
©Growth and Living エンジニア出身のマネージャーはエンジニアである 対象が「コード」から「組織・ビジネス」に広がった
©Growth and Living 新たな知識・スキルを習得する必要がある 目標設定 組織設計 心理学
©Growth and Living マネジメント領域は、学ぶ環境がある 書籍 コミュニティ
©Growth and Living 難しい。けれど、登る価値のある山。 マネージャーだからこそできる エンジニアリングがある
©Growth and Living 見える景色 一人では成し遂げられない成果 技術的な意思決定で 組織を、世界を変えていく
©Growth and Living それでも、マネージャーの道へ進むのが怖いあなたへ キャリアは不可逆ではない この選択は、後戻りできないものではありません。 マネージャーになったあとエンジニアに戻り、 マネージャーの視点をもっているからこその 貢献で活躍している人を何人も知っています。
©Growth and Living じゃあ、いっちょ やってみっか! そういう人が増えたなら、なによりです。
©Growth and Living ご清聴ありがとうございました