未経験でIT業界に入った私が、DXコンサルタントへ転職するまで

このページは、当サイト管理者 ゆき がDXコンサルタントになるまでの経緯を書いております。

この記事は、このような人を対象に書いております。

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

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

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

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

しかし、実際はまったく違います。

私は、これまでITと全く関係のない業種や職業で働いていました。
新社会人になってからしばらくは、自分に何ができるのかも、どのような仕事が向いているのかも分からず、辞めてはしばらくバイトしてみて、別の業界にトライしてみたけど身体を壊して辞めて、また別の職業に手を出してみるという感じで、根無し草みたいに落ち着きがありませんでした。

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

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

未経験でIT業界へ

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

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

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

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

RPAとの出会い

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

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

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

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

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

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

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

RPAツールの基本的な操作方法を研修資料で少し学んだだけ。
エンジニアみたいな実際の開発の進め方も、どのような資料を作らなきゃいけないかも全く知らない状態（そもそも、そういうものが存在することも知らない）で現場に入りました。
「とにかく動くものを作れ」という上司の命令のもと（エンジニアとしていろいろと問題ありますが）、とにかく手探りで地道にやっていくしかありません。
当時は動かしてみて、エラーで止まったらなぜ止まったのか調べ、直して、再トライして、エラーで止まってまた直すというのを繰り返して作っていました。
また、VBAの知識が役に立つと聞いたので勉強したり、RPAのバージョンが上がるたびに新機能がついたりするため実際に使えるかどうか検証してみたりと知見を必死に積み立てていました。
なので私の最高の師匠はGoogle先生です。

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

と喜んでもらえました。

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

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

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

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

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

ツールを作るだけではなく、上流工程をやりたい

エンジニアの人と一緒に仕事をする機会があったときに、エンジニアの人たちが現場でどのように業務自動化について考えているのか、どうしてこのようなルールが必要なのかなどの理論を聞いたり、どうしたらエラーが出ても回避できるか、エラー原因を解決できるかとかの具体的な方法を学べる機会を得られるようになりました。
そして、RPAエンジニアとして経験を重ねるにつれて、

• どのように要件（依頼者の依頼内容やそれに対する解決方法など）を確認して詰めていくのか。
• どのような設計書を作るのか。（いかに環境に左右されない安定性のあるもの、使いまわしができる汎用性があるもの、エラー原因を特定しやすいものを作るか）
• 開発したものをどのようにテストするのか。（チェックリストを作成して証拠を残すようにする）
• トラブルが発生したときに、どこを確認するのか。（ログの出し方や、利用者に不安を与えない伝え方など）

というのを追求するようになりました。
最初は「依頼された作業をただ自動化するツールを作る」だけだったのに対し、より質のよい、利用者が困らないツールを作ることに、私は面白さを感じるようになりました。

RPA開発の一連の工程を経験したことで、自分が特に楽しいと感じる部分も分かってきました。

それは、

利用者から話を聞き、内容を整理し、
「この業務は、どのような流れになっているのか」
「どこまでをRPAやVBAで自動化するのか」
「このシステムにどのような機能変更を依頼したら自動化できるか」
「手順を変更すれば自動化できるか」
「エラーが発生したときは、どうしたら利用者さんの作業に影響が出ないか」

と考えながら設計する部分でした。

私は、ツールを作ること以上に、何をどのように作るべきかを考えることに興味を持つようになりました。
そこで、要件定義や設計などの上流工程をもっと経験したいと希望しました。

しかし、希望を伝えても、上流工程を担当できる現場にはなかなか入れませんでした。
その頃には生成AIが登場し、これまで人が書いていたコードを、生成AIが作れる時代が始まりました。
RPAブームも去ってしまい、

と感じるようになりました。

そして、「何を作るべきかを考える仕事がしたい」という気持ちを指針に、より上流工程や生成AIを活用して人の問題を解決したいという気持ちが強くなっていきました。

「RPAで解決する」以外の考え方を教えてくれた人

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

しかし、そのSEさんは、最初からRPAを使うことを前提にはしていませんでした。

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

と考えていました。

そのうえで、

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

を判断していたのです。

その考え方を教えてもらったとき、私は、

と、心にすとんと落ちる感覚がありました。
ずっと「RPAやVBAで自動化しなくてはいけない」という凝り固まった思考を崩してくれたのです。

業務効率化はツールを導入すること自体が目的なのではありません。
利用者が本当に困っていることを整理し、その問題を解決することが目的です。
必要であればRPAを使いますが、RPAでなくてもよい場合もあります。
また、ツールを導入して終わりではなく、現場の人が実際に使えるようにフォローすることも必要です。

また、「RPA導入しても、技術者がいなくなってしまうと使い物にならなくなってしまう」という長年の悩みも、その考え方で払しょくされました、

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

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

これまで漠然としていた上流工程への興味が、ここで明確な目標に変わりました。
ツールを作るだけではなく、相手の話を聞き、問題を整理し、本当に必要な解決方法を考える仕事をしたい。
そう考えるようになったことが、DXコンサルタントを目指す大きなきっかけになりました。

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

社内SE補助の案件は、第二子の出産で産休、育休を機に離れることとなってしまいました。
育児休業中、改めて今後のキャリアについて考えました。
RPA開発の仕事を続けることも選択肢の一つでした。
しかし私は、RPAという特定のツールだけに限定せず、利用者の課題を整理し、より適切な解決方法を考える仕事に関わりたいと思っていました。

一方で、育児をしながら働くためには、仕事内容だけでなく、働き方も重要でした。
保育園のお迎えに間に合うこと。
残業が多すぎないこと。
可能な限りリモートワークができること。
長く働き続けるためには、これらの条件も無視できませんでした。
当時の会社では出社回帰が進み、希望する働き方を続けることが難しくなっていました。
また、会社の方針も変わり、自分が今後取り組みたい上流工程や業務改善とは、少しずつ方向が離れていると感じていました。
サポート業務そのものが嫌だったわけではありませんが、自分がこれから進みたい方向とは違うと考え、転職活動を始めました。

転職活動の中で出会ったのが、現在の会社のDXコンサルタント職です。

これまで経験してきたRPAやVBAによる業務改善と、これから取り組みたい上流工程の両方を活かせる可能性があると感じ、転職を決めました。

DXコンサルタントとしての仕事は、これから始まる

私は2026年9月から、DXコンサルタントとして新しい仕事を始めます。
現時点では、DXコンサルタントとしての実務経験はありません。

転職が決まった当初は、
「DXって、ITを使って仕事を便利にすること？」
「コンサルタントは、具体的に何をするの？」
という状態でした。

現在は入社に向けて、自社サービスやiPaaS、DXに関連する専門用語、コンサルタントとしての仕事の進め方について勉強しています。

本を読んでいると、
「あっ、これは以前の現場でSEさんに言われたことだ」
「当時は分からなかったけれど、こういう意味だったのか」
と、過去の経験とつながることがあります。

その一方で、自分に足りないものもたくさん見えてきました。
具体的な出来事から共通点を見つけ、本質を考える力。
課題を発見し、解決方法を整理する力。
相手に分かりやすく伝える文章や資料を作る力。
そして、適切に報告、連絡、相談をする力。

どれも、これから身につけていきたいことです。

このブログは、その学びを整理し、アウトプットする場所として始めました。

事務作業が苦手で、RPAに代わりにやってもらいたいと思ったことから始まった私のITキャリアは、少しずつ、

という方向に変わっていきました。

DXコンサルタントとしての仕事は、これから始まります。
今後は、本で学んだこと、実際の仕事で感じたこと、そして自分なりに理解したことを、このブログで発信していきたいと思います。