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
71
スケールする会社を支える開発組織のマネジメント
弁護士ドットコム
November 02, 2016
Tweet
Share
More Decks by 弁護士ドットコム
See All by 弁護士ドットコム
クラウドサインにおけるプロダクトマネージャーの役割と開発プロセス / 20240410_cloudsign-PdM
bengo4com
1
680
実務への応用例から考える 変更に強いオブジェクト指向設計 / 20240324-ooc2024
bengo4com
9
8.8k
GenAI in Production~生成AIに君がみた光と、僕がみた希望~ / 20240215_devsumi2024
bengo4com
1
2.7k
弁護士ドットコム株式会社 プロダクト組織紹介スライド
bengo4com
1
500
APIテスト導入から2年。アジャイルな組織で見えてきたmabl活用の道
bengo4com
1
2k
走りながらエンジンを交換する ~ 大規模プロダクトを成長させつつVue3にするには / 20231028
bengo4com
5
3.9k
私たちが "Customer Reliability Engineering" を手に入れるまで / 20231024
bengo4com
0
5.7k
プレビュー機能で考える、コンテキスト間の依存関係を制御したクラス設計
bengo4com
1
570
クラウドサイン事業本部 プロダクト組織 紹介資料
bengo4com
0
1.9k
Other Decks in Technology
See All in Technology
アプリがつくるNOT A HOTELブランド
hokuts
1
450
WebアプリケーションにおけるPDOの使い方入門 / phpcon odawara 2024
meihei3
2
430
人間の尊厳、幸福、アクセシビリティ / 第116回「WEB TOUCH MEETING」アクセシビリティSP
nulabinc
PRO
2
180
株式会社EventHub・エンジニア採用資料
eventhub
0
1.9k
オブザーバビリティの Primary Signals
onk
PRO
0
550
〜小さく始めて大きく育てる〜データ分析基盤の開発から活用まで
kniino
0
2k
入社後初めてのタスクでk8sアップグレードした話.pdf
kkato1
1
380
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
jacopen
25
5.9k
Data and AI Governance: Existing Challenges and Emerging Trends
scotthsieh825
0
160
マルチアカウント環境への発見的統制の導入
ch1aki
1
1.3k
Postman v10リリース後を振り返る
nagix
0
130
OpenTelemetry を使ったトレースエグザンプラーの活用 / otel-trace-exemplar
k6s4i53rx
2
640
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
76
41k
Building an army of robots
kneath
300
41k
Side Projects
sachag
451
41k
Gamification - CAS2011
davidbonilla
76
4.6k
StorybookのUI Testing Handbookを読んだ
zakiyama
11
4.6k
The Invisible Customer
myddelton
114
12k
Fantastic passwords and where to find them - at NoRuKo
philnash
36
2.5k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
We Have a Design System, Now What?
morganepeng
42
6.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
356
22k
The Brand Is Dead. Long Live the Brand.
mthomps
48
28k
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: 引き出しを増やす • 課題は会社によって千差万別、他社の事 例がそのまま使えるわけではない • でも事例を知っておくと、見通しや対策が 立てやすい • ということでこの後の懇親会で色々お話し
ましょう