明治安田生命の特約保険料返戻漏れ

不祥事

明治安田生命で特約保険料で、本来は契約者へ返戻する分につき返戻していなかったという障害があったとニュースリリースされていました。
なお、リリース資料によると返戻されなかった原因はシステムにあるとされています。
　
「特約保険料の未精算金のご返金について」
http://www.meijiyasuda.co.jp/profile/release/2008/pdf/20081128.pdf
（明治安田生命保険相互会社　ニュースリリース　2008.11.28）
　

１．発生した事象の概要
前納保険料精算システムの対応不備により、主契約の保険料払込期間中に特約保険料を「前納」いただいた?または?に該当するご契約の一部について、以下の精算金が未精算であったことが判明しました。
ａ．前納されていた特約保険料の特約保険期間満了（含む、更新）時の精算金
ｂ．年金開始後契約における特約消滅時（死亡・一括払）の特約未経過保険料の精算金
?旧明治生命で昭和５８年４月１日まで販売した平準払いの終身保険・終身年金保険に「傷害特約」・「災害入院特約」・「手術保障特約」のいずれかが付加された契約のうち、特約保険期間満了時または消滅時に前納保険料精算金のあったご契約
?旧明治生命および明治安田生命で販売した主契約より保険期間の短い特約が付加された一時払契約のうち、特約保険期間満了時または消滅時に前納保険料精算金のあったご契約


どうも、これは20年以上昔に行ったシステム開発で不備があり、それが誰にも気づかれないまま現在に至ったもののようです。
どうやってこの不具合を発見したのかについてリリース資料には全く書かれていません。おそらくほとんど偶然に近い形でたまたま別件で不具合の原因のプログラムを調べていて気付いてしまったのではないかと思います。少なくとも、契約者が気づく類のものではないでしょう。
あるいは、もともとシステム化が不十分でイレギュラー処理として事務作業でカバーするはずのところが現実にはカバーしていなかったという可能性もあります。尤も、この場合は通常はシステム障害とはせずに、事務処理上の不具合とします。もし、これがシステム障害とされたのなら、社内の政治的圧力があった可能性が高いです。
　
このような障害があった場合、影響範囲，原因，再発防止策を私はチェックしています。
今回もそうですが、原因の詳細な内容はリリース資料で書かれていないことが多いです。特にシステム障害では外部に説明するのが困難であるという理由もあって、隠す意図はないけど書けないという面があるのも理解できます。なお、日経コンピュータのような専門誌では、ある程度紙面の制限が緩いのと読者層が素人ではないことからして原因が書かれます。
再発防止策は、ざっくりと書かれることが多いようです。

３．再発防止策
今般の事象につきましては、精算システムの対応不備により発生したことから、未精算の原因となった前納保険料精算のシステム化を実施し、特約保険料の未精算を防止するとともに、定期的なシステム検証を行ない、より精緻化を実施してまいります。

おそらく本音ではこの文章の下1/3の『定期的なシステム検証』は盛り込みたくない内容ではないでしょうか。個人的には今回のような障害を見つけるレベルでのシステム検証は不可能ではないかと思います。
しかし、今回のシステム障害は、金融庁報告をしているはずです。当然に金融庁は、実効性のある具体的な再発防止策を要求します。そこで求められた内容がコレだったかもしれません。
　
一般的に、システム対応というのは以下のような伝言ゲームのようなもので行われます。
　要件定義
　　↓
　外部設計
　　↓
　内部設計
　　↓
　コーディング
　　↓
　単体テスト
　　↓
　結合テスト
　　↓
　運用テスト
　　↓
　本番リリース
ここでいう"コーディング"というのがプログラムを実際に書くことにあたり、ほとんどのシステム障害はそこで書かれたプログラムと"要件定義"で決めた内容のミスマッチによって起こります。さすがに"要件定義"は保険に詳しい社員がやるのが普通ですが、"コーディング"は保険のホの字も知らないド素人がやるのも珍しくありません。つまり、そんなこと言われなくても当たり前と保険業界の人なら思うような事もプログラマーは知らないということが当然にあり得ます。
だから、システムが業務の根幹として重要な企業では、この伝言ゲームは過不足なく正確に伝わっているか、ここ数年ではかなり慎重にチェックして行われるようになっているはずです。きちんとやっている企業なら、伝言のどこで伝達ミスがあったのかドキュメントで確認でき、その対策も比較的容易に検討できると思います。
しかし、20年以上昔はもっともっといい加減でした。会社によっては、その当時はドキュメントとしてきちんと残す習慣もルールもなかったかもしれません。
再発防止策を検討するにあたり困るのがこのような昔に起因するシステム障害です。もはや、伝言ゲームのどこに伝達ミスがあったのか分かりませんし、現在のシステム開発の手順を実施していれば同じようなシステム障害は起こさないでしょう。
かと言って、再発防止策は不要！と言い切る訳にもいきません。確かに、このシステム障害があったことで、この特約に関して他の箇所で精算漏れや計算誤りがないかは当然調べたでしょう。でも、他の特約や保険商品やあるいは全然別の内容で、昔に開発したシステムが起因のシステム障害が発生しないとは到底言いきれません。
再発防止策として確実なのは、昔に開発したシステムのプログラムと現在保有している商品の内容・事務処理を突き合わせて、アンマッチがないか確認することです。しかし、これは非現実的です。まともにやるとシステム全体を再構築するのに等しいほどの分析が必要となり、それに労力を割き過ぎると本社業務部門が機能しなくなる恐れがあります。
プログラムを直接見ないでシステム検証するという手もあります。想定できる全パターンのデータで現在のシステムを動かして、アウトプットが正当かどうか確認するというものです。これも非現実的だと思います。何故なら、想定されるパターンというのが様々な条件の組み合わせになるため、幾何級数的にパターンが増えて膨大になるためです。そこから絞れば現実味は増しますが、検証の効果もそれだけなくなるでしょう。
他にも効果的な再発防止策はありますが、どれもこれも現実的には不可能と思われるものばかりです。
はっきり言って、潜在バグをあぶりだすことを目的にする再発防止策は存在しないのではないかというのが個人的な見解です。