目次
「ARUNASエンジニアの奮闘記」をいつもご覧いただき、ありがとうございます。
今回ご紹介する製品は、ＡＥＳ－ＰＲＭ（電子マネーチャージ機）です。
多数出荷されている製品のため、どこかで見かけたことがある方もいらっしゃるかもしれません。
～思わぬトラブル発生～
さて、早速本題に入ります。
ＡＥＳ－ＰＲＭの設置当初、出荷した３台のうち２台で、「入金直後に操作が固まる」という事象が確認されました。
特に、残高が約３９，０００円台の状態から１０，０００円をチャージした際に、発生していました。
一見すると、入金処理の途中で装置がフリーズしてしまったように見えます。
しかし、本当にソフトが止まっていたのでしょうか？
調査を進めていくと、ソフトが完全に停止していたわけではなく、画面遷移の条件に当てはまらない状態になっていたことが分かりました。
では、なぜその状態が発生したのか。ここから、原因を突き止めるための調査が始まります。
～なぜフリーズしたの？～
今回の不具合は、「入金できる金額の計算」と「画面を切り替える条件」の二つの問題が重なったことで起きていました。
まず、入金できる金額の計算に問題がありました。
[残高に含まれていた「端数」]
ソフト上では、残高を１,０００円単位の値で扱うことを前提としていました。（というか、そのように思い込んでいました…）
ここで問題になったのが、［残高］です。
社内での確認では、マネーカードの残高が［０円］の状態からチャージをすることが多く、残高を減額する際も１,０００円単位前提での動作確認を行っていました。
そのため、残高が１,０００円単位ではない状態での確認が、十分にできていませんでした。
実際のお客様の環境では、残高が必ずしも１,０００円単位になるとは限りません。
そのため、［残高］＋［チャージ可能な限度額（１,０００円単位）］の計算結果が１,０００円単位ではない値となり、想定していなかった条件になっていました。
【障害発生時の上限額チェック】
サーバー側から受信したデータの取り扱いに誤りがあり、本来５，０００円になるはずのチャージ累計限度額が、４，５００円となってしまいました。
当時のソフトは、設定された上限とサーバー側で受信したデータを計算した上限を比較し、小さい方を使用する仕様でした。そのため、誤ったデータの４，５００円を上限として使っていました。
一方、上限判定に使うカード残高は、チャージが１，０００円単位であることに合わせて、１，０００円単位に切り上げていました。実際の残高が１，５００円の場合、計算上は２，０００円として扱います。
図のように、２，０００円をチャージした場合、計算上の合計は４，０００円です。使用している上限の４，５００円を下回るため、この段階では上限を超えません。
ところが、チャージ額が３，０００円になると、計算上の合計は５，０００円になります。本来の上限であれば、ちょうど一致する金額です。しかし、使用している上限は誤ったデータの４，５００円なので、計算上の合計が、判定に使う上限を５００円超えてしまいます。
この状態が、次に説明する「画面を切り替える条件」にも影響していました。
【障害発生時の画面遷移の条件】
この場面で次の画面へ進む条件は、残高と入金額の合計が、上限の４,５00円に「ぴったり」達することでした。
合計が5,000円になると、その条件に当てはまりません。
入金したのに、画面が変わらない――。
チャージ機も遷移先がなくお客様にはチャージ機がフリーズしたように見えていたのです。
「上限を超える金額を受け付けてしまう計算と、上限ぴったりの金額しか想定していなかった画面の切り替え。」この二つが、今回の不具合につながっていました。
では、この二つの問題を、どのように直したのでしょうか。
～再発防止への挑戦～
今回のソフト修正では、［チャージ累計限度額］の計算に使用していた［残高］を、
１,０００円単位に切り上げた値として扱うように変更しました。
あわせて、不要な動作フロー、つまり本来通る必要のない画面遷移も削除しました。
これらの修正により、チャージ上限の判定条件を明確にし、想定外の条件に入って画面遷移できなくなる事象を防止しました。
今回の事象を振り返ると、原因は単純なソフトの条件式だけではなく、
「この値は１,０００円単位で入ってくるはず」という思い込みにもありました。
社内での確認では問題なく動作していても、実際のお客様の使い方やカード残高の状態によっては、その思い込みから外れる場合があります。
今回でいえば、社内では［￥０］からチャージする確認が中心でしたが、実際の運用では、端数を含むさまざまな残高状態で使用されます。
その違いに気づけていなかったことが、今回の不具合につながった大きなポイントでした。
～対策の成果と今後～
その後約１年間に発生したソフト不具合を確認し、今回と同様の事象が発生していないことも確認しています。
今回の経験から、仕様どおりに動くことを確認するだけでなく、
「その前提は本当に正しいのか」
「実際の使用環境では、どのような値が入り得るのか」
まで考えることの大切さを、改めて学びました。
今後も、実際の使われ方に近い条件での確認を意識し、お客様に安心してご利用いただける製品づくりに努めていきます。
最後までご覧いただきありがとうございました。
