トップページ > DEVELOPER BLOG > クレームとか

DEVELOPER BLOG

クレームとか

2011-11-30(水) 09:05:19

WEBシステムを書いていると、常に付きまとうのがクレームです。

​そもそもクレームが出ないようにプログラムを書いていく訳ですが、予算や納期、お客様の意向などによって組み込みたい処理を省く(省いちゃいけないのだけど) ケースも出てきます。

一例をあげると、何らかの申込フォームのメールアドレスチェック。​​私としては
​
1) メールアドレスのみを送信して貰う
2) 届いたメールに申込フォームのURL記載
3) 申込
​
または
​
1) メールアドレス入力フォームの横にチェックボタン
2) 認証コードの送信
3) 申込フォームへ認証コードを記入し、チェック
​
といった​​​​​​​​​流れでメールアドレスが正しいかどうかの確認を行った上で申込をして頂くのがベストなのですが、「お年寄りだと理解し難い」「申込手順が多くなるとユーザーが面倒がり離れる」などといった理由で入力→確認→送信といった流れだけで良いと希望されるクライアントも少なくありません。

それはそれで、そういった前提でお客様へ対応して頂ければ良いのですが

お客様から申込メールが届かないと言われてる、バグだ！
​​​​​３度申し込んでメールが届かない。４回目で出来た。申込処理にバグあるのでは？

などとクレームを頂く事が有ります。
で、申込履歴を見てみると、単なるメアド間違い。docomo.ne.jpがdomoco.ne.jpになっていたりなど。PHPのgetmxrrとか使ったりしてドメインの有効性をチェックしたりなども可能ではあるのだけど、そういう使い方はよろしくないらしいです。※OPEN RSV3では選択出来る形として実装。
http://jp.php.net/manual/ja/function.getmxrr.php

もちろん、メアド間違いの場合は -fやreturnで管理者メールアドレスに届くような仕様にもしますが、こういったクレームを出してくるクライアントは、そういった管理もずさんなケースが多いです。

クレームが来た場合は、先ず履歴やヒストリーを見て何が悪いのか自身で確認し、その上で解らない点をこちらに流して欲しいです。もちろんこれは保守・管理契約を締結してるシステムに関しては別です。​​​​毎月お金が掛かるのは嫌だから買取で終わりな形にして欲しいと希望されているのに、その後にサポートするのは当たり前だ！みたいなのはちょっと・・・。でも付き物だろうなぁと思っています。

もちろん、システムバグは早急に無償対応しますし、保守契約を結んでいなくとも可能な限りサポートしています。​​​​それはクライアントが一番理解して頂けてると思いますし、オープンソースへお問い合わせ頂いた方へも可能な範囲で丁寧に対応しているつもです。

ちょっと愚痴っぽくなりましたが、こういったシステムとして必要と思われるロジックを、お客様へご説明する事が一番難しいなと感じています。いわゆるリスクマネージメント。処理を省いた際に生じるリスクを十分に理解して頂く事が重要だなと。ただ、それはプログラム内部に関する事であったり、理解して頂くにはある程度の知識が必要であったりなど、大変では有ります。