プロジェクトオーガナイザの吉田聖書です。
2月29日に大規模とは言えないものの閏年の閏日に起因するシステム障害が発生しまして、それらを採り上げたいと思います。プレスリリース等は発信されていないようですので日本経済新聞のWeb版（日経電子版）へのリンクを掲載します。
まず、新潟県、神奈川県、岡山県、愛媛県の4つの県警では運転免許証を発行できない状態になったと報道されています。
4県警で運転免許発行できず うるう日でシステム障害か（2024/2/29 日経電子版）
ただし、いずれも詳細なシステム構成は明らかにされていませんが、記事には「運転者管理システム」と「免許証作成機」の2つのシステムが登場します。もしかしたら後者の方は「作成機」とあるので、システムというよりは単なるデバイスなのかもしれません。
システム障害の具体的な事象については記載がありませんが、運転者管理システムから免許証作成機に運転者の情報を送信しようとするとエラーになり、処理を続行できなかったということです。おそらく免許証作成機の日時に関する機能の不備だろうということです。
運転者管理システムから免許証作成機に送信しているデータレイアウトは分からないものの、自分の免許証を見て推測してみたいと思います。IC部分には本籍地が格納されていますが、それ以外にあるかどうかは分からないのでIC内のデータは無視します。目視で確認できる部分に着目すると、券面に印字されている日付だけでも大きく4項目あります。それは運転者の生年月日、免許証の交付年月日、有効期限、そして免許の取得年月日です。取得年月日は実際には3項目ありますが、区分値が異なるだけで意味合いは同じです。
「免許作成機の日時に関する機能にエラーが起きたのが原因」と記事にありますが、パッと思いつくのは西暦と和暦の変換です。ただ、送信した文字列データを単純に印字しているだけなら、閏日であろうとエラーになるとは考えにくいですよね。ですので、文字列データを送信しているのではなく、日付データを送信して、それに対して作成機側で文字列に変換する処理を行っているということになります。
一般的な日付書式の変換処理で閏日が悪さをすることは考えにくく、見たことも聞いたことも記憶にありません。そうは言っても、実際にエラーが発生しましたので、何かがあるんでしょうね。閏日の当日に閏日を印字するのは交付年月日と取得年月日で、免許の更新の場合は交付年月日だけですが、仮に不正な日付が印字されるのを防止するために、日付の妥当性チェックのような処理が走っていたとすると、考慮不足により2月29日を不正な日付と判定してエラーにしてしまった可能性は考えられます。
余談ですが、今回障害が発生した4つの県警では同じメーカーの免許証作成機を使用していたとありますが、地域が分散している割には数時間で復旧なんて随分対応が速かったなと感じました。
※ この記事は、先日公開した以下の音声コンテンツを基に編集したものです。
もう一つご紹介したいのですが、スギ薬局で処方箋管理システムに障害が発生し、処方薬を扱う全国の店舗で会計ができない状態になったと報道されています。
スギ薬局、処方箋管理システムに一時障害 うるう日で（2024/2/29 日経電子版）
こちらも対応は比較的早く、午後1時には全面復旧したそうですが、仮にクラウド上のシステムだったとしたらそれくらいのスピード感は普通なんだろうと思います。
記事では障害の詳しい原因については触れられていませんが、他の薬局チェーンで同様の障害が発生している様子が無いので、パッケージではなく個社システムなのではないかと推測します。こちらは、ジャーナルのようなトランザクションデータを登録する時に、あるいは登録したデータを会計処理する時に2月29日を3月1日と認識して、「まだ2月なのに3月のデータが来るのはおかしい」のようなチェックが走った可能性はありますね。
私の経験上、日時の処理は文字コードの処理と並んでバグが発生しやすいポイントだと考えています。大抵はテスト工程で検出できるんですけれども、そもそもテストケースとして閏日についての項目が漏れていたのかもしれません。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。