0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

人事異動・キャリアに関するボヤキ

0
Last updated at Posted at 2026-08-11

社会人としては15,6年になるおじさんです。
メカ設計エンジニアとして十数年。
その後データサイエンティスト、(アナリスト?)やデータエンジニアとして6,7年働いてきた。

今年4月で異動したのだが、エンジニアとしてのキャリアを考えると次の異動までの期間がつらくてたまらない。なので、吐き出させてほしいし、先輩からのアドバイスや意見もほしい、と思いここに記す。

 
前提として、

  • 自部署(異動先の部署)のDX化を進めてほしい

という依頼から、前の部署の解散タイミングで引っ張られてきた。
本来ならばDX推進系の部署に行くはずだった。
 

今の会社に来たのは4年前。
データサイエンティスト枠として入社。

色々あって「データ分析しかしない」部署から外れ、紆余曲折を経て今年度4月に異動。

今の部署はかなり経営に対して密にかかわる部署で、数年~10年後の需要予測を行っている。
需要予測というと、機械学習のモデルを駆使して、特徴量エンジニアリングして、モデル改善を高速に回す、というイメージがあるかもしれない。

しかし、今の部署で使っているのは単回帰。来年からようやく重回帰になるらしいことは、異動初日の部署説明の際に聞かされた。
身バレ防止のために明らかにはしないが、弊社は規制産業であり、需要予測の手法すらも国の機関から決められている(カンのいい人はこの時点で分かってしまうかも?)。
そのため、単回帰や重回帰しか方式が取れない。説明性が何よりも重視されるためだ。
 
ここで私は不思議に思った。
国の機関から決められているのは知らなかったのだが、「単回帰や重回帰をやるのに、DSである自分を呼んできた必要あるのか?精度向上でいろいろ機械学習でやってほしいことがあったから呼ばれたのではなかったか?」と。

まあ、そこには目をつぶろう。なんせ「部署のDXを現場に入って進めてくれ」、と請われて来たのだ。何も精度改善だけが自分のタスクではあるまい。

さらに驚きは、「まずは業務を覚えてほしい」とのこと。
「確かに、要件定義のためには業務を知らなくてはいけない。だが、業務を覚えてこなすのと、要件定義のために業務を知るのとはわけが違うぞ?きっと言い間違いなのだろう。」とこの時は楽観視していた。

現場は汚いエクセル地獄からの脱却中だった。
幸い先輩にあたる人がtableau prepを頑張って整備してくれており、エクセル地獄は半分程度に改善されていた。
データの持ち方の汚さや、出力されるデータの設計がまるでなっていないものの、処理の流れは理解がしやすかった。この点は評価したい。
会社はsnowflakeの利用を推進しており、その先輩も非エンジニアではあるもののsnowflakeの有用性に気付いていた稀有な存在であったため、我々はすぐにsnowflakeを軸とした業務フロー改善の方向性で一致した。
そのためにはtableau prepで整理してくれたロジックをpythonに書き起こすことが必要だ。自分の呼ばれた意義が見えた。

私は自分の存在意義やキャリア、エンジニアとしての立場を尊重してくれるとやる気が出る人間である。逆もしかり。そのため、爆速でこのコード化を進めた。
この段階ではまだ粗い出来であるものの、それなりにきれいなコードにしておいた。後々snowflake上のstreamlitでこれらを統合して一つの業務システムを作るためだ。

実際この期間は楽しかった。新しいことをやる刺激も十分にあったし、何より必要とされている、という気持ちが「エンジニアとして呼ばれたのだ。よいものを作り上げるぞ!」という前向きさを生んでいた。

しかし、現実は事情である。
上長は「tableau prepでDX化を進めてくれた人が来年異動なので、その人の代わりに呼んだ」というのが本音の様である。
つまり、あくまで自分は需要予測業務をメインで動かせる人になり、来年部下をつけるから指導監督してくれ、ということである。DXはあくまで片手間でやってくれればよい、との見解であった。

私は軽い絶望を覚えた。
エンジニアとして頑張ってきた今までを否定されたかのような気持ちである。
「DXは片手間では絶対に成功しない」これは私の数年間製造業の現場にコンカレントで入ってDXを進めてきた経験則である。
その経験を否定されたように感じた。
途端に3年後の異動までの期間がすごく長く感じた。

エンジニアとして、要件定義からDB設計、製造・テスト・運開まですべての行程に(たった一人ではあるが)携われるなんて貴重な機会、めったにないのでこの機会を生かして自身の経験値アップを図ろうと思っていたのだが、その目論見は崩れ去ろうとしている。
もしこの長文ボヤキをお読みになっているレアキャラな経験豊かな先輩方は、きっと「そんなもの、やり切ろうと思ったら片手間じゃ絶対無理!」とお分かりいただける、と思っている。

エクセル地獄で苦しんでいる後輩たち(もともとその部署にいた若い子)を見ていると、ボタン数回押してパラメータ設定したら数分後に予測結果が返ってくるシステムにしてあげたら、どんなに楽になるだろうか?と思い、自分がいる間にできる最高のものを作ろうと思ったのだが、片手間では叶わない。できても中途半端なものだけ。ある工程で時間短縮ができるだけ。それは自分の望んだものではない。

一方、会社は自分のキャリアをかなえる場所ではないことも知っている。
なので、如何に周りが事務系だらけの職場でDX化推進を嘱望された唯一のIT系人材だとしても、会社からしたらコマに過ぎない。

私の望みは簡単だ。

  • 私の任期の間にエクセル地獄からの完全脱却をするために、システム化の設計製造に専念させてほしい。それができたら最後の1年で現状の方法と並行して運用し、ドキュメントをまとめてベンダーに保守を依頼できる状態にまでもっていく。
  • 専任がかなわないのであれば、お互いの不幸であり自身のキャリアとしても停滞するので、速やかにDX推進の部署に返してほしい。

の2択である。
現状ぎりぎりの人数で回しているので、専任化は無理だとの回答はもらっている。あくまで「片手間でできる範囲」しか望まれていない。

しかし、このエクセル地獄を抜け出すには最低限tableau prepで整備するしかないが、そうなるとろくにtabreau prepを使えない自分を呼んだ意味ってあるのか?
そして、tableau prepだと大規模データを読み込めないならpython使っていいと言われたが、事務系がほとんどの職場で自分がいなくなったらどう管理していくのか?結局ベンダーに泣きつくのが目に見えているが、業務要件をろくに整理できていない状態だと、誰も相手してくれないぞ??相手にしてくれても、めっちゃマージン含んだ金額で吹っ掛けられるぞ?
その辺わかってる?
生成AIで何とかなるって?じゃあやってくれ。
と言いたくなる。(実際言ったが・・・)
このもやもやとあと数年どう付き合っていけばいいのか…

 
自分が高い理想を勝手に掲げてしょぼくれているだけなのだろうか。
それともエンジニアとして健全な考えなのだろうか。

周りにメンターとなる人がいないので、この場で吐き出す。
もし声かけてくれる優しい人いたら、コメント欄で会話したいです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?