「部門横断でプロジェクトを進めろ」と号令をかけたのに、現場が動きません。会議は開いても決まらず、決めても各部門に持ち帰った瞬間に止まります。心当たりのあるPM・PL、IT統括責任者は少なくないはずです。
クロスファンクショナルチーム(CFT)が機能しない背景には、熱意や能力の不足だけでは説明できない要因があります。役割・権限・情報共有が縦割りのまま放置された、構造の問題です。本記事では、失速しやすい3つの原因とPMOによる立て直しの手順を解説します。
- ✓クロスファンクショナルチーム(CFT)とタスクフォースの関係、中長期型と短期型の使い分け
- ✓部門をまたいだチームが動かなくなる3つの構造的原因(ガバナンス不在・KPI不整合・権限委譲の失敗)
- ✓機能不全のサインが、いつ・どこに表れるか(会議の形骸化・決定事項の未実行)
- ✓機能するチームへ変える実践的な打ち手(意思決定ルール・共通KPI・ファシリテーション)
- ✓PMOがCFTで果たす役割と、PMとPMOの役割分担
- ✓立ち上げ直後・運営中・停滞サイン別に使える運営チェックリスト
1. クロスファンクショナルチーム(CFT)とは? タスクフォースとの違いから整理する
クロスファンクショナルチーム(CFT)とは、営業・開発・情報システム・経理といった複数の機能部門のメンバーで構成される、部門横断の活動体です。一つの部門だけでは解けない課題に取り組むための編成です。たとえば全社的な業務プロセス改革やDX推進、基幹システムの刷新が対象になります。それぞれの現場知見を持ち寄って当たるのが狙いです。号令だけでは動かないのは、この「持ち寄り」の設計が抜けているからです。
1-1. CFTの定義:部門の壁を越えて課題に当たる横断チーム
CFTの本質は、特定の部門の指揮命令系統に閉じないことです。通常の組織では、社員は自部門の上司の指示で動きます。評価も自部門の目標で決まります。ところがCFTは、その縦のラインをまたいで人が集まる横のチームです。だからこそ、部門をまたいで初めて見えるボトルネックを発見できます。
その一方で、「誰の指示で動くのか」「何で評価されるのか」が宙に浮きやすいという弱点も抱えます。この宙ぶらりんの状態が、第2章で扱う機能不全の起点になります。皆さまの現場のCFTは、人を集めただけで終わっていないでしょうか。
1-2. タスクフォースとの違い:重なりと使い分けを整理する
CFTとタスクフォースは、対立する概念ではなく重なり合います。CFTは「部門横断である」という構成を表す言葉です。タスクフォースとは、特定の課題のために期限を区切って編成し、その課題が解決すれば解散する臨時の組織です。部門横断のタスクフォースなら、両方に当てはまります。実務では、継続テーマを扱う中長期のCFTと、短期集中のタスクフォースを使い分ける場面が多くあります。次の表は、その両極を対比した例です。
| 観点 | 中長期型のCFT(例) | 短期のタスクフォース(例) |
|---|---|---|
| 期間 | 比較的中長期・常設に近い運用もある | 期限を区切った一時的な編成 |
| 目的 | 継続テーマの推進・全社最適の追求 | 特定の緊急課題の解決 |
| 解散の目安 | テーマ継続中は存続 | 課題解決とともに解散 |
| 運営上の勘所 | 評価・報告の仕組みを恒常的に組み込む場面が増える | 短期集中ゆえ意思決定の速さが要になる |
この対比が運営を左右する理由は、存続期間が長いほど「片手間参加」の綻びが蓄積するからです。数週間で解散するタスクフォースなら、勢いで乗り切れる場面もあります。しかし半年・一年と続くCFTでは、参加者の評価も報告ラインも縦割りのままだと動機が続きにくくなります。CFTほど、次章以降で扱うガバナンスやKPIの設計が効いてくるわけです。
CFTは部門横断という構成を、タスクフォースは臨時編成を表す言葉で、両者は重なります。長く続くCFTほど、その場の勢いよりも、役割・評価・報告の恒常的な仕組みが運営を左右します。
2. なぜ部門をまたいだチームは動かなくなるのか──3つの構造的原因
部門をまたいだチームが動かなくなる要因は、人の意識よりも仕組みの側にあります。原因を「メンバーの当事者意識が低い」で片づけると、打ち手が人の入れ替えや精神論に向かい、再発しやすくなります。本記事では、実務で効いている構造を次の3つに整理します。
- ガバナンス不在(決定権とエスカレーション先が未定義)
- KPIの不整合(部門目標が全体最適に優先する)
- 権限委譲の失敗(動かす手段が渡っていない)
いずれも設計の欠落であり、個人の能力の話ではありません。順に見ていきます。
2-1. ガバナンス不在:「誰が、何を、どこまで決めてよいのか」が曖昧
第一の原因は、意思決定の枠組み、すなわちガバナンスが定義されていないことです。ガバナンスとは、誰にどこまでの決定権があり、決められないときは誰に上げるのかを定めた統制のルールです。
CFTでは各部門の代表が集まります。ただ、その代表が自部門を代表して即決できる立場なのか、持ち帰って上司の承認を得る立場なのか。そこが曖昧なまま、会議は進みがちです。
結果として、その場では結論が出ません。持ち帰り、次回また同じ議論を繰り返します。エスカレーション先が決まっていないため、宙に浮いた論点が延々と滞留します。
これは意欲の問題ではなく、権限設計の欠落が生む症状です。ステークホルダーの利害調整の設計は、ステークホルダマネジメントの実践法もあわせてご覧ください。
2-2. KPIの不整合:部門の目標が全体最適に優先してしまう
第二の原因は、評価指標(KPI)の不整合です。参加者は日常、自部門のKPIで評価されています。営業は売上、情報システムはセキュリティと安定稼働、開発は納期と品質です。
それぞれ正しい指標ですが、横断プロジェクトの場では衝突します。基幹システム刷新では、業務効率を上げたい業務部門と、セキュリティ要件を優先したい情報システム部門が対立しがちです。
CFT共通のゴールと、各人が自部門で負っているKPIが噛み合っていないと、参加者は自部門を優先しやすくなります。意識の低さではなく、報告体制が縦割りのままでは動機が生まれにくいという構造的な課題です。
IPA「DX白書2023」では、DX推進を阻む要因として組織間・部門間の連携の課題が挙げられています。これは課題の傾向を示す記述で、企業ごとの連携度合いを測った数値ではありません。それでも、部門連携に課題を残す企業があることは読み取れます。
2-3. 権限委譲の失敗と、機能不全が表に出るサイン
第三の原因は、権限委譲の失敗です。トップは「任せた」と言うものの、実際には予算も人事も動かせる権限がチームに渡っていません。号令だけが降りてきて、動かす手段が伴わない状態です。
背景の一つとして考えられるのは、意図的に権限を絞る判断よりも、渡すべき権限の範囲がそもそも定義されていないケースです。プロジェクト憲章や規程にチームの決裁枠が書かれていなければ、担当者は判断のたびに上長へ伺いを立てるしかありません。
それが表面化するのは、外部ベンダーへの発注可否、要件変更の承認、追加リソースの確保といった判断を求めた瞬間です。決裁権の所在が分からず、そこで足が止まります。対策の方向は、一定金額以下の費用支出や役割変更、スコープの微調整について、委ねる範囲を明文化することです。明文化すれば自動的に解決するわけではありませんが、止まる箇所を減らす土台になります。
3つの構造的原因は、次のような機能不全のサインとなって表面に出ます。立ち上げ直後は盛り上がっても、数か月のうちに会議が形骸化し、やがて名目だけが残ります。本記事で扱う、横断プロジェクトの失速の型です。下の表は、どの兆候がどの原因に結びつくかを整理したものです。自チームのどこに当てはまるか、照らし合わせながら読んでみてください。
| 表に出るサイン | 背後にある構造的原因 |
|---|---|
| 会議が報告会化し、結論が出ない/毎回「持ち帰り」で終わる | ガバナンス不在(決定権とエスカレーション先が未定義) |
| 決定事項が各部門で実行されない/握った約束が守られない | KPI不整合(自部門目標が優先される) |
| 現場が判断を上に上げても止まる/誰も決められない | 権限委譲の失敗(動かす手段が渡っていない) |
機能不全を「参加メンバーの意識の問題」と診断すると、打ち手が人の入れ替えや叱咤に向かい、再発しやすくなります。見るべきは、役割・権限・評価・報告という「仕組み」が縦割りのまま放置されていないかです。
3. 機能不全がプロジェクトにもたらすリスク
CFTの機能不全は、動きの悪さで終わらず、納期とコストに跳ね返ります。代表的な波及は、意思決定の遅延とスコープの膨張の2つです。「動かないだけなら、いずれ追いつく」という楽観は、この2つを見落とします。順に見ていきます。
3-1. 意思決定の遅延が、クリティカルパスを侵食する
意思決定の遅延は、クリティカルパス上で起きると最終納期の遅れにつながります。クリティカルパスとは、全体の納期を直接左右する、いちばん余裕のない作業の連なりです。横断プロジェクトでは、部門間の合意が必要な論点が工程の随所に現れます。その合意が滞ると、後続作業が着手できず待たされます。
「決まらない会議」の一週間は、単なる一週間ではありません。判断待ちで止まった作業が積み上がれば、リカバリーに要する工数も膨らみやすくなります。意思決定の遅延は、静かに進行するコスト超過の原因の一つです。
3-2. 曖昧な合意が、スコープの膨張(スコープクリープ)を招く
曖昧な合意は、スコープの膨張を招きます。スコープクリープとは、スケジュールやコスト、資源の調整を伴わないまま、やるべき範囲が管理されずに膨らんでいく現象です。
CFTでは各部門が「うちの要望も入れてほしい」と持ち込みます。誰がどこまでを決裁するかが曖昧だと、要望が交渉の力関係でなし崩しに取り込まれます。正式な変更管理を経ていない点が問題で、統制された仕様変更とは区別すべき状態です。範囲が膨らめば、工数も納期も予算も圧迫されます。合意のルールが弱いチームほど、この膨張を止めにくくなります。
CFTの機能不全は、意思決定遅延によるクリティカルパスの侵食と、統制なきスコープ膨張という形で、納期・コストに跳ね返ります。だからこそ、早い段階で構造に手を入れる意味があります。
4. 機能するチームに変える実践的な打ち手
機能するチームに変える起点は、決め方・測り方・話し合い方のルールを整えることです。原因が構造にある以上、打ち手も構造に効くものを選びます。本記事では、意思決定ルールとRACI、共通KPI、会議体の3つを取り上げます。特別なツールの導入は前提にしません。
4-1. 意思決定ルールとRACIを設計する
最初に着手すべきは、「誰が何を決めるか」を可視化することです。ここで有効なのがRACIです。RACIとは、RAM(責任分担マトリクス)の代表的な一形式で、タスクごとに関与者の役割を4種類で割り当てる手法です。割り当てる役割は次の4つです。
- R(Responsible=実行責任・複数可)
- A(Accountable=説明責任・原則1タスク1人)
- C(Consulted=双方向で相談する相手)
- I(Informed=結果を知らされる相手)
Aを1人に定めると、「最後は誰が決めるのか」が明確になりやすくなります。あわせて、チームで決められない論点を誰に上げるかというエスカレーションパスと、チームに委ねる決裁枠も定義します。第2章で挙げた権限委譲の失敗に効く手当ては、ここに置きます。
作り方はシンプルです。主要な意思決定事項を列に、関係者を行に置き、マスを一つずつ埋めます。Aが分散している列や、空欄の目立つ列は、そのまま決定の空白地帯を表します。道具はスプレッドシートで十分です。初版は短時間で作り、キックオフの場で関係者の目の前で一つずつ合意を確認します。
この合意プロセスが抜けると、表はすぐ形骸化します。逆に、決定権のある担当者がその場で判断できる状態になると、「持ち帰り」議題を減らしやすくなります。表を作れば自動的に責任が明確になるわけではありません。関係者の合意と、その通りに運用することが前提になります。
4-2. 共通KPIを合意する
共通KPIとは、CFT全体で追う指標として設定し、各部門の代表と合意しておく目標です。狙いは、自部門KPIと横断ゴールの綱引きを、あらかじめ土俵の上で調停しておくことです。「業務効率」と「セキュリティ水準」のように相反しがちな指標は、どちらかを消すのではなく、両立の許容ラインを共通目標として言語化します。
ここで大切なのは、共通KPIの優先順位づけや投資判断そのものを、PMOが単独で決めない点です。それは業務オーナー・経営スポンサーが担う意思決定です。CFTやPMOは、その判断材料を比較可能な形に整える役回りです。決める人と支える人を、はっきり分けておきましょう。
4-3. ファシリテーターを置き、会議体を設計する
3つ目の打ち手は、会議を「決まる場」に変えることです。そのためにファシリテーターを置きます。誤解されがちなのは、ファシリテーションがその人自身が結論を出す営みではない点です。ファシリテーターの仕事は、場を整え、各部門の立場や懸念を引き出し、合意形成を前に進める支援です。結論を出す権限は、あくまで決裁者にあります。
会議体は、本記事では2層に分ける形を推奨します。週次や隔週の定例は、進捗の共有と軽微な課題に絞ります。チームに委ねた決裁枠を超える事項は、ステアリングコミッティの議題に上げます。
ステアリングは定例より低い頻度で開き、議題の優先順位づけと主要な判断の決裁を扱います。緊急案件は定例を待たず上申します。数値に表れない重大なリスクや判断事項も、議題に含めます。この分離によって、定例が「報告会」に傾きにくくなります。会議体や情報共有の設計を深めたい方は、プロジェクトコミュニケーション管理の極意が実務の助けになります。
株式会社オーシャン・コンサルティングでは、横断プロジェクトの体制づくりやPMO導入に関するご相談を随時承っております。
5. PMOがCFTに果たす役割──PMとの分担
第4章の打ち手を仕組みとして敷設し、回し続ける担い手がPMOです。ただし、PMOの役割はしばしば過大に語られます。本記事で想定するのは、「決める人」ではなく「決められる状態を設計・運用する人」としてのPMOです。下の図は、縦割りの部門とCFT、そしてPMOの位置関係を整理したものです。
5-1. 本記事のPMO像:意思決定者ではなく枠組みの設計・運用者
PMOがCFTのために担うのは、意思決定の枠組みづくりです。具体的には、RACIやエスカレーションパスの設計、共通KPIを比較できる形への整理、定例と上位会議体の設計、進捗の可視化、経営層への報告の橋渡しです。
ステアリングコミッティとは、経営層や関連部門の責任者で構成し、プロジェクトの重要な意思決定とエスカレーション対応を担う会議体です。PMOはこの場に判断材料を整えて上げます。優先順位や予算・投資判断そのものを下すのは、業務オーナーや経営スポンサーです。
PMOのファシリテーションは、対立を自動的に解消する魔法ではありません。各部門の立場と懸念を引き出し、合意形成を支える営みです。最終的な決着には、決裁者の意思決定が欠かせません。
5-2. PMとPMOの役割分担
PMとPMOは上下関係とは限らず、役割が異なります。PM(プロジェクトマネージャー)は個々のプロジェクトの達成に責任を負い、スコープ・スケジュール・コスト・品質・リスクを統合的にマネジメントします。一方PMOは、一つまたは複数のプロジェクトを対象に、標準化・支援・ガバナンスを担う組織機能です。指揮型のようにPMがPMOに報告する形もあります。
CFTの文脈では、個別テーマを前に進めるのはPMやチームリーダーの責任です。その土台となる共通ルールや会議体、報告の型を用意し、横串で支えるのがPMOです。
PMBOK Guide 第6版の分類では、PMOに支援型(Supportive)・管理型(Controlling)・指揮型(Directive)の3類型が示されています。
どれを選ぶかの目安は、本記事での推奨として次のように整理します。既存プロジェクトの延長で立ち上がった直後は、相談役に徹する支援型から入ります。社内標準への準拠が求められる場面では、管理型への移行を検討します。ただし正解は一つではなく、組織の成熟度や案件の重要度で適する型は変わります。
自社のCFTにどの関与度が適するかを見極めることも、体制設計の一部です。両者の違いはPMOとPMの違いと連携で詳しく解説しています。
5-3. 運営チェックリスト:立ち上げ直後・運営中・停滞サイン別
運営チェックリストは、立ち上げ直後・運営中・停滞サインの3局面に分けて使います。局面ごとにつまずき方が違うため、いまの局面に合う行だけを拾ってください。本記事での運営例です。自社の規程や案件に合わせて調整してください。
【立ち上げ直後】土台をつくる
- CFTの共通ゴールを言語化し、各部門と合意したか
- RACIで「A(説明責任)は1タスク1人」を割り当てたか
- 決められない論点のエスカレーション先を決めたか
- 定例会議と上位会議体(ステアリングコミッティ)を分けて設計したか
【運営中】規律を保つ
- 決定事項が各部門で実行されているかを追跡しているか
- 共通KPIと自部門KPIの衝突を、放置せず論点化しているか
- スコープ変更が正式な変更管理を通っているか
- 進捗と課題を経営層へ定期的に見える形で報告しているか
【停滞サインが出たら】原因を切り分ける
- 「決まらない」なら、決定権とエスカレーション先の不備を疑う
- 「決めたのに実行されない」なら、KPIと評価の不整合を疑う
- 「上げても止まる」なら、権限委譲の不足を疑う
未達の項目が、そのまま次の一手になります。共通ゴールが未合意なら、まず合意の場を設けます。Aが空欄の決定事項があれば、決裁者を1人決めます。診断を対処に折り返して使ってください。
チェックリストは「診断」の道具です。サインから原因を切り分け、人ではなく仕組みに手を入れます。この順序で進めると、立て直しの打ち手を外しにくくなります。
6. 結論:クロスファンクショナルチームは「構造」ごと立て直せる
CFTが機能しない背景には、参加者の努力不足よりも構造の問題があります。役割・権限・情報共有の仕組みが、縦割りのまま放置されている状態です。だからこそ打ち手も、精神論ではなく構造に効くものを選びます。意思決定ルールとRACI、共通KPIの合意、ファシリテーターと会議体の設計が、その起点です。
立て直しの進め方は、いきなり全部を変えないことがコツです。まずは機能不全のサインから原因を一つ切り分けます。そこに対応する仕組みを一つ入れ、効果を見て次へ広げます。小さな変更の積み重ねが、形骸化したチームを動かす力になります。変更を現場に定着させる進め方は、PMO流チェンジマネジメント実践法も参考になります。
そしてPMOは、その構造改革のアンカーになれます。決めるのは業務オーナーと経営スポンサー、支えるのがPMOです。この分担を守りながら、RACI・共通KPI・会議体・ステアリングコミッティを整えます。実際の支援でどう進めるかは、PMO支援実績もあわせてご確認ください。号令だけで動かないチームも、仕組みに手を入れれば動き出す余地が生まれます。
大手プライム案件で培ったPMO実務の経験から、現状整理のお手伝いをいたします。
株式会社オーシャン・コンサルティングでは、CFTの体制設計・会議体整備・PMO導入のご相談を随時承っております。
・Project Management Institute『PMBOK® Guide』第7版(2021)──8つのパフォーマンス領域のうち、チーム・パフォーマンス領域、ステークホルダー・パフォーマンス領域として参照。第7版は原則ベースへ移行した版。
・Project Management Institute『PMBOK® Guide』第6版(2017)──PMOの3類型(支援型・管理型・指揮型)、RAM/RACI、コミュニケーション管理の分類として参照。
・独立行政法人 情報処理推進機構(IPA)「DX白書2023」https://www.ipa.go.jp/publish/wp-dx/──DX推進を阻む組織間・部門間連携の課題の文脈として参照。
※引用した資料のみ記載しています。各URLは公開時点で実在を確認しています。
ITプロジェクトに特化したPMO専門組織です。プロセス定義・標準化・可視化・レポーティング環境の整備まで支援し、多数のPMO導入実績を有します。
30歳以上のPMOコンサルタントには「PMP」取得を義務付けています。



