システムは正しいのに、なぜ顧客は怒るのか？ITクレームの本当の原因は「期待値のズレ」にある

クレーム過多。システムは正しいのに、なぜ顧客は怒るのか。期待のズレはどこで生まれるのか。

「システムにバグはありません」
「ご要望いただいた仕様どおりに開発しています」
「技術的には問題なく動いています」

言いたい気持ちはわかります。
現場を知っている方々は「あぁ。。。」となるはずです。

そうです。システム開発やプロジェクトの現場では、こうした説明が行われることがあります。
実際、エンジニアが嘘をついているわけではありません。
事実です。
プログラムも問題なく、バグもない。

テストにも合格し、設計書どおりに動作しているのであれば、技術的には正しい説明です。

それでも顧客からは、次のような言葉が返ってきます。

そういう意味で頼んだのではない
確かに動くけれど、現場では使えない
現場が使えばすぐにエラーが出る
こんなことができないとはしらなかった。
なぜもっと早く説明してくれなかったのか

「そちらの事情は知らない、こちらの事情を全く理解していないですね」
ここで起きているのは、単純な技術トラブルではありません。

エンジニアは「仕様どおりに動くか」を見ています。
一方、顧客は「自分たちの仕事が改善されたか」「期待していた結果が得られたか」を見ています。

つまり、
両者は同じシステムを見ながら、異なる品質を評価しているのです。

ITクレームの本当の原因は、必ずしもバグや技術力不足にあるわけではありません。
むしろ、技術的には正しいプロジェクトほど、顧客との期待値のズレが見過ごされることがあります。

開発・プロジェクトの炎上は、技術力だけでは防げない

株式会社EdWorksが2025年11月、情報通信業に従事する技術系人材1,003人を対象に行った調査では、66％がITプロジェクトの炎上を経験していました。

もちろんのこと自慢にはできませんが、私もこの業界も違う業界も含めて多くの炎上を経験してきました。
炎上とは、スケジュール、品質、コストのいずれかに問題が発生し、当初の目標達成が難しくなった状態です。

興味深いのは、炎上を防ぐために最も重要だと考えられている能力です。
「技術力」と回答した人は13％にとどまりました。
一方、「コミュニケーション力」は38％、「問題解決力」は34％でした。

さらに、開発フェーズに原因がある炎上であっても、技術力によってカバーできると考えた人は27％にすぎませんでした。
調査では、炎上の原因として要件定義が55％、設計フェーズが51％と、開発より前の工程が多く挙げられています。

もちろん、技術力が不要という意味ではありません。

一定水準の技術力は、ITプロジェクトを成立させるための前提条件です。
しかし、技術力が高ければ、顧客の目的を正しく理解できるとは限りません。
認識のズレを早期に発見できるとも、変更の影響をわかりやすく説明できるとも限らないのです。

プロジェクトの後半で見つかる問題の中には、実は前半の会話ですでに発生していたものがあります。

• 顧客が「使いやすくしてほしい」と話したとき、その言葉が何を意味するのか。

• 入力項目を減らすことなのか、スマートフォンで操作できることなのか、誰でも迷わず処理できることなのか、作業時間を半分にすることなのか。

そこを確認しないまま開発を進めれば、システムは仕様どおりに完成しても、顧客が期待した成果には届きません。

顧客が評価する品質は「正しく動く」ではない

この問題を整理するうえで参考になるのが、サービス品質を評価する「SERVQUAL」という考え方です。
＊SERVQUALは、顧客が事前に期待していたサービスと、実際に経験したサービスとの差から、知覚される品質を捉えるモデルです。

簡略化すると、次のように考えられます。

顧客が感じる品質＝実際の経験－事前の期待

実際の経験が期待を上回れば、満足につながります。
期待を下回れば、提供側が一定の成果を出していても、不満が生まれます。

SERVQUALでは、顧客がサービスを評価する要素を、次の5つに整理しています。

• 信頼性：約束したサービスを正確に提供できるか

• 対応性：顧客の要望や問題に迅速に対応するか

• 確実性：知識や説明に安心感があり、信頼できるか

• 共感性：顧客の事情や立場を理解しているか

• 有形性：画面、資料、設備、担当者の印象など、目に見える部分が整っているか

この5つは、英語の頭文字から「RATER」と呼ばれることもあります。
これをITサービスに当てはめると、技術力が直接的に貢献しやすいのは、主に「信頼性」です。

正しく動くこと、障害が少ないこと、データを正確に処理することは、もちろん重要です。
しかし顧客は、それだけで評価しているわけではありません。

• 問い合わせにすぐ返事が来るか。

• 専門用語を使わずに説明してくれるか。

• 問題が起きたときに責任を押しつけず、一緒に解決しようとしてくれるか。

• 自社の業務や現場の制約を理解しているか。

こうした対応性、確実性、共感性も含めて、「この会社に頼んでよかったか」を判断しています。

「技術力に関係するのは5つのうち1つだけ」というのは、SERVQUALの原典が示した結論ではなく、ITプロジェクトに応用した場合の一つの整理です。
ただ、技術的品質だけを見ていると、顧客が評価している残りの要素を見落としやすいことは確かです。

「仕様どおりです」が顧客をさらに怒らせる理由

クレームが発生したとき、提供側は事実を説明しようとします。

「契約書には記載されています」
「その機能は対象外です」
「事前に承認をいただいています」

これらの説明は、法的、契約的、技術的には正しい場合があります。
しかし、顧客が不満を伝えている場面で、正しさだけを返してしまうと、説明ではなく防御として受け取られることがあります。

顧客が知りたいのは、誰が正しいかだけではありません。

「自分たちが何に困っているのかを理解しているか」
「この問題はどうすれば解決するのか」
「同じことが再び起きないように何を変えるのか」

この3点を知りたいのです。

顧客が「現場で使えない」と訴えているのに、「仕様どおりです」と返しても、会話はかみ合いません。
顧客は業務上の成果を話し、提供側は技術上の適合性を話しているからです。

仕様書は、合意形成のために欠かせないものです。
ただし、仕様書に書かれていることと、顧客が頭の中で想像している完成形が一致しているとは限りません。
顧客が承認ボタンを押したことを、「期待まで完全に一致した証拠」と考えるのは危険です。

チャットボットは「正解した」のに、顧客は解決していない

この期待値のズレは、AI時代にさらに見えやすくなっています。

CAT.AIがチャットボット、ボイスボットの利用者を対象に行った調査では、いずれも解決率は49％でした。
一方、満足率はチャットボットで42％、ボイスボットで47％と、いずれも半数を下回っています。

ここには、「解決」という言葉の定義の違いがあります。

例えば、顧客が「パスワードを再設定したい」と問い合わせたとします。
チャットボットが再設定ページのURLや手順を正確に案内すれば、システム上は「回答済み」と記録されるかもしれません。
しかし顧客が本当に求めているのは、説明を受けることではなく、パスワードの再設定を完了することです。

案内されたページに移動し、メールを確認し、認証コードを入力し、元の画面に戻る。その途中でエラーが起きても、チャットボットに相談できない。

この状態を、提供側は「正しく回答した」と評価し、顧客は「何も解決していない」と評価します。
AIの回答精度が高くても、顧客に多くの操作や判断を残していれば、満足度は上がりません。

DIAMOND ハーバード・ビジネス・レビューに掲載された記事でも、チャットボットへの不満の根本には、技術だけでは解決できない人間心理の問題があると指摘されています。

より高性能なAIモデルを導入するだけでは、次の飛躍は生まれません。
顧客がAIに何を期待し、どのような状態を「解決」と感じるのかまで設計する必要があります。

AI導入のKPIを「回答精度」だけにしない

AI導入プロジェクトでは、測定しやすい数値が重視されがちです。
回答精度、処理件数、自動化率、応答速度、削減時間などです。

これらは重要なKPI、つまり重要業績評価指標です。
しかし、この数値だけでは、顧客や現場の体験を十分に把握できません。

回答精度が95％でも、最後に必ず電話が必要なら、顧客の負担は減っていない可能性があります。
自動化率が80％でも、残り20％の例外処理が複雑になり、担当者の心理的負担が増えているかもしれません。

応答時間が数秒になっても、質問の意図を理解せず、同じ回答を繰り返すのであれば、顧客の不満はむしろ強くなります。
AIやDXの評価では、技術指標に加えて、少なくとも次の視点が必要です。

• 顧客が目的を完了できたか。

• 完了までに何回の操作、入力、画面移動、担当者の引き継ぎが必要だったか。

• 問題が起きたとき、人に相談できる経路が用意されていたか。

• 顧客と提供側で「解決」の定義が一致していたか。

• 顧客だけでなく、運用する社員の負担が増えていないか。

AI導入の目的は、自動化率を上げることではありません。
顧客と社員の双方にとって、仕事や手続きを無理なく進められる状態をつくることです。

期待値マネジメントは、期待を下げることではない

「期待値を管理する」と聞くと、最初から期待させないようにすることだと考える人がいます。
しかし、期待値マネジメントとは、顧客の期待を意図的に下げることではありません。

できること、できないこと、現時点では判断できないことを明確にし、提供側と顧客が同じ完成像を持てるようにすることです。

そのためには、プロジェクトの最初に、機能一覧だけでなく「顧客が達成したい状態」を確認する必要があります。

「問い合わせ対応を自動化したい」では、まだ曖昧です。

• 夜間の問い合わせにも即時回答したいのか。

• 電話件数を減らしたいのか。

• 新人でも同じ品質で回答できるようにしたいのか。

• 顧客が自分で手続きを完了できるようにしたいのか。

目的が違えば、選ぶ技術も、必要なデータも、運用方法も変わります。

また、途中で仕様や前提が変わったときには、変更内容だけでなく、顧客の業務にどのような影響が出るのかを説明しなければなりません。

顧客が怒るのは、変更そのものよりも、「知らない間に話が変わっていた」と感じたときです。

ITクレームを防ぐために、最初に整理すべき5つのこと

ITクレームやプロジェクトの炎上を防ぐには、開発手法を変える前に、合意のつくり方を見直す必要があります。

1．顧客が購入したものを確認する

顧客が購入したのは、システムでしょうか。それとも、作業時間の短縮、ミスの削減、売上向上、担当者の負担軽減でしょうか。
機能ではなく、期待している成果を言葉にします。

2．「完成」と「解決」の定義を決める

システムが動けば完成なのか、現場が一人で操作できれば完成なのか、業務時間が短縮されれば完成なのか。
提供側と顧客の終了条件を合わせます。

3．できないことを早い段階で伝える

できないことや制約を後から伝えるほど、顧客は「隠されていた」と感じます。
早期の説明は信頼を失う行為ではなく、信頼を守る行為です。

4．例外時の人の動きを設計する

すべてをAIやシステムで処理しようとせず、判断が難しい場合、感情的なクレーム、緊急時には、人へ切り替えられるようにします。
AIを使いすぎないことも、AI活用の重要な設計です。

5．小さく試し、現場の言葉を集める

全社導入の前に、一部門、一業務、一つの問い合わせ区分から試します。

その際、利用率だけでなく、「どこで迷ったか」「何が以前より面倒になったか」「どの説明がわからなかったか」を確認します。

DXは技術を導入する仕事ではなく、認識をそろえる仕事です

私は、DX支援において、最初から大きなシステム導入を勧めることはありません。
まず確認するのは、現場で誰が、何に困り、どのような工夫で業務を回しているのかです。

Excelや紙が残っていることにも、多くの場合は理由があります。

既存システムでは例外処理ができない。入力項目が多すぎる。現場で必要な情報と経営側が必要な情報が違う。トラブル時の対応方法が決まっていない。
こうした業務構造を整理しないまま、新しいシステムやAIを入れても、問題の場所が移動するだけです。
顧客対応をAI化した結果、顧客の怒りを受け止める社員の負担が増えることもあります。

営業活動を自動化した結果、顧客に不要な連絡が大量に届き、信頼を損なうこともあります。

DXで考えるべきなのは、技術的な効率だけではありません。
現場の運用負荷、顧客の操作負荷、社員の心理負荷、そして長期的に続けられる仕組みかどうかです。

技術は正しくても、使う人が置き去りになれば、そのDXは定着しません。

技術的な正しさと、顧客の納得をつなぐ

ITクレームが発生したとき、「顧客がシステムを理解していない」と考えるのは簡単です。
しかし、顧客が理解できない仕組みや説明になっているのであれば、それもまたサービス設計上の課題です。

必要なのは、技術側が一方的に譲ることでも、顧客の要望をすべて受け入れることでもありません。
お互いの前提、制約、目的を言葉にし、どこまでを実現し、何を人の判断として残すのかを合意することです。

DXは、大きなシステムを導入することから始める必要はありません。

• 顧客との約束がどこで曖昧になっているのか

• 現場と経営の認識がどこでずれているのか

• 業務のどこに無理が生じているのか

を整理することから始められます。

AIを使う前に、人の負担、現場の流れ、運用の持続性を見る。

技術的な正しさだけでなく、顧客がどのように受け取り、どこで不安になり、何をもって解決と感じるのかまで設計する。
そこまで考えて初めて、技術は顧客価値へと変わります。

自社の中だけでは、当たり前になっている業務や認識のズレに気づきにくいことがあります。
そのような場合は、経営と現場、技術と顧客の間に外部の視点を入れることにも意味があります。

私は、システムを導入すること自体を目的にせず、業務の棚卸しから課題の整理、小さな実証、現場への定着まで、無理のないDXを一緒に設計しています。「技術的には問題がないはずなのに、なぜか顧客や現場の評価が低い」

そう感じているときは、技術ではなく、期待と体験の間にあるギャップを一度見直してみる必要があるかもしれません。

参考資料

• 株式会社EdWorks「ITプロジェクトに関する実態調査2025」

• Parasuraman, A., Zeithaml, V. A., & Berry, L. L., “SERVQUAL: A Multiple-Item Scale for Measuring Consumer Perceptions of Service Quality,” Journal of Retailing, 1988.

• CAT.AI「AIコミュニケーションにおけるユーザー評価」

• DIAMOND ハーバード・ビジネス・レビュー「顧客に信頼されるAIチャットボットを構築する方法――人間心理に寄り添う6つの改善策」2025年8月8日。

• Harvard Business Review, “Fixing Chatbots Requires Psychology, Not Technology,” 2025.

室﨑　敬太　【Linkedin】【E-mail】
馬車馬テクノロジーズ　業務執行社員/Chief Strategy Officer
その他DX関連の顧問を複数社請け負わせていただいております。

17歳で学生起業家として活動を開始し、事業の立ち上げと運営を経験。その後、ファーストリテイリンググループに入社。 三井住友海上火災保険株式会社にて法人営業やリスクマネジメントに従事し、金融・保険分野における専門性を確立。 独立後は室﨑総合保険／MKエージェンシーを創業。不動産会社との業務提携を経て役員に就任。 コロナ渦以降にAIやDX、プログラミングを学び現在は企業のDXおよびAX戦略の立案から実行までをリード。AI・LLMを活用した業務改革や新規事業開発を中心に、複数の企業において顧問として参画している。 国内上場企業から外資系企業まで、繊維、小売、自動車、金融、不動産、建設、サービスなど多岐にわたる業界での実務経験を有し、業界横断的な知見と実行力を兼ね備えたDXに強みを持つ。