プロダクト開発部門と管理部門の組織デザイン
エンジニアの組織デザインについて何回か考えてきたが、実際にはエンジニア以外を考慮する必要がある（ほとんどの組織ではエンジニアよりエンジニアではない人の方が多いだろう）。
今回は100人程度の会社全体の組織について考えてみよう（20人程度の組織なら組織戦略をそれほど深く考えなくても良いだろうし、組織よりもプロダクトの方が重要なフェーズだろう）。
プラットフォーム・機能・事業・顧客
組織を考えるとき、いわゆる事業部制の組織と機能別の組織の2種類が考えられるがこれをもう少し詳細に見ていく。
『Scaling Teams』より
組織に関する原則はどちらかというと抽象的なので、ここからは具体例をあげて説明していく。まず、こう仮定しよう。あなたは写真や身辺のニュースを友人と共有する顧客向けアプリを作ろうとしている。顧客が必要としているのはAndroidとiOSのアプリ、デスクトップとモバイルのウェブクライアントで、チームは現時点では比較的小規模だが、今後急成長が見込まれる。さて、どのような枠組みでデリバリーチームを編成すれば、このアプリを首尾よく顧客に届け、新機能の反復処理を効率よく進められるだろうか。
これに対して
まずは自分たちのチームに最適なトップレベルのアプローチを選定する必要がある。自社の現状をにらみつつ、次の4通りの焦点の当て方を比較検討してみてほしい。
この4通りとは
プラットフォームに焦点を当てるアプローチ: 技術によるチーム編成
機能に焦点を当てるアプローチ: 主要な機能によるチーム編成
事業に焦点を当てるアプローチ: 特定の事業目標によるチーム編成
顧客グループに焦点を当てるアプローチ: 特定の顧客グループへの価値提供によるチーム編成
それぞれに一長一短があるが、組織デザインはこの4通りのいずれかの組み合わせになる。機能別組織とはプラットフォームに焦点を当てるアプローチで、事業部制組織とは事業に焦点を当てるアプローチといえる（プロダクトが異なるなら顧客も異なるから、顧客グループに焦点を当てているともいえる）。実際、自分の所属する組織の組織図を見ればいずれかのグルーピングがされていることに気づくはずである。
事業と機能の組み合わせ
例えばこういう場合を考えてみる
法人向けのプロダクトが2つある（プロジェクトAとプロジェクトBとしよう）
営業、エンジニア、デザイナーの3職種によってビジネスを成立させる（実際にはこんなにシンプルなケースはないと思うが）
プロダクトはWebアプリで、エンジニアはフロントエンドあるいはバックエンドを担当する
このときにどういう組み合わせがあるだろうか。
事業＞プラットフォーム＞プラットフォーム
一番ありそうな組み合わせである。
事業部A
営業
開発（フロントエンド／バックエンド／デザイン）
事業部B
営業
開発（フロントエンド／バックエンド／デザイン）
メンバーはそれぞれのプロダクトにコミットするから営業も開発もプロダクトと顧客に対して強い理解を持つことができる。一方、営業面だとクロスセル、開発面だとプロダクト間の技術の一貫性、デザインの一貫性が問題になるだろうし、これらに対する組織横断的な仕組みが必要になりそうだ。なにも考えないと開発のリーダーの上司は事業部長になりそうだがそれが良いかはなんともいえない（事業部長が元技術職でない限り、技術的負債がたまりやすそうなのとエンジニア採用がスムーズにいかなそうだというのは容易に想像できる）。
事業＞プラットフォーム＞機能
末端を技術でなく機能で分けても良い。
事業部A
営業
開発（機能a、機能b、機能c）
大規模な組織でないならそもそも末端部分を公式のグループにはしないだろう（機動力が落ちる）からあまり考えなくても良いと思うが、いずれにしてもコミュニケーションが円滑になるような仕組みは必要になる。
プラットフォーム＞事業＞機能
トップレベルを職能で分ける。
営業部
プロジェクトA
プロジェクトB
開発部
プロジェクトA（フロントエンド／バックエンド／デザイン）
プロジェクトB（フロントエンド／バックエンド／デザイン）
こうなりそうなのは以下の場合だ。プロジェクトBを既存組織で新規開発して事業部として分離していない場合、つまり過渡的な状態としてありうる。別の場合としては、エンジニアを一所に集めたい場合（＝エンジニア間のコミュニケーションを最大効率にしたい場合）だ。ビジネス職を機能別にするモチベーションが弱いならそちらだけは事業部制にしても良い。
事業部A
営業
事業部B
営業
開発部
プロジェクトA（フロントエンド／バックエンド／デザイン）
プロジェクトB（フロントエンド／バックエンド／デザイン）
プラットフォーム＞プラットフォーム＞事業
技術ごとの専門性と独立性が高い場合は次のようにしても良い。
事業部A
事業部B
開発部
フロントエンド（プロジェクトA／プロジェクトB）
バックエンド（プロジェクトA／プロジェクトB）
デザイン（プロジェクトA／プロジェクトB）
規模が小さいならフロントエンドとバックエンドを分けることはないだろうが、こうすると採用プロセスと整合性をとりやすい。例えばエンジニアの募集をかけるときは「iOSエンジニア」とか「バックエンドエンジニア」のような看板を出すだろうし、選考でも特定の専門性を確認できるように面接を組むことが多い。社外の人材に対する選考プロセスと社内の人材に対する評価プロセスは一貫している方が当然望ましく、これを綺麗に実現しようとするとプラットフォームで分けるという判断になる。
混合
混合しても良く、こうすると良いところ取りができる（かもしれない）。
事業部A
開発（フロントエンド／バックエンド）
事業部B
開発（フロントエンド／バックエンド）
開発基盤部
フロントエンド
バックエンド
デザイン（プロジェクトA／プロジェクトB）
実は、というより当然のごとく、営業とデザイナーもエンジニアと同様にどうグループをつくるかという問題はある。ただ、ソフトウェア開発という業務の複雑性（見えにくさとそれに比例するような事業への影響力）と採用の難易度を考えるとある程度エンジニアに寄せて考えるのは悪い判断ではない。
事業部門と管理部門およびそれ以外
これまで事業のことを考えてきたが会社には事業以外の部署もある。総務とか経理とか人事は普通は事業部の中には置かない。階層をもたない〜室と呼ばれるものをつくることもある。株式会社の意思決定機関は取締役会だから（正確には株主総会が最高意思決定機関）、例えばこういう構造が考えられる。
取締役会
事業部A
事業部B
開発基盤部
管理部
社長室
これらも事業部のデザインやエンジニア組織のデザインと同じ原則に従う。例えば社長室は会社最高の戦力であろうCEOの能力を最大限活用する仕組みに思えるが一方でfat controllerを引き起こしやすい。
管理部門の組織デザインもいろいろ考えられる。例えば、エンジニア採用を考えると
人事部
採用グループ
エンジニア担当のチーム
エンジニア以外担当のチーム
これはよくありそうだ。先の4通りのアプローチだとプラットフォーム＞プラットフォーム＞顧客グループに相当する。あるいはこういうのもありそうだ。
人事部
採用グループ
広報
リクルーター
コーディネーター
これはプラットフォーム＞プラットフォーム＞プラットフォームという分け方だ。あるいは完全に横串を通すという考え方もある。
取締役会
CTO室
採用グループ
CTO直下に人事部門をつくってはいけないというルールはない。ただし、これをやるとCTOは採用担当を教育できるのか？という課題は出る。エンジニアの上司が非技術職のときと同様にメリットとデメリットがある。
company betと組織デザインの目的
組織デザインとはなんのためのものだったか。それはコミュニケーションの最適化である。なぜコミュニケーションを最適化するのだろうか？それはその企業の価値を最速で最大化するためだ。
組織のデザインはequity storyを説明でき、事業戦略に従い、事業計画を達成するために最適化されなければならない。それは全ての問題を解決しないだろうがcompany betの成功確率を最高にするものである必要がある。
本当に解決したい課題を解決できるように組織をデザインするのだ。逆に、（組織が順当にデザインされているなら）その会社の組織図を見ればその会社がなににフォーカスしているかがわかる。
おわりに
組織のデザインは「知っていればそれほど複雑ではない」が大抵は「その知識を得る前にそれを行なう必要に迫られる」ような仕事である。本稿とこれまでのnoteを読めば、誰でも自社の組織デザインを洞察できるようになり、どうしたら改善できるのかも考えられるようにもなるだろう。組織論もOSSと同じように誰でも使えて誰でも改善でき、公開的に議論されるようなものであってほしいと思う。
この記事が気に入ったらサポートをしてみませんか？