銀行などの信用機関の83パーセントが本物の個人データをシステムのテスト用に用いている

銀行が新しいデータベースシステムやATMシステムなどを構築した場合，そのシステムが正常に稼動するかどうかを何らかのデータを用いて何度もテストしてみなければならない。ところが，例えば，個人情報（個人データ）を含むデータを開発中のシステムの試験運用で処理させるということは，個人情報（個人データ）を適正に処理することができるかどうかがまだ確認されていないシステムで本物の個人情報（個人データ）を処理するということになるから，形式論としては，個人情報（個人データ）を適正に扱っていないという結論にならざるを得ない。このことは以前から指摘されていたことではあるが，現実にどれくらいの割合で実データを用いたテストが実施されているのかについて正確な統計等が存在しているわけではない。

Dark Readingを読んでいたら，この点に関する調査結果が公表されたということを知った。調査対象が限定されているのだけれど，銀行などの信用機関が取り扱う個人情報（個人データ）は基本的に機微な情報（センシティブ情報）に該当するから，良い対象をサンプルにとった調査なのではないかと思う。

　Live Data In Test Environments Is Alive And Well -- And Dangerous
　dark READING: 3 16, 2010
　http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=223900045

この調査結果は，銀行などの信用情報を扱う機関に関するものだが，現実には，およそすべての種類の業種において同じようなことが行われているとみてよい。

もちろん，テスト用の模擬データが開発されている。

しかし，実データによるテストをしてみないとわからないバグや不具合というものがないわけではなく，なかなか難しい問題だといえる。例えば，正常なデータだけではなく何らかの問題のあるデータに対する例外処理をするためのモジュールのテストでは，模擬データにおいて想定されているエラーしかテストできていないという問題がある。例外処理のモジュールでは，およそ全ての種類のエラーデータに対して例外処理できなければならないはずなのだが，模擬データに含まれているエラーデータが人為的に構成されたデータである以上，種類が限られてしまうのだ。実データであれば，システム開発側では想定不可能なとんでもないエラーデータが現実に混入していることがあり，現行システムではそれがエラーデータであるとは認識されていなくても開発中の新システムではエラーデータであると認識されるということがあり得る。そのような場合に，正常に例外処理ができるかどうかがまさにテストの目的の一つなのであり，もし例外処理のモジュールに欠陥があると，最悪の場合にはシステム全体が暴走するということもあり得る。

他方，分量という問題もある。一般に，少量のテストデータを処理させてみたところ何も問題が発生しなかったが，実際の業務で取り扱っているのと同じレベルの大量のデータを処理させてみるとシステムに異常が生じたり処理できなくなってしまったりするということがしばしばある。もちろん，理論的には模擬データを大量につくればよいということになりそうなのだが，システムの種類によっては，エラーデータを一定分量で含む模擬データを大量に用意するのが意外と難しいことがある。詳論は避ける。

それやこれやで，実データによるテストの需要があるのだ。

ここにもまたトレードオフが存在する。

この問題を解決するためには，かなり大規模なクリーンルームのようなものを構築し，その中において実データでテストするというようなやり方を導入するしかないのではないかと思う。