データエンジニアがバックエンドエンジニアに転生してみた振り返り
この記事はFOLIO Advent Calendar 2022の21日目の記事です。
はじめに
こんにちは。FOLIOでデータエンジニアをしている西山です。
普段はFOLIOではデータエンジニアとして主にデータ基盤のインフラやバッチの開発・運用から、マーケティング案件のデータ周りの効果計測設計から実際のデータ抽出、その他各ステークホルダーからのアドホックなデータに関する依頼の相談・対応などスタートアップらしく?データ周りの何でも屋的な仕事をしています。
ですが、実は私は直近半年弱バックエンドエンジニアとして業務を行っています。
というのも、先日公開になった案件に向け全社一丸となって取り組むため、社内のエンジニアの配置転換を伴う開発リソースを集中する施策が行われました。私もその対象となり、主に4RAPのアプリケーション開発チームに期間限定の異動をした形です。異動後はチームの共通言語でもあるScalaのAPI開発をおこなったのち、主にTypescriptを使った開発をメインに担当しています。異動の期限はもう少し先でもあるのですが、ある程度期間があり、また年末ということもあり今回の異動について振り返り記事を書いてみることにしました。
バックグラウンド
私はデータアナリストからキャリアを始め、そこから徐々に必要ベースでデータ分析基盤の経験を積んでいき、いつの間にかデータ分析とデータエンジニアリングの比率が逆転してきたため、ここ数年はデータエンジニアを自負しています。
私の経験上、現在データエンジニアとして活動されている方の中には、私と同じようにデータ分析の経験を積む中でデータエンジニアにシフトしてきた方が一定数いるようです。この記事では主にそうした方に、「(バックエンドエンジニアを経験していない)データエンジニアがバックエンドエンジニアを経験してみてどうだったか」という経験談として伝われば幸いです。逆に、元々バックエンドエンジニアないしSREとしての経験を積んだ上で、データエンジニアにシフトしてきた方も多いと思います。そうした方には今回の経験談は共感しづらいかと思いますが、あくまでそういう見方もあるのねとご笑覧いただけると幸いです。
異動にあたって考えたこと
異動の打診を受けた際は、ポジティブに受け止めました。私の業務経験、また何度かの転職経験を踏まえて考えても、こういったある意味ドラスティックなroleの変化はなかなか狙ってできるものではありません。
また、Scalaをメインの言語として利用しているFOLIOで曲がりなりにもエンジニアを名乗っているのにも関わらず、Scalaの実務経験がないことにやや引け目を感じていたのも事実で、(実は以前から社内留学のような形での期間限定の異動が出来ないかを上司に1on1の場で相談したこともありました)これはチャンスと思い飛びついた次第です。
もちろん、データ関連の技術は移り変わりが激しく、データ関連の業務から離れることでそれらにキャッチアップしづらくなったりする懸念を感じたことも否定しません。が、こういうタイミングは何度もあるものでもないと思い(何度もあっても困りますが)飛び込んでみることにしました。
余談ですが、FOLIOには「変化を楽しむ」というValueがあり、変化の激しいスタートアップにおいて外的な変化を受け入れ、また自ら変化を起こしていくことをよしとしていますが、こんなにわかりやすい形でこのValueを体現する機会が訪れるとは思っていませんでした。笑
オンボーディング
まず異動にあたっては、オンボーディング用のハンズオン課題を行うところからはじめました。catsやdoobieといったチームでよく利用するライブラリの業務に即したチュートリアルや、テンポラルデータモデルなどFOLIOのシステムの基礎となっているデータモデル(参考)の理解のための課題に取り組みました。全体的に丁寧に作られており、本格的にScalaを書いたことがない(Sparkを書くためにちょっと触ったことがある程度)私でもある程度開発のイメージがわきました。
なお、別チームでのオンボーディングの事例が今年のFOLIOアドベントカレンダーの記事として公開されていますのでぜひそちらもご覧ください。
そこからもチームの既存メンバーにメンターとなってもらい、定期的にペアプロを行ってもらうなどし、初MRのマージにこぎつけました。
私事ですが、昨年の秋に第一子が生まれたばかりということもありプライベートの時間を自分のためだけに使うのが難しい状況が続いていたので、業務の中で手厚くオンボーディングしてもらったのはありがたい限りです。
実際にやってみてどうだったか
まず最初に圧倒されたのがプロジェクトの規模のギャップです。異動後にメインに参画した開発プロジェクトでは、他のチームからメンバーを集めていることもあり、各担当の機能を10人前後の規模で同時に並行して開発を行っているような状況でした。これまで私がデータエンジニアとして開発に関わっていた規模だと多くても5人程度の規模で、データ分析基盤の開発・運用となるとETLバッチの開発やインフラ構築などタスクが分散しがちで、ここまでの同時開発は経験がありませんでした。直近私もデータエンジニア採用に関わる中でお会いする人たちの話も聞く中で、データ分析基盤の開発プロジェクトでこの規模、変化の激しさで開発が進むことは一般的にもなかなか稀なのだろうと思います。もちろん、大手IT企業やメガベンチャーと言われる企業などの例外はいくらでもあることは承知の上です。
さて、FOLIOは金融サービスを提供している企業であり、堅牢なアプリケーション開発が求められます。上記の規模の中でも一定の品質・スピードで開発を進めるために、目の前の機能開発を行うだけでなく、各タスクで使い回せる共通のコード基盤の開発も並行して行う、またコードに落としづらい部分についてはADR(Architecture Decision Record)としてドキュメントを残すなど、結果として各メンバー間でコード品質がぶれづらい環境を整えながら開発を進めていることも印象的でした。
ふとしたときに自分がデータエンジニアとして書いたコードを見直すと、アプリケーション開発チームで学んだエッセンスが活かせそうなアイディアが思い浮かぶなど、自分のソフトウェアエンジニアとしてのスキルが底上げされた実感がありましたし、チーム運営にあたっても上記のようなコード品質を保つ施策もエッセンスとして活かせそうです。
また、実際にFOLIOの大半のプロジェクトで利用されているScalaアプリケーションのコードの構造を理解し、読み書きできるようになることで、自分が関わったプロジェクトはもちろん、他のScalaプロジェクトでもコードの流れを追いながら理解することができるようになりました。これは、エンジニアとしてというより、データエンジニアとしてデータ関連の依頼や調査を行う際に役立ちます。今までもENUMの定義を直接コードを見に行って確認したりといったことはしていましたが、今回の経験を経てある程度コードの処理の流れも追うことができるようになったと実感しています。これについては、「そもそもデータカタログがされていないのが悪い」などというのは簡単ですが、FOLIOのような組織規模において網羅性と鮮度が高いデータカタログを用意するのは現実的ではないと思いますし、こうした手段が選択肢としてとれるようになったのは素直に良かったです。一応釈明をしておくと、事業上重要性が高い各種KPIとそれの算出に使うデータはデータマートのクエリやドキュメント(含むデータカタログ)に落としていますが(参考)、新たに要件が増えたり仕様が変わるなど、それで網羅できないケースが出てきた場合の手段として、という意図で書いています。
ちなみに手前味噌ですが、データ基盤の運用を行うチームも人数が少ないアプリケーションチームに異動しここまで大きな支障なく業務ができたのは、入社時からデータ基盤の障害を減らし、またデータを整備するなどに取り組んできた成果でもあるかと思います。具体的には、データマートやデータカタログの整備、各種バッチやRedashといったBIツールなどを少しずつECSなどマネージドサービス上に移行(ちなみにまだ完全以降は出来ていません)など行ってきました。ただし、直近事業上データの重要性も増す中でどうしてもデータ関連の問い合わせや依頼、追加開発などは出てくるので、それらはチームリーダーや上司、依頼者と相談しながら対応しています。
終わりに
データエンジニアがバックエンドエンジニアになってみると、最初は迷いやなかなか成果を出せないことに対する焦りもありましたが、直近半年弱で良い経験を積めていると改めて実感しました。そして、バックエンドエンジニアとしても楽しくやれている一方で、今回の異動で得た経験を活かし、データ基盤の高度化に取り組んでいきたい気持ちも高まっています。
FOLIOのデータ活用の現在地としては、toC事業を例にしても、先述の通りある程度運用負荷が軽い状態にはできているもののビジネスサイドの要望に完全に応えきれているとは言い難いですし、技術的な側面だけでも、マネージドサービスへの移行やRedshiftの新機能の導入、数が多くなりクエリが複雑化しつつあるデータマートをdbtにマイグレーションするなどやりたいことはまだまだ正直たくさんあります。また、toB事業である4RAPのデータ基盤はリリースに向け絶賛開発中です。
もし少しでもご興味を持っていただけたら、カジュアル面談も実施していますのでお話ししましょう!
この記事が気に入ったらサポートをしてみませんか？