銀行システムとクラウド

正直まだクラウドの正体が掴みきれておりません。

だから、私にはクラウド上に銀行のシステムを構築することの危険性がよく分かっておりません。

地銀の銀行システムをクラウド上に構築する計画が進んでいるそうですが、そのシステムを考えている人たちは、クラウドが安全だという結論に至ったのでしょうか?

「どうぜ100%安全なんて、どの世界にもあり得ないものだよ」というのが合言葉になっていないことを祈ります。

銀行のオンラインシステムは、電算センターの所在地もシステム構成やバックアップシステムの方法も、関係者以外には一切漏らされない厳重なセキュリティのもとで管理されてきました。

以前は電話交換局も、戦争になったら真っ先に狙われるということで、住所や所在が隠されてきましたが、最近はなぜか公開されつつあるようです。電話局が重要な通信の拠点ではなくなってきているからでしょうか?

クラウドと言えば、その拡張性、可用性、柔軟性で様々なオンラインシステムで利用されていて、国内だけではなく海外も含めた複数のデータセンターを組み合わせることで、地震や火災などの災害に強いコンピューターインフラを構築できるのは、確かに銀行システムとしても重要なメリットと言えるでしょう。

ただ、住民票や納税の情報でさえ、どこのコンピューターにデータがあって、誰がどのように管理しているのかが問われるのですから、預金データがどこのあるのかも分からない(分かりにくい)クラウド上に存在することに不安を感じる人も多いのではないでしょうか?

しかも、国内には有力なクラウド環境が立ち上がっていないため、自然と最大手のAmazon Work Spaceに乗っ取られる気配があります。

レンタルサーバーやオンラインサービスでもそうですが、業者がやっているサービスにはセキュリティ上の問題以外に、サービスが商品である以上永続性やコストに不確定な要素を含みます。

要するにお金を他人に預けるのですからそれなりに信用がないといけない訳で、官立のクラウド業者が立ち上がるまでは(そんなのが立ち上がる計画があるかどうか知りませんが)銀行のシステムはオンプレミスで稼働させる必要があるのではないかと思います。

総務省の管轄で個人情報を保護するネットワークを担当する部署があるらしいですが、その部署が中心となって銀行システムのクラウド化をサポートすることが必要なのではないかと思います。

銀行システムの構築には時間がななるので、あるところまで進んでしまうと後戻りできません。

「動かないコンピューター」の再来とならないように、注意深く、かつ迅速に事を進めて頂きたいものです。

回数券と通勤手当

いつの間に鉄道会社が回数券を廃止するようになったのでしょう。

以前なら金券ショップや駅前の自動販売機で、解体されたバラ売りの回数券が売られていました。個別回数券の廃止に伴ってバラ売り回数券の販売がなくなったと思ったら、今度は回数券自体が全面的に廃止されるという事態であります。

一斉に開始されなかったため、利用者は鍋の中のゆでガエルのように気づきにくかったのではないでしょうか?

代替方法としてICカード利用でポイント還元が講じられるようですが、使えるICカードが限定されることも多く、使い勝手が良いとはいえません。

徐々に対応するICカードの種類は増えることを期待しますが、回数券の利用自体が減少傾向だったということですから、ポイント還元制度はおまけ程度ということかもしれません。

ICカードで同じ料金区間を一定回数以上乗車すれば、ポイントを還元するということですが、一定回数までの乗車にはポイントがつかないため、実質値上げになるケースが多くなりそうです。

新型コロナ禍以降、全面的で内にせよ在宅勤務が増えているでしょうから、定期券が割高になるケースも増えるでしょうから、その場合は定期券を止める人もいるのではないかと思います。

今後はICカードのサービス向上を、各社競い合うことになるのでしょうか?

ところで、これまで回数券ならば通勤回数で支払金額が決まっているので、通勤手当の計算が可能でしたが、ポイント還元になった場合、そのポイントは差し引いて通勤手当を計算するのでしょうか?

どうもポイント還元の期間は、月初めからの1ヶ月間で区切っている鉄道会社が多いようですが、ゴールデンウィークや年末年始など休日が多い時期では、割引率に影響する微妙な日数計算になることもありそうです。総務担当者泣かせのポイント還元制度になりそうです。

通勤手当の支給は法律で規定されているわけではなく、就業規則で自由に規定できるそうですから、回数券廃止によって通勤手当がどう変わるかは人それぞれでしょう。

まあ、いずれにしてもあまりややこしい計算をする必要がないことを願いたいものです。

アルコール管理アプリ

どうもお正月は(いやその前から)飲酒量が増える傾向がありまして、傾向と対策ではありませんが過度の飲酒を管理するために、スマートホンにアルコール量の管理アプリを入れてみたのです。

Google Playで検索するとあまたのアルコール管理アプリが登場するので、その中の一つをインストールして元旦以降のアルコール取得量を記録しておりました。

最近の研究では、1週間あたり純アルコール質量で140gが健康を維持する限界とされています。これを超えると不健康になる確率が高まるという数値のようです。

一日あたり20gというとアルコール25ml、つまりアルコール度数5%のビール500ml缶に相当します。如何にも取って作ったような数値ですが、ビール業界に忖度した結果でしょうか?

一日アルコール20gというのは、ビール以外のアルコール飲料でも程よい飲み加減で、確かにほろ酔い程度の飲酒なら健康を害することもなさそうです。

飲酒量については、程々に飲んだほうが寿命が伸びるという説もあったり、いやいやアルコールは毒でまったく飲まないのが健康に良いという説もあります。

個人的な見解としては、治療で細胞を殺すときに体内にアルコール注射をすることから、かなり危険な毒であることは間違いなく、ただ肝臓の働きでアルコールを無毒化することができるだけで、体に良いものでないことは確かです。

あとは、アルコールによって気分的なリラックス効果等によって、それ以上の健康的な効果があるかどうかでしょう。これは人によりけりのところが大きいかも知れません。

さて、スマホアプリですが、アルコール飲酒時に記録して、それがグラフになったり、週や月ごとの集計が自動的にされるのですが、記録するのがなかなか面倒です。

禁酒を励んでやっている人なら、その結果を記録することでモチベーションが上がるでしょうが、たくさん飲みたい人には飲むたびに記録すること自体が苦痛!

タクシーのメーターが上がるのを見ているのと同じ気分です。

しかし、グラフ化すると確かに明瞭に飲酒量が把握できますし、目標の週140gに比べて何%超過しているかが数値化されるので、飲酒量を管理するのにかなり効果的です。

ですから問題は飲酒量を管理したくなくなる気持ちに、どう打ち勝つかです。

まあ、管理しなくても度を過ぎなければ良いのです。どうせ度を過ぎたときは記録できなくなりますから。(証拠を残さずに飲みたいだけ!)

新聞めくり魔

今の時代に通勤電車で新聞を読むというのはどうでしょうか?

人好き好きにやれば良いのですけど、ちょっと気になったのでコメントを。

私が使う通勤電車は、以前より新型コロナ禍で多少空いているでしょうが、それでも自由に腕を伸ばすほどには自由が効きません。

いつも乗る車両のドア近くに、2人の新聞めくり魔(おじさん)がいます。

別に電車で新聞を読むのは自由ですから構いませんが、やたらとページをめくるのはやめてもらいたい。

いやもちろん個人の自由ですけど、今の時代にスマートホンでなく紙製の新聞を読む時点で、かなり曲者であったりするわけです。

それほど自由が効くスペースがあるわけではないのに、ペラペラ、バラバラと新聞のページを捲り続ける、狭い電車の空間で。

めくってじっくり読むならまだしも、ほんの5秒か10秒もしないうちにまたページをめくる。この人は、新聞を読んでいるのではなくてめくっているだけ。

なるほどスマホではなく、紙製の新聞でなければいけない訳だ!

30分ぐらい電車に乗り合わせている間に、数十回ページはめくっています。そんなに新聞にページ数あったっけ?

まあ趣味は人それぞれですから、別にかまわないのですけど、そう頻繁にページをめくられるとこっちが落ち着かないです。

で、そのめくり魔を避けるように次の日に電車の乗る位置を変えたら、そこにはまた別の悪魔が! (うわぁ~!)

今どきのSEO

先日、最近のGoogle AdSenseは設定が難しいという話題を取り上げましたが、その作業をやっている最中に色々インターネットの状況が変化していることに気づきました。(やっと気づいたか、、、)

最初AdSenseを使ったのは2005年頃だったでしょうか。

当時ブログはホームページビルダーがまだ主流だった頃で、Bloggerのような無料ブログシステムがそれに取って代わる勢いで流行り始めていました。

ブログシステムと言えば、当初圧倒的なシェアを取ったのがMovableTypeでした。トレースバック機能を引っ提げてブログの世界であっという間にトップシェを取ってしまいました。

「MovableTypeでなければブログでない」みたいな風潮もあり、無料ブログを卒業してサーバーを借り始めたブロガーは、こぞってMovableTypeを導入したものでした。

サイトのデザインを変えるテンプレートはそれほど豊富でなかったため、cssをいじってサイトの特徴を出す必要がありました。

また当時のSEOで重要だった、他のサイトにリンクを張ってもらうことにも注力したものでした。

さらにSEOには数多くのタグをHTMLで挿入したほうが良いということで、一生懸命手作業で入れたものです。

当時は、本屋に行けばSEOの本がウェブコーナーの一列ぐらい並んでいて、SEOが注目を浴びていましたから、サイトを作ったらすぐにSEO対策をするというのがお決まりでした。

今回、GoogleのAdSenseの設定ドキュメントを見ていると、昔のようなSEOのためだけの対策は姿を消し、コンテンツ重視に様変わりしているのに驚きました。

Googleが検索アルゴリズムを変更する度にウェブ業界が右往左往してきましたが、AIの採用でコンテンツ内容重視に切り替わったのは、オリジナルコンテンツで勝負する人にとっては朗報と言えるでしょう。

いやっ待てよ! 

オリジナルコンテンツと言いながら、AIがせっせとコンテンツを創出するようになったら、そいつらが検索の上位を占めるようになるのか?

う~ん、これはまた難題だ!