部門横断的なCXプログラムの管理

CX変革のキックオフ会議で最も危険な瞬間は、反対意見が出た時ではない。全員がうなずいて「賛成します」と言った瞬間だ。マーケティングも、コンタクトセンターも、IT部門も、それぞれの言葉で賛意を示す。だが会議室を出た瞬間、各部門は自分の四半期目標に戻り、横断プログラムは静かに息を止めていく。

この現象には答えがある。CX横断プログラムが進まない最大の原因は、権限のなさそのものではない。権限のない立場で全社の意思決定を動かさなければならない、という構造を誰も設計していないことだ。プログラムオフィスは各部門の上に立てない。だからこそ、影響力を制度として作り込む必要がある。ガバナンス、意思決定権限、共有KPI、そしてエスカレーションの経路——これらを最初の90日で設計し切ったチームだけが、横断プログラムを1年後も生きたまま維持できる。

なぜCX横断プログラムは合意のわりに前に進まないのか

答えはシンプルだ。責任は全社に分散しているのに、成功の定義がすり合っていないからである。営業部門は成約率で評価され、カスタマーサポートは処理件数で評価され、プロダクト部門はリリース速度で評価される。CX変革チームが「顧客体験を良くしよう」と呼びかけても、それぞれの評価指標には一切反映されない。結果として、誰もが賛成しながら、誰も自分の優先順位を変えない。

これは悪意の問題ではない。個々の部門は与えられた目標に対して合理的に動いている。問題は、CXという横断的な成果に対して、誰も個人的な代償を払わずに済む設計になっていることだ。責任と権限がねじれている限り、キックオフの熱量は3か月で蒸発する。

CXプログラムオフィスの本当の役割は何か

CXプログラムオフィスの仕事は、施策を実行することではない。各部門の施策を、顧客が体験する一本のジャーニーとして整合させる調整機能である。実務を持たないまま調整だけを担うため、権威ではなく仕組みで影響力を作らなければならない。具体的には次の機能を担う。

• 単一の真実源の維持 — 顧客ジャーニーの全体像と、どのタッチポイントがどの部門の管轄かを一元的に可視化する。
• 優先順位の交通整理 — 複数部門から出てくる改善案を、顧客インパクトの大きさで並べ替え、リソースの奪い合いを減らす。
• 共通言語の設計 — NPS、CSAT、CESといった指標の定義を部門間で統一し、「同じ数字を違う意味で使う」事故を防ぐ。
• エスカレーションの受け皿 — 部門間で決着しない論点を、期限付きで上位の意思決定者に上げる経路を持つ。
• 進捗の可視化と説明責任 — 誰が何をいつまでに実行するかを、スプレッドシートではなく生きたロードマップで管理する。

この機能設計を最初から明文化しないプログラムオフィスは、結局「お願いする部署」になる。お願いは、四半期末の優先順位争いに必ず負ける。

部門間の縄張り意識はどこから生まれるのか

ここで行動経済学の視点が効く。人は自分が時間や労力を投じて作り上げたものに、実際の価値以上の重みを感じる。これは保有効果(endowment effect)として知られる現象で、行動経済学者のリチャード・セイラーが1980年に発表した論文で提示した概念だ。コンタクトセンターの責任者が自分の設計したエスカレーションフローに固執するのも、IT部門が旧システムの改修を渋るのも、単なる抵抗ではない。自分たちが構築したものを「失う」ことへの反応である。

さらに、ダニエル・カーネマンとエイモス・トベルスキーが1979年に学術誌Econometricaに発表した論文「プロスペクト理論」が示した損失回避の傾向も働く。人は同じ大きさの利得よりも損失を強く感じる。横断プログラムによる「顧客体験の向上」という利得は抽象的で、しかも成果が出るのは半年後や1年後だ。一方で「自分の裁量が減る」「自分のKPIが変わる」という損失は、キックオフのその日から具体的に迫ってくる。抽象的な利得と具体的な損失が天秤にかけられれば、損失が勝つ。これがCXプログラムが「賛成されながら実行されない」構造的な理由である。

この力学を理解すれば、対策は説得ではなく設計だとわかる。損失の感覚を減らし、利得を早期に具体化する仕組みを作ればいい。

ガバナンスをどう設計すれば横断プログラムは動くのか

ガバナンスは会議の数を増やすことではない。意思決定の摩擦を減らす構造を作ることだ。私が現場で繰り返し使ってきた順序は次の通りである。

1. 単一の北極星指標を決める — 部門ごとの指標とは別に、プログラム全体が動く理由となる顧客側の指標を一つだけ選ぶ。指標が二つ以上あると、部門は都合の良い方を選んで責任を回避する。
2. 三層のスポンサーシップを組む — 経営層の意思決定機関、部門横断の実行ワーキンググループ、日々の調整を担うプログラムオフィスという三層を最初に確定させる。誰が最終決定を下すかを後回しにしないことが肝心だ。
3. 意思決定権限を文書化する — どの論点をどのレベルで決めるかを、責任分担表として明文化する。ここが曖昧だと、すべての論点が結局トップに上がり、プログラムオフィスは単なる連絡係になる。
4. エスカレーションの期限を決めておく — 部門間で3営業日以内に合意できない論点は自動的に上位機関に上げる、といった具体的な期限を設ける。合意のない停滞ほどプログラムを消耗させるものはない。
5. 共有KPIを個人評価に接続する — プログラム全体の指標の一部を、関係部門のマネージャーの評価に組み込む。評価に反映されない指標は、誰にとっても優先順位の外側にある。
6. 統治のリズムを固定する — 週次の実務確認、月次の進捗レビュー、四半期のロードマップ見直しという頻度を最初から決めておく。頻度が不規則だと、忙しい部門は真っ先にプログラム関連の予定を削る。
7. ロードマップを一元管理する — 各部門の施策と顧客ジャーニーの改善点を、一つの可視化されたロードマップに統合する。分断された管理台帳が複数存在する限り、誰も全体像を持たない。

この手順の要は権限マトリクスとエスカレーション設計にある。詳細な運用ルールはエスカレーション戦略の設計として個別に固めておくと、論点が滞留する前に処理できるようになる。全体の統治構造そのものを外部の視点で組み立てたい場合は、CXガバナンス戦略の設計から着手するのが現実的だ。

共有KPIはなぜ部門の抵抗を溶かすのか

共有KPIが効くのは、精神論ではなく評価構造を変えるからだ。ゴール・グラディエント効果——目標に近づくほど努力が加速する現象——は、個人のKPIに紐づいた指標でしか発動しない。CX全体の指標を「見るだけの数字」から「評価される数字」に変えた瞬間、部門の行動は変わる。

ここで顧客体験の実感と自社評価のずれを軽視してはならない。ベイン・アンド・カンパニーが2005年に発表した調査レポートClosing the Delivery Gapでは、企業の80%が自社は優れた顧客体験を提供していると回答した一方、同じ体験を「優れている」と評価した顧客はわずか8%だったと報告されている。この落差は、各部門が自分の担当領域だけを見て「うまくやっている」と判断し、顧客が実際に横断的に経験する体験全体を誰も検証していないことから生まれる。共有KPIは、この検証責任を特定の誰かに固定する仕組みでもある。

チェンジマネジメントなしにガバナンスだけで機能するか

機能しない。ガバナンスは意思決定の構造を作るが、現場の行動を変えるのは人だ。ミドルマネージャーが新しいプロセスを「面倒な追加業務」と感じた瞬間、どれほど精緻な権限マトリクスも紙の上の理想になる。ハーバード・ビジネス・レビューに掲載されたマーティン・ハースとマーク・モーテンセンによる論文The Secrets of Great Teamwork(2016年)は、横断チームの成果を左右する要因として、明確な方向性だけでなく、心理的な安心感と協働の作法そのものを挙げている。ガバナンスは方向性を作るが、協働の作法を作るのはチェンジマネジメントの領域だ。

現場が変わらない典型的な理由は、新しいプロセスの意味を理解していないからではなく、変える動機が自分の評価にも生活にも結びついていないからである。ここで従業員体験の視点を欠かすと、CX変革は経営会議の資料の中だけで完結する。フロントラインの受け入れがどれほど後年まで響くかは、フロントラインのオンボーディングが顧客体験を左右する理由で詳しく扱っている。従業員体験の設計とCXガバナンスを別々のプロジェクトとして扱う組織ほど、横断プログラムの定着に苦労する。

成熟度に応じてガバナンスはどう変わるべきか

立ち上げ期の組織に、成熟した大企業向けの重厚なガバナンスを持ち込むと、逆効果になる。まだCXの共通言語すら定まっていない段階で三層のスポンサーシップと厳格な権限マトリクスを敷いても、会議体そのものが目的化する。初期段階では、まず一つの顧客ジャーニーを対象に小さく横断チームを組み、成果を見せることが優先される。組織の現在地を客観的に把握したい場合は、CX成熟度診断で12の構成要素に沿った現状を確認してから、統治の重さを調整するのが理にかなっている。

逆に、複数事業部を横断する規模の組織では、非公式な調整だけでは必ず綻びが出る。この段階では、部門ごとに散らばった改善案を一つの実行計画に統合するCX実行ロードマップの運用が欠かせない。ロードマップが分断されていると、各部門は自分の施策だけを見て「順調だ」と報告し、顧客が経験する全体のつながりは誰の視界にも入らない。

横断プログラムの運営で実際に崩れる場所はどこか

設計図がどれほど整っていても、現場では必ず同じ場所で綻びが出る。私が繰り返し見てきた崩壊のパターンは次の通りだ。

• スポンサーの異動 — 経営層のスポンサーが変わった瞬間、プログラムの優先順位が組織の中で再交渉される。後任への引き継ぎを制度化していない限り、プログラムは白紙から再出発になる。
• 四半期末の資源引き戻し — 各部門が自部門の数字を守るために、横断施策に割いていた人員を引き戻す。共有KPIが評価に組み込まれていなければ、この引き戻しを止める根拠がない。
• 指標の再定義競争 — 成果が出にくくなると、部門は自分たちに都合の良い形で指標の定義を変えようとする。北極星指標の定義を最初に文書化し、変更には合議を要すると決めておく必要がある。
• プログラムオフィスの実務化 — 調整役だったはずのプログラムオフィスが、いつの間にか各部門の実務を代行する下請けになる。これは責任の所在をあいまいにし、部門の当事者意識をさらに削ぐ。

この四つのうち、最初の二つはガバナンス設計の甘さから生まれ、後の二つは運用中の規律の緩みから生まれる。どちらも、事前に文書化した権限とKPIを盾にできるかどうかで結果が変わる。関連する実務の勘所は、多職能CXプログラムの運営に関する記事でも別の角度から掘り下げている。

横断プログラムが最終的に問われるのは、キックオフの熱量ではなく、四半期末に誰の評価にも入っていない指標をそれでも守る人がいるかどうかだ。その人を一人の善意に依存させるか、仕組みとして必ず存在させるか——それを決めるのがガバナンス設計であり、CXプログラムオフィスの存在理由そのものである。合意は安い。仕組みだけが、合意を実行に変える。