デジタルビジネス・イノベーションセンター（DBIC）

【横塚裕志コラム】システムLogで　「サービス」の満足度を可視化してみたい

2025.10.09（木）

SMICとDBICの共同チームで、「情報システムのLogデータを駆使して、自社のサービスに関する利用者の満足度を可視化することに挑戦しよう」と考えている。
そこで、そもそもの「サービス」とは何か、「満足度とは何か」を学ぶため、「サービスサイエンス」のプロである松井拓己氏（松井サービスコンサルティング代表）をお招きして、9月19日「サービスサイエンスと顧客価値創造の進化」と題したご講演をいただき、議論もさせていただいた。
松井氏からの学びを土台にして、「サービスの満足度を可視化する挑戦」について、私の思うところを書いてみたい。

１．「サービス」とは何か

「サービス」＝「利用者の行動変容」＋「機能の実行」

「サービス」とは、発揮すべき機能を額面通り発揮することに加えて、利用者の行動を変容し続けること、と松井氏は定義する。機能の実行は当たり前だが、利用者の行動変容を加えているところに、この定義の斬新さを感じる。
加えて、松井氏は、「サービスの改善と利用者の変容が、スパイラルにアップしていく共創状態をつくることが重要」と語る。

２．「満足度」とは何か

松井氏は、サービスに対する利用者の事前の期待感がキーだと説明する。
つまり、利用者が持つ「事前期待」＜「サービス」の価値　のとき、満足度が高くなるということだ。企業側が勝手にいいサービスだと考えて提供しても、利用者の期待とずれていれば、それはいいサービスとは言えない。さらに、その満足度が「大きい」と感じていただけない限り、そのサービスによって売り上げを増やすことはできないということが証明されているそうだ。

３．「サービス」の設計

企業が価値を提供するためには、商品を介して提供する「サービス」が、顧客の事前期待を大きく超えるものでなければならない。そのためには、商品の機能が十分発揮できることに加え、「顧客の行動変容」を促すものである必要がある。そのためには、「サービス」を「設計する」ことから始める必要がある、と松井氏は言う。
そこでふと思った。企業の中に「サービス設計部」があるだろうか。私自身は見たことがない。商品を設計・開発する部門や、商品を実行する部門、商品の品質をチェックする部門は備えているが、「サービス」を定義し、設計する部門がまだまだ企業に存在していないように思われる。同時に、行動変容を明確に定義している企業も少ないのではないだろうか。
例えば、保険業界で言えば、住友生命の健康増進活動をすると保険料が下がる商品、東京海上ダイレクトの安全運転指標を上げると保険料が下がる商品など、行動変容を促す事例はある。このように商品が直接行動変容を促すことも一つの方法と思うが、それとは別に、顧客が自主的に行動変容を起こすサービスが設計できたら素敵だなと思う。

４．「サービス」の満足度をシステムLogで可視化できないだろうか

顧客の「事前期待」が何かを分析し、その事前期待に応えているサービスかを可視化できるといいのだが簡単ではない。
「事前期待」をどのように調べるのか。顧客も自分で意識していない可能性が高いので、まずは、「事前期待をモデル化する」ことから始めるべきと松井氏は言う。その仮説モデルを作成したうえで、それをベースに顧客と対話することが効果的と松井氏は言う。その仮説の立案には、知見とデータでの分析が必要だろう。
ビジネス部門に「サービス設計部」があるのなら、その設計内容に沿って、顧客の状況を探るデータを探すことができそうだ。しかし、そういう部門がないとすると、仮説の立案から始めることが求められる。とても興味深い挑戦だとワクワクする。

５．システムLogが可視化に有効だと思う理由

私が、システムLogの有効性に期待する理由は以下の二つだ。

① 情報システムは現場の姿をそのまま映す鏡
現場の業務は、今や情報システムを使わないことはないという状態にまでIT化している。従って、情報システムの使われ方を分析することで、現場の詳細な動きまで可視化できる可能性を持っている。

② データはまさに事実なので、証明力・説得力は明確
データが示す事実は、理論的な説明などより、正しく明解だ。従って、ビジネス現場から遠い情報システム部門が、あえてビジネス部門に対して「サービス」についての評価を意見するうえでは、必須の武器になる。

６．まずは、「使われていない」「使いにくい」システムを可視化してみたい

「サービスの満足度」はかなりハードルが高いから、まずは、「使われていない」システム機能の抽出・分析から始めてみてはどうだろうか。開発したけど、使われていないシステム機能が多々あると思われる。それらを可視化して、なぜ使われていないのかを発注したビジネス部門と一緒に考えてみるところから始めてみるのも面白そうだ。現場のプロセスが変わっていないのか、現場への告知が不足しているのか、システムの機能に問題があるのか。そこから何かが起きるような気がしてならない。
共通のデータを見ながら、情報システム部門とビジネス部門が、自社のサービスについて深い対話をする機会がつくれると、お互いの考えをお互いが理解することにつながり、より本質的なデジタル化を生み出す道が開けていくように思う。

他のDBIC活動

他のDBICコラム

他のDBICケーススタディ