iPadによるクレジットカード申し込みを体験してきた

先日、とあるショッピングモールにて、クレジットカードの勧誘を受けました。そのモールでクレジットカード支払いをすると、通常のポイントカードより多くのポイントが貯まりますという、流通系カードによくあるパターンです。元々、クレジット機能の付いていないポイントカードは持っていて、月に一回くらいは行っているので、クレジットカードを作ってみてもいいかなと思っていたところでした。いまここで手続きをすれば商品券をつけますというお誘いに、つい釣られてしまったわけです。

この申し込み手続きが新鮮でした。従来のように用紙に記載していくのではなく、iPadによる入力だったのです。求められる項目は用紙による記載のときと基本的には同じだったと思います。項目を入力すごとに、「次へ」というボタンを押して先に進めていくのですが、文字の大きさも大きく、早くも老眼の気がある自分には助かりました。

一点だけ詰まってしまったのが、住所の入力です。こういうオフィシャルな書類に書くときは、マンション名まで書くことにしています。郵送物が正確に届くようにということはもちろんですが、運転免許証にもマンション名まで書かれているので、その方が手続きにおける確認作業がスムーズにいくかなという思いもあります。ところが、マンション名まで入れたら、文字数オーバーによりエラーとなってしまったのです。最初は担当者もなぜエラーなのかわからず、数字の部分が半角だからいけないのでは、ハイフンの全角はどうやって出すのか、など何度か試行錯誤。文字数オーバーが原因と判明した際には、マンション名がなくても届くならマンション名を外してくださいとのことで、問題はクリアに。そんなに極端に長いマンション名ではないんですけどね。

紙への記入であれば、文字を小さく書く、2行に書く、枠外に書く、など、「運用でカバー」することができますが、システム化されるとそうはいきません。住所欄を何文字にするかは、カード会社の営業部門と情報システム部門とで、何度も話し合いがされた結果決まったことなのでしょう。IT業界に身を置く者としてそれは容易に想像がつきます。ですが、最後は現場の担当者の機転と決断という「運用でカバー」されたのです。

システムを構築した情報システム部門が悪いとか、独断でマンション名を省くことを可とした現場担当者が悪いとか言っているわけではありません。システムに完全を求めるのは難しいということの例を、結構身近に見たということです。もう一つ思ったのは、こうしたケースが頻発してシステムの仕様を変更するとなったときに、変更の柔軟性がどの程度考慮されているのだろうか、ということです。これは今私が、柔軟な変更に強いNoSQL型データベースを担当しているから思ったことなのですが。

エンドユーザーに近い部分、いわゆるユーザーインタフェースは今後も一層ユーザーフレンドリーになっていくのでしょうが、そうした際にこういったことへの考慮が、より顧客満足度に響いていくのではないでしょうか。

全体を通しては、このiPadでの入力はエンドユーザーである私を大きく満足させる素晴らしいものでした。幼稚園児の息子も画面を見ていて興味深かったのか、おとなしく付き合ってくれたのも助かりました。いただいた商品券を使うだけでなく、クレジットカードも使っていこうと思っています。

IBM 中山貴之のWeb Page (平日は毎日更新中)