元号の問題は制度の問題ではなく業務設計と運用の問題だ

2019年4月2日火曜日

システム開発 政治

t f B! P L

新元号が発表された。


新元号は「令和」となる。

左派の元号廃止論

最近、元号改定の時期が近づいているので「左翼」が「元号を廃止すべきだ」という主張をあちこちで行っている。

ただ左翼はずっと昔から天皇(制)を廃止しろと主張しているので相手にしなければ良いと思う。
彼らは日本が嫌いなので破壊したいのだ。
だから天皇や皇室を廃止して共和制にした上で、次は社会主義に移行して民主主義も破壊するだろう。
最後は中国に身売りして国家そのものを消滅させようとするだろう。

左翼は基本的にリベラル(自由主義)の仮面を被った共産主義(社会主義)者なので最初から詐欺みたいなものなのだ。
だから、彼らはよく権力で言論を封じようとする。
Youtubeやtwitterなどでいつも右派のアカウントを通報して凍結している。
議論するより発言させないようにする。
基本的に民主主義の敵なのだ。

ネオリベや合理主義者の元号廃止論

ネオリベや合理主義者の間でも元号廃止を主張する声は大きい。
こちらにはある程度明確な理由がある。
社会的に効率が悪いからだ。
特に情報システムで元号を扱うのが難しく、銀行のように西暦に変更してしまうシステムもある。
ただ、以下にこの点の問題を記述するが、情報システムで扱うのが難しいからと言って元号制度を廃止する必要はないと思う。
最悪、情報システムで使用しなければ良いだけだからだ。
あくまでシステム運用の問題なのに制度まで変更する必要はないだろう。

元号改定の問題は情報システムの問題

元号改定問題は「元号改定に情報システムの改修を間に合わせることが出来ない」ことが本来の問題だと思っている。

昔と違い、業務のシステム化が進み事務処理の大半がITシステムによって行われている現在では、日本中の年号が一斉にリセットされると、一斉に全システムを改修しなければならないので、情技師(ITエンジニア)のマンパワーから考えて、改修は不可能なのだ。

情報システムの改修は時間も金もかかるので、システムの中には今でも「昭和」で稼働しているシステムも存在する。


今回の改元も全て令和に対応するのは不可能なので、一部のシステムは「平成」のまま使用される。

また、一部は西暦を採用する。


通常現在の情報システムは単独稼働するシステムは少なく、他のシステムと連携して動作しているものが多い。
官公庁のシステムには他の省庁と連携しているものも有るかも知れない。

官公庁全体で、昭和・平成・令和・西暦と4つの年号がバラバラに使われるのだ。
他システム連携を考えると非常に複雑になることが分かると思う。

対策は一つではなくいくつかの方法が考えられるが、今のように業務で使用する年号を一つにするというやり方では対応できないと思う。

改元で何をやる必要があるのか






経済産業省からは次のような通知が行われている。


<参考:改元に係る対応の例> 

1.情報システム改修等の対応 

(1)元号をデータとして保有している場合、元号データの変更や 追加または西暦データへの統一化 
(2)書面やシステム上に元号や「元年」を印字・表示している場 合、印字・表示内容の変更 (3)西暦と和暦との変換処理を行っている場合、変換ロジックの 変更または変換テーブルへの登録 
(4)他の事業者や関係機関のシステムと情報連携している場合、 当事者間での対応策の必要性確認 
(5)その他、必要な対応 

2.事務・運用面の対応 

(1)元号の記載が含まれる証書・帳票等の記載の変更 
(2)旧元号が記載された状態で利用が想定される契約書等の証書 や帳票等の取扱の明確化 
(3)運転免許証等の官公署発行の証明書等に旧元号が残る場合で も、有効な証明書等として受け付ける措置 
(4)顧客に影響が生じうる事項への対応策等に関する顧客への十 分な周知 
(5)その他、必要な対応 

※ なお、新元号公表から短期間で改元を迎えるため、全量対応 は現実的に間に合わないことも想定される。そのため、優先 順位を付けた対応が必要になることに留意。また、その場合 でも、旧元号と新元号が混在することを想定した運用が必要 になることも留意。



日付の改修

最近の情報システムの日付はUNIX時間という規格の日付データを使用している。
1970年1月1日0時0分0秒からの経過秒数を32bitの整数値で表した物だ。
これを使用していればシステムの内部的には西暦であろうと平成であろうと内部のデータや仕組みを改修する必要は無い。

しかし全ての日付データをUNIX時間で扱っている可能性は無いと思う。

年や年月だけを整数で扱うことも多い。
その場合は西暦か元号を使用している。

内部の実装方法はシステムによってバラバラである。

また、CSV・XML・json などテキストファイルによって入出力していたりシステム間連携しているときは、そのテキストファイル内で文字列で年月が記載されている。
元号で構築されているシステムはこれらのデータが改元の影響を受ける。
新元号に対応する場合、期間を表している部分は平成で未来の日時を扱っているのでロジックの改修が必要になる場合もある。

作り方次第なのだが、もしロジックが内部で西暦やUNIX時間に変換して処理していれば改修は少なくて済む。

CSV・XML・json などの中身で元号をそのまま使用していれば新元号に対応する処理を加えなければならない。

元号表示の改修

画面や帳票などの表示や印刷は改修しなければならない。
これは目に見えるので、分かりやすいと思う。

データの改修

例えば私の運転免許証の有効期限は「平成34年」までである。
これが警察庁のデータとしてシステムに登録されている。
このデータを新元号に対応して更新する必要がある。
警察庁は西暦に対応したのでデータ更新は必要ないと思う。
新元号に対応したシステムはデータの改修が必要となる。

毎年集計している統計的データなども改修対象になるかも知れない。
システムが改元と同時に新元号に対応できる可能性は低く、後から対応する可能性もある。
その場合、新システムリリースまでに作られたデータは後に改修対象となる。

旧データへの対応

期間や将来予測など未来の日付を元号で出力している場合、「平成34年」など未来の平成日付も読み取れるようにする必要がある。
データ側の改修で済む場合もあるが、一般人に証書のように配布したデータはデータ改修ができない為、システムが「平成34年」と「令和4年」を両方読み取れる必要がある。

他システム連携への対応

現代のシステムは単独で稼働しているものは少なく、大半はシステムとシステムの横の繋がりがある。
システム連携はCSV・XML・json などのテキストファイルをシステム間で送受信して行う。

先に「官公庁全体で、昭和・平成・令和・西暦と4つの年号がバラバラに使われる」と説明したと思う。

システム連携では連携先のシステムの年号に合わせて改修する必要がある。
自システムが新元号に改修しても、連携先システムが平成のまま運用するなら連携処理は元号の変換処理を持たなければならない。

連携先システムは通常は複数あり、それぞれが対応している年号に合わせる必要がある。
連携処理が全て、一度「西暦」か「UNIX時刻」に変換していれば改修は不要だ。
していなければ改修は困難になる。

OSやミドルウェアの対応仕様に合わせる

今のシステムは一社で開発しているわけでは無い。
OSやミドルウェアやライブラリ・フレームワークなど他社製品を組み立てて、さらに自分達の仕組みを開発している。
使用している他社製品が改元に対応していなければ、システムも対応が難しい。
また、他社製品の改元への対応仕様に合わせてシステムを改修する必要がある。
短期間で出来る作業ではないのだ。
MicrosoftとOracleの改元への対応仕様が同じである保証もない。
平成34年をエラーにするのか、令和4年と解釈するのか会社によって違う場合もある。

顧客やユーザーなど人間系への対応

システムの使い方の変更があれば教育が必要だ。
平成と令和に重複が残る場合はユーザー側で対処しなければならない。
その場合の業務設計が必要だ。
マニュアルの作成も必要となる。
場合によっては、専用の電話サポートなどが必要になる場合もあるだろう。

以上、簡潔に新元号対応に必要となる作業を思いつく範囲で纏めてみた。

改元対応は簡単ではない

既に「官公庁全体で、昭和・平成・令和・西暦と4つの年号がバラバラに使われる」ことから考えても、システムの新元号対応は簡単ではないどころか、全てのシステムを改元するのが不可能なのが分かると思う。

将来はもっと多くの業務が自動化されより多くのシステムの制御で稼働していると思う。

その時改元が行われても、もはや新元号にシステムは改修できないかも知れない。

業務設計を見直す必要がある

もし元号を必要最小限でも残したいと考えるのならば、現在の「一つの業務では同じ年号を使う」という前提を改める必要がある。

つまり業務の中で、「元号」を使用していても問題ない部分を絞り込み、問題のある部分は「西暦」か「皇紀」で標準化する。
「元号」を使用する部分を最小限度に縮小し、改元の影響が小さくなるように業務設計を見直すのだ。

業務設計は人間系の業務を含む言葉だ。
人間の仕事のやり方を変えることを意味する。

年号の運用方法を変更するのだ。

業務の見直し方法の例

日付や年月を使う情報処理は、大体「期間」や「予定」を表すデータと、「追加更新日付」になると思う。
「追加更新日付」の中では賃金統計データのように逐次データを記録し過去と現在のデータを比較する為に日付を記録しているものがある。
これを「逐次日付」と呼ぼう。
特に過去と比較したりはしないがそれが何時行われたのかを単純に記録しているものは「記録日付」と呼ぼう。
法律が施行された日付や、政府や官公庁などからの「政令、省令、告示」「訓令、通知、公示」などの日付である。
これらは過去と現在を比較することがない日付である。

つまり日付には以下の種類がある。
期間
予定
逐次日付
記録日付

元号で扱いにくい日付

「期間」「予定」を扱うデータは元号では扱いにくい。
運転免許証のように「平成29年から平成34年」という期間は「平成29年から令和4年」になる。
未来の予定データの年号が変わってしまう。
「平成29年から令和4年」では期間が何年間なのか分かりにくい。
こういうデータは「西暦」や「皇紀」のようにリセットされることのない年号が相応しい。
(ちなみに今年「西暦2019年」は「皇紀2679年」です)

「逐次日付」を扱うデータも同様に元号では扱いにくい。
「平成31年3月,雇用者数=6651万人」
「平成31年4月,雇用者数=6661万人」
「令和1年5月,雇用者数=6681万人」
「令和1年6月,雇用者数=6711万人」
「令和1年7月,雇用者数=6721万人」
という具合にデータの日付が途切れてしまう。
しかも「平成31年」と「令和1年」は同じ年だ。
これはデータとしてあまりにも使いにくい。

よって、「期間」「予定」「逐次日付」は「西暦」や「皇紀」を使用した方が望ましい。

元号に相応しい日付

政府や官公庁などからの「政令、省令、告示」「訓令、通知、公示」などの日付は元号が望ましい。
元号は権威の象徴とも言えるし日本の独立の象徴でもある。
「政令」や「訓令」の日付には元号を使用した方が権威と重要さが伝わる。

これらの日付は情報システム的にもさほど扱いにくくない。
「予定」ではない為、後で変更されることもない。
「期間」でもないので、期間が何年か計算する事も無い。
つまり純粋な日付の記録以外の何物でも無いところが良い。

ただしこれには少しだけ例外がある。
「公布日付」は当日の日付なので元号で問題ないが、「施行期日」のように予定を表す場合は、「西暦」や「皇紀」が望ましい。
なので、「平成31年4月15日公布、皇紀2680年4月1日施行」のように表記する必要がある。

業務の中で二つの年号を使い分ける

元号を情報システムで扱えるようにするならば業務の中で「元号で扱いにくい日付」と「元号を使用しても問題の無い日付」の二つに分け、前者は「西暦(皇紀)」を、後者は「元号」を使用する業務ルールに変更した方が良い。

全て元号で扱うと改元時のシステム改修が大がかりになりすぎ、実質システム改修が出来ず、西暦などに変更せざる得なくなる。

現実に未だに「昭和」で動いているシステムも存在するのだ。
「システム改修は簡単ではないし金も時間もかかる」という事実を受け入れるべきだ。
大東亜戦争のような精神論でシステム改修はできない。
また敗戦したいのだろうか。

先に説明したように、期間・予定・逐次日付は西暦(皇紀)で扱い、政令や訓令のような記録日付は元号を使用するというルールにすれば、システムの大半は改元時に改修不要になり、権威ある政令や訓令などの要所には元号を残すことができる。

しかも記録日付は改元後から変更する必要がないのでシステム対応の負担が少ない。

以上のやり方なら、全てのシステムに最小減「元号」を残すことができる。

つまり業務設計を改元がやりやすいように作り替えてしまうのだ。
その為に「元号・年号」の運用を変更する。

保守派の強引なやり方では元号はシステムから消滅する

保守派は当初、新元号の発表は改元後に行うと明言した。
安倍総理がITに配慮したのか一ヶ月前に公表することを決めた。
保守派は情報システムで現実的に改元に対応することを全く考えていない。
保守派の現場や時間を無視した強引なやり方で改元を強行すれば、現場担当は情報システムで扱う年号を全て「西暦」に変更せざる得ない。

元々、全てのデータを元号で扱う業務設計自体が間違っているのだ。

「元号」を後世に残したいのなら元号が扱い安いように工夫しろ。
業務手順と運用ルールを見直し、改元がやりやすいように見直すのだ。
これは指導者層の仕事だ。

精神論で強引な圧力かけるだけなら元号は情報システムから消滅する。

もし消えたらそれは保守派の責任だ。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ