マイナカードの一連の問題は明らかな検証不足

ブログ社会制度、インフラ、社会ライフ

(以下、コラム記事を転載しています) **************************************************************************** 

マイナカードに関連するトラブルが頻発している。その多くは、きちんと事前に検証しておけばこんな大事にならなかったのに、と思われる問題ばかりだ。

**************************************************************************** 

マイナンバーカード(以下、マイナカード)の利用に関連するトラブルが連発し、オンライン記者会見やTV番組等で、河野太郎大臣がデジタル庁を代表して釈明や謝罪を繰り返す羽目になっている。

河野大臣の会見と幾つかの報道内容に基づき、どんな問題がなぜ起きているかを簡単に整理してみた(件数は6月12日時点で確認できているもの)。大きく分類して、1)コンビニ交付サービスでの誤交付、2)マイナ保険証の誤登録、3)公金受取口座の誤登録、4)マイナポイントの誤付与、5)マイナポータルでの他人の年金記録閲覧、の5つである。

1)コンビニ交付サービスでの誤交付

【不具合】コンビニでマイナカードを使って住民票の写しや戸籍証明書などを交付するサービスにおいて、別人の証明書が発行される(4自治体で14件)。

【原因】システムの不具合とされる。川崎市の事例では、同じ自治体の住民がほぼ同時に、それぞれマイナカードを使って戸籍証明書を申請したところ、後の人の処理が先の人の処理を上書きしてしまい、先に申請した人にも後から申請した人の証明書が発行されてしまったとのこと。

2)マイナ保険証の誤登録

【不具合】 マイナカードと保険証を紐づけ登録する際に、別の人の情報が登録された(現時点の公表分として全国で7,312件だが、新たな事例が追加されそう)。

【原因】健康保険を運営する組合などが、加入者の健康保険証とマイナカードを紐付ける際に入力を誤ったと考えられる。別人なら住所が異なるため本来なら誤りを見抜けるはずだったが、「あまりに申請の住所と住民票の登録住所の不一致エラーが多く生じるため、住所が一致しなくても生年月日などが同一なら同一人物とみなして作業を進めていた」などといった、マニュアルを逸脱した処理が常態化していた模様。

3)公金受取口座の誤登録

【不具合】他人の公金受取口座が誤ってマイナカードに紐付けられて登録された(748件)。

【原因】①自治体の窓口で直前に利用した人が画面をログアウトせず、次の人が手続きを行ったため。しかもマイナンバーには氏名のふりがなの登録がないことから、ふりがなが登録されている金融機関の口座とシステム上、照合ができないためにこの人為的なミスに気づかなかった。②確定申告の還付金の受取口座を登録する方法の際、国税庁において登録申請者を同姓同名の別人と取り違えたことにより誤登録された。

なお、(本人名義の口座でないとダメなのに)家族名義の口座が約13万件登録されていることも併せて判明したため、9月末までに本人名義の口座に登録し直すように呼び掛けがされている。こちらも本人名義の口座であるかの確認を取れないというシステム上の不備が指摘されている。

4)マイナポイントの誤付与

【不具合】マイナポイント制度において、誤って他人にポイントが付与された(173件)。

【原因】自治体のポイント申し込み窓口で登録する際、前の人がログインしたままの画面で申し込みをしたため、前の人のカードの情報と自分が登録する決済サービスが紐付いた。

5)マイナポータルでの他人の年金記録閲覧

【不具合】マイナポータルで他人の年金記録が閲覧できる。別人の情報と紐づけされているケースが、地方公務員らが加入する共済組合で1件確認されている。

【原因】人為的な入力ミスが原因とみられる。ご入力した個人情報が偶然別人と一致したためとされるが、詳細は不明。

これらの問題に対して政府は、調査や特定、個別対応と通知、システムの改善、情報公開と意識啓発などの対策を打つと報道されている。当然だろう。

確定申告の還付金の受取口座の登録がそもそも間違っていたケースはデジタル庁の責任ではない。そしてコンビニ交付サービスでの誤交付ケースは確かにシステム不備だが(これは改修済だそうだ)、それ以外の大半は人為的ミスによるものとして、河野大臣はそれらに関しては「システムそのものの問題ではない」と庇っていた。

しかしそもそも、こうした国民の多くがユーザーとなる手続きをシステム化するなら、そうした人為的ミスがあっても登録完了前に(エラーになるなど)気づきやすいようにシステム上の工夫をしておくのが当たり前なのに、それができていないのだから許されるものではない。

こうやって整理してみると、事前の検証にてカットオーバー(正式開始)までに徹底的に潰しておくべき問題が大半である。端的に言って、検証不足のままOKを出してしまった役所の大失態である。

小生はITコンサルタントではないが、事業の開発や立て直しのプロジェクトでは新たなシステム構築は今や必須なので、こうしたシステム開発を依頼したり依頼を支援したりすることがよくある。

そこで登場するのがB2B(対事業者)やB2E(対従業員)システムの場合、単体テスト~統合テストを経てカットオーバーを迎えるのがごく普通だ。加えるとしても精々、システム開発事業者にほぼ丸投げで開発した場合に、引き渡しの際に検収テストを行うくらいだ。

この際のテストというのはいずれもテストシナリオに則って粛々と行うものなので、人為的ミスを完全に洗い出すことは難しいことが経験上分かっている。その分、稼働後に多少の不具合が判明して、それに対処せざるを得ないことをある程度は織り込んでいる。それでもユーザーは身内や業務担当者など、「純粋な素人」ではない人たちなので、対処できるものだ。

しかし、このマイナカードのシステムのように、一般大衆と様々な役所の非システム担当者がユーザーであり、かつ個人情報を扱う大規模システムの場合、テストが終わったからといってすぐにカットオーバーしてはいけない。

システムとしての精度を上げるため、実際のユーザーの一部またはそれに限りなく近い、「システムのことを全く知らない」素人の人たちを多く集めて、カットオーバーの前にしばらく使ってもらう必要がある(「試行」とか「トライアル」などと呼ばれる)。

開発者が想定していない操作や正規でない処理を素人ユーザーが行っても、ちゃんと「エラー」表示されるのか、とんでもないトラブルにならないか、周辺システムとの間で思わぬ影響を受けないか/及ぼさないか、等を検証するのだ。

今回のマイナカードで表面化したような人為的ミスによるトラブルの大半は、試行をきちんと行っていればすぐに発現する類だ。発現した不具合の原因を突き止めて、試行期間中に防止策を講ずることができたはずだ。

今回のマイナカードのシステム開発の主契約者は、そうした「試行」というやり方に慣れていなかったのかも知れない。もしくは今回のような複雑なシステムだと、試行をするとしても幾つもの関係機関と非常に面倒な調整を要するので、試行自体を嫌がる発注者(デジタル庁)の反対論に気おされてしまったのかも知れない。

しかし、もしかすると開発スケジュールが遅れたために、当初は計画していた試行を省いてしまったか、試行規模(人数×期間)を話にならないほど縮小してしまった可能性も多分にある。

当初は計画していた試行を省く/大縮小することを、システム開発事業者が自ら提案するとは考えにくい。往々にしてあり得るのは、システム開発のリスクをよく理解していない発注主(この場合はデジタル庁または内閣)の「偉い人」が、無理にでもカットオーバー予定に間に合わせるよう「鶴の一声」で命令するケースだ。

「公開日は世間と関係省庁・自治体に通知済だから延ばせない。何としても公開日に間に合わせよ。そのためには多少リスクをとっても構わない。最終的な責任は私が取る」と。

しかし実際にそのリスクが顕在化(今回のように致命的トラブルが表面化)しても、こうした「偉い人」たちは「そんなことを言った覚えはない」と頬かむりするのが常だ(だから外資系業者なら一筆書いておいてもらう処だが、日系では聞いたことがない)。

今回は本当のところ、どうだったのだろう。それこそ報道陣には事実を「検証」して欲しいものだ。

今回こうした検証不足による一連のトラブルを招いておきながら、政府は2024年秋に健康保険証を廃止して「マイナ保険証」に一本化する方針を未だ取り下げておらず、河野大臣が自分への「何らかの処分」を口にするだけだ。国民の不安を取り除いて信頼を回復するポイントを見誤っていないだろうか。