RPAは勉強してきた。ツールの触り方も分かるし、簡単なフローなら作れる。だが、それはあくまで「学習環境」での話だった。実務は別物だと分かってはいたが、その差を本当に理解したのは、現場に入ってすぐだった。
最初の日、軽く説明を受けたあと、いきなりこう言われた。
「じゃあ、この業務、自動化してみてください」
正直、一瞬止まった。
「え、もうやるのか？」という感覚だった。
頭が真っ白になった瞬間
渡されたのは、実際の業務フローだった。
Excel、ブラウザ操作、ファイル保存、コピペ。
一見すると単純だが、細かい例外が多い。
その場で理解しようとしたが、頭に入らない。
どこから手をつければいいのか分からない。
「RPAを作る」というより、
「何を作ればいいのか分からない」という状態だった。
ここで気づいた。
RPAはツールの問題ではなく、「業務理解の問題」だと。
実務と勉強の決定的な違い
勉強では、答えが用意されている。
手順も決まっていて、その通りにやれば動く。
しかし実務では違う。
- 手順が曖昧
- 例外が多い
- 正解が一つではない
つまり、「自分で設計する力」が必要になる。
RPA未経験というより、
「業務設計未経験」だったことに気づいた。
最初にやるべきだったこと
そのとき、自分がやるべきだったのは
いきなりツールを触ることではなかった。
まずやるべきはこれだった。
- 業務を分解する
- 手順を紙に書く
- 例外を洗い出す
- 人間の判断ポイントを特定する
つまり、「フローを言語化すること」だ。
RPAはその後に乗せるだけでいい。
この順番を逆にすると、必ず詰まる。
AI的に考えるとシンプルだった
後から冷静に考えると、この課題はシンプルだった。
AI的に言えば、やることは3つしかない。
- 入力（Input）
- 処理（Process）
- 出力（Output）
この3つに分解すれば、どんな業務でも整理できる。
例えば、
- Excelからデータ取得（Input）
- 加工・判断（Process）
- ファイル保存（Output）
この構造に落とせば、RPAはただの再現装置になる。
できる人とできない人の差
現場で気づいたのは、できる人は
「ツールを触る前に設計している」ということだった。
逆に、できない人ほど
いきなり画面を触り始める。
これは完全に逆だった。
RPAはプログラミングに近いが、
本質は「設計」だ。
焦りと現実
最初は正直焦った。
「自分は通用しないのではないか」と思った。
しかし、それは当たり前だった。
未経験なのだから、できなくて当然。
問題はそこではなく、「どう理解するか」だった。
ソロログとしての気づき
この経験で一番大きかったのは、
「自分は何ができていないか」を明確に知れたことだ。
- ツールは触れる
- でも業務を設計できない
この差に気づけたのは大きい。
そしてこれはRPAに限らない。
仕事全体に共通する力だ。
結論──現場は最速の成長環境
RPA未経験でいきなり課題を出される。
一見きつい状況だが、実はこれが一番成長できる環境だ。
なぜなら、「考えないと進まない」からだ。
勉強では得られない、本当の理解はここにある。
もし同じ状況にいるなら、焦る必要はない。
まずは業務を分解すること。
RPAはその後でいい。
そしてこの経験は、確実に次につながる。
コメント