機能マップと組織マップは別物である

ここまでの章は「人事には何という機能があるか」を扱ってきました。 この章の問いは「その機能を誰が担うか」です。 この2つはよく混同されますが、独立した設計変数です。 同じ8機能でも、本社人事部が集権的に担うことも、事業部門に分散させることも、 外部にアウトソースすることも、AIに自動化させることもできます。 エンジニアリングで言えば、論理アーキテクチャ(機能分解)と物理アーキテクチャ(デプロイと責任分担)の違いです。

世界標準の語彙 — Ulrichの4役割と3ピラー

4役割モデル(1997)

現代の人事組織論の出発点は、Dave Ulrich『Human Resource Champions』(1997年)の4役割モデルです。 「戦略↔日常業務」「プロセス↔人」の2軸で、人事が果たすべき4つの役割を定義しました:Strategic Partner(戦略パートナー)、Change Agent(変革推進者)、Administrative Expert(管理エキスパート)、Employee Champion(従業員擁護者)。 「人事は管理部門ではなく事業への戦略的貢献者であるべきだ」という再定義が、その後30年の人事組織改革の思想的基盤になりました。

3ピラーモデル(HRBP / CoE / Shared Services)

4役割を組織構造として実装したのが、いわゆる3ピラーモデル(三本脚の椅子)です。

graph TB
  subgraph biz[事業部門]
    BP[HRBP<br/>事業に埋め込まれた<br/>戦略パートナー]
  end
  subgraph hq[本社人事]
    CoE[CoE<br/>Centers of Expertise<br/>採用・報酬・育成等の<br/>制度設計専門家]
    SS[Shared Services<br/>給与・手続き等の<br/>定型業務を集約]
  end
  BP <-.事業ニーズを制度へ.-> CoE
  CoE -.制度・ポリシー.-> SS
  SS -.オペレーション実行.-> biz
  Tech[データ基盤・HRテクノロジー] -.全体を下支え.-> hq

  style BP fill:#10b981,stroke:#059669,color:#fff
  style CoE fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style SS fill:#6b7280,stroke:#4b5563,color:#fff
  style Tech fill:#f97316,stroke:#ea580c,color:#fff
Ulrich型3ピラー。HRBPが事業側に立ち、CoEが制度を設計し、Shared Servicesが定型業務を捌く。データ基盤が全体を支える。

3ピラーの失敗パターン

3ピラーは世界の大企業人事の共通言語になりましたが、完全実装は少数派です。 よく引用される調査では、3要素すべてを実装している組織は約18%にとどまり、1〜2要素の部分採用が主流とされます。 そして失敗パターンは驚くほど定型的です。

  • HRBPの運用業務埋没: 戦略パートナーのはずが、労務トラブル対応と手続きに忙殺される「何でも屋のシニアジェネラリスト」になる
  • ピラー間のサイロ化: HRBP「CoEの制度は現場で使えない」⇔ CoE「HRBPが制度を実装しない」⇔ SS「戦略を知らされず処理だけ」という相互不信
  • 責任の空白: 従業員体験全体のオーナーが不在になる(3つに割ったことで、誰の担当でもない継ぎ目が生まれる)
  • 前提の不足: 役割の明確化・プロセス統合・データ基盤への投資なしに組織図だけ変えて失望する

第1章で見た「機能の縦割りの弊害」が、組織モデルのレイヤーでも再演されるわけです。 分割統治はインターフェース設計とセットでなければ、単なる分断になります。

選択肢は一つではない — McKinseyの5アーキタイプ

「では3ピラー以外に何があるのか」に答えるのが、McKinseyが2022年12月に公表した 「HR's new operating model」(CHRO 100名超へのインタビューに基づく)の5つのアーキタイプです。 すべてのアーキタイプは2つの共通基盤——Data backbone(一貫したデータ基盤)とService backbone(高信頼のサービス基盤)——の上に成り立つとされます。

アーキタイプ概要向いている組織
Ulrich+(48%)古典3ピラーの進化版。HRBPが専門性を持ちCoEから実行責任を引き取る成熟・安定した大企業
EX-driven(47%)従業員体験ジャーニーの構築を最優先し、重要接点にリソースを集中人材獲得競争が激しい人材依存型組織
Leader-led(36%)HRの説明責任をライン管理職へ移し、管理職にツールと支援を提供現場の自律性が高いR&D志向組織
Agile(31%)HRBPは少数で経営助言に特化、部門横断チームが施策を高速実装成長・変革期の組織
Machine-powered(6%)アルゴリズムが選抜・育成判定・離職分析を担い、HRは助言役へデジタルネイティブ組織

%はCHROが「自社に近い」と上位2つに選んだ割合(複数回答)です。 Ulrich+とEX-drivenが拮抗している点、そしてLeader-led(ライン管理職への権限移譲)が3位につけている点は、 次に見る日本のジョブ型移行の方向と綺麗に重なります。

日本の権限分掌の転換 — ジョブ型人事指針20社が示すもの

日本における組織マップの転換を、最も具体的に記録した一次資料が、 2024年8月に内閣官房・経産省・厚労省が公表した「ジョブ型人事指針」です。 導入済み20社(富士通・日立製作所・ソニーグループ・KDDI・メルカリ等)について、 制度の骨格だけでなく「人事部と各部署の権限分掌」を各社に開示させた点が画期的でした。 そこに現れた共通パターンと個別の知見を見ます。

共通パターン — 集権人事部からラインへ

企業権限分掌の変化(指針記載の要旨)
富士通「人事部主導で採用人数を決めて各事業本部に割り振る」方式を逆転。各部署が事業計画から必要人員数と採用人数を決め、人事部門は意思決定支援へシフト
日立製作所採用・人員配置・昇格・処遇の権限を各事業部門に付与。人事部門はHRBP/CoE/HRSSの3機能に分化(3ピラーの明示的実装)
ソニーグループ人事権限は基本的に現場マネジメントに付与。各部署長に人件費予算を配分し、人員計画に応じて補充
KDDI制度の骨格は人事部が決め、現場が意思決定する運用へ。「いきなり現場に任せても決められない」ため人事部が「サブルール」を用意
メルカリ事業部門の裁量を相当程度認め、人事部は制度企画・全社運用方針・制度の一体性確保を担当。連携はHRBP経由

共通するのは、採用・配置・処遇という機能の権限がラインへ移り、人事部が「実行者」から「制度設計者・支援者」へ再定義される動きです。 第2章で見た「100年続いた強い本社人事部」の構図が、政府文書に記録される形で書き換わりつつあります。 McKinseyの語彙で言えば、日本の大企業は集権型からLeader-led+Ulrich+のハイブリッドへ移行していると読めます。

移行の落とし穴 — レゾナックの警句とDeNAの教訓

ただし指針と事例には、単純な「権限移譲万歳」ではない知見も刻まれています。

もう一つの教訓はDeNAです。同社は2014年にHR本部内へHRBP組織を作り、2018年にHRBPを事業部直属に移しました。 ゲーム事業では現場を巻き込む「採用番長」制度で年間200名超の採用を実現するなど成果を挙げた一方、事業部直属化によって、エース人材を全社最適で異動させることが難しくなるという副作用が語られています。 分権は事業への密着度を上げますが、全社の人材ポートフォリオ管理(第4章の配置機能)とトレードオフになる—— レポートラインの設計一つで機能マップの効き方が変わる好例です。

企業規模と組織モデル — 1人目人事からフル3ピラーまで

組織モデルは規模に強く依存します。スタートアップから大企業までの目安を整理します (数値は主に米国の実務知見で、確立された研究値ではない点に注意)。

フェーズ人事機能の持ち方ポイント
〜30名創業者・経営陣が人事を兼務。労務は社労士等へ外部化制度を作り込まない。採用とカルチャーの言語化(MVV)に集中
30〜50名1人目人事の採用タイミングの目安(米国調査では40〜50名が平均)1人目はジェネラリスト。ATS導入・採用プロセス整備・雇用契約の法的チェックから
51〜100名人事チーム化。等級・評価・報酬の3本柱を初めて整備「全員を知っている」マネジメントが破綻する規模。制度による公平性が必要に
100〜1,000名採用・労務・制度企画など機能別に分化データ基盤(従業員マスタ一元化)をこの段階で整えると後が楽
1,000名超フル3ピラー(HRBP/CoE/SS)が視野に。HR-to-employee比は規模とともに低下(SHRM 2024: 100人未満1:40→1000人以上1:140)サイロ化対策(ピラー間のインターフェース設計)が本丸になる

理解度チェック

問題 0 / 50%
Q1

Ulrich型3ピラーモデルは、事業に埋め込まれた戦略パートナーである____(アルファベット4文字)、制度設計の専門家集団であるCoE、定型業務を集約するShared Servicesで構成される。