高凝集性と低結合性で、スケールする組織をつくる
こんにちは！
このトピックスは、「組織と経営のデザイン」を取り扱います。
前回は、もっともベーシックな組織デザインのテーマ、
「ピラミッド型か？サークル型か？どちらの組織形態を選ぶべきか？」
について考察し、「ピラミッド型が良い」が現状の回答になることを見てきました。
前回の記事にたくさんのコメントをいただきました。ありがとうございます！みなさんのコメントを通じて学ぶのがとても楽しいです。
今回は、「凝集性と結合性」という組織をスケールさせる上でもっとも重要な概念を解説していきます！
なんか、名前だけだと難しそうですが、かなりシンプルな概念です。
この2つを抑えておかないと、スケールする組織はつくれないと断言できますし、Amazonなどのビッグテック企業は、この2つの要素を抑えたスケーリングがとても秀逸であると思います。
「企業が成長して大企業になり、調整に忙殺されるようになり、働くよろこびが失われてしまった」
これは組織デザインの典型的な課題であり、もっとも難しい課題です。
人類が社会的生物であり、組織を通じてのアウトプットがその最大の特徴であることを考えれば、人類最大の課題とも言えると思います。
当然、カンタンな解決策はありませんが、ソフトウェアの構造論を組織論に応用すれば、このとてつもなく難しい問題に対応する大きな手がかりを得ることができます。
組織をスケールさせることは圧倒的に難しい
堺屋太一著「組織の盛衰」に書かれている、軍隊の大きさに対応する責任者の例を見てみます。
- 200人までの小隊や中隊：責任者は少尉か中尉
- 1,000人までの大隊：責任者は大尉
- 1,000人を超える連隊長：責任者は大佐
1,000人を超えると、その組織を動かす難易度の飛躍的な増加から、その組織に責任を持つ人物の役職が急に高くなります。
それだけ、1,000人を超えるような大規模組織をワークさせるのは圧倒的に難しい。
私が働くユーザベースも、業務委託などの形態で働くメンバーも加えれば、1,000人を超える組織です。組織をワークさせることが格段に難しくなっていることを実感しています。
大規模組織をワークさせる方法を探るために、組織とソフトウェアの類似性に着目します。
組織とソフトウェアの類似性
前回のトピックスで、ピラミッド型組織とは、プログラムとヒエラルキーからなると説明しました。
- プログラム：繰り返し出現する問題を解決する手順やルール
- ヒエラルキー：プログラムで対応できない例外への対応手順やルール
「ソフトウェア」と「組織」はどちらもプログラムの集合ですが、大きな違いは例外処理にあります。
例外処理に属人性を持たせたもの（例外が発生した場合、上司が対処するという属人性）がピラミッド型組織であり、例外処理の属人性を廃したものが、極端な意味でのサークル型組織です。
「ソフトウェア」と「組織」がどちらもプログラムの集合であるならば、「大規模組織」をワークさせていく上で、「大規模ソフトウェア」をワークさせるための理論やプラクティスが参考になるはずです。
実は現代の組織論は、
という発展の順番があります。
ソフトウェアの構造論が最先端を行く。ここには、Amazon、Microsoft、Googleなどの世界的なビッグテック企業が巨額を投じ、圧倒的な数の実験、理論化、プラクティス化を繰り返しています。
そして、ソフトウェアの構造はソフトウェア開発の組織構造と密接に関連します。それを説明するのが、下記のコンウェイの法則です。
ソフトウェアのアーキテクチャ（構造）は、組織構造を反映したものになる
コンウェイの法則に深入りしませんが、ソフトウェアの構造とソフトウェア開発組織の構造には強い慣性が働くので、ソフトウェア開発組織の構造はソフトウェア自体の構造と合わせて研究され、実験されています。
そして、その研究や実践が企業全体の組織論に落ちていく。
これは、「Software is eating the world」の現代において、ソフトウェア開発中心の組織論こそが企業の組織論の中心テーマであるからとも言えますし、また、組織を正しく抽象化したものがソフトウェアであることの帰結とも言えます。
構成要素の増加による、認知負荷の急激な増加
大規模組織をワークさせるヒントを得るために、大規模ソフトウェアをワークさせる原則を見ていきます。
ソフトウェアが大規模化するにつれて、ソフトウェアの全体像を人間が認識できなくなるという、認知負荷の問題が発生します。
これは、ソフトウェアの構成要素（プログラムやプログラムの塊）が増えるにつれて、
- 1つ1つの構成要素を正しく認知する負荷
- 構成要素同士の依存関係を正しく認知する負荷
という2つの認知負荷が増大してしまうからです。
特に、構成要素同士をつなぐ依存関係の増大がやっかいです。下の図で分かる通り、構成要素が増えるにつれて、2つの構成要素をつなぐ経路である、コミュニケーションパスは急激に増えます。
1つ1つの構成要素を正しく理解することができたとしても、構成要素同士の関連性、依存関係も含めて正しく理解しないと、ソフトウェアをアップデートしたり、エラーが発生した時に修復することができません。
そして、コミュニケーションパスは、構成要素の増大につれて二次関数的に「急激に」増えます。
構成要素同士の依存関係は、組織における「調整コスト」に対応します。大企業になると、途端に調整コストが増え、多くのプロジェクトが行き詰まってしまうという問題を示しています。
1つ1つの構成要素を正しく理解する「認知負荷」、構成要素同士の依存関係を正しく理解する「認知負荷」の2つが、大規模ソフトウェアをワークさせる上での最大の障害です。
大規模ソフトウェアをワークさせる原則
大規模化における認知負荷の急激な増加を避けるために、ソフトウェアの構造論においては、高い凝集性と低い結合性を目指すべきという原則があります。
凝集性とは、その構成要素の内部で、どれだけインタラクション（相互作用）が起こっているかを図る指標。高めるべきもの。例えば、関連性が高いプログラムを1つの単位にまとめれば、それらを「塊」として認識できるので認知負荷が下がる、という考えです。
結合性とは、複数の構成要素をまたいで、どれだけインタラクションが起こっているかを図る指標。低くする（疎にする）べきもの。例えば、AとBという2つの構成要素の依存関係が少なければ、Aという構成要素のみで対応できるケースが多くなり認知負荷が下がる、という考えです。
まとめると、下の表のようになります。
下の図が、結合性が高い（密結合＝Tightly coupled）場合と、結合性が低い（疎結合=Loosely coupled）場合の比較。
さらに下の図が、凝集性と結合性を合わせた例。左が、凝集性が低く、高結合な例であり、右が、凝集性が高く、低結合な例。
凝集性を高めることで、構成要素の依存関係（コミュニケーションパス）が整理されると共に、全体の構造の認知が容易になります。明らかに、右の図のほうが構造を認識しやすいですよね。
従って、構成要素1つ1つの凝集性が高く、構成要素間が低結合な場合、
- 構成要素を塊として認識できる
- 構成要素間の依存関係が最小化される
ということが実現され、ソフトウェアの構造を理解する認知負荷が劇的に下がります。
これにより、エラー率の低下、エラー時の復旧スピードの早さ、構成要素をまたぐプログラム構築の容易さ、などが担保され、大規模化しつつ、アウトプットが増え続けるソフトウェアが実現されます。
高凝集低結合、これが、大規模ソフトウェアをワークさせる原則です。
大規模組織をワークさせる原則
大規模ソフトウェアをワークさせる原則（高凝集低結合）は、そのまま「組織」に当てはめることができます。
組織が拡大した時に、どのような課題が発生するか。
組織の構成人員の増加に伴い、組織の構成単位（チーム）が増える。そうすると、全チームを正しく認識することが難しくなる。
また、何らかのプロジェクトを進める際に、関係するチーム数が増え、調整コストが増す。結果として、スピーディな動きが出来なくなる。
すなわち、組織が拡大すると、以下の2つの問題が起こります。
- そもそも、プロジェクトに巻き込むべき適切なチームが分からない
- プロジェクトに巻き込むべきチームが多くなり、調整コストが膨大になる
これは、「組織の硬直化」、「官僚化」、「サイロ化」などと言われる問題であり、働くよろこびや変化へのスピーディな適応力を失わせます。
この問題を構造化すると、ソフトウェアの大規模化に伴う問題とほぼ一緒です。
この問題を解決するためにどうすれば良いか。
- プロジェクトに巻き込むべき適切なチームが分からない
→ 各チームの役割を明確化し、巻き込むべきチームが容易に分かる様にする
- プロジェクトに巻き込むべきチームが多くなり、調整コストが膨大になる
→ 各チームの役割を機能毎に再構成し、巻き込むべきチーム数を最小化する
チームの機能を明確化し、チームの役割を認識する負荷を下げる。そして、チーム間の依存関係が少なくなる様に再編成することで、チームをまたぐ調整コストを最小化する。
これはまさに、組織構造における「高凝集性」と「低結合性」の実現です。
- 高凝集性：各チームの役割を「機能」に応じて明確に分け、責任範囲も明確化する
- 低結合性：チーム間の意思決定の依存関係を最小化し、チームが独立してできる意思決定を増やす
高凝集性と低結合性を満たすようにチームの役割・責任範囲をデザインすることが、大規模組織をワークさせる原則です。
また、ピラミッド型組織を前提にすると、この高凝集性と低結合性のデザインは階層的に考える必要があります。
チームをたばねるグループという階層を考えれば、チーム単位での高凝集低結合に加え、グループ単位でも高凝集低結合が実現される必要があります。
それは、同じグループ内のチーム同士のコミュニケーションの方が、違うグループに属するチーム同士のコミュニケーションより多く、チームとしてのまとまりだけではなく、それらを上の階層でたばねるグループとしてのまとまりについても、高凝集性と低結合性が実現されている状態を意味します。
アンチパターン（低い凝集性、高い結合性）
凝集性と結合性の説明テーブルを、組織の観点で書き直します。
高凝集低結合な組織に反する、アンチパターンを見ていきましょう。
最初の例は、「機能ではなく、人に組織がつく」ケースです。関連性が少ない（凝集性が低い）2つのチームが上の階層でグループとして束ねられているケース。
この場合、外から見ると、グループとしての役割、機能、責任範囲を正確に認知することがとても難しい。結果、外のチームとのコラボレーションが起こりづらく、サイロ化する危険性があります。
逆に、関連性が高い（凝集性が高い）チームが、別々のグループに属しているケース。この場合、グループを超えたやり取りが頻繁に発生するという高結合な状態になり、調整コストが膨大になります。
より一般には、「暗黙知が多い」組織。役割や責任範囲がチーム毎に明確化、形式知化されていない場合、プロジェクトを進める時に、巻き込むべきチームが分からず、プロジェクトの後半になって、予期していなかったチームから横やりが入るなど、大きな調整コストが発生し得ます。
シンプルな例では、部署名で役割を想起できないと認知負荷が高まります。例えば、「第三事業部」などの呼び方では、その事業部が何を担うのかわざわざ調べなければならない。
誰にでも分かりやすい、「すぐに明確な機能が想起できる」部署名はとても重要。
少し論点それますが、社内の人は理解できていたとしても、社外の人は、この部署名が書かれた名刺を受け取っても役割が想起できず、外部コラボレーションが進みにくくなるという弊害もあります（採用の時も同じですね）。
他には、兼任や、マトリックス型の組織なども、チーム間の依存関係を複雑化させ、認知負荷を増大させるアンチパターンであると考えています。
これらの例は、組織がそれほど大きくない場合、例えば50人規模の組織の場合、大きな問題にはなりません。組織全体を見通すコストが低いからです。
しかし、組織が成長するに従い、急激に調整コストが大きくなり、これらのアンチパターンを抱えたままでは、組織が健全に成長することが困難になります。
事業軸の凝集性と、機能軸の凝集性
難しいのは、階層的に凝集性を高めるのに、2つの方向性があることです。
A、Bという2つの事業があり、それぞれにマーケティングチームがあるとします。
AのマーケティングチームとBのマーケティングチームをまとめる機能軸を優先するか、事業毎にすべての機能をまとめる事業軸を優先するか。
Aというマーケティングチームは、当然、同じ事業内でのインタラクションは多い。一方で、Bというマーケティングチームと共同施策を実施したり、お互いのマーケティング施策から学び合うなど、機能を共有するチームともインタラクションが多くなります。
即ち、事業軸、機能軸という2つの凝集性の方向性があります。
事業軸、機能軸、どちらのラインも持つマトリックス型の組織構造を考えることもできますが、ダブルラインの組織構造はチームの依存関係を複雑化させるアンチパターン。
なので、事業軸か機能軸（少なくともどちらの軸をメインにするか）を選択しなければならない。
これに対する私の解答は以下の通りです。
- 自動化できる機能は、機能軸を優先して集積させる
- 自動化が難しい機能は、機能軸と事業軸を数年毎に行き来させて「歴史」をつくる
Software is eating the worldが進む現在、多くのことが自動化出来ます。
例えば、入社に関わる労務手続きはSaaSを用いてほぼ自動化できます。であれば、このような役割を担う労務チームは、事業毎に設置するのではなく、事業をまたいで集積させるべきです。
自動化は、究極の「チーム間の依存関係の最小化」であり、調整コストの最小化を実現します。
今回例に挙げたマーケティングは、完全な自動化はかないません。
もちろん、事業をまたぐセールス・マーケティングツールを用い、事業横断的で、効率的なマーケティングを実現することは重要です。同時に、事業部に入り込み、その顧客、プロダクトの変化に応じて、適切にマーケティングを変化させていくアジリティも重要です。
この場合、機能軸を重視して、事業部横断でマーケティングチームを集積させた状態、事業軸を重視して、事業部の中に各マーケティングチームが入り込んだ状態、の2つの状態を数年ごとに行き来し、「歴史をつくる」ことが重要だと考えています。
例えば、機能軸で一度まとまった過去を持ち、その後事業軸にバラけた場合、大規模なマーケティングが必要な場合などに、事業部を超えた連携を取ることが容易になります。それとは逆に、ずっと事業軸で固定した場合、事業部を過度に優先し、事業部をまたいだ機能的な施策の実行が困難になります。
そして、機能軸だけでまとまり続けた場合も、機能性を過度に優先し、事業部との連携がスムーズにいかなくなるという、逆方向の弊害が発生します。
これらを防ぐために、数年おきに機能軸と事業軸を入れ替える組織再編を断続的に起こしていく。
以前例に挙げた、2021年1月にリクルートが発表した事業会社7社の吸収合併は、
「事業軸を優先するモードから、機能軸を優先するモードに切り替えた」
と解釈することもできます。リクルートに限らず、分社化と合併を一定頻度で繰り返す組織があるのは、これが理由です。
ソフトウェアの発展により、自動化できる範囲は拡張を続けています。なので、事業軸と比較して機能軸を優先すべき領域が広まっていることには注意が必要です。
後でも述べますが、ビッグテック企業など、世界の最先端企業は、明らかに事業軸より機能軸を優先する領域を増やしています。
働くよろこびへのつながり
これまで書いてきた、「大規模組織をワークさせる方法」は、人の内発的動機を高め、働くよろこびを実現する方法でもあります。
ダニエル・ピンクが提唱する内発的動機づけ（モチベーション3.0）の3要素は以下の通り。
- 自主性：どんな課題を、どのように取り組むか、自身で主体的に決められること
- 成長：自身が掲げた目標に対して、努力を積み重ね、成長が実感できること
- 目的：社会全体への貢献や、組織・チームの目的への貢献を実感できること
これは、「楽しいから仕事をする」、「自分を磨くために努力する」、「社会貢献のために行動する」などを実現するもの。
凝集性が高く、疎結合な組織を目指せば、この3要素を高めることができます。
- 自主性：チームの役割が明確だからこそ、自らの選択としてジョインできる
- 成長：チームの役割が機能的、専門的であり、自身の職能的な成長を実感できる
- 目的：チームの目的が明確で、チーム間のコラボで組織の目的を果たすやり方も明確
逆に、凝集性が低く、密結合な組織だと、
- チームの責任範囲が不明瞭で、目的を見失う
- 複数のチームからの矛盾する要求に混乱し、自主性を失う
- チームをまたぐ意思決定が停滞し、サイロ化し、組織全体への貢献が実感できない
- チームが職能別でなく、ポータブルなスキルの成長実感がない
というようなことが容易に起こり、働くよろこびを低下させてしまいます。
ビッグテックの組織構造
米国発のグローバル企業は、大規模組織のデザインにおいても先頭を走っていると感じます。
特にAmazon。「The Bezos Mandate」という有名な文書があります。これは、2002年前後にベゾスが開発チームに通達した内容であり、2022年の今、ようやく時代がベゾスに追いついたとも思えてきます。
The Bezos Mandate（日本語訳）
1. 今後、全てのチームはデータと機能をインターフェースを通じて公開せよ。
2. チーム間のコミュニケーションは、その公開されたインターフェースを通じて行え。
3. 公開インターフェースを使わないプロセス間通信、直接リンク、他のチームのデータの直接読み取り、共有メモリ、その他のいかなるバックドアも一切認めない。ネットワークを経由したインターフェース呼び出しのみ、唯一許可される。
4. インターフェースに使う技術は特に規定しない。
5. 全てのインターフェースは例外なく、外部に公開できるように設計し直さなければならない。つまり、各チームはインターフェースを世界中の開発者に公開できるように計画・設計しなければならない。一切の例外は認めない。
6. これを守らない人は誰であれクビにする。
7. それでは良い一日を。
これは低結合性を徹底した開発組織（とソフトウェア構造）をつくる強いオーダーです。
また、Amazonの開発チームは、下記のような特徴を持っています。
- 1チーム10人までで構成。兼任は無し
- 1つのチームが1つのプロダクト、もしくは機能の塊を担当
- 開発言語や開発プロセスは各チームに裁量がある
- チーム間のコミュニケーションは原則として減らす
これはまさに、チームの役割を明確化し、かつチームを適切に分割し、高凝集低結合の状態を実現し、認知負荷を低下させて、組織全体のアウトプットを増やすデザインの例になっています。
ビッグテックの組織は、開発以外の部分についても、明確な機能分化を進めています。
例えば、Amazonには「経営企画部」のような、ジェネラルで、役割が曖昧な組織はありません。役割が曖昧であることは、それだけで組織内部で関わる人の認知負荷を高め、組織の生産性を下げます。
Amazonには、経営企画部の代わりに、M&A後のPMIをリードする役割を担う「Corporate Development Integration」という部署があったり、「AWS Expansion Strategy」という、AWSの拡大だけを担う部署があったりします。
これらの部署は、名前だけで役割が明確に想像でき、認知負荷がとても低い。
職能を細かく分化し、明確化し、そこに属する人のキャリアパスが明確であることがビッグテック企業や多くのグローバル企業の特徴です。
一方、「経営企画部」のみならず、「人事」や「総務」など、日本はジェネラルで職能が明確ではない部署が多い。
この違いを、米国型か日本型か、という問題に矮小化してはいけない。
米国人に合う組織体制があり、日本人に合う組織体制がある、という問題ではない。
なぜなら、この「専門性を明確化し、細かくチームを分化する」組織デザインは、大規模ソフトウェアをワークさせるデザイン（認知負荷を下げ、依存関係を最小化するデザイン）と同一だからです。
すなわち、「ソフトウェアとの類似で大規模組織をワークさせる方法を模索」してたどり着く結論であり、米国と日本での商習慣や人の気質の違いに起因するものではありません。
従って、「専門性を明確化し、細かくチームを分化する」ことは、大規模組織をワークさせるためには、必ず取り組むべきことであり、先行しているビッグテック企業の組織デザインが大いに参考になると考えています。
まとめ
大規模でワークする組織をつくることはとても難しい。そのための課題は、
「企業が成長して大企業になり、調整に忙殺されるようになり、働くよろこびが失われてしまった」
という大勢の方の働きがいに直結する課題でもあります。
これを解決するには、高凝集性と低結合性を実現する組織をデザインすること。
- 高凝集性：各チームの役割を「機能」に応じて明確に分け、責任範囲も明確化する
- 低結合性：チーム間の意思決定の依存関係を最小化し、チームが独立してできる意思決定を増やす
高凝集性には、事業軸と機能軸の2つの方向性があるが、ソフトウェアによる自動化が進展している今、機能軸の重要性が増していることを認識すること。
そして、Amazonなどのビッグテック企業は、機能軸をベースに、職能を明確に細かく分化した組織構造を採用している。そのやり方は、日本と米国の違いなどではなく、ソフトウェアと組織の同一性に着眼したやり方として、日本企業にも大いに参考になるはず。
まとめは以上です。
長い文章を読んでいただきありがとうございました。
私自身、ユーザベースという組織が拡大するにつれ、ユーザーに向き合う仕事ではなく、社内を調整する仕事が増え、働きがいを見失いかねない時期がありました。
ここに書いてあるような「調整コストを増大させる組織構造」に気づき、調整コストが増える度に、それを誘発する組織構造に立ち戻って考え、対処するようになってから、調整に追われる時間はどんどん少なくなっていき、今では楽しく働ける環境を保つことができていると感じます。
今回記事として書いたことは抽象度が高いですが、コメントで質問いただければ、具体的な課題への対応法について、考え方を共有することなど出来るかもしれません。
もちろん他のことでも、感想でも、コメントいただければとてもうれしいです〜。
2022年11月28日追記：The Bezos Mandate（日本語訳）について、引用元URLの記載が漏れていましたので、追記しました。
更新の通知を受け取りましょう
気になるトピックスが、きっと見つかる 
他では得られない独自の知見 
交流から生まれる新たな価値 
投稿したコメント