自動化したのに人数が減らない謎を解け

DXツールの進化は目覚ましく、今やなんでもDXでできてしまうと錯覚してしまいそうになるほどです。
1984年にMacintoshが登場するまでは、システムはコードを打ち込まなければ動かないものでした。
GUI（グラフィカルユーザーインタフェース）の登場により、視覚的に動かせるようになったコンピューターは、徐々に一般にも普及するようになり、2000年頃には企業の事務作業には欠かせないものになっていきました。

それと同じように、DX・・・デジタルの力を借りることによって何らかの革新を起こすということも、今や誰も疑うことのない当然の施策であるようです。
商売柄多くの大企業の管理職の方とお話をさせていただきますが、DXが課題だと仰る方は非常に多く、逆に、DXが不要だと仰る方はまずおられません。

事務系の業務に関連するところで言えば、様々な機能に特化したSaaS型（いわゆるDXツール）が比較的安価に利用できるようになったことと、ノーコード・ローコード（プログラムを書かなくてもシステム開発ができるツール）の登場による特殊なIT開発の技術を持たない人でも自動化・システム化ができるようになったことが挙げられるでしょう。後者については、極端に言えば誰でも、自動化・システム化ができるようになりました。

ここで注意が必要なのは、やらなくて良くなったのは「プログラミング（コード化）」、そして場合によっては「単体テスト」だけだということです。
やりたかったことが本当に実現できているのか、たまたまこのパターンだけできているわけではなく、たまたまこのパターンだけできているわけではなくて、予測しうる限りの発生パターンに対して正しい結果を出すことができるのか、これらを確認するためのテストは、アドオン開発なしのSaaSシステムだろうと、ノーコードツール上のシステムだろうと絶対に重要です。

システム構築の知識のない人が、簡単にできるからと身近な自動化を行うとどうなるでしょう。
例えば、これまで元情報を見ながらExcelに必要な情報を転記していって、何らかのアウトプットを作っていたところを、元情報を格納したらAI-OCRで読み取って、RPAでアウトプット用のフォーマットに転記していくなどが考えられます。

システム構築の知識のない方が実施する場合、大抵は「今手でやっているプロセスをそのまま」自動化するものになります。結果的に下記のような問題が起こる可能性があります。

• そもそも実施する必要のない処理を自動化してしまう。
• もっと良い自動化の手段があるのに気づかず、手作業の手順のまま自動化してしまう。
• 必要に応じて多少の手順追加をしていることを考慮せず、基本的な手順だけを自動化した結果、結局毎月、自動化部分だけでは使用に耐えないアウトプットにしかならず、うまくいかなかったところを手で補う羽目になる。
• 関連する他業務との共通化を検討せず、個別最適で自動化してしまう。
• 仕様書を作らない。
• データやプログラムが構造化されていない。
• テストをしない、足りない。

誤解のないように申し添えておきますが、システムの専門家ではない人が身近な自動化をすることが悪いと言っているわけではありません。身近な自動化の経験は、システム開発を勉強するきっかけとなるかもしれませんし、人によってはこのプロセスを自動化する費用対効果があるのかといったことにご自分で気づく場合もあるでしょう。

ですが、現実問題として上記のような問題を抱えている場合、便利になるはずだったのになぜかうまくいかないということがそれなりの頻度で起こってしまいます。そうなれば結局、人を減らせば回らない（オペレーション業務を減らして戦略・企画業務にシフトするはずが、結局オペレーションにかなりの時間を取られてしまう）ということが起こります。
「自動化は計画通りできたのに、人が減っていない」という症状が起きている場合、上記の原因が隠れているかもしれません。

では、業務部門などのIT開発の専門知識を持たない部署で、DXツールを使って自動化を行う場合、何に気をつけたら良いのでしょうか。

重要なのは全体構想とデータです。
全体構想については、欲を言えば全社の業務とデータの流れが可視化されている資料を基に、今回の自動化検討に最適なスコープや手段を検討できれば良いのですが、運よく全社基幹システムの再構築を終えたばかりで、追加開発を業務部門主導で行う場合などでなければ難しいかもしれません。

可視化されている情報がない、あるいは古くて信頼できない場合は、自分たちで調べる必要がありますが、最低限自動化しようとしている範囲の前工程と後工程、また類似の関連業務がある場合は、その内容も明らかにしたいところです。それにより少なくとも、今のやり方をそのまま自動化することが一定程度は合理的だと言えそうか・・・そうでないのかを知ることができるでしょう。

データの重要性ついては、語るまでもないと思います。
企業にとって重要な情報を取り扱うプロセスを自動化する場合には、他部門でのニーズも含め、その情報を有効に使うためにはどういった情報項目を、どのような粒度と鮮度で保持する必要があるのかをよく検討することが必要です。

DXツールの進化を受け、自動化自体は従来に比べて非常に安価に、簡単に、極端に言えば誰でもできるようになりました。
仕様書も書かず、テストも行わず、現状プロセスの一部を自動化するだけであれば、たいした時間もコストもかけずに自動化することができます。それ自体は非常に素晴らしいことではありますが、逆にこの“仕様書もなければテストもしない一瞬の自動化”が本当に効率的効果を生み出せているのかは、一度振り返ってみる価値があると考えます。（本当に効率的効果が生み出せているなら素晴らしいことです）

振り返る際の視点は下記のとおりです。

• 自動化した業務そのものだけを見るのではなく、結局その部署の人数やオペレーション工数全体は減っているのか。
• 今後数年間を想定した際に、その削減効果を維持、あるいはそれ以上に減らしていくことはできそうか。
• メンテナンスやトラブル対応に時間がかかっていたり、仕様のブラックボックス化が起きたりしていないか。（部署のミッションが変わっているなど、単純な業務量比較ができない場合）
• 自動化ツールで作成されるものでは情報が足りず、それとは別のレポートを作成して提出しているなど、処理の二重化が起きていないか。

Excelの関数やマクロといった昔からあるものもそうですが、期待するほどの効率的効果が出ていないのであれば、全社の業務プロセスとデータフローの流れを可視化し、経営上重要なデータを特定してデータ活用を見据えたあるべきデータ保持方法を定義し、それを満たす効率的な業務フロー／データフローを構築仕直す必要があります。そうすることで、効率的効果を上げることができると考えられます。

Horizon One（レイヤーズがベルシステム24ホールディングスと設立した、間接業務BPOのジョイントベンチャー）が業務をお預かりする際にも、あまり効率的効果が高いとは思えない自動化をされているケースが見受けられます。

IT部門以外の業務ユーザーが作った自動化ツールであれば、仕様書がないのは当たり前として、正常に動作するかどうかが怪しいものもしばしば目にします。ひどいものになると毎回エラーが起き、エラーが起きない月はまずないといったものもあります。

我々も最初からこれを直すには業務知識が足りないので、まずはその状態で引き継ぎを受けます。業務によりますが、月次業務であれば1～2年記録を取り続ければ、どういった問題がどの程度の確率で起きるのかの可視化もでき、関連業務や同じような情報をどこでどう使っているかなど、受託業務の範囲内ではありますが、業務の構造的理解もできますので、そのあたりから改善を進めていきます。

業務を実施し続けた記録には大きな価値があり、この記録から例外事象も含めてアウトプットとインプット、プロセスをできるだけ大きな括り（現在のプロセスにこだわらない）で整理し、最もシンプルで効果的なプロセスを検討します。
お客様が使用されているツールについての理解も実務を行う中で得られることが通常ですので、そのプロセスを検討する上では、お客様の業務システムの機能や、RPAやノーコードツールなどの導入状況を加味して、実現性の高いプロセスを考案します。
BPOはあくまでも運用がメインですので、特別なご要望がない限りは改善活動に割ける時間はわずかです。従って、改善活動はゆっくりとしたものにはなりますが、地道な記録を元に最も効果の出そうなところから、着実に改善活動を進めていきます。

ここまでご精読いただきありがとうございました。
当記事に興味がおありの方は、是非お問い合わせください。