キャリアアップの王道、ジョブチェンジ
仕事のやりがいや待遇をアップするキャリアデアップの王道のひとつは、ジョブチェンジである、と私は思う。ドラクエなどのRPGで、戦士が魔法戦士にチェンジして経験値やゴールドがより稼げるようになるが如くに。以下、龍(にジョブチェンジする)が如くに華々しい話では全くないのだけれど、特に(元請・下請含む)SIer界隈のJava屋さん向けの現実的なジョブチェンジの一例な軽いお話。
私の10年間(ポエム)
10年ちょい前、SIer業界でお客様のためにJavaやScalaやPerl/Rubyを書いて食べていた私。今もJavaやScalaやPythonを書いているのだが、その間にプログラマ(フリーランスエンジニア)から、データエンジニア(DE)へのジョブチェンジを経験した(よくある誤解だが、データサイエンティストに、ではない)。
その間、エンジニアとして10年分歳をとってオッサンとなりコードを書く速度ははっきり言って落ちた私だが、手取りの方は時間単価換算で1.8倍ほど増えた。おそらくは今後10年も大差ない手取りになるかと。まぁ先のことは分かりませんが(この半年では5%くらい手取りが増えてはいる)。
...とまとめると、なんかコードばっか書いていたようだが、コードを書いていない期間も相当長いため、少し振り返っておこう。
10年前、Java SE 6がナウだった時。ナウなヤング、ではなく、ナウおっさん化中だった私は、Java 6/Scala2.7のキャッチアップに努め、仕事もそれら言語でこなしていた。すなわち、オブジェクト指向Java(+時々、べターJava)なコンボである。
当時はSIer界隈に(私が見る限り)激震が走ったリーマンショックの後。それまで、納期を守る君で臭いコードを書きまくっていた私に(Code smells !)、暇ができ、子供もできた。
そして、翌年の某案件の納期の日に東日本大震災が起き、ご縁あって見知った街と見知った人とが(津波後の火災で)焼失した。長門有希ちゃんの消失以上のショックであった。とりあえず次の案件をキャンセルした私は、気仙沼線にたどり着くまでに延々と続く海岸沿いのガレキを前にガレキ掃除の真似事をし、以後3年間ほど、コードを書かなかった(食つなぐためにIT業界と一応関わりは持っていた)。
気が付くと、「とある科学の超電磁砲 S」をスマフォで見て、御坂妹たちにレールガンでアウターライズ震災で来る津波をぶっ飛ばしてほしいと思っていた私(おっさん)。Android Java案件時代の到来であった。Android Javaといえば、Java 6。すなわち、私のコーダー復帰の時である。Java 6で、Androidの複雑なステート管理も、出来はする。だが辛い。お客様への納品物はExcel至上主義なSIerさん界隈にいるが、時としてKotlinに心が動く。
そんな時、私はGAFAというバズワード(?)を知る。まぁ、グローバルにサーバ側でデータを蓄積している企業が強いっていう、アレだ。データといえば、データサイエンス、私は統計学に弱いながらもPythonな案件を選ぶことにした。スクリプト言語なPythonとはいえオブジェクト指向言語な訳で、なんとかなる。「ダンジョンに出会いを求めるのは間違っているか」一期が流れる中、ここにいるのは間違っているのかもと思いつつ、統計も勉強しながら頑張りました。
その後、おそらくはグローバルなweb界隈のトレンドのも、Scalaのweb界隈のシェアが3年間で3倍増する中で、サーバ側のScalaエンジニアに復帰する。
で、おっさんScalaエンジニアとして頑張り続ける道もあったのだが、ふとJava/Scala+データ使い=けっこう最強じゃね？、と思い、昨年に転職し今に至る。
今年になり、仙台湾に懸念されたアウターライズ地震が起きることなく、コロナ騒動がおき、あろうことか私は真っ先にウィルス性肺炎で数か月に渡り体調不良でダウンするのだが(保健所トップがいろいろ頑張った某県にて、私のPCR検査は水際阻止されていた)、100%リモートワークOKなおかげで、有休休暇を2日ほど消化するだけで業務継続できた。
てなわけで、データエンジニアに必要なスキルセットとは？
大したスキルではない。
SIer業界(加えて「案件ガチャ」状態なフリーエンジニア業界)にいた私は、現場の空気に(一月以内に)マッチすべく全力を尽くす力はそこそこある。つまり、MySQLであろうとOracleであろうとRDBMSは使えるし、メジャーなWAF(Spring/Play etc.)であろうと謎のWAFであろうと、(基本的には)多少ご迷惑をおかけする程度で何とかできる。まぁ、エンジニアとして普通なこのスキルを持って、データエンジニアとして生きていくことはできる。
いわゆる(ビックな)データはどこに格納されるのか。普通にRDBだったりもする。他方、キャッシュにredisが使われ、インデックスはElasticSearchに張られたりする。加えて、メインのデータの格納先はHive/HadoopやMongoやSnowflakeなどのNoSQL/SaaSであったりするわな。
でも、かつてのオブジェクト指向設計、近年のドメイン駆動設計を学んでいるJava/Scala使いならば、当然、問題はない。データの格納先の類のPeripheralな話はオニオンの外側の話なのだから。
エンジニアとして、まっとうなスキルを追求すれば良い。
一時期、国内の「案件ガチャ」業界(フリーエンジニア界隈)にいた私は、不思議に思っていることがある。グローバルな求人ではけっこう目にするデータエンジニア(DE)という募集職種が、日本の案件にほとんど見当たらないことに。
別に間違ってはいない。前述のように一定のレベルに達したエンジニアは、データエンジニア(DE)の職種も当然にこなせるのだから。
だが、時間単価で、データエンジニア(DE)の単価がプログラマ(PG)の単価と有意に異なる(けっこう良い)という一般的な事実と比べたらどうだろうか。もちろん、例えば、プログラマ(PG)の単価より、上位レイヤーで(ドメイン駆動な)設計を行うアーキテクトの単価が高いことは分かる。まっとうな設計がなされることで、まずい設計の下でプログラマたちが費やすこととなる残業時間の多くが無くなるのだから。ただ、(私の実感としてはだが)データエンジニア(DE)とプログラマ(PG)とがこなすレイヤーは、ほぼ同じ。
だが、転職市場/SES市場では、前者の時間単価の方が1.2～1.8倍ほど高い気がする(個人的な感触)。
う～む。
データエンジニア(DE)に求められるマインドセット
以下、データエンジニアって何よ、的な方は以下をチラ見のこと。
https://qiita.com/e-a-st/items/42c03c61e4003c3b3ee5
実務家(ユーザー) << データ、という職場
データエンジニア(DE)という職種が、相応の待遇を得られる職場には「実務家(ユーザー) << 蓄積されたデータ」という価値観があると私は思う。年の売り上げが10億円であろうと1兆円であろうと、その売り上げを支えているのは蓄積されていくデータであるとされる職場。ここでは、実務家(担当者)が誰に変ろうとも、マスターデータとトランザクションデータとが、適切に管理されることが至上の価値となる。
これが、データエンジニア(DE)が働く職場の一典型。
中長期の視点とアジャイルというマインドセット
① 参入障壁としての、中長期に渡るデータ蓄積
蓄積されたデータに対価を支払いたいというお客様がいらっしゃる業界では、お客様向けに加工されたデータの蓄積それ自体が、参入障壁となる。
言わずとも分かるだろうが、データを蓄積し続けること(データを集め、加工し続けること)はけっこう大変。5年前、10年前と今とを比較し現場が稟議書を書き、経営層が意思決定をする必要がある業界に、新規参入者がデータ提供者として参入するハードルは高い。データエンジニア(DE)はそうした業界にいる。そのため、ひとたびそうした業界に入ったならば、中長期に渡り安定的にデータを蓄積するための業務を行うこととなる。そうしたデータエンジニア(DE)を雇う者は、データ蓄積のノウハウのリスクを避けるために相応の待遇を提示してくることだろう。
② 参入障壁としての、データ蓄積のためのアジャイル
他方で、お客様に売るためのデータのソース(源)が他社/公的機関のものであることも多い。これらのデータソースは他社/公的機関の都合により、フォーマットやID体系が変更されることはある。
お客様にデータを提供する事業者は、当然ながら、そうした上流の変化は可能な限り社内で吸収しなければならない。
ということで、データエンジニア(DE)は、いつ起こるかはわからない社外の状況に適時・迅速に対応できるチームに属することとなる。Scrum(もしくはLarge Scale Scrum)なチームはその一典型。
そうした組織の経営陣は、データにまつわる状況の変化に迅速に対応するためのチームを維持することが求められるという訳。エンジニア視点からいうと、突然のことが起きない「凪」の時には定時に帰ったりスキルアップに努める時間があるというわけ。
私が定時後に何かしていると、お前は定時外に業務にまつわることがしないというご指導がしばしば入る。むろん、何かあったら、何とかしてやるわけだけれど、ね。
③ つまりは、データへのロイヤリティ。
データがまっとうに蓄積される限り、組織は永続する。
私のいる組織ではすでに半世紀以上、データを蓄積し続けている。当然ながらそのためのコードは陳腐化していく(私が目にするコードの多くは50年ものから、10年もの)。コードをナウなものへと漸次移行させながらも、データの蓄積は止めないこと。これがデータエンジニア(DE)の職責である。(10年以上前の担当者からまとも引継ぎを受けていない)現場の担当者が何を言おうと、蓄積されているデータのIntegrity(一貫性、まっとうさ)が全てに優先する。
このロイヤリティを保つために、あらゆるエンジニア・スキルを駆使するロイヤリティを持つもがデータエンジニア(DE)である、と、データエンジニア(DE)に分類されるキャリアは3年ほどの私が言ってみたりした。
データエンジニアへのジョブチェンジに、キャリアアップを求めるのは間違っているか？
エンジニア歴だけは長く20年を超える私が言えること:間違っているかもしれないし、間違っていないかもしれない。
ただ、デートエンジニア(DE)へのジョブチェンジ・転職も現実解のひとつであると思う。データベース設計力もドメイン駆動設計力も普通に求められているし、役立つし。コロナ騒動な何かとかで、何らかの嫌がらせにあってちょっと進む道に迷った人は、特に。私は一日5時間くらいしか起き上がれなくても、結果として有休をほとんど消化する必要となかった。ありがたや。
てな感じで、データエンジニア業界は、将来企業二階建て年金生活を送りたいおっさんホイホイな業界ですよと、「とある科学の超電磁砲 T」が終わり、少し黄昏ている私は言う。
常盤台中学生の皆さんは、10年近く先に「とある科学の超電磁砲 U(?)」でも同じ制服を着ることだろう。その頃に、私もおそらくは同じくおっさんデータエンジニアをしていると予知夢は語る。
もちろん、別のキャリアアップに向けてのジョブチェンジをゼロから始める異世界生活(第二期)もあるのだろうけれども。
なお、私が属するLarge Scale Scrum Teamという仰々しいチームで、私が行っている初歩的なコードレビューやリファクタリングのあれこれはここでは語らない(恥ずかしいから)。そのあたりをこっそりと聞きたくて、エンジニアリング力に応じたまっとうな(もしくはそれ以上の)待遇を得たい皆さんは私にTwitterなどで絡んでくださいな。なんといっても、相変わらず、人手不足なのです、この業界。
私はというと20年くらい後に定年した後にラノベ書いてるハゲになろうとして、日々、自らの白髪を抜いているのですが。
黙って、ラノベ書け、このハゲ(死語)。