トップ 追記

日々の破片

Subscribe with livedoor Reader
著作一覧

2019-06-18

_ 人はどのように鉄を作ってきたか、読了

Twitterを眺めていたら、誰かのツィットで妙におもしろそうな本だったので買って読んだ。

天下の奇書と呼んで差支えなかろう。

とにもかくにも読了したのはおもしろかったからなのだが、一方、まるで聖書(の旧約聖書で人名がずらずら並ぶあたり)を読んでいるかのような苦行でもあった。

最初は、何しろ鉄の作り方なんて知らないから実に興味深い。高温で溶かすための仕組みや、化学反応で炭素や酸素を取り除いたりする過程がおもしろいのなんのって、おう、こういうものを楽しめるということは、中学高校で習った化学の基礎知識は役に立っているうえに身にもついてるじゃん(といっても、基本、FeとCとOしか出てこないから単純極まりないわけだけど)、とか思わぬ自己発見すらある。

が、1/4くらい読み終わるうちに、世界中の溶鉱炉を訪ね、歴史上の製鉄技術を訪ね、さまざまな鉄の作り方が説明されているうちに大きな疑問が湧いて来る。

砂鉄しか取れない日本、鉄鉱石のうち~成分が多い地方、~成分が多い地方、コークスを発明したイギリス、炉の作り方にも地域特性があるからそれぞれで作り方が異なるのは良いけれど、

羽口前で木炭を燃焼すると、羽口前から上部は酸化雰囲気になり温度が上がった。そこに銑鉄や鋼の小片、あるいは銑鉄の棒の先端を挿入しゆっくり加熱し溶解した。銑鉄は溶け、脱炭しながら炉底のスラグ溜めに滴下した。滴下に応じて銑鉄棒を少しずつ炉に挿入し、木炭を常にいっぱいになるよう装荷した。このとき銑鉄中のシリコンが酸化し、鉄も一部酸化してファイアライト組成のスラグを生成し炉底に流れ落ちる。スラグ溜めには(後略、37%)

みたいな、観察記録が延々と続くのだった。で、確かにどのタイミングで何が起きるか、いつ酸化するか、いつ脱炭するかは、それぞれで微妙に異なるし、燃料や炉の形状によって温度も異なるのだが、言ってしまえば、末尾に;がつくか、ステートメントの切れ目に:がつくかみたいな違いをずーっと文章で説明している。著者もすごいが、編集者もえらいよ、この本は。

そりゃ、そういう本なのだというのはわかるのだが、もうずっとなぜおれはこんな細かい相違点について同じような文章を延々と読んでいるのだろうか? という疑問が離れない。良くできたスクリアビンの音楽のようでもある。窓が違うが出てくる顔はみな同じというやつだ。

が、それが読書の快感でもあるのが不可解極まりない。まさにスクリアビン的だ。

少なくとも小学校高学年か中学生のうちに、本書を読んで、読了後に、反射炉と第3の製鉄方法と、たたら製法の違いについて400字にまとめる能力を身に着けると、すごくよろしかろうとかすら考える。というか、入試問題用の文章としては抜群に良いかも。

たたら製法によって作った鉄は現代式の鉄よりも錆びないメカニズムの説明とかもえらく興味深い。鉄といっても純Feではないので、酸化しかたが異なるからだ。

そして、最後、驚くべきことに電子レンジを使った製鉄が出てくる。そんなことできるの? それができるということが説明される。

アルミナやマグネシアは室温ではほとんどマイクロ波を吸収しないが、1000℃程度の高温になると突然発熱し暴走することがある。マグネタイトや炭材は室温から周波数2.45GHzのマイクロ波をよく吸収し、ヘマタイトは300℃以上で吸収するようになる。そこで、鉄鉱石と炭材の混合粉末にマイクロ波を照射すると、原料自体が効率良く発熱し製鉄ができる。

図19-3に電子レンジを用いた製鉄実験の図を示す。(後略)

で、化石燃料で製鉄するよりも電気のほうが高効率なので、どうすれば製鉄所を電化できるかの考察に向かう。抜群におもしろい。読み進めていて良かった!

人はどのように鉄を作ってきたか 4000年の歴史と製鉄の原理 (ブルーバックス)(永田和宏)

それにしてもこの人が1950年代の中華人民共和国にいたら、土炮炉大作戦が成功して=大躍進に成功して、世界の在り方もずいぶん違っていたかも、とか思わなくもない。

【※CDではありません】ディアギレフへのオマージュ-3/プロコフィエフ:鋼鉄の歩みOp.41,リャードフ:キキモラOp.63,ストラヴィンスキー:3つの舞曲~ペトルーシュカ【中古LP】(I.マルケヴィチ指揮フィルハーモニアo./【仏COLUMBIA】FCX 359)


2019-06-09

_ プッチーニと新海誠

音楽で一番好きなのはプッチーニだが、もちろん演奏家と体調といったものにも左右される。ただ、たとえば蝶々夫人の花嫁行列が立ち現れるところや、トゥランドットでリューが氷の女王の次に歌うバイオリンソロに重ねて歌い始める箇所など、そこのメロディとオーケストレーション、特にオーケストレーションなので音色ということになるのだが、に凄まじい快感があって、それはワーグナーだとジークフリートの最後ハープが上昇してブリュンヒルデが目覚めの挨拶を歌い出す瞬間とかでもそうなのだが(そしてワーグナーの場合は全作品を通して、そこしかない。あとはザンドナーイのフランチェスカの3幕途中の箇所とか北イタリア学派にはそれなりにあるので、おそらく和声進行と音色が特におれにとっては重要なのだろう)、快感としか表現しようがない。カタルシスではない。

で、それ以外の表現芸術ではこの種の快感というのはまったくないのだが(唯一の例外が、とても良くできた飛翔シーン、それも飛び立った瞬間の映画や舞台となるのだが、これまで舞台では野田秀樹で1回だけ、映画でも数えるほどしかない)、今日、新国立劇場で蝶々夫人を観ていて、あれ? 昨日、映画館で同種の快感を味わったぞ、と気づいた。

で、昨日観たのはアラジンだが、確かに飛翔シーンはあり、メンケンの音楽は最高だが、でもアニメほどの快感はなく、あれはなんだったか? と考えて、思い出したが、新海誠の天気の子の予告編なのだった。

新海誠は、まともに観たのは君の名はだけだし、正直まったく絵柄も話も何もかもが好きではないが(ついでだが、アニメの声優のセリフ回しが実に気持ちが悪く耳に不快でたまらんのだが、ジブリの場合は同じような感覚の人が作っているのか、とてもまともに観ていられる)、空に向けてカメラが向けられてそこから光が注ぎ落ちる映像は別格だ。あれはプッチーニと同じくらいの快感で、ということは、天気の子は映画館に観に行くのだろうなぁと思うのだった。


2019-06-08

_ 鬼が口がでっかな間抜けに変わる

かれこれ30年ほど前に、沢島忠という作家主義ではなく、三船敏郎の映画という文脈で新選組を観たのだが、とにかくえらく違和感があった。

この映画では最後の薩摩の有馬藤太(この映画のおかげもあって、唯一おれの中で歴史上好感が持てる薩摩である)との直談判が印象的なのだが、徹頭徹尾、近藤勇の映画なのだ。また三船敏郎が通常の無頼漢風の演技を抑えているのもわかるのだが、この映画を観る限り、新選組とは一にも二にも近藤勇で、やばいのが伊東甲子太郎、良い奴が山南敬助だ。

映画としてははっきり言ってまったく良いところがない、紙芝居をフィルムに無駄に投射したようなものだが、逆に有馬との直談判は絵的に紙芝居がぴったりはまっているので良かったのだろう。鳥羽・伏見の戦いなんか最悪の映画のお手本で、右から「うおー」と攻めて行くと、今度は左から「錦の御旗が立ったぞー」と言いながら逃げて来ておしまいというようなものだった。

という映画のだめさ加減とは関係なく、一にも二にも近藤勇、三四がなくて伊東甲子太郎で五に山南敬助という点に違和感がありまくる。

つまり土方歳三の影の薄さに違和感がすごかった。

新選組 [DVD]

沢島忠の新選組は1969年の映画だが、観たのは多分池袋文芸坐の三船回顧展かなにかで80年代の初めの頃と思う。

その当時のおれにとって新選組についての知識は主に1970年後半以降に読んだマンガからだった。

つまり、望月三起也、和田慎二、そしてみなもと太郎によって、新選組を知ったその目には、沢島忠の新選組は実に奇怪だった。

冗談新選組 風雲児たち外伝〈増補新版〉(みなもと太郎)

(みなもと太郎の新選組も表紙からわかるように、みなもと組の役者で、近藤勇はダヨーン、沖田総司が頭が悪い人で、主役は土方歳三だ。最後、五稜郭から飛び出して戦死するシーンは良く覚えている)

和田慎二では沖田は美少年なのは良いとして、土方が圧倒的に主役で、近藤は気のいいおっさんに過ぎなかった記憶がある。

まあ、不思議なこともあるものだが、三船敏郎っておれさま主義者だから、おれが演じるなら局長、ならば最高なのは局長、当然局長が歴史を回すとかにしたのかなぁで終わりにしていた。

世の中にはおもしろい人がいる。

なぜ、土方が鬼の副長と呼ばれるようになったのかを調べた人がいる。

その、土方歳三がいつの間にか「鬼の副長」と呼ばれていた経緯という自由研究を読んで、ああそうだったのかと得心しまくった。

1964年に司馬遼太郎が、新選組を取り上げて、そこで土方歳三をクローズアップしたのが、変化のきっかけだったのか。

沢島忠の映画は1969年で司馬より後だが、むしろ子母澤寛にそっていたのだとすると話が合う。

一方、上であげたマンガ群は、完全に司馬遼太郎の影響下にあるのだろう。

みなもと太郎がおそらく1971年くらい、望月三起也がもう少し後ではないか(どこかのインタビューで断然土方とか喋っているのを読んだ記憶があるが、司馬遼太郎の新選組の土方、ということに違いない)、和田慎二は80年代になっていたのではなかろうか。浅黄色という言葉を和田慎二のマンガで覚えた記憶は鮮明だが、あまりおもしろいマンガではなかったような。

あさぎ色の伝説 4 (花とゆめCOMICS)(和田 慎二)

(プレミアムつけて売っているやつがいた)


2019-06-07

_ アラジン

アニメのときは妻と二人で観に行ったんだから、何十年も前のことが、こんだ親子そろって観に行くことになって、その間にディズニーはピクサーを取り込んで全然違う映画の世界になっているわけだが、やはり比較してしまうわけだ。

で、オーソンウェルズの市民ケーン風なカメラワークで周縁の語り部の言葉が歌にのって物語の舞台に潜り込むシーンがどえらくうまくて舌を巻きまくる。さあ映画が始まるよというわくわく感は実に見事なものだ。

語り部におちを付けるとか、全体の構造も見事なものだ。

主役は、アニメと同じで口を歪めて出てくるのでなんじゃこりゃと思っていると、周囲からの視線の変化に合わせてだんだんと顔が整っていき、最後は立派な人物になるとかおもしろい。

とにかく魔法の絨毯の映像化が抜群。アニメと同じく単なる絨毯のままでちゃんと感情表現ができていてすごかった。

ジェファーの造形がおもしろく、アニメは見るからに巨悪っぽいのが、こちらは単なるデコ助坊やで、最初の登場であれなんだこれ? と拍子抜けして観ていると、ランプの洞窟のシーンでアラジンに芸を披露して炊きつけるので、ああ、なるほどアラジンのダークサイドなのかと理解する。

この自分は本物ではないと信じるデコ助があり得ない本物の自分になろうとするという点で共通しているので、アラジンは心理的弱点を突けるし、3番目の選択をするというのはきれいな物語だった。

ただ、ジャスミンはデコ助が言うように、あまりにも現実を知らない(商品を獲得するには対価を払うことすら知らないのに、わたしは勉強をしたとか、確かに笑止千万)ので、ちょっとジャスミンに焦点を当てるにしては、元の話との整合性がうまく取れていないなぁとは思った。

逆に、解放されたジーニーが無敵の魔人のまま世界旅行に行くのではなく、人間化するというおちのつけかたもきれいだった。

まあ、こんなものだな。


2019-05-31

_ RPAとは何か? EUCとは何が異なるのか? なぜ誰も知らないのか?

羽生さんのいきいき塾特別編に参加して、羽生さんが見た聞いた実感した「これからはRPAですよ!」を聴講。その後で、酒匂さんやいがぴょんさんと少し討論。

おもしろかった。

RPAが何かは、なんとなく理解していたし、その点では「なんだやっぱりそうだったのね」なわけだが、羽生さんのユーザー環境体験を(UXではなくEUEXと呼んでみよう)聞いて目から鱗ばぼろぼろ落ちまくって足元に溜まりまくって身動きが取れなくなるほどだった。

そこに酒匂さんの懐疑的な見解が出る。

だが、それは違うと直観的にわかった。酒匂さんは、すごい人だが、ことこの点については宇宙飛行士観点でRPAをEUCの延長として捉えているのだ。つまり、エンドユーザーによる局地最適化(部分最適化に輪をかけて悪いレガシーの導入)という観点だ。でも、そういうことではない。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)(バートランド・メイヤー/酒匂 寛)

(酒匂さんといえばメイヤーの訳業だが、地味だが、どう作るかではなく何を作るかをちゃんと考えようよ本は好き)

課題・仕様・設計―不幸なシステム開発を救うシンプルな法則(酒匂 寛)

EUC(エンド・ユーザー・コンピューティング)というのは、普通にイメージすれば良い。

経理のおっさんが、そろばんやら電卓やらで給与計算しているうちに、ふとExcelに着目する。

こいつで計算すれば良いのでは?

そこで、教本片手にExcelの関数を調べ、マクロを調べ、さらにはVBAで入力を簡単にするフォームを作り、それまで3日かけていた給与計算を2時間で終わらせるようにする。やった!

というのが、1995年前後のEUCで、適用分野が変わっても、それから30年たってもEUCはEUCで、全社システムと無関係、または全社システムがそもそも存在しない環境で、コンピューターのエンドユーザーである経理のおっさん(の必要はなくてお姉さんでも少年でもなんでも良いのだが、イメージは経理のおっさんだ)が自力で作ったシステムを指す。

それ自体は正しいコンピューターの使い方なので、どこにも問題はないのだが、問題または軋轢が生じることがある。

今、SIerが自社製品のERPを持ち込む、あるいはSAPなどのパッケージを担いで売り込みに来る。おお、これは素晴らしいと社長が言って導入が決まる。もちろん、現行システムの計算ロジックを踏襲するのだよね? もちろんです!

そして地獄が始まる。

元の経理のおっさんが

・現存するが、非協力的。だって俺様が作ったExcelを排除する気なんだろう?

・すでに定年退職しているので、今いる人たちは何もわからない。とにかくExcelブックを開いて何か入力すると結果が出てくるということしか知らない。

という状態のときに、エンドユーザーならではの

・仕様書がない

ことにSIerは愕然とする。え、これで給与を計算しているんですよね? 仕様書はどこ?

もちろん、仕様書なんかあるわけがない。元の経理のおっさんの頭の中にあり、VBAの中に時にはコメントアウトの固まりで、時にはバグが残ったまま、継ぎ足しと思いつきのテスト無しリファクタリングによる意図不明な関数化やその時その時の気分の変数名やらもろもろがすべてだ。

つまるところ、動いているプログラムは何よりも優れたドキュメントだからどうにかなりそうには見える。VBAはソースコードがそのまま残るし。

しかしおもしろいことに、現行システムの分析は要件定義(要件を現行踏襲で済ませれば、現行機能からの基本設計起こしでも別に構わんが)の範疇なので、いわゆる上流SEの作業となるわけだ。

もちろん、上流SEはプログラムを読めない。

いや、3か月ほどJavaの研修は受けたかも知れない。でも、VBAは読めない。

そうはいってもVBの文法は単純なのでどうにか読めはするだろう。しかしExcelのオブジェクトモデルは知らない。それでもMSDNを調べてオブジェクトモデルを理解したとする。でも、型がない。イベントドリブンによるプログラム構成を理解できない、Excel関数なにそれ?

まあ、能力不足なわけだが、そうは言っても予想もしていなかった、工数が必要となる。当然、プロジェクトの進捗に支障が出る。しかも経理のおっさんだけならまだしも、営業の部長かなにかが暇に飽かせてこしらえた営業支援システムが営業2部にはあり、営業1部には、独自に導入して何かどこかで設定を間違えたのを運用でカバーしているパッケージ(今、SIerが導入しているものとは縁もゆかりもない)が勝手に動いている……絶望だ!

というわけで、利害関係がある連中(ERP系SIer、パッケージ業者)が声高に排斥するのがEUCということだ。

でも、RPAは全然違う。

EUCとの共通点は、現場で作って現場で運用しているという、ただその1点だ。

本質がまったく異なる。

EUCは、それそものもがシステムだ。しかし、RPAは、それはシステムではなく逆にエンドユーザーの作業でしかない。エンドユーザーのPC上のエージェントとなって、代理するだけなので、正しくロボット(機械労働者、当然、どこにも頭脳(システム)は存在しない)なのだった。

だから、端的に言えば、RPAはエンドユーザーにとってはブラックボックスではなく(この比喩で言うと、EUCはエンドユーザーが自分で作ったブラックボックスである)、エンドユーザーが正しくコンピュータを利用するための初めて目にするツール(いや、当然なのだが、エンドユーザーには「ツール」という概念がそもそも存在しない)なのだ。

コンピュータは、人間の能力を解放するわけで、それはシステムにからんでいれば普通のことだが、エンドユーザーにとってはそうではなく、それは上から押しつけられた新たな労働(作業)で、そこに対してボタンを押したりキーを押したり、デバイスから何かを読み込ませる、ことで賃金がもらえる何かの機械でしかない。

でもRPAによって、コンピューターを利用できるようになったのだ。

これは大いなる意識改革だし、すごいことだ。

そういうことだったのか!

(RPAの本質はつまり、エンドユーザーがコンピューティングを獲得するための手段であり、システムを自分事として理解するための取っ掛かりで、これがあって、初めてなるほどコンピューターというのは便利なものですな、と発見することなのだが、では具体的に……となる前に疲れたのでとりあえずここまで)

_ RPAとは何か? EUCとは何が異なるのか? なぜ誰も知らないのか?(続き)

RPAは、スクリーンスクラッチャー(今作った言葉)だ。やれることは、PCの画面の上を引っ掻いて回ることだけだ。どこにもインテリジェンスがない。

たとえばSeleniumを知っていれば話が早いし、Win32APIを知っていれば、GetWindowHandleしてSetFocusして、SendInputするプログラムをエンドユーザーがお絵かきツール(というよりも、eToyを想像すると良いかも知れない)で作ると考えれば良い。

つまり、人間の操作の自動化である。

羽生さんは、UIPathでメモ帳を起動して文章を入力して名前をつけてファイルに保存するデモを見せてくれたが、重要なのは何をするかではなく、それがお絵かきツールで作れるということだ。

これは明らかにEUCではない。

なぜなら、こうやって作られたRPAの成果物(以降、スクリプトと呼ぶが、もちろん、PythonやRubyで作るプログラムを想像してはならない。せいぜい、パイプを使う#!/bin/shスクリプト程度だ)には、どこにもビジネスロジックがないし、データもない。あるのは、ユーザーオペレーションを再現するためのスクリプトだけだ。それは、まともなシステムであれば、マニュアルに記載されている。したがって、レガシーにすらなりようがない。

想像するに、RPA作りにはそれなりのノウハウは必要だ。だが、それは一般化できない現場オリエンテッドなものなので継承する必要すらないものだろう。

たとえば、メモ帳でファイルを名前をつけて保存をすることを考える。

Alt-Fに続いてAを送る。ここまではOKだろう。

しかし次の一手としてファイル名を入力したり、文字コードを選択するには、モーダルダイアログのオープンを待つ必要がある。それが1秒か3秒か0.5秒かは、利用しているマシンのスペックに依存する。

そこで、たまたまsleep(1)で、動いてるからといって来月もそれでいけるかどうかは誰にも保証できない。仕込まれているウィルス検索機のダイアログオープン時の処理が重くなるかも知れないし、Windows Updateでメモ帳のダイアログの形式が変わるかも知れない。

でも、大丈夫。もしエラーになったら、作り直せば良い。そのためのRPA IDEだ。テストくらいはするだろうが、リリース管理もバージョン管理も必要ない。なぜなら、上で書いたタイミング調整のようなものはビジネスロジックではなく、単なる運用上の差異だからだ。

RPAは単に人間の操作を再生するだけのスクリプトだから、スクリプトが失われても何もビジネスは失わない(3秒のボタン操作が、30分の人間操作に戻るので、時間は失うかもしれないが、EUCの仕様のなさとは次元がまったく異なる)。

・歴史(メモがないので数字の正確性はあやしい)

羽生さんの調査によれば、RPAの歴史はものすごくいびつだ。

まず、ガートナーのハイブ曲線についていえば、2016~2018の間にグローバルでは一切存在しない。

日本固有のハイブ曲線についていうと、2017年にいきなり頂上にあり、2018年に安定の少し下がった位置につく。

日本固有のものか? でも、上にリンクを張ったUIPathをはじめ、海外製のRPAツール(スクリプトを作成するためのIDE)がそれなりの数が出ている。日本だけでビジネスできるわけがない。したがって、動いている金額はグローバルでもそれなりのはずだ。

でも、もちろん、ガートナーのグローバルハイブ曲線は、われわれの感覚に近い。

つまり、RPAをシステム屋やソフトウェアは知らない。それがどこにあり、だれが買っているのか。

それは知らないうちに、ユーザー部門に入り込んでいるのだ。

でも、それをEUCの同類とみなして排斥するのは、愚かだ。

なぜならば、それはEUCとは異なるからだ。つまり、ビジネスとデータが存在しない。

なぜ、ガートナーのハイブ曲線ではトレンドとしてつかめないのか? たまたま日本では、三菱UFJ銀行の事例が大きく取り上げられたからではないか、というのが羽生さんの見解だ。

もしそれがなければ、ユーザー部門主導(ベンダー主導でもなければ、プラットフォーマー主導でもなく、もちろんコミュニティ主導でも、技術主導でも、研究主導でもなければ、まあ目に入るはずないね。でも、その視野の狭さは我が事ながらおもしろい)で知らないうちに広範に利用されている実態がIT業界に見える化されることはなかったのだろう。したがって、グローバルなハイブ曲線には影も形も現れない。

次に、ProsとConsについて考える。

おれは基本的にConsは存在しないと考えている。

逆に、すべてを徹底的に管理したい人にとってはConsしかないだろう。たかがスクラッチャーなスクリプトとは言えソフトウェアである限り、バージョン管理、リリース管理、仕様書、QAが必要だと信じ込んでいればそりゃそうだ。ビジネスロジックはなくても、ビジネスのコンテキストで実行することに変わりはないわけだし。そもそもおれの目の届かないところで勝手にソフトウェアをインストールするんじゃねぇ、それはコンプライアンスに反しますると大騒ぎする連中もいるだろう。

したがって、三菱UFJ銀行の事例のように経営主導で導入すべきものではあるだろう。

だが、そこにはおれは興味はない。そうではなく、ユーザーの意識に与える自由が重要だと考えているからだ。

つまりProsは、ユーザーとビジネスで利用するコンピュータの関係の正常化にあるとおれは考える。

まず、ユースケースについて考える必要がある。

本来、システム間の連携はシステムで行うものだ。

しかし、そこに人間の介在が必要となるニッチが存在する。RPAはシステム化できなかったニッチを埋めるものだ。

たとえば、タイムカードの入力という簡単な処理を考えてみる。

従来は、事業所の入り口にあるマシンに退出側の箱から自分のカードを取り出して、マシンに通して打刻して、出勤側の箱に入れていたとする。それにしても何十年前のシステムなんだというのはおいておいて、そういうものだったとする。

システム化したから、もうカードと打刻機は不要となり、オフィスの机の前に腰かけて、PCの電源を入れて、デスクトップ上のショートカットをクリックしてIE11(Windows10になってよかったね。でもEdgeじゃなかったりして)を起動して、打刻ボタンを押して、もう使わないし、残しておくとメモリを食って次の作業の邪魔になるのでIEをクローズする。

まあ、この程度であれば、RPAも必要ないだろう。

しかし、すべての事業所がイントラネットで結ばれているわけではないものとしよう。さすがに東京と大阪の間には太い専用線を前世紀から利用しているので、大阪事業所の人たちも東京本社の打刻用Webサーバーにアクセスできることになっているとする。

でも、四国や九州の事業所ではそうはいかない。よくわからないがセキュリティが危ないので、東京本社の打刻用Webサーバーにはこれらの事業所からはリーチできない。VPN何それ?

というわけで、四国や九州の人たちは、代わりに出退勤をExcelに記録して、月末に本社の人事に各自メールに添付して送るというばかげた運用となった。まあ、送る人たちには我慢してもらうとして、本社の人事の人たちはどうするの?

幸い本社のWebサーバーにはExcelアップロードボタンがあって、ボタンを押すと、該当Excelの送り主の社員コードを入力し、事業所をドロップダウンリストから選択して、ボタンを押してExcelを選択して(ということは、メールの添付ファイルを一度ディスクに保存する必要もあるってわけだ)、そして送信ボタンを押すと、ダイアログがポップアップして、~事業所の社員コード~のExcelブック~をアップロードしますか? OK/キャンセルが表示される。そんなことは言われんでも今入力したじゃないか、くそばかシステムのばーかばーかと思いながら、確認しないでOKをクリックする。ふー、一息ついてメールボックスを見るとあと138人分残っている。

なんか、前のシステムのほうが楽だったなぁ。で、一日つぶれる。明日の営業研修用の資料をこれからまとめなきゃならないのに、なんてこった! 残業だよ、とは言っても、水曜日だから残業はないってことで(と、Webサーバーに本社勤務だから退勤ボタンをクリックしてから)資料作りを始める。(運が良ければ、各事業所内の所長が確認したこととして、所長からの1つのメールに全員分のブックが添付されているかも知れないが、そのメールを開くのは地獄の刑罰なみに時間がかかるだろうなぁ)

本来であれば、全事業所が仮想的であろうがそうでなかろうが、同じネットワークの中で利用すべきものが、予算の関係でそうなっていないような場合に、上記のような異常事態が生じる。

幸い北海道事業所は主要な取引先が多いので、前世紀から専用線が引かれている。32Kbpsだぜ。というわけで、タイムカードの打刻に20分かかる。そもそもマシンも前世紀に導入された512MBのP3マシンだ。OSの起動に5分、IEの起動に5分かかるからそりゃそうだ。おれの貴重な朝の20分の間にさっさと客先に行きたいのだが、たかが4回クリックするだけのためになぜ、これだけ無駄な時間を使わなければならんのか。これどうにかならんのか?

こういった状況に対してRPAが提供されれば、そりゃ救世主でしかない。

スクリプト実行ボタンをクリックすると、Outlookを開き、件名に【タイムカード】が入ったメールを開き、添付ファイルを保存する。保存した添付ファイルをエクスプローラで開いて、2番目のセルから社員コード、3番目のセルから事業所名を取りだす。(Excelブック内に入っているのに、アップロード時のダイアログに入力させることで確認しようという素晴らしいシステムなのだな)、デスクトップ上のショートカットをダブルクリックしてIEでアップロードページを開く。その前にログインページだ。ユーザーの社員コードとパスワードはスクリプト内に入っていて自動入力されてOKがクリックされる。アップロードページに遷移するまで10秒(長すぎるけどまあいいや。短いとエラーになるし)待って、Excelブックから取得した社員コードを入れて、タブキーを送って、事業所を選択して、タブキーを送って、クリックを送って5秒待ってファイル名を入れて、OKをクリックして、3秒待って次のポップアップのOKをクリックして1分待つ。IEのXボタンを押して終了して(というように、作ってしまうところがエンドユーザーならではだし、多少工夫して2度目のループからこの処理をスキップするように作る人もいるかもしれないが、どうでも良い)、ExcelのXをクローズして、保存しますかにNoをクリックして、Explorerで開いてある添付ファイルを選択、右クリック、削除、OK、Outlookに戻って次の【タイムカード】を選択……というのをPRA用マシン(これだけは新規に導入)に実行させておいて、自分の本来の作業に取り掛かる。その間5分。

もしかすると、ふとRPA用マシンを見ると、Excelが開かれたままになっていて、3個しか送れていないかもしれない。RPAにはインテリジェンスはないから、タイミングによってそりゃ起きる。でも、問題なし。Excelを終わらせてやって、状態を整えて、再実行すればよい。いずれにしても、このくらいの手間で済むなら大した問題じゃないね。

同じように北海道の人も、PCの電源を入れて、客先訪問の準備をしている間にマシンが立ち上がる。ボタンを押して、あとの処理よろしく! と出かける。あとはRPAが勝手にやっておいてくれる。

ここで観点は3個ある。

経営者観点からは、RPA用の金(専用マシン含む)、スクリプト作成のための作業時間を許容すること、がコストだが、VPNとかよくわからないものやセキュリティリスクがどうたらみたいなよくわからない話で積みあがる全社ネットワーク接続に必要なコストを無視できるだけで、それ以上でもそれ以下でもない。実際、なくても、サービス残業でどうにかしてくれるわけで、知ったことではない。(もしかすると、人事が地方から送られてくるExcelタイムカードをさばくために雇っていたアルバイト3人が不要となる可能性は高い)

システム部にとっては、ちょっと怖い。特に、なんだかよくわからないスクリプト内にタイムカードアップロード権限を持つユーザーIDとパスワードが平文で入れられるところとか恐怖だ。(が、実は、担当者の不在時に誰でもタイムカードをアップロードできるように、PCにはユーザーIDとパスワードを書いた付箋紙が貼られている実態を知っているので、要はシステムの結合が不完全なのだからしょうがないとわかっている上司が黙認しているので自分も黙っている)というか、ちゃんと期限内にデータがアップロードされていればどうでも良いというのが本音だ。

ユーザーにとってはどうだろうか? 間違いなく楽になったので、それははProsだが、重要なのはおそらくそこではない。

そうではなく、RPA導入前には延々と決まりきった作業を繰り返させられていたのが、言い換えるとコンピュータ(というかシステム部が勝手に導入したなんだかわけのわからない勤怠システム)のために自分が奴隷のような作業をしていたのが、RPAツールを使って自らスクリプトを作ってそれを実行するようにしたことで、言い換えると自分が本来すべき処理をコンピュータが自動的に実行するようにすることで、コンピュータとユーザーの関係を180度転回したことにある。

これがEUCではないのは、システムそのものは何も変わっていないことから明らかだ。

では何かと言えば、ユーザーの作業の素朴な自動化に過ぎないわけだが、明らかにコンピュータとユーザーの関係が、主人と奴隷から、奴隷と主人に逆転している。

これはすごい。

システム的には、くだらないとは思う。まず、システム化が中途半端だし、インフラがそもそも不足しているのが問題だ。UXもよろしくない(大体Excelシート内の情報をわざわざアップロード時に入力させたり確認させたりすることがばかげている。そんなもの形骸化するのは自明過ぎる)。この運用(厳密なユーザー権限による運用が不可能という前提)であれば、アップロード処理はユーザーID/パスワードよりも、端末のアドレス縛りのほうがまだましだ。

いずれにしても、RPAのユースケースは上記のような、システムのニッチを埋めるために必要となる手作業の自動化にある。

このような手作業が必要となる主要因は2つある。

1つはシステム部の怠慢によるインターフェイスの設計ミスだ。しかし、その事情としてインフラにかけられる予算があるとすれば、次の原因と結びつく。

より重要な要因は、雇用形態にある。

終身雇用を前提とする賃金体系のもとでは、労働者に対する労働時間の増加は、勘定外として無視される。つまりシステムの不備による10分の作業量の増加は経営側からはないものとして処理されるということだ(人件費という一括りなうえに生涯で幾らという計算となるため、時間給的な発想とはならない。問題は、その発想のまま外部委託したりする点にもある)。付け加えると、これは、なぜ開発者に貧弱なマシンを与えるのか問題と軌を一にする。環境の問題で作業時間が伸びることによる非効率(生産性の低下といっても良い)は、労働者の問題であり、経営側の問題ではないと考えているからだ。少なくとも人件費(ここに職能に払っているのではなく、頭数に対して払っているという感覚があるわけだ)は織り込み済みだが、資産(たとえばコンピュータ)の導入は問題外となる。

したがって、現場における非効率的な作業の増大は企業システムとしては無視されることになる。

この発想のままなので、結果的にRPAは人減らしのためのツールとして導入されることになるわけだが、その一方で、すでにみたように、奴隷労働を主人労働に転換するものでもある。

少なくとも、同じ作業を繰り返すばかばかしさの解消、それを自力で成し遂げること、つまりコンピュータを入力作業のための奴隷労働の対象から、自分の力でコンピュータを奴隷として扱うようにするためのツール、それがRPAの価値だ。

それが可能となったのは、開発者の手作業によるテストから開発者が開発する自動化テストというテストに対する考え方の変化と、それに伴うOS操作のためのテストツールの充実と、プラットフォームとして利用できるIDEの出現と進展にあるというのが、おれにはとてもおもしろく感じる。

システムを作る側が楽をするためのツールの進展によって、システムを使う側が楽をするためのツールが出現して同じく楽になり、コンピュータが作る側からも利用する側からも道具となる、実に気分が良い。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|

ジェズイットを見習え