皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

いよいよ今年も残りわずかとなり、このブログへの投稿も年内は最後となります。

そこで、今日は2019年を振り返ってみたいと思います。

2019年の投稿記事を振り返る

今年は何と言っても『改元』でしょう。

2019年5月1日から『令和』がスタートし、Windowsのみならず、各システムの『改元対応』が間に合うのか懸念されたところもあったことでしょう。

日本である以上、『元号』にこだわりたい気持ちもわからなくはないですが、やはり今後は西暦で管理する方が負担が少なくて良いと思います。

改元で”Y2K”問題発生の可能性

次に、『〇〇Pay』という『モバイル決済サービス』が乱立する中、リリース早々に問題が起き、撤退することにまでなってしまった『7Pay』の乗っ取り不正利用問題が印象深いです。

7payで早くも乗っ取り不正利用

その他、『Thunderbird 64bit版』が正式に公開されたことや、iOS 13のリリースとともに登場した『Sign in with Apple』、VPNサービス『1.1.1.1 with WARP』の登場などもインパクトのあるものでした。

Thunderbird68.1で待望の64

Sign in with Appleは秘匿する

1.1.1.1 with WARP はじまる

さらには、何度かお伝えしてきた『Windows 7』のサポート終了に関して、当初はボリュームライセンス向けの延長だけであったものが中小企業向けに配慮をする措置が取られることも現状を大きく表しているような気がします。

Windows 7延長 中小企業にも

直近では、『Microsoft 365』において大規模な障害が発生したことや、Apple製品の『use-after-free』の脆弱性、『EC-CUBE』における『クレジットカード流出』もありました。

Microsoft 365 大規模障害発生

Apple製品 対策不可能な脆弱性

EC-CUBE2系でクレカ流出被害

※　過去の記事へのリンクは一部のみ記載しています。

他にも是非再読いただきたい記事はたくさんありますが、全体の中からピックアップして振り返ってみました。

最後に、今年もこのブログにお付き合いいただきましてありがとうございました。

たまに事業者向けなのか？という記事もなくはないですが、そこは従業員の方へ事業者からアナウンスしていただきたいという意味もあって投稿しております。

来年も事業者に役立つ記事の投稿を心がけて参りますので、どうぞよろしくお願い申し上げます。

年明けは2019年1月6日（月）から投稿を予定しております。

どうぞ良いお年をお迎えくださいませ。

さて、現在のWindowsの状態は？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

いよいよ来週、新元号『令和』がスタートします。

そんな中、少々気になる部分も残っています。

それは？

Windows の令和対応は間に合うのか？

今日は2019年4月25日ですが、今朝『Windows』の日付と時刻を『和暦』で確認してみると5月1日以降も『平成』のまま。

？？？

これ、未だ新元号『令和』に対応したパッチ（更新プログラム）が間に合っていない状態なのです。

日本マイクロソフトによると、『本国（米国）の技術チームが準備を進めているものの配信時期が確定していない。』とされているようで、このGW（ゴールデンウイーク）前までには間に合わない可能性もあるとのこと。

配信される予定のパッチ（更新プログラム）は新元号の『令和』に対応し、2019年4月30日までは『平成31年』、2019年5月1日以降は『令和元年』と認識させるもので、IME（かな漢字変換機能における『令和』の変換、令和を全角1文字で表す『合字』の追加も予定されています。

これが間に合わないとなるとどうなるのか？

Windows上で動作するシステムにおいて『改元』に伴う誤動作が発生する可能性があります。

今後の課題として、

１．システム上で改元用の予備項目を設けておく

２．西暦のみで対応していく

といったことが必要かもしれませんね。

これにより、19年強前の2000年を迎えるにあたり、2000年になった際の下二桁『00年』が1900年の下二桁『00年』に誤認識されてしまうという『2000年問題』がありました。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

来週、2019年4月1日の正午前あたりには新元号が発表となり、翌月の2019年5月1日からは実際に新元号がスタートします。

それに関連し、Microsoft（マイクロソフト）が『日本版の”Y2K”問題が発生するおそれがある』と警告しています。

改元による”Y2K”問題発生の可能性

今回Microsoft（マイクロソフト）が警告している『日本版”Y2K”問題』というのは日本独自の問題で、日本におけるコンピュータシステムの多くに『元号』が使われていることに起因します。

現時点では新元号は発表されていないわけですから、新元号対応としてのシステム改修などを進めていたとしても完成には至っていないのは致し方ありません。

（ほぼ終わっているところは新元号を埋めるだけになっているのかと。）

そして、改元に伴う新元号への対応を進めているところであれば問題はないですが、この対応が全くされていなかったり、元号が使われている部分があるのかどうかすら不明であるところにおいては問題です。

ある調査によると、システム内で元号が使用されているかどうかの調査が完了すらしていない企業が約20%あったようで、これが実際の改元までに間に合わなければ日付の認識が行えず、処理上に不具合が生じる可能性があることをMicrosoftは警告しています。

比較的最近のシステムを使われている企業は大丈夫かと思われますが、未調査や未対応の事業者の方、何とか乗り切って下さい。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

2019年5月1日、新天皇即位に伴う改元が行われることはご存知かと思いますが、それに関連し、ソフトウェアの和暦情報に関しても影響が出るため、日本マイクロソフトは新元号対応への取り組みを公開しています。

日本マイクロソフトが公開した新元号対応

日本マイクロソフトは、改元への対応策として以下のような対策を公開しています。

＜Windows＞

・和暦がハードコードされたモジュールを修正しレジストリで管理

・日付フォーマット変更（例:平成02年（成と0の間に半角スペース） → 平成2年）

・元年表記をデフォルトに変更（1年表記にも変更可能）

＜.NET Framework＞

・.NET Framework 3.5 でも元号情報をレジストリから取得し新元号に対応できるよう変更

・平成32年等の許容可否をデフォルトではWindowsレジストリで判断するよう変更

・元年表記をデフォルトに変更（1年表記にも変更可能）

＜Office＞

・日付挿入機能や日付計算機能などの新元号対応

そして、新元号対応に際して『考慮が必要な項目の例』もあげています。

＜考慮が必要な項目の例＞

・日付フォーマット変換（例:平成31年10月1日を許容するか否か）

・新元号を一文字で記した合字（例:㍽ ㍼ ㍻）の追加（新フォントの展開、新合字の文字コード、正規化のルール（例:平成は㍻と同じ）など）

・合字を含めた元号の並べ替えロジックの見直し

・元年という表記とそのデータが及ぼす影響

また、ユーザーへの推奨事項として、新元号公表前後において以下の準備などを推奨しています。

＜新元号公表前の準備＞

１．システムが破損していないかどうかの確認

２．Windows 向け更新プログラムのインストール

＜新元号公表後の対応＞

・マイクロソフトが毎月提供する更新プログラムを適用する

さらに、経済産業省主催で『改元に伴う情報システム改修等への対応についての全国説明会』も既に実施されており、日本マイクロソフトからは以下の資料が配布されています。

『全国説明会における日本マイクロソフト株式会社からの配布資料』

（※　経済産業省のサイト内になります。）

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

2019年5月1日、元号は現在の平成から新元号へと変わります。

それに伴い問題となるのがシステムの元号対応。

さて、この先もこの元号対応を続けていくのでしょうか？

システム日付は西暦で管理すべき

お客様専用で構築したシステムにおいては特別指定がない限り元号対応を盛り込むことはあまり見かけない話しですが、これが業務系のパッケージシステムとなると少々違います。

業務系のパッケージシステムにおいては元号か西暦を選択できるようになっているものが多く、改元の際には新元号対応されたプログラムへのバージョンアップが必要になる場合があります。

普段から西暦を選択して使っている事業者にとっては無視して良い話しにはなりますが、元号での表記を使われているところにおいてはパッケージメーカーの対応待ちという状態が発生します。

今回の場合は改元の日付が決まっているものの、今後も同じようになるとは限らず、かつ、元号が発表されるのは改元直前です。

こういった状況にならないようにするには、システム日付はすべて西暦で管理していくことが無難と言えるでしょう。

有償で元号対応をしているパッケージメーカーなどにおいてはもったいない話しかもしれませんが、全体的なことを考えるとその方が得策と思えます。

そうでないのであればユーザー側でメンテナンス可能なものとして提供することが一番良い方法かもしれません。

現在、元号で帳票類を出力している事業者の方、この先は西暦で出力していくことを検討された方が良いかもしれません。

過去に出力したものと見た目が少々変わることで統一感のなさを感じる部分もありますが、どこかで切り替えてしまった方が気にすることが一つ減ることにもなります。