列車ダイヤについて -- 3-23 コロナ禍と生活 ーー その二
2020年10月05日
3-23 コロナ禍と生活 ーー その二
3-22 コロナ禍と生活 ーー その一からの続きです。
ITリテラシーの向上には、SNSを使っているタレントの人など、影響力のある人が、自身の使い方を
積極的に発言するのもひとつの方法だと思います。必ずしもIT技術に期待しているのではなくて、
フォロワーの数が多い人しか感じ取れない、SNSの実情を語って欲しいと思うからです。
タレントの人で、新型コロナウイルスに感染し、自分の状況を自分の言葉で発信した人がいました。
非常に役にたちました。
接触確認アプリ「COCOA」が、6月19日にリリースされた後で、新型コロナウイルスに感染したタレントの人
も居たのですが、COCOAから、どのような通知が来たという発言は、今のところ聞いていません。
積極的に導入して欲しいと思います。
もちろん、フォロワーが誰もいない、一般人（筆者のような人です）、あるいは、
携帯を使わない、家に黒電話と糸電話しかないという人の
発言も貴重です。
SNSに関して、聞いてみたいのは次のような事です。
一般人の何人かには聞いてみましたが、ほとんど相手にされませんでした。
１）大坂 なおみ選手が、BLMについての発言を、Twitterの文字数制限を回避するため、
スクショ（Screen Shot)でTwitterに投稿しました。それなら、基本的に文字数制限がない、
FB（Facebook)に投稿すれば良いと思いますが、Twitterに投稿することに意味があるのでしょうか？
（つっこみどころは、そこではないというような反応でした。）
２）TV、ラジオの番組で、”ハッシュタグ「#（半角のシャープ）」をつけてつぶやいてください”
というのをよく聞きます。本日のテーマのメールを受け取る、あるいは、TwitterのIDを決めて、reply
を受ければ良いと思いますが、どのような人にどのような情報が拡散するのを期待しているのでしょうか？
情報を受け逃すリスクはあると思いますが、問題ないのでしょうか？
およそ１０年ほど前、Twitterのデーター保持の方法が、
MySQLから、キー・バリューストア型のCassandraに変更になったというのは有名な話ですが、
ほとんど使っていないので、ほとんどなにも感じていません。
多くのECサイトは、row型のRDBを使用しています。東京証券取引所は、MySQLではありませんが、
row型のRDBを使用していました。以前マルチバリュー型データベースを開発するという話題が、
あったので、現在の正式な構成は知りません。有名なERPのSAP HANA はcolumn型の
DBを使用しています。アプリを利用していて、直感でデーターの保持方法の違いを感じる
ことがあるのでしょうか？
３）GIGA難民という言葉を聞くことがあります。
もし、鉄道の駅や、列車のなかで、高速フリーWiFiが使えるなら、
鉄道通学にしようかというほどのインパクトなのでしょうか？
GIGAは常に余っている筆者には感覚がわかりません。
４）TikTokの動画が、１５秒または、６０秒なのに対し、TV CM （地デジ１５秒、BS６０秒）と
共通する感覚があるのでしょうか？（無いという反応でした。）
バイトダンス社は、ニュースアプリ「今日頭条（Toutiao）」で有名な会社です。
TikTokの動画が１５秒という話を聞いた時、動画から投稿者の関心項目などを引き出す
AIが処理できるデーターの量が、１５秒なのかと思いました。（何の根拠もありません）
５）使用するSNSのサーバーを、米国や中国の会社が管理している、
政府共通プラットフォーム」に「AWS」が採用されることに、情報漏えいのリスクを感じないのでしょうか？
６）SNSの情報を誰が閲覧しているのかというプライバシーの設定がよく理解できません。直感で理解できるのでしょうか？
誰が見ても良いと思う情報は、HP（ブログスタイル）にあげる。
特定の人に送りたい情報は、メールで送るのパターンを今も基本的に維持しています。
Android携帯を持っている人は、gmailのIDを持っています。持っていないと端末を初期化できません。
gmailは、シンプルなIDでも、見たくないメールは別のフォルダーにAIが分類してくれるので、
必要と思う少数のメールだけが、受信フォルダーに届きます。
メールで情報交換というと、寿限無のように長い携帯メールIDを教えてくれる人がいます。
i-モードのプッシュ型メールは、２０年前には画期的でした。しかし、現在は存在価値が
理解できません。（筆者の個人的な感覚です。）もし廃止すれば、携帯料金が下がるのなら、
廃止してほしいと思います。（これも筆者の個人的な感覚です。）LINEやSMS、日本のプロバイダーのPCメールにも
時々希望しない情報が届きますが、gmailは今のところセーフです。
もちろん、日本にgmail iCloud Eメール を上回るメールサーバーがあれば、そちらを使います。
SNSの裏アカ（裏アカウント）を持つという発想も理解できません。合理的な使用方法もあるのでしょうが、
悪口を含む、本音を書き込むために持つという人がいます。なぜ海外のSNSの管理者が情報を悪用しないと信用
できるのでしょうか。どうしても悪口あるいは、自分では正しいと信じる暴露情報を保持したいとしたら、
オンプレ(on-premises)で保持します。情報を共有する必要があるのなら、
個人的に、人間が信用できる、情報漏えいと情報喪失を防ぐ技術を持っていると信用できる人の
オンプレ(on-premises)のサーバーにのみ情報を書き込みます。もちろん情報の可用性では、
クラウドのほうが明らかにすぐれているので、クラウドのサーバーも候補としては考えています。
さらにもうひとつ、気象予報士の方に、ITシステムの利用について、積極的に発言して欲しいと思います。
台風の進路予想について、参考としていくつかのルートが表示されることがあります。
これは、ナビエ–ストークス方程式をFEM（有限要素法）で解く時、誤差が発生するので、
いろいろな解き方をしてみた結果だと勝手に思っていました。
しかし、ある時、気象予報士の方が、いろいろな初期条件を与えて、偏微分方程式を解いてみます
とおっしゃいました。目から鱗という感じでした。それとともに現在の様子が、詳細に正確に観測できるならば、
台風の進路はもっと正確に予測できるのかという疑問が生じました。
ナビエ–ストークス方程式は、カルマンフィルターでいうところの、 フィルタリングとスムージングのように、
時間を逆向きに解くことに意味があるのかどうかはまったく見当がつきませんが、
台風が通過してから、１週間後位に、進路予測がどれほど当たったのか、外れたのか、その理由は何だったのか
というような解説をしていただきたいと思います。
ITシステムでは、すぐれた物が広まるのではない、広まったものが改良されて良いものになるという特徴があります。
台湾の"デジタル大臣"オードリー・タンさんが、
”まだ鳴らせる鐘を打ち鳴らせ
完璧な捧げ物なんて忘れてしまえ
すべてのものはひび割れている"
とおっしゃるのと同じ発想かもしれません。
日本人が、失敗しないようにしようとするのが、悪い方向に働いているかもしれません。
天気予報にしても、８５％より、９５％はすごく良いです。しかし、その時、はずれることもある。
まだ５％改善の可能性があるという発想も必要になります。
まあ適当でよい、とりあえず結果を振り返ってみるという発想も貴重です。
完全をめざすかわりに、失敗したら隠蔽するというのではなく、
結果がわかってから、楽しんで振り返ってみるという発想も必要です。
そして、ITシステムにもっとパワーが必要だと誰もが感じるなら、もっと良いスパーコンピューターが
必要だと、多くの人が思うということです。
導入前に、一位じゃないとダメですか？といっても所詮よくわからないので、
日常的な活動のなかで、コンピューターの処理結果を皆がみて、一位じゃないとダメか、どうでも良いかを
判断すれば良いと思います。
さらにもうひとつ、気象予報士の方には、
”Weather never stops" の観点からも、ITシステムの利用について、積極的に発言して欲しいと思います。
最近東京証券取引所のシステムが、丸一日取引を停止しました。
あくまで筆者の個人的な感想ですが、午前９時の時点で、丸一日運用を止めるという判断をした、
運用担当者は非常に優秀だと思います。
もし、期待した値段で株を買うことができなかったとか、振り込んだお金がどこかにいったという
ようなことが起きれば、翌日の運用も危うくなります。個人のPCのように運用中に
簡単にリブートできるわけではありません。午後から運用するというような、
一度もやったことのないことをすれば、失敗のリスクが高いです。
新幹線の運行管理システムの場合は、そういかない事情があります。
明日は正常に運行します。今日新幹線に閉じ込められている人は、運が悪かったと思ってください。では
満足しない人も居ます。いろいろな事情で、正常稼働できないシステムのほうが、
運用も含めて、異常時の耐性が高いシステムということもできます。
新幹線の場合、地震など線路の安全が確認できない場合、安全な場所を選んで停車します。
その場合、新幹線に閉じ込められている人は、運が悪かったと思ってあきらめるしかありません。
航空機の場合、燃料がなくなる前に着陸させる必要がありますから、
航空管制のシステムは止めないようにします。
バックアップの装置に切り替わらなかったとか、RAIDが全部壊れたというのは、
よくあることです、（決して良いことではありません。）
新幹線の運行管理システム（COMTRAC)の場合は、年に一回、大阪のバックアップの
運行管理システムで運用して、日頃から訓練しています。
arrowheadの場合も、電気設備の安全点検の日は止めなければいけませんが、
もともと土曜日・休日は止めるシステムなので、
丸ごと、別のサイトのシステムで運用することは考えてないようです。
新幹線の運行管理システムの場合、回送列車も含めて、０時３０分頃には運転が終了します。
そのあと、当日の実施ダイヤの設定をしますが、その場で考えるわけではなく、
事前に決まっていたものを入力するだけなので、２時頃には作業が終了します。
実施ダイヤは、例えば午前５時に自動で登録されますから、
２時ごろから、４時半頃までは、システムを止めて、メジャーアップデートを適用することができます。
前日に降雪があって、ダイヤが大幅に乱れたなど、特殊な事情が無い限り、システムを止められる
蓋然性は高いと言えます。もちろん、メジャーアップデートを適用したら、ブートできなくなった
というのも、よくあることです、（決して良いことではありません。）
arrowheadの場合、公表されているメジャーアップデートからは１年近く経っていますから、
今回の件とは無関係だと思います。
気象予報システムの場合、夜間、集中豪雨が来ることもあるので、皆が２４時間運用を
当然のこととして期待します。
運用が困難なシステムという見方もできますが、異常時の情報が多く集まるシステム、
すなわち異常時に対する耐性が高いシステムを構築するための情報が多く集まる
システムということもできます。
ぜひ、気象予報士の方には、 ”Weather never stops" の観点から、ITシステムの利用について、
過去には思ったような運用ができなかったという失敗例も含めて積極的に発言して欲しいと思います。
さらにもうひとつ、本当にこれが最後です。
ここまで読んでいただいて、不満が多い方もいらっしゃると思います。
ひとつには文章がつたないということもあるでしょう。
それとあわせて、このサイトが HTTPS（Hypertext Transfer Protocol Secure）でないことに
不満をもっておられる方もあるでしょう。
ブログがさかんだったころに、インターネットサービスプロバイダーの無料のHPサイトでこのHPを開設しました。
そしてそのままになっています。情報をアップデートする際にも
SFTP（Secure File Transfer Protocol）が使えないため、専用のソフトを使っています。
もちろんお金を払って、専用のドメインを取得すれば解決するのですが、
無料で使いはじめたものに、お金を払いたくない、
日本のITメーカも当然サービスを向上するべきだ、情報を表示するだけで、情報を入力するトランザクションがないので、
大丈夫、情報の改ざんに責任をもつのは、プロバイダーの側だ、
radikoのサイトも、HTTPだから、そもそもそれほど危ないものではない。
など勝手な理屈をつけて、今も使い続けています。
自分が行うことには、自画自賛が激しく、
他人が行うことには、どうしても細かなことだけが気になって、肝心なことが気にならないのが
ボクの悪いクセかもしれません。