スタートアップにおける組織デザインの要点
こういう風に考えながら組織のデザインを考えているよ、というお話
組織デザインの基本
そもそも組織デザインとはなにか？これにはすでに答えがある。
ベン・ホロウィッツによると
組織デザインで第一に覚えておくべきルールは、すべての組織デザインは悪いということだ。あらゆる組織デザインは、会社のある部分のコミュニケーションを犠牲にすることによって、他部分を改善する。
また
この場合、組織デザインを社内コミュニケーションのアーキテクチャとして考えるとよい。特定の社員間のコミュニケーションをスムーズにしたいと思えば彼らをひとりのマネジャーの下に所属させるのが、一番間違いない方法だ。逆に組織図で離れた位置にあればあるほど、そこに所属する社員間のコミュニケーションは疎遠になりがちだ。
組織デザインはコミュニケーション設計と同義だ。こう考えるとなにが必要でなにが必要でないかが見えてくる。
要点は3つある。
最もコミュニケーションを密にしたい部分をグループにする
グループに求められる意思決定を明らかにし、その責任者を置く
組織図に反映されなかったコミュニケーションをケアする
2番目はaccoutablityと言い換えても良い、そのグループには達成する責務があり、なんらかの権限が移譲され、それを説明のつく状態（accoutable）にする必要がある。『HARD THINGS』では、責任者を決めるのは「コミュニケーションと意思決定の優先度を決めた後」としているが、人材と時間のリソースに限りがあるスタートアップにおいてこれが現実でないことのほうが多いだろうし、実際は同時に考えることのほうが多いだろう。
機能別組織と事業部制組織
「最もコミュニケーションを密にしたい」グループ、これは自明ではない。例えば、iOSエンジニアであれば「iOSグループ」という形にするかもしれないし、あるいは「グロースハックグループ」にするかもしれない。
前者は
他のiOSエンジニアとのコミュニケーションが密になる
技術のサイロ化がされにくく、技術を深堀りやすい
テックブログ、イベントのような発信がしやすい
tech leadあるいはengineering managerというキャリアパスを作りやすい
後者は
PdMやデザイナーとのコミュニケーションが密になる
KPIが明確であり、開発チーム一体となってプロダクトに向き合う雰囲気が作られる
フルスタックに開発する裁量が与えられやすい
エンジニアからproduct managerあるいはgrowth hackerというキャリアパスを作りやすい
当社ではプロダクトに向き合うことがなにより大事だから横串の組織にする？それほど簡単な話ではない。技術的負債は「一瞬で」蓄積し複利で効いてくるため、2週間も経てば事業計画の足を引っ張るようになる。
組織図上、両方のグループをつくるという手段もある（マトリクス制）、この場合、two-in-the-boxという組織的負債が生まれる。accoutabilityという点でbad practiceだし、コミュニケーションという点でもbad practiceである。
機能別にすると長期的影響、横串にすると短期的影響を出しやすいので、長期において良いエンジニア組織を作っていきたいなら、例えば組織図は機能別にして日々の稼働は横串のOKRチームをつくるのが良いプラクティスだろう。逆に、そもそもプロダクトに向き合う組織文化がなく放置すると職種ごとのサイロ化が進みそうだという場合は、組織図上で横串にしてしまうというのもありうる。
わかっていることはどう組織をデザインしても両方の仕事は存在するということだ。組織図に反映されない重要な意思決定とコミュニケーションがあり、正式なレポートラインを利用せずにケアする有効な手段がないなら、それは組織図にきちんと反映したほうが良い。また、あらゆる問題よりも優先的に解決したい問題があるなら、当然それは組織図に反映したほうが良い。
コミュニケーションのキャパシティ
エンジニアの組織を作るのは重要そうだ、ではどの粒度でまとめるべきだろうか。本部（事業部と並べる）にすべきか、本部以下の部にすべきだろうか（それより細かくするともう機能別組織ではないだろう）。
これは一概に言えないが、グループの人数には注意を配るべきだ。効果的にコミュニケーションできる人数には限界がある。
結論としてはコミュニケーション人数は3〜8人程度が適切である。10人を超えていたら完全にダメであり、コミュニケーションは機能しない。これはCEOですら例外ではない。
組織的負債を定量的に測る一般的な手法はないが、技術的負債を測る便利な計算方法はある。例えばcyclomatic complexityがそれだ。これはただの指標で負債を総合的に判断しないがこういう指標は有用だ。
とりあえず簡単な計算で自社の状況を確かめてみよう。
組織図を見る
マネージャーの配下に何人いるかを数える
5を超えていたらyellow、10人を超えていたらredにする
yellowな人の数とredな人の数を数える
メンバーの人数は平均的には5人程度にすると良いだろう。これを厳密に守ると、1人のシニアマネージャー、5人のマネージャー、25人のメンバー、で合計31人の部署ができあがる。この人数なら教室一つ分に収まる程度でコミュニケーションは比較的容易だし、仮にマネージャーが何らかの理由で一人いなくなっても短期的にはシニアマネージャーが兼任できる（シニアマネージャーは4人のマネージャーと5人グループメンバーの合計9人をみればよい）。他の職種の部署と組み合わせて事業部を作っても、31 * 5 + 1 = 156人程度でコミュニケーション不全を起こさない程度の人数である（というかこれはダンバー数である）。逆にこれを超える人数になってしまうなら、事業部を分けるフェーズと判断できる。
その他、例えばHR部門（特に採用部門）は組織図を反映しないコミュニケーションを取ることが多いのではないかと思う。一人あたりのコミュニケーションしている相手の人数が多すぎるならそれはおそらくリソース不足だろうし、担当者を増やしたほうが良いだろう。
コミュニケーションの距離
組織デザインをコミュニケーションのアーキテクチャと捉えると、組織をヒエラルキーにするのは合理的である。フラットな組織は小規模なら最高に機能するが、絶対にスケールしない。
では、無制限に上下関係を作り続ければよいか。当然NOである。組織図上で離れるとコミュニケーションは疎遠になる。
コミュニケーションのキャパシティを守りつつ限界まで揃えると
1段階上のマネージャー＝6人のグループ
2段階上のマネージャー＝31のグループ
3段階上のマネージャー＝156人のグループ
4段階上のマネージャー＝781人のグループ
こう考えると、3段階までが意思疎通の限界でそれより外はコミュニケーションが機能しない。
事業部＞部＞グループの形を取っているとすれば、ある部署のメンバーはCEO（自分の所属する事業部の責任者がCEOでないなら）あるいは他部署の事業責任者とはコミュニケーションが不通になる可能性が高いといえる。
これをケアすることは重要だが（今の組織デザインが永遠に最適とは限らない）、権限や裁量の観点でも考えてみると良いだろう。LeSSで重要なプラクティスはfeature teamに十分な権限が与えられていることだ。これは組織でも当てはまる。つまり、事業部長に創業期のCEO並に十分な権限と裁量がないのなら、その部署はスタートアップとは思えないほどに窮屈に感じられるだろう。
おわりに
新規事業を行いたい、さてどの部署がもつべきだろうか。開発の部署か、営業の部署か、社長直下か。座組をつくるとは組織をデザインすることであり、コミュニケーションを設計することである。
この記事が気に入ったらサポートをしてみませんか？