RPA外部委託で失敗しないために

2021/02/05 コラム



 RPA はプログラミング経験がない現場ユーザーでも比較的簡単に業務を自動化できるということで人気を博した。そのため、RPAを導入する際には、基本的には自社の従業員による内製を前提にプロジェクトが組まれることが一般的である。一方、外部委託 (外注) をする選択肢も時には必要となるだろう。ただ、外注にむやみに頼りすぎてしまったばかりに、業務がブラックボックス化してしまったりコストが掛かり過ぎてしまうなど失敗してしまう事例も出てきている。この記事では、RPAの外注で失敗しないためのポイントを紐解いていく。

人材・スキル不足を克服する手段としての外部委託

 RPA (Robotic Process Automation: ロボティック プロセス オートメーション)は、2017年頃から大企業を中心に導入が進んできた。これからRPAを導入しようとしている企業も多いだろうが、中には社内にRPA推進担当者を置くことが難しいために導入を躊躇している企業も一定数いるようである。RPAは内製化が基本ではあるものの、自社で人材を確保しきれない場合に、コストを支払う余裕があるのであれば外部委託を考えるのは選択肢としてはあり得るだろう。さまざまなRPAの調査によると、RPAの展開に一番障害となるものは、スキル不足、人材不足であるといわれている。

 

日本におけるIT外部委託の歴史とRPAへの期待

IT黎明期から外部委託傾向が強かった日本

 日本では元々ユーザー企業における技術者の割合が28%と欧米諸国の50~65%前後に比べて極端に少なく※、ユーザー企業が独自で自社のITシステムを実装する能力 (=内製する能力) が弱い。これはITで組織のシステムを作るようになってから一貫しており、この20年くらいは傾向が変わっていない。

 

IT企業とそれ以外の企業に所属する情報処理・通信に携わる人材の割合(日本、米国、イギリス、ドイツ、フランス:2015年、カナダ:2014年)出典: 情報処理推進機構「IT人材白書2017

 

 パソコンが一般の職場にも普及してきた2000年前後にエンドユーザー・コンピューティングという、組織内の一般ユーザーが身の回りのシステム化を自分でやることが流行った時も、日本においてはそれが内製化の方向に向かうことはなかった。

 

内製/外部委託の適材適所の活用と近年のビジネスとITの融合

 外部委託によるITインフラの管理は、構築時に専門家人材による設計、構築サービスを受けたり、ユーザー企業側の人材不足を補うことができるというメリットがある一方、一旦安定稼働してしまった後は、そのシステムの維持管理が目的化してしまったり、その後のビジネスニーズを柔軟に取り込むことができないなどの弊害もある。内製と外部委託はどちらが優れているということはなく、ビジネスや社会、技術の動向によって両者を適材適所で使い分けることが求められる。

 特に、2010年以降はITインフラのクラウド化が進み、ITインフラ管理にそこまでの専門性が求められなくなってきていたり、2015年以降のディープラーニング技術の発展とクラウドの結合による「AIの民主化」によって、実際にITを使ってビジネスを行うべき業務部門とIT人材が一緒になって活用方法を考え、新しいビジネスモデルを生み出すことが経営上の大きな差別化要因として前面に出てきたことにより、業務部門におけるIT人材の活躍の場がますます増えるようになってきた。かつてのエンドユーザー・コンピューティングブームのように、市民開発者 (シチズン・デベロッパー)という言葉がもてはやされるようになってきた。

 

RPAの登場と期待、外部委託との関係

 そのような状況の中で、業務部門において技術者でなくても業務自動化が推進できるRPAの登場にユーザー企業の期待が一気に集まり、2017年頃からのRPAブームに繋がっている。しかし、未熟なRPAツールの利用により結局現場で使いこなせなかったり、紙や判子業務がいたるところに残っていてITの力で自動化するにあたりそもそもその前提条件が満たされておらず、ビジネスプロセスの見直し (BPR : Business Process Reengineering) といった専門的な手法による業務全体の再構築が必要になるなど、RPAを活用して大きな成果を出そうとした場合には外部委託と完全に切り離せない状況が続いた。

 少なくとも、デスクトップの自動化に留まらない全社展開を行う場合は、RPAを業務に適用する順番のあたりを付けたり、業務部門で継続的にプロジェクトを回していく際のノウハウなど、RPAツールの使い方指南や実装以外のところで、プロジェクトの最初の段階では引き続き外部委託を活用したほうが結果としてのプロジェクト成功率があがることになる。

 

RPAで外部委託のやり方を誤るとROIが出ない

 このようにRPAにおける外部委託は、うまく活用すればプロジェクトを効率よく進めることができる。しかし、あまり考えずに従来のITプロジェクトと同様に外部委託に任せっきりにしまうと、ずっと外部委託コストを払い続けることになり、いままでのITプロジェクトと何ら変わらなくなり、現場で活用できるというRPAならではの良さがなくなってしまうことに注意しよう。当然、コストもかさむことになり、当初予定していたROIが出ないことになる。

 また、前述したように、採用したRPAツールによっては、画面が一見簡単そうに見えても、実用的なシナリオを構築するためには開発者レベルの知識が要求されたりして、外部委託漬けから抜け出せない状況になってしまっている例も見受けられる。

 

成功するための外部委託

 それでは、RPAプロジェクトにおいてどのように外部委託を活用するのが最も望ましいのだろうか。これ以降では、RPAプロジェクトを進行するうえでのいくつかのポイントについて解説していく。

 

開始時の人員配置を間違えるな

 まず、基本的な考え方として重要なのは、「将来的には内製化に移行することを見据えた人員配置」を最初から考えておくことである。よくありがちなのは、将来的なビジョンなしに開始時の人員配置を決めてしまうことである。ロボットの開発や管理などをすべて外注に頼ってしまい、内部の人間と外注で完全に分業してしまうことがよくある。しかし、そうすると、内部の人間でRPAプロジェクト全体を把握している人がいなくなってしまい、外部委託業務がブラックボックス化して、見えないコストを払い続けることになりつつ、その部分の変更管理がとてもやり辛くなるという従来のIT管理と同じ問題を抱えてしまう。

 そこでお勧めなのが、内部の人間が概要を把握すべき重要な役割については、最初は外部委託を入れつつも内部の人間も同時につくようにしてスキルを上げていき、徐々に内部の人間に引き継ぐ体制を取っていくことである。たとえば、以下のような役割を含む体制を組む場合、1年目と2年目以降で徐々に外部委託から内製にシフトしていく人員配置を取るとよいだろう。

  • プロジェクトマネージャ: プロジェクト目標の設定、伝達、リソース管理、進捗管理等を行うRPA プロジェクトのリーダー。プロジェクトの要の存在。
  • アーキテクト: RPA環境、インフラ、導入、拡張性、安全性の管理を行う。
  • ボット開発者: 実際にロボットのシナリオを作成していく開発者。
  • 品質管理担当: ボット開発者が作成したロボットを本番環境に展開する前に品質チェックを行う。
  • サポート: ロボット開発やインフラについての支援、テクニカルサポートを行う。
  • トレーナー: ボット開発者を教育して育てる。
役割 戦略

必要人数

(大規模の例)

1年目

外注割合

2年目

外注割合

プロジェクトマネージャ 最初は外注に立ってもらいノウハウを学びつつ、社内調整は先頭に立つ。プロジェクト運営をマスターしたら完全内製する。 1~2 50% 0%
アーキテクト 最初は外部の専門家に任せつつ、内製リソースでリードできる体制にシフトする。 4 100% 70%
ボット開発者 現場の市民開発者に任せる場合と外部委託する方法がある。100%外注にはせず、内製リソースを育ててオーナーシップは現場部門に持ってもらうのが良い。100%外注にすると、オーナーシップ感が薄れる。 多数 70% 70%
品質管理担当 開発は外部に委託したとしても品質管理は内製化を目指し、動いているロボットの内容と品質はきちんと把握するようにする。認定資格取得を目指す。 1~2 50% 0%
サポート ここはある程度外部委託に頼れるところ。 6 100% 70%
トレーナー 初期は外部委託に頼れるところだが、組織内でも認定資格を持ったトレーナーを育成しておくとボット開発者内製に大きく貢献できる。 2 100% 50%

 

最初に小さな成功をつかみ取るためのアジャイル開発

 人員配置を正しく行ったうえで、初期プロジェクトを開始していくにあたり、業務の選定や自動化の進め方についても、押さえておくべきポイントがある。その中でもポイントとなるものとして「いきなり大きすぎる目標を追わない」ということが挙げられる。プロジェクトが始まったばかりの時は、組織内の関係者もまだRPAに懐疑的な人も多く、小さな成果であってもなるべく早くRPAによる成果を挙げて、組織内にアピールをする必要があるからだ。

 そのためには、従来行われていたようなウォーターフォール型開発ではなく、試行錯誤を繰り返すアジャイル開発でプロジェクトを進める必要がある。たとえば、従来のウォーターフォール型開発では、いくつかの工程を経てタイヤ、シャーシ、ボディなど車の部品を作っていき、最終的にそれらをくみ上げて車を完成させる、といった手順で成果物を出力していた。しかし、この方法だと、車が完成する段階までは、其々のパーツは単体では役に立たないため、早期に成果を見せる (=乗り物に乗る) ことができない。一方、アジャイル開発では、最初はスケボーのようなすぐに作れるものを作成し、小さな成果ではあるが実際に活用できる (=乗れるもの) ものを生み出す。その後、三輪車、自転車、バイクなど、構造がより難しいが、成果が出るものを順番に作成していき、最終的に車を完成させる、という手法を取る。

 このような、顧客に価値を提供できる最小限の製品 (実用最小限の製品、Minimum Valuable Product)をいかに早く生み出すか、ということが、RPAの開発については問われることになる。

 

毎日の進捗を追跡して可視化

 他に大事なことは、RPAプロジェクトの進捗を細かく可視化していくことである。開発者やステークホルダーのRPAに対するモチベーションを維持してプロジェクトに巻き込んでいくことがRPAプロジェクト成功のカギになるのだが、そのためには成果や進捗が定期的に、できれば毎日の単位で見えるようにすることをお勧めする。見える化する項目はたとえば以下のようなものがある。

  • 開発者毎のロボット作成数 (設計中、開発中、テスト中、リリース待ち、運用開始の数)⇒部門別、ロボットの種類別に集計
  • RPAにより削減された時間の合計 (運用開始されたロボット数と、ロボット毎の削減時間から計算)⇒部門別、ロボットの種類別に集計。金額に換算するのも良い
  • 部門別トレーニングを受けた開発者の数

 これらは目標値とともにグラフ化をして表示し、関係者から見えるところに置いておくとさらに効果が高いだろう。目標値は時間の経過の関数として通常は直線で表示される。それに対する実績値を一緒に表示することで、日々の進捗管理が可視化され、関係者が目標を達成しようという意欲を掻き立てることになる。外部委託先にも共有できる数字は共有するとモチベーションアップになるだろう。

 ちなみに、目標値は大きく超えればよいというものでもなく、超えすぎていると逆に品質が雑になっている可能性があるため、あくまでも目標に沿った達成を行うことが好ましい。

 

まとめ

 この記事で見てきたように、外部委託を活用する手法は、リソース不足を補う手段としてありだが、手法を間違えると従来の硬直化したIT管理と何ら変わらないプロジェクトになってしまう。外部委託を使う際には、どの場所でどの期間どのように活用すべきかを最初によく考えたうえで、期限を切って活用することを考えることをお勧めする。そして、その間にできるだけ内製でカバーできる力をつけ、企業文化を変革していくことが望まれる。

 

情報処理推進機構「IT人材白書2017」/ 総務省平成30年度版情報通信白書