1人データエンジニア4年間の学びと悩みを総括

こんにちは！ゲンシュンです。
datatech-jpアドベントカレンダーの18日目です。（めちゃめちゃ遅くなってすみませんmm）

ここ最近、FindyToolsさんのアーキテクチャconf、Sansanさんのキャリアイベント、datatech-jpのみんなの考えた最強のデータ基盤アーキテクチャ等いろんなイベントに登壇させていただきまして、アーキテクチャ話からキャリア、仕事への向き合いまで様々なお話をさせていただきました。
どのイベントでも言ってますが、前提データエンジニアのミッションや業務領域は、事業フェーズや組織規模によって多種多様なためキャリアのロールモデルがそんなに無く、多くの方が模索していると思ってます。自分も流れ着いた先が結果的にデータエンジニアという職種で、組織から与えられた役割/ミッションなどが変わりながら1人データエンジニアとして試行錯誤してきました。

てことでこの記事では、データエンジニアとしての4年間を振り返りながら、ミッションに対して「意識したこと」「悩んだこと」を思い出せる範囲で振り返っていこうと思います〜。で、色々振り返ったら1万文字を超えてしまった笑！たくさん書いたので、何か1つでも参考になる部分があれば！

1年目

広告事業のPMからSaas事業のプロダクト戦略へ配属が決まり、データ基盤を立ち上げることに。
開発、人事、PMと様々な職種を経験してきて、これからは開発兼プロマネがキャリアの軸になるのかな〜とか考えていたんですが突如データエンジニアに。なんか面白そうだしとりあえず頑張ろう！ってなりました笑

ミッションは、プロダクト戦略のデータ基盤の立ち上げ。

意識したこと

データ基盤要件の明確化

データ周りはカオスでした。どんな指標を見ていくのか、今どんなデータが溜まっているのか、今後必要なデータは何か？データ基盤の業務活動は誰(部署)にしてもらえるのか、逆に対立関係になり得る部署ってあるのか（個人情報系の扱いが慎重なスタンス等）、とにかく現状整理から始まりました。
最終的に「誰が」「何の意思決定のために」「どんなデータが必要なのか」を明確化、そのデータは取得可能なら工数は？取得不可なら技術的に可能なのか？を固めていきましたね。特に「誰が」と「何の意思決定のために」は気づいたら要件が膨れ上がってクソデカプロジェクトになってしまうのはあるあるだと思うので、初期は目的をシャープにしたいです。

冪等性からデータ基盤を作る

最初期のデータ基盤アーキテクチャは冪等性の担保を最優先で実装 しました。広告事業時代の経験として、レポート集計の夜間バッチが途中でコケた際「冪等性担保されてるので、再実行さえしておけばデータ重複せずに集計できる〜」という安心感がありました。正常系よりも異常系で面倒にならないことってやっぱ大事で、リリースやバグ改修による手動でバッチ実行したら一部のテーブルに重複データ入っちゃった！とかになると本当に面倒なことになります。
そこから分析のユースケースが固まるまでは、アナリストが欲しい情報.sqlをとりあえず即作り、冪等性が担保されたスケジュールクエリを1日1回定期実行してデータを溜めていきました。並行しながらプロダクトデータのドメイン知識や、システムの仕様、GoogleCloudの技術のキャッチアップを進めました。

今思い返せば正直この時期が一番大変でしたね。事業もビジネスプロセスもデータのドメイン知識もGoogleCloudもデータ基盤も色々な解像度が低かったので、適切な進み方をしているのかが不安でした。ただ100点満点がわからないのなら、50点クオリティで速攻作り即改善というプロセスを何度も重ねることが大事 だなと思い、スピード重視で序盤進められたのは良かったです。

わからないことをわからないと明言する

自分がわからないことや疑問を周りが見える場所で発言することを意識してました。広告事業時代は「自分がわからない状態は表には出さない。不明点は後で裏(こっそりみたいな意味じゃないすよ笑)で調べたり人に聞く」だったので、完全に逆のスタンスっすね。
一応自分なりの意図はありまして、新設チームだし自分含め新しいミッションが与えられたメンバーが多く、プロダクトのことも移籍したばっかりでわからんこと多いだろうと（知ってたらごめんね笑）。不明点や「俺的には◯◯だと思うけど△△なのってなんでだろう？」みたいな雑な疑問でもいいので、とにかくslackやMTGでこの手の発信を増やしてました。チームメンバーからも同様の疑問や不明点が出てきたら、情報足りてないね取りに行こうぜ！というチームのアクションになるし、自分の疑問を見た他部署の人がslack教えてくれる時もあったりで、まぁ良かったかなーと思います。

とにかく プロダクトの戦略を立てるのがミッションのチームなので 「わかったつもりになっていた」状態をとにかく撲滅したかった って感じです。

悩んだこと

データの品質担保をどうするか

自分の思考がアプリケーションエンジニア寄りだったので、初期はBQのテーブルスキーマを基本的にREQUIREDにする等ガッチガチにしてました。アプリケーションはどこかでvalidationが入りますが、初期データ基盤ではvalidationが無かったので想定外のNULLがそこそこ入ってきました。これの原因がSQLの実装がイケてないバグ由来なのか、想定外のデータパターン(NULLが入り得る正常系)が発生したのか、プロダクト側のバグでNULLデータが入っちゃったのかをまず判断しなきゃいけないし、何より スキーマのエラーでジョブが止まってしまうのでその日中に修正しないとデータが欠損しちゃうのがとにかく辛い。。
また新機能追加による既存分析テーブルにカラムを増やす際、データ的にはNULLは入り得ないが過去日付のデータは存在しない。ではリリース前のデータに、FALSEやら0なのか穴埋めデータを入れてスキーマをREQUIREDにするのか、諦めてNULLABLEにするのかで悩みました。穴埋めデータは分析時に困る（そもそもスキーマのために適当な値を入れるのがなんか気持ち悪い）ということでNULLABLEにしましたね〜。

スケジュールクエリでデータを分析用に加工してるだけだったので、最終アウトプットのテスト等は出来ず。BigQueryのスキーマでデータの振る舞いや品質の担保は難しいし適切じゃないなーとぼんやり考えてました。またシステム側のリリース影響とかモロに影響受けるので、影響ある全スケジュールクエリを修正して、before/afterの件数をテストするSQLを手動で確認したり、地道な運用を続けてました。辛かった〜。

地道なメタデータ管理に苦労

データのドメイン知識やテーブルの仕様、データ欠損の利用やリリース日などの情報をとにかくドキュメントとして残したく、基盤開発向けや分析者向けにNotionで「データ基盤のトリセツ」を作りました。
超雑な例ですが、テーブルA(12/4にリリース)とテーブルB(12/8)をjoinした際に、テーブルBの「設定ON/OFF」カラムが、未設定(=NULL)というデータなのか、12/4〜12/7の期間はjoinの仕方によってNULLカラムになっちゃったのか、みたいなのって初期データ基盤ではあったので、毎回思い出さなくても済むようにしたかったです。ただ、これを続けたら情報量が膨大になるし、手動で全部自分が運用してるの回らなくなるだろうな〜という予感はありました。

2年目

dbtとterraform、dimensional modeling導入によるデータ基盤の進化や、Looker導入によるデータ民主化、データガバナンスに取り組みました。
dbtによる開発とデータモデリング改善が業務の中心になり、dbtめっちゃイイ〜!!ってなってました。terraformはスケジュールクエリ、サービスアカウント、ロール、データセット等のインフラリソースは全部管理してました。唯一の例外はBQのテーブルぐらい？（dbtがテーブルを量産するので、データセットまでを管理）。

ミッションは、データ周りの守護神に俺はなる！とそのデータを使った社内ユーザへのデータ利活浸透です。

意識したこと

dbtとdimensional modelingをとにかく学ぶ

dbt導入が始まりました(検証してくれたのは元チームメンバーのtenajimaさんです、マジで感謝〜)、要件は「冪等性の担保」と「バグったデータが取り込まれた際のリカバリが可能か」の2点でした。
ログ由来のテーブルはデータ量が莫大なためdbtのincrementalで作り、それ以外は基本洗い替えで実装したので冪等性は良さそう。そしてバグデータ取り込みのリカバリについては、BigQueryのタイムトラベル機能を使えばもとに戻せる（1週間以内であれば誰かがバグに気づけるっしょ！というノリ）ので無事導入へ。スケジュールクエリで頑張ってた時代から、dbtによるデータの品質担保と保守運用がしやすい新時代の幕開けです！

スケジュールクエリからdbtへの移行は、BIツールを使う 社内ユーザーへの影響を無にするため、数カ月間ダブルメンテ状態（スケジュールクエリもdbtも両方同じものを開発する） で乗り越えました。今思えは社内ユーザー影響を無にするのはtoo muchだったかも、まぁ当時はパワーで乗り切っちゃいましたが。

dbtの設計はBest practice guidesに準拠しました、ざっくり言語化すると以下かな。

• データレイク→dbt(stg→DWH→mart)→BIというデータの流れを死守。データ利用者にはmart以降からの取得を徹底、データ基盤開発も層をまたいた実装（例：stg→martのようにDWHを経由しない）をさせない方針
• mart層は部署など用途ごとにディレクトリを切り、集計ロジックはそこに集約
• テーブルがmaterializedなのかviewなのかはユーザは意識する必要がないので、データセットやテーブル名に実態有無の名前を入れない
• dbtのtestをとにかく駆使して品質担保。elementaryも併用してテスト結果をslackに通知して可視化

dbtって本当に便利で、アンケート定性情報とプロダクトデータをメアドで紐づけて分析するみたいなあるあるなケースも、ephemeralで結合テーブルを実装することで、BQにメアド含むテーブルを残すことなく分析結果を得られたり。
ここまでの話は第一回みんなの考えた最強のデータアーキテクチャで話しているので、気になる方はぜひ。

またdbt導入を機にタイミングでデータモデリングを知り、dimensional modelingの深淵へと足を踏み入れました。チームメンバーともたくさんディスカッションしましたし、もっと学ばなきゃと思い社外データエンジニアの方の勉強会に参加しました（今でも継続してます✌）。StarSchema、DataManagement at Scale、The DataWarehouse Toolkitなど分厚い洋書を読んで議論して理解を深められました。本当に良い機会に感謝です〜mm

DWHとBIの責務をチーム内で言語化する

アーキテクチャは、アナリティクスメンバーと議論して以下のような形に着地しました。
システム都合はdbtのstg層、基本的な集計はmart層で対応し、より分析都合な要素はlooker側のlookMLで対応、 martとLookerの境界線はあえて明言せずに緩めでいきました。データ基盤の開発が、データエンジニア+アナリティクスエンジニアと人数が少なく同じチームなので、現段階で厳密にするメリットがあまりなかったのが理由です。
基本的な集計がmartで出来たのは、日付、メンバーID、会社IDなど集計の最小粒度でベース実装が出来たからだと思ってます。期間は週や月でドリルダウンしやすかったし、任意の期間任意の会社単位で各部署ごとに集計ロジックが変わったとしても、group by元が一緒なのでdbt macroでいい感じに共通化出来たイメージです。

データ民主化とデータガバナンスを両輪で進める

社内への利用浸透活動にあたり、一部でデータポータル(現LookerStudio)が使われているのを発見。データポータルが現在更新されていない古いテーブルを参照していたので撲滅活動しつつ、基本的にデータ基盤のmart層以降のデータを使ってもらうように推進しました。

利用浸透も色んな施策をしましたね〜。個人の目標として利用人数を追っていた時期もあったんですが、 触る人を増やすのは大事だが増やすことが目的になっていて本当に目指したいことだっけ？ になりまして、特定のチームまたは人の具体の課題を解きにいく動きに変えました。小さな成功体験作って、データ基盤で◯◯がわかる！を少しでも実感してくれる仲間をちょっとずつ増やしていくイメージです。

悩んだこと

dbtのディレクトリ構成

チーム内で議論した内容として覚えているのは、ディレクトリの切り方をドメイン(機能)単位にするか、ユースケース(部署)単位にするか。

• 機能で切るメリットは、長期スパンで見ても変化しづらいので保守運用が楽そう。一方、部署によって見たい指標が違うので集計ロジックの差分はどこで吸収するべきか難しい。
• 部署で切るメリットは、その指標を見せたい人に見せられるのでシンプル。年に数回組織体制が変わるのでそれに追従する必要があったり、特定の部署にはこの指標を見せたくない、みたいなケースがあると実装が難しい。

こんな感じです。当時はプロダクト部に特化していたデータ基盤が、ビジネス方面への展開も求められていたので、部署単位で切りましたね。超レアな集計は、アドホックに実装し運用フローが固まったら取り込むみたいな感じで。

対システム方面へのコミュニケーション

dbt導入してもシステム側の変更に追従する必要がありますが、対システム周りで2点ほど悩みました。

1つ目はシステム仕様についてまぁまぁ深めな理解が必要だったこと。
変更履歴を追うデータについてはdbt snapshotを使ったSCD Type2で対応出来ます。めちゃめちゃ便利なんですがデータソース側で ModifiedAt のカラムが無いと「どのカラムが上書きされ得るのか」をデータ基盤が参照する全てのテーブルで把握しなければならなかったです。まぁ聞けば済む話なんですけど、データソースって正規化されてることが多く、テーブルのリレーションを把握してstg層やDWHで非正規化することが必要なのに、それに加えてカラムの上書き有無も把握しなきゃあかんのか、、、となってました。

2つ目は、ユーザ影響無いが分析に影響があるプロダクトバグについて。
「バグ=顧客影響がある」という前提があったので顧客影響ないリリースの扱いに温度差がありまして、データ基盤目線だと分析影響あるのでバグに見えます。これは誰が悪いとかそういう話ではなく、 バグについて組織ごとに認識が揃っていないので揃えていく動き をしました。チーム上司に相談しながら打診し、CTOやマネージャーからトップダウンで決めていくような動きです。この辺の動きってデータエンジニアあるある話だと思ってて、ステークホルダーが多いとコミュニケーション周りで難しい場面が出て来やすいです。ボトムアップ/トップダウンどっちが適切なのか、部署を横断して認識をどう揃えていくのか、これは一人で決めずにチームや周りに相談してやっていくのが良いと思います。

開発チーム方面へのコミュニケーションで意識したことはデータ基盤チームが組織に周知する際に意識したことにて詳細まとめてるので、こちらも気になった方はぜひ。

データ分析業務で自分たちのリソースが逼迫

データ民主化やデータ基盤の浸透に伴い分析依頼が殺到、チーム人数が少ないので捌くので精一杯になるという嬉しい悲鳴。自分はpythonを使わなくてもBIツールやデータ基盤で出せるような軽度の分析依頼を受けてました。
依頼のうち一部はBIツールで自分たちで出してもらうようお願いしたり（データステュアートになって欲しい）、要件を落としてシンプルに行くよう交渉したりしました。要件調整は大事だと思ってて、 分析依頼の目的って「データから示唆を得ること」であって「依頼内容をこなされたら良い」ではない ので、依頼者の依頼をそのまま受け取る作業者にならない意識が大事です。超複雑な要件（厳密に出すならRagged/Variable Depth Hierarchiesを使う必要がある）を超シンプルにしたのが個人的な成功体験だったな〜と。

3年目

前半はプロダクト側のシステム大移管の対応に集中！データ基盤への影響を最小限にしつつ、様々なシステム移管対応をしてました。リファクタをしてたら結構キレイな基盤になった記憶です。後半はプロダクト戦略業務中心で、事業戦略とプロダクト戦略の接合や各チームの目標に対してデータ基盤で何ができるのか？などを考えるフェーズでした。データ基盤がかなり安定化したので、所謂プロダクト戦略のお仕事に使える時間が増えましたね！この時期はデータエンジニアリングはあまりやってないです。

ミッションは、システム移管を乗り切る + プロダクト戦略を事業戦略と接合させ各チームへの支援

意識したこと

データエンジニアだけが苦しむ構造に抗う

データエンジニアが、新機能の利用をデータから見たい依頼者と新機能実装する開発者との板挟みになりやすい のは、構造上あるあるかと思います。

先述したModifiedAt無い問題にも関わりますが、新機能開発で利用状況をデータ基盤で可視化することになったが、プロダクト側のスキーマやテーブル設計だと機能の利用状況が取れないことが後々から発覚するパターンがたまにありました。システム要件時に、データ分析観点も出れば良いんですが必ずしもそうとは限らないので。そのあたりのしわ寄せが結局データエンジニアに集約してしまうのはなんか健全じゃないな〜と感じてました。チーム上司に色々相談しながら組織の力学を使って解決するように動き、プロダクト戦略室として開発フローに入り込んでデータ周りのレビューを自分がするような体制にしました。 人が頑張るのではなく仕組み化大事、仕組み化のために組織の力学を使うのも大事 です。レビューも自分のスタンスとしては、開発が始まる前に自分が把握してデータこれで取れるかな〜？という意見は言う程度で、基本アプリケーション都合のテーブル設計が最優先です。
フローに入り込むと、今度は小さなリファクタ系アイテムについても自分が把握しなきゃいけないんだっけ？みたいな新たな課題も出来てしまいまぁ〜難しいですね。自分が社内で誰が何の開発をやっているのかある程度知ってるので直接ヒアリングしたり、◯◯の開発をするってことは△△サービスに手を加えるってことは□□あたり影響ありそう！？みたいな見聞色が発動したり、アプリケーションエンジニアから積極的に教えてくれたり。今振り返ると結構ヒューマンパワーに頼ってた部分だったな〜。
1プロダクトのマイクロサービスとデータ基盤って実は相性悪いんじゃね？とかこの時期考えてましたね。

ビジネスプロセスに向き合う

システム移管完了後、ISSUEが結構溜まってきましてなんでこんなにつらいんだ？という気持ちになってました。
データモデリングの見直しの際「どうして◯◯という状態をデータで表現出来ない？」とか「△△のデータが作られるの、想定されてないケースだと聞いてたが月1ぐらいの頻度で作られるぞ？」みたいな疑問が挙がったので、真相を知るためにビジネス部門方面に聞き込みしてました。当時の売り方と今の売り方が違うがシステムのドメイン設計やデータ設計に反映されているわけではない（売り方はビジネス都合で変わりうるので、都度追従できない）ということがわかったり、「△△というフローは例外である」と思いきや実際は頻度の低い通常フローであることがわかったり。 例外という言葉は結構難しい言葉で、Exceptionなのか頻度が超低いだけなのか、全然意味が違ってきます。

dimensional modelingはビジネスプロセスの可視化なので、ビジネスプロセスがわからないとデータモデリングが適切に出来ないな〜 という学びでした。ビジネスプロセスに向き合った結果、ビジネスプロセスの変化をシステム側で吸収できない部分について、dbtのintermediate層を導入して解決した〜みたいなのをデータマネジメント新年会で話しましたね。自分たちの実装や設計を言語化する良い機会でした。

またこの時期ぐらいにlookerの実装をDWHに諸々寄せましたね！集計ロジックが増えてlookerのクエリが重くなったり、BIはビジュアライゼーションに特化してBigQueryに計算させたほうがよくね？みたいな理由でした。諸々経てデータ基盤はだいぶ安定していきましたね〜イケイケ！

属人化解消への種まき

パワーで頑張った結果、人依存のまま仕事が回っていると錯覚してしまったケースが割とあったので、人からチームへ、人力から仕組み化へ、というのを色々考えてました。

GoogleAnalytics周りは、個人に知見を集約せずチームに知見や業務を集約させるように意識した最初の取り組みですね。昔の自分だったら依頼を受けて自分がレビュー入って、実装やテストして、ドキュメントまとめて独走してたかもです。まずみんなでやってみよう触ってみようみたいな感じで最初は進めた感じですね。
もう1つはdbtのプロダクト側への逆輸入です。元々は負債解消文脈で提案してたんですが、データ基盤チームの一部しかdbt触れない状態を解消できたので結果的に属人化解消の種まきにもなりましたね。まさにプロダクトの集計機能をdbtに置き換えた話の記事でやったことまとめてるので、アプリケーションエンジニア方面にdbtをどう勧めたのか気になる方はぜひ。

悩んだこと

データの品質担保への悩み

品質周りで2点ほど悩みました。ざっくり書きます。
1点目はdbt testが肥大化してしまい、どこの品質を担保するべきか悩んだ所です。
元々dbtのgeneric testをゴリゴリに使っており基本全モデルに一通りのテストを実装したんですがdbtの実行時間が激増してしまいました。諸々考えた結果、 データの入口と出口の2箇所を集中する方針 にしましたね。入口(stg層)ではプロダクトのデータパターンが正しいこと(not null、unique等）を担保し、出口(mart層)では集計結果を担保するようにしました。例えば様々なdimensionをfactにleft joinする際にjoinのやり方ミスって重複レコードが生まれてないかチェックするために集計粒度単位でuniqueテストしたり。 レイヤーごとに担保すべき品質ラインをチームで決めた 感じですね。全部をテストするのは理想に見えるかもですが、テストの保守コストが上がっちゃうのでメリハリをつけるのが大事かな〜と。

2点目はデータ基盤のSLO的な概念を導入したほうが良いんじゃね？みたいな話です。
全てのデータが完全に正しいことを担保し続けたり、バグ発覚したら即日修正する動きって正しい動きだとは思いますが適切なリソースのかけ方なのだろうか？なので諸々相談して「バグ発覚から◯日以内に修正されていること」みたいなラインに落ち着きましたね。
そして過去のデータをどこまで担保するかも話題になりました。データ基盤誕生以降は我々が担保し、それ以前のデータはそこまで担保しないみたいなスタンスになったかな。もちろん、過去◯年前のデータが社内の分析であまり使われないことなどを確認した上での判断です。
これは各社データエンジニアの皆さんともよく話題になりますね〜。ぶっちゃけ全てのデータの品質を担保し続けるのはリソース的に難しいすもんね。特に データから得られる示唆って古いデータであればあるほど少なかったりするので、保守運用するコストに対するリターン（示唆）が薄い イメージです。直近5年間のデータの品質にフォーカスし、5年を超えたらデータのスタン落ちさせる、みたいな運用だとだいぶ楽になりそうだな〜という感覚です。

4年目

新設された事業企画チームにPMOとして参加。ビジネス部門へのデータ利活用をゴリゴリ推進したり、BIツール変更対応したり。後半は転職により1人エンジニアを卒業し、データチームの規模が大きめの新職場で新たなチャレンジへ。今回は1人データエンジニアの振り返り記事なので、ここの話はまたいつか話せれたら。一応、初転職のデータエンジニアが心がけた3つのことという社内ブログ書いたので、これも気になる方はぜｈ。

ミッションは、データを使ったビジネス部門の利活用推進。

意識したこと

データの利用者のことを知る

これまではプロダクト部でのデータ利活用がメインでしたが、ビジネスデータを統合してビジネス部門へのデータ利活用や指標作りなどにチャレンジです。ビジネス部門へのデータ利活用についてどうアクションすればいいんだろう〜みたいな話は結構聞きますし自分も試行錯誤してきました。2点だけ意識したことざっくりまとめます。

1点目は、各チームの目標やミッションを知ること。
雑すぎる例ですが「なんか困ってること無い？データ基盤でなんか出来ますよ」みたいなこと言われても「うーん」と反応されたり、事業的に重要度が低い悩みが出たりします。 チームのミッションを知り、現場メンバーの声や数値とかを把握した上で「◯◯のデータから△△したらxxxのアクションが出来たりしない？」みたいな仮説をぶつけに行く と、打率が上がるな〜というイメージ。

2点目は、部署の雰囲気を知ること。
物理的に座席近くで仕事することを意識しましたね。普段皆さんはどんな会話をしているのか、どんな画面をみているのか、雰囲気など。 業務フローを変えたり指標を一緒に考えるにあたり、このあたりのコンテキストを知るのって大事 だと思ってます。刺さらない施策を作っちゃうかもしれないので。超雑ですがslackやsalesforceを業務でずっと開きっぱだから、slack連携やsalesfoce連携って自分が想像する以上に超大事だしありがたいんだろうな〜みたいな。

悩んだこと

ビジネスデータの扱いと対応について

プロダクトデータと違って、ビジネスデータって結構カオスなんですよね。カオスなデータを取り込みつつ、今のデータ基盤が壊れないアーキテクチャを考えてました。
特にSalesforceのデータ取り込みが結構大変でした（これ各社みんな言ってますよねｗ）。自分は、必要なデータが多くなかったのとユースケースが限られていたので、最小工数でくぐり抜けました。Salesforceの欲しいデータをレポートとして作成、スプレッドシートに連携、BigQueryの外部テーブルにスプシ参照、スケジュールクエリで定期実行でレコードを実体化し履歴として残す、みたいなよくあるシンプルパターンすね。スプシを経由しているので闇の魔術だよな〜というモヤモヤがありましたが。

あとはデータエンジニア系のイベントで話題にでるのが「リアルタイム性」「マスターデータ」とかですかね。自分はリアルタイムの要件がなかったので一切考えなかったのですが 先程の「例外」という言葉と同じで「リアルタイム」という言葉を、所謂リアルタイムなのか、早ければ早いほど良いなのかで全然意味違ってきます からね〜。個人的には「リアルタイム性」が必要なケースほぼないと思ってます。
マスターデータ系の悩みであるあるは、社内の人事データ（組織とか役職とか名前とかそういうの）って、社内スプシ、人事系Saas等色んなところに散らばってるんですよね。各所に散らばってるマスターデータは、そのマスターデータを扱う人が必要なもののみを扱ってるので仕方ないっすよね〜。じゃこれを解消するためには組織の力学的なことを使うしか無く、雑なたとえですが「データ基盤や社内分析のために、これを社内人事データのSSoTとしましょう！データ分析時にエラーでちゃうから、きちんとメンテしてください」みたいなミッションを与える、ぐらいのことをしないと実現出来ないんだろうな〜という肌感はあります。

まとめ

たった4年ですが、改めて振り返ってみるこんなにたくさんの経験や学びがありました。長々と書いてしまったんですが、まとめると以下3つかな。

• 1人で切り開くんだ〜と考えない！周りの仲間の協力が必要で時には組織の力学を頼る必要もある。周りも巻き込むためには事業や組織、人を知ることが大事！
• データ基盤はただの手段である。会社・組織の課題と目的、つまりAs is To Beの整理が超大事！
• 職務領域が広くてやることが七変化してる、まさに総合格闘技！データエンジニアは超楽しいぞ！お前もデータエンジニアにならないか？

今でも自分は試行錯誤し続けているので、皆さんの悩みやチャレンジしていることを是非ツイッターやdatatech-jpのコミュニティ等で話してほしいな〜！
以上です！ありがとうございました〜。