光景ワレズANNEX

赤いソファを知ってるか　青いソファを知ってるか

「サマータイム導入はコンピュータシステム的に難あり」の記事のヤバさを業界外の人向けに解説します

この記事が話題でした。

 

blogos.com

 

ブコメを見るとおりわかってる人が読むとトンデモな内容なのですが、IT業界の方以外だとピンとこない部分も多々あると思うので、そんな方のために自分の経験／見聞きしている範囲のシステムをベースにこの記事のおもしろポイントをツラツラと解説します。

 

※プロの方から見たら私の解説にも多少ツッコミどころのある部分はあるかもしれませんが、業界外の方に理解してもらえることを優先しているので飲み込んでください。なるべく業界にしか通じない表現を噛み砕く意識で書きます。

※私は業界歴10〜15年の範囲、いわゆる上流SIerの仕事に従事しています。アプリ開発、要件定義〜設計、あと提案、インフラ構築と運用以外は上から下まで囓ってきてはいます。業界は金融、一般企業、公共も経験しています。 

※サマータイム導入の是非そのものとかアスリートファーストがどうとか放映権がどうとかという話は本記事のスコープ外です。

 

“「サマータイム導入はコンピュータシステム的に難あり」は本当か”のヤバさ

結論から言うと、この記事のヤバさはこんなところにあります。

■この筆者の想定している「システム」と、いまIT業界で日々業務に従事されている皆様の想定している「システム」の規模感に大きな差がある

■この筆者の知識、経験が古く、狭すぎて今のIT業界に当てはまらない

■この筆者はプログラミングとITシステム構築を混同している

■上記の知見に基づいた文章が、個人ブログレベル以上の場で発信されてしまった

 

つまり、筆者の想定＝経験している規模のシステムではサマータイム対応は実現できると思ってしまっていると。井の中の蛙というか、知識のアップデートを怠っているというか、日経SYSTEMS（業界誌）あたりでも定期購読してればまだ実際の業務に従事せずとも理解できるようなことをせずサボっているのは明白ですが、それでITジャーナリストを名乗るのはいくら何でも図々しいと言わざるをえません。

 

以下、本文を引用しながら解説します。

 

 

さて、サマータイムの導入の議論は、繰り返し現れては消えておりますが、その度に「懸念」されるのが、コンピュータシステムについてです。

果たして対応できるのか、社会は混乱しないか。

ハッキリ言って「アホ」と申し上げます。なぜか？ だって私がプログラマーとして社会人になった平成元年から、ずっと議論されていたことだからです。

結論からいえば「大丈夫」。コンピュータシステムを知っていれば、さほど大騒ぎする事ではありません。むしろ、サマータイムを導入する最大の障壁は日本人の習性にあります。

私の結論からいえば「大丈夫？」です。

まず話の前提を置きます。この筆者の考えるサマータイム対応というのは、「全国津々浦々のシステムが、日本標準時を2時間ズラすことに合わせ一斉に2時間ズラすこと」と考えている、と定義します。（違ったらごめん。でも前提置かないと話が進まないので）

ちなみに、ITシステムはそのままで人間の生活だけ2時間ズラせばいいじゃないという案もありますが、人間の生活リズムに合わせて構築されているものが多々ありますので、結果、システムの都合で仕事を始めたり店を開けたりできる時間に制約がでてきたりする可能性があります。

で、まあ確かに対応はできます。所詮はシステムなので。できるけど、真面目に対応するための時間とカネとヒトが莫大に必要です。まずシステムに影響する範囲の特定に規模に応じて時間がかかるということ。時間はそれ次第ですが、少なくともターゲットとして設定されている2020年に全国の企業や公共のシステムが対応するのはまず無理。言い切れる範囲で言っても、私の担当しているシステムは少なくともまず間違いなく無理です。

例えば、ISDNが終了するという話があります。

www.nikkei.com

これは大分前から話がでていて、「2020年には止めるから皆もう使うのやめてね！」ってNTTが言っていたのに「ちょ、もうちょっと、ちょ、マッ、まてよ！」と引き延ばす企業が多々あり、2024年に終了を延ばすという話です。ご家庭の感覚からすれば「ドコモからauに回線移行」くらいの作業ですが、そういうことをするだけでも肥大化したシステムにとっては大変なことなのです（この辺を引き延ばしお願いしてるのは特に銀行・金融系じゃないかと勝手に思います）。このご家庭の感覚でITを語る、というのは、仕組みの理解には良いのですが規模感がマヒってしまうのが玉に瑕です。

カネは影響範囲特定の結果ほぼかからないかもしれないし、莫大にかかるかもしれない。ヒトは同時にあちこちでそれなりの改修が入るとするならば、エンジニアの取り合いになってしまうかもしれませんね。

 

コンピュータ（システムやプログラム）には「時間経過」の概念がありません。命令を受けた瞬間からの経過時間は、秒単位でカウントアップしていくだけで、つまり「その瞬間」しかコンピュータは認識していません。 

 

これは「時間」を語る観点がズレています。

ここでこの方が言っているのはCPUの仕事している時間、例えばRAWデータの写真を現像するだとか動画をエンコーディングして終了するまでとか、そういう感覚ですね。そういうことをITシステムで語っても仕方が無いというか……。

経過の概念が無いというのもちょっと補足しますと見方によっては間違いで、excelでお馴染み、時間などを入力していたセルが突如謎の長い数字になって困ったことがあると思います。これは通称UNIX時間などというやつなのですが、1970年1月1日0時0分0秒を起点とする経過時間を扱う形式です。プログラムやexcelの計算式で使ったりもするように、これを扱っているシステムもあると思われます。絶対時間が必要なのか経過時間が必要なのか、それを決めるのは人間の業務に合わせて作られたシステムによります。

 

もう少し、かみ砕くと、「いま何時？ 3時か、あと2時間仕事しなければ」という発想はなく、命令された時間だけ作業を繰り返しているということです。

 

仕事の定時を意識するコンピューターなんてかえって優秀ではないだろうか(笑)。でもね、

「3時か、あと2時間以内にこの仕事を終えなければ9時の開店に間に合わない！」

とか、

「3時か、あと2時間以内にヨソから来るデータを待ち合わせなければ次の処理ができない！」

とか、そういうことを考えるのが業務システムであり、システム開発です。人間の仕事を人間に置き換わってやるのがシステムなので、人間の営みの基軸のひとつである時間とは切っても切り離せないのは当然です。

 

 

システムがデータを処理する考え方としては大きく分けてオンライン処理とバッチ処理という概念があります。

 

オンライン処理というのはリアルタイムに処理を行うもの、Twitterにツイートしたら即座に世界中から読めるようになる、こういうのを指します。

バッチ処理というのは一括処理のことで、昼間の業務で発生したデータを夜中のうちに反映したり処理したり、ということを大きなシステムでは大抵やっています。

 

業務システムの仕事に従事したことがない人は、世の中の全てのシステムが上記で言うオンライン処理で動いているように何となく捉えているのではないでしょうか。

でも例えば会員登録をしたり会員情報変更をして、その反映が最大2日かかります、みたいに書いてあるサービスを見かけたことはないでしょうか。

これはそのシステムが夜間バッチ処理でシステムのマスターとなるデータベースに反映する、みたいな作りになっているからです。古くからの設計のまま現存するシステムや、大規模な銀行や金融系、一般企業のシステムも大抵はこうした一括処理を夜中に行っています。特に、どの時間が2時間削られるのかわかりませんが、そこに一括処理が被ると悲惨でしょうね。

 

反対に「時間の経過」を確認するプログラミングをすると、秒単位でカウントアップしていく内部時間とは別の、外部時間（時計）を用意しておかなければならず、さらに両者を絶えず確認しなければならないので、二度手間三度手間になってしまいます。 

だから、どこかの瞬間、サマータイムにより2時間ないし、何時間と時間がずれても、そのまま処理するだけで影響は軽微です。目覚まし時計の時間がずれたら直すように「サマータイム」となったとき、コンピュータの時計を合わせ直せば良いだけのことです。

ホストコンピュータなどと接続していて、連続した情報をやりとりしているシステムなら、バチっと電源を落として、その後の立ち上げで日時の変更をすればよいだけのこと。

 

ここはバチッと電源を落とすという「テレビは叩けば直る」レベルの強いワードが出てそこに目を奪われ、カウントアップ云々が結局何が言いたいのかよくわからないです。

 

で、そもそも論として「時間がまき戻る（進む）と何がヤバイのか」ですが、ひと言で言うと「影響範囲が不明すぎてヤバイかわからないからヤバイ」ということです。影響を調べるのも無料でもないし10分でできるものではないんです。

 

例えば、一連の時間軸である前提のデータでインプットされないと処理がエラー停止してしまうシステムはこれで死にます。結果的に大丈夫なシステムもあると思いますが、自分たちで担当している範疇のシステムはそうでも、他社範疇のシステムに送るデータもそういうので問題ないかはわからないのです。そういうのはひとつひとつ確認を取っていく必要があります。  

 

なお、大抵のサーバーはバチッと電源が落ちないように工夫されており、電源系統の二重化はもちろん、UPS（電池みたいなやつ）の導入、設置データセンターの自家発電装置、など考慮済みのうえ、そもそもですがバチッと落とさなくても時間は変える気になれば変えられます。 てか時刻なんで電源落とす発想なんだろう。

 

 

なお、日時の変更はすべてのコンピュータシステムでできます。仮にできないコンピュータがあれば欠陥品と断言できます。なぜなら、内部時間を刻むクォーツには誤差があり、これを絶えず修正しなければなりません。

 

最新のシステムではネットを介した日時の自動修正や、電波時計を用いた萬年単位で狂いのないシステムを構築することもできますが、それでも、日付またぎ、年またぎ、うるう日のチェックなどのために、「日付を設定する機能」というのは必ず必要となるからです。

 

そりゃ補正はできるよ、補正は。皆が言っているのは「機能としてできない」ではなく「業務システムとして2時間を一度に一斉にズラせない」なのに……。

 

説明しますと、

時刻同期で時間を合わせに行く場合は、ミリ秒単位で徐々に近づけていく処理が一般的にされます（設定による）。これもシステム影響を最小限にする工夫。大幅にズレているものを合わせに行く場合はそもそも時刻同期自体をエラーにさせるシステムもあります。多分、いきなり2時間の補正を促すコマンドは影響予防のため通らないシステムも結構あるのではないかと。少なくとも私の知ってるあるシステムでは通りません。

 

あと通常、ほぼ全てのシステムやネットワーク機器などはタイムサーバ（日本標準時を取ってきて配布する専用のサーバ）を設置して、そこから時刻を取得して日本標準時に内部時計を合わせています（パソコンやスマホもね）。スタンドアロン環境などの都合で時刻取得できない場合は、CPUの性質によりますが1日数分単位で時間がズレていきます。ただそのコンピューター単体の内部の時間というのはそこまで重要な話ではなくて、24時間365日の連なる流れの中で、突如の断絶や巻き戻りがあることを皆問題視してるのです。

 

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。

なお、西暦の下二桁が0になる年にうるう日はありません。一方、400で割り切れる年はうるう日になります。つまり、2000年2月29日は、400年に1回訪れるうるう日でしたが、その400年に1回に対応するように、私が従事ししていたコンビニのPOSシステムは設計されていました。たしか昭和の終わり頃には。

つまり、日時変更できないコンピュータは、これらの処理を確認していない欠陥品だということです。

日時は変更できるでしょう。繰り返すけど皆が言っているのは「機能としてできない」ではなく「業務システムとして2時間を一度に一斉にズラせない」なのに……。

 

 

サマータイムは日付変更すればすむ話し。一方で24時間、365日絶えず稼働しなければならないコンピュータで、日付を変更するわずかな時間すら許されない場合はどうするか。

先のコンビニのPOSシステムでさえ、サマータイムにはいつでも対応できるように設計されていました。平成元年の時点なので、いまから30年近く前のことです。海外の事例を参考に、変更開始日時と、その変更時間の幅と、終了時刻を処理する仕組みが考えられていたのです。実際に店舗に配備されたレジに、その機能は搭載していませんでしたが、ゴーサインがあれば、瞬時に対応できるようにしていたのです。

このへんに論点のズレがあるわけですね。つまり、この人は閉じた世界のシステム（ここではあるコンビニのPOSのみ）しかアタマにないのです。それなら確かにそのPOSシステムは時間を変更できる。でもそのコンビニだけ変えたからって何？って話です。あと今はコンビニから各業界へのインターフェースもかなり多いので対向側の確認とテスト大変ですね。

 

あと、海外の業務パッケージソフトウェアを買ってくるとサマータイム処理は確かに組み込まれています。が、当たり前ですがそれは使わない前提でカスタムしてシステムとして構築されています。最近は無いかもしれませんがむしろ構築時の不具合の要因だったりするケースもあったと聞いたこともあります（サマータイム発動を想定し忘れて発動してしまって色々処理コケた、みたいな）。

 

プログラミングとは、その時点において考え得るすべてを洗い出し、対応できることは対応し、将来、予想されることに備えておくものです。

いいですね。高い理想です。でも後ろのほうで

イレギュラーはイレギュラーとしてあきらめるのもプログラミングにおける基本なのですが、

と言ってますが。（まさか、if... elseのことじゃないよね……）

まあ真面目に、仕様に無い機能を勝手に付けたら怒られます。

 

 

コンピュータの内部は西暦で処理されていますが、元号表記が必要な場合、「1989年1月8日からは平成」と変換しているだけのことです。それが次は「2019年5月1日からは○○」と新元号の処理を一行加えるだけです。

さらにこれらの制御は「フラグ」によって行います。あるフラグが立っていれば元号処理、または「新元号」を含んだ処理をさせ、そうでなければ通常処理という具合です。

サマータイムも同じく、「サマータイム」のフラグが立っていれば、サマータイムの開始日時を参照し、その切り換え日ならば、必要な時間調整をするというだけのもの。プログラミング初心者でもできる程度の処理です。

この辺も単一のプログラムの処理しかアタマにないですね。ここでサマータイムに難色を示しているIT業界の各位が、if文イッコ追加するのが面倒でそう言ってると思ったのでしょうか。それが全国津々浦々のシステム内のプログラムに渡り、そしてその相互の関係性をテストするとしたら？というところまで想像が及んでいないようです。

 

 

 

 

先に述べたように、時間のずれた目覚まし時計を合わせるように「日付時刻の変更」をすれば済むだけの話。仮に政府案のとおり、東京五輪までの2年間限定ならば、システム改修など不要で、サマータイム開始日と終了日の年2回×2年の4回だけ「人力対応」すれば済む話。

これは「費用対効果」の話しです。システム改修に数千万円も掛けるなら、そこだけ「手間」をかけるほうが安上がりで合理的なのですが、こう考える日本人は少なくありません。

「コンピュータに任せているのだからコンピュータにやらせるべきだ」と、「自動処理」を望む日本人が少なくありません。筋が通っているようですが実は珍説。コンピューターは道具に過ぎず、それをつかって人間がどう楽するかがポイントなのに、コンピュータだけで完結させるために人間が右往左往するのです。

ここの文章でわかるのは、ITシステムを自分ちのパソコンの感覚で語っているということです。

業務システムというのはつまるところ、入力、処理、出力（Input/Process/Output）しかしていません。しかしそれらが多岐の業務、多岐のシステム、多岐の会社間にわたって絡み合っています。その絡みのひとつの基軸になるのが時間なのです。それをいじくることがどれほどの影響を与えるのか、パッと思いつく範疇でもアレコレでるのでこれだけ業界の人は否定しているのです。「いっせーの、はい！」で簡単に切り替えられるなら既にこれだけの否定論は出ません。10分の業務停止時間を作るために半年前から調整を始めたり、システム障害による数分の停止で監督官庁への報告になるようなクリティカルなシステムはザラにあります。

 

あと、人力対応というか運用対応は、特にエンドユーザー向けにサービスを提供するスピード感重視の会社では割と普通に取られる手段です。ある新サービス開始、でもシステムが追いつかない間は手作業、とか全然あります。新サービス開始して数ヶ月は無料キャンペーン！みたいのも、実は単純にシステム化が追いついてないだけで金を取りたくても取れないみたいな裏事情もある場合もあります。

 

 

また、サマータイムの変動幅が2時間とすると、初日の一日は22時間となり、終了日は26時間となります。この時の売り上げの扱いはどうするのか、また「日給」はどうするのか、そしてこの処理をコンピュータにさせるにはどうすべきか、とまぁ馬鹿馬鹿しい議論が、プログラミングの前に行われます。 

これを「仕様」と呼ぶのですが、主に発注者の「希望」が盛り込まれるもので、この発注者がコンピュータを理解していないことが多く、無理難題が盛り込まれることも多々アリ、これが日本のIT化を遠ざけている大きな要因となっています。

イレギュラーはイレギュラーとしてあきらめるのもプログラミングにおける基本なのですが、無知な人ほどコンピュータに「完璧」を求め、完璧を求める日本人の性向がこれに拍車を掛け自体を悪化させます。

ここではその年に2回のイレギュラーを「運用でカバー」「手作業でカバー」などで済むようであれば、コスト、準備期間、業務影響、その他パターンの案も含めて議論するのがシステム屋の仕事です。確かにシステムを理解していない人は、（いま「AI」という単語がそうであるように）よくわからんが何でもできる！何でもなれる！とHUGっとプリキュア的に捉えがちですが、それってまさに今この人がそっち側になっちゃってるっていうのがイソップ寓話っぽいですね。まあ筆者の方が所長である東京ホームページセンター様におかれましては丸投げで好きなようにやらせてもらってるようなのでその感覚なのでしょう。

 

 

東京ホームページセンター – ホームページの相談は東京ホームページセンターまで。TEL.03-3898-9128

f:id:akasofa:20180810225902j:plain

 

 

 

ここまで来て感じたと思うのですが、2時間早める／遅らせることにシステム目線で言うと「そうとうシンドい割に、得るものが皆無」なことはなんとなく伝わったと思います。それならば、時刻をそのままにしておいて、JRの正月の終夜運転とか、お店の0時初売りとかみたいなイレギュラー対応の仕掛け自体をどこまで活用できるかを考えたほうがずっと現実的です。社会がレギュラーな状態でない時点でそれはサマータイムが目指したかったモノとは言えませんけどね。

まあコンピューターシステムで仕事が回るようになった数十年前以前からこれがある前提でシステムが組まれていたか否か、というのは相当なハードルの違いがあるわけです。

積み木の家の土台部分の木を入れ替えるような話なので、スッとうまく抜いて差し替えることができるかもしれないし、どこかで歪みがでて崩壊するかもしれない、としか今は言えないのです。

 

 

おまけ

 

 

 

 

 

（おわり）

Â