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
800
実務への応用例から考える 変更に強いオブジェクト指向設計 / 20240324-ooc2024
bengo4com
9
9.1k
GenAI in Production~生成AIに君がみた光と、僕がみた希望~ / 20240215_devsumi2024
bengo4com
1
2.8k
弁護士ドットコム株式会社 プロダクト組織紹介スライド
bengo4com
1
560
APIテスト導入から2年。アジャイルな組織で見えてきたmabl活用の道
bengo4com
1
2k
走りながらエンジンを交換する ~ 大規模プロダクトを成長させつつVue3にするには / 20231028
bengo4com
5
4.1k
私たちが "Customer Reliability Engineering" を手に入れるまで / 20231024
bengo4com
0
5.8k
プレビュー機能で考える、コンテキスト間の依存関係を制御したクラス設計
bengo4com
1
600
クラウドサイン事業本部 プロダクト組織 紹介資料
bengo4com
0
2.1k
Other Decks in Technology
See All in Technology
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
130
DevRelによる信頼構築とデータ駆動で変わるエンジニア採用 / DevRel Trust Building to Data Driven Engineering Hiring
bobtani
1
120
知識と実践を紡ぐGenAI / Connecting Knowledge and experience with GenAI
aki_moon
2
120
Documentação de Produtos: Artefatos essenciais na prática
rigolon
1
270
#phpconkagawa レガシーコードにもオブザーバビリティを 〜少しずつ始めるサービス監視〜
yamato_sorariku
0
480
テストコードを書きながらCompose Multiplatformを乗りこなす
subroh0508
0
110
M5stackで使用できるpHセンサの開発
shinrinakamura
1
300
20240509 CloudWatch でいろいろなものを監視してみよう
masaruogura
1
110
AWSやJAWS-UGとの出会いを振り返る
yoyoyopg
1
200
LLM評価の落とし穴~開発者目線で気をつけるポイント~
rishigami
8
2.1k
AWS Observability ベストプラクティス 大紹介
o11yfes2023
0
130
コードファーストの考え方。 Amplify Gen2から学ぶAWS次世代のWeb開発体験
yoshiitaka
2
580
Featured
See All Featured
How to Ace a Technical Interview
jacobian
273
22k
Documentation Writing (for coders)
carmenintech
60
4k
A Philosophy of Restraint
colly
197
16k
Producing Creativity
orderedlist
PRO
338
39k
Become a Pro
speakerdeck
PRO
13
4.6k
Done Done
chrislema
178
15k
Git: the NoSQL Database
bkeepers
PRO
423
63k
A Modern Web Designer's Workflow
chriscoyier
689
190k
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
Agile that works and the tools we love
rasmusluckow
325
20k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
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: 引き出しを増やす • 課題は会社によって千差万別、他社の事 例がそのまま使えるわけではない • でも事例を知っておくと、見通しや対策が 立てやすい • ということでこの後の懇親会で色々お話し
ましょう