マイナンバー対応の問題をチャンスに変えた出来事：萩原栄幸の情報セキュリティ相談室（1/4 ページ）

いま現場では様々な問題が発生しているものの、困った状況をチャンスに変えることができた企業が出始めている。筆者が実際に見たケースを紹介したい。

[萩原栄幸，ITmedia]

見直しテストで“逆転勝利”

　マイナンバー制度への取り組みが早かったA社でのケースだ。今年（2015年）2月には、既にテスト環境でマイナンバーのエントリーシステムや人事システムなどサブシステム単位でのテストを繰り返し実施していた。5月からはサブシステムをつなげた週次、月次、期次、年次といった処理のテストも繰り回し実施するなど順調に作業を消化しているという。たぶん中規模以上のシステムを擁する企業の中では早い方だろう。

　しかし残念ながら、このマイナンバー対応プロジェクトの要員の中に、A社のシステム群全体を俯瞰できるシステムエンジニア（SE）がいなかった。そこで経験豊富な勤続30年程度のSEとベンダーが、ピンポイントでチェックしていた。通常こういうプロジェクトではサブシステム内部における設計変更については問題がない。それより、サブシステム間での連動や障害対応時に発動されるプログラムなどについて、見落としが生じてしまう可能性が高い。

　筆者も、A社のその他の基幹システムにおけるインフラ部分に関して根本的な設計変更を行うプロェクトに参加していた。2018年4月にリリースされる予定の約800ある現存システムについて現状調査を実施し、セキュリティに特化した問題点を洗い出した。その作業が収束して引き継ぎをしていたところ、A社の役員からマイナンバー対応プロジェクトにも一度参加してほしいと要請され、加わることになったのである。

　マイナンバー対応プロジェクトの方は、テスト環境では実施できない複雑、大量、障害といった各種イベントを挙げて、そのテストの有無や割り切り事項、危険度、代替策などについて検討していた。いつも前倒しで作業を推進している企業だけあってその取り組みはすばらしく、専属ベンダーがチェックしていたこともあり、ほぼ完ぺきであった。

　一度みてほしいという程度の依頼だっただけに、筆者はこれで円満に契約を終了するだろうとの思いから、半ば「見学者」として見守っていた。だが資料を解析してみると、きれいにまとめられていた一覧表の中で、とあるプログラムに関するテストケースに目がとまった。

　それはテストの可否について「NG」とされた点である。理由は、主要システムのほとんどが関係していて日程も時間も動員する余力もないということだった。机上ながら十分にチェックし、プロシージャー単体での確認テストも実施済みとある。しかも、これが発動する可能性も極めて低い（過去10年に緊急トラブルは幾つか発生しているが、本件は一度も発動していない）とあった。この説明だけを読むと、いかにも納得できるような文章である。

　しかし銀行の大規模システムを幾つも経験してきた筆者の感覚では、違和感を覚えずにはいられなかった。かつて「嫌がるテストほど率先して行うべき」「費用や人員の面で不可能なら逆に可能にさせて実行すべき」「そこに工夫や創造力が求められる」という事を肌で感じてきたからだ。実際にこれを怠った某銀行では幾重にテストしても、結局はATMの停止という大騒動を起こした。「人事尽くして天命を待つ」には「人事を尽くす」ことが条件である。

　このことをA社のプロジェクトメンバーにアドバイスした。「外部の人間の意見だと片づけるもの良いが、私（萩原）は一応意見を述べる立場なのでお伝えしているだけです。決めるのは皆さん。再考していただけるならうれしい」と。

　その半月後にメンバーからメールが届いた。筆者の指摘に基づいて再度確認してみると、連動処理の一部でパラメータの設定ミスから動かなくなってしまったという。もし本番環境で起きれば、基幹システムの重大トラブル対応に集中している最中での緊急対応プロシージャーであるだけに、本件の原因分析には長時間を要していただろう。机上のチェックだけで済まし、「10年に一度も発動しないプログラム群」と軽視していたが、実際に動かすと、テスト環境ながらトラブルが起きた。もし本番で発動すれば、その対応は想像を絶する対応を余儀なくされたと思う。メールには「感謝したい」とつづられていた。