効果的なユーザーサポートとは?ユーザーの自己解決を促す仕組みづくり

2022-03-09

デジタルトランスフォーメーション(DX)を推進するにあたり、新システムを導入するケースが多いですが、導入する以上多くのユーザーにシステムを利用してもらうことが重要です。そのためにはユーザーがシステム利用の障害となるような問題に直面した場合に、それを解消するようなサポートをストレスなく受けられるような仕組みが必要です。本稿では効率的なユーザーサポートの仕組みの構築について、実例を紹介しながら解説します。

DX推進におけるユーザーサポートの重要性

DXを推進する際には、新しいシステムの導入も伴うことが多いです。しかしシステムを導入するだけではDXの目的は達成されません。大きな成果を得るためには多くのユーザーにシステムを使ってもらうことが重要となります。

そのためにはシステム利用の障害となるような問題が生じた際に、それを解消するようなサポートをストレスなく受けられるような仕組みを構築する必要があります。満足なサポートが無い場合、ユーザーはシステムを利用することによるメリットを過小評価してしまったり、利用負荷を過大に評価してしまったりすることで、システムを利用しなくなってしまう恐れがあります。

ユーザーをサポートするには、大きく分けて2つの方法があります。1つはヘルプデスクと呼ばれる、ユーザーからの問い合わせを直接受けつけて解消する窓口を設ける方法です。もう1つはユーザーが問題を自己解決できるようにシステム自体を改善したり、マニュアルやFAQの公開といったサポートドキュメントを拡充したりする方法です。

DXを推進する際には複数のシステムを多数のユーザーに向けて導入することが多く、サポートに要する工数はシステム数やユーザーが増えるに伴い増加します。2つのサポート方法を有機的に組み合わせることで、効率的かつ持続性のあるサポート体制を構築することが重要になります。

PwCあらた監査法人(以下、PwCあらた)全体のDXを推進する部署であるアシュアランス・イノベーション&テクノロジー部(以下、AIT)での事例を元に、効率的なユーザーサポートモデルを紹介します。

PwCあらたのユーザーサポート体制

AITではユーザーサポートを主に2つのチームで提供しています。1つはプロダクトチームです。こちらはシステム企画、導入および保守開発といったプロダクトマネジメント全般を行うチームであり、サポートドキュメントの提供主体です。このチームは会計士やITの専門家で構成されており、現在30名程度のメンバーで多数のシステムを運営しています。

もう1つがヘルプデスクチームです。こちらのチームはユーザーからの問い合わせ窓口を担っており、マニュアルやFAQに記載されている内容や過去の問い合わせ事例を元に、問い合わせの一次対応を行います。ヘルプデスクチームで解決できない問い合わせについては、プロダクトチームの担当者に対応を依頼します。チームは現在、5名のメンバーで運営しています。

図表1はサポートフローの概要を記載したものです。

図表1:サポートフロー概要
図表1 サポートフロー概要

プロダクトチームは毎年複数の新システムをリリースしており、今後も同様のペースでリリースを続ける見通しです。サポート範囲も年々拡大する見込みであり、ユーザーに必要なサポートを効率的に提供することが課題になります。

ユーザーサポート効率化の仕組み

ユーザーサポートには2つの方法があることを前項にてご紹介しました。1つはヘルプデスクによる対応、もう1つはユーザーが自己解決できるような仕組みによる対応になります。効率的にサポートするためには、この2つの方法の特色を理解したうえで上手く組み合わせる必要があります。

ヘルプデスクではユーザーに寄り添ったサポートを提供できるため、自己解決にゆだねる場合と比べて、ユーザーがシステムを利用しなくなることを防ぎやすくなります。また、問い合わせ内容からシステムの改善点を把握することもできます。一方、問い合わせを受けるたびにヘルプデスクチームおよびプロダクトチームの人的リソースが必要になるため、問い合わせ件数の増加に比例してサポートコストが高まるという課題があります。

ユーザーが自己解決できるようにする方法は、資料作成などの対応を1回でも実施してしまえば、追加のサポートコストはほぼ必要ありません。一方、ユーザー自身にも自己解決をするITスキルが必要となります。また、ヘルプデスクでの対応と比べるとユーザーが抱えた問題を正確に把握できないため、問題点が分からないままユーザーがシステムを利用しなくなってしまう恐れがあります。

図表2:ユーザーサポート方法の特徴

 

ヘルプデスク

ユーザーによる自己解決

メリット

  • ユーザーに寄り添ったサポートができる
  • システムの課題を把握できる
  • 資料を作成してしまえば、追加のサポートコストは少なくて済む

デメリット

  • 問い合わせ数に比例した人的リソースが必要となる
  • ユーザーに一定のITスキルが必要となる
  • プロダクトチーム側がユーザーの課題を把握しにくい

リソースが潤沢にあるならばヘルプデスクでのサポートを手厚くすることが理想的です。しかし、システム数や利用ユーザー数が年々増えていく現状では、ユーザーによる自己解決を促し、新システムのリリースを継続して行えるようにサポートコストを下げることが重要です。

図表3:サポートコストイメージ
図表3 サポートコストイメージ

では、ユーザーによる自己解決ができるような施策を進めるにはどのようにすればよいでしょうか。実は、ヘルプデスクに寄せられた問い合わせ内容が重要な役割を果たします。

ヘルプデスクに問い合わせが寄せられるということは、システムの操作性やサポートドキュメントが不十分であったと考えることができます。その問い合わせをもとに、ユーザーが自己解決できるように検討することで、問い合わせの件数を減らすことができます。このような取り組みを継続することで、サポートコストは逓減していくのです。

図表4:ヘルプデスクのフィードバックループ
図表4 ヘルプデスクのフィードバックループ

図表4は、ヘルプデスクで問い合わせを受け付けてからサポートコストの削減につなげるまでの流れを示したものです。起点はヘルプデスクへの問い合わせ受付となります。問い合わせがあった際、その場では解決までに多くの時間をかけられない場合も多く、問い合わせたユーザーの問題を解決できるならば、暫定的な方法も含め問題解決に努めます。その後、問い合わせ内容を振り返り、ユーザー自身で問題が解消できる方法を検討し、実際に改善します。その上で、ヘルプデスクに同様の問い合わせが来なければ適切に改善できたと判断します。

ユーザーが自己解決できるようになるための施策の具体例

ユーザーが自己解決できるようになるためには、どのような施策を検討すれば良いでしょうか。まずはユーザーが問い合わせにたどり着くまでのステップを見直し、改善可能なポイントを特定することが重要です。

ユーザーはまずシステムを操作します。問題が生じた際にはマニュアルやFAQを参照します。それでも解決しない場合にはヘルプデスクに問い合わせを行います。つまり、ヘルプデスクに問い合わせるまでに、ユーザーが触れるシステム内、もしくはマニュアルやFAQなどのサポートドキュメントのいずれかで問題を解消できるような情報を提供できれば、ユーザーは問題を独力で解決できるようになります。

図表5:ユーザーに情報提供できるポイント
図表5 ユーザーに情報提供できるポイント

改善すべきポイントを絞り込む際には、問題の内容がヒントになることがあります。例えばシステムの不具合が原因である場合、システムを改修するのが良いでしょう。また、マニュアルやFAQの誤りが原因である場合には、その部分を修正すべきです。

ただし、多くのケースでは複数のポイントを改善する余地があります。そういった場合には、どのように判断するのが良いでしょうか。考え方の1つとしては、特に発生頻度が多いものや重要度が高いものについてはシステムでの改善を最優先し、次にマニュアルを充実させ、最後にFAQを拡充させることが考えられます。これは問題が解決するまでの速さとユーザーが目にする頻度を軸とした改善方法です。システムそれ自体はユーザーが必ず触れるものであるため、システム自体の使いやすさを向上させることが最も効果的です。ユーザーはシステム外部の資料を参照する必要がないため、問題の解消も最も速くなります。ただし、システムを変更するための追加コストが高くつく場合や、SaaSなどのように外部システムであるためそもそも修正できないものもあります。

その場合はマニュアルを充実させることで対応します。マニュアルはユーザーが初めてシステムに触れる際に参照する可能性が高く、ユーザーに内容を覚えてもらうことも期待できます。SaaSなどの外部システムであっても自社向けのマニュアルを用意するケースは多く、改善の余地がある場合が多いです。ただし、マニュアルに情報を詰め込みすぎると読みにくくなり、ユーザーがマニュアルを敬遠してしまう可能性もあります。そこでマニュアルに反映するほどではない些末な問題についてはFAQに記載するようにします。

改善を行うポイントや優先度は、発生した問題の内容やシステムの特性、自社のユーザー特性によっても変わるため、優先度の高低は一概には言えません。ただし、どこを改善するかによってその効果も異なるため、改善すべきポイントは慎重に検討することが重要です。

これらを前提に、具体的な問い合わせ内容と改善例を紹介します。

システム概要

PwCあらたでは勤怠管理および業務管理のためのシステムを導入しており、その工数情報をcsv形式で出力できるようになっています。これは完全にスクラッチ開発で作成されたシステムであり、ユーザーの利用頻度は月1回程度です。

問い合わせ内容

一部業務の情報が出力されないことに関する問い合わせでした。調べてみたところ、システムの仕様上一部業務は出力対象外になっており、そちらに該当していたことが原因でした。この仕様は注意事項として記載されていたものの、10近くある留意事項の1つとなっていたため、ユーザーに認識されていませんでした。問題の重要度は高くないものの、同様の問い合わせが複数あったため、ユーザーサポートの効率化の観点から、改善の優先度は高いと判断しました。

改善内容

システム利用上の注意事項として、一部業務は出力対象外であることを画面上の目立つ場所に大きく記載しました。情報は書いてあるだけでは不十分であり、ユーザーが気づきやすい場所にあることが重要です。小さな修正でしたが、過去複数件あった同種の問い合わせはそれ以後なくなりました。

システム概要

特定の監査業務を効率化する、PwCグローバルネットワーク全体で利用されているシステムです。汎用的な作りのため多くの設定値があることが特徴です。ユーザーの利用頻度は年に1、2回です。

問い合わせ内容

設定後にシステムを実行した際、エラーが発生するという問い合わせでした。問題を確認したところ、ある1つの設定値を誤って選択していたことがわかりました。同様の事例は複数件あり、原因を調査したところ、選択肢に誤解を招くようなものが含まれており、そちらを誤って選択していたことが原因であることが分かりました。問題解消までに時間を要するケースも多く、また監査の主要な業務に直結したシステムであったため、改善の優先度は高いものでした。

改善内容

こちらはマニュアルを改善しました。当該選択肢の解説ページを追加し、一般的に選択すべき選択肢を明記するとともに、他の選択肢がどのような場合に用いられるものなのか、詳細に説明しました。システムを改善することが理想的なのですが、グローバル共通で利用しているシステムであり、容易に改修できない状況でした。また、当該システムを利用するユーザーの利用頻度は年1、2回程度と少なく、多くの設定値があることからユーザーが利用する度にマニュアルを参照する可能性が高いと想定したため、マニュアルを改修することにしました。改修後、過去複数件あった同様の問い合わせは、ほとんどなくなりました。

システム概要

特定の監査業務を効率化する、小規模な自動化ツールです。作成したものを各自がダウンロードすることで容易に利用できます。スクラッチで作成したもので、細かい不具合を半年に1回程度修正しており、利用前には最新版をダウンロードした上で実行することを推奨していました。ユーザーの利用頻度は年1回程度です。

問い合わせ内容

利用時にエラーが発生するという問い合わせでした。問題の原因は過去に修正済みの不具合でしたが、過去のバージョンを利用していたために発生していました。過去のバージョンを利用したことに起因する問い合わせはいくつかあったものの、それらの原因となった不具合の種類はさまざまでした。なお、これらの不具合によってエラーが発生したとしても業務上の問題は大きくなく、優先度が高いものではありませんでした。

改善内容

こちらはFAQを改善しました。具体的には、過去のバージョンを利用した際に表示されるエラーメッセージごとにFAQを作成し、バージョンアップにより解消することを案内する内容のものでした。

こちらのツールはユーザーがダウンロードして利用する形式のため、システムでの改善が難しいものでした。最新バージョンしか実行できなくする制御も検討しましたが、実装までの見積もり工数が多くかかってしまう一方で問題の影響度は小さく、費用対効果の観点から過去のバージョンを実行できないようにする制御の実装は見送りました。

また、マニュアルへの反映については、通常のユーザーにはほぼ関係ない内容であり、細かすぎる情報を記載することでマニュアルの可読性を落としてしまうこともあり見送りました。

一方、この問題に直面した際にはエラーメッセージが表示されるため、ユーザーがFAQを参照する可能性が高いと考えました。ユーザーがFAQでバージョン差異が原因であることに気づけるよう、エラーの種類ごとにFAQを記載するようにし、同様の問い合わせを減らすことに成功しました。

 

これら3つのケースが示す通り、ユーザーが問題を自己解決できるような改善は小さな修正で達成できることが多くあります。そこで求められるのは、特別な技術や知識ではなく、問題の原因を整理し、適切な方法を検討することです。

なお、ユーザーが問題を自己解決できるようにするためには、ユーザーにも一定のITスキルが必要となります。PwCあらたでは、全職員に向けたデジタル研修を行うことでスキルアップを図っています。デジタル研修に関する詳細は、コラム「AI時代の社員教育(4)役員・新人が同じ机で研修」をご参照ください。

このように効率的かつ持続的にユーザーサポートを提供することで、DXがより進んでいくと考えています。

執筆者

服部 光

マネージャー, PwC Japan有限責任監査法人

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}