読書の力で広がる考え方
知識や経験は抽象化により価値が上がる
体験や知識は、具体的なものごとだけをとらえると、同じことが起こらない限り利用価値がない。
類似する経験や知識と組み合わせることで抽象化が可能となり、抽象化することより広い事象に対して応用が可能となる。
本は経験による疑似体験
ただ、自分の体験だけを元ネタとするだけでは、幅を広げることが難しい。
そこで、注目すべきは読書である。
読書は、筆者の考えや体験情報の集約であり、そこから疑似体験できるのである。
本には筆者の体験や考えが詰まっており、自分の考えと掛け合わせることで、新しい抽象化思想を定義することができ、自分の考え方を広げられる。
私はそんな読書を重宝しており、どんなに忙しくてもなるべく捻出するように心がけている。
行動経済学：無意識の判断を合理的にする
行動経済学とは？
行動経済学とは、経済学と心理学を融合した学問で、人々が合理的に判断していると思っているが、意外とできていないことを研究する学問です。
例えば、普段1万円の服を高いと考えていても、10万円のドレスの購入後に、1万円の服を見ると安く判断してしまったりする（アンカリング効果）
行動経済学を知ることで、自分の行動選択や他人とのコミュニケーションにも活用が可能です。例えば、暴落している株を絶対にあがるとして持ち続ける心理や、得をすることより損を回避する行動を重視する心理など、普段無意識に判断していることを冷静な判断が可能になる。
行動経済学は、ビジネスやマーケティングなどに利用できることは容易に想像できますが、日常においても自分自身の行動選択や他人とのコミュニケーションにも活用が可能であると言える。
無意識の判断を、より合理的な判断にするために行動経済学は有益な学問である。
RPAが目的になるとき成功はない
RPAは目的でない
RPAを利用する人にどのような未来を提供しようと考えるか、この本質の目的を常に意識する必要があります。
RPAのご相談を受けるとき、RPA化をすることを目的として依頼があることがありますが、それは良いものは絶対に作れない可能性が高いです。
作っても使われない可能性が高いでしょう。
それはなぜか。RPAを利用する人にどのような未来を提供しようと考えるか。
この本質の目的を常に意識する必要があります。
どのような機能でどのような部分がRPAで賄えればよいかを考え続けることで、利用価値のあるRPAが出来上がります。
時に、コストや期間の制約で一部機能をそぎ落とさないといけないケースもありますが、根底の目的は絶対に外さないようにすることは必ず必要となります。
是非意識してみて、利用価値のあるRPAの作成を目指してください。
【番外編】毎日散歩とAudible
テレワークの気晴らしではじめた趣味
週５ほとんどテレワークで労働していることもあり、なるべく空き時間に外に出るようにしている。今は朝、昼、晩の３回Audibleで本を聴きながら散歩するようにしている。
おかげで、気持ちのリフレッシュができており、常に安定したメンタルをキープできており、また、毎日１冊ずつぐらい本を聴くことができている。
最近では、いろんな本でいろんな筆者の考え方を吸収したく、歩きたくてうずうずしてしまっている。
良い習慣として、続けられたら良いな。
そして、これが好きだと思えているので、必ず続けられると思っている。
全社RPAの運用設計はどのように設計する？？？
全社RPAの運用設計
全社RPA立ち上げの際に、運用設計を行う必要があったが、最初どのような仕組みにすべきか迷いました。
RPAは落ちても仕方ないとされるが、それに合う運用とは？
運用者はどこから調達するべきか？
運用時に発生する障害やリリースなどの運用フローはどのような手順とするか？
各作業における責任者や承認は誰にどのようにするか？
今回短期間で立ち上げる必要があるので、私は、既存の情シスのシステム運用フローをすべてベースにすることにしました。
そうすることで、運用者も承認者もほぼ同じメンバー設定で、フローもほぼ同様のフローを活用することができます。
ただ、RPA特有の部分は当然あるので、情シスのシステム運用フローをベースに中身を見ていきRPA運用に沿わないもののみを更新するスタンスとしました。
ちなみに、今その運用にて全く問題なく運用は回ってます。
運用まで考えるとどうしたらいいのと悩んでいる人は参考にしてください。
何事もゼロから構築しようとすると困難を極めます。今回のケースも最も利用できる類似したものを探し当ててそこから修正して構築しました。
この考え方は他にも応用できると思いますので、参考として頂ければデス。
RPA立ち上げ後の業務効率化に関する問題と解決策
全社RPA立ち上げ後の問題
全社RPAを立ち上げ、社内の多くの人に向けたRPAをリリースしたが、すぐに多くの人が利用されるようなことはなかった。
問題の要因は色々あった。以下に例をあげる。
- 問題点
- 業務効率化のイメージをもたらすことができなかった
- 選定方法に問題があった
- 手動実行ロボットが不評だった
- トップダウン指示でない
新業務の効率化イメージをもたらすことができなかった
説明会を行い、多くの人に全社RPAを伝えたが、
具体的な業務の効率化イメージをもたらすことができなかった。
誰がどのタイミングでどの目的で利用することで効率化できるという具体的な業務方法を伝える必要があったが、局所的な作業負荷の違いと機能説明に留まっていたため、うまく活用に踏み切ってもらうことができなかった。
現在は、活用されている部署からの説明会を行い、新業務方法のイメージ共有を進めている。
選定方法に問題あり
RPAの選定方法として、すでに社内でRPA化されていたロボットからの選定であったため、部署特有の仕様が含まれており、一般化されていなかった。また、その中には、リリース後もほとんど利用されないものも含まれていた。
この教訓として、その次の開発選定では、部署内で選定メンバーを募り、そのメンバーにヒヤリングするスタンスで実施している。
利用者参加型なので、この参加者達がコアな利用ユーザになる効果も見込まれる。
手動実行RPAが不評
手動実行のRPAはインストール作業が手間で、実行するまでのセットアップであきらめるメンバーが多く発生した。また、実行時に画面を占有するため、自分が実行したほうが早いという意見も多く出た。
多数の利用者が見込めるケースでは、自動実行RPAを強く進める。
トップダウン指示スタイルでない
上位組織からRPAをつかった業務実行の指示により、リリースされたわけではないため、敢えて今の業務を変えようという意思でRPAを利用しようとする人がそもそも少なかった。
RPAの推進はボトムアップだけでなく、トップダウンからのアプローチもあると強制力がかかり利用に拍車がかかる。
まとめ
立上げ後すぐ上記のような問題が発生していたが、徐々にコアユーザも増え利用人数も増えてきている。
リリースしたら終わりではなく、そこから第二ラウンドの戦いとして、利用促進運動があることを忘れてはならない。
プロジェクト改善 PM改善
プロジェクト改善
前に記述した通り、私は型にはまった仕事をする機会が少なく、よくわからない案件に投入されることが多いです。
その一つに運用改善の案件に参画した時がある。
その時いくつかの改善施策を施したが、最も効果があった施策はPM改善（プロジェクトマネージャー改善）を行った。
プロジェクト概要
RPAの保守運用を行なっている案件で、タスク領域が広くなるので、もっと圧縮して行えるように運用改善することで契約して、私が参画した。
問題点と改善点
色々改善できるところはあったが、1番改善の効果があるのは、タスクの平準化だと考えた。
プロジェクトマネージャーは残業が多く忙しそうにしているが、メンバーはそこまでタスクが詰まっておらず、常に定時上がりだった。
プロジェクトマネージャーの責任の一部をメンバーに少しずつスライドすることで、負荷分散できると考えた。
PMヒヤリング
PMとヒヤリングをして、なぜ忙しいか確認した。
そうすると、PMは他の人に責任を分配するのを拒んでいた。
メンバーヒヤリング:意思の確認
まず、私がおこなったのは、メンバーとの1on1で、現状とどうしたらいいか、リーダーやマネージャーの興味を確認した。
ほとんどのメンバーはPMの負荷を認識し、下げたいと思っている反面、何したらいいかわからないと言っていた。
また、リーダーやマネージャー業務にも興味を示した。
PMにフィードバック
PMとまた1on1をし、メンバーのヒヤリング結果を伝えた。
そうすると、自分が心配しすぎていたことを認識してくれた。
メンバーに任せることができることを認識してくれた。
メンバーを分野毎のリーダーに任命
何人かのメンバーに一部の分野に責任を担当してもらうために、リーダーとして任命した。
リーダーに任命されたメンバーは不安を少し口にしたものの、全員でバックアップすると伝えると安心して、引き受けてくれた。
改善後の運用
その後のプロジェクト状況について、私は3ヶ月ほどの施策期間を終えて離任したため、その後の支援案件の時に、改めてPMとメンバーに今の状況を聞いてみた。
PMからは前より仕事量が減って、メンバーの責任意識が向上したと感謝された。
メンバーからも特に不満なく、よりイキイキとして仕事できていることを伝えられた。
PMはメンバーを大切に思う気持ちが強かったため、責任あるポジション設定ができなかった。そこをメンバーの気持ちを伝えることで、任せて良いことを認識して、PMとして一皮剥けることができた。
