ようやくコロナ禍が終わろうとしているときですが、コロナ禍と同時に日本でも始まった「DX」の流れはむしろこれからという動きを見せています。
以前「下からのDX」という言葉を使って、現場手動で業務のオートメーション化することの課題について触れました。
この記事では私が実際に体験した事務職系業務の現場において「下からのDX」を推進させることに成功したケーススタディを２つ紹介しながら、「下からのDX」の今後について考えをまとめてみたいと思います。
なお「DX」というと厳密にはデータ利活用やAIも含まれますし、そもそもオートメーション化に限っても、ゴールのない終わりなき課題と思っています。今回紹介する２つのケースの成功事例もあくまで、「推進」に成功したのみで完全なゴールの姿ではない点についてご了承いただければ幸いです。
目次
ケース１：Officeマクロからの拡大
まず最初のケースはWord・ExcelといったOffice製品を使い倒す過程でVBAまでたどり着き、VBAを使ったオリジナルの業務自動化アプリケーションを使い倒した結果、主要な作業のオートメーション化に成功した事例です。
Word、ExcelといったOffice製品には、マクロという頻繁に行う作業の自動化を行う機能があります。このマクロは「作業録画機能」という、ボタンを押して一定作業をデスクトップ上で実演したうえで自動化するものから、VBA（Visual Basic Application）というプログラミング言語を使って実際にプログラムを組んで動かすことまでできます。
※ご興味のある方はネット上に入門サイトもたくさんあったり、以下のような書籍もたくさんありますので手に取ってみてください。
特にVBAを使った自動化までたどり着けると非常に強力な武器となり、なんと作業を行っているExcelファイル以外のアプリケーションの操作もできてしまいます。
以下のサイトの紹介例のようにSeleniumというブラウザ操作ツールと組み合わせることでブラウザの自動操作もできてしまいます。
Officeマクロを使い倒した結果「下からのDX」を進めることに成功した組織は、Excelファイルに図形挿入を駆使してボタンや入力フォームを設置した操作ツールを使い、ボタンを押すことで、ブラウザが立ち上がり取得したいデータの自動取得を行ったり、別のExcelファイルに自動取得結果の一覧表を作成したり、あるいは、別のExcelファイルに登録されたデータをもとにWordファイルを作成して印刷実行といった自動処理をExcelアプリだけで実現しています。
ケース１の方々は基本的に専門学校でエンジニアとしてプログラミングを学んだ方がいることはあまりなく、ほとんどエクセルマクロを使い倒した結果、自然とプログラミングを学んでしまった方がほとんどです。
そして、中には職業プログラマ顔負けの綺麗で処理が効率的なプログラムコードを書いている人まで存在するときもあります。
このような「下からのDX」が推進されるきっかけは、一人のOffice製品を使い倒した人の努力による発展ではありますが、よりしっかりした組織になるとそのナレッジを水平展開・冗長化させて担当者ごとの育成計画やジョブディスクリプションとして定義させています。結果として組織全体が「DX化」されたプロフェッショナル集団として機能しています。
ケース２：ITエンジニアとの連携
次のケースは身近にITエンジニアがいることから、ITエンジニアに自動ツールを開発して運用してもらうことを定常化してもらったり、逆にノウハウやナレッジを学んで事務作業を行う担当者自らが自動化ツール開発に着手している事例です。
ITエンジニアにも様々なタイプがいますが、特にプログラムを書くことの多いソフトウェアエンジニアにとって、定型的な作業の自動化は手作業によるミス防止も含めて興味関心が高い傾向があります。
結果として、彼らのナレッジが事務作業にまで手に及びオートメーション化を達成して「下からのDX」の推進ができたのがこのケースになります。
ケース１はOfficeベースであったためにVBAをベースにしていましたが、ケース2の場合はエンジニア界隈の影響が強いため使う技術は少し違い、VBAを必ずしも採用しているというわけではないという特徴があります。
私が目にする限りでは特に多いのは初心者向けプログラミング言語として定評のあるPythonを使っているところが多い印象です。
※Pythonも以下の本のように自動化をするためのHowTo本が数多くあります。興味がある人は手に取ってみてもよいかもしれません。また、私もかつて初心者向けに以下のような記事を書いていますので興味があればこちらもご覧ください。
なお、ケース２については、どちらかというとWEBベンチャーのようなもともと職種の垣根が低かったり、非エンジニア系の職種の人がエンジニア職の人との接点が強いところが多いです。職種間の連携がうまく回った結果発生した「DX化」と言えるかもしれません。
「下からのDX」を進めているチームにとってのRPAツールの存在意義
ここまでは2つのケースをご紹介しました。どちらかというと「上からのDX」の視点で今日RPAツールの存在が注目されていますが、「下からのDX」を進めている彼らにとってRPAツールはどのように見えているのでしょうか。
結論から言うと、必ずしも有効的なツールとして見ていないという状況になります。
Microsoft Power Automateを代表するRPAツールは初めてオートメーションをチャレンジする人にとっては非常に強力なアイテムになると私も思っています。しかしながら、彼らにとってはすでに実現できていることに対する二番煎じであったり、逆に小回りが利かないなどの問題から採用しづらいという声をよく耳にします。
ケース1，ケース2で「下からのDX」を進めている彼らにとってはもうすでに解決済みの課題でしかないのかもしれません。むしろ会社としての業務ガバナンス観点でRPAツールの導入を推進するところとの軋轢が生まれるケースも私は懸念しており、この点からも改めて「上からのDX」を進める専門部署と現場での対話や理解がますます必要になってきていると考えております。
今から「下からのDX」を目指す場合
最後に今から「下からのDX」にチャレンジしたい組織はどのように進めればよいかという点について私の考えを述べたいと思います。
目指すならケース1か
ケース1、ケース2とも特段組織としてハンドリングした結果生まれたものではなく、自然発生した結果生まれたものです。
そのためケース1、ケース2どちらかを目指すのであればケース1のほうがやりやすいかもしれません。ケース2の場合はエンジニアと接点があることがそもそも重要であり、今から接点を作りに行こうとしても、どのようなジョブスクリプションのエンジニアと接点を持ったりすればよいのかハードルがあるのではないかと思います。
もっともケース1であっても、従来の業務環境ですでにOfficeの利用スキルが十分である環境では「下からのDX」が発生するのは難しいのではないかと思っています。仮に1人無茶苦茶Office製品を使い倒した人が入社しても、その人のスキルを水平展開したり、ジョブディスクリプションとして定義の上、教育カリキュラムなどを維持しなければ、メンテナンスができず進めることはできません。
そのため、ケース1を目指す場合も組織運営観点での改革が必要であり簡単な道のりではないと思います。
ゼロから始めるならRPA導入がよさそう、ただし注意点あり
ゼロからの導入であるなら、まずはRPAで試してみるのが良いかもしれません。特にMicrosoftのPower Automate Desktopは無料で使えることもあり、書籍やネット上の記事がたくさんあり、手軽に試してみることができます。
もっとも私個人は、RPAツールはやはり小回りが利かない問題や、結局アルゴリズムを組み立てる作業に難儀している方を多くみており、あわせてプログラミングの学習やVBAやPythonといった発展的な技術の学習をあわせてやる必要があると思っています。
Power Automate Desuktopも現状は細かいことになるとPythonやVBAを書かせる状況になっていることや、そもそも、文字ベースではないビジュアルベースでのプログラムを組むことがPower Automate Desktopktopでも必須となっており、この点が現状のRPAの課題であると私は思っています。
もっとも、すでに小学生のプログラミング教育が必修になっており、あくまで一時的な過渡期としての課題になるのか、それとも別途社会人の教育カリキュラムとして必要になるのかは今後の社会変化としての注目点と私は考えております。
終わりに
誰かに向けたものと言うよりは私の日常業務の考えを整理した記事ですが、何か気づきがあれば幸いです。最後まで読んでいただきありがとうございました。
Photo by Lee Campbell on Unsplash
