そろそろRPA:Robotic Process Automationについて一言言っておくか

RPAは専門外だが、自動制御ってところで25年飯を食ってきたので一言書いておきたい。ポエムだよ。あとTwしたものをまとめている。

RPAの第一歩はまず、業務内容の言語化。日本語でまず業務内容を「細かく」記述できるかどうかがまず第1の関門。ここで躓くようなら、業務内容か組織に自動化に対する問題がありすぎて作業の自動化は無理なので、素直に諦める。まず初めにそっちをどうにかしないといけない。

次の関門は、記述できた業務内容をフローチャート化出来るものと、フローチャート化出来ないもの、フローチャート化はナントカできるが複雑すぎるもの3種類に分ける。1番目はそのまま完全にRPA化が可能。2番目のフローチャート化出来ないものは、人がやった方が早いのでRPA化しない。実は3番目もやらない。現状のRPAのソリューションで3番目を片付けるのはやっかいなので、まずここをどうシンプルにするか業務改善を考えた方が良い。システム化はそのあと。そして、皆さん何故かRPAが2番目と3番目の項目に適応できると考えていらっしゃる。はっきり言ってムリ。現状RPAはつまらないルーチンワークを見つけ出して、そこを効率化することで、社員を本来しなければならない業務に集中させるツールとして考えないと失敗する。PRAもAI技術も銀の弾丸じゃないので夢を見すぎてはいけない。しかし、何故か皆さん主要業務が自動化できると考えている。

結局業務内容見直しとその改善のと言う点で、かつてもてはやされたBPRとRPAは本質的に何も変わらないよ。これらの本質は業務改善であって、RPAを入れることが目的化したらそれは手段の目的化に過ぎないし、そうであれば100%失敗することを保証する。まず、業務内容を言語化して文書化する。そしてそれを見なおす。そこからはじめる。RPAは道具。適材適所がある。

F#の方向性の話

TL;DR We’ve moved the F# GitHub repository from microsoft/visualfsharp to dotnet/fsharp, as specified in the corresponding RFC. F# has a somewhat strange history in its name and brand. If we roll back the clocks to the year 2015, F# sort of had two identities.

情報源: The F# development home on GitHub is now dotnet/fsharp | .NET Blog

微妙な二系統の開発は止め、.NET Coreベースのオープンソースプロジェクトへの集約という事らしいです。