エンジニアの発する、「にゃ～ん」は、結構な割合で、辛いとき・悲しいときの、魂の叫びだと思います。
0. 前提（おねがい）
この記事は、
- RPAの、導入や運用が、失敗しやすい理由
- それを改善するための、手法の案
で、構成されています。
その前提ですが、改善手法の案は、全部をやる必要はなくて、できるところから、やれば良いですと、最初に書いておきます。
理想的なプロジェクト運営は、文字通り、理想です。でも、皆さんの眼前にあるのは、現実です。
それに対して、「理想か、現実か」の「0/1思考」で、用いるためではなく。
この記事は、「ちょっとずつ、理想に近づけるための、指標や、考え方の補助、アイデアなど」として、お伝えしたいのです。
では、本題に入りますね。
1. なぜRPA導入・運用が、失敗しやすいか
RPAの導入は、難しい、と、よく聞きます。
- 検証する、時間がない。
- 動作が、不安定。ちょっと想定外があると、止まる。
- 覚えるのが、大変。簡単と言われたけど、そうでもない。
- 現場の人に、負荷がかかる。あるいは、協力してもらえない。
RPAに、仕事で携わる人であれば、こういった声を、どこかで、聞いたことがありませんか？
先に、結論を書くと、これらの問題は、本質的には、RPAだけの、特殊な原因・理由などでは、ありません。
ただ、企業・組織での、RPAの導入は、影響範囲が大きくなりがちだったり。
他のソフトウェアより、自由度が高い分、工夫が必要だったり。
そもそも、導入の目的への、認識が、人によって、違ったり。
そういったことの、積み重ねが、RPAの導入・運用を、難しくしている部分が、あるように思えます。
これでは、誰も幸せに、なれません。
そこで、この記事では、RPAの導入を、安定させるための、材料として。
プロジェクトマネージメントの、観点から、
- 失敗しやすい、という原因の、詳細
- 組織や、プロジェクトとしての、RPA導入
の、2つの軸で、RPAの導入を、より、成功しやすくする、考え方を、お伝えします。
2. 原因を、分解する
2-1. RPAの導入はシステム開発、RPAの運用はシステム運用です
前提として。RPAは、ソフトウェアです。その上で構築される、自動化のための機能は、システムです。
ですから、RPAを導入するには、システム開発や、運用保守の、プロジェクトと、共通する部分が、たくさんあります。
「プログラミングができなくても、RPAはできる」とか、「RPAは簡単」という、セールストークは、よく聞きます。
これは、嘘では、ありません。ソフトウェアの操作としては、大抵のRPAは、プログラミング環境より、簡単に作られています。
ただし、それは「動作を、制御することの難易度」です。その周辺にある要素は、プログラミング、すなわちシステム開発と、大差はありません。
この違いは、大型トラックと、一般乗用車の違いだと、思ってください。普通のシステム開発が、大型トラックで、RPAが、乗用車です。
運転操作の難易度は、乗用車のほうが、簡単です。
しかし、守らなければいけない交通法規は、トラックも乗用車も、ほぼ同じです。事故防止のための、ルールやマナーに、大きな差は、ありません。
また、維持するのに、税金の支払いや、駐車場の手配、車検など、やらなければいけないことのリストで、考えれば、大差はないのです。（個々のコスト、たとえば駐車場の費用などは、違いますけれども）
つまり、プログラミング等の、技術は、RPAの方が、簡単でも。システムの、開発や運用、そのためのプロジェクトとして、考えるべきこと、学ぶべきことは、実は、大きくは違わなくて。
そこを、疎かにしてしまうことが、「思うように成果が出ない」「導入に失敗する」の原因ではないでしょうか。
そこで、本稿では、一般的な、システム開発のプロジェクトでの、失敗の原因になりやすい要素を。RPA特有の事情も加味して、解説したいと思います。
2-2. システム開発が、失敗する理由
2-2-1. 成果や、目的の、不一致
どのようなプロジェクトであれ、成果を求めることに、違いはありません。（「成果物」ではなく「成果」です）
言い換えれば、成果を求めることの、目的は、極めて重要です。
ところが、RPAの導入では、この目的意識が、正確に共有されていないことが、多々あります。特に、うまくいっていないRPAのプロジェクトでは、この傾向は顕著です。
よくある目的を、列記してみます。もちろん、これ以外にも、目的はあるかもしれません。
- 雇用コストの削減（残業抑止・バックオフィス人員の縮小）
- アウトソーシングの削減
- オペレーションミスの減少
- 従業員が、他の業務をする時間を作る
- デジタル化を行っているアピール
もちろん、目的が、この中の1つだけとは限りません。むしろ1つだけである方が、少ないでしょう。
いくつかの項目は、さらに、具体的な指標（KPI）を、設定することも可能です。
さて、この目的が、きちんと共有されていないと、プロジェクトは、迷走しやすくなります。
目標の優先度や、KPIがどうなっているか。その認識に、齟齬があれば、メンバーの行動の方向性が、変わります。（KPIの、決め方、妥当性についても、後述します）
2-2-2. ステークホルダーを、把握できていない
ステークホルダー。いわゆる利害関係者です。
これを、プロジェクトを推進する人が、正しく把握できていないことは、失敗の原因になります。
そもそも、RPAの導入を行う主体が、企業・組織によって、異なります。
- いわゆる「情シス」が、兼務で行う
- 組織内の、部門・部署が、独自に導入する
- RPA導入の、部署/プロジェクトが、作られる
どうあれ「情シス」と「RPAで、業務を自動化する、部門・部署」は、当事者になります。更に言えば、どちらも「部署・所属」ですから、そこのメンバー全員が、ステークホルダーに、なります。
他にも、
- 労働時間の、削減などが起きれば、人事／労務
- 派遣社員に依頼している業務や、アウトソーシングしていれば、その契約先
- 自動化する、業務に関わる、取引先や、顧客
- 業務に、法的な規制や要求があれば、法務部門
- 社内システムの、保守管理を、外注していれば、その外注先
- 社内で、ソフトウェアを導入していれば、そのベンダー
- RPAソフトウェアの、販売元ベンダーや、パートナー
なども、ステークホルダーたり得ます。
プロジェクトによる成果や、プロジェクトのあり方によっては、ステークホルダーにとって、リスクや、不利益が発生することもあります。それに対する、事前の、合意の有無は、かなり重要です。
つまり、ステークホルダーの見落としがあり、必要な、コミュニケーションが、とれていないと。
途中で、横やりが入ったり、前提条件の変化に、つながります。それがそのまま、思わぬ障壁となったり、プロジェクトが躓く、原因になったりします。
（**ステークホルダー＝関係者、ではありません。**たとえば、厳密には、自社の競合会社も、プロジェクトを進めることで、「ライバル企業が、業務改善により、コストや品質面で改善する、かもしれない」という影響を受けるので、ステークホルダーたり得ます。でも、わざわざプロジェクトには、巻き込まないですよね？ ステークホルダーすべてと、コミュニケーションを行う、必要はありません。あくまで、ステークホルダーを明確化した上で、必要に応じて、どれくらい、どういったコミュニケーションを、行うか、判断する必要があります）
2-2-3. 利益の分配が、正常でない
原則論で言えば、多くの企業は、究極的には、そのオーナー（株式会社であれば、株主）のものです。
とはいえ、株主が、細かいことまで意思決定に関わることは少なくて、多くの場合、最終的な意思決定は、経営者（経営陣）が行います。たいていの企業は、そこから、階層的な構造に、なっていて、さらに細かい意思決定や、フィードバックが行われます。
あるいは、それが公的機関でも、階層があり、意思決定や、管理する人がいる点は、変わりません。
何が言いたいかというと、身も蓋もないことを言えば、組織の中で、人は平等ではありません。そして、人は、立場を利用して、利益を求めます。
当然、上位にいる人の、意思は。そして、利益は。ある程度、優先されてしまいます。
とはいえ、人は、利益なしには、基本的には、動きません。
この場合の、「利益」は、狭義の、すなわち金銭的なものではなく、「メリット」と言い換えるほうが、すんなり来るかもしれません。たとえば、「給料は変わらないけど、仕事が楽になる」とか、「精神的にイライラせず、仕事ができる」とか、あるいは、「達成感がある、褒められてうれしい」も、利益です。
こういう話を、書くと、志が低いとか、俗物的とか、言われるのですが。
私は、上記のような、広義の利益（メリット）なくして、動く人こそ、ビジネスには向いていない、あるいは、プロジェクトを失敗させる要因になりやすいと、感じます。
なぜなら、利益（メリット）が、損害・コスト（デメリット）を上回る限り、動いてくれる人とのほうが、お互いに、いわゆる「Win-Winの関係」を、築きやすいからです。
さて、少し脱線しかけましたが、プロジェクトが失敗する原因は、「利益の分配が、正常でない（うまくいっていない）」場合に、よく起こります。
言い換えれば、前項に記載した、ステークホルダーのうち。少なくとも、直接プロジェクトに、携わる、人や組織の中で。
「利益を得られない」人や組織がいると、その人の、プロジェクトへの協力を、期待しにくくなるからです。
もちろん、全員が同じように、利益を得られることは、理想ではあっても、現実的ではありません。前項で、記載したように、ステークホルダーにとっての、リスクや損失すら、プロジェクトの中では発生し得ます。
また、最初に書いたように、組織の中で、権力が強い人に、優先的に利益（メリット）を用意しないと、プロジェクトを進める上で、必要な意思決定が、得られないこともあります。
そういったことを、勘案した上で。
「利益が得られない」人が、プロジェクトの重要な部分にいると、失敗のリスクは、大きくなります。
権力による、勾配や、そもそも、利益として用意できる、リソース・メリットに、上限はあるので。「実際に、うまく分配するのは、難しい」というのは、正しいです。それでも、やはり、ここは重要な視点になるのです。
RPAに、限らないことですが、「利害関係者の、協力が得られなくて、プロジェクトが失敗した」経験、多かれ少なかれ、ありませんか？
それを、思い出してみてください。少なからず、利益の分配が、うまくいっていなかった部分、ありませんでしたか？
2-2-4. 不確定さと、考慮不足を、混同している
世の中には、不確定なものがあります。
たとえば、明日、隕石が落ちてきて、会社がなくなるかもしれません。大地震で、都市機能が麻痺するかもしれません。
というのは、極端な例ですが。
RPAで動かす、外部のサービスが、バージョンアップで、画面が変わるとか。
法律や、規制の変化で、業務のやり方が、変化するとか。
取引先の、送ってくるデータの、形式が変わるとか。
様々な「不確定の／～かもしれない」要因が、あります。
それらを、すべて事前に決めて、あるいは想定して、動くことは、不可能です。
故に、プロジェクトを進める上で、不確定なことを、不確定と認識した上で。あえて、進める必要が出てくることは、当たり前に存在します。
ですが、それはそれとして。
不確定なことでも、一定の発生率や、リスクを伴うことは、きちんと「想定した上で、対策するか、あえて放置するか」等の、判断が必要になります。
また、単純に「プロジェクトメンバーが知らなかった」「考えていなかった」ことを、前述の「不確定さ」と混同してしまうと、問題が発生した際の、対策（リカバリー）や、再発防止を行う上で、ノイズになり得ます。
2-2-5. 改善や最適化が、行われていない
もはや、陳腐なフレーズかもしれませんが、「ビジネスの環境は変化します」
・・・という、大上段な言い方でなくとも、RPAの、導入や運用をしていて、システムや、アプリケーション、使用するサービスに、変更が加わったり。組織内の、体制や、業務プロセスが、変化したり。あるいは、組織が従うべき、法令や規格に、改正があったり。細かい例を挙げると、きりがないほど、外的要因による変化はあります。
また、RPAの導入だけの視点でも、製品選定やPoCを行うフェーズ、一部業務に適用が完了したフェーズ、自動化がほぼ完了したフェーズなど、内的要因にも、左右されます。
RPAの、運用にしても、最初は手探りでも、ある程度の規模になると、設計書や、管理台帳、運用の手順書など、ドキュメントを充実させる必要が、でてきます。
同時に、適用規模が、広がるほど、運用に必要な工数は、増えていきます。
たとえば、単純に、RPAのプログラムで使用する、ロジック（ワークフローとか、シナリオとか、呼び方は色々あります）の、作り方でも。
色々、作ったり、運用していくうちに、作成作業の生産性を向上させたり、精度や安定性をあげる、ノウハウが溜まってきます。
さて、このノウハウを「昔、作ったもの」に、適用したり。過去には作られていなかったけれども、必要性が指摘されて、作成されるようになった、ドキュメントを追加したり。そういった、過去の成果物の、最適化が行われていないと、だんだん、運用効率を下げていく、原因になります。
逆に、RPAソフトウェアのベンダーや、協力会社が作成した、プロジェクトの規範・基準とか。社内の、システムの運用ルールだとか。そういったものが、現状に則しているのか。形骸化してしまったルールや、現状にあわない規格・仕様を、引きずっていないか。
そういった視点での、プロジェクト内の、規範や方針、規約などの見直しを、定期的に行わないと。
最終的に「必要以上に過去の経緯に縛られて、生産性が落ちる」とか、「古い成果物の、メンテナンスができなくなる」といった、弊害を生み出します。
こういった、棚卸しや、品質の安定化が、疎かになってしまうと、プロジェクトが、不安定になりがちなので、それは、避けるべきです。
3. RPAの、プロジェクトを、成功に導くには
ここからは「プロジェクトを改善するための、考え方」を、書いていきます。
3-1. 透明性や、わかりやすい方向性があると、プロジェクトは安定します
3-1-1. 「成果」の共有
最初に、はっきり書きます。成果と、成果物は、異なる概念です。
成果は、プロジェクトの目指すところであり、いわば、「プラスに働く結果」です。これは、概念や目標の類です。対して、「成果物」は、成果を出すための物です。一般的に、アウトプットは、この形です。
多少、語弊があるかもしれませんが、成果は目的、成果物は手段、と考えても、良いかもしれません。
なぜ、「成果物」ではなく、「成果」の共有が、必要なのかと言うと、「成果物の作成が、成果につながる」ことを、担保するためです。
まず、成果物が、どう成果につながるのか（つまり、何をどう改善するのか、どのような利益を生むのか）を、理解していることは、徒労感の軽減になります。やっている作業の、意味が見えないと、多くの人は、ストレスを感じます。
また、間違った方向性、すなわち「成果の目指すところと、求められている成果物にズレがある」ことに、メンバーが気がつきやすくなります。
もちろん、その気づきを、きちんとエスカレーションできる、体制がないと、意味はありません。それについては、次項以降で、説明します。
とにかく、まずは「成果のビジョンを、プロジェクトメンバー全体で、共有すること」が、プロジェクトの安定には、重要な指針になります。
3-1-2. リーダーシップの育成
前提として。
- 権限と、権利と、リーダーであることは、すべて別の要素です
- ここに書くのは、リーダーシップを持つこと（リーダーになれること）であって、権限や、権利の話ではありません
「全員がリーダーシップを持つ」というのは、上意下達の、志向が強い組織だと、少し、なじみの薄い考え方、かもしれません。
ですが、プロジェクトを成功させるために、全員がリーダーシップを持つことは、非常に重要です。
そもそも、リーダーシップとは？と、考えてみてください。
細かい書き方は、色々あると思いますが、
- 全体を見て、必要な決断ができる
- 他のメンバーとの協調関係を築ける
- 利害関係の調節ができる
- 必要な情報を発信できる
・・・ね？ここまで書いたことに、結構、一致しませんか？
組織で活動する以上、権限や、権利は、末端に行くほど、一般的には、少なくなる／狭くなると思います。
だからといって、末端の人に、リーダーシップが不要かと言うと、そうではないのです。
3-1-1項で、成果の共有が、必要と書きました。リーダーシップの重要性も、実は、そこに通じる部分はあります。
プロジェクトとして、何が成果なのかを、共有した上で。「そこに向かっていくことを、確実にするために」リーダーシップが、必要になります。
さて、リーダーシップの育成に、必要なことは何でしょうか。
特に重要なのは、「心理的安全性が、確保されていること」、言い換えれば、「コミュニケーションが安全であること」だと思います。
プロジェクトを、進める上で、意見や見解、主張の相違は、どうしても発生します。
そこで「問題」ではなく、「人」に焦点が当たると、だいたいの場合、人間関係の悪化が、加速します。たとえば、主張する側の、どちらが偉いから、とか、誰が言ったから、というベクトルでの、解決は、何かしらの、しこりを残します。
あるいは、問題を見つけたことを、問題視してしまうと、発見された問題が、報告されなくなります。最近、某メガバンクのことが、よく話題になりますが、まさに「事なかれ主義」が横行して、システムの開発や、運用が、失敗した例と言えるでしょう。
コミュニケーションの、リスクや負荷が大きくなるほど、リーダーシップが抑制され、結果として、失敗のリスクが高まります。心理的安全性の、確保は、そのままメンバーの生産性に直結します。
3-1-3. 利害の一致と、共通認識が、図られていること
2-2-3.項に、書きましたが、利益（利害）が、きちんとコントロールされていないと、プロジェクトの進行を、阻害する要因になります。
組織体系や、契約上は、指示・依頼できることでも、やはり、相手側に、どれくらいメリットがあるかで、レスポンスは変わります。
具体的な、例で、考えてみましょう。
契約社員として、雇用している人に、「あなたの業務を、自動化します。完了したら、契約は切るので、さようならです」と言ったら、本気で、協力して貰えるでしょうか？あるいは、社内システムの、開発元に、「保守作業を、自動化で巻き取るので、仕様を開示してください。その後は、保守費は減らします」と言って、十全な協力が、得られるでしょうか？
もちろん、契約上、相手が、協力をせざるを得ない場合、ある程度の協力は、得られるでしょう。
ですが、上記のようなに、協力する側から見て、プロジェクトの成果が、自身のデメリットになる場合に。その人の視点で、プロジェクトを、失敗させうる要因を、見つけても、それを教えてもらうことは、期待できません。
こういった、消極性による非協力的な振る舞いを、道徳や、精神論で、非難することは、建設的ではありません。そもそも、それは、相手の立場を無視して、道徳の名の下に、損害を強いているだけです。
この問題に、対応するためには、2つのアプローチがあります。
1つは、プロジェクトの目的達成により、メリットよりデメリットが大きい人や組織に、何かしらのメリットを、バーターで用意して、協力する動機を作ることです。
もう1つは、メリットを用意できないとき、諦めて、その人や組織からの、協力を、諦める（契約等で担保される、最小限のものと見なす）ことです。
どちらにしても、プロジェクトの、方向性と、利害関係を、明確化し、それに対処することで、プロジェクトは安定します。
3-1-4. KPIを、明確にしましょう
KPIは、何かしらの、プロジェクトで達成すべき、目標を、数値化したもの、と考えてください。
プロジェクトの、成果を、明確にする必要は、前に述べました。
さて、そこで問題になるのが、「どうやって、成果を達成したかどうか、確認するか」です。
逆説的ですが、数値化できるものが、正しい「成果」の設定です。数値化できない場合、それは、目的の共有や、利益の分配に、悪影響を及ぼします。
たとえば、メンバーは、成功したと、思ったのに、明確でない理由で、失敗と判定され、評価が下がる、とか。そういった問題を、回避するために、KPIは、プロジェクトを進める上で、必ず設定し、合意される必要があります。
（言い換えれば、KPIの合意が、成果の共有になります）
3-2. プロジェクトの、ポートフォリオを作りましょう
「ポートフォリオ」と聞いて、何をイメージしますか？
金融分野だと、複数の投資先のセットだったりします。
就職活動だと、学習や、各種活動の、記録をまとめたもの、でしょうか。
プロダクト・ポートフォリオ・マネジメントという分野もあります。
ここで書くのは、どちらかというと、就職活動の、ポートフォリオに近いでしょうか。
この文章で、今まで、書いてきた要素。
- プロジェクトの、目的（成果）と、KPI
- ステークホルダーの、一覧
- スケジュール
- 想定される、成果物
- 規範や、規約の場所
こういった、情報を、一元化して、メンバー全員が、すぐ見られる場所に、置いてみてください。
（スケジュールや、規約などは、ポートフォリオに、すべて記載すると、冗長になるので。スケジュールであれば、マイルストーンだけ。規約であれば、リンクと、目的や概要だけ。記載すれば、良いと思います）
そして、ポートフォリオは、作って終わりではありません。
**ポートフォリオに、沿わない、活動や、作業がないか？情報に、抜け漏れが、ないか？**という、観点を、常に、メンバーが持ち。
もし、沿わない何かや、情報の抜け漏れが、あれば。それを、記載するとともに、「なぜ、その情報が抜けていたか」「そこの変更で、他に影響が発生しないか」という、見直しを行うことが、プロジェクトの安定に、寄与するのです。
3-3. CoEのすすめ
組織によって、RPAを進めるのも、現場部門だったり、情報システム部門だったり、あるいは、独自の部門だったり、しますが。
RPAの、導入や開発、運用を、プロジェクトとして、成功させるには、CoE（Center of Excellence）を、作ることを、おすすめします。CoEとは、組織の中で、RPAを推進するための、中核となる部署、といったニュアンスでしょうか。
RPAの、導入や運用は、ともすれば、従来のシステム開発・運用以上に、ステークホルダーが多くなります。
また、どのような製品（RPAのソフトウェア）を使用するにしても、良くも悪くも、他のシステムとの境界が、曖昧になりがちで、従来の、システム開発の手法が、そぐわない部分が、多かれ少なかれ、出てくるのが常です。
前項までで、情報の共有・可視化や、プロジェクト内での利害調節、リーダーシップの共有が、必要と記載しました。これらを、主体的に行うには、組織内で、ある程度、独立していて、リソースもある、部署でないと、難しいからです。それが、CoEに該当すると、考えています。
また、CoEが、主体的に、RPAの導入・推進を、行うことで、組織内での、整合性がとれた、導入が容易になります。これは、内部統制や、長期的な運用計画、全体最適の維持、人員の育成など、多くの面でメリットがあります。
3-3-1. 強権型から、分散型への、ゆっくりとした推移
CoEを作り、RPAを進める、メリットの1つに、推進する部門の、あり方そのものを、コントロールできる点があります。
よほど、条件が整った組織でない限り、RPAの導入は、漸次的に行われることに、なります。
これは、「導入が進んでいる部署と、進んでいない部署」および、「（部署内で）自動化が進んだ業務と、未着手の業務」という、2つの軸になるので、尚更です。
さて、最初のうちは、RPAを導入する上での、規則や、ガイドライン、あるいはロジック（ワークフロー／シナリオ）の作成方法などを、やや四角四面に、進める必要があります。きちんとしたガイドラインなしに、手当たり次第に進めると、内部での、互換性や、管理性を損なうからです。
（実際には、PoCや、最初期の導入では、規則や、ガイドライン、運用ルールの整備が間に合わないことが、多いので。規則などが、整ってから、最初期の成果物は、整った規則に基づいて、リビルドが求められると、思います。）
ところが、ある程度、進んでいくと、正当な理由があって、ガイドラインとあわない事態が、発生します。たとえば、特定の法律に絡む業務は、自動化の際に、通常のレビュープロセス以外に、法務部のチェックが必要になる、とか。取引相手の、使用するシステムを、自動化で操作するのに、社内規約に、反する実装が、必要になるとか。
もちろん、それらの状況で、ルールに反するプロセスの、必然性はレビューされる、必要がありますが。必要であれば、これらの事態に対して、ルールをむりやり強制するのも、あるいは、その例外のために、ルールを変更するのも、あまり、建設的・経済的ではありません。
つまり、適宜、ルールに対する、特例が、運用上、必要とされるようになります。これは、よほど小さい組織でなければ、必然と思って、問題ないと思います。例外が必要ない、組織や業務運用は、理想ではありますが、なかなか現実的ではないので。
問題は、そういった状況に、どう対応していくかです。ここにも、CoEを主体とする、メリットがあります。つまり、どれくらい、強権的に、ルールを遵守させるのか。あるいは、例外を認め、部門側に、自動化プロセスの運用を、委ねるのか。その「体制をゆっくり変えていく」コントロールを、CoE自体が、主体的に行えるからです。
3-3-2. アジャイル開発の、管理
よくある、プロジェクトの進め方の、対比として、
- ウォーターフォール型
- アジャイル型
というのが、あります。ウォーターフォール型は、要件定義、設計、開発、テスト、リリースと、段階を追っていき、基本的には、フェーズを戻さず、順番に進める方式です。対して、アジャイルは、トライ＆エラー的に、改善していく、方式です。
不確定と、考慮不足については、2-2-4項に、書きました。さて、考慮不足を、完全に排したとしても、現実的には、RPAの開発・運用では、不確定なことは、発生します。
不確定・変化への、対応を考えたとき、ウォーターフォール型での、開発は、手戻りや、混乱の原因となりがちです。
システム開発で、ウォーターフォール型が、用いられる理由は、いくつかありますが、たとえば、開発の委託・発注をする際、契約範囲を、明確にしやすいから、という点があります。
しかし、RPAの場合、これは、お勧めしません。前述したように、不確かさや、変化への適応を考えると、ウォーターフォール型の開発では、成果物は得られても、成果が出せない（あるいは、一時的にしか、得られなくなる）可能性が、高いからです。
この問題は、本格的に踏み込むと、大変、難しい部分です。外注の管理は、それなりに、コストになるからです。
ただ、最終的な（あるいは、長期的な）成功を、目指すのであれば。CoEの中に、外注先の、管理者も巻き込む、あるいは、KPIを定めて、その達成率で、インセンティブをつける等、継続的に、利益が得られる形で、契約を続けるほうが、安定するかと思います。
4. 最後に -RPAは、誰のため？-
会社や、組織において、RPAは、誰のためか？という点は、割と、見過ごされています。
これは、裏を返すと、RPAをなぜ、導入するか、という視点そのものが、不安定になっている証拠です。
そういう状態では、「自動化すること自体が、目標になる」とか、「目標が定まらないまま、物事を進めて、後付けで目標を探す」という、本末転倒なことすら、発生します。
- まず、戦略目標があり
- そのために、業務があり
- 業務達成の手段として、自動化があり
- その、全体最適を維持するための、方法が、RPAである
という点を、見失わないように、してください。