IT業界未経験からDXコンサルタントになった私がこのブログを立ち上げるまで

このページでは、IT業界未経験だった私がRPAエンジニア、DXコンサルタントへと進み、その経験からなぜこのブログを立ち上げようと思ったのかを書いています。

DXコンサルタントになる前の自分について

「DXコンサルタント」と聞くと、皆さんからまずこう言われます。

「DXコンサルタントってなに？？」

もしくは「「DX」って言葉が入ってるし、ITめちゃくちゃ詳しいの？？」とか「コンサルタント」という言葉から、「その道を極めし超エリート」とか「なんかうさん臭い職業」と思われたりもします。

実際にはそういう人もいるでしょうが、私はどちらかというと、ITと全く関係のない業種や職業で働いていました。
大学は畜産系の学部専攻でしたし、新社会人になってからしばらくは就職してバイトしてと落ち着きがなく、根無し草みたいになってました。

ですが、派遣で働いていた頃、PCでメール送信や社内システムを操作する作業をしていた時に、子どもの頃からパソコンを触ることが好きだったのを思い出しました。
当時は掲示板やチャットを使ってコミュニケーションをとったり、ホームページビルダーでホームページを作ったりして遊んでいました。

そして、未経験でIT業界に就職しました。

未経験でIT業界へ

何とかIT系の会社に採用され、インフラ系のIT事務（データの入力、申請作業など）として働き始めました。

しかし、実際に事務の仕事をしてみて、私は大変な事実に気付きました。

私は、同じ作業を毎回正確に繰り返すことが、とても苦手でした。
手順を理解していても、入力を間違えたり、作業の一部を飛ばしたりしてしまいます。
他の人に相談してアドバイスを生かしたり、いろいろ手を尽くしましたが、ミスはなくなりませんでした。

その頃、RPAという技術が注目されるようになりました。

RPAとの出会い

RPAは、人がパソコン上で繰り返している操作を、代わりにロボットにやってもらうソフトウェアです。データをシステムに入力したり、ファイルを加工したり、決まった内容のメールを送ったりといった定型作業を自動化できます。

当時の現場にもRPAが導入され、その動きを初めて見た私はこう思いました。

退屈な事務作業からとにかく逃げたかった私。
「RPAに仕事を取られる」という不安はまったくなく、「自分が苦手な作業をやってくれる」ことに、大きな魅力を感じたのです。

そこから、RPAの仕事をやりたいと上司に何度も何度も伝え、半年後にRPAエンジニアとして働く機会をもらうことができました。

何も分からないまま始まったRPA開発

念願のRPAエンジニアに移れることになりました。

なんと、投げやり状態でさっそく途方にくれます。
「すべて自分で勉強してね。」でちょっと研修しただけで現場に投入されるのは、エンジニアあるあるだそうですが、業界経験者ならともかく、未経験で現場に突然入れられるのは不安が大きかったです。

RPAツールの基本的な操作方法を研修資料で少し学んだだけ。
エンジニアみたいな実際の開発の進め方も、どのような資料を作らなきゃいけないかも全く知らない状態（そもそも、そういうものが存在することも知らない）で現場に入りました。
とりあえず「自動化対象の作業の最初から最後まで一通り処理できるものを作る」というのをゴールに（エンジニアとしていろいろと問題ありますが）、とにかく手探りで地道にやっていくしかありません。
また、VBAの知識が役に立つと聞いたので勉強したり、RPAのバージョンが上がるたびに新機能がついたりするため実際に使えるかどうか検証してみたりと知見を必死に積み立てていました。

苦労が多かったですが、RPAが実際に動くところを利用者の方に見せると、

と喜んでもらえました。

自分の作ったものによって、誰かの作業が楽になる。喜んでくれる。
その成果を間近で見ることがうれしくて、RPA開発を続ける大きな励みになりました。

そして次第に、ただ動くものを作るだけではなく、

といろいろと考えることが増え、それを解決するのが楽しくなっていきました。
解決すれば解決するほど、その作業が「楽に終わる」というのにとても達成感を感じたのです。
事務作業は苦手でしたが、その事務作業をどのように自動化するか構造を考えることは、私に合っていたようです。

そして、次第にちゃんとしたエンジニア出身の人たちがRPA界隈に進出してきて、開発手順やルールが少しずつ整えられていきました。

いろいろな現場でRPAツールを作るに伴い、そのようなエンジニアの人たちと話をする機会があり、これが次のステージに進むきっかけになりました。

RPAツールを作るだけではなく、上流工程に挑戦したくなる

とある現場で、何人かで人事システムにデータの登録・編集を自動化するRPAツールを作ることになりました。
私ともう一人はRPAツールを作るメンバーで、もう一人はエンジニア上がりのマネージャーです。

その中で、自分が今までやってきたやり方をさらにレベルアップさせる経験ができました。

こんな風に、いろいろと具体的な方法を学べる機会を得られるようになりました。

また、新たな課題にもぶちあたりました。

その時に、初めてITエンジニアの人たちが現場でどのような資料を作ったり、その資料を作ることによってどのように役に立つかなどの必要性を教えてくれました。

それを聞いた私の感想はこれです。

はい、事務仕事が苦手な私。実は資料作成とかもめちゃくちゃ苦手でした。

いままで人からお願いされた作業をRPAで自動化すればいいだけだった仕事に、さらにその内容を資料にまとめられるようになる。それが次のステップでした。

このあと、資料作成についてはずっと個人的課題となりました。

この頃には

1. 開発をしてほしいツールの内容を依頼者から聞く
2. 設計する
3. ツールを作る
4. 説明書などのドキュメントを作る

という、RPA開発の一連の工程を経験していました。

特に１～２の部分が楽しく、「上流工程」という相手の要望や依頼内容を「どうしたら叶えられるか」「何をどのように作るべきか」を考える仕事を極めたいという気持ちが強くなりました。
そこで、要件定義や設計などの上流工程をもっと経験したいと会社に希望したり、転職活動でそういうことができる求人を探したりしていました。

また、その頃は生成AIが登場し、これまで人が書いていた資料などを生成AIが作れる時代が始まりました。

はい、すぐに飛びつきました。
「面倒なことをもっと楽にしたい」という考えは、この頃も変わっていません。

そして、次の現場で出会った人により、仕事の考え方が大きく変わることになりました。

本当の効率化という考え方を教えてくれた人との出会い

次の現場では社内SEの補助として、RPAの開発や保守運用を担当する案件に入りました。
そこで一緒に働いたのが、元JavaエンジニアのSEさんでした。
外部の人間の私に、その方は開発の進め方だけでなく、利用者からの話の聞き方や、タスクの整理方法、関係者との調整方法なども細かく教えてくれました。
特に印象に残っているのが、業務自動化の依頼として依頼内容を聞いたときの考え方です。
それまで通り、私はRPAエンジニアとして「この作業を、どうやってRPA、またはVBAで自動化するか」しか考えていませんでした。

しかし、そのSEさんは最初から聞いた内容を自動化することを前提にはしていませんでした。

その社内SEさんはまず、「なぜこの作業が発生しているのか」
そもそも、「この作業自体をなくすことはできないのか」
自動化するよりも、「業務の進め方やシステムを変えた方がよいのではないか」
もしくは、「RPAやVBAよりもいい解決方法があるのか、ないか」

と考えていました。

そのうえで、

• RPAを一時的な対策として使うのか
• 問題の一部をRPAで解決するのか
• RPA以外の方法を選ぶのか

を判断していたのです。

「RPAかVBAの自動化で解決する」以外の考え方を教えてもらったとき、私は、

と、心にすとんと落ちる感覚がありました。
ずっと「RPAやVBAで自動化しなくてはいけない」という凝り固まった思考を崩してくれたのです。
しかも、ツールを作る必要もないので、開発する時間や手間、さらにその後の保守も削減したのです。

業務効率化はツールを導入すること自体が目的なのではありません。
利用者が本当に困っていることを整理し、その問題を解決することが目的です。
必要であればITツールを使いますが、使わずに解決できる場合もあります。
むしろそうしないで済む方法で解決できるほうが、その後に増える保守や現場の人が実際に使えるようにフォローする仕事を減らせて楽になるのです。

私はその方の仕事を近くで見ながら、

と思うようになりました。

依頼された内容そのままうのみにしてツールを作るのではなく、相手の話を聞き、依頼内容の本質や問題を分析して整理し、本当に必要な解決方法を考える仕事をしたい。
そういう仕事をするのであれば、やはり「上流工程」ができる方向へ進むしかないと思いました。
これまで漠然としていた上流工程への興味が、ここで明確な目標に変わりました。

RPAエンジニアからDXコンサルタントへ転職

社内SE補助の案件は、第二子の出産で産休、育休を機に離れることとなってしまいました。
育児休業中、改めて今後のキャリアについて考えましたが、大きな壁にぶち当たります。

家事と育児と仕事の両立です。
第一子の時は何とか回っていた仕事と家事も、子供が二人となるとそうもいきません。
しかも、出社回帰の波により、以前は保育園のお迎えに間に合っていたのに、時短勤務しか選べない状況になってしまいました。そして、今後のことを考えたときに経済的危機などの不安に駆られました。

その時、社内SEさんの言っていたことを思い出しました。

そのとき、はっとしました。
今まで何気なく本やネットでやっている方法を何も考えずにやっていましたが、私に不要な工程があるのではないかと。
それに書き出すことや人に相談することによって状況を言語化することにより「状況把握」をし、見えてなかった本質や、いい方法を考える「課題解決力」というスキルを教えてもらったことを思い出しました。

これが、コンサルタントに必須な力が日常でも役に立つと実感した出来事でした。

その後、私は家事の一つ一つの作業を書き出して「ここは削っていい」「ここはこうしたらやらなくてよくなる」「これはやらなかったら後々影響が出る」という風に分析してやることを決め、
　・継続してやる」
　・やらない
　・へらす
　・やり方を変える
　・人（外部の人）に任せる
に分けて実行しました。

育児しながらだったのでかなり大変したが、

という自分の「時間の余白」を作るのをモチベーションに頑張りました。
その結果、めちゃくちゃで居心地が悪かった家が実母に「きれいになったわね！」と褒められるくらいに片付き、家事の時間はおそらく3分2くらいまで減りました。
これにより、ちょっと本を読んだり、ちょっとブログを書くくらいの余白を作ることにも成功し、個人的にとても辛くて大変でしたが、やってよかったと思える体験になりました。

また、転職にも成功しました。
自分に必要な生活をするための理想条件を書き出し、「本当にこれは必要なのか」「夫や周りの人に協力お願いできるなら、有利になる条件に変えられないか」など書き出しては問いかけを続け、できうる限り子持ちでも転職に有利な条件に整えていくことができました。
そして、自分の希望に近い条件で転職に成功しました。

ここまでの経験から、「状況把握」と「課題解決力」は、仕事以外にも日々の悩みやよりよい生活を送るために必要な「時間の余白」を作り出すために必要な考え方だなと実感しました。

この世の中で必要なのは「時間の余白」だ

忙しいと、目の前のことをこなすのに意識を持っていかれがちで、「それが本当に必要なことなのか」「もっと楽にできる方法はないのか」というのを考える余裕がないことが多いです。私もそうでした。

その中で、私は

という考えからRPA開発をはじめ、現時点ではコンサルタントとしての「状況把握」から問題の分析や本質を考えることを教えてもらい、「課題解決力」を身に着けることによって「自分の時間」を少しだけ取り戻すことができました。

私自身、仕事や家事に追われていた時期に強く感じたのは、「自分で自由に使える時間がほしい」ということでした。
なぜなら、私の中で「時間の余白」というのは、できることの選択肢を増やす方法のひとつであり、心穏やかに過ごすために必要なもののひとつであり、お金を払ってでも手に入れたいほどの価値があるものだからです。
だから私は、効率化の目的を「もっと仕事をすること」ではなく、「自分で使い方を選べる時間を増やすこと」「心の余裕となる『時間の余白』を手に入れること」と考えています。

やらなければならないことを全部なくすことはできません。
だからこそ、その中に「本当に必要？」「もっと楽にできない？」と問いかけることで、自分で使える時間を少しずつ増やせるのではないかと思っています。
それには「これ、もっと楽にできない？」という疑問を自分が当たり前に行っていることに対して問いかけてみることが必要です。

このブログでは、

自分の時間を取り戻す。
―「これ、もっと楽にできない？」から、時間に余白を。―

をコンセプトに、日々の1分、10分といった作業の短縮方法や「それもっと楽にできない？」「それ本当に必要？」などの考え方、お役に立てる情報を発信していけるよう頑張っていきたいと思っています。

DXコンサルタントとして学んだことや、これまでの業務改善・自動化の経験をもとに、「これ、もっと楽にできない？」を考えていきます。

仕事に追われる時間を少しでも減らして、自分がやりたいことに使える時間を増やす。

このブログが、そんな「時間の余白」をつくるヒントになればうれしいです。