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
エンジニアが事業をつくる強み
Search
Masato Ishigaki / 石垣雅人
March 11, 2020
Technology
1
530
エンジニアが事業をつくる強み
2020/03/11 役員と先輩社員が語る!「IT企業で生きぬく人材とは」
Masato Ishigaki / 石垣雅人
March 11, 2020
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
7
16k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
5
1.9k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
3
210
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
5
600
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
8
1.7k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.4k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.5k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
29
22k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
11
2.9k
Other Decks in Technology
See All in Technology
AI エージェントと考え直すデータ基盤
na0
20
7.9k
shake-upを科学する
rsakata
7
1k
QuickSight SPICE の効果的な運用戦略~S3 + Athena 構成での実践ノウハウ~/quicksight-spice-s3-athena-best-practices
emiki
0
290
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
120
ソフトウェアQAがハードウェアの人になったの
mineo_matsuya
3
200
Copilot coding agentにベットしたいCTOが開発組織で取り組んだこと / GitHub Copilot coding agent in Team
tnir
0
200
Four Keysから始める信頼性の改善 - SRE NEXT 2025
ozakikota
0
420
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
伴走から自律へ: 形式知へと導くSREイネーブリングによる プロダクトチームの信頼性オーナーシップ向上 / SRE NEXT 2025
visional_engineering_and_design
3
460
Maintainer Meetupで「生の声」を聞く ~講演だけじゃないKubeCon
logica0419
0
110
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
670
三視点LLMによる複数観点レビュー
mhlyc
0
230
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
96
6.1k
GraphQLとの向き合い方2022年版
quramy
49
14k
Site-Speed That Sticks
csswizardry
10
700
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Producing Creativity
orderedlist
PRO
346
40k
4 Signs Your Business is Dying
shpigford
184
22k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Transcript
1 エンジニアが事業をつくる強み ビジネス職・エンジニア職 March 11, 2020
2 About me Masato Ishigaki 総合トップ開発部 部長 2015年度 新卒エンジニア入社 DMMにおけるアカウント(ID)、認証(Auth)
周りのプロダクトオーナーを経て、 2018年7月にリードナーチャリング領域を強化するチームの立ち上げを行う。 2020年3月には、DMMの総合トップなどを管轄する総合トップ開発部の部長を務 める。 現在はアプリプラットフォーム基盤の プロダクトオーナーにも 従事 i35-267 @i35_267 i35-267
3 Agenda About DMM.com 入社してからの略歴 業務内容・1日の流れ プロダクト開発の流れ エンジニアが事業をつくる強み
入社してからの略歴 Engineer EM ( Engineering Manager ) 部長 GEM ・Product
Management ・Human Management ・Technology Management ・Project Management (Agile) (エンジニアキャリア例) ・Engineering PO ( Product Owner ) 新卒1年目 : Engineer - Engineering 新卒2年目 : Engineer - Engineering - Project Management (Scrum Master) - Technology Management 新卒3年目 : Product Owner(略 : PO) - Product Management - Project Management 新卒4年目 : PO + チーム立ち上げ - Product Management - HumanManagement - Project Management 新卒5年目 : 部長 + PO + 事業立ち上げ + 部立ち上げ - Product Management - HumanManagement - Project Management 役割の領域 役割の領域
業務内容 1. Product Management a. KPIの数値、データ分析、仮説立案、予算 2. Human Management(Team) a.
組織戦略、1on1、評価、キャリア、採用 3. Project Management a. アジャイル開発、プロジェクト管理 4. Technology Management a. アーキテクチャ、組織構造、サーバーコスト 比重 施策のROIを考えたり、SQLを書いてデータ 分析したり、ユーザークレームを分析したり。 TEAM - PO : 1名(私) - SM : 1名 - UI / UX Designer : 2名 - iOS/Android Engineer: 3名 - Backend Engineer: 5 - Growth / Marketing : 1名 部 - 30名程度 如何に早く 正確にプロダクトを作るか 事業モデルとアーキテクチャの質とスピードの部分 アーキテクチャと組織構造の関係性( Ex. コンウェイの法則) 4つの領域を網羅的に
11:00 13:00 15:00 16:00 19:00 出社 採用面接 / 会食 KPIの数値確認
特に施策実行前後は、相関指標含めてよく観察 ランチ 1日の流れ 1on1 キャリア、困りごと スクラムイベント 振り返り 次イテレーションで何をするか デイリースクラム プロダクトバックログリファインメント いわゆる施策や開発の優先順位を常にリファクタリング データ分析をしたり MTGをしたり 施策A 施策B 施策C 施策D
入力 input 出力 output 事業モデル フィードバック feedback KPI 選択と集中 1,000,000円
10,000円 10人 施策A 施策B 施策C 施策D ROI , etc... 課題可視化 t 施策A 施策B 施策C 施策D Milestone PT : 10h WT : 2h %C/A : 0% PT : 1h WT : 0h %C/A : 70% PT : 1h WT : 0h %C/A : 70% 12h 84h 100h 12h 12h KPI選定 (課題) 仮説 検証 計測 施策A 施策B 1/15 2/1 2/15 3/1 ・どうやって収益 / 効果をあげている? ・システム理論的な事業理解 ・事業構造の要素分解 → KPI ・数値可視化による課題抽出 ・費用対効果が高い KPIの選定 ・課題に対して仮説/施策の立案 ・ROIやコストなどの複合的な優先順位 ・ProductBacklog ・施策のスケジューリング→Milestone ・常に施策の優先順位についてリファクタリング ・ユーザーからのFBによって施策のPoCは見直す。またはやめる ・KPIサイクルの回転数を高速にあげる ・必ず成功する施策はわからない。 ・A/Bテストなどで失敗許容性を担保しながら、数多くの施策を実行する ・そのためには、検証→測定→学習(Mesure→Lean)の部分を重視する ・常にプロセスを定量的に可視化 → VSM,etc... ・ボトルネックを洗い出し、開発の高速化を行う ・プロセス → アーキテクチャ / 組織構造 / 開発プロセス / 調整量
8 誰も成功する施策はわからない。 しかし、成功する確率は、失敗を繰り返し、データによる学習を繰り返せば、精度は上げら れる = 正しく失敗できる環境を作り出す + 開発を圧倒的に早く回すことがで きれば、事業スケールの一番の近道となる。 短期的に集中して、短期的に施策を実行して、数字を動かす作業を繰り返す
ソフトウェア開発において重要なこと
KPI 1,000,000円 10,000円 10人 施策A 施策B 施策C 施策D KPI選定 (課題)
仮説 検証 計測 施策A 施策B user 何を作るか、なぜ作るのか Product Management どう作るか Technology / Human / Project Management 事業責任者がエンジニアリングを理解していると、すべてがコントロール可能に
10 リードタイムを「1/3」に短縮できれば、 1年間で4回リリースを12回 (3倍) にすることができる ※ 2年間だったら、8回 → 24回 ※3年間だったら、12回
→ 36回 .... 開発リードタイムの重要性
何を作るか、なぜ作るのか Product Management どう作るか Technology / Human / Project Management
ビジネスサイド? エンジニアサイド? ≠
エンジニアキャリア engineer career Engineer 武器をどう使う 事業を伸ばす(戦士) 武器を作る 武器を売る(武器商人) t t
武器 (技術) の使い方を習得して 武装して強く戦えるようにする XaaS化との戦い Ex. MLエンジニア vs AWS,GCP AutoML 市場との戦い 事業知識とそれに適した 武器の使い方の豊富な知識