マトリクス組織

英語名 Matrix Organization
読み方 マトリクス オーガニゼーション
難易度
所要時間 組織設計3〜5時間
提唱者 NASA(1960年代のプロジェクト管理)
目次

ひとことで言うと
#

メンバーが 機能部門(専門領域)と事業部門(プロジェクト/製品)の2つの報告ラインを同時に持つ 組織構造。専門性の深化とビジネスニーズへの対応を両立できる反面、権限の曖昧さや意思決定の遅さが課題になりやすい。

押さえておきたい用語
#

押さえておきたい用語
機能軸(Functional Line)
エンジニアリング、マーケティング、人事など専門領域ごとのライン。スキル育成・採用・評価を担当する。
事業軸(Business / Project Line)
製品・地域・プロジェクトなどビジネス目標ごとのライン。成果の達成とリソース配分を担当する。
ツーボス問題(Two-Boss Problem)
2人の上司から異なる指示を受け、メンバーが板挟みになる状態。マトリクス組織の最大の課題。
ストロングマトリクス
事業軸(プロジェクトマネージャー)の権限が強い形態。リソース配分とタスク指示はPMが握り、機能マネージャーは技術指導に専念する。

マトリクス組織の全体像
#

機能軸と事業軸が交差する二重構造
開発部門営業部門マーケ部門製品A製品B製品CABCDEF機能軸→事業軸↓各メンバーは2人の上司を持つ機能マネージャー(スキル育成)+事業マネージャー(成果達成)
マトリクス組織導入の進め方
1
2軸を定義
機能軸と事業軸をそれぞれ明確にする
2
権限を分割
誰が何を決めるかのルールを明文化する
3
コンフリクト解消
対立発生時のエスカレーション手順を決める
定期チューニング
権限バランスを四半期ごとに見直す

こんな悩みに効く
#

  • 部門の壁が厚く、横断プロジェクトが進まない
  • 専門性は育つが、ビジネス全体を見られる人材が育たない
  • 複数の製品ラインや地域を横断的にマネジメントしたい

基本の使い方
#

2つの軸を明確に定義する

機能軸と事業軸の組み合わせは企業によって異なる。自社に合った軸を選ぶ。

  • 機能 × 製品: メーカーに多い(開発・営業・製造 × 製品A・B・C)
  • 機能 × 地域: グローバル企業に多い(マーケ・営業・サポート × 日本・APAC・欧州)
  • 機能 × プロジェクト: IT企業に多い(エンジニア・デザイナー × PJ1・PJ2)
権限の分割ルールを明文化する

ツーボス問題を防ぐため、「誰が何を決めるか」を具体的に決める。

意思決定事項機能マネージャー事業マネージャー
スキル育成・研修×
タスクアサイン・優先順位△(相談)
人事評価○(技術力)○(成果)
採用△(相談)
コンフリクト解消のプロセスを設計する

2つの軸の間で対立は必ず起きる。放置せず、迅速に解決するルールを用意する。

  • 48時間以内に当事者同士で話し合い
  • 解決しなければ上位のマネージャーにエスカレーション
  • 四半期に1回、権限のバランスを全体で見直す

具体例
#

例1:IT企業がプロジェクト型マトリクスに移行して開発速度を上げる

状況: 従業員100名のWeb開発会社。機能部門制(フロントエンド部・バックエンド部・デザイン部)を敷いていたが、「プロジェクトの要件が部門間で共有されない」「会議だけで1日が終わる」状態だった。

マトリクス導入

  • 機能軸: 各技術領域のスキル育成と採用
  • 事業軸: プロジェクトマネージャーが各PJのタスク管理と優先順位を決定
  • エンジニアは機能部門に「所属」しつつ、日常業務はPMの指揮下で動く
指標導入前導入6か月後
平均リリースサイクル6週間3週間
部門間の調整会議週5回週2回
メンバーの「仕事の見通しが立つ」評価2.8/5.03.9/5.0

最初の2か月は「誰に報告すればいいかわからない」という混乱が出たが、権限分割表を全員に共有してからは安定した。

例2:消費財メーカーが地域×機能のマトリクスで海外展開を加速する

状況: 従業員800名の化粧品メーカー。日本市場が成熟し、東南アジアへの本格展開を計画。しかし、機能部門(商品開発・マーケ・営業)が日本市場の論理で動いており、現地ニーズへの対応が遅れていた。

マトリクス設計

  • 機能軸: 商品開発・マーケティング・SCM(本社主導)
  • 地域軸: 日本・タイ・インドネシア・ベトナム(各国GMが主導)
  • 各国のマーケティング担当は、本社のマーケ部長と現地GMの両方に報告

東南アジアの売上は導入初年度で 前年比35%増。現地マーケ担当が「本社の知見を活かしつつ、現地に合った施策を打てるようになった」と報告。タイ市場では現地限定パッケージを3か月で企画・発売し、初月 目標比120% の売上を記録した。

例3:大学病院が診療科×プロジェクトのマトリクスで研究と臨床を両立する

状況: 病床数600床の大学病院。各診療科が独立して動いており、複数科にまたがる臨床研究プロジェクトの進捗が遅く、論文発表数が5年間で 30%減少 していた。

マトリクス導入

  • 機能軸: 各診療科(内科・外科・放射線科など)→ 臨床業務と人材育成
  • プロジェクト軸: 研究プロジェクト(がんゲノム研究・AI診断支援など)→ 研究主任が横断チームを統括
  • 各医師は診療科に所属しつつ、週の 20% を研究プロジェクトに充てるルール

2年後、複数科共同の論文発表数が 年12本 → 年28本 に増加。「他科の視点が入ることで研究の質が上がった」と研究主任が評価している。

やりがちな失敗パターン
#

  1. 権限を明文化しない — 「臨機応変に」で済ませると、メンバーが常に板挟みになる。何を・誰が決めるかを書面で共有する
  2. ツーボスの優先順位を決めない — 2人の上司から矛盾する指示が来たとき、どちらを優先するかのルールがないと現場が混乱する
  3. コミュニケーションコストを甘く見る — マトリクスは報告ラインが増える分、会議や調整の時間も増える。効率的な情報共有の仕組みが必須
  4. 全社一律で導入する — マトリクスが有効な部門とそうでない部門がある。全社導入ではなく、複合的な課題を持つ部門から段階的に始める

まとめ
#

マトリクス組織は専門性と事業ニーズを両立させる強力な構造だが、運用コストも高い。成功の鍵は「権限の明文化」と「コンフリクト解消のプロセス設計」。導入前に「ツーボス問題をどう防ぐか」を徹底的に詰めておくことが、混乱を最小限に抑える。