クラウド移住記：Google Cloud未経験者がSmartHRのデータエンジニアとして約半年働いてみた
はじめまして！2024年7月にSmartHRに入社したitokenです。
事業推進本部 BizTech部 データ活用推進・基盤構築ユニットで、データエンジニアとして働いています。
事業推進本部のアドベントカレンダーもいよいよ残り３日！今週で最後です 👏 🎄
私からは、所属ユニット名である”データ活用推進・基盤構築”の役割の中でも「基盤構築」に焦点を当てつつ、
SmartHRに入社してから半年弱、データエンジニアとして働いてみて感じたことをお話させていただきます！
後半は特に技術的なところに少しフォーカスしていますが、ご興味あれば最後まで読んでいただけると嬉しいです😌
なお、私の入社前からのデータ活用全般の取り組みについては、
hasedaさんの「過去5年の顧客データ系の取り組みと組織の変遷」、
データの「活用推進」における取り組みについては、
isseiさんの「約1年働いて感じた、SmartHRのデータアナリストとして働く面白さ」
をぜひご覧いただけると嬉しいです！
何をしてきた／している人なの？
かるーく経歴
冒頭で書いた通り、SmartHRには約半年前に入社しました。
SmartHRに入社する前はシステムの受託開発を行う会社におり、システムエンジニアとして5年間ほど働いていました。
その過程でBIエンジニアやデータエンジニアぽいことも多少してましたが、本格的にデータエンジニアと名乗ってキャリアを歩んでいるのはSmartHRが初めてです！
SmartHRに入社してやっていること
SmartHRでは、提供しているサービス「SmartHR」に日々溜まっていくデータやSalesforce/Zuora/Marketoといったビジネスサイドで利用しているSaaS（Software as a Service）プラットフォームに溜まっていくデータを日々 社内のデータ基盤に連携しています。
そして、データ基盤に蓄積されたデータは、RedashやLookerといったBIツールなどを介して社内活用されています。
そんなデータ基盤まわりの仕組みの開発・整備・改善が主な業務内容です。
縁の下の力持ち的な役割なので、端から見ると正直ちょっと地味かもしれない。けれど、全社的にデータを使った意思決定をしていく中で「データがあること」は大前提になってくるので、安定して利用できるデータを継続的に蓄積し提供することは最重要といっても過言ではないと思っています。
半年働いてみてどう？
前職でもデータエンジニアぽいことはしてたとはいえ、個人としては業務内容や立ち回りが結構ガラッと変わったな〜というのが一番に出てくる感想です。
全部書いているとボリュームオーバーになってしまう（それだけ新しい経験ができています）ので、
その中でもデータエンジニア観点で"個人として扱う技術スタックが変わったこと"を中心に、この半年間を振り返ってみようと思います🙌
SmartHR入社後に初めて触ったものに関してはまだまだ勉強中の身のため、偏った意見になっているかもしれませんが、一個人の意見としてフムフムくらいに捉えていただければと思います🙏
転職前後での技術スタックの変化
前職では、データ基盤まわりの技術スタックについて以下を中心に扱っていました。
クラウド：Amazon Web Service
データウェアハウス：Snowflake
BI：Tableau
対して、SmartHRの入社後は以下を中心に扱っています。Google系のサービスはド初心者だったので、SmartHRに入社してから触り始めました。
クラウド：Google Cloud
データウェアハウス：BigQuery
BI：Redash, Looker, Looker Studio
（ちなみに、前職でもSmartHR入社後でも使っているサービス・ツールというと、Slackとビデオ会議ツールくらいしかないことに書きながら気づきました👼）
※なお、以降の文面ではGoogle Cloudを「GCP」、Amazon Web Serviceを「AWS」と略称で記述しています。略称が「GCP」で良いのか？論争はここでは割愛します🙏
技術スタックが変わっても、ベースとなる考え方や仕組みがわかっていればそれほど恐れることはない
私の中での結論は、コレに至りました。
SmartHRへの転職時に
「転職先では今まで扱ってきたサービスやツールはほとんど使わないです〜」
的なことを周りに言うと
「結構大変じゃない？」
という声をちらほらもらっていました。
私は「まあ大丈夫かな〜、むしろ技術者としての幅が広がってプラスな面が多そう」と考えながらエイヤッでSmartHRに飛び込んだのですが、正解だったと思います😌
もちろん、なんの抵抗もなく触れるようになったか？と言われると
そんなことはなかったですし、未だに理解しきれていない部分もあります。
最初にGoogle Cloudのコンソール画面を見た時はフリーズしました。笑
それでも類似サービスを触っていた経験・知識があることで、確実に理解は早かったですし、”完全に一から覚え直し”という感覚はありませんでした。
どんなサービスでも可能な限り内部のアーキテクチャや仕組みをきちんと理解しておくと、類似サービスを扱う時でもそれほど苦労しないと思います。
データウェアハウス製品（BigQuery, Snowflake, …etc）でいうと、一般的なアプリケーション用のデータベースとアーキテクチャ構造が大きく異なるので、その辺りの仕組みの理解はBigQueryだろうとSnowflakeだろうと他のサービスだろうと必須かなと思います（もちろんアーキテクチャ構造以外にもいろいろありますが）。
とはいえ、機能に差異があったり、意味合いの異なる用語があったりするので注意が必要
ただ、類似サービスといえど完全に一緒ではないので、
「前触っていたサービスにこんな機能があったから、類似サービスもこういう機能はあるだろう」と思っていたら、ちょっと仕様が違ったり、そもそもその仕様がなかったり。
特にそのサービスを使った時に発生するコスト面の違いを理解していないと「思いの外コストが嵩んでいる…」ということにもなりかねないので、様々な技術要素が絡んでくるデータ基盤開発においては注意が必要だなと思っています。
（"データエンジニアは総合格闘技"というフレーズもちらほら耳にするくらいなので🥊）
類似サービスの知見を持ちつつも、「似たような機能っぽいけど、本当に同じような仕様なのか？」と疑問を持つ意識は持っておくべきだなと思います。
最近はむしろGCPとAWSで用語も機能も全く一緒だと、本当に一緒なのか？と心配になるようになりました。笑
例として一つ取り上げると、権限設定周りが各サービス間で違いが大きいなぁと思っています。
例えば、権限を表すサービスとして「IAM」というサービスがAWSにもGCPにもあるのですが、
AWS の IAM は、 ”どのリソースに対して何ができるか" を人に紐づける
GCP の IAM が、 "誰が何をできるか" をリソースに紐づける
という考え方がベースになってくるので、根本の思想が違います。
そのうえで、AWSでもGCPでも共通して「ロール」や「ポリシー」というワードが出てくるのですが、根本の思想が違うゆえに用語の意味合いも異なってくるので、
何気なく社内で権限周りの言葉を使うと認識齟齬が生まれてドボンします😱
データウェアハウス製品においても権限設定周りはかなり違ったりと他にも色々あるのですが、上記のように同じ用語でも定義が違うことがあるので、コミュニケーションは気をつけるようにしています（むしろエンジニア以外の方と話すときの方が平たい言葉に変換して話そうとするので、ドボンしない気がしたり…）。
システム用語に限らずですが、共通の言葉の定義をすり合わせてから会話や議論することはやはり大事だなと思いました…！
SmartHRだからこそ、キャッチアップがしやすかった面も
SmartHRのデータエンジニアとしてジョインできたからこそ、技術スタックが変わってもキャッチアップにそれほど時間がかからなかったとも思っており、その理由を３点ほど挙げてみます！
１．社内ドキュメントがオープンに公開されている
SmartHRでは、社内で公開して問題のない議事録やドキュメントについては、所属部門に関わらず社員全員が自由に参照できるようになっています。
データエンジニアはビジネス部門の所属ですが、技術的な事に関してはプロダクトの開発部門の情報が参考になることも多いです。
情報の整然さに差はあったりするものの、それらの情報を簡単に参照できることで技術面のキャッチアップにかなり役立ちました。
（業務に直接関係なくとも興味本位で見て参考になるものも多くあるので、とてもありがたい…！）
また、弊社は過去に基盤となるクラウドサービスをAWSからGCPに移行した経緯があり、当時のドキュメントや記録が残っていたりもします。それらの情報は古いものもありますが、AWS界隈から移ってきた自分には理解の一助になることもありました。
他部門が持っている情報を参照することに障壁がない、SmartHRのオープンな文化もいいなと思うところです！
２．オンボーディングが手厚く、初期のキャッチアップがスムーズだった
SmartHRには毎月数十名という社員が入社するのですが、全社的な受け入れ体制が非常に整っており、手厚いオンボーディングがあったことが印象的でした！
それによりデータエンジニア業務に集中しやすい環境ができ、初期のキャッチアップも比較的スムーズに進めることができました。
周囲のメンバーも積極的にサポートしてくださるので、めちゃめちゃ仕事がしやすかったです。これといった不安がなかったことで、心理的にも余裕があったのは大きかったかなと思います。
少し話は逸れますが、入社してから１ヶ月後の8月にはGoogle Cloudが主催する年次のカンファレンス・イベント「Google Cloud Next Tokyo '24 」にも参加させてもらい、GCPのサービスの全体感や最新トレンドの把握にも役立てることができました。
３．SlackでGoogle Cloudエンジニアのサポートが気軽に受けられる
SmartHRでは、チャットツールとしてSlackをフル活用しているのですが、SlackからGoogle Cloudのカスタマーエンジニアと直接連絡をとることができるので、そこで技術的なサポートをしてもらえます。
直近では、データ基盤のETLパイプラインの一部を「Dataflow」というGCPのサービスへ移行しようとしていたのですが、パフォーマンス課題が発生し・・・というところで手厚くサポートをしていただきました（Slackのスレが50件ほどになるまでやり取りさせてもらいました🙇）
自分自身で調べて解決することももちろん大事だと思いますが、Google Cloudのエンジニアとやり取りすることで、各サービスの理解やベストプラクティスなどの把握に役立ち、理解を深めることができました！
SmartHRのデータエンジニアにチャレンジして良かった！
ITの中でも、とりわけデータ基盤まわりの技術スタックの進化はめちゃめちゃ早いと思っていて、１年キャッチアップしていないだけで全然ついていけなくなると思います。
そんなスピード感なので、「このサービスしか扱えません」はかなりリスクだと考えています。
データ基盤関連の複数のサービスを扱った経験があることで、トレンドのキャッチアップもしやすいですし、技術選定やアーキテクチャ設計等をする場面での納得感も増すと思うので、
今現在、SmartHRでGoogle Cloudまわりのサービスに触れて、まだまだ発展途上にあるデータ基盤の業務に携われていることの恩恵は大きいなと感じています！！💪
終わりに
事業推進本部には私のユニット以外にも、ビジネスサイドで組織の生産性を向上させるため、さまざまなバックグラウンドを持ったメンバーが働いています。他のメンバーのアドベントカレンダー もぜひ読んでみてくださいね🎅
明日12/24(火)は、私と同じデータ活用推進・基盤構築ユニットのtakashoさんが「データマネジメント」の取り組みについてお話くださる予定です！👏👏👏
最後まで読んでいただき、ありがとうございました！