SaaSプロダクトのサービス提供プロセスを統合しようとしたら、「適応課題」への対応だった話

SaaSプロダクトでサービスを提供する「プロセス」は、本来は型が決まっているはず。ですが実態は、現場で微妙なカスタマイズが繰り返され、徐々に「分化」していきがちです。

弊社では、サービスの立ち上げ直後からエンタープライズ向けとSMB向けとでプロセスが分れたまま、それぞれの現場でブラッシュアップが繰り返され、ユーザーごとに最適化されたプロセスが生まれているという状況でした。しかし、このまま「分化」が進行すれば、サービスの提供クオリティのばらつきや、カスタマーサクセス（以下CS）の生産性の低下に繋がりかねません。そこで、今回「分化」したプロセスを1つに「統合」することになりました。

ただ、言うは易し行うは難し。

この「統合」に向けた一連の動きを整理しておきたいと思います。

1 これは「適応課題」への対応

ハーバード大教授のロナルド・A・ハイフェッツ氏は、その著書「最難関のリーダーシップ」の中で次のように述べています。

職場や家庭で私たちを取り巻く諸問題には、知識や技術、経験によって解決することができる「技術的課題」と、価値観や信念の違いを明らかにし、痛みや喪失を受け入れて新たな見方や考え方を見つけることで相手や自分、組織の行動を変えていかなければ解決しない「適応課題」がある。

最難関のリーダーシップ（amazon.co.jp）

単に新しいプロセスを作り、現場に共有するだけであれば技術的課題として対応すればいいでしょう。しかし今回のケースで言えば、現場CSたちは自分なりに磨きこみ、慣れ親しんだmyプロセスを持っています。今回プロセスを「統合」するにあたっては、そうしたmyプロセスは捨ててもらわなければいけません。当然そこには痛みや喪失が伴うでしょう。その意味で、今回のプロセス統合は、適応課題への対応だと捉える必要がありました。

そこで最難関のリーダーシップに書かれている通り、プロセス統合によって影響のある組織やその中に在籍する個人などを一括りに「System」として捉え、そのSystemに対して「Diagnose（診断する）→Mobilize（動かす、機能させる）」のステップで対応を検討していきました。

2 Diagnose the System

結論から言うと、今回のプロセス統合における適応課題は、

大切にしている価値観と行動にギャップが生まれる
（最難関のリーダーシップでいう「第1類型」）

ということだと考えました。
つまり、クオリティの安定化やCSの生産性向上のために、プロセス統合が必要だということはみんな頭では理解している。しかし実際の行動としては、従来から慣れ親しんだプロセスを使い続ける（＝統合プロセスが使われない）。こうした価値観と行動にギャップが生じることが、1番の課題だということです。

この結論に至るまでに、「組織の構造」「文化」「習慣的対応」の3つの観点でSystemを診断し、次の特徴をあぶり出しました。それは、

①部署としての結束の強さ
②コンサルタントという自己定義

です。

弊社ではカンパニー制を敷いており、かつエンタープライズ向けとSMB向けとでカンパニーは分かれています。カンパニー内で、上司はとても信頼されており、メンバー同士の風通しも非常に良く、かなり強固な仲間意識が芽生えていると言えます。ですが裏を返せば、カンパニー外に対して排他的になるリスクを秘めているとも言えました。

またCS個人としては、「カスタマーサクセス」より「コンサルタント」に近い特性を有しています。目の前のユーザーに「示唆を提示するぞ！」という思いが強いが故に、ユーザー毎に資料などをカスタマイズしようとする傾向が見られました。これは弊社の成り立ちや採用時の期待値によって形成された文化のようなもの。プロセスの型が確立していない時期などにおいては、こうしたCS個々の力がプラスに働くメリットがある一方で、今回のような「統合」には障壁になるリスクを秘めていると考えました。

3 Mobilize the System

最難関のリーダーシップでは、バルコニーに上がるというキーワードがたびたび出てきます。これは自分自身を含めたSystem全体を俯瞰的に見るということを指しています。
今回のケースでバルコニーに上がって物事を見た場合、プロセス統合を画策する私たち（Opsサイド）と、それを押し付けられる現場CSという図式を作ることは失敗のリスクを高めると考えました。そこで取り組む前提として、一蓮托生で新プロセスを作ることを強く意識しました。

その前提の上で、Systemを動かすためにやったことは2点です。

1点目は、各カンパニーのCSマネジャーをプロセス統合の設計段階から巻き込んだことです。プロジェクトの初期から巻き込んだことで、彼らの意向を汲むことができ、彼らにとって納得感の高いプロセスを構築できたと思います。大切なのは正しいかどうかではなく、納得できるかどうかではないでしょうか。そして統制が取れたカンパニー内において、彼らが「統合プロセスを使おう！」と働きかけてくれれば、確実にSystem全体に影響が波及します。上記の特徴①の逆活用です。

2点目は、CSのKGI・KPIの設計です。統合プロセスが使われているかどうかを単に管理したとしても、上記の特徴②に照らして、やらされ感が増幅されるだけでしょう。そうならないようなKGI・KPIを設定するために、現行プロセスを運用する上ですでに指標となっているヘルススコアを活用できないか検討しました。具体的には統合プロセスを実行した場合に、ヘルススコアがどう推移するかをシミュレーションしたところ、A〜Dの4段階の内、AB（＝上位）になることが立証されました。そこで、KGIをヘルススコアに、そしてKPIをヘルススコアを下げない特定の行動とすることで、統合プロセスとの連動を図りました。逆に言えば、それ以上の管理は避け、KGI・KPIをいかに上げるかの工夫の余地は現場CSに残しました。上記の特徴②の逆活用です。

これらによって、現状、現場CSにかなり受け入れてもらえていると思います。

4 さいごに

今回の学びとして、「適応課題の対応」という捉え方をしたことで、先んじてリスクを回避できたと思います。統合プロセスへの移行はまだ始まったばかり。この先、いくつもの障壁が待ち受けているかもしれませんが、適応課題として対応することで、1つひとつ乗り越えていきたいと思います。