本記事は『CXaaS 「攻めのIT活用」を実現する新しいクラウドサービスモデル』の「第3章 理想を実現する「CXaaS」」から一部を抜粋したものです。掲載にあたって編集しています。
常識外れのサービスモデル「CXaaS」とは
本書のタイトルとした「CXaaS」は私たちの会社*が実践し、展開している新しいクラウドサービスモデルの呼称です。従来のクラウドサービスとしての分類はSaaSにあたりますが、ソフトウェアの提供にとどまらず、実際にソフトウェアを活用する「顧客体験」までをサービスとして提供するため、「CXaaS」（シーザース）とよんでいます。
*編集者注 著者の寺尾望さんが所属するコムデザイン
現在のSaaSは「道具を提供する」発想を追求してきたと言えます。インフラ運用の負担からユーザーを解放し、提供するソフトウェアをより手軽にユーザーに利用してもらえるようになったことで、道具を選ぶようにITツールを導入できるのがSaaSの良さであると理解されてきました。ユーザー自身の手でカスタマイズできるようにするノーコードやローコードというアプローチも、SaaSを提供するITベンダーはITツールの提供に専念し、手離れのよいサービス提供を目指すSaaSならではの思想の表れだと思います。
SaaSビジネスで見られる顧客への利用定着を支援するカスタマーサクセスにおいても、ユーザー自身がITツールをより深く理解し、最終的には自立して利用することを目指したサポートが一般的です。一見、スマートで合理的に思えるSaaSの在り方ですが、結果としてユーザー企業とのミスマッチを埋めきれないことが多いのも事実です。
そのミスマッチを埋めるために、利用に苦戦するユーザーの代わりにテクニカルな設定作業などを行い、ましてやユーザーが希望する機能を個別に開発するということは、SaaSにおいて非常識な対応と言えます。さらに、そのような対応をサブスクリプション型の費用体系の中で、追加費用をもらうことなく行うとすると、これまでのシステム開発の在り方からして非常識と言えるのではないでしょうか？
その、非常識な価値提供を実現しているのが「CXaaS」です。
ない機能は作るという選択肢
「CXaaS」の概要は次の通りです。
- SaaSとして、クラウドにてITツールを提供
- 提供するITツールに対してユーザーが望むカスタマイズ開発を行う
- 開発作業を含むテクニカルな作業はサービスとして専門エンジニアが対応
- 上記をサブスクリプション型の費用体系で提供
一般的なSaaSは、あらかじめ用意したソフトウェアを手離れよく提供することを目指します。提供するソフトウェアにユーザーが望むような機能がなかった場合、SaaSではそれ以上の対応が難しいと言えます。諦めてもらうか、将来のバージョンアップでの実装を期待して待ってもらうしかありません。
それに対して「CXaaS」では、顧客要望を満たす機能がない場合は新たに開発して対応します。ユーザーニーズを満たす、シンプルで確実な方法です。当然、SaaSとして展開する以上、一つのユーザーニーズに対応して終わることはなく、さまざまな顧客ニーズに対して継続的に対応するために機能をどんどん開発していくことが求められます。結果、ソフトウェアとしては高機能なものに発展していきます。また、開発した機能を組み合わせて提供することも可能です。
このようにSaaSでありながら、CXaaSはかなりの自由度を確保して、ユーザーに合わせたシステム構築を実現できるサービスモデルです（図1）。
ノーコード、ローコードによるカスタマイズはあらかじめ想定された範囲での設定や開発に限定されます。それに対して、「CXaaS」はプロコードによる開発作業も選択肢となり、さらに高い自由度をもって対応することができるのです。
人的サポートもサービスとして提供
高機能で自由度が高いというと、一般的にはメリットとして受け止められますが、これまでのシステム活用の状況を鑑みると一概にもそうは言えないことは理解いただけるでしょう。つまり、高機能で自由度の高いソフトウェアを利用するためには、たくさんの機能を十分に理解して、自由に扱うために十分なITスキルを持ち合わせることが求められるのです。
ローコード、ノーコードによるアプローチの課題として、ユーザーニーズへの適応性の高さと引き換えに、利用するまでのハードルの高さに問題がありました。その解決のために、ユーザー企業は外部ITベンダーに頼るような構図が出来上がりつつあります。これは、SaaSビジネスの基本戦略でもあるソフトウェア提供に専念し、手離れのよいユーザー提供の在り方を重視した結果と言えます。
「CXaaS」はSaaSとしてローコード、ノーコードを上回る自由度を確保しながらも、利用するまでのハードルの高さに対して人的なサポートもサービスの提供価値の一部とすることで解決を図っています。すなわち、ユーザーが苦手とするテクニカルな設定作業や、必要な開発作業についても、SaaSを提供するITベンダーに所属するエンジニアが対応して利用を支援するのです。
このように、SaaSとしてITツールを提供するだけにとどまらず、ITツールを実際に活用できるところまで人的サポートを行うことが、「CXaaS」の特長の一つとなっています。
定額のライセンス費のみのシンプルな費用設計
「CXaaS」では、ユーザーが自由度の高いITツールを専門エンジニアのサポートの下、負担なく使うことができます。ユーザーにとって、従来のシステム導入の課題を考えれば理想的なサービスと言えるのではないでしょうか。かつ、このサービスは定額のライセンス費のみで利用できます。つまり、開発に関する費用や、デリバリーのための作業費用が追加で発生することがないのです。
IT活用において、計画の段階で漏れなく要件を考慮して判断することは非常に難しく、予期せぬ要件が発生した場合、従来のシステム提供の在り方では想定外のコストが発生することは免れませんでした。また「攻めのIT活用」を実現する上で、予見できないコストは柔軟性を損ね、変化を許容しづらくする大きな要因の一つになりえます。
「CXaaS」では、定額の費用設定により予期せぬコスト上昇のリスクを最小化し、変化に寛容なIT活用の在り方を実現するのです（図2）。
高い満足度と継続率
SaaSはパッケージを選択するように導入できます。しかし、それだけではユーザーごとの細やかな要求を満たせない場合があります。ノーコード、ローコードといったカスタマイズの仕組みをユーザーに提供することで細やかなニーズを満たせるような設計も可能ですが、自由度としては想定された枠組みに限定され、利用するユーザーに相応のリテラシーと手間が要求されます。
それに対して「CXaaS」は、SaaSならではのパッケージを選ぶように導入する手軽さを残しながら、足りない機能や欲しい機能についても追加開発という選択肢を持つことで高い自由度をもって提供され、かつ自由度のメリットを十分に享受するためのテクニカルな対応は専門エンジニアに任せることができます。しかも、定額費用の範囲内でです。
結果として「CXaaS」の提供するサービスは、ユーザーにとって満足度の高いものになるでしょう。実際に私の会社が「CXaaS」として提供するサービスの月間のカスタマーチャーンレート（解約率）は、平均0.3％を下回る水準で推移しており、解約の理由のほとんどは事業部門の統廃合による利用停止など、ユーザー都合によるものです。SaaSビジネスでは3％未満を維持すべきであると言われており、その水準と比較しても非常に低いことがわかります。
このことからも、「CXaaS」はユーザー企業にとって理想的なITツールの提供の在り方なのではないかと考えています。
「CXaaS」の要、FAE
「CXaaS」の特長の一つである、「人的なサポート」において中心的な役割を担うのがFAE（フィールドアプリケーションエンジニア）です。FAEは一般的には営業担当者と同行し、技術的な専門知識を活かしたサポートや技術的な打ち合わせを行う要員を指します。
「CXaaS」におけるFAEは、提供するITツールの専門家としてユーザーと直接コミュニケーションをとりながらニーズを聴取し、要件を調整し、利用環境を構築します。また新規の開発が必要な要件については、開発エンジニアとの橋渡しの役割も担います（図3）。
このようにCXaaSにおけるFAEは、顧客窓口として直接コミュニケーションをとりつつ、必要なシステム構築作業もできる、自己完結した存在であると言えます。少なくとも自分たちが提供するITツールについては、どのような機能が備わっており、どのような設定をすべきか、またそれにはどのような作業が発生するのかなど、バックグラウンドも含めて具体的な業務知識を保有した存在となります。また、自己完結性が高いため、対ユーザーへのメインの担当者はほとんどの場合1名となり、顧客対応の判断にあたっては各自の裁量が与えられています。
エンジニアでありながら、顧客と直接コミュニケーション
ユーザー企業の窓口として担当者と直接コミュニケーションをとることも、FAEの仕事です。一般的にはコミュニケーションに長けているのはエンジニアよりも営業担当者というイメージがあるのではないでしょうか。私も仕事でシステム関連の打ち合わせに参加すると営業担当者＋エンジニアという組み合わせが多く、基本的には営業担当者がユーザーとコミュニケーションをとりながら、必要に応じてエンジニアに意見を求めるという光景は、企業を問わず目にします。それに対して、「CXaaS」では早い段階からFAEが直接ユーザー企業の担当者とコミュニケーションをとることが一つの特徴になっています。このことから、FAEに求められるスキルとしてはシステムを深く理解するためのエンジニアのスキルとともに、コミュニケーションスキルも重要です。
プロコードによる開発は開発エンジニアに依頼
FAEは、ユーザーがITツールを利用するための環境構築や設定作業を行います。これらの作業は、これまで見てきたノーコード、ローコードでの開発作業に近い、プロコードでの開発作業よりも簡略化された作業となっています。
一方で「CXaaS」の良さの一つとして、従来用意されていない機能の提供があります。中には、プロコードでのゼロからの開発が必要なケースも当然発生します。この場合のFAEの役割は、ユーザーとプロコードでの開発を行える開発エンジニアとの橋渡しです。FAEがコミュニケーションをとりながら、ユーザーのニーズに対して既存機能での対応は難しいのか、新規開発するにあたって既存機能とどのように整合性をとるべきかなどを考慮し、開発要件を調整していきます。
調整の過程では開発エンジニアとしての観点からの指摘もあり、ユーザー、開発エンジニアの双方の意見に対して最適な着地点を探っていくことが、FAEにとっての重要な役割の一つです。
FAEとのコミュニケーションで金銭的な交渉は発生しない
「CXaaS」でFAEがコミュニケーションの中心となる背景としては、ユーザーとのコミュニケーションにおいて金銭的な交渉が発生しないことがあげられます。よく見られる営業担当者＋エンジニアの構図は、金銭的交渉窓口として責任を負うべき役割が営業担当者に求められていると考えられます。
一方、「CXaaS」では、開発作業やテクニカルなサポート対応について定額費用内での対応が前提となるため、議題としては技術的な要件に限られます。ビジネスモデル上、FAEとして売り上げ目標を持っているわけではないので、関心事はユーザーに満足して使ってもらうことになります。
このようにユーザーとFAEの関係でお金が影響を与えることはなくなり、お金を軸とした交渉や駆け引きなどのコミュニケーションは不要になります。シンプルに、ユーザーとして何を望むか、そしてどう実現するべきかについて話し合うことが主となります。
導入経験豊富な人員が対応
「CXaaS」のFAEは、経験豊富なプロフェッショナルとなる可能性が高いと言えます。エンジニアは一種の職人です。多くの現場を経験することで、発想とスキルを深化させていきます。
それに対して、オンプレミス型システムのプロジェクトは、ユーザーの希望を聞きながら対応することは「CXaaS」と同じですが、プロジェクトの規模によっては数年を要するなどの大掛かりなものも存在し、かかりきりでの対応が求められることもあります。また、エンジニアは大きなチームの一部として働くことも多く、主体的に考えて仕事ができる立場になるには、それなりのキャリアが必要になります。いわば下積み期間が長くなりがちなのです。
一方「CXaaS」では、SaaSならではのスピード感で導入が進みます。経験できるプロジェクトの数は必然的に多くなります。また、FAE各自に裁量が与えられているということは責任を負うということでもあり、主体的な立場として場数を踏むことになります。この点からも、プロフェッショナルとしての人員が育ちやすく、「CXaaS」が提供する人的サポートの質を高めることにもつながっています。
経験豊富なFAEによるお金のしがらみのない提案
FAEがさまざまな企業でのシステム導入を経験していることは、ユーザー企業の安心感につながります。例えば、似たような課題の相談を受けた場合、他のユーザーの事例から解決策を提案することも自然にできるようになります。FAEの提案の選択肢の広さは、そのまま「CXaaS」が持つ自由度を活かすポテンシャルに直結するのです。
また、幅広い選択肢を狭めかねない、利益のしがらみを考慮する必要がないということも重要です。利益のことを考えれば、お金になりそうにない提案はしないという発想が生まれかねず、結果として「CXaaS」の良さをユーザーが享受できない可能性を生むからです。
システムの「用意」と「利用」
システムの恩恵を受けるまでには二つの工程があると思います。「用意」する工程と「利用」する工程です。これまでご紹介してきたシステム活用において直面する困難は、主に「用意」の苦労にあたるでしょう。
システムとは、手段の一つと見ることができます。例えば川を渡って前に進むという目的があったなら、用意するべき手段は舟や橋です。舟や橋さえ作ってしまえば、使い心地に文句があったとしても、少なくとも目的に前進します。しかしながら、その舟や橋を用意することこそが、大きな苦労にあたるのではないでしょうか。この大きな苦労を避ければ、川を渡ることはできず、前に進むことはできません。
「CXaaS」はシステムの恩恵を受けるまでの、大きな負担である「用意」のフェーズをFAEによる人的なサポートでユーザー企業のシステム導入担当者を助けます。また「攻めのIT活用」とは、前節の事例でもご紹介したように運用の中で新しい目的が生まれ、新しい仕組みの「用意」が求められることになります。つまり、この「用意」の負担をいかに軽くできるかが、「攻めのIT活用」を実現する上で、重要な観点になると考えられるのです。
実行力のあるパートナーがいる安心感
継続的に新しい仕組みが求められる場合、相談できるプロフェッショナルがいることほど心強いことはないでしょう。先ほどの例でいえば、舟や橋を作ることができる大工からアドバイスを受けられるのであれば、これほど心強いことはありません。「CXaaS」におけるFAEとは、まさしくそのような立場にあると言えます。提供する手段のプロフェッショナルとして相談できるパートナーです。
プリンシパル＝エージェント関係を考えれば、一般的には相談するだけでもお金がかかります。しかし、「CXaaS」におけるFAEは相談、すなわちコンサルティングに対して費用を求めることはありません。FAEの仕事は話を聞くことではなく、ユーザーの要望を実現することであり、提供するITツールを活用してもらい、満足していただくことで、解約することなく末永く契約を継続してもらうことなのです（図4）。
高度化する産業においては、しばしばこの相談するという行為も価値を持ちます。しかし、IT業界における情報の非対称性を考慮すると、実行をともなわない仕事は、モラルハザードのリスクがつきまといます。それに対して、「CXaaS」は実行まで責任を持つ実行力のあるパートナーとなります。
このように、相談事の実現まで責任を持てるプロフェッショナルに相談できることは、システム導入の担当者にとっては心強く、サービス提供者にとっては信頼というビジネス上かけがえのない資産を得ることにつながります。
現在の要件に絞った判断で済む
「用意」の工程では、「計画」し、「検討」する作業が最も負担になると言えます。なぜなら、システム導入において計画の段階で抜け漏れがあると、オンプレミス型システムであれば大変な手間とコストが、SaaSの導入であれば再度のシステム移行の検討が必要となります。では、この検討の負担を軽くするには、どうすればいいのでしょうか？
シンプルな方法としては、判断すべき範囲を限定して狭めることです。A社の事例でも、将来要件については抽象的な要件として情報収集にとどめることでプロジェクトを前進できました。これが、例えば将来的な機能要件まで網羅した場合の検討や、将来要件が実現できなかった場合のリプレイスに要するコストまで検討が求められたらどうでしょうか？ 担当者はおそらく疲弊し、プロジェクトがもしかしたら解散となっていたかもしれません。
将来を見越したシステムの選択は難しい
ITツールを選ぶ際に、現時点では必要はないが将来追加する場合に余分なコストが発生する要件は、確実に存在します。車に例えるのであれば、軽自動車とファミリーカーのように、新婚のときは軽自動車で十分だったとしても、家族が増えれば手狭になり乗り換えが必要になるでしょう。システム、特にSaaSにおいては同じような状況はよく発生し、現在はコストや小回りの点で適性のあるサービスも、事業の状況によってはリプレイスが発生します。
そしてこのリプレイスに関連するコストにより、結果的に、最初からある程度の要件をクリアできるサービスを選んでいた方が安上がりだったということが起こりえます。検討すべき要素が増えれば、それだけ複雑な判断になるのです。
こうした状況に対して、「CXaaS」は最適な選択肢となります。自由度の高さと、それに対するコストを気にすることなく利用できる費用体系、そしてFAEの支援により、負担を気にせずに状況に合わせた利用方法を選択できます。つまり、ユーザー企業の担当者は現在必要とする要件に集中して判断を下すことが可能になります。
コミュニケーションから導ける必要機能
ユーザー企業の担当者は、現状のシステムが抱えている課題をわかっていても、必要な機能に結び付けることができなければ、どのような解決策を求めているのかが具体的には定義できません。このような状況においても、FAEの役割は非常に大きいと思います。
例えば、現状で使っている顧客情報管理システムで、問い合わせのあった電話番号の入力作業に毎回すごく時間がかかっており、入力ミスが多かったとします。この課題を解決するにはどうすればいいのか、ユーザー企業担当者が具体的な方法まで発想し、要件を詰めていくことは大変でしょう。
それに対して、FAEに現在の課題と目的を伝えることができれば、コミュニケーションを通してシステムの仕様も踏まえた上でのアドバイスが可能です。そして、実際に実装へと進むのであれば、その作業はFAEが行います。ユーザー企業の担当者はAPI（機能連携に用いられるインターフェース）などの詳細要件や設定方法などについて、不安な思いで勉強しなくても済むのです。
見えないコストを最小限にとどめることが可能
次に担当者を悩ませるのがコストの問題です。想定していた予算から追加で必要な機能が判明し、後から見積もりが提示された場合、社内外に対して調整が求められるのはユーザー企業の担当者です。今まで経験がないプロジェクトのハンドリングであったとしても、見積もりが甘いということで、場合によっては社内での立場が悪くなる可能性もあります。
それに対して「CXaaS」であれば、当初想定していなかった必須要件が追加になったとしても、定額の費用の中で対応が可能です。もしこれを都度請求されていたら、そのたびに社内を説得するのか、機能を諦めるのか、提供ベンダーと交渉するのか、いずれにしろ、相当なストレスとなることは間違いありません。こうした負担も減らせるのが「CXaaS」の強みです。
「用意」する苦しみからの脱却
従来のオンプレミス型システムの運用では、システム更改は5年ごと10年ごとに発生し、大規模なシステムの更新が必要でした。オンプレミス型システムの導入プロジェクトは、SaaSの導入と比較すれば高額かつ長期的であり、担当者の負担は大きいと言えます。それでもたまに訪れる大仕事と考えれば、耐えられるかもしれません。しかし、今後本質的な意味でのDX、すなわち「攻めのIT活用」を各企業が志した場合はどうでしょうか？
5年ごとにゴールを設定するにはとどまらず、常に新しいゴールに向けた取り組みが要求されます。そして、その取り組みのたびにユーザー企業で選ばれた担当者は最適な手段、すなわちITツールの「用意」が求められるようになるはずです。こうなれば、これまでは負担もコストもやせ我慢でなんとかやり過ごしてきたという企業も、本質的な対応が求められるのではないでしょうか。
その本質的な対応の一つの回答が「CXaaS」であり、ユーザー企業の担当者のよきパートナーとして寄り添う存在がFAEであると、私は考えています。
SaaSの基本戦略から逸脱した「CXaaS」
従来のクラウドサービスの類型として「CXaaS」が提供する機能はSaaSに分類されますが、ソフトウェアの提供に関する基本戦略は、一般的なSaaSとは大きく異なります。
SaaSはクラウド上で用意された機能を選択して利用してもらう形態が一般的です。言い換えれば、用意されていない機能は提供できず、個別のユーザーのニーズに合わせて機能を開発するという発想は生まれづらいのです。
もちろん、SaaSの良さは継続的なアップデートによる機能拡充にあります。多くのユーザーから要望された機能であれば、意見を反映してもらう可能性もありますが、個別性の強いニーズへの対応は優先順位として低くなるでしょう。このように、SaaSの基本戦略とはユーザーニーズに対する最大公約数的な機能をサービスとして提供することを目指すものと言えます。
また、新しい機能を追加するにもエンジニアの稼働が発生します。そうした場合、せっかく作った機能によってより利益を確保したいということも自然な考えです。結果として、オプション機能として提供することで追加の費用を求めたり、従来のシンプルな機能を低価格で提供するパッケージと比較して多くの機能を高価で提供するパッケージのように付加価値に応じたエディションを展開したりするなど、提供機能に応じて少しでも収益性を高めることを追求するアプローチが戦術として見受けられます（図5）。
SaaSの弱点を克服するCXaaS
一方で「CXaaS」ではどうでしょうか？ これまでに紹介した通り、SaaSの基本戦略である最大公約数的なアプローチとは異なり、「CXaaS」ではユーザーの個別ニーズをすくいあげることを価値としています。また、それらの開発作業、そして過去に開発した機能の提供に際して追加費用を求めることはありません。また機能提供にあたり、ARPU（Average Revenue Per User：顧客平均単価）の向上を求めない点についても特異であると言えます。
運用に合わせたシステムの検討を実現
ユーザー企業は、SaaSを選択する上で「帯に短し襷に長し」という悩ましい問題に直面します。つまり、欲しい機能以外に不要な機能がたくさんついた高価なサービスを選ぶのか、欲しい機能がいくつか不足しているが安価なサービスを選ぶのかという、悩ましい問題です。システム導入判断はビジネスに関わるものとなり、費用、つまりコストの重要性は機能要件に劣らない評価軸となります。
この問題はオプション機能やエディションの選択だけではなく、異なるSaaS間の比較検討においても発生します。帯として短くても不便に耐えて利用し、襷として長いのであれば機能を持て余しながら、余分なコストに耐えつつ使っていくことも考えられます。ユーザー企業がシステムに合わせて運用を検討するという、逆転現象が発生するのです。
ユーザー企業の立場からすれば、不本意ではないでしょうか。やはり、運用に合わせて最適なシステムを利用していくことが理想的であるはずです。「CXaaS」ではその理想に対して、完全にフラットな費用体系を設定し、その費用体系の中で全ての機能、また開発が必要なのであればその開発に関わる対応も含めて提供します。そうすることで、ユーザーにとって機能要件、コストの判断を単純化し、運用に合わせて自由に使いたい機能を利用してもらえるようになります。
システムを使いながら成長可能
システム導入の担当者は、忙しい業務の中でマニュアルや仕様書などのドキュメントだけでシステムを理解することは、実際には無理な話です。実際に触って使って初めて理解できることも多いでしょう。まさしく、A社の担当者の事例がそうでした。導入前に全ての機能を完璧に理解し、活用のイメージを具体的に持って、利用するシステムを選択するというのは無理があるのです。
それに対して、「CXaaS」のように、まずはシンプルな利用方法でシステムを運用しながら、さまざまな「気づき」を得ていき、その「気づき」から運用にフィットした利用法を見つけていくというのが、現実的で最もリスクが低いIT活用の在り方であると思います。このIT活用の在り方を実現するのであれば、やはり幅広い機能提供が前提となっていることが求められるでしょう。
また、その機能を持て余すことなく、必要なときに必要な機能を無理なく使えるように「用意」できることも重要です。そして何よりも、やりたいことが出てくるたびに値札が提示されるなら、思ったようなIT活用には至らないのではないでしょうか。システムを使いながら、ユーザー企業と一緒に成長していくためには、機能の充実とコストが高度にバランスをとれていることが求められます。
現場から意見を出す文化へ
現場の担当者が知恵を出して業務や製品、サービスを改善していくマネジメント手法としての"Kaizen"は、日本企業の強みを生む企業文化の一つであると思います。小さな改善の積み重ねが、気づけば競争力の源泉となっていくのです。この強みが、さまざまな要因が絡み合って活かせていないことは、IT活用の分野における大きな損失と言えます。
それに対して、「CXaaS」はこの状況を打開する一つの方策であると考えています。A社の事例で見られた、運用の中で生まれる「気づき」と、改善のために生まれるシステムへの要求をサービスとして解決できる体制を提供できるからです。DXというと派手で画期的な印象がありますが、DXに求められる「攻めのIT活用」の実践と仮説検証の在り方として、日々の運用における「気づき」に対する小さな改善をITを活用しながら継続することも重要な要素であると考えています。
