Upgrade to Pro — share decks privately, control downloads, hide ads and more …

リクルートテクノロジーズの実体験 RPA導入の理想と現実

リクルートテクノロジーズの実体験 RPA導入の理想と現実

2018/09/19 実践的デジタルレイバー導入カンファレンスでの弊社野川の講演資料になります。

Recruit Technologies

September 19, 2018
Tweet

More Decks by Recruit Technologies

Other Decks in Technology

Transcript

  1. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 1 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  2. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪会社紹介:リクルート 2 創立

    1960年3月31日 「大学新聞広告社」としてスタート グループ 従業員数 40,152 連結売上高 21,733億円 ※2017年4月-2018年3月 連結経常利益 1,917億円 ※2017年4月-2018年3月 関連企業数 361社 ※連結対象子会社 2018年3月末 目指す世界観 「あなた」を支える存在でありたい ※2018年3月末
  3. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪リクルートの事業内容について 3 ライフイベント領域

    進学 就職 結婚 転職 住宅購入 車購入 出産/育児 旅行 ビジネス支援 生活/地域情報 グルメ・美容 ライフスタイル領域 選択・意思決定を支援する情報サービスを提供し、 「まだ、ここにない、出会い。」を実現する。
  4. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪リクルートのビジネスモデルについて 4 リクルートには、ユーザーとクライアントという2つのお客様が存在します。

    企業と人(B to C)、企業と企業(B to B)、人と人(C to C)、すべての間に立ち、 双方にとって最適なマッチングを図る「場」を提供しています。 ユーザーとクライアントを新しい接点で結び、 「まだ、ここにない、出会い。」の場を創造する。
  5. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪リクルートテクノロジーズ 5 技術・ソリューションを磨き続け、リクルートの各サービスがもつ価値を

    最大限に発揮できるようビジネスへ実装。 ITの側面からサービスを進化させることを通じて、世の中に新しい価値を 提供していきます。
  6. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪組織紹介 6 DI推進部

    の Mission 私たちはデータ活用技術を駆使することで リクルート・カスタマ・クライアントの 意思決定を進化させ、イノベーションを創出する データ活用技術で人生を豊かに DI推進部 の Vision  株式会社リクルートテクノロジーズ ITエンジニアリング本部 データイノベーション推進部  野川 幸毅 シニアマネジャー  株式会社リクルートテクノロジーズ ITエンジニアリング本部 データイノベーション推進部  野川 幸毅 シニアマネジャー
  7. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪取組紹介 7 目的に沿った解釈性の高い

    レポートとセルフBIの推進 活用優先度の高いデータを 正しく使いやすい形で整備 意思決定を合理化・高度化 するためのプロダクト開発 RPA・DataRobotなど 有用な仕組みを積極活用 BIツール AI 業務支援 ツール データ マネジメント RPAツール × AI × リクルートテクノロジーズ データイノベーション推進部 私たちはデータ活用技術を駆使することで リクルート・カスタマ・クライアントの 意思決定を進化させ、イノベーションを創出する 技術を有効活用し 業務自動化にも着手
  8. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 8 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  9. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ 10 下記3つのClassでの説明が主流に...

    【Class1】 Robotic Process Automation 【Class2】 Enhanced Process Automation 【Class3】 Cognitive Automation RPAは業務効率化・自動化の取組 RPA (Robotic Process Automation)とは、認知技術(ルールエンジン・機械学習・ 人工知能等)を活用した、業務効率化・自動化の取組 決められたルールの 反復作業 大量データによる学習 多様な選択肢 新しい選択肢を提案 処理の例:
  10. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ 11 2019年までに全業務の

    25%が自動化されると予想 RPAを導入した企業の97%が 5割以上の業務工数削減 RPAはフロント・バックオフィス 関係なく、幅広い業務に適用可 RPAの導入スピードは加速 国内導入企業5,000社へ 技術の進化で自動化が加速
  11. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪RPAを進めることで 13 作業1

    作業3 作業2 作業4 作業5 作業6 週 次 で 行 う 定 型 業 務 作業1 RPAが 実行 作業5 作業6 別作業 作業量に人が振り回されるのではなく 「システムでコントロール」できる状態を増やすことで 働き方が変化していく!! 時短 作業ボリュームに合わせ 人の工数調整ではなく システムで調整 例えば… 考える 試す
  12. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪RPAを進めることで 14 作業1

    作業3 作業2 作業4 作業5 作業6 週 次 で 行 う 定 型 業 務 作業1 RPAが 実行 作業5 作業6 別作業 作業ボリュームに人が振り回されるのではなく 「システムでコントロール」できる状態を増やすことで 働き方を変えていく!! 時短 作業ボリュームに合わせ 人の工数調整ではなく システムで調整 例えば… 技術進化により 導入障壁は下がっているものの “実務適応の難易度は高く” トライ&エラーを続けている
  13. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪本日持ち帰って頂きたいもの 15 本日は実際に起きた課題を交え

    取組のポイントを整理してみました。 新組織で業務自動化に向き合い1年… 正直、まだまだ模索中です。 何かしら皆様の検討の きっかけになれば良いと思っています。
  14. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 16 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  15. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪自動化すべき業務とは? 18 ボリューム?

    同じ作業の 業務量が大量なら 自動化すべき? 実施頻度? 同じ作業の 頻度が多いなら 自動化すべき? 実現難易度? 作業の 内容が単純なら 自動化すべき? など
  16. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪自動化すべき業務とは? 19 実施頻度?

    同じ作業の 頻度が多いなら 自動化すべき? 実現難易度? 作業の 内容が単純なら 自動化すべき? など ボリューム? 同じ作業の 業務量が大量なら 自動化すべき? コスト削減 同じ作業の 業務量が大量なら コストが大きいので 可能性が高い
  17. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪自動化すべき業務とは? 20 ボリューム?

    同じ作業の 業務量が大量なら 自動化すべき? 実現難易度? 作業の 内容が単純なら 自動化すべき? など 実施頻度? 同じ作業の 頻度が多いなら 自動化すべき? 働き方改革 頻度が少なくとも タイミングが 早朝や深夜なら 検討の余地あり
  18. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪自動化すべき業務とは? 21 ボリューム?

    同じ作業の 業務量が大量なら 自動化すべき? 実施頻度? 同じ作業の 頻度が多いなら 自動化すべき? など 実現難易度? 作業の 内容が単純なら 自動化すべき? 質の担保 作業内容が複雑で 暗黙知が多いほど 担当依存をなくすため 検討の余地あり
  19. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪自動化すべき業務は目的次第 22 コスト削減

    同じ作業の 業務量が大量なら コストが大きいので 可能性が高い 働き方改革 頻度が少なくとも タイミングが 早朝や深夜なら 検討の余地あり 質の担保 作業内容が複雑で 暗黙知が多いほど 担当依存をなくすため 検討の余地あり など
  20. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪目的次第といっても… 23 業務に適応できない

    技術の理解とともに 求められる質を担保 できなければ 実務適用できない など 技術力が足りない 世の中で言われる Class3:CAなど 技術的未知数が多い ものは別検討で コストが非現実 ビジネスである以上 許容できるコストで 目的が達成できる ことが必須
  21. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪業務に適応できない 24 実現性の観点では、サービスレベルが重要

    実現性 1. RPAツールはリカバリが前提  Class1のルールベースの作業代行に利用されやすい  作業代行なので、人と同じような事象(ソフトが上手く起動しない ネットワークが不安定など)で作業が止まってしまうことが RPAでも起こります  ロボットのリトライ(再実行)や、人が主導でリカバリーできる サービスレベルの業務がRPAに向いている ※開発時に例外処理や自動リトライ処理などを導入中 2. AIへの過剰な期待は注意  Class2の過去データ学習による判断に利用される  過去データからの学習なので、過剰な期待(100%近い精度など)の 達成は難しく、実務適応に至らないことが多い  運用イメージを後回しにすることで、AIで判断したものを 愚直に人が確認し、(仕組みがなく)手間が増えるといったことも 起きやすい…
  22. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ちなみに… 26 明示的に業務自動化チームを発足してから1年

    私たちも改善を繰り返し、様々な目的に向き合うことで 各種相談依頼を受ける状態に進化している  コストインパクト:1.7万時間/年の業務の50%を自動化  処理量の増加: AIで処理しきれていない業務量を実施  働き方改革: 数時間/月を自動化し、早朝作業を削減 などなど 当初はコストインパクトを重視していましたが 目的が曖昧になり、RPAの導入が目的になるプロジェクトも… 特に新しい取り組みは 判断軸が緩くなりやすいので振り返りが必須
  23. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 27 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  24. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪実装難易度が高いポイント 29 開発者の業務理解

    担当者も見落とす 暗黙知が多い ミスの想定が難しく 手戻りが起きやすい など
  25. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪開発者の業務理解 30 要件化の経験が少ない担当者も多いため

    開発者の業務理解が重要 業務理解 1. 暗黙知の手戻りが多い  人の手で担保している業務は、比較的暗黙知で質を担保している ことも多く、この暗黙知は本人も自覚していないことがある  細かく処理を定義できている業務以外は、開発者がしっかり理解する ことが重要  特に業務を見るだけでなく、動画に撮っておくと双方の確認の手間が 減ることが多い 2. 誤処理・誤作動が検知されない  人は経験をもとに、感覚でミスを検知できることが多い  Class1,2では、定義できていないミスを検知することができないため、業務理解が 不足していると、ミスが増えるだけでなく、 誤処理・誤作動を認識できないことも多い  特にAIの領域は、元々の担当者との認識が合わず、想定したものが 正しく実装されていない、ということも起きやすいので注意が必要
  26. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ 開発者の業務理解 担当者も見落とす

    暗黙知が多い ミスの想定が難しく 手戻りが起きやすい 実装難易度が高いポイント 31 など 開発者の技術理解 ツールを含め 技術とその特性理解 が不足すると 手戻りが大きい
  27. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪開発者の技術理解 32 業務知識がある担当者が実装できることがベストだが

    ツール理解だけでなく、開発技術も重要 技術理解 1. 異常系の想定  RPAツールは、業務担当者も比較的手を出しやすく、RPAの急成長を促してるもの の、開発経験が不足した人だと正常系の担保に陥りやすい  業務自動化とは、人の手を離れ、システム依存度が高くなるため、管理できている 状態が必要であり、異常系の想定は重要である 2. RPAツール/AIの知識が必須  実装の仕方により発生するリスクの想定が重要 • 参照システムのVerUPを意識せず、コマンドではなく元々の作業通り操作を実装 • 起動後の処理など、ロボの処理は人より早い(待ち処理実装など) • 実装時点では精度を確認したが、直近のイレギュラー処理を大量学習し、ミスリードが増えた が気づかない など • ゾンビプロセスのキル、ポップアップなど、懸念ポイントの対策  また、業務影響は開発者だけでなく、元々の担当者に仕組みのポイントを説明し、 一緒に考えてもらうことも重要
  28. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪実装難易度が高いポイント 33 開発者の業務理解

    担当者も見落とす 暗黙知が多く ミスの想定が難しく 手戻りが起きやすい など 開発の標準化 個々で開発が進み 野良化し易い 機能重複も増え 開発と運用に無駄が 開発者の技術理解 ツールを含め 技術とその特性理解 が不足すると 手戻りが大きい
  29. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪【補足】RPAツールの活用について 34 操作対象となるアプリの(人が自然と担保している)想定外の振る舞いに弱い

    Ex. アプリの最大化やポップアップ、ゾンビプロセス、レスポンス確認 使い回しができる仕組み(共通化)や、ログ収集・エラーメッセージなどの 開発標準を作ることで、質を担保しつつ開発工数を削減 ※引数と戻り値をプログラムの関数のように慎重に整理 ポップアップ 想定外の画面 他にもたくさん… Excelを引数のシート を開く作業 社内システムAにログ インして特定ページま で進める作業 今まで作成したロボ 共通化パーツ 社内システムBで特定 条件で集計しものをダ ウンロードする作業 共通化パーツを活用することで、 開発工数とテスト工数を削減
  30. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 35 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  31. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪運用フェーズを見据えて想定すべきこと 37 リリース後にエラー

    テストやリリース時点 でうまく行っても 潜在リスクを考慮 しないとエラーが多発 業務継続性 業務停止リスクの許 容度を定義し、冗長 化や人によるリカバ リー有無を判断 エラーの調査 ログやドキュメント 不足だと、原因調査 に多大な工数がかか り、改善活動に支障
  32. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪改善活動の方針 38 運用フェーズにおける体制や改善活動の方針によって

    開発工数の考え方が異なる 改善方針 1. 開発工数を抑え、開発者が運用対応  担当者が継続対応することが確定している場合は、リリース後の 継続的エンハンスが比較的実施し易いため、ドキュメントを含め、 ある程度安定稼働した後での整備も可能  ただし、急な異動でドキュメント整備が疎かになるなど 属人化しやすいのは否めない 2. 開発工数をかけ、運用体制で担保  潜在リスクの考慮やログ収集といった、安定管理するための実装を ドキュメント化を含め、開発フェーズで実施  開発工数がかかるものの、運用体制に引き継ぎやすく、 属人化を抑制することができる
  33. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ちなみに… 39 当初は、ログ設計とモニタリング設計が不足しており運用工数が2倍に…

    システム開発と同様に抑えるべきポイント(ログやメッセージなど)の標準化や 技術の共有化を進めることで運用工数が半分以下に 例えば モニタリングは下記のように分類し、対応方針を決定 • 障害レベルは、業務継続性の観点で優先度(高中低)を設定 → リカバリはある程度許容することとしレベル高を出さないことを目標 • 中・低も運用工数の削減のため、モニタリングと対応方針を整備 モニタリング分類 方針 備考 業務障害 運用ルールの見直し エラーメッセージの整備 入力データミス 連携システムエラー システム障害 (新・再) 再発させないことを目標 改修と共有 要件・開発の考慮もれ 不明・その他 再現性がなければ深追いしない ログ収集の見直し 再現性がなく 調査工数が大きい
  34. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 40 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  35. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪業務自動化のポイント 41 技術は進化しているため、開発しやすくなったのは事実ですが

    システム開発と同様、プロジェクト推進・異常系の想定対応が重要だと実感  目的が曖昧だとプロジェクトも曖昧に  技術と業務観点で実現見込みがあるか 企画 1  業務理解と開発技術の分断は要件の漏に  標準化やドキュメントなしは野良へ 実装 2  ログがないと調査が困難  業務継続性を抑えないと推進が止まる 運用 3
  36. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪Agenda 42 1.

    自己紹介 2. 自動化への期待と現実 3. 企画フェーズの落とし穴 4. 設計・実装フェーズの落とし穴 5. 運用フェーズの落とし穴 6. ポイントの整理 7. さいごに
  37. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ 44 とはいえ

    技術は使うことで進化します ぜひ挑戦し、学びを増やし 働き方を変えていきましょう!
  38. (C) Recruit Technologies Co.,Ltd. All rights reserved. ▪ご静聴ありがとうございました 45 

    株式会社リクルートテクノロジーズ ITエンジニアリング本部 データイノベーション推進部  野川 幸毅 シニアマネジャー リクルートは人生の選択肢を増やし 皆様の人生を豊かにすることを目指しています。 リクルートテクノロジーズは 技術を磨き・活用することに挑戦し続けます。 新しい未来を目指したい人は ぜひ一緒に!!