日次まとめ 2022年06月10日

その他

一般

ゲーム

ガジェット・サービス・ツール等

技術・事業・セキュリティ等

  • アカウント作成前にアカウントを乗っ取る方法が発見される | TECH+
  • りゅうぐう地下物質も採取　検出アミノ酸は２３種類―はやぶさ２成果論文・ＪＡＸＡなど：時事ドットコム
    関連：小惑星「リュウグウ」元の天体に“大量の水”採取サンプル分析 | NHK
  • 新たな形態のLinuxマルウェアが見つかる–検出は「ほぼ不可能」 – ZDNet Japan
  • YouTuberが4chanでAIを訓練して「ヘイトスピーチマシン」を生み出しネットに放流してしまう、AI研究者は困惑と懸念を表明 – GIGAZINE
    思うところはあるけれど、そもそものデータが人間が発信したもので学習されたものなので、そこは皮肉として面白いとは感じます
  • 「BOOK☆WALKER」で不正ログイン発生　パスワード変更、購入履歴確認など呼び掛け – ITmedia NEWS
  • 三重の小中109校、タブレット使用のテストでシステムトラブル | 毎日新聞
    この記事を見る限りでは求めているのはインフラエンジニア系か。

    だとするとITはITでも一般的なイメージであるプログラマーなどとは別枠で、IT系の分野でも人材が少数なんですよねぇ
    (役割的に1つのプロジェクトに何人もいたってしかたないから割合的に少なくなる。かといって需要がなくならない役割だから、会社によっては居るところには居るけど居ないところには居ないという人材の確保の面でもバランスが悪い。いくつも掛け持ちさせられたり、一般的な人が仕事をしないような夜間や休日の対応が入りがちで、そのせいで買い物がしづらかったり(今はネットの恩恵が大きいけども、病院とかは行きづらいとかはある)、人にも会いづらかったり、その割に(少なくとも昔は)給料がよくなかったりとかで、インフラエンジニアになろうとする人が相対比較するとそもそも少ないという。今はさらにクラウドや仮想化などと技術の進化が直に必要な知識やスキルにつながることが多く広範囲ですからね。IT系の中でも苦労するわりに日陰で理解してもらいにくい役割の筆頭でしょう。もちろんここに書いたことは全部が全部そうだというわけではないですよ。そういうケースもある、という話)。

    育成するならそれなりに長期で考えて、専任者を定期的に出すようにするか、無難に委託をした方が現実的じゃないだろうか。
    教師で兼任となるとそれ相応の給与が加算されないと割には合わないだろう。

    あとはまぁユーザーが集中したときなど、特定の条件下でも作動し続けることを目指すには、
    ものすごく色々省いて端的に言うと、「お金がかかる」んです。

    これはすごく単純な話です。1日3人分の仕事を1人に渡してやれって言ったって、3日はかかります。
    どうしてもそれを1日で終わらせたいなら、人を3人に増やすでしょう。
    当然、新たに人をひっぱってくるなら、その人に払う給料などでそこにお金が追加でかかるわけです。

    コンピューターが処理できる仕事量も同じなんです。こなせる量には性能に応じて限界がありますから、
    より高性能なものにしたり、あるいは台数を追加したりすれば、そりゃあお金がかかるわけです。

    でも予算が増やせないなら、処理できる仕事量も増やせないわけです。
    その場合は単に、仕事が終わるまでの時間が長くなるだけの話です。
    それってシステム自体は正常なんですよ(時間がかかるだけの話。いやまぁ間接的にエラーが発生したりはしますけどね)。

    つまるところ、どんなにIT人材を増やしても、
    予算の壁(≒こなせる仕事量に一定の上限)があって、環境をいつまでも変更できないなら、同じようなことなら条件を満たせば何度でも起きます。

    もちろんシステムを作る側は、試算・見積をして、どれくらい仕事量が発生するだろう、
    この金額でこれくらいの性能ならその仕事がこれくらいの時間でこなせるだろう、っていうのは考えています。

    でも例外なんていくらでもありますからね。

    例えば遅刻しないように、いつもこれくらい時間かかるから、このくらいの時間に家をでよう、とか試算はしますよね。
    ところが、雨や雪などの天候の変化や、体調不良や事故・天災などがあれば予定より時間が多くかかることはあります。
    そういった可能性も踏まえて、多少多めに時間を見積もったりもするでしょう。

    システムってのはそういう何かの要素で変動する道路の交通状況みたいなものを含むような類なので、
    設計する際に同じようにあれこれと考えるんです。
    それでもそれはあくまで予想であって、それが全くのズレなくぴたりと当てはまるというのはなかなか出来ません。

    そもそも確率が低いものは試算からは除外しますからね。
    外出するときに「隕石が降ってくるかもしれないから、外出はやめよう」なんて判断を通常するわけがないのと同じです。
    でも絶対とは言い切れない(確率が0%でも100%でもない)ので、例外ってのはたいていどういった物事でも発生しうるものと考えるべきなんです。

    ですので、その例外のリスクを低くするためにも、
    特に「初めて」の場合などは、あらかじめ本番に近い環境で事前に試験・確認などを行ったりするものなのですが、
    直接 人が関わるものだと、機械じゃないから複数人が完全に同時に実行するってのは難しいですし、
    人には意思や能力(身体 含む)の違いがありますから、ある程度そこでズレが出たりで、必ずしも本番に起こりうることが事前に確認できるとは限らないんです。

    そういうこともあるから、最初については何かトラブルが起こりうることはむしろ想定の範囲内としておくべきで、
    最初に何かあったら、もうこのシステムを使わない！ と判断するのは時期尚早すぎるのです。

    現実と設計段階の試算・見積のズレを調整していけば、ある程度の改善はできますからね。
    (もちろんその後も同じような問題を何度も繰り返した場合や、
    あまりにも現実から遠い試算や見積をしている場合はその前提に問題があります)

    (道路の例で言えば、突然天候が変わったり、天災が起きたりするかもしれない、ということ。既にその道路ができて何年も経っているなら、
    今までの実績から予想の精度も高くなるけど、作ったばかりでまだ誰も通行したことがない道路だったら、データが無いので精度は下がるから、
    何か起こったときに追加で対応していくような類。
    大雨の時に近くの用水路があふれて道路が水浸しになったりすればじゃあその対策を、
    ●●が原因で事故が多いから、じゃあその対策でガードレールや信号機を設置しましょう、など、都度対応して、
    始めから完全完璧な状況にするのが難しいのと(システムは)同じようなものです。)

    この辺は一般的な物理的に手にする商品のようなものとは感覚は違うかなとは思いますし、
    やはりどういうものなのかを知らないから、物(商品)自体が悪いのだと思ってしまったりするのかな、と想定しています(あとはまぁ・・・いや、いいや)。

    そういった意味では教師が対応できるほどのスキルの習得まではいかずとも、
    状況を多少は理解できる程度の教育はあったほうが良いですかね。

    理解できないと不審にもつながって、色々と掛け違いも起こるからなぁ・・・。

    いやまぁ理解できないからという理由で、相手の話を聞こうともしない(そもそも理解しようとしていない)方もいますけど、まぁその辺はもう本旨と関係ないから割愛しよう。

    (追記(そういや人が集中したケースの例示がなかったなと)：
    例えば道路を新たに作りました。本日から開通です！
    あれ、渋滞してる！ よしじゃあもう１車線ずつ道路を増やすようにします！
    さっそく今から通行禁止です！ さあ工事開始！！
    なんてことになるわけないですよね。

    もともとの車線で予算が組まれて完成したものですから、
    １車線ずつ増やすにしても、その材料は？ 土地は？ 工事する人は？
    それにかかる費用は？ そもそも1車線ずつ増やすだけで解決するの？ 根拠は？
    となるわけで混雑してるから道をすぐに広げるなんて出来ません。

    根本的に渋滞した原因の調査すらせずに、混雑しているという現象だけで道を増やすというのは短慮でしょう。

    もしかすると開通日初日で物珍しさから一時的に渋滞しただけかもしれません。
    そういった理由だったら道を増やさずそのまま放置して、あまりにもひどいなら、
    警察官なり交通整理をする人を短期間だけ投入するだけで解消する可能性があります。
    あるいは事故があったのが原因だったら、今回は何もせずとも良いことだってあります。
    何日か、あるいは何週間か経過観察してみたら、特定の時間帯だけ混むことがわかっていたら、
    もしかすると信号機の点灯時間の調整で解決するやもしれません。
    恒久的に混み続けるなら、そこでようやく道路を増やそうか、などとなってきます。

    システムだって利用者が集中して混雑しているからといって、
    設備を増強すれば良いっていう話ではないのです。
    原因は一つかもしれませんし、複数の可能性もありますから、
    いずれにせよ観察・監視して特定する必要はあります。

    プログラムの不具合だったら改修したり、
    設定でどうにかできるなら変更したり(これは道路の例で言う、信号機の時間の調整みたいなもの。もとある機能自体を変更するわけではなく、設定だけで処理に影響を与えるような類)、
    明らかに性能不足が原因だったら性能を上げたり、
    回線の細さが問題だったら増設したり(これは道路で言う、道＝車線の数と思ってもいい)、とかです。

    ただまぁITシステムに関してはクラウドを使ってたりすると、
    お金さえあればすぐに増設できる手段があったりするので、
    ここは現実の道路とは大きく異なるところではありますけども。

    だから例えばシステムだったら一時的にもう原因特定は保留にしておいて、
    とにもかくにも設備を増やしてしまってその場はしのいで、
    その間に原因調査して、問題があれば対応して、
    対応した状況での混雑具合を見て問題なかったら、元の設備の数に戻してしまう、
    みたいなこともできるわけです。

    現実の道路だったらポンポン増やしたり減らしたりなんかできませんから、
    前述通り、採れる手段として考えられるものの前提が異なる部分はあります。

    ただまぁやっぱり正攻法は原因があるならその原因だけを
    対処する方がスマートではありますけどね(その分、時間がかかることはある)。
    この辺は優先度なり予算なり、諸々の都合がありますから、
    必ずしも特定の方法だけが正しいというわけではないんです。

    この辺も含めてIT人材として教師を育成します？ できます？
    と考えるとまぁ前の方で書いた通り、長期計画で考えたり、専任者として設けたり、
    委託したりが現実的じゃないのかなぁと。
    あー・・・「餅は餅屋」の一言で済む話かな。
    とにもかくにも「インフラ系」は物とは違いますから、プログラム(≒物)なんかと同じように育成すりゃすぐ対応できるだろう、とは考えない方がいいです。広域の知識やケースバイケースでの判断や対応ができるような経験などが必要になる。)

  • シェアサイクルサービス「Mobike」ユーザーのパスポート・運転免許証など12万件超の個人情報がオンライン上で暗号化されないまま公開されていることが明らかに – GIGAZINE