RPA一辺倒なIT屋さんの今後のキャリアパス
ヘッダーは2022年7月に知人と行った能登半島にて。道路復旧したらまた行きたい。
とある製造業のIT部門に新卒入社してJava開発を経て2018年2月からUiPathを使ったRPAの推進プロジェクトに参画したのをきっかけに、今日に至るまでの6年半ほど携わっています。開発、ヘルプデスク、EUC開発サポート、基盤担当を経て、現在はCoE開発のフロント業務に携わっており、維持管理業務以外は全域をカバーしている状況です。
ちょうど社内で年１回のキャリアプランを考える時期に来ており、決められたフォーマットに落とし込むまでの間のふわっとしたものを備忘録的に書き留めていこうと思います。
仕事のモチベーション
私にとって仕事のモチベーションは、ズバリ「頼りにされること」。これに尽きます。
今担当している業務は社内のユーザが困っていることに対して要件を聞き、開発者が開発しやすいように要件を整理し、技術的サポートを行いながらリリースまで円滑に進むように多方面に気を配っているのですが、ユーザや身内がそれに気づいてねぎらっていただく事があり承認欲求が満たされます。
当然賃金はあるに越したことはないですが、水準以上を頂くことになると肩に乗っかる責任も増えてくるので、経験と共に少しずつ増えていく現状にある程度満足しています。
やってて楽しい仕事
2024年8月現在は1,2人の開発者を抱えてRPA開発をする小規模プロジェクトのプロジェクトリーダー的な立ち位置にいます。その立場で担う仕事のうち、得意というよりかは実際にやってて楽しいなと思えるものは下記3点です。
業務整理や課題発掘をして資料にまとめる
学生の頃にテスト範囲を紙にまとめることで原理原則を“腹落ち”させることを繰り返したおかげか、下記のような業務整理や課題発掘のロジックを資料にまとめるのが楽しく集中して作っています。
現状を整理して見つけたムリ・ムラ・ムダの解決策を、ステークホルダーと共有するために作る箇条書きされたメモや簡易的なUML
業務整理した内容をシート別にまとめたExcel
作業内容を時系列でまとめた作業漏れ防止用チェックリスト
PowerPointやWordにまとめたユーザ向け取扱説明書
上記の類を作っている時は、頭をこねくり回して七転八倒している場合もあれば、既に頭の中にこんな感じと浮かんでいるものを出力するだけの時もありますが、楽しいと思えるタイミングに差はあれど快感の大小に差はないです。
サンプルプログラムの作成
業務要件に即したサンプルプログラムをUiPath、PowerShell、PowerQuery、PowerAutomateで作ることで技術的に実現できるか確認をよく行っています。公式リファレンスを参照しながら試行錯誤していましたが、社内でChatGPTが解禁されてからはその速度が向上しました。ありがてぇ…
しばしば開発者に丸投げして開発者を困らせた上に筋の悪い作りのままリリースさせるフロントエンジニアの方もいらっしゃるかと思いますが、私のポリシーに反するので基本的に技術検証は欠かせません。
表計算
元々この業界に入ったきっかけが大学時代にやっていた本屋でレジ締め作業でExcelで表計算の効率化をしたことだったので、データテーブルの構成には人一倍敏感です。
それが高じてか、月イチで基幹システムからテーブル情報と従業員に入力させた工数実績からデータをピボットテーブルで成形する定常業務を4年ほど担当しており、半年ほど前にデータの参照方法が変わったことを受けてデータの正規化や項目の見直しをして作業工数を70%ほど削減しています。
これまでで一番の成果
詳細は複雑怪奇なので省きますが、UiPath、PowerShell、PowerBI(PowerQuery)をうまく連携させてUiPathのUR実行スケジュール予約分析ツールのプロトタイプを作成したことが一番の成果だと思っています。当時私以外に作成できる開発者もいなかったでしょうし、例え私でもこれまで担当した全ての領域の知識や経験がなければできなかったと思っています。
苦手な仕事、視点
ここまではポジティブなことを述べてきましたが、より上位の立場で仕事をしていくに際して障壁となるような仕事の仕方や視点について述べていきます。
第二者、第三者など相手に伝わるような伝え方、文章
業務内容として、プログラムとして正しい内容を資料にまとめるのは楽しいですが、それが相手に伝わる形でまとめられるかどうかは別の話。特に日本語でまとめるのが小学校の頃から苦手で、20年ほど経った今も苦しめられるとは思ってもみませんでした… 読書感想文を書くコツってあるはずなのに何で教えてくれないんですかね。今はnoteでお気持ちをまとめることで日本語能力を養おうとしている所です。
QCDのQualityを下げてCostやDeliveryを優先
RPAに長年携わっていると、「ここのライン以上クオリティを下げると後々になって我々の誰かが被害を被るから、納期を遅らせてでもクオリティを死守すべき」と思えることがあります。大抵は定例会などで上司に相談して致命的なことにならないように最低限の納期遅延で済ますのですが、放置した場合その預言的なものは本番化してから1週間後になるか半年後になるかの差はあれど、大抵大問題に発展します。
ハナから起きると分かっていた大問題の尻拭いが嫌すぎるのでQualityを下げたくないのですが、それが理解されない。先ほど述べた伝え方が下手くそということに通ずるわけです。なので、そのリスクを許容できるかどうかを説明するだけの日本語能力を養うのも行いつつ、Qualityを下げないように自分が頑張って要件定義をまとめて開発者が困らないようにしたり、全体の納期を遅らせるのを許容してもらうという手段を取っていますが、そのバランス感覚が難しい。
今後のキャリアパスは…?
RPAとその周辺しか守備範囲はありませんが、IT屋さんとしての今後のキャリアパスをざっくり考えていきます
マネージャー
立場上一番想像がつくキャリアパスはマネージャー職でしょうが、PM、PLの経験が規模や経験数共に不足しているので2,3年後に役職者になってねと言われるのは厳しいと感じています。
PM、PMを担う上で必要な心構えを養うという目的で、手始めに「マネージャーの全仕事」を参考書として読んでいる最中です。
技術専門職
こっちはいばらの道。なんせ最近オライリー本が出たばかりで、業界内でも役職がついている技術専門職はあまりいないイメージです。
オライリー本は運良くフラゲできたので読み進めようと思います。
個人的には人を管理するマネージャーよりも、皆が同じ方向を向いた時に欠けている能力を補えるようにリード・サポートしていく技術専門職の方が向いている気がしています。役割として明確になっていないですが、同僚によく支援を求められることがあるのでマネージャーよりもイメージが出来ています。
最後に
定年まであと30年ほどあるので、その間に楽しく仕事ができるようなキャリアパスを色んな書籍や人から見聞きして切り開いていこうと思います。
P.S.
スカウトエージェントの方、もし気になるようでしたらこっそりX/TwitterでDMください。
この記事が気に入ったらサポートをしてみませんか？