日本の「IT 人材不足」の正体


公開 (UL): 2022-06-24
更新 (UD): 2022-06-24
閲覧 (DL): 2022-06-26

この記事のもくじ

→本文へ
当サイトは SNS の公式アカウントがないので,「議論ネタ」にする際は,皆さんのブログ,メーリングリスト,SNS や掲示板などで,適当にハッシュタグを付けたりリンクを掲載するなどしてご利用ください。

前の記事

2022-05-28
QR コードの功罪

最近の記事

2022-03-31
パソコンを無改造で障害者対応にするヒント
2021-11-29
「折り畳み」の魅力
2021-10-25
今どきの企業の意識の危うさ
2021-09-21
「使命」を捨てる日本のマスコミ
2021-09-06
現場を知らないメーカーの夢想
新着情報

新着情報 Recent docs.

Sorry, but almost these pages are only Japanese.
日本の「IT 人材不足」の正体 «The simple reason why Japanese companies lack IT-skill.»
保険会社からのセキュリティガバガバメールが「IT 人材不足」の正体を暴く。
QR コードの功罪 «"Un-readable QR-code" discloses incompetences of the government in Nishi-tokyo city.»
「読めない QR コード」に見えたオヤクショの無能さ。
パソコンを無改造で障害者対応にするヒント «The hints of PC fitting for persons with disabilities without technical work.»
部品屋さんのサイトで見つけた, 安いけど工夫次第で超便利に使えそうな製品をご紹介。
現場を知らないメーカーの夢想 «Makers say "we'll make good!" without investigation of working on-the-job.»
日経新聞記事の感想。「遠隔操作ロボットが医療介護現場で人材を活かす」という眉唾。
「マイナンバー」が危険なこれだけの理由 «The reasons of "My-Number System" is danger.»
それでも「マイナンバー」を推す裏の理由を推察。

人気記事 Frequent view pages.

表計算で「令和」に対応する方法
How to adapt the Gengo era "Reiwa" on spreadsheet applicaiton.

古いアプリも OK。「表計算 令和」の検索結果上位御礼!
表計算ソフトで予定表を自動作成する超便利な方法 «How to make the schedule table automatically on spread-sheet.»
「毎月第○×曜日」的な法則は自動で作らせてラクしよう!
表計算ソフトに「個人情報保護機能」を仕込む方法 «Prevention to leak private-data with spread-​sheet macro function.»
「漏えい」のためのフェイルセーフ。「表計算 個人情報」の検索結果上位御礼!
オランダの介護に対する考え方一例
大学などからのアクセス多数! 検索語「オランダ 介護の考え方」での上位御礼!
Wary-Basher (ワリバッシャー)
DIY device that enables the handicapped to operate many things with a switch like push-button.

障害者の様々な操作をスイッチ操作で実現する器具。キットも発売中! 「作り方」PDF ダウンロード多数御礼!←地方教育委で人気。
貧乏人を殺す行政の構造 «Structurally, the administrators kill the poors in Japan.»
ヘタすると多摩川に流されるところだった台風 19 号

この記事に対する → 調布市の反応

おすすめ! Recommend

文字ベース天気予報 «Weather forecast in text mainly from JMA Json-data.»
古いブラウザやスマホ,音読ソフトでも大丈夫! 気象庁の JSON データを利用した文字ベースの天気予報(試験版)。
「事故防シート」について «Cared persons taking with "Jiko-​Bow-​Sheet" prevents from accidents.»
介護現場の負担軽減と事故防止のアイデア
【連載】 キーボードの「キー」の詳しい使い方 «The detial of usage each key on keybord.»
各キーの機能詳細。機能別五十音順一覧。
和易ゐ記 (WAI-WIKI) «WAI-WIKI is light­weight markup language for Japanese, and generates HTML on this server on-​demand.»
当サイトで開発/使用中の日本語向けに特化した軽量マークアップ言語

ご連絡 For contact safely.

当サイト管理者(石川)への連絡内容の機密保持には,こちらで取得できるパスワードをご利用ください。 Get password for file(s) encryption to send the admini­strator of this site M.Ishikawa.

時事川柳 News Senryu

ワクチンを
 「打って変わった」
  厚労省

 厚労省が外部からの指摘で統計を修正したら,ワクチン2回接種者より未接種者のほうが感染率が低くなったって話(参考記事: CBC テレビ日経ビジネス)。 子供向けの国語の問題か何かで,「打って変わって」を使って短文を作るというお題に「お父さんは薬を『打って変わって』しまった」という間違った使い方がネットで話題になっていたのを思い出した。 ワクチンには,思考能力を減衰させる副反応もあるのかもね。 ちなみに,当サイト管理人はアレルギーの関係で未接種。 何が「ワクワク割」だ!? (2022-06-06)

ご支援 Support this site.

でも絶賛 コロナ失業中!!
CORONA-NEET, seeking works now!

この活動をご支援いただける方はこちらへ Could you support this site, see here (but Japanese).

 最近,ある大手企業の代理店からメールを受け取りちょっと呆れた。理由は以下のとおり。

 少しは IT に詳しい人なら分かるとおり,これらの多くは「セキュリティ上問題が多い」とされていること。それらを見事に踏襲している。しかもその「大手企業」というのは……いや,もうあえて社名を晒すと「水井杉友海上火災(仮名)」という保険会社。それと,じつは数年前まで使っていた「帝京海上白動(仮名)」という保険会社からも似たような方法でメールが送られて来ていたから,1つの会社だけの問題ではないと思う。つまり様々な大手企業の間で,もう何年も前からセキュリティ上のリスクが放置されている可能性が考えられる。
 もちろん,そのメールの送信者は「代理店」だが,そうはいっても,安心や安全を謳う保険会社の代理店がそれでいいのかは大問題だろう。セキュリティ意識については,まずは親会社が堅固なものを持ち,その意向が末端の子会社まで行き届いていてしかるべきもの。この記事公開(2022-06-24)後,速やかにこれら問題が解消されることを望む。

 ただ,IT にそれほど詳しくない人は,「どこが問題なのか」と思っているかもしれない。以降,「何が問題か?」を詳しく述べてみる。

● メールに潜む様々な問題

◆ 大きな添付ファイルを突然送る

 これには,以下のような問題がある。

 最初の項目を理由として,使っているメールサーバやメールソフトなどが,突然送られて来た大きな添付ファイルのメールを,「ウイルス」と判断して自動で削除してしまったりする可能性がある。すると当然,宛先ではそのメールは読めなくなる。
 逆に,そうした大きな添付ファイルを普段から疑いなく開いてしまっていると,「ある日突然ウイルスが送られて来た」時も,無防備に開いてしまう可能性が高くなるのは,言うまでもないだろう。何のためらいもなく「普段から大きな添付ファイルをやりとりする」ことが,いかにセキュリティ上の問題を大きくしているかということだ。

 2番めは,じつは筆者の今の通信環境はそれに近い。以前は ADSL という「容量制限なし」のサービスを利用していたから,少々大きな添付ファイルが送られて来ても大して問題なかったのだが,そのサービスが打ち切られてしまい通信環境が悪化。今は実質「従量制」のため,デカいファイルほど通信費が多くかかる。今回も,1MB 超のファイルが添付されていると知って……通信費節約のため,安定した公衆無線 LAN の使える 2km ほど離れた駅まで出かけてダウンロードしたのだった。
 ちなみに,通信環境悪化の根本原因は,打ち切る通信サービスを引き継ぐような同等の通信環境と価格帯で利用できるサービスを通信業者に用意させないまま,打ち切りを認めた「総務省」が悪いと思っている。

 でも「他のメールまで読めなくなる」のはなぜか。それは,サイズの大きなファイルは,メールの保存領域を満杯にしてしまう可能性が高くなるため。満杯になれば新たに保存する場所がないから,以降に受信するメールの着信をサーバが拒否してしまうことがある。サイズが大きいメールは,そのリスクを高めることは言うまでもないだろう。

◆ PPAP

 豹柄の服着てペンとリンゴ持って踊る「アレ」ではない。「パスワードで秘匿したファイル」をまず添付で送り,「パスワードそのもの」を「あとから」メールで送る「プロトコル(手順)」のこと。「あとから(Atokara)」とか,略語に日本語が含まれているが,実際,日本特有のやり方らしい。他の国ではされない方式。なぜなら,セキュリティの意味がほとんどないから。無意味なセキュリティの方法を,深い意味のないダンスになぞらえて同じ略語を使った……ということのよう。別に筆者が勝手に解釈した略語でも何でもなくて,「PPAP メール」などで検索して引っかかってくる多数の記事で,「セキュリティ上問題が多い方式」として一般化している言葉。そこまで「一般的に」ダメな方式として知られているのに,それで資料を送って来る時点で……もうね。

 筆者は,PPAP に代わる方式として「PPOP」というものを提案しているが,PPAP が「なぜセキュリティ上無意味なのか」についても,その説明記事に詳しく書いている。

▼ PPOP(PPAP に代わるパスワード秘匿方法)
http://treeware.jp-help.net/?ssss9

 簡単に言えば,使用しているメールソフトやメールサーバから情報が漏れると,その「パスワードをかけた添付ファイル」と,「パスワードを伝えるメール」の両方が同時に外部に知られる可能性が高いからだ。つまり,結局は漏れた先でファイルのパスワードは解除され,何の問題もなく見られてしまう。セキュリティは上がらず,その「パスワードで暗号化する手間」が無駄にかかるだけ,ということになる。

 PPAP のさらなる問題は,コンピュータウイルスに悪用される危険性が高まっているらしいという点。
 この方式,言うまでもなく,パスワードで暗号化したファイルとそのパスワードの発信元はたいてい同じになる。コンピュータウイルスも,多くは,感染した「1つの」コンピュータで「複製」されて拡散される仕組みだから,コンピュータウイルスが,複製したウイルスそのものを「暗号化」して,PPAP と同じ方式で同じ発信元から同じ相手に「こちらがパスワードになります」などといった本文と共に送ることも簡単。メール受信側の感覚としては,「パスワードかけて来るくらいだから,発信相手の作った重要なファイルなのだろう」と思い,直ぐ開こうとするだろう。つまり PPAP を装うことで「怪しまれずに開いてもらえる」可能性を簡単に高められる。感染を広げるには好都合というわけだ。
 「それで感染した」という具体例の報告の記事は見たことがないが,時を追うごとに巧妙化するコンピュータウイルスだから,いつそうしたウイルスが出てくるのかは,時間の問題ではないだろうか。
 いや,以下の「まめこ」さんのマンガを見ると,もう実際に PPAP によく似た方法が既に詐欺に悪用されているようだ。いかに普段からためらいなく PPAP を使うことが危険か,「表情から」よく分かると思う。

▼ 新手のウィルス、やり口がどんどん巧みになる
https://mamekichimameko.blog.jp/archives/86365297.html

 「それは受信者が気をつければいいだけの話だろう」と思われるかもしれないが,頻繁に PPAP が使われれば,それだけ相手に「開いて中を見なきゃ」という気を起こさせるから,PAPP に似た方式で送られるウイルスや詐欺メールも開いてしまい,犯罪被害者になるリスクを高めることになる。セキュリティ意識があるなら,使うべきではない方法だ。
 既にこの手で拡散をしてしまっているウイルスがあるかもしれない。ただ,最近のコンピュータウイルスは,感染してすぐには発症しないらしい……何だか似たようなウイルスが人間に感染して大騒ぎしていた気もするが,つまり,感染した「その時」を知ることはできないわけで,ウイルスが潜んでいる PPAP を開いて感染してしまっていたとしても,気付かないかもしれない。これでは「気を付けようもない」わけだ。
 これが,PPAP という方法に潜むリスク。普段からこの方法でメールをやりとりすることが,いかに危険かということ。筆者が述べるまでもなく,たとえば「PPAP ZIP」などで検索すると,この組み合わせのリスクについて述べた記事が多数出てくる。その方法でメールを送って来る保険会社代理店のセキュリティ意識は,残念ながらその程度と言える。

◆ 日本語のファイル名

 C. で「筆者の使っているソフトでは ZIP を開けなかった」と書いたが,原因はおそらく処理系の文字コードの違い。筆者の使用する Linux という処理系では,UTF-8 と呼ばれるものが「標準文字コード」として採用されている。この形式は日本語だけでなく,世界共通の文字コードだから,Linux に限らず多くの処理系で標準として採用されている。
 一方,たぶん保険会社から送られてきた ZIP には,Windows で標準の「シフト JIS」と呼ばれる形式のファイル名で収録されていたのではないかと思う。「JIS」の文字が含まれることで分かるように日本特有の規格。だから「世界共通」の規格である UTF-8 との間には日本語の表記に互換性はない。ZIP 内のファイル名に「シフト JIS」の日本語が使われていたため,Linux で「UTF-8 ファイル名」として扱おうとしてうまくいかず,ソフトが解凍できなかったのだろうと推測される。

 じつはこれは「作る側」で簡単に回避する方法がある。「ファイル名に日本語の文字を使わないようにすればいい」だけの話。UTF-8 とシフト JIS で異なるのは日本語の文字の扱いだけで,半角の英数……つまり,アルファベットと数字の扱いは共通している。日本語文字コードには,他に EUC-JP と呼ばれるものもあるが,そちらも英数部分の扱いは共通しているから,どうであれ,英数のみをファイル名に使い,日本語を使わなければ,Windows 上で作成した ZIP ファイルでも,たいていの処理系で問題なく解凍できた可能性が高かったのだ。
 なお,同じ英数でも「全角」は日本語の扱いになるのでダメ。また,あくまでも「作る側」でできる対策。この点を考慮されずに日本語名のファイルを収録した ZIP は,もし作成側とは異なる文字コードの機種だった場合,受信側ではどうしようもなくなる可能性が高い。じつはその後「開く前に英数のみのファイル名に変更できる」と分かったので,何とか開くことはできたが,それもたまたまそうした変更に対応したソフトがあったから。それがない人はあきらめるしかない。それだって,ZIP に収録されていた元のファイル名が何なのかは分からないままだ。

 だいたい,この方法で送って来るのは筆者に対してだけ……なんてことがあるだろうか? そうではないはず。筆者に送って来たということは,他の人にも同じような方法でメールしているのではないだろうか。
 「開くことができた」とはいえ,それは,筆者が「ZIP を開く方法を複数知っていた」うえ,「名前を変更してから開く」なんて手段が使えたからこそ。おまけに,当初はスマホにダウンロードしたのだが,そこに ZIP を開くアプリ設定がなかったため,スマホでは見れなかった。だから,そこからパソコンに移す手間も余計にかけている。これなども「パソコンに移す方法」を知らなかったら,見れないままになる。これらの方法の1つでも知らなかったら,開くことはできなくなり,資料を見るのはあきらめざるを得なくなるだろう。
 送信する側が「日本語の扱いは処理系により異なる」という基礎知識的 IT 事情を知っていれば,「英数のみのファイル名の資料にする」などの対策をとるだろうから,開くのに苦労することもないだろうが,この保険の代理店はそれを知らず,他の人にも同様にメールを送信している可能性がある。開く方法が分からず,あきらめて見れないままになってしまう人も多数いて,放置されているのが実態ではないだろうか。
 資料を見せて保険の詳しい内容を利用者に伝えることは,「代理店の使命」ではないかと思うが,前述したようなことが放置されているとすれば,とても「代理店の使命」を果たしているとは言えないはずだ。

◆ Outlook

 ここ最近「猛威を振るっている」と言われているコンピュータウイルスが,拡散のために悪用されるのがこのメールソフトらしい。つまり,ウイルス拡散に使われる可能性の高いソフトを,安心や安全を謳う保険会社の代理店が使っているという点で,筆者は疑問に感じる。

 で,最初に述べたように,大きな添付ファイルの付いているメールは「ウイルス」の疑いを持たれる可能性も大きい。となると,Outlook で送られてきた大きな添付ファイルのメールは? セキュリティの意識の高い組織や個人なら,うっかり開かないようにするため「ゴミ箱直行」の設定をしている可能性も高いだろう。筆者はたまたまその設定にはしていなかったが,普段から迷惑メールに悩まされている人などは,そうした設定にしている可能性も高く,「ゴミ箱直行」で読まれないことも多くなるのではないか。
 あるいは,「受信サーバ」上でそうした「ウイルス対策」が働くと,受信者に届く前に削除されてしまう可能性もある。この場合,受信前に削除されてしまうため,そうなれば,受信者の使うメールソフトの「ゴミ箱」にも入らず,メールがあったことすら知ることはできなくなる。

 ちなみに,これまでに筆者の元に送られて来た,「詐欺」と思わしきメールは,その送信に使われたメールソフトとして Outlook の文字が記載されているものも多い。「多い」とは言っても割合的な話で,全体数としては少ないから,今は何の対策もしていないが,その手の着信が多くなって来たら,うっかり開いてしまわないよう,発信者に心当たりのない Outlook からのメールは「ゴミ箱直行」か着信拒否設定をすることになるかもしれない。既にそうした状況にある人がその設定をしていれば,Outlook から送信されたメールは読めないことになるだろう。

 ウイルスに詐欺……これが Outlook の抱えるセキュリティリスク。

◆ 「なぜダメか」まとめ

 保険会社代理店からメール添付で送付された資料の「ダメな点」をまとめると,以下のとおり。

 いかにセキュリティ上問題が多く,「読まれない」可能性の高い送付の方法だったかということ。ただ,一番問題が大きいと思うのは,これらの方法をことごとく踏襲したのが,本来は安心や安全に気を遣うべき保険会社の代理店で,しかも「大手」保険会社であるという点だ。多数居るであろう顧客に同様な方法で資料を送付しているとすれば,リスクをバラ撒いている以外の何者でもないのではないか。

● 「IT 人材」が不足する理由

◆ 「新入り」が指摘すると?

 さて,もし筆者がこうした会社に入社し,述べてきたような主張をしたらどうなるだろうか。つまり,「デカいファイルをメール添付で送るなんてダメです! PPAP なんてダメです! ZIP に日本語ファイル名で収録するなんてダメです! Outlook 使うのをやめなさい!」……などと言ったとしたら,どんな扱いをされるだろうか。「新入りごときが,長く問題のなかった当社のやり方を侮辱するのか!」などと言われて,追い出されるのがオチだとは思えないだろうか。
 述べてきたようなことは,筆者が主張するまでもなく,検索すれば,セキュリティ会社のサイトなどに同じようなリスクを訴える記事があったりする。たとえば「エモテット PPAP」などで検索してみるといい。「エモテット」とは,Outlook の節で述べた「猛威を振るっている」と言われているコンピュータウイルスの1つ。述べて来たやり方がいかにリスクを高めるのかは,筆者以外の記事があちらこちらのサイトで読める。経営者なら,それらを自分で調べてでもセキュリティを考慮すべきだし,調べていれば筆者が「ダメです!」という理由も理解されるはずだし,ある意味,筆者が言うまでもなく,述べてきたような手法で資料をメールに添付して送らせることなどさせないのではないだろうか。
 でも,新入りの筆者がそれを言うと,辞めさせられるだろう。では,リスクを指摘する社員を辞めさせ,いざその「エモテット」などのコンピュータウイルスに感染して被害が出たらどうする? ネット上には,あちらこちらのサイトに「この度はエモテット感染で,関係者に多大なご迷惑をおかけし……」などといったお詫び記事を見かける。大企業やその子会社のみならず,お役所や公官庁サイトなどでも見かけた気がする。つまりウイルスの「実害」は既に出ているわけだ。では,もしその部署に「過去にウイルス感染リスクを指摘していた新入りを追い出した上司」が居たら,「責任」を問われるだろうか。セキュリティのリスクの指摘に聞く耳を持たず,追い出しておいて,まさにその指摘を原因とする問題がたとえ起きたとしても,追い出した側の責任は一切問われない……これが,今どきの企業や社会の仕組み。それでいて経営者は「IT 人材不足でして……」などと釈明してはいないか。

 こうした矛盾するような状態が放置されるのはなぜか。それは,どんなに IT 事情に詳しい人を辞めさせようと,それが「部下」であれば,社内の「局所的な内部事情」といった扱いで幕引きされて,その上司の「辞めさせた判断が妥当だったかどうか」は検証されずに済まされて,その判断の責任の所在は見えないまま追求されない仕組みだからだ。
 少し話が反れるが,ある国は,一部民族の虐待を指摘されると「内政干渉だ!」と言って反発する。「内部事情に外部からとやかく言われる筋合いはない」というスタンスだ。また,福島第一原発の事故は,東京電力の内部調査で「大きな津波で補助電源が機能しなくなる危険性」を指摘されていたのに,当時の社長をはじめ幹部たちは「信じられない」的な理由で対策を先送りしていたらしい。結果的に津波で機能が停止し大事故となって,多くの人がその「先送り」の正当性を疑うと思うが,当事者たちは,裁判で「無罪」を主張している。こちらも「当時の内部調査に対し,指揮監督的立場で『信じられない』と判断したのだから,外部からとやかく言われる筋合いはない」というスタンスに見える。
 そうしたスタンスがいかに問題をこじらせているかは,民族虐待問題や原発事故裁判の例が示すとおり。IT に詳しい新入社員を何人辞めさせようと,「『部下』の評価は『上司』の判断であり,内部事情だ」という扱いで,辞めさせた上司の責任が問われずに済む状態は,民族虐待に対する批判を「内政干渉だ」と主張する国や,大きな津波の可能性を「当時は信じられなかった」で無罪を主張してしまう東電幹部に,似た構図を感じる。結果,IT とセキュリティ問題をこじらせ続けているところまで含めて,よく似ている気がする。
 それで,いざコンピュータウイルスへの感染や情報漏えいが起きると「IT 人材不足で」と釈明する。これが日本の「IT 人材不足」の正体。

◆ その結果「サポセン」はこうなる

 「それは企業のサポートにでも直接言えばいいことで,ウェブで公表するようなことではないだろう」と思われるかもしれない。が,述べているようなメール送信方法が「セキュリティ上問題」とされることは,筆者が言うまでもなく,検索すれば同様な問題を指摘する多くの記事が読める。それほど以前より問題なのに,そうしたセキュリティガバガバのメールが送られて来たのは,「サポートが機能を果たしていない」からではないか。であるなら,サポートにクレームしても無駄だろう。
 既にウェブ上には「問題だ!」とする様々な記事があるわけだから,企業内に「セキュリティ上の問題を指摘できる人」が居れば,とっくに内部で誰かに指摘され,そんなメールの送り方をすることなどなかったはずだ。それが送られて来てしまうということは,企業内の「セキュリティの問題を指摘できる人」……ある意味筆者のような者は既に排除されてしまった結果と考えられる。少なくとも末端のサポートに「セキュリティに詳しい人」など配置しそうにないのは想像できるだろう。すると,会社側の重大なセキュリティ問題を指摘するクレームであっても,受け付けたサポート担当者が気付けずに,「上司は当社のセキュリティは大丈夫と言っているから,セキュリティがどーのこーのと言って来るクレームは当人の勝手な思い込みに決まっている」といった対応になるのではないか。そして「顧客の『思い込み』なんか上には伝えない」といった対応になっていくであろうことは,容易に想像できる。
 一方で,その「上」としては,いちいちよく分からないセキュリティ上のクレームを報告されて「どうします?」と指示を仰ぐ人よりも,どんなクレームも適当にあしらって報告をして来ない担当者をサポートに充てておいたほうが,「対処を考える必要がない」からラクができる。サポートの担当者も,セキュリティがよく分からないまま「何言ってんの? そっちが悪いに決まっているでしょ!」的な対応で「解決済み」扱いにするような人ほど「クレームを『減らしてくれる』優秀な社員」としての報酬を受け取れるようになっていく気がする。セキュリティのことは分からないからクレームに対処したくない「上の人たち」と,よく分からないセキュリティ上のクレームを報告しないことを「評価されて」報酬を受け取れる「サポート担当者」は,Win-Win なのである。
 つまり,セキュリティに問題のあるメールを平気で送って来る企業は「サポートが機能しない状態」なのは,ほぼ明白と思われる。そうした企業にまともなサポートを期待するのは無駄な気がする。
 だいたい今回は,何万人もの顧客の居る可能性のある大手の保険会社なわけだし,ウェブにいくつも記事があるほどポピュラーな「セキュリティ上の問題」なのだから,筆者がこんな記事を公開する以前から既に何人もがこうしたメール送信方法についてクレームしていてもよさそうに思えないだろうか。つまりそれだけ指摘されていても,そのガバガバなメールを出しちゃうくらい放置されている可能性が高いわけだ。
 言い方を換えれば,「サポートが機能していないから,もう何年間も『セキュリティ上問題』とされる方法が見直されずに,そのまま平気でメール送信に使われた」と考えると,しっくりするだろうか。サポートで「そっちが悪いんじゃない?」的対応をしている限り,その悪い要因が会社側にあっても,末端のサポートで全てぶっ潰され上に報告されないから,悪い要因は残り続ける。だからガバガバなメールが来るのである。セキュリティの事情をよく知らずに,上に報告せず改善につながらないサポートとのやりとりが時間の無駄になるのは,言うまでもない。

 これが今どきの,いわゆる「サポセン」の実態だろうと考えている。保険会社以外でも,身に覚えのある人も多いのではないか。

● では「IT 人材」とは?

 今回,こうした指摘をしている筆者は,この記事を書いている時点では,コロナの影響もありほぼ無収入。「IT やセキュリティに関連する説明をしに来て欲しい」なんて話は全く来ない。
 では逆に,「望まれている」IT 人材とは,どんな人たちだろうか。
 おそらく経営者たちの言う「人材」というのは,筆者のように従来のやり方の(ぜいじゃくせい→)脆弱性を指摘し「やめなさい!」という人ではなく,従来のやり方,また経営者が出した指示に対しても,誤りや脆弱性など一切指摘することなく,「それやります!」と言って指示通りのことを安い賃金で実現してくれて,できれば,もし不具合が発覚したらその責任は負ってくれるような人たちではないだろうか。そんな「人材」などいるかって話。「不足」するのは当然のような気がする。

 たとえばどこかの「大」企業が,誰かに「セキュリティシステム」の製作を「百万で」依頼したとする。その後,もし他の企業から「ウチに同じシステムを作ってくれたら一千万出す!」と言われたら,製作者はどうするだろうか。「百万で十分生活できる」なら断わるだろうが……百万では生活できないとなれば,背に腹は代えられず,請け負うことになるのではないか。もちろん,他で同じ仕組みのものを作れば,脆弱性などは筒抜けになる。じつは後者の依頼人の背後に大規模な詐欺グループがいて,報酬の一千万は,後の計画でその脆弱性を調べて悪用するための「先行投資」的なものだったとしても,巧妙に隠されて接近されたのでは依頼を受けた側からは感知しようがない。「大」企業であるほど顧客も多いから,システムの脆弱性を悪用して詐欺をすれば,そのぶん引っかかる「カモ」も多く,詐欺で得られる稼ぎも大きいはずだ。詐欺グループにとって一千万くらいの先行投資は「はした金」レベルと考えられるだろう。つまり,「大」企業であるほど,セキュリティの高いシステムを作るべきであり,それなりにセキュリティ意識の高い人たちを集めて作らせて,述べたような他への技術流出防止のためにも「もう他で働く必要がない」レベルの報酬を与えてもいいくらいだと思うのだが……今どきの企業経営者は,その辺りをどう考えているのだろうか。
 それを垣間見る例は,社長が「二段階認証」のセキュリティを知らないレベルでシステムを作った結果,開始からわずか数ヶ月でサービスが終了した「セブンペイ」。「セブン……」といえば流通大手だし,そのシステムに関わっていた企業は,ハード,ソフト,金融とりまぜ「大」企業ばかりだったと思うが,ウワサではそのシステムで使われたソフトウエアの一部が公開されていたとか。それが本当なら「脆弱性」も何もかもバレバレだったのではないか。早々のサービス打ち切りは,悪用がひどかったのも要因だったようで,実際に公開されていたソフトが悪用されたのではないかといった話も何かで読んだ気がする。セキュリティ意識のしっかりしない経営者の考えを,「しっかりしないまま」に,しかも「安い賃金」で働いてくれる人たちだけを集めてシステムを作った結果であるなら,当然のような気もする。これが現実ではないか。

 今どきの企業が「IT 人材」と言っているのは,じつは「奴隷」のような人のことではないか。上司の考えに「それはセキュリティ上問題です」などと指摘すると,追い出されてお金をもらえなくなるから,お金をもらうためには,たとえセキュリティ上問題と気づいても一切指摘しない人か,作る技術はあってもセキュリティに十分配慮した仕組みまで考える能力はなく「ただ言われたとおりに動くだけ」の,奴隷のような人たちばかりになるような気がする。少々安くても「お金さえもらえばいい」人たちばかり働くとどうなるか。報酬が安ければ,「いかに多く仕事をこなすか」で稼がないと生活が成り立たない。すると,セキュリティがガバガバだろうと何だろうと「とりあえず」言われた通りに動くように見えるものに手早く仕上げて,なるべく多く繰り返そうとするだろう。そんな時は,公開されているソフトを流用すれば早く仕上げられる。そして,そうした人たちは賃金以上の責任を負う気もないだろうから,逆に作ったソフトを公開するなどして収入を増やす……なんてことをする輩が出てきても不思議ではない。「セブンペイ」をはじめ,システムの一部が公開されていたなんてウワサが現実としてあるわけだ。
 で,そうやって似たような作り方で作られたシステムがあちらこちらで使われ,そこに共通して流用されたソフトに致命的な不具合や脆弱性が発見されたりしたら,どうなってしまうだろうか。

 「いや,今まで PPAP で問題なかったし……」などと考える人も多いだろう。それこそ「正常性バイアス」と呼ばれる危険な考え方。考えてみてほしい,十数年前まで多くの日本人が「原発は安全」と思っていたのではないか。2011 年3月のあの日の前までは……。「今まで大丈夫だった」ことを,「これからも大丈夫」と勘違いしたから,あの事故につながったとは考えられないだろうか。PPAP はじめ,述べて来た従来のやり方の脆弱性はあちらこちらで指摘されている。それでも「今まで問題なかったから」という理由で使い続けていていいと思うだろうか。危機管理とは? セキュリティとは? もっと考えるべきだと思う。

 日本に不足しているのは「IT 人材」ではなく,社会全体の「セキュリティに対する思考能力」ではないかと,筆者は思っている。



© M.Ishikawa; TREEWARE 2022.