日々の破片

_ 魂のゆくえ

ユナイテッドシネマ豊洲でポールシュレイダーの魂のゆくえ。

ポールシュレイダーは、僕にとっては何よりもハードコアの夜の作家なのだが、後期アメリカン・ニューシネマの作家という位置づけになる。

アメリカン・ニューシネマの末期に中学生だったので相当観たし、その時点での印象なので映画史的な事実とは異なるのかも知れないが、僕にとっては、集団戦が、2人の旅になり、末期には1人になる過程のように感じた。

したがってスケアクロウや真夜中のカウボーイで相棒との別離があって（明日に向かって撃てはちょっと印象が異なる）、人間ではなくネコが道連れとなって（ハリーとトント、アリスの恋は息子だが同格ではないからな）、そしてたった一人のタクシードライバーと、親父の娘探し（ふと気づいたが、これは捜索者だったのだな）のハードコアの夜で終わる。

ハード・コアの夜 [DVD](ジョージ・C・スコット)

もっとも、ハードコアの夜を観たのはそれよりも遥か後で、妻と僕の間にジョージCスコットのブームが吹き荒れたときだった。チェンジリングか炎の少女チャーリーがトリガーになったのだと思うが、その一環で観たのだった。

で、魂のゆくえがいきなりやって来たので観に行ったのだが、悪くはなかったがさほど感心もしなかった。

最初から最後に向かって、だんだん1シーンあたりの時間を短くしていくことで緊迫感を上げるとか、構図の良さとか技術的な点ばかり目立つように思う。それなりに余分なセリフ無しで、主人公がゴミを捨てると、そのゴミをオルガン弾きが見てしまい、それからしばらくして唐突に上司からの酒の飲み過ぎへの忠告になるとか続けているのだが（したがって、ストーリーを構成するには映像を正しく見ていないと追いつかない）、雰囲気を作る映像の多さが退屈ではある。でもまあ、説明ばかりをぺらぺらしまくる映画に比べればよほど映画ではあった。

話は、ほぼタクシードライバーと同じで、戦争の後遺症（こちらは息子をイラクで亡くして、妻に逃げられる）による苦悩という個人的事情が(それだけでは不足とばかりに胃癌による死の宣告に対する恐怖がないわけでもない)、ふとしたことでのめり込んだ公害企業に対する義憤から自爆テロへ向けて暴走し始めるが、偶然のタイミングで計画を中止するのだが、タクシードライバーが孤独な運転手に戻って何かのトリガーで再び狂気に走りそうなまま終わるのに対して、愛を見つけてぐるぐる回る大団円でうんざり、というのが違う。

ハードコアの夜と同じテーマとも言えなくもない。唐突な不幸に見舞われていろいろ調べて行くうちに現代社会の闇を見つけてしまい、狂気にとらわれていく。ハードコアの夜は一応は娘を取り戻して大団円っぽいが、多分、娘は再び家出するだろうし、今度はジョージCスコットはもっとやばい世界に入って行きそうで暗澹たる終わりだったので、そちらに近いかも知れない？ いや、イーサンホークは自分を律することにしたので、それは違うだろう。が、胃癌なのは間違いなさそうだ。何も解決になっていないという点で終わらせることに関しては何も変わっていない。

ピンクの薬が溶け込むシーンと、自殺しようとしてグリセリンが何かを飲もうとするところとか、液体の気持ち悪さの映像が妙にスタイリッシュで退屈さに輪をかけなければまだ良かったのだが。

それにしても、ドライヤーは別格だな。いや、ポールシュレイダーが凡庸なだけなのかも。

むしろ終わった後の妻と子供の会話のほうがおもしろかった。

「それにしてもイーサンホークはいい男」

「おっさんじゃん」

「でもいい男じゃない？」

「おっさんじゃん」　←　年齢フィルタリングがハイプライオリティ

……

「それにしても話題になってもいないのに、それなりに混んでいたけど、ポールシュレイダーには根強い人気があるのね」

「イーサンホークがいい男だから観に来たんじゃない？」

「どうして？」

「自分で言ってたじゃん。来てたのおばさんばかりだし」

_ WTF経済

読了したのでメモ。

4部構成。

全体としては一貫した主張をするためのエッセー。未来予測という確立させようがない分野に対してそれなりに成功しているオライリーという人の考え方を示し、どう未来がなりそうなのか、そのためにはどうしなければならないか（日本憲法と同じく、良いものを守るには不断の努力が大切というやつだ）を考えたもの。

結論としては、パーソナライズされたタイムスケジュールと人類の生産能力の向上によって働き方や政府のあり方も変えられるし、その方向に進んでいるように見える。とはいえ、いくらでも悪くすることはできるので、皆さん、人類全体の福祉という観点から行動を律しようよ、という内容。

第1部は、オライリーがオライリーであるためにどういう機会にどう考えてどう行動したかという内容。こうであろうというマップ（鳥瞰）がなければ正しく考えることはできないが、一方実際はこうであるという現実を正しくフィードバックさせないと間違えてしまうから注意ということ。

ここではUberの経営者がどれだけひどいやつかとは無関係に、こうであって欲しいという願望と、こうできるという技術的確信と、中産階級の激減（貧困層の増加）という社会的背景がからみあって、リアルタイムなオンデマンド雇用という新しいジャンルが生まれたことを示す。

第2部は、プラットフォームについて。一体プラットフォームとは何なのか、どういう経緯で生まれて、どういうことができるのか。

第3部は、社会のあり方について。ミルドン・フリーマンは善意からだろうが、誤った方向に社会を導いた。

第4部は、未来はどうあるべきか。端的には、生産性の向上をどう配分するかということ。

19世紀イギリスでは15時間労働が当たり前だったが、それを12時間に減らすなんてあり得ないと資本家たちは言った。12時間労働になると、それを8時間に減らすなんてあり得ないと資本家たちは言った。

植民地から収奪した（実際の流れは、本国で生産した材を植民地へ送り、そこから対価を得ることで、国内へ還流して経済発展をしたのだから、わざわざ政治的に支配しなくとも市場を正しく組み込むだけで良いと了解できた1950年以降は植民地をわざわざ経営するという愚かな政策は負の遺産を漸次解消する必要があったポルトガルくらいでしか残らなかった。

結局のところは、公正な方向のほうが、全世界が富むことになったし、、それによって世界中が医療を甘受できるようになったことで、さらに全体が好ましい状態になりつつある（ファクトフルネスだ）。

フリードマンの方向は、努力した人が報いられるといえば聞こえは良いが、実際には大多数の人が取り残される状況を作ることになった。これでは局所最適化の罠から逃れられていない。全体最適化したほうが結局はうまく世界が回るというのは明らかだ。技術とビジネスを全体に奉仕させる方向で考えた方が得だ。

WTF経済 ―絶望または驚異の未来と我々の選択(Tim O'Reilly)

_ フルートと現代（近代）音楽

子供に誘われて杉並公会堂でオパキャマラードの演奏会。

カレッザという作曲家の作品がおもしろい。旋法がドビュッシーかラヴェルのようで、印象派の未知の作家だなと思っていると無調になったりする。様式としては20年代（と書くと、すでに2020の可能性があるのか）っぽい。

おもしろい。最初は3回わかりやすいメロディーが出てくるロンドのようなソナタのような微妙なやつで、第2主題というよりも、ロンドのつなぎの部分と感じたわけだが、は、無調になる。長いパウゼの後にアタッカ(なんとなく、本来はパウゼ無しに続くように感じたのだが、実際には、ちゃんと分離しているのかも知れない)で2部目が始まると速度が上がって遠くへ進んでいく。ちょっとスクリアビンの4番のような組み合わせだなとか感じるのだが、相当好きだ。

次に、アルトフルートの全音域を使うという説明が最初にあってから、マウアーという人のソネット。まあソネットという楽式があるわけではないので、セレナータみたいなものか？ と思いながら聴いていると、ジャージーで、もしフルートではなくサックスだったら普通にトムスコットあたりの曲のように感じる。夜は夜でもマンハッタンの夜だな。これも悪くないというか、おもしろい。

休憩時間に、スマホをいじっていたら、隣の腰掛けている二人組の会話が聞こえてきた。

年配のほうが、なんで誰も知らない現代音楽とかで、モーツァルトとかをやらないんだ？ と若いほうに言っている（再構成している）。

すると若いほうが、うーん、誰も知らないといっても、音大で管楽器やったら、普通だからなぁ。と答えた。

っていうのは、課題曲にしても授業でやる曲にしても、当たり前だけど、その楽器の技術を学ぶわけじゃないですか。実質金管のフルートが発明されたのは1858年（だと思うが聞き違い、覚え違いの可能性はある）だから、その技術を駆使する曲といえば、当然それよりも後になるし、その意味ではヴァイオリンやピアノとは違いますよ。

もちろんモーツァルトのフルート協奏曲みたいなものはあるけど、あのフルートはいまのフルートではないし、演奏して技術的におもしろいわけでもないからなぁ。フルートを聴かせるとしたら、良い選曲と思います。

なるほどなぁ、と年配者が納得するのと同じく、おれも納得した。

そういえばバスフルートのやつでも、ユーフォニアムの曲として聞いたこともない作曲家の曲をやっていたけど、同じことなのだろう。

すると、もしかして、ベートーヴェンの時代、あるいは後になってリストの時代には、なんであいつは、自作の妙な曲ばかり演奏するんだ？ ハイドンやモーツァルトが聴きたいのにな。とか言い出すやつがいて、それに対していやいやピアノフォルテの音を生かし切るには、今の作品が必要なんですよ。だって、こないだ改良されたんだから、とかいうような会話があったのかも知れない。

おもしろかった。

_ ラピスラズリ

山尾悠子のラピスラズリ読了。

なんかKindle版の安売りしていたから、買って読んだのだった。

といっても、山尾悠子の作品はこれが初回だ。なんとなくだが、多分名前の悠の字のせいで尾崎翠の現代版なのかなとか考えていたが（全然字面は似ていないが、おれには同じカテゴリの字に見える）、大きくは違わなかったが、全然違った。

むしろ読んでいる間は、相当、中井英夫の悪夢の骨牌などの擬ヨーロッパ文学臭を感じていた。あるいは、森川久美だ。

青色廃園(傑作集) (花とゆめCOMICS)(森川 久美)

1980年前後の花とゆめやそれより少しあとのプチフラワーの世界に少し通じるものがある。現実との折り合いの悪さという主観が終末の予兆という客観に至る物語だ。

もっとも、文学なので構造はより複雑で奔放だ。特に今語っている時点からの未来をどんどん予見していく前のめりにつんのめっていくような不思議な語り口の独特さがおもしろい。時間の行き来によりある人物が異なる人物と重なり、ついには国までまたがってしまい、近未来のようでありながら、いきなり16世紀に引き戻される。

それにしてもアッシジの聖フランチェスコの登場で、リストやロッセリーニのような感覚に相通じるものがあるようにさえ思った。

ラピスラズリ (ちくま文庫)(山尾悠子)

聖フランチェスコには思い出がある。神保町というよりも小川町のあたりの洋食屋から出たら、近所の2階の和風の窓の格子に半身をもたらせながら伸ばした片手で1階の屋根に集まった鳥にえさをやっている浴衣の青年がいて、ああ、あれは聖フランチェスコなのだなとその一瞬、世界の様相ががらっと変わったのだった。

_ PIXAR <ピクサー> 世界一のアニメーション企業の今まで語られなかったお金の話 読了

クーリエジャポンの紹介記事というか抜粋が抜群におもしろかったので、PIXAR <ピクサー> 世界一のアニメーション企業の今まで語られなかったお金の話を買った読んだ。

最後の3章くらいのああ西海岸の70年代文化圏の人なんだね、という箇所を除けば（いや、ここも含めても良いのかな。それにしてもボームのホロニズムがいきなり出てくるのには驚いたが、西海岸だなぁ）抜群におもしろかった。翻訳もうまいね、と思ったらベゾスやウォズニャックの本でさんざん読んできた人だった。

ジョブズの友人のローレンスはジョブズからピクサーの財務責任者になってくれと電話を受ける。シリコンバレー風の企業弁護士からキャリアを開始しているローレンスにはピクサーというのは全くの興味の埒外だし、オフィスは石油タンクの前のぱっとしないうえにゴールデンブリッジの向こう側だし、しかも業態もこれまで扱ったこともないエンターテインメント圏の企業ということでしり込みする。

が、実際にピクサーが製作中のトイストーリーの冒頭を観させられて感銘を受けて、結局引き受けることにする。

いっぽう毎月数100万ドル（億円だ）が回収のあてなく単に出て行くピクサーにジョブズはいらいらしている。さすがにマネタイズできないと持たない。ネクストもだめ、全然だめな状態で落ち着かない。1994年頃のことだ。しかも投資額がでかすぎるのでピクサーの従業員にストックオプションを渡してもいない。いっぽうピクサーの従業員は一生懸命に未来のアニメを作るのだと頑張っているが、ストックオプションがもらえていないので金銭的には不満の固まりでもある。落としどころを探すのもローレンスの仕事だ。

この本が抜群におもしろいのは、テクノロジーでもアニメでもなく、マネタイズと契約が主眼な点にある。しかも、バックグラウンドに、テクノロジーとアニメとディズニーがある。興味の種が尽きない。とにかく、落としどころをどう設定するか、そこへ向けてどう回りを巻き込むか、仕組みの設計と実装の話なのでおもしろいことこの上ない。

もちろん、IPOが成功し、トイストーリーは大成功、ジョブズはビリオネアになり、その後のすべての作品がほぼ大成功、ピクサーの残念な話はジョンラセターの失墜くらい（というのは現在の話で、本書の範囲ではない）だ。

そのジョンラセターは主役側ではないが、2回、目立つ登場をする。

1つは、ピクサーというブランドをディズニーに認めさせるかどうか（その条件によって、ディズニーとの不平等条約を解消できるかどうかという論点）で、あっさりとブランドを守るという側に立ち、ジョブズも賛同する。

もう1つは、クリエイティブへの投資判断を誰がするかという株式が公開された企業でのどうやらきわめて重要な論点で、おれたちのチームに決まってるじゃんと（映画業界的には）あり得ない選択肢を提示するところ。

本人が書いているからある意味当然なんだろうが、とにかく著者のローレンスがえらくいいやつで、いいやつなだけに、出てくる人間すべてが魅力的に描かれている（裏側でえらくやっかいなことがアイズナーとジョブズの間で繰り広げられたことが後になって触れたりはしているが、登場するシーンでは、全員、みんな魅力的ないい奴ばかり）ことで、このあたりも読んでいて気分良いのかも知れない。

あーおもしろかった。

PIXAR <ピクサー> 世界一のアニメーション企業の今まで語られなかったお金の話(ローレンス・レビー)

アニメとマネタイズというのは実は物語的に相性が良いのか、映像研とか銭（最初の章）とか、おもしろいものが多い印象を受ける。

映像研には手を出すな！（４） (ビッグコミックス)(大童澄瞳)

銭 壱巻 (ビームコミックス)(鈴木 みそ)

_ ハムレット

シアター・コクーンでハムレット。

シェークスピアは本ではがんがん読んでいるが、舞台で見たことない（オペラならオテロだろうがファルスタッフだろうが観ているけど、演劇とオペラは異なるから範囲外）ので子供に誘われてハムレットを観に行った（蜷川のを観たような記憶もあるが、思い出せないので多分観てない）。

というか、演劇を観るのって相当前に三〇〇を観たのが最後で数十年ぶりではなかろうか。

抜群におもしろかった。シェークスピアだからつまらないわけがないのだが、それにしても良い舞台だった。

ハムレットはハムレットだからどうでも良いかなぁと事前の情報をまったく調べずに観始めたのだが、舞台は1940年あたりに設定してあって、いきなり国境警備兵の交代のシーン、スーツを着たホーレショと続く。ホーレショ、良い役者だな。

ハムレットも良い。最初、どうもこういう演技を観たことがあるという既視感にとらわれまくったが（そして思い出せないのだが）悪くない。ときどきセリフを度忘れしたようなそういう言葉につまる演出のような、でも思わず照れ笑いしてやはり度忘れかも、という感じなのだが、そういった所作含めてハムレットっぽくて実に好感が持てる。岡田将生という人。

舞台でのセリフ回しという点ではガートルードの人が圧倒的。

だが、なんか突っ立っているだけでえらく存在感があって、フォーティンプラスの人がえらく気に入る。確かにあの姿を観たら、ハムレットならずとも、国はあいつにやる、と言わざるを得ないのではなかろうか。

それにしても、おれが読んだことがあるどのハムレットとも違う……と途中まで思っていたのだが、（小田嶋は少なくとも読んだような記憶がある）、もしかしたら完全に読んだのはみなもと太郎だけではないかという疑惑が渦を巻く。そうでなければ、フォーティンプラスのことがまったく記憶から抜けている理由がつかない。

それにしても、みなもと太郎版のできは抜群だったようだ（もし、本当に戯曲そのものを読んだことがないのだとしたら）。原作から改変しているのは、亡霊が本当に父親でクローディアスの件は本当に暗殺の陰謀だったのか、それとも亡霊は悪魔で父親のふりをして対立させることで国を破滅させようとしているのか、というすべてに懐疑的な原作にはあるらしきハムレットらしい悩みがまったくないことと、フォーティンプラス、そして多分、クローディアスの2人の子分をハムレット自身の陰謀で葬り去るところだろう（どのみなもと太郎一座の役者がクローディアス（だよーん顔）、ホーレショ（頭悪そうな人）、レアティーズ（口が尖った人）、法務官（はげ）が演じたかこうやって思い出せるくらい、みなもと太郎版は記憶にあるので、間違いないだろう）。

【みなもと太郎の世界名作劇場】 ハムレット(みなもと 太郎)

（買いなおすことになる）

_ 新国立劇場のドン・ジョヴァンニ

べらぼうに歌手が良い。それも全員という驚異的な舞台だ。

特に音楽的にはいなくてもいいなぁと思っていたドンオクタービオの1幕の歌声の美しさはびっくりだ。

が、少なくとも1幕に関しては、指揮が遅すぎて血が立ったまま眠ってしまうくらいに退屈だった。歌手が抜群なのにもったいない。

_ 名探偵ピカチュウ

声がおっさんというのは予告編で知っていたが、単純にサトシを黒人の少年に置き換えたお話くらいに考えていたら、いきなり保険会社の下っ端が友達に言われてカラカラを捕まえようとして失敗する話でなんじゃこりゃと思った。

保険会社のうだつの上がらない下っ端が主人公といえばグレムリンなわけだが、全然似てないが、似てなくもない話で、作家はジョーダンテなんかまったく意識も何もしていないだろうが、ハリウッドには保険会社の下っ端というコンテキストがあるのかなぁ。

えらそうな会社の重役がいるビルに上昇して執務室に入り込むところはブレードランナー風だったり（そもそも偉くない人が、高層ビルの偉い人とさしで話すというのはディックの小説のパターンだな）、全然頭を使わずに状況と文脈を映像化しているので、つまらなくはなかったし、最後に、ああ、そういうお話だったのかと思わせたところはうまかった。

使われていない子供部屋のピカチュウの耳がはえたベッドが泣かせる。

フシギダネが役得だ。

_ スケーラブルデータサイエンス データエンジニアのための実践Google Cloud Platform

翔泳社の野村さんからもらったので、なんとなく（ちょっと表紙のセンスが良いのと内容が想像できないこともあって）読み始めたら、これは妙だ。おもしろい。新しい。勉強になる。必読書の類にみえる。

とりあえず1章まで熟読、あとは流し読み時点で書いている。

内容は、GCPでこんなことができるよ（サンプルはhttps://github.com/GoogleCloudPlatform/data-science-on-gcpにあり、Cloud Shellで実行できるらしい）なのだが、読んだ限り単なるGCPの宣伝（こうすればダミー頭でも使えるので明日からデータサイエンティストみたいなやつ。ただしCloud Shellの使い方は図入りで解説されていて、かつ注で1年以上前のことだから今は違うかもみたいなことも説明されているが、ここはGCPの宣伝本としては本質なのだろうが、本書の内容からはそれほど重要ではないのも間違いない）ではない。

とにかく異様に頭の良い書き方がしてある（感心しまくっている）のがポイントだ。

まず課題が明確だ。その明確さによって、向き合い方、解法の探求、実問題への適用というそれなくして無意味であるところの、課題の汎化に対して大きく開かれている。そこがむちゃくちゃすごくて、読み始めると、あっという間にフォーカスされた問題と向き合わされる。

1章の冒頭で車を中古で売る時の例で走行距離計が数行取り上げられる。そこであっという間に改竄されていないか？ という観点に触れられる。課題に対する見方の分岐の量、速度、種類が抜群なのだ。

読者対象として、データアナリスト、データベース管理者、データサイエンティスト、システムプログラマと並べたあとに、衝撃的な展開がある。お前ひとりでこれら全部のロールをやれる、そのようにシステムは進化したのだから、そうしろ。良い時代だろ？ そうなのか。そう、GCPがあればね、とジョブズ風なプレゼンではなく、どのインフラがどうなっていることで、どの領域についての考慮点を減じることができ、というのがほぐされていく。しかし、それにしても、頭良いな、こいつ。

書いたのはGoogle CloudのPS部門のリーダーだそうだ（謝辞を読むとやたらと広範にわたって協力関係もある）。翻訳しているのは米系企業でデータを扱っていたりソリューションアーキテクトをしている人たち。ここで（訳者紹介は「はじめに」の直後になるからだ）ちょっと潮目が少し変わったような気がしたわけだが、確かに違う（もちろん、僕が最近の潮流についていけてないだけかも知れないが、そんなに大きくは外しているとは思えないので多数の人にとっても違うのではなかろうか）。

原書の出版が2018年1月なので1年半遅れだが、上記のように日本の僕の認識とのギャップから考えても、見た目の時間よりも遅くはないと思う。

はじめにを読んでいてえ？となったのは、本書がオライリーだということで、原書も動物シリーズではないのか、それとも版権の都合でこうなったのかは知らないが、ちょっと驚いたのだった。

スケーラブルデータサイエンス データエンジニアのための実践Google Cloud Platform(Valliappa Lakshmanan)

_ 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の出現と進展にあるというのが、おれにはとてもおもしろく感じる。

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