1. はじめに
こんにちは、TOKIUMでCRE（Customer Reliability Engineering）をしている市原です。
「この案件の経験、今後のキャリアに本当に役立つのだろうか？」
2025年3月、私はこの問いを抱えながら、あるRPA移行案件に参画しました。社内で使ったこともないツールを扱う、所属部署とは全く異なる領域への挑戦。エンジニア未経験の私にとって、不安だらけのスタートでした。
結論から言えば、その経験は間違いなく今の業務に活きています。
この記事では、SIerのような立場で携わったRPA移行案件で直面した壁と、その経験が現在のCRE業務にどう繋がっているかをお話しします。同じように「今やっていることに意味があるのか」と悩んでいる方にとって、何かの参考になれば幸いです。
2. エンジニア未経験からのRPA移行案件参画
突然の案件アサイン
2025年3月、私はとあるお客様のRPA移行案件にアサインされました。具体的には、それまでお客様で運用されていたRPAソフトを、MicrosoftのPower Automate（以下、PA）にリプレイスするというプロジェクトです。
当時の私はエンジニアとしての経験がほとんどなく、RPAツールについても名前を聞いたことがある程度。どちらのRPAソフトも、実務で触れた経験はほとんどありませんでした。しかも、この案件はSIerのような立場での参画であり、お客様の業務を理解した上で、最適な自動化の形を提案・実装していく必要がありました。
「本当に自分にできるのだろうか」
そんな不安を抱えながらも、与えられた環境で最善を尽くすしかない。そう腹を括って、案件に臨むことになりました。
RPA移行とは何か
RPA（Robotic Process Automation）とは、人間がパソコン上で行う定型的な作業を、ソフトウェアロボットによって自動化する技術です。今回の案件では、既存RPAで構築・運用されていた自動化フローを、PAに移し替える必要がありました。単純な「置き換え」ではなく、移行を機により効率的で安定した運用ができるよう、設計から見直すことが求められていたのです。
3. 直面した5つの壁
案件を進める中で、私は大きく分けて5つの壁に直面しました。どれも当時の自分には高いハードルでしたが、一つひとつ乗り越えていく中で、確実に成長の糧となりました。
壁①：ツール理解の壁
最初に立ちはだかったのは、PAというツールそのものへの理解です。
PAはMicrosoftが提供するクラウドベースの自動化ツールで、ローコード・ノーコードで業務フローを構築できることが特徴です。しかし、「ローコードだから簡単」というわけではありません。独自の概念や用語、できることとできないことの境界線、他のMicrosoft製品との連携方法など、習得すべきことは山ほどありました。
私が取った対策は、とにかく手を動かすことでした。公式ドキュメントを読み込むだけでなく、実際に小さなフローを作って挙動を確認する。エラーが出たらその原因を調べ、一つずつ理解を積み重ねていきました。
壁②：業務理解の壁
ツールの使い方がわかっても、それだけでは自動化は実現できません。「何を」自動化するのか、つまりお客様の業務そのものを深く理解する必要がありました。
P社の業務フローは、長年の運用の中で築かれた独自のルールや例外処理が複雑に絡み合っていました。ドキュメントを読むだけでは到底理解できず、MTGの機会をいただいて直接ヒアリングを重ねました。
「この作業は、どんな状況で発生しますか？」
「例外的なケースはありますか？」
何度も質問を繰り返す中で、少しずつ業務の全体像が見えてきました。この経験を通じて、「自分が理解できていないことを正確に把握し、適切な質問をする力」が養われたと感じています。
壁③：設計の壁 ── 効率性と安定性の両立
業務を理解した次のステップは、それをどのようにRPAに落とし込むかという設計です。ここで求められたのは、「効率よく」かつ「安定して」運用できる設計でした。
効率性だけを追求すれば、複雑なロジックを詰め込んだフローになりがちです。しかし、複雑なフローは障害発生時の原因特定が困難になり、保守性も下がります。一方で、シンプルさだけを重視すると、本来すべて自動化できるはずの業務に手作業の工程が残ってしまい、導入効果が薄れてしまいます。
このバランスを取るために、一つのフローに詰め込みすぎないこと、エラーが発生しやすいポイントには適切なエラーハンドリングを組み込むこと、将来的な業務変更にも対応しやすい柔軟な設計にすることを意識しました。
壁④：運用設計の壁 ── エラー検知と影響判定
RPAは「作って終わり」ではありません。本番環境で安定して動き続けるためには、運用面の設計が欠かせません。特に苦労したのは、エラー発生時の対応フロー構築です。
エラーの検知方法：フローが失敗したとき、それをいち早く検知できる仕組みとして、PAの標準機能に加え、メール通知やTeamsへの自動投稿など複数の検知手段を組み合わせました。
影響範囲の判定：「どこまで処理が進んでいたのか」「どのデータに影響があるのか」を迅速に判断できるよう、ログの出力ポイントを適切に設計しました。
関連部署への連携手段：エラー発生時に誰に、どのような情報を、どのタイミングで連携するか。この連携フローを事前に関係者と合意し、ドキュメント化しておくことで、いざというときの混乱を防ぎました。
壁⑤：分析の壁 ── 稼働状況の可視化
最後の壁は、RPAの稼働状況を集計・分析する仕組みの構築です。
各フローの実行回数、成功率、処理時間、エラーの発生傾向など、さまざまな指標を定期的に集計し、レポートとして可視化しました。この取り組みによって、潜在的な問題の早期発見や、改善ポイントの特定が可能になりました。
データを集め、整理し、そこから意味のある情報を抽出する。この分析のプロセスは、後述するCRE業務でも頻繁に求められるスキルとなっています。
4. CRE業務で活きた「思考の型」
現在のCRE業務
RPA案件を経て、私は現在CRE（Customer Reliability Engineering）チームに所属しています。CREは、技術的な側面から顧客の不安を解消し、プロダクトへの信頼性を最大化することをミッションとする職種です。具体的には、「エラーが発生している」「動作がおかしい」といったお客様からの問い合わせに対し、ログやソースコードを調査して原因を特定し、解決に導く業務を担っています。
一見すると、RPA案件とは全く異なる領域に見えるかもしれません。使うツールも、対象となるシステムも違います。しかし、RPA案件で培った「思考の型」は、CRE業務のあらゆる場面で活きています。
共通する「エラー調査のアプローチ」
エラー内容を正確に把握する力：RPA案件では、フローが失敗したときに「何が起きたのか」を正確に読み解くことが求められました。エラーメッセージを鵜呑みにせず、実際のログを確認し、どの処理でどんな問題が発生したのかを一つひとつ確認していく。このアプローチは、CREでの調査対応においてもそのまま活かせています。
原因を一つずつ潰していく姿勢：エラーの原因は、最初から明らかなこともあれば、複合的な要因が絡み合っているケースもあります。「仮説を立て、一つずつ検証して潰していく」という地道なアプローチは、CREでの調査においても変わりません。
「この業務、自動化できるのでは？」という視点：CRE業務を進める中で、定型的な作業に気づくことがあります。そんなとき、「これは自動化ツールで効率化できるのでは？」という発想が自然と浮かぶようになりました。RPA案件での経験が、業務改善の視点を与えてくれているのです。
ツールは違っても、本質は同じ
RPA案件ではPAを使い、CRE業務ではまた別のツールやシステムを扱っています。しかし、「何が問題なのかを正確に理解し、原因を特定し、解決策を導き出す」という一連のプロセスは共通しています。異なるツールや環境を経験したからこそ、「ツールに依存しない問題解決の考え方」が身についたと感じています。
5. おわりに
「畑違いの案件経験は、CRE業務に活きるのか？」
冒頭で投げかけたこの問いに対し、今の私は明確に「活きる」と答えることができます。
RPA案件で直面した5つの壁を乗り越える過程で培った「思考の型」は、現在のCRE業務においても確実に役立っています。エラー内容を正確に把握すること、原因を一つずつ潰していくこと、自動化の可能性を常に意識すること。これらは、案件を通じて身についた、かけがえのない力です。
初心者のうちは、目の前の業務が将来どう繋がるのか、見えないことも多いと思います。しかし今振り返れば、周りにある業務のすべてが勉強材料であり、その後のスキルアップに繋がっていました。
大切なのは、今与えられた環境で最善を尽くすこと。目の前の業務をコツコツと積み重ねること。私はこれからも、CREとして目の前の課題に誠実に向き合い、今日の経験が明日の自分を作ると信じて、日々の業務に取り組んでいきたいと思います。
最後まで読んでいただき、ありがとうございました。同じように初心者として奮闘している方の、何かの励みになれば幸いです。