僕は今RPAシステムをつくって、定型業務の自動化を行っている。

今一番考えているのが、自分たちの事業部だけでなく、他の事業部にも「横断的にこの仕組みを浸透させるためにはどうすればいいか」だ。で、いろいろと試行錯誤してきた結果、少しだけ見えてきたことがあったので、備忘録的にnoteに纏めておきたいと思う。（このnoteが誰かの参考になったらとてもうれしいけれど、あまり居ない気もする。。）

現場とトップの課題は異なる

課題は現場に埋もれている。だから会社を良い方向に導きたいのであれば、現場からボトムアップで課題を定義し、トップに提案していくことが理想だと思う。

でも実際にそれをやったとしても、なかなか上手くトップに説明ができなかったりする。その理由は様々だと思うけれど、僕がこれまでの経験で一番ネックだと思ったのが「現場とトップで抱えている課題が異なる」ということだ。

当たり前の話だけど、その人のポジション・役割に応じて抱えている課題は異なる。だからその違いを前提としてコミュニケーションをしないと、現場からどんなに有用な提案をしても、それが簡単に通ることはない。(いや本来は会社の課題を「現場・トップの垣根なしに考えるべき」なのだけど、そういった正論がなかなか通らないのが現実だったりする）

「意思決定はトップが行う」ということを忘れない

「何を当たり前のことを」と思われるかもしれないけれど、「意思決定はそのチームのトップが行う」ということを忘れてはいけないと思う。

現場からトップに対し「現場の課題と解決策」を数字とロジックで説明したとしても、トップの心を動かすのは結構難しかったりする。（みんながみんなそうではない、とも思うけれど。あと、もちろん現場側の提案の仕方にも不足があることもある。RPAの例でいうと、トップが知らない新しい技術をいきなり受け入れろ、と言われても厳しかったりもする。それがどんなに便利なものだとしてもだ)

じゃあどうするかというと、「まずはトップの課題から解決」し、その効果をトップに実感してもらう他ないように思う。

RPAの例で言うなら、トップが普段行っている定型業務をヒアリングし、実際にRPAでそれらの作業を変わりに行い、手動よりも早く正確なアウトプットが自動でできる、ということを身をもって実感してもらう。

そしてトップが納得するアウトプットを出すことができれば、そこからの話は結構早かったりする。

結果を出すことで、他事業部への横展開もたやすくなる。ある事業部のトップからお墨付きをもらうことができれば、他の事業者トップへの説明もしやすくなる。（というか、彼らに口コミで広めてもらったり、直接説明してもらえたりすることもある。ここまでくると、かなり効率的だ）

本来やろうとしていた「現場の課題」への着手はその後でいいと思う。まずはトップの課題を解決し、結果を出す。(仮に現場の課題を解決したほうが費用対効果が高いとしても、まずはトップの課題解決を行う。）

もちろんこのやり方はすべての会社で当てはまるということではない。その会社の考え方、文化に応じて順番は変えるべきだと思う。僕が対象としている組織は少し旧態依然な組織なので(それがいいか悪いかはさておき）、おのずとこうなったのだと思う。

会社を変える順番

こうしたやり方は一見遠回りに見えるかもしれないけれど、結局は「解決する順番だけの話」で、「誰の課題から着手するか」はそこまで大きな問題ではないと思う。大切なのは「やり抜く力」で、「会社を変える順番」なんてその力の前ではさしたる問題ではない。

テクノロジーが現場とトップをつなぐ

何でこういうことができるかというと「テクノロジーが現場(の課題)とトップ(の課題)をつなぐから」だと思う。(大前提として、汎用性の高い課題を定義しておくことは必要だとは思うけれど)

土台となるテクノロジーの基盤さえしっかりしていれば、誰のどんな課題だろうと解決できる。柔軟に、あらゆる状況に対応できるのは強さだと思うし、これからの時代を生き抜く上で必要不可欠な要素だ。

だからこそ毎日新しい技術をキャッチアップし、自ら実践し学び続けていく必要があるのだと思う。よりしなやかで柔軟な、どんな組織に対しても貢献することのできる力を身に付けていきたい。と改めて思った。