データエンジニアとアナリストを両立するキャリアパスを考えてみる(エンジニア編)

f:id:drizzlyrain:20220120232422p:plain

はじめに

ちょうど最近、上司とキャリアパスの話をする機会がありました。

その中で、データエンジニアとアナリストのどっちの道に進むか迷っている、という話をさせてもらいました。

またデータエンジニアとして吹っ切る、という考え方もあるとは思っています。

ただ現時点では、アナリスト要素をキャリアに取り入れたい、と何となく考えてます。

そこで、データエンジニアとデータアナリストとしてのキャリアを成功させる？ためにどんな要素が自分に足りないのか？をメモ書きとして残していこうと思います。

もうちょっとスペック的なことを書いた方が良いかもですが、分かっていること・分かってないことを書けば自明になるかなと思って省略します

私自身のキャリアの変遷

これまでデータエンジニアとして2.5年ほど、その前はデータアナリストとして2年ほど勤めてきました。

データアナリストをしていた頃は、SESの形態で客先に常駐して勤務をしていたため、扱いたいデータを全て触ることができない

また分析基盤と呼ばれるものも無い状態だったので、自分で分析用のデータマートを作って、消して、作って・・・、ということを繰り返していました。

その過程を通して、自分で分析基盤を構築して、データ分析ができたら最強なんじゃね？みたいに社会人1年ちょい過ごしてから感じたわけです。

あとはSESは力がないと現場を選べず、一旦正社員として勤務してスキルを高めないとやっていけないなあ、ということをやっと感じ始めた頃だったと思います。

そのため、新卒で務めた会社を1年半ほどで退職して、現在勤めている会社に転職することにしました。

転職した当初は、社内のデータに慣れるためにいわゆるデータ抽出業務と呼ばれるものを行って、Redash上に登録する、みたいなことをやってました。

そのため、最初はアナリスト要素の方が強かったです。

その過程で、embulkを利用して、BigQuery上にデータを集約するようなETL回りの業務を少しづつ、行うようになった感じでデータエンジニアとしての経験を積み始めた、という流れです。

転職後にデータエンジニアとしてやってきたことを書いていると本題に入れないので、キャリアの変遷はこの程度に留めたいと思います。

まずはキャリアパスを考える上で短期的にやる必要のあることと、長期的に行っていくことに分解をしていこうと思います。

ただ、自分に足りない要素を考えていく上で、自分が見えている範囲しか気付くことができない、という問題は強く意識する必要があります。

そこで、実は以前参考にしつつ挫折した、データエンジニアロードマップを再度参考にしたいと思います。

github.com

データエンジニアとして足りない要素

CS fundamentals

いわゆるコンピューターの仕組みに関する部分だったり、Linuxについて知る、ということが挙げられてます

ここら辺は、去年このロードマップをなぞって学習を始めたときに、社内のドキュメントにまとめたので、移植してみようかな..

Learn a programming language

ここでは、pythonやJava、Scalaが挙げられていますが、python自体も凄い書き慣れている訳じゃないんですよね..

今pythonで実装されているものの機能を拡充させていくとか、関数やclassを利用して簡潔に書く、ということをまずはやっていく必要性を感じています

pythonの開発者がtypescriptが素晴らしすぎて、pythonの4系が生み出されることが無い、みたいなことを発言して話題になっていた記憶はあります。

ただそれを見ても、何が良いのか？をあまり分かってない、というのが正直なところ

テスト観点

いわゆる単体テスト、結合テスト等はアプリケーションエンジニアではないから、という区分はおかしいかもですが、ほとんど意識せずに過ごしてきました。

直近、cloud composerを利用してワークフローを構築したりするようになったので、ここら辺はまだ業務で経験できるかも、と思っている自分はいます(本当か？)

RDBに対する理解

・BQが列志向で、RDBが行志向
・アプリケーションから参照される際に、BQは不向きだけどRDBは適している
などは、BQとの違いを理解する、という観点で勉強したり、調べたことがあるので理解はしています。

ただし、RDB自体は業務で扱う機会が少なく、理解が乏しいです。
embulkで参照する、ということは何度もやっているのですが..

DBAの方にインデックスを貼ってOKと言われて、対応したところ永遠に終わらない、という事件(自分の中で)ありました。
結局その後にDBAの方にフォローしてもらったりしたのですが、その過程でインデックスを貼る仕組みをやっと知る、というレベルです。

DBAの方「BigQueryは富豪ですよ」という言葉は忘れられないです。笑

DBを自分で建ててみる、というのが1から流れを理解できて良いのかな..

DWH

ここでいうDWHは、いわゆるデータ基盤の分類におけるDWHではないです。
少し前から話題になっているSnowflakeとか、BQやRedshiftの話ですね。

データ基盤をどこに構築するの？という技術選定を行っていく上で、これらの違いを理解することは必要だと感じています。
全く分かっていないことを優先すべき、という観点で考えるとこの辺りはちょっと優先度が下がります。

Monitoring and observability for data pipelines

ここら辺も全然経験出来てないですね。。
というか挙げられているサービス名で知らないものが多い、というレベルなので、まずは調べてみるところからか..

GCPのCloud loggingとは違うのかな？というレベルの分かってなさ

ZABBIXに近いのかな？

qiita.com

インフラ面のナレッジ

良くも悪くも現在のデータ分析基盤はGCPのBigQueryを採用しています。

そのためインフラ面はあまり理解していなくとも、分析基盤を構築することができてしまうと感じています..

例えば、GCP上にDBを建てた際にファイヤーウォールを設定して、とかそういったネットワーク回りの要素は全然分かっていないです。

既存の社内サービスはRDBを利用していて、インフラが社内ネットワークを構築しており、その中でBQ上にデータを集めるだけで良かった、という背景はありますね..

以前、社内勉強会で何となく参加して、フワッと読み終えたTCP/IPの本を再読すべきか？？

www.amazon.co.jp

Infrastructure as Code

少し前にmecabでテキストマイニングを行う過程で、ユーザー辞書とシステム辞書を日次で更新する、ということを行いました。
その過程で初めてDockerを利用して、何となく理解できたことは良かったです

また先ほど挙げたCloud composerでのワークフロー構築の過程で、Terraformも使い始めています。
GCPのIAMを割り振っていく過程でも使えたらと思っているので、この部分も若干優先度が低そうです。

Dockerを使う必要性のある業務があんまりない、と現時点では思っているが、こういったことにも使うと便利だよ、ということを気付くことが必要な気がする..

CI/CD

ここは理解がめちゃくちゃ甘いです。
Jenkinsを社内では使っていますが、1から設定したことはほぼ無いです。
gitlabからgithubに切り替えていこうという動きが社内であったときに、ちょろっと新しいjenkinsを登録したぐらいですね
ただこの際も、既存の設定を参考に行ったので、細かい設定とかほぼ調べずに対応できてしまいました(良くも悪くも)

またGithub Actionsに関しては、一度も使ったことが無いので業務の改善タスクとして積んでみようかな..
時間を作っていくという観点を重要視したときに、この改善タスクは順位が上がりそうだと考えています。