プロジェクトを成功に導く8つのポイント(4)：適切な体制作り
プロジェクトを推進するには、適切な体制作りが不可欠です。適切な体制とは、自社の企業規模、組織体制、プロジェクトのサイズ、アプローチ、スキルレベルに適したプロジェクト推進体制のことです。たとえば大規模プロジェクトにもかかわらず、全体をコントロールする事務局を作らなかったり、RPAのスキルレベルが低いにも関わらず、サポート体制を用意しなかったりすると、当然プロジェクトはうまくいきません。
適切な体制は一義的にプロジェクトサイズに依存します。ここでは具体的な体制の選択肢と留意点について、小規模プロジェクトと大規模プロジェクトに分けて説明します。
小規模プロジェクトの推進体制
小規模プロジェクトとは、中小企業が少人数でRPA導入を行うケースや、大企業が１つの部門を対象に小さく始めるケースを指します。小規模プロジェクトが取りうる推進体制は、次の３つのパターンが考えられます。
①社内のみの体制
スモールスタートで多いのが「社内のみ」の体制です。自分たちでRPAを勉強しながら、「できるところからやってみる」というアプローチです。取り組みに時間がかかりますが、費用は低く抑えられ、リスクも小さいため、トライアルのような位置づけで進めやすい体制です。状況を見て必要であれば拡大すればよいでしょう。
②社内＋技術支援の体制
小さく進めるにしても技術的に不安がある場合、外部のアドバイザーに参画してもらう体制が考えられます。アドバイザーにはあくまで助言をしてもらうだけであり、RPAの開発は自分たちで行います。社内にスキルが蓄積されてくれば、社内のみの体制に切り替えても構わないでしょうし、同じ体制で規模の拡大やスピードアップを狙うことも可能です。
③外部委託の体制
この体制は従来のシステム開発に近い形です。「餅は餅屋」という考え方で、自社は本業に専念し、システムは外部のエンジニアに任せるという体制です。最も効果を早く刈り取れる体制ですが、その分の費用も多くかかってしまうため、投資対効果をよく勘案する必要があります。中長期的に社内へ技術移転をし、内製化を目指すことも可能ですが、それであれば②のアドバイザー体制のほうが適しています。③の外部委託体制では完全に分業化されてしまうため、従業員の学習効果は期待できないでしょう。
大規模プロジェクトの推進体制
大規模プロジェクトとは、複数のチームが同時並行で取り組みを行うケースを指します。これには次の２つのパターンがあり、いずれのケースも全体を管理する「事務局」が必要です。
事務局とはプロジェクト全体の運営をサポートするチームで、プロジェクトリーダーの補佐役として、プロジェクト全体の計画策定、実行支援、技術支援、進捗管理、課題管理などを行います。PMO（Project Management Office）とも言います。大企業では「RPA推進室」といった組織を常設しているところも少なくありません。
①社内＋技術支援の体制
大規模プロジェクトの場合は、それなりのスピード感を持って進めていくため、技術支援は必須になってきます。上記の体制図では、技術支援を事務局の一部として表現していますが、独立した別のチームでも構いません。
社内に情報システム部門があるなど、技術支援ができる人材がいる場合は社内のみで体制を組めますが、もし社内に適任者がいない場合は外部の専門家に委託する必要があります。いずれにしても技術支援はアドバイスだけであり、実際のRPA開発はユーザーが行うことになります。
技術支援チームを作ることには一定の合理性があります。これはRPAのスキルが組織に散在しているよりも、1か所に集約して組織横断的な活動をしたほうが貴重なスキルを最大限活用できるからです。これをCoE（Center of Excellence）と呼び、RPA導入などのDXではよく用いられる体制です。DXなどへ長期的に取り組む場合には、CoEをプロジェクトチームの位置づけではなく、組織として設置するというのも１つの考え方です。
②外部委託の体制
外部委託の体制は大企業でよく用いられるパターンです。最も費用がかかりますが、最も大きな成果を早く刈り取れる体制です。大手企業の事例で、短期的に何千時間もの業務削減に成功しているケースがありますが、これは社内リソースだけで実現できるものではありません。業務の改善効果が見えている場合は、外部の活用も合理的な手段となります。
外部委託のメリットの１つは、プロジェクト推進に強制力が働き、緊張感を持って進められる点です。社内だけで取り組むと、それほど緊張感もなく、ずるずるとスケジュールが後ろ倒しになりがちです。なぜならば、プロジェクトが少しくらい遅れても誰も困らないからです。しかし、外部ベンダーは一定の期間内に一定の成果をコミットして契約しているため、プロジェクトの遅れなど許されません。企業側の都合でスケジュールを変更するならば、ベンダーから追加費用を請求されるでしょう。つまり推進に強制力が働くのです。
一方、外部委託した場合の課題は、ユーザーによる継続的改善をどうするかという点です。ユーザーが継続的改善を行うことはあきらめて、従来のシステム開発と同じように、システム改修も含めてすべて外部委託するという割り切り方もあるでしょう。また外部委託しないまでも、社内のCoEが対応するという方法もあります。いずれにしても、短期的な効果の刈り取りと、長期的な改善をどうバランスさせるかの検討が必要です。