ITコーディネータの吉田聖書です。
先月RPAについての記事を書いたところ
普段よりも反響が大きく
RPAについての関心の高さを感じていました。
そして、タイミングよく今月9日に
日本システムアドミニストレータ連絡会（JSDG）の主催で
「RPAで進める働き方改革、シスアド再興！」
というテーマの研修会が開催されましたので
参加して感じたことをお知らせしたいと思います。
今回の研修会で講師として登壇されたのは
大和ハウス工業（株）内でRPA研究会のメンバー・松山竜蔵さんです。
松山さんはいわゆる組織図上の肩書とは別に
組織横断的な活動としてRPA研究会に参画しておられます。
この日は、RPA研究会での活動内容から、
具体的にRPAを業務に導入した成功事例・失敗事例、
また導入時の検討のポイントや、
やってみて分かったことなどを話してくださいました。
その中から特に私が注目したことを3点お伝えします。
(1) ウォーターフォールモデルのような直線的な開発手法はそぐわない
硬直化した組織で新しい事を導入しようとすると、
つい計画を立てて予算を付けて進捗を管理して…
という進め方に陥りがちです。
例えば要件定義の中で、
フィージビリティースタディといって
実現可能性を調査・検討する活動がありますが、
出来るかどうかを検証していく過程で
ロボットが出来上がってしまいます。
ですので、従来のような厳密な要件定義をして
設計、開発、テストというプロセスを踏むような
直線的（linear）な開発手法ではなく、
とにかくトライアンドエラーを繰り返して
何とか実運用に耐えるものを作り上げるというのが
現実的なプロセスなのだろうと思います。
実際、どこで詰まるかはやってみないと分からないのだそうです。
(2) 外部サービスに依存する業務はロボットのメンテナンスが重要
ロボットを作る際、どのボタンを押すとか、
どの項目にどのような文字列を入力するとか
そういった作業を定義していきます。
その際、社内システムならともかく、
外部のサービスを利用する業務の場合、
予期せぬシステムのリニューアルによって
画面などのUIが変わってしまい、
結果としてロボットが動かなくなることが想定されます。
人間がやる場合は多少のUIが変わっても
何とか新しいUIで業務を行うことができると思いますが
（その人間の適応力は素晴らしいと思いますが）
ロボットの場合は再定義をしてやる必要があります。
そういった日々のメンテナンスが、
RPAを導入したことによって代わりに発生する業務となります。
リニューアルではなくても計画停止があるかも知れません。
UIは変わらなくても取得されるデータが変わるかもしれません。
昼間は順調でそのまま動かし続けても、
翌朝見てみたらエラーで止まっていたということだってあり得ます。
また、そういった理由から、
RPAをクリティカルな業務で適用しないことも
RPAで失敗しないためのポイントだとおっしゃっていました。
(3) ロボットはあくまでも部分最適化ツールである
ロボットは人の代わりに定型的な作業をこなしてくれます。
しかし、その作業は、本当だったらなくせる作業かもしれません。
RPAの導入によって業務の再構築（BPR）はおろか、
RPAを前提にすると逆に業務が硬直化してしまう危険性があります。
また、従業員が思い思いにロボットを構築して運用してしまうと、
管理されていない野良ロボットが増えてきた時に、
それぞれのロボットが何をしているのか
全体を把握しようとしてもできなくなってきます。
そしてそれはセキュリティ上の脅威にもなりかねません。
大和ハウス工業では、RPA研究会が窓口となって
全社のロボットを台帳で管理しているとのこと。
それぞれのロボットにも社員IDを振出し、
ロボットの活動をトレースできるようにしているのだそうです。
少なくともRPAの管理者を立て、
導入しようとする場合には管理者の許可を得るといった
最低限のルールは必要なのだろうと思います。
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。