スタートアップにおける組織デザインの構造と影響
続、組織デザイン
もう少し解像度を上げてみよう。
組織デザインのテンプレート
Scaling Teamsより
開発チームの作り方は4通りに分けられるが、これは開発チームに限った話ではなく一般の組織デザインにも利用できる。
事業（Why、なぜやろうとするのか）
プラットフォーム（Who、いわゆる職能）
顧客（Whom、価値を提供する相手は誰か）
機能（How、具体的にやること）
これらに次を加えても良さそうだ。
事業所（Where）
時間軸（When）
思い出すべきこととして、組織デザインに関わらずこれらは全て必要なものである。全ての組織デザインは悪い、できるのは悪を最小化することだけである。
上に6通り書いたが実際にはいくつかは自明である。例えば、組織デザインはコミュニケーションのアーキテクチャであるため、物理的な距離は支配的となる。そのため、普通は事業所で大きく組織を区切るだろうし、これには妥当性がある。
事業と顧客には相関があり、多くの場合には一致する。顧客が変われば事業は変わるだろうし、逆もまたしかり（ターゲットユーザーが変わればプロダクトは変わる）。このため、顧客で組織を作ると事業で組織を作るのと似たような形になる。
時間軸で組織をつくる場合は、例えば短期的と長期的に分けるような場合だが、これも機能で組織をつくる考えに近い（短期的な成果を上げるための機能と、長期的な成果を上げるための機能が一致することは、まあないだろう）。
そう考えていくと実質的に問題になるのは次の3つ
事業
機能
プラットフォーム（職能）
プラットフォームはあとに回して先に事業と機能を考えてみよう。
事業 vs 機能
なんとなく関係がありそうなプロダクトが2つあるとして、売上構造を適当に分解できるとすると
上が事業、左が機能（施策）になる。見て気づくように、全体の売上に対して機能で切るとKPIが掛け算で効いて、事業で切るとKPIが足し算で効く。
(A_ARPU * A_NU * A_RR) + (B_ARPU * B_NU * B_RR)（↑荒っぽい式。）各施策が事業の完全なサブセットである場合は難しくないが（プロダクトAとプロダクトBのARPU改善施策はきっとそれぞれ独立施策だろう）、クロスするような機能の場合は複雑になる。例えばマーケを共通で行なう場合はあるだろうし、インフラを共通化することもあるだろう。このように事業ではなく機能に寄せた方がコストコントロールしやすくなるものはある（上図の「白い四角」ごとに人的コストと金銭的コストがかかる）。
オーナーシップあるいはアカウンタビリティの観点で考えると、「最初に大きく切ったもの」の方が強い裁量と責任を持つことができるから
機能で切った場合、特定のKPIを伸ばすときに効きやすいが、事業ごとの売上をコントロールしづらくなる
事業で切った場合、売上に係る責任を明確にできるが、機能ごとの最適化は不完全になりやすい
こういう性格が出る。
最初に思い出したとおりに、組織デザインは必要悪なのでどちらを優先すべきか（あるいは組織デザイン以外でカバーできるか）の検討が必要となる。
組織デザインとフォーカス
組織デザインは次の順番で考える
最もコミュニケーションを強くしたいグループを集める（すなわち最も優先すべきはなにかを決める）
アカウンタビリティをもたせる（果たすべきこと、それは現実的に達成可能であること、結果として得られるものについて、説明のつく状態にする）
マネージャーを決める
他のグループとのインタラクションを考える（優先されなかったコミュニケーションをケアする）
一番重要かつ難しい議論はなにを優先すべきかだ。これについてはだいたい次の4つを考えると良い。
達成したいこと、ムーンショットを狙うもの
必ず達成しなければならないもの、ハードコミットするもの
現在できていないこと、非常に困難であるもの
今できていること、得意なこと、競争力のあるもの
また、逆の考え方をするというのも良い。
達成度が低くても進捗があれば良いもの
達成度がルーズであっても良いもの
諦めたほうが良いもの
注力しなくても自然とできること
例えば、エンジニアにまつわるトピックだと次が多いだろう。
ムーンショットを狙うもの：良いプロダクトをつくる、開発計画
ハードコミットするもの：コスト管理（サーバ費用）
非常に困難であるもの：採用、文化づくり
得意なこと：プロダクトへの愛
このようなバランス感覚の中でグループを決める。それが大事なものであったとしても、放置してもうまくできるのであれば実はグループをつくるほどではないのかもしれない、こういうものはある。
組織デザインと文化
組織デザインは組織の文化に決定的な影響を与える。
できるだけ実用的に表現するとこうだろうか、企業文化とは明確な指示、目的、ルールがないときに社員がとるデフォルトの行動である。正解が特に示されない状況で最初に選ぶ選択肢、それが文化だ。
重要なことがある、デフォルトは1つだけということだ。2つにはならない。そしてこの1つを組織デザインが決めることがある。
例として、事業が4つ、職種が4つ（企画、営業、デザイン、エンジニア）の組織の物語を考えてみよう。
この組織ではいわゆる事業部制の体制をとった、事業責任者＝マネージャーとして4人のマネージャーがいる組織である。
ふと気づいた。エンジニア組織を作るのが難しい。エンジニアのマネージャーをおいたほうが良さそうだ。これを加えて5人のマネージャーがいる組織になる。
ここで考えたいのは、はたしてこの組織のエンジニアのマネージャーは働きやすいのだろうかということだ。次のことが起きることが想像できる。
社長曰く「マネージャーは数字に責任を持つべきである」（ただしエンジニアのマネージャーは別と後で聞く）
経理は「マネージャーは領収書を毎月提出することを前提にするルールをつくる」（エンジニアのマネージャーに提出すべき領収書はないのだが毎月リマインドされる）
採用は「マネージャーはメンバーの職種と一致しない。面接した候補者が面接官と同じグループに必ずしも配属されないという前提のフローをつくる」（ただしエンジニアは・・・）
評価、リモートワーク、機材購入、、
組織は与えられたデザインに従って効率的になるように自然と最適化されるから、エンジニアやそのマネージャーのデフォルトの行動はそれ以外のものに強く牽引される。
極端に言うと、エンジニア以外のグループが全て職能別グループだとエンジニアのグループも機能しやすくなる。当然、エンジニアのグループが最重要かは自明ではない。組織デザインは必要悪である。
おわりに
あまりまとまりのない文になってしまった気がしないでもないが、全部まとめて書くとえらい分量になってしまう。どうしたらよいか。
前作
この記事が気に入ったらサポートをしてみませんか？