36歳中小ベンダーSEが社内SEに転職しました！

昨日の帰宅時 ―

山手線で新宿から乗り、20時半ごろ品川へ到着。
通常だと、ここから京浜東北線に乗り換えて、自宅のある大森へ向かうのですが、この日は山手線で「京浜東北線は大森―蒲田間の沿線で発生した火災のため運転を見合わせております。」との車内アナウンスが。

また止まってんのかよ。（呆）

事あるごとに遅延・見合わせが発生する京浜東北線。
まぁ、沿線火災ならJRのせいではないんですが。

そして、大抵仲良くセットで止まることが多い東海道線も、やっぱり運転見合わせ。

東海道線と京浜東北線が止まった場合、品川駅では何が起きるか。

そう、京急線の大混雑です。

このときも、東海道線・京浜東北線から振り替えしようとする人でごった返しになり、早々に入場規制がかかってました。
こうなると、お次はバス・タクシーということになりますが、こちらもいつも通り長蛇の列。

この光景をもう15年ぐらい見続けてますが、いい加減に何かしら改善できないものでしょうか。

ちなみに、京浜東北線ホームに一応行ってみましたが、品川駅で回送列車となってしまっていたため、車内で座って復旧を待つことすら許されない状況。
それでも、復旧を信じてホームで立ったまま待ち続ける人も多数いました。

中には、駅員さんに食ってかかる人も・・・
駅員さんに言ってどうなるもんでもないだろうに。

スポンサーリンク

こんな感じで品川駅の様子を15分ほど見て回った結果、早々に決断しました。

徒歩で帰宅することを。

「広範囲に延焼している」というアナウンスがあったため、鎮火されるのは早くても2時間程度はかかるだろうという想定。
であれば、2時間立ったまま待つのも、2時間歩くのも大差ないだろうと思いました。

ということで、大混雑の京急線改札やバス・タクシー乗り場を横目に、高輪口から出発。
途中、同じように徒歩帰宅を選択したらしき人達も、数十人ほど見かけました。

品川から大森へは、第一京浜をただひたすらまっすぐ歩くだけなので、道に迷うことはありません。
で、特に苦もなく、10時前ごろに大森駅に到着。

実は、東日本大震災のときに徒歩で帰宅した際は、品川駅から大森駅まで、虫の息になりながら約2時間かかりました。
が、運動不足だった当時とは違い、富士登山をキッカケに週二で1時間ウォーキングを続けていることが、功を奏したのでしょうか。

パチスロのために駅近まで出てきていた嫁と合流し、軽く労をねぎらってもらった後、リンガーハットで長崎ちゃんぽん麺2倍＆餃子セットで夕食。

そして、歩いて自宅まで向かう道中・・・
いつも通る商店街に、消防車が10台ほど止まっていました。

オイオイ、火元はここやったんかい。（汗）

大森―蒲田間と言うより、ほぼ大森駅やんけ。

でも、もう火は消えてるのに、電車は相変わらず動いてなさそう。（10時15分ごろだったかな）
もう運転再開しても良いのでは？
しかも、この火災で京浜東北線が止まるのはまぁ理解できるが、東海道線は止めなくても良かったんじゃないか？
いくらなんでも、火元になった店舗とは真逆サイドを走っている東海道線の線路にまで影響が及ぶとは思えんが・・・

今日調べてみたら、結局運転再開したのって11時ごろだったんですね。（苦笑）

3時間も止まってやがったのかよ。。。
結果的には好判断だったことになりますが、判断を一つ誤ってたらえらいことになってたな、こりゃ。

しかも、もう少し退社が早くて下手に品川から京浜東北線に乗れてたら、駅間で止まって電車内にカンズメにされるところでした。
そう考えると、最悪な事態の中でも、一応は歯車は良い方に噛み合ってくれたということでしょうか。


還元率の高いポイントサイトで、ハイペースでポイントが貯まります

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます

Azureの「Computer Vision API」で実務文書のAI OCRを試みて、見事に返り討ちにあってから約2ヶ月 ―
Watsonなんかも試してみようかと思いましたが、自作RPAの方がやたらと忙しくなり、全く手を付けられず。。。

そんな中、元々取引のあるとあるベンダーの営業から、ちょうどAI OCR製品の提案が最近あったので、話を聞いてみることにしました。

ちなみに、そのベンダーは自体が開発した製品ではなく、他社が開発したものの販売代理店＆PoC受託が飯のタネとのこと。
RPAツールにしてもそうですが、まぁよくある話です。

とりあえず、パンフレットなんかを説明してもらって、ちょこちょこ質問。
と言っても、AI OCRについては、セミナーなんかも含めて常にアンテナは張っていますので、特に真新しい情報はありません。

しかし、せっかくの機会ですので、Azureで玉砕した手書き文書をどのぐらいの精度で読み取れるのか、試してもらうことにしました。
いくつかサンプル画像を送付してみて、待つこと約一週間。。。

結果が出たとのことで、SEと一緒に再度来社してもらいました。

そして、プロジェクタに映し出された読み取り結果のCSVデータを固唾をのんで見てみる・・・

す、す、すごい！！

当社用の学習は当然やっておらず、帳票設定もあまり細かいことはしていないとのことでしたが、それでも最低でも識字率は80%以上ありそう。

スタンドアロンで動作する上、推奨スペックは一昔前のPCレベルなので、高価なサーバ機など用意する必要もナシ。
ちなみに、イマドキの普通スペックPCだと、1枚読み取るのに30秒程度でした。
まぁ、このレベルなら、夜間バッチで夜通し読み込みさせれば問題無いので、十分な性能です。

う～ん、市販AI OCR製品・・・恐るべし。

尚、Computer Vision APIなどの無料の文字認識サービスがダメな点は、何と言っても項目指定ができないこと。
項目指定ができないので、「この項目は数値のみ」「この項目は英数字のみ」といった指定ができず、文書中の全ての文字に対して、英数記号＋日本語のどの文字に近いかを判定するハメになります。
そうすると、候補文字がいくつも該当してしまうので、結果として誤読率が上がってしまうのです。

例えば、「1」と「I」と「|」って、手書きだと殆ど区別はつきません。
でも、金額欄とか時刻欄のような数字しか書かない項目なら「1」しか有り得ませんし、英字のみの項目に書いてあるなら「I」しか有り得ないでしょう。

このように、項目ごとに読み取り属性が指定できることは、識字率の向上において最も重要な要素なので、無料サービス達もここに対応してほしいのですが・・・
タダだから、そんな要求はさすがに厚かましいか。（苦笑）


スポンサーリンク

デモで読み取り過程の画像も見せてもらったのですが、何と罫線が全て消されています。これは、罫線と被ったりすると文字が認識しづらくなるので、事前処理として罫線を消す処理を行うようにしているとのこと。

しっかし、よく数字の「1」や漢数字の「一」と罫線の区別がつくな、コレ。

もちろん、この罫線認識にもAIが使われているのでしょうが、器用なことに罫線のみがほぼ100%消えています。
しかも、手書き文字が枠をはみ出していて、文字と被ってしまっている罫線すらもキッチリと消去される徹底ぶり。
これだけキレイに罫線が無くなれば、確かに文字認識の精度は上がるでしょう。

実際、Azureで文字認識を試したときも、罫線を「1」だの「I」だの、果ては「|」（パイプ）として読み取りやがりましたから、OCRにおいて罫線は邪魔以外の何物でもないのです。

ということで、AI OCR製品に関しては、セミナーや世間の評判は正しかったということが実証されました。
が、AIの悲しいところですが、学習を重ねると、大抵どの製品も95%を超える識字率になってしまうのです。

それはつまり、機能で差がつきにくいので、結局は価格競争になってしまうということ。

当然、うちの会社においても、今回の結果を受けてAI OCR製品の実力は良く分かったのですが、同時にとにかく安い製品を探し始めるという結果に。（笑）

相場的には、月額20万円～の製品が多そうです。
が、RPAツール市場と同様に、少し待てばすんごい安い製品が出てくる可能性も大いにあります。

どこかのベンダーが月額5万円ぐらいで提供するような事態になれば、恐らく当社はすぐにでも食い付くと思います。
でも、それを皮切りにして、一気に過当競争に陥ってしまいそうな気も・・・

AI OCR製品を開発しているベンダーが少ないのは、意外とこれが原因なのかもしれませんね。


還元率の高いポイントサイトで、ハイペースでポイントが貯まります

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます

私が作っているExcelマクロでの自作RPAと、とあるベンダーから購入したRPAツールが同居している当社―

＜現在の勢力図＞
　RPAツール：　営業部門のとある１部門のみ利用（５台で稼働）
　自作RPA：　その他のほぼ全ての部門で利用（数十台で稼働）

ま、自作RPAの方はお金がかかりませんから、社内シェアとしては上記のような構図になるのは、ある意味当然のこと。
しかし、まだまだRPAツールを導入した部門もシェア拡大を諦めてはいないようで、管理部門へのハンズオンセミナー参加を企画しているようです。

ということで、先日管理部門の部長陣を集めて、セミナーに参加させる社員についての打ち合わせを行っていました。
以下、ある一場面を抜粋。

営業部長：「RPAツールによって、既に当部門では工数削減効果が出ています。管理部門でも導入して、積極的にご活用下さい。」（ドヤ）
人事部長：「おたくで効果が出ているのは、専任で開発できる人がいるからでしょう。」
営業部長：「確かにそうですが、兼任でもそれほど難しくないかと思います。」
人事部長：「それは、多少なりとも技術に詳しい人がやるからではないですか？」
営業部長：「まぁ、普通の人よりは多少PCの扱いやマクロなどに詳しいかもしれませんが・・・」
人事部長：「そんな社員はウチにはいませんし、専任化させるような余力もありません！」
営業部長：「・・・」
人事部長：「システム部で開発してもらうことはできないんですか？」
システム部長：「システム部で開発するなら、たみおとさんに今やってもらっていること（自作RPA開発）と何も変わりません。」
人事部長：「同じことができるんですか？」
システム部長：「同じことができます。」
人事部長：「じゃあ、尚更こんなの必要ないじゃないですか。」
営業部長：「はぁ・・・」


スポンサーリンク

世間ではRPAツール崇拝の風潮が漂っていますが、現実には業務部門の拒否反応は強く、上手な活用はおろか、導入すらも簡単にはいかないものなんだということが垣間見えた一幕でした。

RPAツールの本来の長所は、業務部門で「必要なときに必要な自動化処理を自分達で作れる」というところにあります。
が、実際にはRPAツールの使い方や注意点などを習得したり、その後のロボ作成やメンテを行っていく余力がある部門など、中々無いということでしょう。

なので、世間的に「RPAツールの導入が成功した」とアピールしている会社でも、システム部門がロボ作成を担当しているところが大半なのではないでしょうか。

でも、これはRPAツールの長所を活かしきれているとは言えません。
そもそも、システム部門がRPAツールを使ってロボを作るぐらいなら、マクロを勉強してマクロで自動化処理を組めるようになればいいだけの話なのです。

10月から我がシステム部に異動してきた人も、RPAツールの話題が出たときに、「こんなこと、マクロでできますよね。昔からあるのに、何を今さらって感じです。」と話していました。

と言いつつ、私も去年までExcelマクロからDOM（Document Object Model）を操作できることを知るまでは、RPAツール信者の1人ではありました。
が、いざマクロで実現可能なことを知ってしまうと、無料で簡単に作れるのに、わざわざ大金をかけてRPAツールを買うのは馬鹿らしいと思うようになりました。
（もちろん最初は苦労しましたが、コツが分かってしまえばRPAツールと同じぐらいハイペースで開発可能）

社内SEで、もしこの記事をご覧になっている方がいらっしゃいましたら、まずは自作してみることをご検討下さい。
余力やスキルの関係でどうしてもダメそうなら、RPAツール導入も止む無しですが、その際には、「Excelマクロで自作も可能」であることは社内には絶対に伏せておくようにして下さい。

でないと、ムダな投資をしたと勘違いされ、上層部からの印象が悪くなりかねませんので・・・

還元率の高いポイントサイトで、ハイペースでポイントが貯まります

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます