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
投下資本に比例して成長できる開発組織体制について / How To Create Scalab...
Search
Hiromichi NOMATA
August 21, 2021
Technology
1
540
投下資本に比例して成長できる開発組織体制について / How To Create Scalable Development Team
投資家目線での開発チームの作り方
Hiromichi NOMATA
August 21, 2021
Tweet
Share
More Decks by Hiromichi NOMATA
See All by Hiromichi NOMATA
プロダクトと一緒に成長できるMVCフレームワークの使い方 / Adjustable MVC Framework
hiromichinomata
1
490
急にDX言い出した理由と真にDXを実現するために必要なこと / DX Explained
hiromichinomata
1
740
エボルタNEOくん三輪車で学ぶ動くペーパクラフトとバルーン / Evolta NEO Three Wheeled Cycle
hiromichinomata
1
720
ガンダムとザクの構造比較から見る動くガンダムを手に入れるために必要なこと / Gundam vs Zaku
hiromichinomata
1
720
絵文字扇子の作り方 / How to create Emoji Sensu
hiromichinomata
1
680
Ruby 2.7クイズ / Ruby 2.7 Quiz
hiromichinomata
1
440
クララと学ぶbash / Learn bash with Clara
hiromichinomata
2
64
クララと学ぶプログラミング / Learn Programming with Clara
hiromichinomata
1
140
Other Decks in Technology
See All in Technology
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
73k
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.3k
生成AI時代にこそ求められるSRE / SRE for Gen AI era
ymotongpoo
4
2k
変化するコーディングエージェントとの現実的な付き合い方 〜Cursor安定択説と、ツールに依存しない「資産」〜
empitsu
4
1.1k
月間数億レコードのアクセスログ基盤を無停止・低コストでAWS移行せよ!アプリケーションエンジニアのSREチャレンジ💪
miyamu
0
690
Azure SRE Agent x PagerDutyによる近未来インシデント対応への期待 / The Future of Incident Response: Azure SRE Agent x PagerDuty
aeonpeople
0
280
SMTP完全に理解した ✉️
yamatai1212
0
180
データ民主化のための LLM 活用状況と課題紹介(IVRy の場合)
wxyzzz
2
600
AI時代、1年目エンジニアの悩み
jin4
1
150
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
17k
2026年、サーバーレスの現在地 -「制約と戦う技術」から「当たり前の実行基盤」へ- /serverless2026
slsops
2
160
ZOZOにおけるAI活用の現在 ~開発組織全体での取り組みと試行錯誤~
zozotech
PRO
4
3.8k
Featured
See All Featured
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
350
Visualization
eitanlees
150
17k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
150
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
310
Balancing Empowerment & Direction
lara
5
880
YesSQL, Process and Tooling at Scale
rocio
174
15k
How to Think Like a Performance Engineer
csswizardry
28
2.4k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.6k
A Tale of Four Properties
chriscoyier
162
24k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
0
100
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
77
Transcript
投下資本に⽐例して成⻑できる 開発組織体制について @hiromichinomata
組織の話の前提 • ソフトウェア開発。IT企業 • 数⼗⼈以上
株式会社の⽬的とは • 多くの株式会社は利益を出すのが⽬的(例外: ESG投資) • 投資家のお⾦を増やす必要がある • 利益だけでなく利益率も意識 • 短期でなく持続的アウトプット
開発組織の⽬的とは • チャレンジの最⼤化 • 読めない新規事業は少ない⼈数でまわるように • 成⻑性が⾒込める事業には⼈数を投下 • (衰退する事業は⼈数を減らす)
スケールする組織とは何か? • 明確なリーダーがいる組織? • 裁量がある組織? • 技術的チャレンジができる組織? • オンオフがしっかりしている組織? •
⼈⽉の神話
スケールする組織とは何か? • ロールが明確、構造が整理されている組織(Team Topologies) • (極⼒)機能ベースの組織 • ⾃⼰⽣産、再帰的な組織
Team Topologiesの類型 • ワンマン社⻑ • マネージャー多すぎパターン • 社内フリーランスパターン
Bad: ワンマン社⻑パターン • マネージャー1⼈に数⼗⼈部下 • 優秀なプレイヤーだった⼈が陥りやすい • 権限委譲できない
Bad: マネージャー多すぎパターン • 1マネージャーに部下0~数⼈ • 管理する⼈ばかりで仕事が進まない • キャリアパスがマネージャーしかないと陥りやすい
Bad?: 社内フリーランスパターン • ティール組織 • 社内通貨制度(アメーバ経営) • コンサル、⼠業
適切なSpan of Controlとは • ⼀般的には5〜9⼈と⾔われることが多い • ⼀⽅、⼯事現場とソフトウェア開発は違う。デジタルは集計やトラッ キングに有利 • ⾃⾛できる⼈を採⽤できればマネジメントの9割は終わっている
機能ベース vs 職種ベース • 機能ベース: プロダクトA、プロダクトB、プロダクトC... • 1つのことに集中しやすい • R&Dに近い部分(機械学習、検索基盤)とは相性が悪い
• 職種ベース: 開発部、営業部、⼈事... • ハードウェアではメリットがあることも(⽣産はオフショア) • 隣の部署は別の会社
組織構造とコードの構造は 1 : 1 に • コンウェイの法則: システムの構造は組織構造に近づく • Bad:
⼀⼈の担当が複数のマイクロサービスを担当 • Bad: チームは分かれているのに分割されていないモノリスを共⽤ • 必ずしもマイクロサービスにしなくても良い(モジュラーモノリス) • 逆コンウェイ戦略: ⽣産性の⾼い組織構造をあらかじめ定義すること でシステムの構造をコントロールする
スケールするロール戦略 • 既存事業が成⻑したがチーム分割できない • 分割したいがチームAのxxさんと同じ⼈がチームBにいない • 既存事業を縮⼩してつらみ • 今まではxxをやるだけだったのに苦⼿なooまでやる必要がある •
第⼆創業がうまくいかない • 職種が細分化された結果フルスタックエンジニアが不在
よくあるエンジニア、デザイナー求⼈像 • PM不在の組織で「事業のわかるエンジニア」がいない • SPAゴリゴリのサイトでフロントエンドもバックエンドもわかる⼈が 欲しい • デザイナーがプロジェクト兼業の組織でエンジニアがFigmaでのUI作 成も兼任 •
UX重視のサービスでデザイナーがPM兼任
評価制度は経営者の意思表示 • ⼈それぞれキャリアパスがある • 転職しやすい業界は会社特有スキルを上げるモチベーションが低い • エンジニアの求⼈倍率は10倍 • 要件を⾜して成⽴するビジネスもありだが腹をくくる必要がある •
マネージャーとスペシャリストのパスを⽤意 • 単⼀専⾨性とフルスタック性を評価
再現性、再帰性のある組織構造 • チームAからチームBに異動しても同じパフォーマンスを維持できる • 複数チームを束ねるトップがいなくなってもチーム内トップが昇格し やすい • 中途採⽤に求める要件を持つ⼈材が新卒から成⻑できるように
ジョブローテーションは悪か • ツラミある • 強制異動、転勤を伴う • ⼤幅に変わるもの(エンジニア=>⼈事) • ツラミ少ない •
本⼈の意欲あり、元に戻れる • 期限がある(評価を猶予、経歴ロンダリングを防ぐ)
まとめ: 投下資本に⽐例して成⻑するには • ロール、組織構造を戦略的に整理する • (極⼒)機能ベースの組織に • ⾃⼰⽣産、再帰的な組織を⽬指す