【ネタ】通知書類で「平成３元年」と誤表記されてしまった理由がひどい
世田谷区が区民に通知した書類の中に日付が「平成３元年」となっていたものがあったそうです。
実害はなかったということですが、どうしてそういうことになったのか見ていきたいと思います。
原因は？
印刷業者のソフトウェアの不具合が原因ということのようです。
しかしどういう不具合なのでしょうか。
実は和暦の1の位が「１」だったら「元」にするという処理が実装されていたそうです。
そしてテストに使ったダミーデータでは発覚しなかったということのようです。
和暦の1の位が「１」の時という「？」な条件
普通に考えたら和暦が１だったら「元」と表示するという条件の方が実装が楽に思えます。
あえて和暦の1の位が「１」の時という条件にした理由はなんなのでしょうか？
また普通のプログラマーであればすぐに「11」、「21」、「31」、「41」、…と条件に引っかかる事が分かると思いますが、どうしてそういう実装にしたのでしょうか？
実装の考察
固定長レコード
どうもネット上の考察では固定長レコードの文字列に対して置換をおこなっている可能性が指摘されています。
"平成 １年" → "平成 元年"4文字目だけをチェックして元にしていたような感じと思われますが、ただそれでも色々な疑問が残ります。
暫定対応を10年以上使用の可能性
このシステムは平成22年以降に使われだしたシステムだそうです。
ですので元号の元年の処理は適当に入れておいた可能性があります。
「そこの処理は仕様が無いので取り合えず適当に入れといて」の部分はTODOのまま最後まで放置されることはよくあります。
そもそもそのシステムを10年以上使用する想定ではなかったのかもしれません。
レビュアー不在の可能性
実装コードのレビュアーもいなかったのかもしれません。
コードレビュー時に誰が見てもおかしいとすぐに指摘できますし、その時点で処理を変更することも可能です。
仕様通りの可能性
もしかしたら仕様の時点で和暦の１の位が「1」だったら「元」にするというものだったのかもしれません。
そして疑問を持ちつつも問い合わせるのが面倒くさいので、その仕様のままプログラマーが実装したということも考えられます。
プログラマーの凡ミスの可能性
精神的に疲れ切ったプログラマーとか、経験が全くない新人プログラマーが単にやらかしただけという可能性も残されています。
その場合でもテストケースがお粗末すぎますし色々と疑問符の付く開発だと言わざるを得ません。
まとめ
今回の事例に関して言えば、例えプロジェクトにプログラマーとしての能力がないメンバーがいようが、マネージャーがしっかりと管理していればどこかの段階で発覚するミスだと思います。
システム開発に限らずチームで行うプロジェクト等は管理者の管理能力が顕著に試されることが多く、チームメンバーの能力が標準よりも低くてもチームを管理する管理者の管理能力が優れていれば上手くいくことが多いのも事実です。
もしプロジェクトで何か問題が起こった場合、犯人捜しをするよりもまずはチームの体制や管理者の管理能力を疑った方が建設的だと思います。
今回の事例は滅多にない事だと思いますが、システム開発に携わる人間であれば教訓として新人研修などで紹介するのもいいのかなと思いました。