（この記事は私の主観が大きく含まれていますので、予めご了承くださーい）
お客様システム担当者といろいろな検討を重ね、苦労の末リリースしたシステム。どんなに考慮を重ねても、どんなに丁寧にシステムを作成してもサービスイン後にはすかさずエンドユーザーからクレームが来きますよね。もし「俺のシステムは完璧だから、クレームなんか来たことないよ」という人がいたら、それは余程の天才か「使われないシステムを作った」のどちらかだと思います。
そんなクレームにもいろいろ種類があり、とても有用なクレームを挙げてくれる人もいますが、中にはイチャモンに近いようなクレームを挙げてくるエンドユーザーもいます。
では、どういった人がイチャモンみたいなクレームを入れるのでしょう？ その答えはズバリ「暇な人」です。仕事で実績が上げることができず、何となく日々を暮らしている人にとって新規システムのリリースは格好のターゲットです。そんな人は新しくリリースされたシステムを弄くり回して少しでも不具合と思える箇所があれば、本筋とは関係なくてもこれ見よがしににクレームを入れてきます。恐らく新しくリリースされたシステムの不具合を指摘することで「自分の存在価値を示そう」という思いなのでしょう。（いわゆる承認欲求的な・・・）
考えてみてください。あなたも自社の社内システムのユーザーだと思いますが、もし自社のシステムに不具合や使いずらいところがあったとしたら自ら自社のシステム部にクレームを入れますか？余程のことがない限りシステム部にクレームを入れることはないと思います。なぜならあなたは本業が忙しいからです。
もちろんバグや使いづらい部分については改善すべきだとは思いますが、それはあくまで費用対効果を考えての話。会社に大きく貢献している人のご要望であればシステムを改善する効果も高くなりますが、会社の実績に貢献している人ほど日々の業務が忙しくてなかなかシステムの改善要求まで出してくれないのが実態ではないでしょうか？
ここで私が何を言いたいかといえば、
・システムをリリースしたり、機能改善が行えばユーザーから必ずクレームが来る
・ユーザーからのクレームを一律に対応したのでは費用対効果が悪い
・費用対効果を少しでも上げられるようなクレーム処理のルールをリリース前に準備しておくべきである
ということです。
例えば、
・システムの目的を達成できない程の大きな不具合は別としてクレームは一定期間貯めてから対応を検討する
・不具合の影響度合いも添えて寄せられたクレーム以外は対応しない
などなど、お客様ご担当者と事前に決めて（CIOとか）エライ人の了承ももらっておくとグーです。
いかがでしょうか？ システムにおけるクレームについてリリース前にルールを決めておくということはあまりやられていないと思いますが、皆さんが幸せにリリースを迎えられるアプローチなので是非検討してみてください。
コメント