マクロやRPAで自動化しても、何故に給与が上がらないのか?

マクロやRPAなどを使って業務を自動化して何十時間も節約しているのに給与は…みたいな話しを時折見かけるので、何故給与が増えないのか考察したいと思う。

マクロやRPAなどの活用による業務の効率化は二つの段階に分けられる。

・1stステージ
マクロやRPAを利用した自動化により、事務作業にかかる時間が削減されている状況。この段階は従業員個人の能力により業務時間の削減がなされている。作業負担の軽減により同僚からは感謝されたりはする。だがこの段階では会社の利益には繋がっていない。

・2ndステージ
自動化により削減された時間をより付加価値の高い業務に割り当てたり、あるいは余剰人員を人手の足りない部署に異動したり、従業員の解雇を行っている状態。

マクロやRPAの開発と維持には費用が発生している。作業時間の短縮により不要になった労働力を異動あるいは解雇するなり、短縮された時間を用いてより付加価値の高い作業を行うので無ければ、会社としては開発と維持にかかる費用分を損した状態になってしまう。

「マクロを勉強して自動化しました」という話しをしているとき、殆どの場合は1stステージの状態にあり、まだ会社に利益を生み出せていない。故に給与が増えることを望むなら、1stステージ→2ndステージへの移行が重要になるのだが、ここが難しい。

余剰人員異動や解雇には人事権が必要になるし、より付加価値の高い業務を生み出せる人材は自動化人材よりも貴重だ。2ndステージの実現には管理職の協力が必要不可欠になる。管理職者に1stステージで自動化の恩恵を見せて、2ndステージに移るための協力を得なければならない。

…が、そこで自動化を進められる素養を持つ上司なら、従業員に言われるまでもなくIT化を進めているはずだよね…的な達観があったり無かったり。

と言う訳でマクロを使えたり、RPAを使いこなせたからと行って突然に給与が増えることは無い。でも使える手札が増えれば、選択肢も増えるわけで、今後にチャンスをものに出来る可能性が増えるわけで、無駄では無い。

cocoaの障害とか、気象庁WEBの障害とか

Andoroid版 COCOAの修正版リリースや、AWSの障害により気象庁のWEBが停止したニュースを受けて、政府のIT関係の調達について再び議論が起こっている。

COCOAではリリース以降、管理責任が曖昧のまま致命的な不具合が指摘されていたにもかかわらず数ヶ月にわたって放置されていた事が問題となった。他にもiOS版で接触履歴が初期化されるなど致命的な不具合が残っている。

AWS等のクラウドを使うのは、良い試みだと思う。ただし、実態として何処のクラウドサービスでも数年に毎に大規模な障害が起こっている。細かな障害に至っては日常茶飯事に発生する。クラウドだから可用性(信頼性)が高まるという訳ではない。したがってライフラインに直結するようなサービスをクラウドの載せるなら、一部のデータセンターが停止しうることを前提に冗長化しておくのが当然で、それを怠っていたのなら重大な問題だろう。

そもそも民生用のAWSで動かしていたのも如何なものか。例えば米国政府もAWSを積極的に利用している。AWS GovCloudとして提供されているそれは、FedRAMP等の米国政府の要求するセキュリティ要件を満たす。Amazonは従業員のバックグランドチェックを行い、米国市民以外が運用に関わらない体制を取り、民生用とは切り離された独立したデータセンターで運用されている。日本政府もAWSのクラウドを導入する事が決まっているが、はたして何処まで要件を纏めているのだろう?

結局の所はcocoaの不具合と同じ問題に行き着くのかもしれない。厚労省に限らず、発注元である政府に、情報システムの開発・運用要件を纏めてる能力が無くなっている事の証左に見える。

新たに組織されようとしているデジタル庁には大きく期待しているのだが、結局の所、以下のような問題の本質に行き着くのではないかと思う。

  • 現在の賃金・雇用体制では専門家を雇用するにも十分な賃金や地位を出せない。
  • 政府内において専門家を育成する事も出来ていない。

18日に河野太郎規制改革相が公務員の残業代を全額支給すると共に、労働実態を把握するように指示をしている。この事が公務員の人事制度改革に繋がることを期待してやまない。

IT media:AWS障害、5時間でほぼ復旧 気象庁Webサイトなどに影響
CNET Japan:通知の不具合を解消、1日1回程度アプリ再起動を推奨–接触確認アプリ「COCOA」修正版
東京新聞:COCOA開発受注企業が事業費94%を3社に再委託、さらに2社に…不具合の原因企業「分からない」

ソースコードは流出して当たり前と思おう

SMBCに続きNTTデータも被害を確認、広がるGitHub上のコード流出問題

とかくソースコードが流出したことが問題視されがちだが、本当に重要なのはソースコードが流出しても問題の無い運用体制・セキュリティ体制が取られている事にある。

大規模なソフトウェアの開発には数百人規模のエンジニアがかかわる事になる。その全員が悪意を持たず、過ちをおかすこと無く、善良かつ有能で忠誠心に溢れていることを期待するのは無理がある。如何に流出対策を厳重にしたところで、記憶までは消すことが出来ない。悪用する事が目的なら、故意に脆弱性を仕組んだり、あるいは脆弱性にかかわる部分だけを記憶できれば十分なのだから。

誤ってもインターネットの利用を制限しようなどとは考えないで欲しい。今の時代、全てのリファレンスマニュアルやバグ情報、あるいはサポートなど全てがインターネット経由なのだから。ましてgithubを制限しようものならオープンソースのコード利用が著しく困難になってしまいます。結果的に生産性が落ち、誰も得をしません。

デジタル教科書を紙と併用?あり得ないよね。

デジタル教科書、紙と併用か・全教科か…文科省が5案提示

全児童にパソコンを行き渡らせる事が決定しているが、今更に教科書の電子化を議論しているらしい。電子教科書と紙の教科書を併用させるつもりでいるようだ。結論を言おう。パソコンを持たせるなら、教科書を電子化する以外に選択肢など存在しない。

数年前から登校する児童の荷物の多さが国政の場でも問題視されている(国も動き出した「重すぎるランドセル問題」)。時には体重の50%を超え、中には健康被害を受けている児童までいるというのだから、何故ここまで放置してしまったのか憤りさえ覚える。

健康被害を受けずに習慣的に運ぶことの出来る荷物の量として体重の20%程度が限度と言われている。仮に体重の20%としたときに、小学校低学年女子だと4Kg強程度が限界となる。

・ランドセル 1200g
・水筒(1リットル) 1200g
・パソコン(含むACアダプタ) 1200g
・筆箱 200g
・鉛筆(5本) 25g
・ノート(5冊)750g
これだけでも合計4575g。あっという間に重量オーバーである。

教科書の重量は1冊200~300g。結構重たい。パソコンを持たせたら、教科書を持たせる余裕など、そもそも残らないのだ。

PaaSの請求額に愕然とした経験

たった1日の利用で750万円をGoogleから請求された企業

上記リンク先の企業は750万円の請求を受けたようだが、私自身も似た良いな経験はある。個人的に勉強がてらMicrosoftのAzule MLで遊んでいた。無料枠でリミットがかかるつもりで居たが、突き抜けて十数万円の請求金額が表示されていたのだ。あわててMicrosoftのサポート窓口に連絡して、請求を取り下げていただき事なきを得た。

IaaSやPaaSの使い方を試しながら学習する上で、この手のリスクは常に発生し、避けようがない。実験的に動かす場合にも、本番環境と同様に従量課金で料金が発生する。最初から完璧に習熟していて、絶対に間違えない人など居ない。いくら気をつけていたところで、見落としや設定ミスによる重課金が発生するリスクは常にあるのだ。

うっかり数百万円溶かしても「あほぅ」の一言で済ませてくれる組織でもない限り、実のところエンジニアは業務でPaaSを安心して使えない。「この機能を使えばこんなことが出来るはず・・・」と知識で知っていても、ミスを許容してくれる組織でない限り怖くて新しいことにチャレンジ出来なくなる。

クラウドへの移行を考えている・・あるいは既に実施している企業の役員の方には、この事を知っていて欲しいのだ。

ちなみに、色々と検索した限りでは、速やかに連絡すれば請求を取り下げてくれる事が少なくないようである。

PPAP問題はパスワードをメールで送るのを止めても解決しない

PPAP(パスワード付きZIPファイルと、そのパスワードを別送する)が無意味どころか、むしろ危険を増している事がようやく認識されるにいたった。だが、もう一つの問題、そもそもZIP2.0暗号方式を使って暗号化することの無意味さが知れ渡っていないようだ。

ZIP2.0暗号方式には計算量的脆弱性があり、比較的少ない計算量で総当たり攻撃をおこなえることが知られています。ハイエンドGPU(RTX 2080Ti 価格20万円程度)を4枚搭載したパソコンを使用すれば、15桁のパスワードでも15時間程度で解読できてしまう事が報告されています。ということは文字数を増やして16文字にすれば56日となるかというと、これ以上パスワードの文字数を増やしても解読に変わる時間は延びません。内部的に96bit(15文字程度)の状態しか持てないため、これ以上パスワードを長くしても意味が無いのです。

ZIP形式のファイルはこの問題を解決するために、今ではAES方式暗号に対応しています。ですが、Windowsが標準ではAES方式のZIPファイルに対応していないために、利便性を優先してZIP2.0を使用する事が常態化しています。セキュリティは利便性とのトレードオフになる事が度々ありますが、利便性を優先して実効性のない暗号方式を採用し、そのために無駄な作業や別の危険を増やすのは本末転倒でしょう。

暗号化したファイルのパスワードをメール以外・・・例えば電話で伝えるのは進歩です。でもZIP2.0形式を使い続けるなら、そこに実効性はありません。利便性と実効性を考えたなら、素直に暗号化などせずに添付して送るのが一番良いでしょう。

ではどうすれば良いのでしょうか?私がお勧めするのはメールを使用しない事です。メールの根本的なセキュリティ問題は認証機能が無い事にあります。そこで認証機能のしっかりしているSNSなり、Google Drive等のストレージサービスなりを経由して送るわけです。この時使用するサービスは、出来ればデータを受け取る側に用意して貰うことが重要です。アップロードする場所を指定するやりとりの中で、重要なデータを送る前に相互に認証を行う事ができます。

テレワーク税制が必要だよね

テレワーク手当に新たな問題、JISAは「税金取らないで」と要望

通勤手当が課税取得とならないように求めているらしい。実際に問題となり得るのはそれだけでは済まないので、テレワークを想定した税制改革を早急に進めて欲しい。

テレワークに伴う税制上、法律上の問題には以下のようなものがある。

・標準報酬月額が減る。
年金や産休手当、療養手当などの算出につかわれる標準報酬月額は通勤手当を含む賃金で算出される。したがって通勤手当が減れば、負担額も減るし、給付額も減る事になる。必ずしも損をするわけでは無いが、人生設計への影響は大きい。

・在宅勤務にかかる経費の控除が認められていない。
自宅の労働環境整備に伴う費用負担は本来ならば経費として控除される。自営業者なら家賃や光熱費を事業経費と生活費とに按分して経費控除することが行われている。給与所得者の場合には特定支出控除として通勤費、転居費、研修費、資格取得費、帰宅旅費、図書費、衣服費、交際費について条件を満たした場合に認められている。実勢に家賃や光熱費、通信費を按分して計上したなら、在宅勤務のために年間数十万の経費負担が発生しているはずだが、これらを控除することは認められていない。

・労働環境の整備にかかる経費
労働安全衛生法上、労働環境の整備は事業者の義務となる。PCで作業するにしても作業環境を整える義務が事業者側にあるのだが、では家庭の労働環境の整備の支出を経費控除出来るかというとできず、従業員への給与となってしまう。

・償却資産税の申告先
償却資産税は地方税となっており本来であれば設置場所の自治体(市区町村)に申告する。もし機材が従業員の自宅に設置されているなら、本来ならば従業員の自宅を設置場所として償却資産税の申告を行う必要がある。経理担当者に取っては結構な手間のはずだ。

マイナンバーカードをやめるべき?

暴論のようで一理ある。

今のシステムは希望者のみ数千万人に配布し、希望者のみが活用する事を前提に作られている。人口のほぼ全て1億2千万人に配布して、様々な手続きに活用し、その他の公的証明書類の機能を統合しようとするなら、そこに求められる要件は大幅に異なるものになる。発行時には運転免許証や健康保険証に頼らずに本人確認を行う事を求められるし、再発行に一ヶ月もかかっていては許されないし、様々な場所に端末を置くなら閲覧者の認可システムも見直しだ。

「マイナンバーカードをやめるべきだ」、サイボウズ青野社長がデジタル庁に直言

セキュリティ上、メールサーバーはどんなサービスを利用すべきか。

業務上使用しているメールサーバーのセキュリティについて考慮したことがあるだろうか?実態として問題なく利用できるメールサービスは限られている。

セキュリティ上、パスワード漏洩等のインシデント発生時に被害の程度や範囲を特定する必要がある。このためには最低限でもPOP/IMAP/SMTP/WebMailの認証ログを閲覧し不正な接続の有無や接続元を特定する必要がある。だが実態として認証ログを閲覧出来る事が明記されているメールサービスは少ない。

サービスを提供する事業者は第三者間の電気通信を中継している都合、電気通信事業者とてし法律の制約を受ける。そこには通信の秘密を守る義務が含まれており、通信相手の接続元などの情報を提供することが出来ないためだ。

自社でメールサーバーを運用するのであれば、電気通信事業法上の制約を受けることなくログを閲覧出来る。かといってメールサーバーの運用には多くのノウハウがあり、中小企業でメールサーバーを運用できる技術者を確保する事は難しい。

以下にセキュリティ上の認証ログを閲覧出来るメールサービスを例示しておく。色々と探したのだが、三つしか見つけることが出来なかった。

Google Workspace
Microsoft 365
カゴヤ・ジャパン株式会社 メール専用サーバ

番外として下記も紹介しておく。認証ログを閲覧する事は出来ないが、代わりに接続元IPアドレスを制限する事が出来る。境界型セキュリティで安全を担保する前提であれば、接続元IPアドレスを制限したり、代理サーバーを介在させたりすることで、同様の要件を満たす事はできる。
WebArenaメールホスティング

Active Directory環境でDHCPを使用する。

Active Directory環境でDHCPを使用する場合には、DHCPサーバとADサーバとの間で信頼関係を結び、ADサーバ上のDNSに登録されているクライアントPCのIPアドレスを更新する必要があります。

ADサーバーとの間で認証する都合上、必然的に使用できるDHCPサーバーは限られます。LinuxとSMBを使っても出来るはずですが、実際に構築したという情報も少なく面倒そうです。

DHCP自体は負荷の高いサービスでは無いので、ADサーバーとDHCPサーバーを兼ねるのが良さそうです。各ネットワークセグメントにDHCP Relayサーバーを配置して、中央のADサーバにDHCPの問合せを送ります。

参考:More about authorizing DHCP servers in AD DS