Power Autoamte Desktopを導入

遅ればせながらPower Automate Desktop(以下PAD)を導入。

以前はPowershell + UIAutomation.dllでデスクトップアプリケーションの自動化を行っていた。同じ処理をPADで再実装してみたが、実装にかかる作業時間が1/5程度になっている感じでありがたい。Powershell + UIAutomation.dllで記述したときには画面が表示されるのを待つためのループ処理やディレイ処理が多く遅かったのだが、PADで記述したことでディレイ処理は1箇所のみに減り、大幅に早くなっている。

ただしいくつか気になる点もある。

1.複数のMicrosoftアカウントをWindowsに関連付けていると動作しない。実行時例外が発生して「The cache contains multiple tokens satisfying the requirements. Try to clear token cache.」となってしまう。あまり使わない方のMicrosoftアカウントの連携を解除して解決した。

2.圧縮→ZIPファイルが日本語ファイル名に対応しておらず、文字化けしてしまう。OSSのUnZip(http://infozip.sourceforge.net/UnZip.html)を子プロセスとして呼ぶことで対応した。

3.コードの見にくさ。WEB上のMicrosoft Flowも何度か使ってみた事はあるのだが、一画面に20ステップ程度しか表示出来ないので、やはり複雑な処理は書きにくい。

4.バグを見つけたのでレポートしたいが、お手軽なバグレポートツールが見当たらない。ヘルプ辺りにレポートメニューがあると有り難いのだが。

総じてデスクトップアプリの自動化を行うツールとして、無償でここまで扱いやすいツールは他に無く、とてもよいと思う。だがWEBアプリ操作やファイル処理を行おうとすると、なかなか厳しい。その辺りは適材適所、SeleniumやVBAを併用する事は続きそうだ。

マクロや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。結構重たい。パソコンを持たせたら、教科書を持たせる余裕など、そもそも残らないのだ。