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
弁護士ドットコム
November 02, 2016
Technology
0
99
スケールする会社を支える開発組織のマネジメント
弁護士ドットコム
November 02, 2016
Tweet
Share
More Decks by 弁護士ドットコム
See All by 弁護士ドットコム
新規プロダクト開発、AIでどう変わった? #デザインエンジニアMeetup
bengo4com
0
460
TypeScript をより型安全に扱うプラクティス #TSKaigi #TSKaigi2025_kataritai
bengo4com
0
2.1k
入門 ESlint Typegen #TSKaigi #TSKaigi2025_kataritai
bengo4com
0
2k
VueUseから学ぶ実践TypeScript #TSKaigi #TSKaigi2025
bengo4com
3
5.5k
技術的負債解消の取り組みと専門チームのお話 #技術的負債_Findy
bengo4com
1
1.5k
アクセシブルなマークアップの上に成り立つユーザーファーストなドロップダウンメニューの実装 / 20250127_cloudsign_User1st_FE
bengo4com
2
1.5k
フロントエンド設計にモブ設計を導入してみた / 20241212_cloudsign_TechFrontMeetup
bengo4com
1
2.1k
サービスの拡大に伴うオペレーション課題に立ち向かう / 20241128_cloudsign_pdm
bengo4com
0
1.1k
QAEチームが辿った3年 ボクらが改善業務にスクラムを選んだワケ / 20241108_cloudsign_ques23
bengo4com
0
1.8k
Other Decks in Technology
See All in Technology
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
190
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
38k
Cloud Native Scalability for Internal Developer Platforms
hhiroshell
2
460
脅威をモデリングしてMCPのセキュリティ対策を考えよう
flatt_security
4
1.7k
Whats_new_in_Podman_and_CRI-O_2025-06
orimanabu
3
180
Tenstorrent 開発者プログラム
tenstorrent_japan
0
310
自分を理解するAI時代の準備 〜マイプロフィールMCPの実装〜
edo_m18
0
110
「規約、知識、オペレーション」から考える中規模以上の開発組織のCursorルールの 考え方・育て方 / Cursor Rules for Coding Styles, Domain Knowledges and Operations
yuitosato
6
1.8k
Kotlinで学ぶ 代数的データ型
ysknsid25
5
1.1k
TODAY 看世界(?) 是我們在看扣啦!
line_developers_tw
PRO
0
210
白金鉱業Meetup_Vol.19_PoCはデモで語れ!顧客の本音とインサイトを引き出すソリューション構築
brainpadpr
2
390
CIでのgolangci-lintの実行を約90%削減した話
kazukihayase
0
280
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
41
7.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Bash Introduction
62gerente
614
210k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Language of Interfaces
destraynor
158
25k
How GitHub (no longer) Works
holman
314
140k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Fireside Chat
paigeccino
37
3.5k
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: 引き出しを増やす • 課題は会社によって千差万別、他社の事 例がそのまま使えるわけではない • でも事例を知っておくと、見通しや対策が 立てやすい • ということでこの後の懇親会で色々お話し
ましょう