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
73
スケールする会社を支える開発組織のマネジメント
弁護士ドットコム
November 02, 2016
Tweet
Share
More Decks by 弁護士ドットコム
See All by 弁護士ドットコム
クラウドサインにおけるプロダクトマネージャーの役割と開発プロセス / 20240410_cloudsign-PdM
bengo4com
1
780
実務への応用例から考える 変更に強いオブジェクト指向設計 / 20240324-ooc2024
bengo4com
9
9.1k
GenAI in Production~生成AIに君がみた光と、僕がみた希望~ / 20240215_devsumi2024
bengo4com
1
2.7k
弁護士ドットコム株式会社 プロダクト組織紹介スライド
bengo4com
1
550
APIテスト導入から2年。アジャイルな組織で見えてきたmabl活用の道
bengo4com
1
2k
走りながらエンジンを交換する ~ 大規模プロダクトを成長させつつVue3にするには / 20231028
bengo4com
5
4k
私たちが "Customer Reliability Engineering" を手に入れるまで / 20231024
bengo4com
0
5.8k
プレビュー機能で考える、コンテキスト間の依存関係を制御したクラス設計
bengo4com
1
590
クラウドサイン事業本部 プロダクト組織 紹介資料
bengo4com
0
2k
Other Decks in Technology
See All in Technology
ExaDB-D dbaascli で出来ること
oracle4engineer
PRO
0
2.1k
【NW X Security JAWS#3】L3-4:AWS環境のIPv6移行に向けて知っておきたいこと
shotashiratori
1
710
.NET Profiler in 2024.
kkamegawa
2
2.4k
One engineer company with Ruby on Rails
rstankov
2
460
LayerXにおけるLLMプロダクト開発の今までとこれから
layerx
PRO
4
1.3k
今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
devops_vtj
21
6.2k
高専で制御を、大学でセンシングを学び、次は脳みそ
satoshirobatofujimoto
0
120
cgroup v2 で何が変わったのか / TechFeed Experts Night #28
tenforward
2
110
Azureの基本的な権限管理の勉強会
yhana
1
2.2k
パスワードを保存しますか?
hanacchi
0
160
障害対応をちょっとずつよくしていくための 演習の作りかた
heleeen
1
1.8k
いいたいことちゃんという
tkengo
0
260
Featured
See All Featured
It's Worth the Effort
3n
180
27k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Creatively Recalculating Your Daily Design Routine
revolveconf
211
11k
4 Signs Your Business is Dying
shpigford
176
21k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
9
1.3k
Infographics Made Easy
chrislema
238
18k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
358
22k
Statistics for Hackers
jakevdp
790
220k
The Invisible Customer
myddelton
114
12k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
22
1.4k
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: 引き出しを増やす • 課題は会社によって千差万別、他社の事 例がそのまま使えるわけではない • でも事例を知っておくと、見通しや対策が 立てやすい • ということでこの後の懇親会で色々お話し
ましょう