RPAの開発は「コーポレート情報技術部主導による開発モデル（CoE）」と「各事業部のエンジニアが主導するプラットフォーム利用開発モデル（FED）」を同時並行で実施した。ただし、FEDを自由にしすぎるとガバナンスの観点から収拾がつかなくなることを鑑み、FEDに携わるメンバーには事前にトレーニングを受けてもらい、ロボット開発後のメンテナンスは、コーポレート情報技術部が実施するよう取り決めた。
そして、運用サイクルを回しながらプロセスを改善して開発を進めた結果、約1年間で101プロセス（ロボット）の構築を達成した。その内訳は、CoEのロボットが40％、FEDが60％で、月間で1300時間の業務時間削減に成功したとのことだ。
RPAの開発モデルは、コーポレート情報技術部主導と各事業部のエンジニア主導を同時並行で実施している
とはいえ、RPA導入を進める過程では、さまざまな軌道修正も余儀なくされた。その1つが組織体制だ。当初は3つのサブチームを運用していたが、「スキル不足」「リソース不足」「曖昧なロールの定義」「品質プロセスの形骸化」といった課題が噴出し、プロジェクトの遅延が発生してしまったという。内藤氏はその原因を以下のように説明する。
「ビジネス分析担当者は、Blue Prism開発に関する知識が十分でなかった。その結果、開発側からの手戻りが多くなってしまった。予想以上に案件が増加し、リソースが不足することもあった。また、チーム間同士のロール定義が曖昧だったため、引き継ぎがうまくできていなかったこともあった。さらに、複数のチームに別れていたので、（ロボットの品質確認を）“エンドトゥエンド”で担当する人の責任と担当も曖昧になってしまっていた」（同氏）
こうした課題を解決するため、楽天では4つのサブチームを構成し、ロボットを“エンドトゥエンド”で担当するプロデューサーを配した。また、スキル不足の解消には、これまで午前9時から午後6時までだったサポートデスクをインドにアウトソーシングすることで、24時間体制にした。さらに、コーポレート情報技術部メンバーのタスクをプロセスごとに可視化し、作業責任を明確化した。
なお、現在はRPAプラットフォームの構築と平行し、事業間で共通利用可能なオブジェクト開発に注力している。汎用性の高いアクションをコーポレート情報技術部が収集し、共通利用可能なライブラリとして提供することで、ロボットの開発生産性向上に取り組んでいるという。
共通利用可能なオブジェクト開発でロボット開発の生産性向上を目指す
内藤氏はこれまでの運用で得た教訓として、「自動化する業務対象は定常化したものにし、これまでやったことがない業務の自動化は避けること」「現場の細かい業務の知識がない“名ばかり業務担当者”には注意すること」「担当者が入れ替わってもスムーズに引き継げるよう、ドキュメントに残す作業を怠らないこと」を挙げた。
もう1つ詳らかになった課題は、「事業部側の期待値とのギャップ」だという。RPAは“デジタルレイバー”であり「落ちないシステムではない」ことを伝えた上で作業可能な範囲を理解してもらう必要があるとのことだ。
内藤氏は「RPAの開発は簡単だが、慣れも必要になる。最初は小さく開始し、慣れてきたらスケールするのがよい方法だと考えている」と総括して講演を締めくくった。
