最近『データエンジニアリングの基礎』という本を読み始めた。
この本の冒頭で、データエンジニアリングやデータエンジニアの定義は曖昧で、人によって言っていることがバラバラだという話が出てくる。そこで著者たちは自分たちなりの定義を示し、それに則ってデータエンジニアリングの全体像を解説することを試みている。
「データエンジニアリング」が指すものが定まっていない、というのは自分も日々実感している。指すもの、イメージするものが、人や組織によって違いすぎる。
単に言葉の定義の問題ではなく、「データエンジニア」と称される人が実際に何をやっているのかは、組織によって本当にバラバラだと思う。
そんな状態なので、各組織の各データエンジニアが何をしているのか外からはよく分からないだろうし、データエンジニアが何に面白さを感じているのかも世間に伝わりづらいと思う。
この記事では、私が HERP のデータエンジニアとして働く中で感じる面白さについて書いてみる。
あくまでも、私の話だ。2025 年 2 月に HERP で働いている私の話を書く。一般論のようなものは書かない。多くのデータエンジニアに当てはまる最大公約数のような話も書かない。
そして、「面白さ」以外の話はしない。重要性とか、意義深さとか、何をやるべきかとか、何をやらなきゃいけないとか、そういう話はしない。なぜならこれは「面白さ」を語るために書いた記事だから。
＊＊＊
最近は Dataproc クラスタで dbt Python model で動かそうとしているけど、これはけっこう面白い。
新しいことを学べるから。
最初にこの問題に着手したのは確か去年の 4 月頃だったと思う。その後、優先順位等の問題で自分のリソースを他のことに使っており、最近再び着手し始めた。最初に dbt の公式ドキュメントを読んだときは、さっぱり分からなかった。Dataproc も PySpark も聞いたことがなかったから、「何の話をしているのか」を掴むことすら難しかった。そもそも Google Cloud に対する理解が今以上に浅かった。とはいえやるしかないのでひとつずつ調べ、実際に動かし、理解が深まっていった。こういうのは面白い。
学ぶことは業務でなくてもできるが、業務の場合、課題や機会が自分の外からやってくるのがよい。独学の場合、「知らないと知っていること」以外を学ぶのは難しい。業務では、現時点での自分の知識やこれまでの歩みとは無関係に「お題」がやってくるのがよい。
そして、知識を使う機会があるのも、業務のよいところである。知ったこと、学んだことを使って物事を達成するのは、面白い。
Dataproc クラスタで dbt Python model で動かそうとしているが、色々とエラーが出てくる。エラーログを睨みながら、状況を把握し、推論し、仮説を立て、前に進んでいく。
解決するのも楽しいが、「自分はちゃんと理解できている」という実感を得られるところもよい。Google Cloud について以前よりも理解できている、と感じられる。既存の実装からコピペしたコード、生成 AI に示されたコードを試したら何か知らないけど動きました、ではなく、ちゃんと分かっている。なぜこの問題が起き、そのためにどのように対応が必要か理解し、必要な手を打ち、意図した通りに動いた。そういう経験は満足感を与えてくれる。
エラーログといえば、毎日実行している dbt のログのモニタリングも修正した。エラーを吐いてもそれが Datadog 上でエラーログと認識されていなかったので、修正した。
大した修正でもないのだが、この件の調査や対応で Status Remapper など Datadog に関する新しい知識を得られたので、楽しかった。
そしてこのとき Datadog の知識を得ていたことで、後日 dbt 側の設定変更に伴い Datadog の設定も変える必要が生まれた際、スムーズに対応できた。何をやればよいかすぐに見当がついた。
習得しておいた知識を使って物事を解決するのは面白い。
データプラットフォームの可観測性にはまだ伸びしろが多いので軽く調べてみたところ、どうやら Elementary というものがよいらしいと知った。
HERP ではモニタリングツールとして以前から Datadog を使っており、既存の仕組みに乗っかったほうが早いという判断でデータパイプラインでも Datadog を使ってモニタリングしているが、いずれは Elementary を導入するとよいかもしれない。
こんな感じで調査系のタスクは色々と学びがあるが、同僚に教えてもらえることもある。HERP のデータチームには、自分たちより経験が豊富な業務委託の方が複数在籍しているが、その方々から学べることは多い。例えば最近 SDF が dbt Labs に買収されたが、このニュースも業務委託の方に教えてもらった。自分はそもそも SDF を聞いたことがなかったので、SDF について軽く調べてみるキッカケになり、面白かった。
データチーム外の同僚から学ぶことも多々ある。
BigQuery Data Transfer Service が転送元として MySQL や PostgreSQL を指定できるようになったのだが、これを最初に知ったのも社内 Slack の投稿だった。
それから、同僚のひとりが自主的に Google Cloud の Colaboratory を素振りしてその結果を共有していた。自分は Colaboratory というサービスの存在自体を知らなかったが、この共有をキッカケに自分の環境で軽く触ってみて「こういうのがあるのか」と学ぶことができた。
ここまで書いてきたように、新しいことを学ぶ機会と実践する機会がある、というのが業務のよいところだが、さらにそれとは別に「動作しているコードが既にあるため、それを読むことで学習効率が高まる」という利点もある。
以前 Kubernetes での機密情報の管理について把握する必要があったのだが、その際に、インフラの面倒を見ているチームの同僚から「これ読んでおいて」とドキュメントを渡された。これ自体が分かりやすいものだったが、実際にこの機能が使われているコードが既に社内に存在するため、それを読むことでよりスムーズに理解できた。
そして、既に動作しているコードがあると、実践がしやすい。数行コードを変更することで改善できたりする。先程のドキュメントを読んでいて、「この設定は便利そうだけど使ってないな」というものがあったので、Pull Request を出して導入した。結果、オペレーションや運用が少しだけ効率化した。微々たる改善だが、こういった創意工夫を行っていくのは創造的であり、面白い。
創意工夫を行う対象はコードとは限らない。業務プロセスを改善する機会もある。
以前、データ関連のとある業務で異常系が発生したときの通知周りについて、改善した。それまでは自分が通知を見て担当者に状況を伝えていたが「これムダでは？」と気付き、担当者が直接通知を受け取るような形にした。
合わせて、「この通知は何なのか、どういう問題が起きているのか、どう対応すればいいのか」をドキュメントに書き、通知の文言にそのドキュメントへのリンクを含めた。
テキストを書くのは元々好きなのだが、年始に『GitLabに学ぶ 世界最先端のリモート組織のつくりかた』を読み、非同期業務やそのための中心的な手段であるドキュメンテーションに対して気持ちが高まっている。以前からある程度ドキュメントを書いたが、より意識的に、ドキュメントを残していこうと思っている。
先程の業務プロセスの改善もそうなのだが、非開発者（に限らないが）に何かを伝える機会、知ってもらう機会がそれなりにある。そうした「共有しているコンテキストが乏しい相手に、いかに必要なことをわかりやすく伝えるか」はチャレンジングであり、面白い。自分なりに分かりやすく説明したつもりでも、そもそもの前提知識が異なっており上手く伝わらないことがある。フィードバックや質問をもらって「確かにここから説明しないと何のことだか分からないな」と気付き、それを説明するためのドキュメントをまた書く。
大前提としてそれが事業や組織にとって有益だから、ドキュメンテーションを上手くやらないと組織がスケールしないと考えるからやっているのだが、それは単に有益であるだけでく、自分にとって面白いことでもある。
ドキュメンテーションが典型的だが、自分は「積み上げていくもの」が好きである。面白さを感じる。
データ活用周りで、とある依頼を受けた。急ぎではないとのことだったので、依頼者のロール等も踏まえ、依頼者自身が依頼内容に挑戦してみるのはどうかと提案した。快諾してもらえたので、必要な手続きを案内したり、ドキュメントを書いたりした。
こういった動きは、状況や環境への働きかけ、投資であり、ただタスクをこなすのとは違う。残るものがある。積み上がるものがある。積み上げていくことで、よりよい状態へと向かっていく。
タスクを自分以外の人間でも解決できるようにしたり、タスク解消のために必要な作業量を減らしたり、そもそもタスクが発生しないようにしたりしていく。そういったことは、とても創造性のある行為だと思う。
降ってくるタスクをひたすら片付けるのは好きではない。タスクに追いかけられているし、振り回されている。そうではなく、こちらから意思を持って投資を仕掛けていきたい。主体性を持って臨み、創造性を発揮していきたい。
学習においても、「積み上がるもの」を学んでいきたい。
ライブラリのメジャーバージョンアップの Breaking Change の内容を調べるのとかは、好きじゃない。積み上がる感じがしないから。やらざるを得ないからやるし、学びだってあるけど、基本的には面白くはない。
ただこれは、認識の問題である。自分がどう認識するのかに過ぎない。Breaking Change の調査に面白さを感じる人だって当然いるだろう。
先程のタスクの話もそう。個々のタスクを片付けることによって生まれるもの、積み上がるものが、存在しないわけではない。
だから面白いかどうかという観点で大切なのは、実際に積み上がっているかどうかではない。積み上げているという感覚を抱けるかどうかだ。
ドキュメントで誰かに何かを伝えるときは、知ってもらいたい対象そのものだけでなく、その背景や前提も伝え、読み手が脳内に全体像やメンタルモデルを構築できるようにするのが望ましい。
データ周りについて何を学習するとよさそうか、という会話を非開発者の一人としたことがあるが、そのときも、「自社のデータプラットフォームの仕組みや構造を学んでもらうのがよいと思う」と伝えた。SQL や各種ツールについて学んでもらうのも勿論よいのだが、システムの概要を最初に理解してもらったほうが費用対効果がよい。相手からも「システムの仕組みに対する理解を深めることで、障害対応などの際により自信を持って交通整理できるようになると思う」と同意してもらえた。もちろん説明する側の工夫も大切ではあるが、それとは別に、聞き手側のなかでメンタルモデルが構築されていれば、自身である程度、推論できるようになる。前提を押さえておくことで、相手が専門的な話をしていても行間や前提を読み取って論旨を掴めるケースが増える。質問をするにしても、自分が何を理解できておらずまずは何を知るべきなのか、認識できるようになる。それは単に「障害対応が上手くなる」というだけの話ではなく、自分が直面している課題をより主体的に解決できるようになるということだ。
このように「全体像を掴むことで理解やコミュニケーションがスムーズになる」と考えており、全体像やメンタルモデルを構築してもらえるようなドキュメントを作るのは意欲的かつ創造的であり、面白い。
ただそれだけではなく、そもそも私自身が、「全体を知りたい」という欲求を持っている。要素と要素がどのようにつながって全体を形作っているのか、どのような機序によって全体がひとつの機構として成立しているのか、ということを知りたいという欲求がある。そしてそれを知っていくことは、面白い。
既に少し触れたがデータチームではいわゆる「インフラ」を触る機会がそれなりに存在し、それは「全体」を知ることに役立っていると感じている。
ウェブアプリケーション全体を理解するためには、それがどのように提供され動いているのかも知る必要があり、そのためにはインフラを理解しなければならない。そうしないと DevOps を実践していくのは難しいと思う。断片的な情報や一般論は調べれば出てくるが、それを目の前の状況、今自分が置かれている状況に適用させるためには、全体を掴んでいないと難しいと思う。
データエンジニアリングをやることはインフラを学ぶことにつながるのでは、という期待を持っていたが、その通りだった。自分が知りたいこと、学びたいことを学んでいくのは、当然面白い。
先程、全体像を掴みメンタルモデルを構築できると「自分が直面している課題をより主体的に解決できる」と書いたが、全体を理解することだけでなく、そのような問題解決そのものも、面白い。
全体を知り、その知識や理解を活用して物事を判断し意思決定していくことには、楽しさがある。
最初に触れた Python model にしても、単に機能を実装するのではなく、既に稼働しているシステムを壊さずに変更するにはどうすればいいのか、どう進めると小さくインクリメンタルに変更や学習を実施していけるのかを考え実践していくのは、面白い。
今日現在の HERP のデータプラットフォームは、全体像を掴みながらの開発や運用を行いやすいと感じている。ただ目の前のことだけをやっているのではなく、全体のなかの一部に取り組んでいるのだという感覚を比較的持ちやすい。
まだ歴史が浅く規模が大きくなく複雑性も低いから、だとは思うが、よくも悪くも分業が進んでいないということも関係しているかもしれない。
もちろんこれもまた、「どう認識するか」という話に過ぎない。データプラットフォームだって HERP のシステム全体の一部であるし、巨大で複数の機能を持ったアプリケーションからひとつの「全体」を取り出すことだって出来るのかもしれない。あくまでも私にとって今のデータプラットフォームはひとつの全体として切り出しやすい、そのように認識しやすい、という話だ。
全体を把握しそして意思決定をしていく、というのは会社からのオーダーともある程度重なり合う。
より高いレベルの意思決定をしていくようにして欲しいというオーダーをもらっているが、そのためにはできるだけ広い範囲を見る必要がある。
当面は、よりよいデータプラットフォームやデータ組織とはどういうものかを考え、絵を描き、どのようにそれを実現していくのか考え、優先順位をつけて実行していくことになると思う。
目の前の事業上のニーズに応えることを優先した結果、今のデータプラットフォームはお世辞にも整っていて使いやすいとは言い難い状態になっている。そのトレードオフとしてスピードを手に入れたから仕方ないのだが、例えば、dbt の model や各種クエリが整理されておらず、混沌としており、生産性が落ちてしまっている。他にも課題が山積している。
少し前に、データ業務で使っているとある SaaS の権限について考え実践する機会があった。既存のルールを惰性で踏襲するのではなく、その時のニーズに合わせて適切な設定の組み合わせを考え付与した。こういうのは面白いし、創造的だと思う。
これは本当に小さな内容なので、より大きく、広く、やっていかないといけない。
様々なニーズや守るべき制約があるなかで、適切なデータプラットフォームはどのようなものかを考え、作っていく。これはそれなりに面白そうに思える。
＊＊＊
こうしてみると、全体を見る、何かを創造する、創意工夫の余地が大きい、新しいことを知る、知ったことを活かす、技術を使って物事を実現する、戦略や方針を考え意思決定する、文章を書く、あたりに自分の関心があるらしい。
そう、ここまで書いてきたのは、データエンジニアリングの話ではなく、私が何に面白さを感じるかの話。
データチームに属する自分が何に対してどのような面白さを見出しているか、ということを書いてきた。
というか、そういう風にしか書けない気もする。ある仕事の万人にとっての面白さ、というものは存在しない。
何度か「認識」の話をしてきたが、「面白さ」もそうで、何に対してどのような面白さを感じるかは人によって異なる。それぞれに異なる傾向や感性を持っているし、それは絶えず変化していく。それまで自覚していなかった傾向に気付くこともある。
「好き」「楽しい」「面白い」という want to こそが情熱を生み、人を駆動させる。外発的動機よりも内発的動機のほうが持続性が強いことは広く知られている。
だから、自分の want to は何なのかを自覚し、リフレーミングなどを使ってそれを業務と結びつける能力は、とても重要になる。事業や組織としての戦略や方向性、生み出したい成果、といったものがあるなかで、どうやって want to と業務の結節点を見つけ出すか。
そして、自分の want to と親和性の高い環境や業務というものも当然ある。何かが満たされたことで違う何かを求めるようになることもある。
この記事を読んで HERP のデータプラットフォームの開発や運用に want to との結節点を見出せるかもしれないと感じた方はぜひご応募ください。
