こんにちは。READYFOR（レディーフォー）で CTO をしている町野です。
READYFOR Advent Calendar 2020 の25日目の記事になります。
はじめに
早いもので、2019年に READFOR に CTO に参画して、もうすぐ２年が経とうとしています。当時まだ10名に満たなかった開発チームは倍以上の人数になり、おかげさまで全社の社員数も100名を超える規模にまで成長しました。
組織が一定の規模を超えてくると、その規模に合わせた組織の構造化が必要になってきます。この記事では、READYFOR のプロダクト開発体制をご紹介しつつ、組織設計において必ず問題になる「境界マネジメント (boundary management)」について思考を巡らせてみたいと思います。
ミッションと専門性で分かれる組織単位：Squad & Chapter
READYFOR では現在、Spotify Model をベースにした組織設計をしています。Spotify Model にはは、ミッション軸で組成する “Squad” と、専門性軸で組成する “Chapter” という基本的な組織単位があり、各メンバーはその両方に所属する形を取ります。
- Squad（スクワッド）
- ミッションベースで構成される Cross-functional な職種混成チーム
Chapter（チャプター）
- 技術的専門性 (Frontend, Backend, etc.) を軸にまとまったグループ
READYFOR では、各 Squad が半期単位でミッション (OKR) を持った上で Squad Lead が責任をもってチーム開発を推進し、人事上のマネジメントライン（1on1 や評価）は、主に専門性軸の Chapter で行っています。
ミッションと専門性の両軸で組織構造を持つことで、セクショナリズムやサイロ化を抑える力が働きます。READYFOR が大切している価値観である【乳化】を支える施策の１つです。
マトリクス組織の難しさ：２つに分かれるレポートライン
Spotify Model には、Squad を束ねた数十人単位の “Tribe” や、Tribe を跨いで自発的に生まれるコミュニティである “Guild” など、他にもいくつかの組織単位の概念があるのですが、基本的な組織構造の観点からいえば、いわゆる「マトリクス組織」に分類されます。
マトリクス組織では、社内で垣根を越えたコラボレーションを生みだす大きなメリットがある一方で、事業軸と機能軸で２種類のレポートラインが生まれることによって、各メンバーの目標管理や指揮系統において混乱が生じやすくなるデメリットもあります。
READYFOR では１人に対してメイン評価者とサブ評価者が付くことで両軸のバランスを取っているのですが、Chapter 軸でのメイン評価者からは Squad の動きが見えづらいので、OKR に関するコミュニケーションが難しくなるという課題も実際にありました。
組織の細分化が生み出す課題：役割のレッテル化
事業と組織が大きくなるにつれ、事業軸の Squad も機能軸の Chapter も、種類や数が増えていくことになります。「会社全体が１つの Squad」のようだった状態から「フィーチャーAの担当 Squad」「Webフロントエンドの Chapter」のような細分化がどんどんと進んでいきます。
細分化されたグループに個人が所属するようになっていくと、自分の役割が明確になり、自らの専門性領域を活かし磨いていけることになるので、基本的にはモチベーションもパフォーマンスも向上します。一方で、「そのタスクは OKR に入っていないので受けられない」「ここは〇〇領域なのだから〇〇エンジニアがやるべきでない」というような、望ましくない形で個人の活躍範囲を限定／制限するような行動を助長してしまうこともあります。
役割が明確になることの裏返しとして、逆に「自分の役割として定められていないこと」が浮かび上がってきてしまうのです。これは、目標や役割が細かく明確であればあるほど顕著になります。
境界マネジメント (boundary management) の重要性
組織において、各人の役割を MECE に（漏れなく被りなく）分けきることなど到底できません。役割が一部被ってしまってバチバチすることもあれば、役割の間にボールが「ストン」と落ちてしまって、お見合い状態になることなどは、どうしても起こりえます。
大切なのは、そうした状況が発生した時に素早くリカバリーをかけられる組織であることです。そのためには、組織における「境界 (boundary)」の必要性と性質について、共通理解を深めることが重要だと思っています。
なぜ組織単位が分かれる必要があるのか
「Squad やら Chapter やら、細かくチームを分けすぎるからいけない。マネージャー職も意思決定を遅くするだけなので、個人に役割を設けずにフラットな組織にすればよいんだ」という考え方もあるかもしれません。
ボトムアップで決められる範囲が増え、自律分散的なチームが増えることは大切ですが、それは「組織に構造が不要である」ということではありません。「フラット（平坦）」という言葉は「一様で画一的」なイメージを強いので、私はなるべく使わないようにしています。
マネージャー職ついても、Google が過去に実施した「Project Oxygen」等を通して、その必要性、重要性が広く認識されています。
2008 年には、調査チームが、マネージャーは重要な存在ではないという一部の意見を証明しようと試みますが、すぐにまったくの正反対であることがわかりました。つまり、マネージャーはきわめて重要な存在だったのです。
マネージャー職の必要性を前提にすると、組織の拡大に応じて組織単位が増えていくことは、ほぼ自動的に決まってしまいます。それは、私たち人間という生物が持ちうる認知的・社会的能力には限界があるためです。
Spotify Model において、Squad の人数は 6~12人ほど、Tribe の人数は 40~150人とされています。これらは、マネージャーが直接持てるライン「Span of Control」の上限と、集団が社会的関係を維持できる上限といわれる「ダンバー数」に、それぞれ対応した人数です。
人数が増えれば、その集団の中の人間関係は、組み合わせの数だけ増えていきます。10人の組織の人間関係は 45通りですが、1,000人の組織になれば、499,500通りの人間関係（ネットワーク）が生まれます。情報コミュニケーションの効率性の観点だけをとっても、組織の構造化、境界付けは避けて通れない課題だといえます。
組織を分かつ境界の複雑性を理解する
組織単位が増えていくことが必然であり避けられないのであれば、それに付随する問題にはどう立ち向かえばいいのでしょうか。
繰り返しになりますが、全ての役割を MECE に分割することなどできません。例えばミッションとスキルの２軸で平面にマッピングするとして、綺麗なボロノイ図のように分割された組織単位になるようなものではないのです。組織の境界はもっと複雑かつ曖昧に重なり合っています。
「拡大する組織で、境界を引き組織単位を分割していくこと」を敢えて理屈っぽく表現すると
- 多次元空間の中で、位置がそれぞれ時間発展していく点の集合を、クラスタ当たりの要素数が一定値を越えないように、定期的にソフトクラスタリングしていくこと
だといえないでしょうか。
エンジニアであれば担当する機能やスキルセット (React, Rails, AWS..) など、個人は様々な特徴量の組み合わせを持ちます（多次元空間の中の点）。与えられるミッションの変化や日々のスキルアップによって、それらの点は動き回り、入退社によって点の数も変化します。
クラスタの要素数が Span of Control の限界を超えないように、動的に変化する点集合を定期的にクラスタリングした結果生まれるものが、Squad や Chapter 等の組織単位なんじゃないかなと思っています。
このとき、特定のクラスターにのみ所属するハードクラスタリングではなく、複数クラスタへの所属を許す「ソフトクラスタリング」であることもポイントだと思っています（実際 READYFOR では、複数 Squad への所属を許容しています）。異なるミッションを持つ組織単位に複数所属すると、時に相反する立場を重ね持たなければならないのですが、私たちはそもそも多面性と自己矛盾を持ちうる「分人 (dividual)」であって、そうあって当然だとも思えるのです*1。
組織の境界はシステム境界・ビジネス境界と相互作用する
組織的な境界設計について書いてきましたが、組織上の境界（組織単位）は、システムの境界やビジネス上の境界と強く相互作用することが知られています。
システム境界との相互作用に関しては、コンウェイの法則が有名です。「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」という経験則ですが、それを逆に利用して、組織構造から目指すシステム構造を生み出す「逆コンウェイ戦略」があります。ビジネスにおける境界とも、Eric Evans の DDD における「Bounded Context（境界付けられたコンテキスト）」の概念で繋がっています。
ビジネス↔システム↔組織における境界が全て相互作用するからこそ、事業・開発・採用の戦略の方向を全社でアラインさせる必要があり、その境界マネジメントをすることが CTO の担う「役割」の一部だと感じています。
おわりに
コロナ禍に見舞われた2020年は、私たち READYFOR にとっても激動の１年となりました。クラウドファンディング事業者として自分たちにできることを全力で取り組もうと決め、様々な支援プログラムを立ち上げてきました。
フルリモート体制に移行する中で、事業も採用も止めずに走りきれたのは、価値観を共有する強い仲間がいたからこそだなと思います。今年は初めて READYFOR メンバーでアドベントカレンダーを埋めることができました。是非メンバーの記事もご覧ください！
*1:ジル・ドゥルーズの「分人 (dividual)」という概念は鈴木健さんの『なめらかな社会とその敵』で紹介されています（様々な境界の生物学的起源についても論じられています）。
