何でもRPA化で無法地帯……秘伝のロボ術で起死回生した百貨店企業

2016年からRPAを導入し、年間4600時間分の削減したＪ．フロント リテイリング。しかし、その過程では「IT部門が関与しないところでRPAが作られ、“無法地帯が生まれる」といった苦労を経験した。苦労の中で編み出した、秘伝のロボット活用術を紹介する。

[齋藤公二，インサイト]

　「大丸」や「松坂屋」といった百貨店、「PARCO」などの商業施設を全国で展開するＪ．フロント リテイリングは、2016年にRPAを導入して48業務で年間4600時間分の削減に成功した。順調に思えた業務改善だが、実態は「無人島に取り残されたような状態」に陥った。

　山積する課題に対し、「ロボット作成の『内製化』による開発スピード倍増」を打ち出す。ここでいう内製化とは、外注による開発から社内の開発部隊による独自開発に移行することではない。「Microsoft Excelの式は書けてもマクロは書けない」レベルの現場スタッフでもロボットを作れる状態の実現だ。同社の挑戦を紹介しよう。

「何でもRPA化」で無法地帯になる

　「RPAはコンサルタントの力を借りて導入したのですが、実際の運用フェーズに入るとどこに他のユーザーがいるのか分からず無人島に取り残された状態になります。もっと効率的な方法があるのではと思っても確認のしようがない。RPAの取り組みは常にそうしたジレンマと背中合わせでした」

　こう振り返るのは、Ｊ．フロント リテイリング 業務統括部 シェアードサービス推進部の石井勝也氏だ。同社のロボット開発はIT部門の4人でスタートしたが、1年あまり運用を続ける中で内製は絶滅の危機に瀕した。

　そこで「内製化」を再定義し、今後1年間で100業務を対象として1万時間を削減することを目標と定めた。「内製化とは情報システム部がITベンダーに依存せずに開発するという意味ではなく、ITスキルが高くない人でも開発できることを指します。例えばExcelの式は書けてもマクロは扱えないという人がロボットを作れる状態です」（石井氏）

　課題は3つに大別できた。トータルコストが下がるのかを考えずに「何でもRPA化」してしまうこと、社内で設計だけ済ませて後は「何でも社外エンジニア頼り」だったこと、IT部門が全く関与しないところで開発が行われる「技術的な無法地帯」だったことだ。

RPA化する「価値」がある業務を算出する

　3つの課題は「コスト算出」と「手順の作り方」に起因する。石井氏はこれらに対する考え方を変えることから着手した。

　コストは「5年間のトータルコスト（開発コスト＋ランニングコスト）」で考えている。ロボットのライフサイクル（減価償却）を5年、保守工数を1人月（同社では1人当たりで年間に45ロボットを開発すると想定した）としてモデル化した。

　「当社の場合、1カ月当たり8〜9時間の業務を5年間まわしたときのコストがおおよそRPA化のコストと等しくなります。これは年間100時間の業務ならRPA化する、それ以外ならば別の手段も考えるということです」（石井氏）

　コストは誰が開発するのかでも変わる。単純に考えれば、RPA化が進めば人材が余るようになる。開発を外部に委託すると内部の人はますます余るようになると同時にコスト高にもつながる。内製化を進めれば余剰人員が生まれることもなくなり、業務だけが効率化されるわけだ。現在、内製が9人、外部委託が3人という陣容だ。

RPA開発、運用業務の半分以上は内製できる

　内製化の主体はシステム部門ではなく現場のエンドユーザーだ。「RPAの開発工程の全てが難しいわけではありません。内部のスキルでできる部分が半分以上あり、内製工程と外製工程に分割できることも分かりました」（石井氏）

　まずは社内で「できること」と「できないこと」を調べた。「業務フローを描く」「サンプルを見て再現する」「テスト」「運用」などは内部で実行可能で、「フローチャートを描く」「リファレンスマニュアルを利用する」「デバッグ」「トラブルシューティング」などが難しかった。

　これを基に内部メンバーと社外エンジニアの役割分担を決めた。「業務ヒアリング」「業務フロー作成」「業務説明」「パーツ組み立て」「テスト・運用の切り替え」を内部で担当し、「ロジック立案」「共通部品仕様立案」「共通部品作成」「デバッグ支援」などを社外のエンジニアに委託する。

　「社外に出している開発や運用作業のうち、半分くらいは内製化できます。プログラムに必要な要素をまとめる『基本骨格』をExcelのテンプレートで用意し、エンジニアにわたすところまでを自分たちで記入してもらうようにしました」（石井氏）

　テンプレートは小学生用のプログラミングツール『Scracth』をイメージして作成した。条件分岐などを考慮した骨格が作成できる。この他、やりたいことを起点に方法を調べられる「BizRobo逆引きリファレンス」、再利用の需要がありそうなコードをパーツ化して共有できるようにした「パーツライブラリ」などを提供した。

BizRobo逆引きリファレンス

非エンジニアでも「コピペ感覚」でRPA開発

　石井氏は「業務を再利用可能な部品に分解し、部品の作成をエンジニアに、部品を利用したロボットの組み立てを内製メンバーが分担して行う体制です。ポイントは内製メンバーの作業から複雑さをいかに排除できるかでした」という。

　だが、RPAツール特有の課題に直面した。「部品化を阻む変数スコープ」「try/catchによるエラー処理」「複雑な条件分岐」「表データの変形」「GUIプログラミングのレビューの煩雑さ」が複雑さの排除を阻んだ5つの要素だ。特に「try/catchによるエラー処理」はエンジニアではない内製メンバーには理解しにくいものだった。

　そこで独自の工夫や改善を行い、「コピペ感覚」で部品を組み立てられるようにした。具体的には、再利用可能パーツの前後でパラメータを内部変数に変換したり、後処理でtry/catchのエラー処理を行うようにしたのだ。

　石井氏は「RPAの取り組みは孤立無援に陥りやすく、ユーザー同士がどんな工夫や改善を行っているかも見えにくくなります。情報を共有しながら取り組みを進めていくことが重要です」とまとめる。石井氏自身もメールやFacebook、Slackなどで情報公開や共有に積極的に応じている。

部品化を阻む変数スコープとtry/catchによるエラー処理の対策

本稿はRPAテクノロジーズ主催「BizRobo! LAND 2018 Tokyo」で行われた講演「外注依存から脱却しロボット開発を内製化した、その手法にまつわるちょっと技術的な話」を基にしています。