プロジェクトオーガナイザの吉田聖書です。
5月2日に、3月の横浜市に続いて、今度は川崎市のコンビニで他人の戸籍謄本（戸籍全部事項証明書）が交付されたという事故が発生しました。この事故について証明書交付サービスのシステムベンダーである富士通が、9日にお詫びのプレスリリースを出しました。
川崎市様における証明書誤交付ついて（お詫び）（2023/5/9 富士通Japan株式会社）
3月の横浜市の時は対象の帳票が住民票でしたけれども、今回は戸籍謄本というところが違います。違いはそれだけでなく、そもそも別のプログラムの不具合だということです。で、面白いのは、そのプログラムを使っているのは川崎市だけだということなんですね。面白いというか不思議ですよね。戸籍のシステムは、日本全国どこの自治体でも同じアプリケーションを使ってないとおかしいと思います。ですが実際はそうなっておらず個別に調達・構築されているようです。
私自身は自治体のシステム開発や運用に携わったことが無いので何とも言えませんが、自治体システムの関係者からすれば当たり前すぎる話なのかもしれません。
3月の横浜市の事故では、直接の引き金はコンビニでの証明書交付サービスの利用者の増加でした。今回は必ずしもそうではなさそうです。というのも、3月の時は、過負荷によるタイムアウトが原因でしたが、今回は2人のユーザーが同じタイミングで証明書の交付申請を行ったことが原因だと発表されているからです。
もう少し詳しく見てみると、「2か所のコンビニで、2名の住民の方が同一タイミング（時間間隔1秒以内）で証明書の交付申請を行った際に、後続の処理が先行する処理を上書きしてしまう」のが原因だとプレスリリースには記載されています。そんなことがあり得るのか？と思うかもしれませんが、実は過去に私が関わったシステムで似たような事故がありました。
関わったと言っても、私自身が開発したわけでもありませんし、担当していたシステムから利用する外部サービスだったので、構築時に実装レベルの検査は出来なかったという前提があります。もうずいぶん前の話でうろ覚えですが、元々の実装として、印刷をリクエストする時に、システムのタイムスタンプを年月日時分秒の形式でキーにしていたそうです。ただ、構築当初はそれで問題にはなることはありませんでした。
ところが、ある時、そのサービスの基盤を刷新して処理スピードが上がり、1秒間で複数のリクエストを処理できるようになりました。そうすると、秒刻みのタイムスタンプではキーが重複してしまい、結果として別のデータが印刷されてしまうという事故に至りました。その時の対処法としては、確かタイムスタンプをミリ秒の精度にするということだったと記憶していますが、それでも付焼刃的で対策としては危ういと感じます。
タイムスタンプをキーとして使うアイデアは割と一般的ですけれども、タイムスタンプ「だけ」を使うというのは今の時代、もう少し深く考えた方が良いのではないかと思います。もっとも、今回事故を起こしたプログラムが、同じ仕組みで事故に至ったかどうかはプレスリリースからは読み取れませんけれども、当たらずとも遠からずと言ったところではないでしょうか。
※ この記事は、先日公開した以下の音声コンテンツを基に編集したものです。
プレスリリースでは「これまでに他の自治体様で発生したコンビニ交付の印刷障害を受け、類似サービスの総点検を既に完了しております」としていますが、奇しくもそのプレスリリースが出された同日に、河野デジタル大臣から富士通に対してコンビニ交付サービスを停止しての再点検が要請されています。サービスを停止しなければ実施できない点検がどのようなものか、パッとイメージできないのですが、もしかすると、本番系で徹底的にテストを実施せよということなのかもしれません。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。