平成から令和に元号が変わってから１ヶ月が過ぎようとしています。この改元の動きの中で情報システムの対応が注目されていました。政府からは 「これまでのところ情報システムに支障があったという報告は受けていない」 という発表がされましたが、実際は以下の様なトラブルが発生していました。
- 某自治体で通知書類の一部の日付が「平成3元年」になっていた。
- 某自治体で4月に送付された水道使用量の通知ハガキの年号が「令和31年」になっていた。
- 某自治体で水道使用量の5月分の検針票の日付が「元年5月」でなく「31年5月」になっていた。
- 一部の銀行のATMでの取引の表示が「2019年」ではなく「1989年」になっていた。（※1989年＝平成元年）
- 某自治体で印鑑登録システムに障害が発生し、数時間印鑑登録ができなくなった。
・・・
いずれも表示や印字上の問題であり、恐らくは取引の記録が行われない、金額等の重要データが実際と異なる、といった重大なトラブルではないため、先の政府発表が行われたと考えられます。 トラブルの発生状況を見ると、地方自治体での発生が目立ちますが、これは多くの民間企業では脱和暦・西暦化が進んだ結果と考えられます。また、報道等で確認できるのは当然ながら住民等が確認可能な対外的システムが対象であるため、企業や自治体の内部でのみ使用されている情報システムも含めると、もっと多くのトラブルが発生しているのではと考えられます。
改元対応のシステム改修は困難だったのか？
改元対応におけるシステム変更内容（いわゆる「変更仕様」）を考えると、以下の様になります。
- 2019年5月1日以降、元号を令和とする
- ただし、令和1年については令和元年と表示・印字する
- 元号「令和」は、2019年5月1日（改元日）以降に発行した文書等に表示・印字する
しかし、システムの変更を行う場合、もう一つの大前提となる（つまり当たり前）の仕様があります。それは、 ・変更仕様以外は変えない
ということです。実際に報道された内容を見ると、「改元で変えなければいけない」ことばかりに注目しすぎた結果、「変えてはいけない」部分を確認していなかったことに由来すると考えられます。逆に言えば、上記の仕様をきちんと理解していれば、それほど難しい内容の修正ではありません。 例えば、「平成3元年」の表記は、改元のタイミングはきちんとプログラミングされていたかもしれませんが、和暦の年数の１の位が「１」であれば「元年」にするようにプログラムしてしまったため、「平成31年」→「平成3元年」と変換されてしまったと考えられます。つまり、「平成31年4月30日までは今まで通り」 という確認を怠っていったため、誤ったプログラムが反映されてしまったと考えられます。（もしかしたら、「平成2元年」「令和1元年」といった表示・印字もされていたかもしれません） 他のトラブルも変えるべきところ、変えてはいけないところの理解が曖昧であったために発生したのでは、と考えます。
なぜこうしたトラブルが発生したのか
私自身は実際に開発の現場にいる訳ではありませんが、こうしたトラブルの発生は単純にシステム担当者のスキル不足以外だけではないと考えます。想定される原因として、以下が考えられます。
1）プログラム変更作業の「ワンオペ」化
2）管理者によるレビュー不足
１）について、深夜の飲食店やコンビニでの「ワンオペ」が問題になっていますが、実際は様々な企業で行われています。その背景として、以下のプラス／マイナス双方の要因があると考えられます。
（＋）オフィスのデジタル化に伴う省力化
（＋）チャットやSNS等によるリアルタイムコミュニケーションの実現と普及
（－）業務量に対する人手不足感
等
一方、システム開発・改修の流れは以下の通りです。
要件定義 → 設計 → 開発（プログラミング） → テスト → リリース
本来であれば、設計・開発担当者+テスト担当者、または設計・テスト担当者+開発担当者の2名体制で実施してチェック機能を働かせるべきなのですが、この一連の工程を「ワンオペ」で行ってしまうと、チェック機能が働かなくなります。つまり、開発を行った担当者がテスト作業を行うと、設計・開発作業で「こう動く」という思いが残存するため、見落としや思い違いがあっても気付きにくくなる傾向があります。（ペーパーテストの「見直し」を行っても満点が取れないのと同じです）
さらに２）が加わると、本来確認すべき内容が十分に確認されず、レビューが完了してしまうというリスクが発生します。このレビュー不足には様々な理由があります。管理者の絶対的な時間が不足しているケースもあります。また、管理者が必ずしも開発経験者とは限らないという側面もあります。様々な業種と同様、システム開発でも工程や役割によって求められる知識やスキルが細分化されています。個々の従業員に掛けられる教育の時間は限りがあるので、昔の様に階段を上がっていくような育成ではなく、ある程度の段階でインフラ技術者、システム開発者、プロジェクト管理者、といった職能に応じた育成をせざるを得ない状況にあります。要員が充足していれば組織内でうまくタスクを割り振ってカバーできるのですが、人的、スキル的に作業量と人員のバランスが取れない場合、十分なレビューがしきれないという課題が発生する可能性があります。
こうした問題点は当然のことながら、改元対応だけの問題ではなく、様々なシステム開発の現場で起こりうることです。
改元は今回だけではない
将来に目を向けると、改元対応は今回だけではないことに留意すべきです。今回の改元対応は改元日や新元号が事前に予告された「特殊」なケースです。
しかし、今後起こるであろう改元対応はある日突然発生します。そのような事態に向けた備えをシステム委託先会社が行っているか、きちんと確認すべきです。
今回の改元対応でも、情報システムの状況や委託先会社の考え方、等の様々な要因によって、短期間（＝低コスト）で対応できたケースもあれば、長期間にわたって大量の人材投入（＝高コスト）で行われたケースもあったと考えられます。日本国内で企業活動を行う以上、「改元」というイベントは発生することが前提です。そこを考慮できない、或いは小遣い稼ぎの場だと考える委託先会社ならば、今後の支援をお任せできるのか、考慮すべきではないでしょうか。
システムユーザー企業による管理の必要性
一昔前はシステム開発会社に対して「餅は餅屋」という考えでシステム開発会社に任せておけばいいという企業も多かったと思います。「どうせ技術はわからないから」という理由でシステム開発会社が作成した文書も全く目を通すことはなく、場合によっては文書類の納品も必要ないと考える担当者も存在します。 しかし、システム開発会社の内部での作業がきちんと行われていないと、稼働する情報システムはトラブルの内在する可能性が高くなり、企業活動にとって大きなリスクとなりえます。そうならないよう、システム開発会社に対する管理を適切に行い、稼働する情報システムの品質を高いレベルで維持することが重要であると考えます。
上記内容に関するご相談やお問い合わせについては、「お問い合せ」のページからご連絡ください。
デルタエッジコンサルタントでは様々な経験を通じて培ったノウハウを活用し、システム委託先の選定から業務のモニタリングまで、外部委託管理の高度化、適正化を支援します。
詳細は、こちらのページをご確認ください。
＝＝＞「外部委託先管理支援サービス」
興味や関心がございましたら、ぜひご連絡ください。
