About

The consultancy born at the intersection of behavioral economics and human experience.

René Studio
AI EXPERIENCE STUDIO

The CX design platform we built from a decade of client work.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Mystery audits we run, scored live for every location.

Explore Mysterya
NOW HIRING

Join a team reshaping how the world experiences brands.

View open roles →

COMPANY

GROW WITH US

CONNECT

Services

Comprehensive CX and management consulting for enterprise brands.

René Studio
AI EXPERIENCE STUDIO

Every engagement, mapped and scored in one AI workspace.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Mystery shopping, scored and evidenced in real time.

Explore Mysterya
ALL SERVICES

Explore the full range of CX & management consulting services.

Browse all services →

CORE

SPECIALIST

Solutions

Structured solutions that turn CX ambition into measurable outcomes.

René Studio
AI EXPERIENCE STUDIO

Map, score and fix the journeys we redesign, with AI.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Check the experience you designed is delivered.

Explore Mysterya
ALL SOLUTIONS

Explore every CX solution we offer.

Browse solutions →

STRATEGY & GOVERNANCE

DESIGN & DELIVERY

CULTURE & EXPERIENCE

Industries

A decade of CX transformation across the region's defining sectors.

René Studio
AI EXPERIENCE STUDIO

Sector-ready journeys, scored by AI in minutes.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Mystery audits tuned to your sector, scored live.

Explore Mysterya
ALL INDUSTRIES

See how we work across every sector.

Browse industries →

BUILT ENVIRONMENT

FINANCE & TECH

PEOPLE & MOBILITY

Products

Proprietary tools, platforms, and AI that power CX transformation.

René Studio
AI EXPERIENCE STUDIO

Design, score and fix customer journeys with AI.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Audit every location and act on what you find.

Explore Mysterya
REBELDECK A · 36 FORCES

The forces that shape how humans experience the world.

Explore REBEL Reveal →
ALL PRODUCTS

Explore the full Renascence product ecosystem.

Browse products →

PLATFORMS

AI & TECHNOLOGY

LEARNING & FRAMEWORKS

CX TOOLKIT

Opinion

Insights, research, and conversations at the frontier of CX.

René Studio
AI EXPERIENCE STUDIO

Turn what you read into a journey you can score.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

See what customers really experience, visit by visit.

Explore Mysterya
ReadExperience JournalArticles & research on CX, behavior, and transformation.Watch & listenExperience LoomOur video podcast on CX & behavior.CuratedCX NewsIndustry news that matters in CX, minus the noise.

Latest articles

Latest episodes

Latest news

Hub

Free tools, templates, and resources to advance your CX practice.

René Studio
AI EXPERIENCE STUDIO

Design, score and fix customer journeys with AI.

Explore René Studio
Mysterya
MYSTERY AUDITS, LIVE

Every visit, every location, every score. Live.

Explore Mysterya
THE MANIFESTOBurn the Deck.
Ten Virtues. Zero Excuses.Start reading →
THE HUB

Every free tool, template and resource in one place.

Visit the Hub →

AI TOOLS

FREE TOOLS

LEARNING

CULTURE

Organizational Transformation · August 10, 2026

スケールするCXオペレーティングモデルの設計と運用

CXプログラムが18ヶ月で失速する本当の理由は構造にある。ガバナンス・実行リズム・説明責任の3要素を組み込んだ、スケールするCXオペレーティングモデルの設計原則を実務家の視点で解説する。

加
加藤 湊
1 min read
スケールするCXオペレーティングモデルの設計と運用
Work with usBring behavioral CX to your organizationBook a discovery call

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プログラムの「後工程」ではなく「並走するトラック」として設計することが、定着率を大きく左右する。

Related solutionDesign experiences grounded in behaviorExplore our services

スケールの条件:能力開発なしに構造は動かない

オペレーティングモデルがスケールするためには、それを動かす人の能力が必要だ。ジャーニーオーナーがジャーニーマップを読めなければ、オーナー制度は機能しない。マネージャーがCESとNPSの違いを理解していなければ、月次レビューは数字の報告会になる。

能力開発は研修プログラムだけでは足りない。日常業務の中で、正しい問いを立てる習慣を作ることが本質だ。「このタッチポイントで顧客は何をしようとしているか」「どこに摩擦があるか」「その摩擦は除去できるか、それとも設計で軽減するか」——こうした問いが会議の中で自然に出てくるようになれば、組織のCX能力は実質的に上がっている。

体系的な能力開発が必要な場合は、カスタマイズ研修プログラムを組織の実情に合わせて設計することが、汎用研修より定着率が高い。

メトリクス設計:何を測るかが何を改善するかを決める

NPS、CSAT、CESの3指標はそれぞれ異なるものを測っている。NPSは関係性の強さ、CSATは特定インタラクションへの満足度、CESはその取引にかかった努力量だ。3つを混同して「顧客満足度」として一括管理している組織は、改善の方向を見誤る。

スケールするモデルでは、ジャーニーのどのステップにどの指標が適切かを設計段階で決める。オンボーディングの完了ステップにはCES(手続きの簡便さ)が適切で、長期ロイヤルティの測定にはNPSが適切だ。指標とジャーニーステップの対応表を作り、それをレビューの基準にする。

また、定量指標だけに頼ることの危険性も認識しておく必要がある。スコアは「何が起きているか」を示すが、「なぜ起きているか」は示さない。定性的なVoCデータ、ミステリーショッピング、エスノグラフィック観察を組み合わせることで、初めてアクション可能な洞察が得られる。

エンプロイーエクスペリエンスとの連動:上流を無視したモデルは壊れる

CXオペレーティングモデルを設計するとき、従業員体験(EX)を切り離して考えることはできない。顧客に届く体験の質は、それを届ける従業員の状態に直接依存する。フロントラインスタッフが自分の仕事に意味を感じていない組織で、感情的なつながりを伴う顧客体験を設計しようとしても、実行段階で必ず失速する。

これは抽象論ではない。ジャーニーオーナーが「このステップの改善に何が必要か」を問うとき、答えの多くは「フロントラインの権限拡大」「プロセスの簡素化」「ツールの改善」——つまりEXの改善だ。従業員体験の設計をCXオペレーティングモデルのスコープに含めない組織は、顧客向けの施策が実行段階で空洞化するリスクを常に抱えている。

実装ロードマップ:最初の180日間に何をするか

理論を実装に変えるための、最初の180日間の優先順位を示す。

  1. Day 1〜30:現状診断とスコープ確定。CXマチュリティを評価し、最も改善インパクトの高いジャーニーを2〜3本特定する。全ジャーニーを同時に動かそうとしない。
  2. Day 31〜60:ガバナンス構造の仮設計。エグゼクティブスポンサーを確定し、ジャーニーオーナーを指名し、CPO機能の担当者を決める。正式な組織変更は後でよい。まず「誰が何を持つか」を合意する。
  3. Day 61〜90:実行リズムの立ち上げ。週次・月次のレビューカレンダーを設定し、最初の月次レビューを実施する。アジェンダは「赤信号の項目と次のアクション」だけに絞る。
  4. Day 91〜120:VoCループの設計。顧客の声を特定のジャーニーステップに紐づけるデータフローを設計する。既存の調査データがあれば、まずそれをジャーニーに対応させる作業から始める。
  5. Day 121〜150:最初の改善施策の実行と可視化。1つのジャーニーで、1つの具体的な改善を実施し、その前後のスコア変化を記録する。この「証拠」が次の投資を正当化する。
  6. Day 151〜180:モデルの評価と拡張計画。最初の180日間で何が機能し、何が機能しなかったかを正直にレビューする。拡張するジャーニーと強化すべきガバナンス要素を決める。

このロードマップの詳細設計には、CX実装ロードマップのフレームワークが実際の組織規模・業種・マチュリティに応じた調整の基準になる。

スケールとは「大きくする」ことではない

最後に、スケールという言葉の誤解を解いておきたい。スケールするCXオペレーティングモデルとは、組織が大きくなっても、複雑になっても、CX改善の質と速度が落ちないモデルのことだ。部門が増えても、市場が拡大しても、新しいチャネルが加わっても——構造が適応し、リズムが維持され、説明責任が機能し続ける。

それは、完璧なモデルを最初から設計することではない。動くモデルを作り、使いながら改善し、組織の成長に合わせて進化させることだ。Harvard Business Reviewが2010年に発表した顧客努力に関する研究が示したように、顧客が最も評価するのは「期待を超える体験」ではなく「期待通りに、摩擦なく機能すること」だ。オペレーティングモデルも同じだ——華やかさより、確実に動き続けることが価値を生む。

CXを「プロジェクト」として扱っている組織は、常に次のプロジェクトを探している。CXを「インフラ」として設計した組織は、顧客体験を継続的に改善する能力そのものを持っている。その差が、3年後・5年後の競争優位の差になる。

Further reading

FAQ

Questions we get on this topic

CX改善の意思決定・実行・説明責任を組織の日常業務に組み込んだ恒久的な構造です。プロジェクトではなくインフラとして設計され、ガバナンス層・実行リズム・説明責任メカニズムの3要素で構成されます。

エグゼクティブ・スポンサー層、CXプログラムオフィス層、ジャーニーオーナー層の3層が最低限必要です。各層の意思決定権限を明確にし、ジャーニーと担当者名を紐づけることが機能の前提条件です。

最も多いのは、CX改善の責任をCXチームだけに集中させる設計ミスです。チームがボトルネックになり、組織全体への影響力を失います。正しくはCXチームを設計・支援・計測の中枢と位置づけ、実行は各部門のジャーニーオーナーが担う構造です。

顧客の声を特定のジャーニーステップに紐づけ、そのステップのオーナーに届け、改善アクションに変換するループを設計することが核心です。データの収集で止めず、アクションへの変換プロセスをオペレーティングモデルに組み込む必要があります。

複雑なガバナンス構造を一度に入れず、まず1〜2本のクリティカルジャーニーに絞り、ジャーニーオーナーを1人決め、月次レビューを始めることを推奨します。完璧なモデルより動くモデルを優先し、成熟度に応じて段階的に拡張します。

Related reading

加
加藤 湊
Renascence

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.