Organizational Transformation · August 10, 2026
スケールするCXオペレーティングモデルの設計と運用
CXプログラムが18ヶ月で失速する本当の理由は構造にある。ガバナンス・実行リズム・説明責任の3要素を組み込んだ、スケールするCXオペレーティングモデルの設計原則を実務家の視点で解説する。
CXプログラムの多くは、立ち上げから18ヶ月以内に失速する。ツールが足りないわけでも、データが足りないわけでもない。問題は構造にある。誰が何を決め、誰がそれを実行し、誰がその結果に責任を持つのか——その設計が曖昧なまま走り続けた結果、CXは「全員の仕事」になり、実質的に「誰の仕事でもない」状態に陥る。
スケールするCXオペレーティングモデルとは何か。一言で言えば、CX改善の意思決定・実行・説明責任を、組織の日常業務に組み込んだ恒久的な構造だ。プロジェクトではなく、インフラである。この記事では、そのインフラをどう設計し、どう立ち上げ、どこで崩れやすいかを、実際に運用した立場から書く。
なぜCXオペレーティングモデルが必要なのか
CX戦略を持っている組織は多い。しかしCXを運営する仕組みを持っている組織は少ない。この違いは決定的だ。
戦略は方向を示す。オペレーティングモデルは、誰が毎週何をするかを決める。ジャーニーマップをスライドに描いて終わりにするか、それとも毎月のKPIレビューで「このタッチポイントの改善オーナーは誰か」という問いが自然に出てくる組織になるか——その差がオペレーティングモデルの有無だ。
行動経済学の観点から言えば、これはデフォルト設計の問題でもある。Richard Thalerが指摘したように、人は明示的に選択しなくてもよい場合、デフォルトのまま動く。CXの改善行動を「意識的に選ぶ」ことに依存したプログラムは、忙しい現場に負ける。オペレーティングモデルは、CX改善をデフォルトの行動にする仕組みだ。
スケールするモデルの3つの構成要素
実際に機能しているCXオペレーティングモデルを分解すると、共通して3つの要素が揃っている。
1. ガバナンス構造:誰が何を決めるか
ガバナンスとは会議体のことではない。意思決定の権限と速度の設計だ。CXプログラムが失速するとき、たいてい「誰かが承認待ちのまま止まっている」か「誰も決めていないのに全員が動いている」かのどちらかだ。
機能するガバナンスには最低3つの層が必要になる。
- エグゼクティブ・スポンサー層:予算・優先順位・組織横断の障壁を取り除く権限を持つ。月次または四半期での関与で十分だが、関与が形式的になった瞬間にプログラムは死ぬ。
- CXプログラムオフィス(CPO)層:戦略と実行の橋渡し。ロードマップ管理、KPI追跡、部門間調整を担う。専任でなくてもよいが、誰かが「この役割」を明確に持っている必要がある。
- ジャーニーオーナー層:特定のカスタマージャーニーに責任を持つ現場リーダー。「オンボーディングジャーニーのオーナーは営業部長」という具合に、ジャーニーと人名が紐づいていること。
この3層が揃っていないと、CXガバナンス戦略はペーパー上の概念に留まる。
2. 実行リズム:どの頻度で何をレビューするか
構造があっても、リズムがなければ動かない。CXプログラムオフィスが設計すべき実行カレンダーは、概ね以下のようになる。
- 週次:ジャーニーオーナーによるタッチポイント改善の進捗確認。15〜30分、アジェンダは「赤信号の項目だけ」。
- 月次:NPS・CSAT・CESの推移レビュー。部門別ではなくジャーニー別に集計すること。「どの部門のスコアか」より「どのジャーニーのどのステップで何が起きているか」が問いの形。
- 四半期:エグゼクティブ向けのCXヘルスレポート。スコアの報告ではなく、「次の四半期に何を優先するか」の意思決定会議として設計する。
- 年次:CX戦略と優先ジャーニーの見直し。市場変化・顧客セグメントの変化・競合動向を踏まえたリセット。
このリズムを設計するとき、ゴール勾配効果(goal-gradient effect)を意識すると実行率が上がる。ゴールに近づくほど努力が増すという心理的傾向を利用し、四半期末に近づくにつれてレビューの頻度を上げ、「もう少しで達成」という感覚を意図的に作る。
3. 説明責任のメカニズム:スコアを誰の評価に結びつけるか
これが最も実装が難しく、最も効果が高い要素だ。CXスコアが人事評価や部門予算と連動していない組織では、改善活動は「余裕があればやる」扱いになる。
すべてのKPIを給与に直結させる必要はない。しかし少なくとも、ジャーニーオーナーの四半期目標にCXメトリクスが含まれていること、エグゼクティブの年次レビューにCX改善の進捗が含まれていること——この2点がなければ、説明責任は機能しない。
よくある設計ミス:何が実際に壊れるか
理論は整っている。問題は実装だ。私が実際に見てきた失敗パターンを率直に書く。
「CXチーム」に全部押し込む
CX部門を作り、そこに全責任を集中させるモデルは、短期的には動くが必ずスケールの壁にぶつかる。CXチームが10人でも、影響を及ぼすべき組織が1,000人なら、チームはボトルネックになる。
正しい設計は、CXチームを「実行部隊」ではなく「設計・支援・計測の中枢」として位置づけることだ。実行はジャーニーオーナーと各部門が担い、CXチームはそのインフラと能力開発を支える。組織変革の文脈で言えば、これは「センター・オブ・エクセレンス」モデルに近い。
ジャーニーマップを成果物と勘違いする
ジャーニーマップは分析ツールであり、改善の起点だ。しかし多くの組織では、マップを作った時点でプロジェクトが終わる。6ヶ月後にそのマップを見ると、現実とずれている。
スケールするモデルでは、ジャーニーマップは生きたドキュメントでなければならない。タッチポイントのスコアが更新され、改善施策の実施状況が反映され、顧客の声が定期的に織り込まれる。カスタマージャーニーの設計と管理をプロセスとして組み込まない限り、マップはすぐに死ぬ。
VOCを「収集」で止める
Voice of Customer(VoC)プログラムを持っている組織は増えた。しかしデータを収集して終わりにしている組織も多い。NPS調査を毎月送り、スコアをダッシュボードに表示し、それで「VoCをやっている」と思っている——これは収集であって、活用ではない。
機能するVoCは、顧客の声が特定のジャーニーステップに紐づき、そのステップのオーナーに届き、改善アクションに変換されるループを持つ。Voice of Customer戦略の核心はこのループ設計にある。
CXマチュリティとオペレーティングモデルの関係
オペレーティングモデルの設計は、組織のCXマチュリティによって変わる。成熟度が低い段階で複雑なガバナンス構造を入れようとすると、形式だけが残って中身が空洞化する。
マチュリティの低い段階(「CXとは何か」をまだ定義している段階)では、まず1〜2本のクリティカルジャーニーに絞り、ジャーニーオーナーを1人決め、月次レビューを始めることだ。完璧なモデルより、動くモデルを優先する。
マチュリティが上がるにつれて、ガバナンス層を追加し、メトリクスを精緻化し、説明責任の仕組みを強化していく。組織の現在地を正確に把握するには、CXマチュリティ評価ツールを使って12の構成要素を客観的にスコアリングすることが出発点になる。
チェンジマネジメント:モデルを「使われるもの」にする
オペレーティングモデルの最大のリスクは、設計後に使われなくなることだ。これはチェンジマネジメントの失敗であり、構造の失敗ではない。
行動経済学の損失回避(loss aversion)の観点から言えば、人は「新しい良いもの」を得る喜びより「現状を変えるコスト」を重く感じる。CXオペレーティングモデルの導入は、現場のマネージャーにとって「新しい会議が増える」「新しい指標で評価される」という損失として知覚されやすい。
これを乗り越えるには、早期に「勝ち」を作ることだ。最初の90日間で、新しいモデルを使って解決した具体的な問題を1つ可視化する。「このジャーニーのこのステップで、こういう改善が起きた」という具体的な成果を、エグゼクティブと現場の両方に見せる。成功体験が次の行動を引き出す。
チェンジマネジメントをCXプログラムの「後工程」ではなく「並走するトラック」として設計することが、定着率を大きく左右する。
スケールの条件:能力開発なしに構造は動かない
オペレーティングモデルがスケールするためには、それを動かす人の能力が必要だ。ジャーニーオーナーがジャーニーマップを読めなければ、オーナー制度は機能しない。マネージャーがCESとNPSの違いを理解していなければ、月次レビューは数字の報告会になる。
能力開発は研修プログラムだけでは足りない。日常業務の中で、正しい問いを立てる習慣を作ることが本質だ。「このタッチポイントで顧客は何をしようとしているか」「どこに摩擦があるか」「その摩擦は除去できるか、それとも設計で軽減するか」——こうした問いが会議の中で自然に出てくるようになれば、組織のCX能力は実質的に上がっている。
体系的な能力開発が必要な場合は、カスタマイズ研修プログラムを組織の実情に合わせて設計することが、汎用研修より定着率が高い。
メトリクス設計:何を測るかが何を改善するかを決める
NPS、CSAT、CESの3指標はそれぞれ異なるものを測っている。NPSは関係性の強さ、CSATは特定インタラクションへの満足度、CESはその取引にかかった努力量だ。3つを混同して「顧客満足度」として一括管理している組織は、改善の方向を見誤る。
スケールするモデルでは、ジャーニーのどのステップにどの指標が適切かを設計段階で決める。オンボーディングの完了ステップにはCES(手続きの簡便さ)が適切で、長期ロイヤルティの測定にはNPSが適切だ。指標とジャーニーステップの対応表を作り、それをレビューの基準にする。
また、定量指標だけに頼ることの危険性も認識しておく必要がある。スコアは「何が起きているか」を示すが、「なぜ起きているか」は示さない。定性的なVoCデータ、ミステリーショッピング、エスノグラフィック観察を組み合わせることで、初めてアクション可能な洞察が得られる。
エンプロイーエクスペリエンスとの連動:上流を無視したモデルは壊れる
CXオペレーティングモデルを設計するとき、従業員体験(EX)を切り離して考えることはできない。顧客に届く体験の質は、それを届ける従業員の状態に直接依存する。フロントラインスタッフが自分の仕事に意味を感じていない組織で、感情的なつながりを伴う顧客体験を設計しようとしても、実行段階で必ず失速する。
これは抽象論ではない。ジャーニーオーナーが「このステップの改善に何が必要か」を問うとき、答えの多くは「フロントラインの権限拡大」「プロセスの簡素化」「ツールの改善」——つまりEXの改善だ。従業員体験の設計をCXオペレーティングモデルのスコープに含めない組織は、顧客向けの施策が実行段階で空洞化するリスクを常に抱えている。
実装ロードマップ:最初の180日間に何をするか
理論を実装に変えるための、最初の180日間の優先順位を示す。
- Day 1〜30:現状診断とスコープ確定。CXマチュリティを評価し、最も改善インパクトの高いジャーニーを2〜3本特定する。全ジャーニーを同時に動かそうとしない。
- Day 31〜60:ガバナンス構造の仮設計。エグゼクティブスポンサーを確定し、ジャーニーオーナーを指名し、CPO機能の担当者を決める。正式な組織変更は後でよい。まず「誰が何を持つか」を合意する。
- Day 61〜90:実行リズムの立ち上げ。週次・月次のレビューカレンダーを設定し、最初の月次レビューを実施する。アジェンダは「赤信号の項目と次のアクション」だけに絞る。
- Day 91〜120:VoCループの設計。顧客の声を特定のジャーニーステップに紐づけるデータフローを設計する。既存の調査データがあれば、まずそれをジャーニーに対応させる作業から始める。
- Day 121〜150:最初の改善施策の実行と可視化。1つのジャーニーで、1つの具体的な改善を実施し、その前後のスコア変化を記録する。この「証拠」が次の投資を正当化する。
- Day 151〜180:モデルの評価と拡張計画。最初の180日間で何が機能し、何が機能しなかったかを正直にレビューする。拡張するジャーニーと強化すべきガバナンス要素を決める。
このロードマップの詳細設計には、CX実装ロードマップのフレームワークが実際の組織規模・業種・マチュリティに応じた調整の基準になる。
スケールとは「大きくする」ことではない
最後に、スケールという言葉の誤解を解いておきたい。スケールするCXオペレーティングモデルとは、組織が大きくなっても、複雑になっても、CX改善の質と速度が落ちないモデルのことだ。部門が増えても、市場が拡大しても、新しいチャネルが加わっても——構造が適応し、リズムが維持され、説明責任が機能し続ける。
それは、完璧なモデルを最初から設計することではない。動くモデルを作り、使いながら改善し、組織の成長に合わせて進化させることだ。Harvard Business Reviewが2010年に発表した顧客努力に関する研究が示したように、顧客が最も評価するのは「期待を超える体験」ではなく「期待通りに、摩擦なく機能すること」だ。オペレーティングモデルも同じだ——華やかさより、確実に動き続けることが価値を生む。
CXを「プロジェクト」として扱っている組織は、常に次のプロジェクトを探している。CXを「インフラ」として設計した組織は、顧客体験を継続的に改善する能力そのものを持っている。その差が、3年後・5年後の競争優位の差になる。
Further reading
FAQ
Questions we get on this topic
Related reading
Writing on how human behavior shapes the experiences brands deliver — at the intersection of behavioral economics and customer experience.
Stay ahead of CX
Get the Journal in your inbox.
Insights, frameworks and event round-ups from the Renascence team. No spam, ever.



