コストカット

エポキシ系接着剤がダイソーで販売されている。
最初に購入したときは、両液あわせて20gだったが、16gに減った。
だが、最近見てみると再び20gに戻っていた。
円安でほとんどの原材料は高くなっているので、更に重量は減ると思っていたので驚いた。
同じように、日本製両面テープも長さが9mから10mに増えていた。
事実上の値下げだ。
もちろん、値上がりしているものもあるだろう。
継続的に百均で購入しているものはそれほど無いので何が値上がりして、何が値下がりしたのかよくわからないが、値下がり要因の無い中でどうやって同じ価格で重量なり、長さなりを増やすことができたのか。
簡単に企業努力と言ってしまうのはつまらない。
本当ならダイソーに質問したいくらいだ。
もしかして、海外での人件費が上がり、日本で作ったほうが安くなるなんてことが起きている可能性も否めない。

盛岡市のガバクラ移行

ガバクラ移行でコスト倍増の記事と同日に別のメルマガで盛岡市のシステムのガバクラ移行についての記事が届いた。
コスト倍増の記事は日経クロステック。
gmailに対するメルマガ送信の記事を書きながら、自分達は対策できていないメルマガを発行しているところだ。
一方、盛岡市のケースのメルマガはアイティメディアのメルマガ。
残念ながらこちらのメルマガはdmarcはおろか、dkimもspfも認証されていないものを配信している。
この記事の中では、盛岡市の担当者とシステム開発の業者の双方のコメントが載っていた。
移行先ターゲットはaws。
リソースとデータ転送量を適切に見積り、リソースの最適化をはかることで、既存システムをまるっとawsに移行したようだ。
元のシステムはオンプレミスで運用していたそうなので、行政側の担当者もシステム開発業者もサーバに対しては正しい知識を持っていて、クラウド運用での過剰なリソースは持たないことがコストダウンのポイントだということを押さえていたと推測できる。
クラウドは海外の運用元を採用すると、為替リスクを気にする必要がある。
円安に振れると、1gbの転送が0.1ドルだったとしても、実際に支払うべき金額は円換算では1.5倍になったりすることもある。
そもそも、自治体の支払い用の資産が円だけで準備されていること自体が海外クラウドを採用する時点で大問題だ。
自治体独自で管理しなくても、例えば2年間の予算としてドル建てで支払うべきお金を準備しておくなどいくらでも手はある。
それとも、今からの日本経済がバブルの頃のように、ジャパン・アズ・ナンバーワンに復活するのだと考えるような頭の中がお花畑の人物だらけなのか。
人口減少に伴い、行政職員、地方議員、国会議員、全てに対して最適な人数を見直さなければいけない。
それとも、議員制度が作られたときよりも日本の人口は多いのだから、まだ議員数は減らす必要が無いと考えているのか?

仮想サーバーでのoracleライセンス料金

oracleのライセンス体系が想像以上にボッタクリ。
というのも、ライセンスはCPUのコア数に対して課金されるとのこと。
そもそも何でこんなライセンス体系なのか。
簡単にマルチプロセスの動作から説明する。
厳密には現実とは異なる例になるが、例えば動画を複数再生する場合、それぞれの処理を行うためにはCPUが動くのだが、CPUの処理性能は高いので、付きっきりでその動画再生のために動くわけではなく、チョコっとその仕事をしたらすぐに別の仕事をしている。
つまり、ひとつのCPUは仕事を複数掛け持ちしている。
これが、マルチプロセス。
では、とても大変な仕事を複数行う必要がある場合はどうか?
同時にこなせるジョブの数は最大でそのマシン上で動作しているCPUのコアの数になる。
oracleに最大のパフォーマンスを期待するなら、全てのコアを同時に実行させることになる。
それが最大性能を引き出すことを前提にしたライセンス体系になっているということだ。
仮想環境では、物理サーバのCPUリソースをそのサーバ上で稼働させるサーバでシェアする。
コストを無視して安全なインフラ設計をするのなら物理サーバのCPUコアが24個なら、仮想サーバーに割り当てるCPUの数の合計は24以下にするだろう。
oracleのライセンスは物理サーバの24コア分で契約しなければいけないが、実際にoracleが稼働する仮想サーバーにCPUコアが8しか割り当てられていなければ、どんなに足掻いてもoracleのベストパフォーマンスとしては物理CPUの8コア分を超えることはない。
なんて理不尽なライセンスだろう。
では実際にoracleはどのくらい、世の中のシステムで使われているのか。
大昔にデータベースが、使われ始めた頃にトランザクション制御が細かく行えるという理由で選ばれたデータベースというイメージしかない。
安全がお金を払って買えるのならばと、oracleは様々なシステムに採用された。
そして、独自仕様という囲い込みと製品の使いこなし技術者等級という手段で、IT企業からは高い金を請求できるテクノロジとしてoracle教が普及されて、今に至っている。
実際にはOSSのDBで問題なくシステム構築できるものであっても、高い金を払ってoracle教を信仰し続けるしか無くなっていて、システム構成を変更しづらくなっている。
憐れなクライアント。

英国郵便局のシステム不具合

暴言極論という日経クロステックの記事がある。
筆者は多分元富士通関連での就業経験のある人間。
基本的には、国内最大ベンダーの一つである富士通に対しても辛辣な記事を書いているのだが、英国郵便局の件では富士通を擁護していた。
その理由は、富士通は不具合があることを通知していた。
有罪判決を受けた人達の冤罪は、システムが下した結果ではなく、裁判によって人が犯した過ちであり、全英でこんなに多くの類似した金額の誤りがあったにも関わらず、これが人為的な犯罪によるものだと判定したから冤罪となったというのが、その理由だ。
富士通は不具合を作り込んでしまった道義的責任はあるかも知れないが、冤罪に関してはその責任を負う必要はないというのが、筆者の主張である。
個人的にはこの意見には非常に違和感を感じる。
金額が一致しないという事実だけを捉えれば、同じようなことが全角で発生していたとしても、当事者が疑われるのは当然のことである。
システムの不具合を疑わないほうがおかしいとするのは、それこそ暴言極論だと言わざるを得ない。

富士通が不具合の報告をしていたとするならば、その不具合が引き起こす可能性のある事象をつぶさに報告していたのかという疑問が起きる。
もしも、今回のような事象も不具合が顕在化した場合の例として挙げられていたとすれば、それを見落とした警察や司法による冤罪だと言っても良いだろうが、そうでなければ、やはり富士通が責められるのはやむ無しと思うのだが。

自治体システムのガバクラ移行

メールマガジンに自治体システムをガバクラに移行することで、運用コストが数倍に膨れ上がるという記事が載っていた。
何故そんな事が起きるの?というのが正直な感想なのだが、理由は単純。
自治体ごとにカスタマイズされたシステムが存在しているからだ。
現行の自治体システムは、一体どこで稼働しているのだろうか?
まず、そんな疑問が浮かび上がる。
データセンターと契約してハウジングを占有して運用というのが、よくあるパターンのようだ。
では、ガバクラになるとどうなるのだろうか。
現行稼働しているシステムやデータはそのまま使い続けることが移行トラブルの最大の回避策であることは、誰が考えても明白である。
ガバクラになると、仮想サーバー1台ずつに対して毎月の料金が発生する。
しかも、現在ガバクラ利用先として最も使われているawsでは、サーバーリソースの料金だけでなく、データ転送量に応じてネットワーク使用料が請求される。他のガバクラもそうかも知れない。
つまり、アホみたいにデータ通信を行うと、アホみたいに通信料が請求され、スマホのパケ死と言われる状況になる。
ではどうすればコスト削減になったのか?
答えは簡単。
サーバ台数を減らして、システムの共通化を図ることだ。
クラウドの最大のメリットは、必要な時に必要に応じてリソースを増やしたり減らしたりできることだ。
現在契約していデータセンターがシステム開発も引き受けていたならば、現在のデータセンターで使っているリソースをそのまま使用する契約をガバクラで行った場合の見積りをするだろうし、データ転送量にしても、最悪ケースの見積りを出すことだろう。
運用が始まったら、追加費用の発生は認められないんですよねの一言でワーストケースでの見積もりが許されてしまう。
期末などでリソースパワーが必要な時だけCPUやメモリを増強して、それ以外では最低限のリソース契約にする。
そして、システムで稼働するサービス・プログラムの数をシステムの共通化で削減することが必要になる。
単純にガバクラ移行でコスト削減なんてことをデジタル庁が旗振りするのはおこがましい。
共通化プラットフォームを設計して、システムの共通化を強力に推進して、ガバクラ上にサーバー展開したうえで、移行時にはデータの移行だけを現在契約しているシステム業者に依頼するようにするべきなのだが、システム業者も既得権益を失いたくないから、なんだかんだとバカ高い見積りを出してくるだろうが。
システム業者との契約にデータ構造の情報開示が含まれてさえいれば、データ移行用のシステム開発なんて、そこらの小規模事業者でもできそうだ。
ITに関して無知であるがゆえに過剰な利益を提供し、挙げ句に寡占だと税金をかけようなんてバカなことがまかり通るんだな。

世界の自殺者率

日本の自殺者率は世界6位。
そして、韓国は世界1位。
韓国での自殺者は高齢者が多い。
理由は経済的窮乏。
韓国では年金制度の整備が遅かったことにより、受給額が少なかったり、受け取ることができない高齢者が生活で苦で自殺する人が多いそうだ。
本来、韓国は儒教の国であり親を大切にする国。
子供が老親を扶養することは当然のことであり、老親が少ない年金受給であったとしても、生活に困窮することは無いと考えていたのだろう。
何か、日本との共通点が見えないか。
日本において老齢年金だけで生活することは極めて困難だろう。
蓄えもなく老齢年金だけで生活しようとするならば、生活に必要なもの以外への支出をゼロ、交際費や共助に必要な自治会費用などもゼロにしないと支出が収入を上回る可能性が高くなる。
医療費などは最悪の支出だ。
わずかながらでも収入を得られるかもしれない可能性を病気により無くし、高額な医療費を仮に一時的とはいえ負担しなければいけなくなる。
負担額の上限が設けられていたとしても、老齢年金だけで医療を受けることが現実的ではなくなるかも知れない。
国民健康保険を支払い、医療費を支払い、生活保護というセーフティネットは国民皆低所得層になったとしても機能するのだろうか。
死にたくない老人は軽犯罪で懲役刑を望む。
余生の80%を刑務所で過ごせば、その期間の受給年金で残りの20%を普通に過ごせるという試算が成り立つかも知れない。
老齢年金の平均受給額は56000円。
これは可処分収入ではない。
ここから、保険料が取られる。
ライフラインとして、電気、水道、ガスの支払いは最低基本料金で収まる人がどれだけいるだろう。
食費にかけられる金額は一体いくらだと試算しているのだろうか。
食べられるだけで満足しなければいけない国は文化的に成熟した国と、言えるのだろうか。

日本の自殺者率が世界一になるのはそう遠くないとは考えたくない。

ヤマト運輸

個人事業主のヤマト運輸契約ドライバーが2024年度末までに29000人契約終了となる。
2024年4月からドライバーの労働条件が変更となり、長時間労働ができなくなる。
これが物流の2024年問題と呼ばれていて、ドライバーの不足が深刻になるのかと思っていたが、ヤマト運輸では個人事業主のドライバーとの契約を大量に終了するという。
何故そんなことをするのか。
考えられる理由は、ドライバーが足りているか、扱う物流の総量を減らすかしか思い浮かばない。
確かに、2024年問題により配送料金の大幅な値上げも考えられるから、物流総量が減っても、売上高は変わらないのかも知れない。
では、ヤマト運輸が扱えなくなった物流はどうなるのか。
インターネット販売サイトは、Amazonがそうしたように、物流拠点となる倉庫を全国に多く配置するだろう。
もしかすると、倉庫の運用コストを下げるために楽天とAmazonが共同運用する倉庫も出てくるかも知れない。
最近ではAmazonの配達はAmazonが行って、ヤマト運輸を使うケースも減ってきた。
ヤマト運輸は取り扱い量を減らそうとしているのではなく、すでに減らされてしまっているのかもしれない。

初のアブガルシアのスピニングリール

アブガルシア。
スウェーデンの釣具メーカー。
最初に買ったベイトリールが名機と言われたUC4601。
丸型でキャスト性能に優れると言われるモデルだったが、まともにキャストできることなく、ベイトリールを使いこなすことは無理だと思わせられたモデルだ。
それ以降、アブガルシアの釣り道具として購入したのは、ベイトロッド2本。
最廉価モデルのベイトリールであるBlackmax。
これだけ。
ベイトロッドは2ピースの同じモデルを2本購入しているのだけれど、バット側とディップ側の組み合わせは決まっているというか、元の組み合わせと違うものだと込みが合わない。
ヘラブナ釣りをしていた時、SHIMANOの竿で穂先が魚に持っていかれたとき、釣具店で穂先を注文する際に穂持ち以降も預けていたので、ブランクスは工業製品とはいえ、バラツキが大きいのだろう。
話がずれてしまったが、バイオマスター3000の代替品として、あまり高くなく、剛性があるものを探していた。
候補としては皆がアホみたいに絶賛するDAIWAの23レガリス、20レブロス。
SHIMANOの21ナスキー、22ミラベル、21アルテグラ、23セドナ。
候補たちの価格帯は6000円から12000円となかなか幅がある。
サイズは2500番のシャロースプールモデルでハイギアにも重量にも拘らないが、強度は必要。
なので当然ハンドルはネジ込み式。
できればドラッグはスムーズであってほしい。
満足度を考えると、21アルテグラ一択だし、手持ちのアルテグラはトラブル知らずでこのシリーズへの信頼度も揺らぎない。
引っかかるのは価格だけ。
最近購入しているベイトリールの金額を予算にすれば、21アルテグラは2台買えるのだが、サヨリとアジサビキ釣りにしか使わないのに、巻き性能だのそんなのは要らない。
求めるのはトラブルレスであること。
心地良さはそれほど重要視しない。
リールメーカーとしてみれば、世界的にSHIMANOとDAIWAはワンツーのポジションだろう。
だが、アブのリールはかっこいい。
アンダー10000円のリールを3機種勧めるYouTube動画の中で、ぬこまた釣査団の隊長である大西氏がアブのスーペリアというリールを推していた。
2019年に発表したモデルなので当然最近のものにテクノロジーでは敵わない。
しかも海外製品なのだから、2大巨頭に性能が勝てるわけはない。
だが、調べてみるとこのリール金属のモノコックボディでデザインもかなりいい。
唯一気になるのは、糸よれ。
実は、トラブルレスのアルテグラには今では標準装備である、糸よれ抑止のラインローラーが使われていない。
なので、テンションをかけずにリトリーブしていると、ピョン吉と言われる状態やモモってしまうという最悪最強のトラブルに見舞われる。
糸よれ抑止の考え方はどこのメーカーも同じで、スプールにラインを巻き付けていくベールのラインローラーでラインをねじる方法が取られている。
ここでスムーズにラインをひねるには、ラインローラーがラインに合わせて回転する必要があるらしい。
つまり、ラインローラーの回転性能が高くなければ、ラインローラーの形状が糸をひねるようになっていても、ラインがローラーの上を滑るだけで糸はひねられず、ねじれが蓄積されていく。
アブのスピニングリールのラインローラーの形状も当然糸よれしにくいものになっているはずなので、ここの回転性能を高めることが肝心。
スーペリアはここにプラスチックブッシュが使われているので、ベアリングにすれば回転性能は飛躍的に向上するはず。
というわけで、スーペリアの2500番シャロースプールモデルと適合するベアリングを購入した。
だが、ラインローラーで糸よれは多少は防げるというが、結局縒れる向きと逆のよじれを発生させないとダメ。
市販の糸よれとりは、キャストして巻き取る時にスピニングリールの巻き取り時のスプールと逆に回転するというもの。
YouTubeではトップウォータールアーのペラにおもりを付けたものを使っていた。
流石にこれだと捻れすぎ。
糸よりトレールとかそんな商品名のものは、棒状のシンカー表面にネジみぞみたいなものが切られている。
確かにこれなら、水流を噛みすぎないので適度な逆回転ネジレができそうだ。
こんなのが二本で1000円ほど。
冬場だし、中通しオモリにステンレス線を入れて、それ三本で薄っすらとみぞっぽいものを付けた。
これでも十分に回転するだろう。

Windowsサーバー

Windows2012サーバーがサポート期間を終了した。
どのくらいの数のサーバーがリプレイスすることになるのか分からないが、完全に外部ネットワークから切り離されているからとリプレイスを先伸ばしにしている企業も少なくはないだろう。
サーバーではないが、WindowsはOSが無料ではないので、無料のLinuxを使おうとした自治体がかつてあったが、今ではどうなっているのだろうか。
OSが有償であっても、PCとしてWindowsを使うメリットは十分にある。
まず、使用者が勝手に身につけているスキルを流用できること。
家庭でもバリバリにLinuxのデスクトップを使っている人は少ないというか、日本ではまずいない。
だが、Windowsならば基本的な操作はできるという人は多い。
使い慣れないOSを使わせるよりも普段から使い慣れているOSを使わせる方が圧倒的に作業効率は高い。
第二に、トラブル発生時の対応だ。
例えWindowsであったとしても、さすがに使用者がトラブルに対処することは難しいので、保守契約を結んでいる業者に対応を依頼することになる。
だが、保守対応出来る人員の数がLinuxだと、圧倒的に少なくなるため、業務の停止時間が長くなる可能性が高くなるし、エンジニアの単価も高くなるので、保守料金が高くなる。
こんな理由で職員の端末をLinuxにするのは、経費削減に大きく寄与するかといえばそうでもないのだ。
では、サーバーの世界ではどうだろうか。
WEBサービスの提供が始まった頃は、Windowsサーバーならば、IISの一択で当時主流であったapacheの選択はできなかったと記憶するが、今ではWindowsサーバー上でapacheもnginxも動かすことができる。
nginxを選択する場合、敢えてWindowsサーバーを採用するようなことは考え難い。
結局のところ、今でもIISを使うか、apacheを使うかだろう。
サーバーサービスの開発は大規模である場合が多い。
もちろん、WEBサービスだけチョロチョロっと動かすような場合であれば、PC上に仮想環境で本番用のシステムを構築して開発テストまで行うことができる。
ただし、仮想環境であってもOSのライセンスは必要だし、商用ソフトウェア製品を使うにはそのライセンスが必要になる。
開発用ライセンスを使って開発することはあるだろうが、結局開発環境はそのままテスト環境として運用することがあるため、本番と同じか同等のものを準備することになる。
何度もこのブログでとりあげているが、centosはRHELと全く同じと言って良いディストリビューションなので、テスト環境での使用には最適でしかもOSライセンス料金が不要になる。
リリースタイミングの問題があるじゃないかと考える人もいるだろうが、OSのメジャーアップデートなんて、簡単に行えるものではない。
RHELがリリースされて、centosがアップデートされるまでのタイムラグなど問題にならないほどの、影響調査、更新計画などの準備が必要なのが現状なのだ。
ここまで書くと、WindowsサーバーからRHELに乗り換える企業が多いのでは?と思うかも知れない。
だが、システムには呪縛とも言える制限が存在する。
結局、最初の選択に縛られ続ける。
いつの日か、車を乗り換えるように自由にシステムプラットフォームを選択できる日が来るだろうか。