投下資本に⽐例して成⻑できる 開発組織体制について @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に異動しても同じパフォーマンスを維持できる • 複数チームを束ねるトップがいなくなってもチーム内トップが昇格し やすい • 中途採⽤に求める要件を持つ⼈材が新卒から成⻑できるように 

ジョブローテーションは悪か • ツラミある • 強制異動、転勤を伴う • ⼤幅に変わるもの(エンジニア=>⼈事) • ツラミ少ない • 本⼈の意欲あり、元に戻れる • 期限がある(評価を猶予、経歴ロンダリングを防ぐ) 

まとめ: 投下資本に⽐例して成⻑するには • ロール、組織構造を戦略的に整理する • (極⼒)機能ベースの組織に • ⾃⼰⽣産、再帰的な組織を⽬指す