前々回記事 https://blog-isnt-that.vercel.app/posts/14_work_with_fun
を思いついたことによって色々考えることができました。

前回記事 https://blog-isnt-that.vercel.app/posts/15_belonging
では採用活動に応用してみることで、また違う視点を得た気がします。

本稿は「チームトポロジー」を読んだことで、組織構造へはどう影響できるだろう？と考え始めたのがきっかけになります。
これを書いたことでかなり全体感が見えたかな〜と思っています。

ここまでをまとめて、また別の応用形 (評価制度やフィードバック、KPIへの展開) などに繋げていきたいかも。

またしても超長いですがゆっくり読んでみてください。

---

はじめに

本稿の主張を一文で表現すると以下になる。

組織構造は、効率（Efficiency）ではなく、効果（Effectiveness） から設計されるべきだ。

効果とは「正しいことをやっているか」であり、それは何を価値ある成果とみなすか という価値観によって定義される。
本稿ではその価値観を、10の要素の重み付けとして表現する。

10要素の重みが定まると 効果の基準 が明確になり、次のことが一貫して導かれる。

• 組織を何軸で分けるべきか（帰属の源泉）
• チームがどのように動くべきか
• 個人がどの役割を担い、どう補完し合うか

図が示す通り、本稿では「価値観 → 効果 → 構造 → 人の動き」という設計順を重視し、効率化はその後段に位置づけている。

チームトポロジーのような効率化手法は、「方向性が定まった組織で、効率を上げるためのツール」として位置づけられる。
そのため、効果（＝方向性）を定義しないまま効率を最適化しても、組織は「速く、間違った方向へ」進むだけである。

第1部：理論的基盤

1. 10要素モデルとは

10要素モデルは、仕事の楽しさを構成する要素を分解したものだ。

• 詳細はこちら
  https://blog-isnt-that.vercel.app/posts/14_work_with_fun

要素	説明
帰属	何に向かうか、どこに属するか
自律	自分で決められる裁量
承認	認められている実感
内容	仕事そのものの面白さ
快適さ	働きやすい環境
協働	一緒に働く関係性
達成	目標を達成する喜び
貢献	誰かの役に立っている実感
成長	自分が成長している実感
感謝	感謝される、感謝する

このモデルは、会社・チーム・個人のどのレイヤーにも適用できる汎用的なフレームワークだ。そして、10要素の「重み付け」は会社によって異なる。何を最重視するかが、その会社の「らしさ」を形作る。

「楽しさがアウトプットを産む原動力だ」という考えに立てば、10要素を整えることは持続可能な成果を出すための条件を整えることでもある。

2. 仮説: 10要素の重み付けが組織構造を規定する

ここで一つの仮説を提示したい。

会社として定めた10要素の定義があったとき、それを最大限発揮させるための最適な組織構造が導出できる。

具体的には、以下の2つの軸で組織構造が決まる。

2.1 帰属の源泉 → 組織の「分け方」

帰属の源泉（何に向かうか）が、組織をどう分けるかを規定する。

帰属の源泉	組織の分け方	例
ミッション	事業部制（ミッションごと）	複数事業を持つ企業
顧客	顧客セグメント別	B2B/B2C分離、業界別
プロダクト	プロダクト別	プロダクトラインが複数ある企業
専門性	機能別（職能別）	専門家集団、士業
地域	地域別	グローバル企業、小売チェーン

2.2 重視する要素 → 組織の「動き方」

何を重視するかが、組織の動き方（仕組み・制度）を規定する。

重視する要素	導かれる構造・仕組み
自律	フラット、少階層、権限委譲、ルールより原則
協働	クロスファンクショナルチーム、情報共有の仕組み、チーム評価
達成	明確な目標設定と評価、競争と報酬の仕組み、個人評価
貢献	顧客との接点を最大化、フィードバックループを短く、現場への権限委譲
成長	ローテーション推奨、メンター制度、学習の余白

残りの5要素も「動き方」に影響する。ただし、上記5要素が「チーム間・個人間の関係性」を規定するのに対し、以下は「環境・制度・フィードバック」のレイヤーに影響する。

要素	影響するレイヤー	導かれる仕組み
帰属	採用・オンボーディング	ミッション共感を重視した採用、原体験の共有
承認	評価・称賛の仕組み	成果の可視化、称賛チャンネル、表彰制度
内容	ジョブデザイン	仕事の切り方、裁量の範囲、専門性の深さ
快適さ	環境・ツール投資	開発環境、オフィス設計、業務効率化ツール
感謝	フィードバックの仕組み	感謝を伝える文化、ピアボーナス、1on1での承認

つまり、10要素すべてが構造・仕組みに影響するが、「分け方」に直結するのは帰属、「動き方」に直結するのは自律・協働・達成・貢献・成長、「環境・制度」に影響するのは承認・内容・快適さ・感謝という整理ができる。

2.3 効果 (Efeictiveness) への接続

冒頭で「組織構造は、効果（Effectiveness） から設計されるべきだ」と述べた。
これをもう少し具体的な言葉に変えるなら以下である。

「帰属の源泉」に沿って組織を分けると、効果の基準が構造的に純化される。

例えば、「顧客」を帰属の源泉とする組織では、チームは「この顧客セグメントの課題を解決する」という明確な効果基準を持つ。「プロダクト」を帰属の源泉とする組織では、「このプロダクトで価値を届ける」が効果基準になる。

つまり、10要素モデルで組織を設計すると：

• 誰の・何の課題を解決すべきかがチーム単位で明確になる（＝効果の基準）
• その基準に沿って意思決定できる構造になる（＝正しい判断がしやすい）
• メンバーが 「なぜこの仕事をするのか」を理解できる（＝納得感と楽しさ）

「楽しさ」と「効果」は対立するものではない。むしろ、「何のためにやっているか」が明確な組織ほど、メンバーは楽しく働け、正しい意思決定ができる。10要素モデルはこの両方を同時に設計するフレームワークだ。

2.4 効果の検証サイクル

組織を設計した後、「本当に効果（ゴールが正しいか）が上がっているか」をどう検証するか。チームトポロジーが「デリバリー速度」という効率指標で検証できるのに対し、10要素モデルでは以下の観点で検証する。

検証の観点	問い	検証方法の例
効果の基準	各チームは「誰の・何の課題を解決するか」を言えるか	チームへのヒアリング、OKRの質
意思決定の質	現場で正しい判断ができているか	意思決定の振り返り、手戻りの頻度
納得感	メンバーは「なぜこの仕事をするか」を理解しているか	エンゲージメント調査、1on1
顧客への価値	実際に顧客の課題は解決されているか	NPS、顧客インタビュー、解約率

このフィードバックループを回すことで、「構造は正しいが運用がずれている」のか「そもそも構造設計が間違っている」のかを判断できる。

第2部：具体例で検証する

ここからは、上記の仮説を2つの架空の会社で検証してみよう。

3. 具体例1: 株式会社クラフトワークス（SaaS企業）

3.1 会社概要

項目	内容
社名	株式会社クラフトワークス
事業	中小企業向け業務効率化SaaS
規模	50名、創業5年目
フェーズ	成長期（PMF達成後、スケール中）

3.2 会社の10要素: 6つの枠で整理

まず、会社レベルの「うちらしさ」を6つの枠で整理する。

	背景（なぜ）	目的（何を）	手段（どうやって）
ポジティブ	創業者が中小企業の経理担当だった時代、非効率な作業に苦しんだ。ツール一つで劇的に楽になった原体験	「働く人の時間を取り戻す」	シンプルで迷わないUI、顧客の声を聞いて改善し続ける
ネガティブ	大企業向けSaaSで働いていた時、顧客の声が届かず、使われない機能ばかり作っていた	「作って終わり」の仕事、顧客不在の開発	机上の空論、顧客と話さない開発

3.3 会社の10要素: 各要素の「うちらしさ」

要素	うちの作法	背景	好ましい傾向	許容範囲
帰属	「中小企業の味方」というポジションへの共感が必須	創業者自身が中小企業で苦労した原体験	中小企業で働いた経験がある人	経験がなくても「なぜ中小企業か」に自分なりの答えがあればOK
自律	方向性を確認したら、やり方は任せる。「どうしましょう？」より「こうしようと思います」	少人数で立ち上げた時期、各自が自分で考えて動かないと回らなかった	自分で考えて提案できる人	最初は確認が多くてもOK。ただし「自分で決めたい」意欲は必要
承認	成果はチームの場で共有・称える。Slackの #wins チャンネルで週次共有	「一人で頑張っても誰も見てくれない」という前職での辛さへの反発	自分の成果をオープンに共有できる人	控えめでもOK。ただし他者を称えることはできてほしい
内容	「顧客の課題を解決する」ことに面白さを見出す。技術は手段	技術的に凝ったものを作っても使われなかった経験への反省	課題解決型。「なぜ作るか」を考える人	技術志向でもOK。ただし「顧客にどう届くか」への関心は必要
快適さ	ツール・プロセスへの投資は惜しまない。非効率は即改善	「業務効率化」を売っている会社が非効率だと説得力がない	非効率を見つけたら声を上げる人	自分で改善できなくてもOK。気づいて共有してくれれば
協働	困ったら即相談。「大丈夫？」と声をかけ合う。一人で抱え込まない	創業初期に一人で抱え込んで炎上した苦い経験	相談のハードルが低い人	内向的でもOK。ただし「困ったら言う」はできてほしい
達成	高すぎず低すぎない目標。達成可能だがストレッチ	無理な目標で疲弊した経験と、緩すぎて成長しなかった経験の両方	目標を自分事として追える人	数字へのこだわりが薄くてもOK。ただし「やりきる」姿勢は必要
貢献	顧客の声を全社に共有。月次で「顧客の声」MTGを実施	「誰のために作っているか」を忘れないため	顧客の反応を気にする人	直接顧客と話さない職種でもOK。間接的な貢献への理解があれば
成長	「幅を広げる」を推奨。3年で違う役割を経験	50人規模で専門分化しすぎると硬直化する	新しいことへの好奇心がある人	深さ志向でもOK。ただし「隣の領域を知る」意欲は必要
感謝	その場で言葉にして伝える。Slackの :arigatou: リアクションが活発	「やって当たり前」扱いされた経験への反発	感謝を言葉にできる人	照れ屋でもOK。リアクションやスタンプでもいい

3.4 10要素の重み付け

要素	重み	根拠
帰属	◎	「中小企業の味方」が明確
自律	◎	「自分で考えて動く」が重視
協働	◎	「困ったら即相談」が絶対
貢献	◎	「使ってもらえた」が最高の喜び
快適さ	◎	「非効率は即改善」が文化
内容	○	顧客の課題解決に没頭
成長	○	幅を広げる推奨
達成	△	目標は追うが、質を犠牲にしない。数字より「正しい価値」
承認	△	成果は共有するが、承認のために動く文化ではない
感謝	△	感謝を伝え合うが、仕組みとして強調はしていない

最重視する要素 : 帰属、自律、協働、貢献、快適さ

3.5 組織構造の設計

10要素の重み付けから、組織構造を導出する。

帰属の源泉 → 分け方

帰属の源泉はプロダクト × 顧客（中小企業）。
→ プロダクト中心の構造。顧客に価値を届けるチームが主役。

重視する要素 → 動き方

重視する要素	導かれる構造・仕組み
自律	フラット、少階層。やり方は任せる。マイクロマネジメントしない
協働	チーム内の連携を密に。情報共有の仕組み。心理的安全性
貢献	顧客との接点を持つ。フィードバックループを短く
快適さ	ツール・プロセスへの投資。非効率を許さない

導出される組織構造

3.6 チームの10要素: プロダクトチーム

項目	内容
ミッション	顧客の業務を効率化する機能を届け続ける
人数	8名（PdM 1、デザイナー 1、エンジニア 5、QA 1）

要素	会社から継承	チーム固有の調整
帰属	「中小企業の味方」	+ 「顧客に直接価値を届ける最前線」という自負
自律	方向性確認後は任せる	PdMが優先順位を決め、Howはエンジニアに委ねる
承認	成果をオープンに共有	リリースごとに #wins で共有。月次で顧客の反応をフィードバック
内容	顧客課題の解決	機能の企画〜開発〜リリースまで一気通貫。スコープ明確
快適さ	非効率は即改善	基盤チームが提供するCI/CDを活用。プロダクト開発に集中できる
協働	困ったら即相談	毎朝15分の同期。Slackでの相談が活発。CSとは週次で連携
達成	ストレッチだが達成可能	2週間スプリント。リリース頻度とユーザー利用率をKPIに
貢献	顧客の声を全社に共有	CSから顧客の声が直接届く。使われている実感を得やすい
成長	幅を広げる	フロント⇔バックのローテーション推奨
感謝	言葉にして伝える	リリース後に関係者へ感謝を伝える文化

チームの強み・弱み

強み	弱み
顧客志向が強い	技術的な深掘りが弱くなりがち
スピード感がある	ドキュメントが後回しになりがち
協働が活発	-

3.7 チームの10要素: 開発基盤チーム

項目	内容
ミッション	プロダクトチームが顧客価値に集中できる環境を作る
人数	4名（リード 1、SRE 2、DevOps 1）

要素	会社から継承	チーム固有の調整
帰属	「中小企業の味方」	+ 「プロダクトチームの味方」という二重の帰属
自律	方向性確認後は任せる	技術選定・設計は完全に委ねられる。高い裁量
承認	成果をオープンに共有	「インフラが安定しているのは当たり前」になりがち → 意識的に可視化
内容	顧客課題の解決	直接の顧客は「プロダクトチーム」。技術的な深さを追求できる
快適さ	非効率は即改善	自分たちが「快適さ」を提供する側。自チームの環境も整備
協働	困ったら即相談	プロダクトチームとは依頼ベースで明確にやり取り
達成	ストレッチだが達成可能	デプロイ頻度、障害復旧時間、開発者満足度をKPIに
貢献	顧客の声を全社に共有	直接の顧客（プロダクトチーム）からのフィードバックを重視
成長	幅を広げる	新技術の検証・導入を推奨。深さも認める
感謝	言葉にして伝える	プロダクトチームから感謝されると嬉しい。意識的に伝え合う

チームの強み・弱み

強み	弱み
技術的な深さがある	顧客（エンドユーザー）との距離が遠い
自律性が高い	「当たり前」扱いされやすい
-	プロダクトチームとの温度差が生まれやすい

3.8 個人の10要素: プロダクトチームの2名

田中さん（エンジニア、3年目）

項目	内容
役割	フロントエンドエンジニア
経験	前職はWeb制作会社。顧客と直接やり取りする経験あり
動機源	承認優位。認められることでエネルギーが出る

要素	強み/弱み	詳細
帰属	◎	中小企業で苦労した親戚がいて、原体験に共感
自律	○	自分で考えて動けるが、確認は多め
承認	◎	褒められると伸びる。成果を共有するのも好き
内容	○	顧客の課題解決に興味あり。技術も好き
快適さ	○	非効率に気づくが、自分で改善するより声を上げる
協働	◎	相談しやすい。声をかけるのも得意
達成	○	目標は追えるが、数字へのこだわりは薄い
貢献	◎	「使ってもらえた」が最高のモチベーション
成長	○	新しいことは好き。深さより幅
感謝	◎	感謝を言葉にするのが得意

チーム内での動き方

観点	動き方
強みを活かす	協働・感謝の強みを活かし、チームのムードメーカーに。CSとの連携役
弱みを補う	技術的な深掘りはシニアエンジニアに相談しながら進める
成長の方向	バックエンドにも領域を広げる。自律（自分で判断する力）を伸ばす

鈴木さん（エンジニア、5年目）

項目	内容
役割	バックエンドエンジニア、テックリード
経験	前職は大企業のSIer。技術的には強いが、顧客との距離が遠かった
動機源	自律優位。自分で決めて進めたい

要素	強み/弱み	詳細
帰属	○	「中小企業」への原体験は薄いが、ミッションには共感
自律	◎	自分で考えて判断できる。任せてもらえると燃える
承認	△	あまり気にしない。褒められなくても平気
内容	◎	技術的なチャレンジに没頭できる
快適さ	◎	非効率を見つけると自分で改善する
協働	△	一人で黙々とやりがち。相談されれば答える
達成	○	目標は達成するが、過程を楽しむタイプ
貢献	△	顧客の反応への関心は薄め
成長	◎	技術の深さを追求したい
感謝	△	言葉にするのは苦手。行動で返す

チーム内での動き方

観点	動き方
強みを活かす	自律・内容・快適さの強みを活かし、技術的な判断とプロセス改善をリード
弱みを補う	協働・感謝は田中さんと補完。意識的に「声をかける」を増やす
成長の方向	技術の深さは維持しつつ、「顧客にどう届くか」の視点を広げる

田中さんと鈴木さんの補完関係

3.9 個人の10要素: 開発基盤チームの2名

山本さん（SRE、4年目）

項目	内容
役割	SRE（Site Reliability Engineer）
経験	前職はインフラ専業会社。安定稼働を守ることに誇り
動機源	自律優位。技術的な判断を任せてもらいたい

要素	強み/弱み	詳細
帰属	○	「プロダクトチームを支える」という役割に共感
自律	◎	技術選定・設計を任せてもらえると燃える
承認	△	「安定して当たり前」扱いに慣れている。気にしない
内容	◎	インフラ・SREの技術に没頭できる
快適さ	◎	「快適さ」を提供する側。自分でも整備する
協働	○	依頼ベースで動く。明確なインターフェースを好む
達成	○	SLOを守ることにこだわり
貢献	△	エンドユーザーとの距離は遠い。プロダクトチームへの貢献で実感
成長	◎	新技術の検証が好き。深さを追求
感謝	△	言葉にするのは苦手

チーム内での動き方

観点	動き方
強みを活かす	自律・内容の強みを活かし、技術的な深掘りをリード
弱みを補う	感謝は苦手だが、プロダクトチームからの依頼に丁寧に対応することで信頼を得る
成長の方向	技術の深さを維持しつつ、プロダクト視点（なぜこの基盤が必要か）を広げる

佐藤さん（DevOps、2年目）

項目	内容
役割	DevOpsエンジニア
経験	新卒2年目。前職なし。成長意欲が高い
動機源	承認優位。フィードバックがほしい

要素	強み/弱み	詳細
帰属	○	会社のミッションに共感。まだ深くはない
自律	△	まだ自信がない。確認が多い
承認	◎	フィードバックがエネルギーになる
内容	○	CI/CDに興味あり。学ぶことが多くて楽しい
快適さ	○	新しいツールへの適応は早い
協働	○	聞く姿勢はある。発信はまだ弱い
達成	○	小さな達成を積み重ねたい
貢献	○	プロダクトチームに感謝されると嬉しい
成長	◎	成長意欲が高い。何でも吸収したい
感謝	◎	感謝を言葉にするのが得意

チーム内での動き方

観点	動き方
強みを活かす	成長意欲・感謝の強みを活かし、積極的に学びながらチームの雰囲気を明るくする
弱みを補う	自律はまだ弱いので、山本さんに相談しながら判断力を養う
成長の方向	まずはCI/CDを深める。徐々に自分で判断できる範囲を広げる

山本さんと佐藤さんの補完関係

3.10 クラフトワークス: 全体像

4. 具体例2: 株式会社キャリアブリッジ（人材紹介）

4.1 会社概要

項目	内容
社名	株式会社キャリアブリッジ
事業	ミドル〜ハイクラス層向け人材紹介
規模	80名、創業8年目
フェーズ	安定成長期（業界内で一定のポジション確立）

4.2 会社の10要素: 6つの枠で整理

	背景（なぜ）	目的（何を）	手段（どうやって）
ポジティブ	創業者が30代で転職に失敗し、キャリアを棒に振りかけた。その後、良いエージェントに出会い人生が好転した原体験	「人生を変える転職を届ける」	求職者の人生に深く関わる。数より質。長期的な関係構築
ネガティブ	大手人材会社で「数字のために人を動かす」やり方に嫌気がさした	「駒扱い」する紹介、ミスマッチを承知で押し込む成約	短期的な数字のために求職者・企業を犠牲にすること

4.3 会社の10要素: 各要素の「うちらしさ」

要素	うちの作法	背景	好ましい傾向	許容範囲
帰属	「人の人生に関わる仕事」という重みを理解していることが必須	創業者自身が転職で人生が変わった原体験	自分自身がキャリアで悩んだ経験がある人	人材業界未経験でもOK。ただし「なぜ人の人生に関わりたいか」に答えがある人
自律	担当顧客（求職者・企業）へのアプローチは各自に任せる。「どう関係を作るか」は自分で決める	人と人の関係に「正解のマニュアル」はない	自分なりのスタイルを持っている人	最初は型を学ぶ期間があってもOK。ただし「自分のやり方を見つけたい」意欲は必要
承認	成約は全社MTGで共有。ただし「成約数」より「どんなマッチングだったか」を語る	数字だけを称えると、質より量に走る	「良いマッチングができた」ことを誇れる人	数字で燃えるタイプでもOK。ただし「質を犠牲にした数字」は評価されないことを理解している
内容	「人を深く知る」ことに面白さを見出す。表面的なスペックマッチではない	スペックだけ見て紹介してもうまくいかなかった経験	人に興味がある人	内向的でもOK。ただし「人を理解したい」という欲求は必要
快適さ	事務作業・入力作業は最小限に。顧客と向き合う時間を最大化	「CRMの入力で1日が終わる」という本末転倒を避けたい	「この作業、本当に必要？」と問える人	事務が苦手でもOK。ただし最低限の記録はつけてほしい
協働	個人の成果を追いつつも、案件の相談・共有は活発に。「一人で抱え込んで失注」を避ける	営業は個人戦になりがちだが、情報共有で全員のレベルが上がった経験	自分の案件を共有できる人	個人で集中したい時間があってもOK。ただし困ったら相談する姿勢は必要
達成	目標はストレッチ。ただし「質を落としてでも達成」はNG	数字を追いすぎて質が下がり、結果的に長期で損をした経験	数字に向き合える人	数字が苦手でもOK。ただし「成果を出す」ことへのコミットは必要
貢献	成約後のフォローを重視。「入社して終わり」ではなく「活躍してこそ」	入社後すぐ辞められると、求職者も企業も自分も誰も幸せにならない	「その後どうなったか」が気になる人	新規開拓が好きなタイプでもOK。ただし「売って終わり」の発想はNG
成長	「業界・職種の専門性」を深めることを推奨。何でも屋より専門家	浅く広くだと、求職者・企業に深いアドバイスができない	特定領域を深掘りしたい人	最初は広くやってみるフェーズがあってもOK
感謝	求職者・企業からの「ありがとう」を全社に共有。Slackに専用チャンネル	「感謝の声」がこの仕事の一番のエネルギー源	感謝されることを素直に喜べる人	照れ屋でもOK。ただし感謝の声を受け取る姿勢は持ってほしい

4.4 10要素の重み付け

要素	重み	根拠
帰属	◎	「人の人生に関わる重み」への共感が必須
自律	◎	「アプローチは各自に任せる」
貢献	◎	「入社後に活躍してこそ」
感謝	◎	「ありがとう」がエネルギー源
内容	◎	「人を深く知る」ことへの面白さ
協働	○	個人戦だが情報共有は活発
達成	○	数字は追うが質を犠牲にしない
快適さ	○	顧客対応時間を最大化
成長	○	専門性を深める
承認	○	質を語れる成約を評価

最重視する要素 : 帰属、自律、貢献、感謝、内容

4.5 組織構造の設計

帰属の源泉 → 分け方

帰属の源泉は顧客（求職者・企業）× 専門性（業界・職種）。
→ 専門領域別のチーム構成。

重視する要素 → 動き方

重視する要素	導かれる構造・仕組み
自律	個人に裁量を与える。アプローチは任せる
貢献	顧客（求職者・企業）との直接接点を最大化
感謝	感謝の声を共有する仕組み
協働	個人戦ベースだが、情報共有の場を設ける

導出される組織構造

4.6 チームの10要素: CA（キャリアアドバイザー）チーム - IT業界担当

項目	内容
ミッション	IT業界で働く人のキャリアを、深く理解して支援する
人数	5名（リーダー1、メンバー4）
担当領域	IT業界（エンジニア、PM、コンサルなど）

要素	会社から継承	チーム固有の調整
帰属	「人生を変える転職を届ける」	+ 「IT業界の人材市場を熟知したプロ」という専門家意識
自律	アプローチは各自に任せる	求職者との関係構築スタイルは個人に委ねる
承認	質を重視した成約を称える	「この求職者にとってなぜこの転職が良かったか」を語れる成約を評価
内容	人を深く知る	IT業界特有のキャリアパス、技術トレンドへの理解が必要
快適さ	顧客対応時間を最大化	面談の事前準備・事後記録を効率化
協働	案件の相談・共有	RA（企業担当）との連携が生命線。週次で案件共有会
達成	質を維持した目標達成	月間成約数＋入社後3ヶ月定着率をKPIに
貢献	入社後のフォローまで	入社後1ヶ月、3ヶ月でフォロー連絡
成長	専門性を深める	IT業界の知識を深める。技術トレンドのキャッチアップ
感謝	感謝を共有する	求職者からの「ありがとう」メッセージをチームで共有

チームの強み・弱み

強み	弱み
IT業界への専門性が高い	他業界の案件には対応しづらい
求職者との関係構築が丁寧	数を追うスタイルではない
RAとの連携が密	-

4.7 チームの10要素: RA（リクルーティングアドバイザー）チーム - スタートアップ担当

項目	内容
ミッション	成長企業の採用を、深く理解して支援する
人数	5名（リーダー1、メンバー4）
担当領域	スタートアップ・ベンチャー企業

要素	会社から継承	チーム固有の調整
帰属	「人生を変える転職を届ける」	+ 「成長企業と人材をつなぎ、産業を育てる」という社会的意義
自律	アプローチは各自に任せる	企業開拓のスタイルは自由。紹介・イベント・SNS何でもOK
承認	質を重視した成約を称える	「この企業になぜこの人材が必要だったか」を語れる成約を評価
内容	人（企業）を深く知る	スタートアップ特有の組織課題、成長ステージへの理解が必要
快適さ	顧客対応時間を最大化	求人票作成の効率化。企業情報のテンプレート整備
協働	案件の相談・共有	CA（求職者担当）との連携が生命線。マッチング精度を上げる
達成	質を維持した目標達成	月間成約数＋採用後の活躍度をKPIに
貢献	入社後のフォローまで	入社後の活躍を企業からヒアリング。長期的な関係構築
成長	専門性を深める	スタートアップ市場の知識を深める。投資トレンドも把握
感謝	感謝を共有する	企業からの「良い人を紹介してくれた」声をチームで共有

チームの強み・弱み

強み	弱み
スタートアップ市場への深い理解	大企業案件には対応しづらい
企業との関係構築が得意	求人数が不安定（スタートアップの採用は波がある）
新規開拓に強い	-

4.8 個人の10要素: CAチームの2名

中村さん（CA、4年目）

項目	内容
役割	キャリアアドバイザー（IT業界担当）
経験	前職はIT企業の人事。採用する側の経験あり
動機源	貢献優位。「この人の役に立てた」実感がエネルギー

要素	強み/弱み	詳細
帰属	◎	自分自身が転職で苦労した経験があり、ミッションに深く共感
自律	◎	自分なりの面談スタイルを確立している
承認	○	称賛は嬉しいが、それより求職者の反応が大事
内容	◎	人の話を聞くのが好き。キャリアの深掘りが得意
快適さ	△	事務作業が苦手。後回しにしがち
協働	○	RAとの連携は得意。チーム内共有はやや弱い
達成	○	数字は追えるが、無理はしない
貢献	◎	「入社後に活躍してます」の報告が一番嬉しい
成長	○	IT業界の知識を深めたい
感謝	◎	求職者からの感謝メッセージを宝物にしている

チーム内での動き方

観点	動き方
強みを活かす	内容・貢献の強みを活かし、深い面談で求職者の本音を引き出す
弱みを補う	事務作業はオペレーションチームのサポートを積極的に活用
成長の方向	チーム内での知見共有を増やす。「自分のノウハウ」を言語化してチームに還元

高橋さん（CA、2年目）

項目	内容
役割	キャリアアドバイザー（IT業界担当）
経験	前職は営業（不動産）。人材業界は未経験
動機源	達成優位。目標を追いかけるのが好き

要素	強み/弱み	詳細
帰属	○	ミッションに共感はあるが、まだ深くはない
自律	○	自分で動けるが、まだ「型」を学んでいる段階
承認	◎	成約を称えられると燃える
内容	○	人と話すのは好き。IT業界の知識はまだ浅い
快適さ	◎	事務作業も効率的にこなせる
協働	◎	相談上手。先輩にすぐ聞ける
達成	◎	数字を追いかけるのが好き。目標必達
貢献	○	成約は嬉しいが、「入社後」まで意識が回りにくい
成長	◎	早く一人前になりたい。学ぶ意欲が高い
感謝	○	感謝されると嬉しい

チーム内での動き方

観点	動き方
強みを活かす	達成・協働の強みを活かし、数字をしっかり追いながら先輩から学ぶ
弱みを補う	IT業界の知識は中村さんから学ぶ。貢献（入社後フォロー）を意識的に増やす
成長の方向	まずは成約数で実績を作る。その後「質」にもこだわれるように

中村さんと高橋さんの補完関係

4.9 個人の10要素: RAチームの2名

小林さん（RA、6年目）

項目	内容
役割	リクルーティングアドバイザー（スタートアップ担当）、チームリーダー
経験	人材業界一筋。大手からキャリアブリッジに転職
動機源	自律優位。自分のやり方で成果を出したい

要素	強み/弱み	詳細
帰属	◎	大手の「数字至上主義」に嫌気がさして転職。ミッションに強く共感
自律	◎	独自の企業開拓スタイルを確立。業界でも顔が広い
承認	△	あまり気にしない。成果で示すタイプ
内容	◎	スタートアップの経営者と話すのが好き
快適さ	○	自分のやり方で効率化している
協働	○	チームを引っ張るが、やや属人的
達成	◎	数字もしっかり追う。ただし質を犠牲にしない
貢献	◎	企業の成長に関わっている実感がある
成長	○	市場の変化を追い続けている
感謝	△	言葉にするのは苦手。行動で示す

チーム内での動き方

観点	動き方
強みを活かす	自律・内容・達成の強みを活かし、トップセールスとしてチームを牽引
弱みを補う	「暗黙知」を言語化してチームに共有する。属人化を減らす
成長の方向	プレイヤーとしての強さは維持しつつ、リーダーとしてチーム育成に力を入れる

田村さん（RA、1年目）

項目	内容
役割	リクルーティングアドバイザー（スタートアップ担当）
経験	新卒1年目。就活で苦労した経験から人材業界へ
動機源	承認優位。認められたい。早く成果を出したい

要素	強み/弱み	詳細
帰属	◎	自身の就活経験から、ミッションに強く共感
自律	△	まだ自信がない。指示を待ちがち
承認	◎	褒められると伸びる。成果を認めてほしい
内容	○	人と話すのは好き。企業への深い理解はこれから
快適さ	○	新しいツールへの適応は早い
協働	◎	素直に聞ける。先輩からの指導を吸収
達成	○	数字は追いたいが、まだ型ができていない
貢献	○	「企業に感謝された」経験をもっと積みたい
成長	◎	成長意欲が高い。早く一人前になりたい
感謝	◎	感謝を素直に伝えられる

チーム内での動き方

観点	動き方
強みを活かす	帰属・協働・成長意欲を活かし、素直に学びながら成長
弱みを補う	小林さんに同行してスタイルを学ぶ。まずは「型」を身につける
成長の方向	最初の1年は先輩の型を学ぶ。2年目から自分のスタイルを模索

小林さんと田村さんの補完関係

4.10 キャリアブリッジ: 全体像

5. 2社の比較: 違いはどこから来るか

観点	クラフトワークス（SaaS）	キャリアブリッジ（人材紹介）
帰属の源泉	プロダクト	顧客（人）× 専門性
最重視	協働、快適さ	自律、貢献、感謝
チームの形	一体となって作る	個人戦＋情報共有
顧客接点	CSが中継	各自が直接持つ
成果の単位	チーム	個人

同じ10要素でも、業界・事業によって「中身」がまったく違う。

観点	クラフトワークス	キャリアブリッジ
帰属の源泉	プロダクトへの愛着	人への関わり
達成の性質	デリバリー（リリース）	成約（マッチング）
内容の面白さ	技術・課題解決	人を深く知る
協働の形	チームで一つのものを作る	個人戦＋情報共有
成長の方向	技術の幅/深さ	業界/職種の専門性
貢献の実感	使ってもらえた	人生が変わった

クラフトワークスは「チームで一つのものを作る」ので、協働が構造の中心になる。キャリアブリッジは「個人が顧客と関係を作る」ので、自律が構造の中心になる。

どちらも帰属（何のためにやるか）は明確だが、その実現方法が違う。だから最適な組織構造も違う。

2社の10要素比較

要素	クラフトワークス	キャリアブリッジ
帰属	◎	◎
自律	△	◎
協働	◎	△
貢献	○	◎
快適さ	◎	△
感謝	△	◎
達成	△	○
成長	○	○
内容	○	○
承認	△	△

この表から、2社の「形」の違いが見える。

• クラフトワークス : 帰属・協働・快適さが高い → チームで一体となってプロダクトを作る構造
• キャリアブリッジ : 帰属・自律・貢献・感謝が高い → 個人が自律的に顧客と向き合う構造

10要素のどこを高く設定するかで、組織の「骨格」が決まる。

第3部：検証と逆算

6. 検証: 10要素の重み付けから組織構造を導出できるか

6.1 クラフトワークスの検証

観点	10要素から導出した理想	実際に設定した構造
チーム構成	プロダクト中心	プロダクトチーム（SA）が主役
顧客接点	開発者が顧客の声を聞ける	CSチームが顧客の声を届ける
ツール整備	専門チームが担当	開発基盤チーム（PF）が担当
階層	フラット	少階層を想定
チーム規模	少人数	5〜8名程度

6.2 キャリアブリッジの検証

観点	10要素から導出した理想	実際に設定した構造
チーム構成	専門領域別	IT業界担当、スタートアップ担当など
役割分離	CA/RAの分離	CA（求職者）とRA（企業）を分離
裁量	個人に高い裁量	アプローチは各自に任せる
情報共有	仕組みを整備	週次案件共有会、Slackチャンネル
サポート	事務代行部門	オペレーションチーム
感謝共有	仕組みあり	Slack専用チャンネル

6.3 逆検証: もし10要素の重み付けが違ったら？

クラフトワークスで「達成」を最重視していたら？

要素	変更
達成	◎◎（最重要）
協働	○（下げる）

導かれる構造の変化 :

• 個人の成果が見えやすい設計
• 競争と報酬の仕組み
• チームより個人単位の評価

→ プロダクトチームを「機能別」に分け、個人のアウトプットを測定しやすくする
→ 今の「一体となって顧客価値を届ける」構造とは異なる

キャリアブリッジで「達成」を最重視していたら？

要素	変更
達成	◎◎（最重要）
貢献	△（下げる）
感謝	△（下げる）

導かれる構造の変化 :

• 成約数ランキングの可視化
• インセンティブ報酬の強化
• 個人間競争の促進
• 「入社後フォロー」は別部門に切り離し、営業は新規に集中

→ 大手人材会社的な「数字至上主義」の構造になる
→ 今の「質と関係性を重視」する構造とは異なる

7. 逆算: 既存の構造から10要素を読み取る

ここまでは「10要素 → 組織構造」の順で考えた。逆に「組織構造 → 10要素」の逆算もできる。

7.1 観察ポイントと読み取れる要素

分け方

実態	読み取れる要素
事業部制	帰属の源泉＝ミッション
顧客セグメント別	帰属の源泉＝顧客
プロダクト別	帰属の源泉＝プロダクト
機能別（職能別）	帰属の源泉＝専門性

階層の深さ

実態	読み取れる要素
深い（多階層）	承認（階層での評価）、達成（明確なキャリアパス）
浅い（フラット）	自律（権限委譲）、協働（横連携）

評価の単位

実態	読み取れる要素
個人評価中心	達成、自律、承認
チーム評価中心	協働、貢献

意思決定の仕方

実態	読み取れる要素
トップダウン	承認（上からの指示）、達成（目標の落とし込み）
ボトムアップ/合意形成	自律、協働
現場委任	自律、貢献（現場が顧客に近い）

情報の流れ

実態	読み取れる要素
縦（報告ライン中心）	承認、達成
横（共有・連携中心）	協働
外（顧客接点中心）	貢献、感謝

報酬・インセンティブ

実態	読み取れる要素
成果連動が強い	達成
固定給中心	帰属、成長（長期的関係）
チームボーナス	協働

育成の仕組み

実態	読み取れる要素
ローテーション推奨	成長（幅）
専門性深掘り推奨	成長（深さ）、内容

7.2 典型的な組織パターンの逆算

パターンA: 伝統的な日本企業（機能別・多階層）

観察ポイント	実態
分け方	機能別（営業部、製造部、総務部...）
階層	深い（部長→課長→係長→主任→一般）
評価単位	個人（ただし年功序列的）
意思決定	稟議・根回し（合意形成だが遅い）
情報の流れ	縦中心（報告ライン）
報酬	固定中心、年功序列
育成	ローテーション、OJT

逆算される10要素 :

要素	推定	根拠
帰属	◎	「うちの会社」への帰属意識を重視
自律	△	稟議文化、個人の裁量は小さい
承認	◎	階層での昇進が承認の主な形
快適さ	△	効率より手続き重視
協働	○	根回し・調整はある（ただし遅い）
達成	△	数字より「頑張っている姿勢」
貢献	△	顧客との距離が遠い部門が多い
成長	○	ローテーションで幅を広げる
感謝	△	表に出さない文化

暗黙のメッセージ :
「会社に長くいて、階層を上がっていくことが成功」
「個人で目立つより、組織に溶け込む」

パターンB: 外資系コンサル（プロジェクト型・Up or Out）

観察ポイント	実態
分け方	プロジェクト型（案件ごとにチーム編成）
階層	明確だが流動的（パートナー→マネージャー→コンサルタント）
評価単位	個人（プロジェクト評価の積み上げ）
意思決定	現場委任（プロジェクト内は自律）
情報の流れ	プロジェクト内は密、横断は弱い
報酬	成果連動、Up or Out
育成	OJT、プロジェクト経験で成長

逆算される10要素 :

要素	推定	根拠
帰属	○	ファーム全体より「プロジェクト」「クライアント」への帰属
自律	◎	プロジェクト内では裁量が大きい
承認	◎	評価・昇進が明確。Up or Out
内容	◎	知的チャレンジ、問題解決
快適さ	△	激務、効率より成果
協働	◎	プロジェクト内は密な連携
達成	◎	プロジェクトの成功が最重要
貢献	◎	クライアントへの価値提供
成長	◎	成長しないと生き残れない

暗黙のメッセージ :
「成長し続けろ、成果を出せ」
「プロジェクトで価値を出すことが全て」

パターンC: スタートアップ（フラット・プロダクト中心）

観察ポイント	実態
分け方	プロダクト/機能のハイブリッド
階層	浅い（CEO→リード→メンバー程度）
評価単位	チーム寄り（ただし曖昧なことも）
意思決定	現場委任、スピード重視
情報の流れ	全方向（Slackで全部オープン）
報酬	ストックオプション、成長期待
育成	OJT、やりながら学ぶ

逆算される10要素 :

要素	推定	根拠
帰属	◎	ミッション・ビジョンへの共感
自律	◎	裁量が大きい、自分で決める
承認	○	カジュアルに称え合う
内容	◎	プロダクトへの愛着、技術的挑戦
快適さ	○	整備途上だが、改善意欲は高い
協働	◎	少人数で密に連携
達成	○	重要だが、プロセスも重視
貢献	◎	ユーザーの反応がダイレクト
成長	◎	会社と一緒に成長

暗黙のメッセージ :
「ミッションを信じて、自分で考えて動け」
「一緒に会社を作っていく仲間」

7.3 逆算の価値

1. 「言っていること」と「構造が示していること」のギャップ発見

言っていること	構造が示していること	ギャップ
「自律を重視」	稟議が5段階必要	構造が自律を阻害
「顧客第一」	顧客接点は営業だけ	多くの人が顧客を知らない
「チームワーク」	個人評価・個人インセンティブ	協働より個人戦を促進
「成長支援」	同じ仕事を10年続ける	成長機会がない

このギャップが「言行不一致」として社員に伝わり、信頼を損なう。

2. 組織統合・M&A時の文化診断

構造を見れば、言語化されていない文化が見える。

A社の構造	B社の構造	予測される衝突
フラット・自律重視	階層・承認重視	意思決定スピードの違い
チーム評価	個人評価	協働 vs 競争
顧客接点多い	顧客接点少ない	顧客意識の違い

3. 変革の起点を見つける

「文化を変えたい」と言っても、構造が変わらなければ変わらない。
逆算で「どの構造が、どの要素を阻害しているか」を特定できる。

第4部：構造変更の進め方

8. 10要素と構造がズレている場合

8.1 原則: 10要素が先、構造が従う

理由 :

1. 10要素は「なぜ」、構造は「どうやって」
   「何を大事にするか」が決まらないと、構造の良し悪しが判断できない。構造は10要素を実現するための手段。

2. 構造から変えると、形骸化する
   「フラットにしろ」と言っても、なぜフラットかがわからないと、形だけになる。10要素が共有されていれば、構造変更の意味が伝わる。

3. 10要素は変えにくい、構造は変えやすい
   10要素（価値観・文化）は時間がかかる。構造（制度・仕組み）は決定すれば変えられる。だからこそ、10要素を先に固めて、構造を合わせる。

8.2 判断フロー

8.3 例外: 構造から10要素を変える場合

構造が先に変わり、それが10要素（文化）を変えることもある。

ケース	説明
M&A・統合	買収先の構造に合わせざるを得ない
外部環境の激変	市場変化で構造変更が先に必要
意図的な文化変革	構造を変えることで、文化を変えようとする

ただし、この場合も「新しい構造が前提とする10要素は何か」を明示すべきだ。暗黙のまま構造だけ変えると、混乱が生じる。

8.4 具体例: 構造変更で文化が変わったケース

Spotify のSquad/Tribe/Guild

変更前 :

• 機能別組織（開発、デザイン、QA...）
• サイロ化、連携コストが高い

構造変更 :

• Squad（小さな自律チーム）を基本単位に
• Tribe（関連Squadの集まり）で緩やかに連携
• Guild（職能横断のコミュニティ）で専門性共有

この構造が暗黙に前提とする10要素 :

要素	前提
自律	◎ Squadに大きな裁量
協働	◎ Squad内は密、Tribe間は緩やか
内容	◎ Squadが機能をEnd-to-Endで持つ
快適さ	○ 依存関係を減らす
成長	○ Guildで専門性を深める

結果 :
構造が「自律と協働を両立する文化」を促進した。

ポイント :
構造変更と同時に「この構造は何を大事にしているか」を明示したから成功した。

9. 構造変更の優先順位

全部は一度に変えられない。どこから手をつけるか。

9.1 4つの判断軸

軸	説明
10要素の重み付け	最重視する要素に関わる構造から変える
影響範囲	全社に影響するものを優先
難易度	着手しやすいものから成果を出す
痛みの大きさ	離職・成果不振など緊急度が高いものを優先

9.2 重視する要素と優先すべき構造変更

最重視する要素	優先すべき構造変更
自律	権限委譲、稟議削減、階層のフラット化
協働	チーム編成、情報共有の仕組み、評価単位
達成	目標設定、評価制度、インセンティブ
貢献	顧客接点の設計、フィードバックループ
成長	育成制度、ローテーション、学習機会

9.3 優先順位マトリクス

	難易度: 低	難易度: 高
影響範囲: 大	最優先 情報オープン化、稟議の簡素化、評価制度変更	重要だが大変 マネージャー意識変革
影響範囲: 小	小さく始める パイロットとして試す	後回し 優先度低い

• 最優先: 影響が大きく、着手しやすい。すぐ始める。
• 重要だが大変: 影響は大きいが時間がかかる。計画を立てて進める。
• 小さく始める: 影響は小さいがやりやすい。パイロットとして試す。
• 後回し: 影響が小さく大変。優先度低い。

9.4 具体例: 優先順位の決め方

ケース: 自律を重視したいが、構造が追いついていない

ズレている構造	影響範囲	難易度	優先度
稟議が5段階	全社	中（制度変更）	★★★ 高
マイクロマネジメント	部門による	高（マネージャーの意識変革）	★★ 中
情報がクローズド	全社	低（ツール導入）	★★★ 高
個人裁量が小さい	全社	中（評価制度変更）	★★★ 高

優先順位 :

1. 情報をオープンに（ツール導入で着手しやすい）
2. 稟議の簡素化（制度変更、影響大）
3. 評価制度の変更（個人裁量を評価）
4. マネージャーの意識変革（時間がかかる、継続的に）

ケース: クラフトワークスが急成長して構造が追いつかなくなった

第2部で紹介したクラフトワークス（50名）が、2年後に120名に急成長したとする。何が起きるか。

発生した問題

領域	症状	根本原因
協働	「誰が何をやっているかわからない」	人数が増えて情報共有の仕組みが追いつかない
自律	「勝手に決めていいのかわからない」	暗黙のルールが共有されず、新メンバーが判断に迷う
貢献	「顧客の声が届かない」	CSと開発の距離が遠くなった
帰属	「何のためにやってるんだっけ」	ミッションが形骸化、新メンバーへの浸透不足

10要素での診断

要素	50名時点	120名時点	ギャップ
帰属	◎ 全員が原体験を共有	○ 新メンバーは「聞いたことがある」程度	浸透の仕組みが必要
自律	◎ 暗黙知で動ける	△ 判断基準がわからない	原則の明文化が必要
協働	◎ 全員の顔が見える	△ チーム間の壁ができた	情報共有の再設計が必要
貢献	◎ CSと開発が近い	△ 中継が増えて距離が遠い	顧客接点の再設計が必要

構造変更の優先順位

変更内容	影響範囲	難易度	優先度	理由
全社会議でミッション再共有	全社	低	★★★ 高	帰属の再構築、すぐできる
判断原則の明文化	全社	中	★★★ 高	自律の回復、新メンバーの迷いを解消
チーム横断の情報共有会	全社	低	★★★ 高	協働の回復、週次で開始可能
開発メンバーの顧客同席	開発	中	★★ 中	貢献の回復、段階的に導入
チーム再編成	全社	高	★ 低	影響大だが、上記で改善しなければ検討

変更シナリオ

• フェーズ1: 即効性のある施策
  • 全社会議でミッション再共有
  • 判断原則を5つに明文化
  • 週次の全社情報共有会を開始
• フェーズ2: 仕組みの整備
  • 新メンバー向けオンボーディング強化
  • 開発メンバーの顧客MTG同席を制度化
  • チーム間連携の定例を設計
• フェーズ3: 構造の見直し
  • 必要ならチーム再編成を検討
  • 評価制度の見直し

ポイント

• 10要素の重み付けは変えない（「うちらしさ」は維持）
• 構造・仕組みを10要素に合わせて再設計する
• いきなり大きな変更をせず、小さく始めて効果を検証する

このように、10要素モデルは「何が問題か」を診断し、「何を優先すべきか」を判断するフレームワークとして機能する。

9.5 変更の進め方

フェーズ1: パイロット
特定チーム/部門で先行実施。効果と問題点を検証。成功事例を作る。

フェーズ2: 展開
パイロットの学びを反映。全社に展開。抵抗への対処。

フェーズ3: 定着
新しい構造を「当たり前」に。評価・報酬との整合性を確認。継続的な改善。

9.6 構造変更の罠

罠1: 構造だけ変えて、運用が変わらない
「フラットにしました」と言っても、実態は変わらない。構造変更と同時に「何が変わるのか」を具体的に伝える。

罠2: 変えすぎて混乱
一度に多くの構造を変えると、何が原因で何が起きたかわからない。優先順位をつけて、段階的に。

罠3: 現場の声を聞かない
上から構造を押し付けると、抵抗が生まれる。現場を巻き込んで設計する。

罠4: 評価制度を変えない
構造を変えても、評価が変わらないと行動は変わらない。構造変更と評価制度変更はセットで考える。

まとめ

10. 10要素モデルから組織構造を導出できる

11. この整理の価値

1. 組織構造の変更に「なぜ」を与えられる
構造変更の議論が「うちらしさ」に紐づく。「なぜこの構造なのか」を10要素で説明できる。

2. 構造と文化の整合性をチェックできる
10要素と構造がズレていたら、どちらかを直す必要がある。「文化は自律重視なのに、構造がマイクロマネジメント型」→ 矛盾を発見できる。

3. 採用・評価との一貫性が保てる
10要素で採用し、10要素で評価し、10要素に基づく構造で働く。一貫性があると、カルチャーが強くなる。

チームトポロジーとの関係

チームトポロジーは「効率」の話だった。10要素モデルからの組織設計は「効果」から始まり「効率」までを射程に入れる。

フレームワーク	扱う範囲	前提
10要素モデル	効果（帰属）〜効率（内容・快適さ・協働）	なし
チームトポロジー	効率（認知負荷の管理）	帰属が明確

方向性が定まっている組織では、チームトポロジーは有効なツールになる。しかし、まず「何に向かうか」「何を大事にするか」を明確にすることが先だ。

10要素を言語化し、それに基づいて組織構造を設計する。このアプローチは、MVVやOKRよりも具体的で、「どこを優先してどこを諦めるか」の議論がしやすい。構造は戦略に従い、戦略は「らしさ」に従う。

12. このモデルが向かないケース

10要素モデルは万能ではない。以下のような状況では、別のアプローチが適している場合がある。

ケース	理由	代替アプローチ
緊急のターンアラウンド	事業存続の危機では「楽しさ」より「生き残り」が優先。トップダウンで迅速に動く必要がある	まず止血、その後に10要素で再設計
高度に標準化されたオペレーション	コールセンターや物流センターなど、個人の裁量より効率・品質の均一性が重要な場合	プロセス設計を優先、10要素は採用・定着に活用
短期プロジェクト型の組織	数ヶ月で解散するチームでは、10要素を深く言語化する投資対効果が低い	最低限の帰属（目的）のみ明確化
創業直後のカオス期	2〜3名で走っている段階では、構造設計より「とにかくやる」が優先	10名を超えたら10要素を言語化し始める

また、10要素モデルには以下の前提がある。

前提1: 「楽しさ」が持続的な成果につながると信じている
「楽しくなくても成果が出ればいい」という価値観の組織には合わない。

前提2: 経営陣が10要素を言語化し、共有する意志がある
トップが「そんなの面倒」と思っていると機能しない。

前提3: ある程度の時間軸で組織を考えている
半年で売却予定の会社に、10要素を整備する意味は薄い。

これらの前提が満たされない場合、10要素モデルは「良いフレームワークだが、今じゃない」という判断もありえる。

13. 10要素間のトレードオフ

10要素すべてを最大化することはできない。何かを重視すれば、何かが犠牲になるか、コストがかかる。

トレードオフ	説明
自律 vs 協働	「各自が勝手に決める」を極めると、足並みを揃えるコストが上がる
達成 vs 成長	短期の数字を追いすぎると、学習や挑戦の余白がなくなる
自律 vs 承認	自律を重視すると「自分で決めて自分で責任を取る」が求められ、承認を求める人には厳しい環境になる
貢献 vs 快適さ	顧客接点を最大化すると、社内の効率化が後回しになることがある
内容 vs 協働	専門性を深掘りしすぎると、チーム間の連携が難しくなる

重要なのは、トレードオフを認識した上で、意図的に選択することだ。

「うちは自律を最重視する。だから協働のコストは受け入れる」と言えれば、それは健全な選択だ。問題なのは、トレードオフを認識せずに「全部やろう」として、どれも中途半端になること。

すべてを◎にするのは不可能であり、だからこそ「何に重みを置くか」というトレードオフの決断が経営者の仕事である。

10要素モデルは「何を優先し、何を諦めるか」を明示的に議論するためのツールでもある。

14. 組織の「サイズ」と「フェーズ」による変数

10要素モデルの適用方法は、組織の規模とフェーズによって変わる。

サイズ別の特徴

規模	10要素モデルの使い方	注意点
〜10名	暗黙知で十分。言語化より「やってみる」が優先	創業者の価値観がそのまま10要素になる
10〜30名	言語化の始めどき。「なぜそうしているか」を説明する場面が増える	採用時に伝える「らしさ」が必要になる
30〜100名	本格的な設計が必要。部署間の整合性を意識しないと、サブカルチャーが乱立	マネージャー層への浸透が鍵
100〜300名	構造的な仕組み化が必須。10要素を制度・プロセスに落とし込む	「例外」の扱いが難しくなる
300名〜	事業部ごとに変数を持たせる判断が必要に。全社共通の「芯」と、事業部ごとの「色」を分ける	全社で統一しすぎると硬直化、分けすぎると求心力低下

フェーズ別の特徴

フェーズ	重視しやすい要素	後回しになりがちな要素
立ち上げ期	帰属（ミッションへの共感）、達成（PMF達成）	快適さ、承認
成長期	成長（学習機会）、貢献（顧客インパクト）	協働のコスト管理
安定期	協働（組織効率）、快適さ（環境整備）	達成の緊張感
変革期	自律（新しい挑戦）、帰属（再定義）	安定・予測可能性

規模拡大時の典型的な課題

10名→50名の壁で起きること：

• 「阿吽の呼吸」が通じなくなり、協働のコストが急上昇
• 全員が創業メンバーと直接話せなくなり、帰属の希薄化

50名→150名の壁で起きること：

• 専門部署ができ、内容の分化が進む
• 「自分の仕事がどう貢献しているか」が見えにくくなり、貢献の実感が薄れる

150名→500名の壁で起きること：

• 事業部制や職能制の選択が迫られ、帰属の源泉の再設計が必要
• 評価制度の公平性が問われ、承認の仕組みが複雑化

それぞれの壁で、10要素のどこにテコを入れるべきかを意識することで、成長痛を予見しやすくなる。