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
housuke
November 07, 2016
Programming
8
3.9k
スケールする会社を支える開発組織のマネジメント
housuke
November 07, 2016
Tweet
Share
More Decks by housuke
See All by housuke
20180515_ブロックチェーンの基礎からスマートコントラクト等の応用まで
housuke
0
430
Other Decks in Programming
See All in Programming
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
200
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
590
Introduction to Git & GitHub
latte72
0
120
AI OCR API on Lambdaを Datadogで可視化してみた
nealle
0
180
AIエージェント開発、DevOps and LLMOps
ymd65536
1
340
kiroでゲームを作ってみた
iriikeita
0
180
サーバーサイドのビルド時間87倍高速化
plaidtech
PRO
0
450
デザインシステムが必須の時代に
yosuke_furukawa
PRO
2
100
Constant integer division faster than compiler-generated code
herumi
2
690
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
A Gopher's Guide to Vibe Coding
danicat
0
170
物語を動かす行動"量" #エンジニアニメ
konifar
14
5.4k
Featured
See All Featured
Gamification - CAS2011
davidbonilla
81
5.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.4k
The Art of Programming - Codeland 2020
erikaheidi
55
13k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Navigating Team Friction
lara
189
15k
Writing Fast Ruby
sferik
628
62k
Making the Leap to Tech Lead
cromwellryan
134
9.5k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Typedesign – Prime Four
hannesfritz
42
2.8k
Thoughts on Productivity
jonyablonski
69
4.8k
Transcript
スケールする会社を支える 開発組織のマネジメント 2016/11/02
自己紹介 • 市橋@技術部部長 CTO • 略歴 ◦ コンサルティング会社で5年 ◦ 共同創業した会社で3年
◦ 弁護士ドットコムで3年
入社時@2014年頭 • 社員数 ◦ 約20名 • エンジニア ◦ 約5名
課題: カウボーイスタイル開発 優先度付け の不在 • 依頼開発がエンジニア個人に飛び交う • 全てのタスクが最優先 開発ルール の不在
• masterにcommitしてpush • RedmineやJenkinsはあれど使っていない 貧弱な 開発環境 • テストサーバー1台を皆で共有 • 画像の表示確認・DB変更で死ぬ
対策: 開発プロセスの整備 開発ルール の不在 優先度付け の不在 貧弱な 開発環境 開発ルール 策定
全社での 優先度付け ローカル開発 環境の整備 • スプリント毎に全社的にタスク を優先度判断 • スクラム開発の本格導入 • Redmine/Gitブランチルール /Jenkins運用整備 • Vagrant/Ansibleの整備
上場後@2015年頭 • 社員数 ◦ 約40名 • エンジニア ◦ 約10名
課題: 人数増加にともなう混乱 チーム肥大化 と設計の混乱 • ピザ2枚ではまかなえない人数で一体感が薄れる • 属人的な設計方針の違いで品質にも影響 評価制度の ミスマッチ
• 目標を立ててもビジネス要件で事後修正の嵐 • 「何が評価されるのか」も曖昧に 顔と名前の 不一致 • 入社ペースが加速して月に5〜6名入社 • 他部署が中で何をやっているかも見えにくく
対策: スケールする組織へ 行動指針/ 評価制度 チーム分割/ Tech Lead シャッフル ランチ /BeerBash
• max8名程度にチームを分割 • Tech Leadを置いて設計面で の品質を担保 • 「エンジニア行動指針」を策定 し、それに基づく評価制度に • 4人組をランダムに作ってラン チ代支援 • オフィスで軽い飲み会 評価制度の ミスマッチ チーム肥大化 と設計の混乱 顔と名前の 不一致
最近@2016年 • 社員数 ◦ 約100名 • エンジニア ◦ 約15名
課題: はざまに落ちるボール 責任所在が 不明確 • 良く言えば臨機応変、悪く言えば現場任せ • ビジネス/開発側でお見合いするケースも プロダクトの 担当数増加
• 上場後も新規事業を続々と展開 • 弁コムをやりつつ片手間には見れない規模に 技術的負債の 蓄積 • 独自の「20%ルール」で対応していた • 大規模なものは対応し切れず障害も
対策: チーム役割分担の明確化 チームの 再編成 プロダクト オーナー チーム SREチーム 強化 •
ビジネス・エンジニア・デザイ ナーの3人1チームで責任を持 つ • 規模を踏まえ1プロダクト = 1 チームに近い形に • プロダクトとは1歩離れて、基 盤整備に専念 プロダクトの 担当数増加 責任所在が 不明確 技術的負債の 蓄積
いろいろあったけど、結局 スケールする会社を支える 開発組織のマネジメント ってなんだ?
開発組織のマネジメント対象領域 with 社外 with 経営層 with 他部署 プロダクト アーキ テクチャ
開発 プロセス 人材/組織 技術広報・ブランディン グ 予算・採用・スケジュー ルの説明責任 エンジニア的文化の 相互理解 コアバリュー・ロードマッ プ・カスタマージャーニー マップ 開発言語・フレームワー ク・ミドルウェア・XaaSの 技術選定 Redmine・GitHub・Jenki ns・Slack・ChatOps 採用・教育・評価 組織体制 開発組織外とのコミュニケーション プロダクト・サービス開発
領域の重みはライフサイクルによって変わる http://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-aws
重点領域例 (実際は会社/プロダクトにより異なる) http://www.slideshare.net/HayatoKiriyama/aws-startup-security-talks-aws with 社外 with 経営層 with 他部署 プロダクト
アーキ テクチャ 開発 プロセス 人材/組織
大事なこと1: 解決しない • 課題はあるのか? 存在しない課題を解決してはいないか? • 本当に課題なのか? 誰にとっての・どれ程の課題か? • 今やるべき課題なのか?
「やった方がいい」程度でないか?
大事なこと2: アンテナを張る • 課題が大きい程、認識→対策→解決には 時間がかかる • 兆候にアンテナを張って、「ノイズ」か「シグ ナル」かを見極めよう • 3回起きたら偶然ではない・倍になったらど
うなるか
大事なこと3: 引き出しを増やす • 課題は会社によって千差万別、他社の事 例がそのまま使えるわけではない • でも事例を知っておくと、見通しや対策が 立てやすい • ということでこの後の懇親会で色々お話し
ましょう