最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。
前提
まとめてみるとはいっても、約5年3社の経験なのでどんなデータエンジニアにも合うかは知らないし、そのつもりで書く気もない。あくまで自分の経験の範疇のことについて書く。どの会社でも割とIC(Individual Contributor)的な立ち回りや役割をしていた。
- はてな:
- データ基盤をほぼ0から構築
- 利用人数は10人行かないくらいの小規模なもの。CREやプロダクトオーナー、プロダクトマネージャーが主に利用
- 詳細: 「今日から始めるデータ活用」というタイトルでオープンセミナー岡山に登壇します - yasuhisa's blog
- Monotaro:
- すでに十年以上データ基盤が運用されているフェイズから参加
- 社内で数百人がデータ基盤を利用しており、マーケティング / 物流 / SCMなどデータ基盤を使っていない部門を探すのが難しいくらいデータ基盤が利用されている
- データ基盤に関わるコストも大きい、所属していたデータ基盤チームは4~5人の規模、マーケティング専門のデータ関連のチームも複数存在した
- 10X:
- 数十人の社員がデータ基盤を日常的に利用
- アナリストだけでなく、BizDevやPdMなど複数の職種の人がデータ基盤を利用する
- データ基盤専任で関わるメンバーとしては3~4人
どこでも必要とされたスキル
データマネジメントに関する概要レベルの知識と実行力
データエンジニアになるための準備ができてからデータエンジニアをやろうとすると、範囲が膨大なためこれは現実的ではない。走りながら勉強していく必要がある。そのため、全体領域がどういうなっているのか、それぞれの分野で自社がどういう状況に置かれていて、何をやっていく必要があるのかを荒くでもいいので把握しておくとちょっとだけ安心して走れるし、マネージャーなど他職種に自分の仕事の概形や必要性を伝えるのに役に立つと思う。
本当に広い分野だし、広く浅く触りながら必要なところを掘っていくスタイルがいいと思う。
セキュリティや法令に関する知識
データエンジニアであれば、データセキュリティは考えないといけない場面が多いと思う。ガバナンスという観点で誰に何を見せていいのかといった権限整備であったり、法令で求められることを法務担当と話したり、データ分析以外のデータがどうなっているかをコーポレート担当と話したり、データセキュリティに対する課題感をセキュリティチームと協力しながら進めていく、などが具体では必要になることが多かった。
セキュリティや法令も広くて深い分野なので、大まかな知識は市販されているテキストをがっと読み込んで、必要に応じてそれぞれの専門家に相談できる知識を頭の中に持っておけるとよいと思う(むしろ自分だけの判断で決めるほうが危ないことも多いので)。
事業ドメインに関する興味関心
データエンジニアの仕事をやっていると、そもそもデータの仕様が分からないとか、このログはどこで発火するのか、などで困ることが少なくない。こういう時に自分を救ってくれるのはドメイン知識であることが多い。自社サービスを自分でとにかく触ってみる、現場に行ってみる、ユーザーに近い人に話を聞くなどはドメイン知識を得るための絶好の機会だ。ドメイン的な制約により分析が楽になることもあるし、得られたドメイン知識はメタデータなどに記入しておくなど、今後のデータ基盤に役立てていく動きも自分を助けてくれる。
C向けでなくB向けの場合、特に医療とか法律ドメインでは自分がユーザーになるのは難しいこともあるだろうが、興味関心を持てる分野でそもそも働くほうがいいと思うし、そのほうが楽しいと思う。逆にこういうことに興味がない場合、事業会社でのデータエンジニアはやっていても面白さを感じないかもしれないので、向き不向きがあると思う。
他職種とのコミュニケーション能力
これはデータエンジニアに限らずよく言われるやつだとは思う。
BizDevやPdMなどの職種の人とコミュニケーションする場合、言われたままにクエリやダッシュボードを作っていくのではなく「そもそも解決したい課題や得たいインサイトって何でしたっけ?」あたりから押さえにいくヒアリング能力は必須。使われなさそう / 他で代替できそう / 別に今でなくてもよさそうなどの場合、依頼を断わることも覚える必要がある。また、データエンジニアに都度依頼がくると大変なのはどこでもそうだったので、彼ら/彼女ら自身が問題解決をできるようにDWHで使いやすいテーブルを提供していく、などEnablingのスキルも中長期的には必要になることが多い。
開発チームとのやり取りも結構必要になることが多い。必要なデータがなければログを出してもらうように依頼したり、仕様が不明確なものをヒアリングしにいったり。開発チームも暇じゃないので、ちょっとしたことであれば自分でコードを読みに行ったり、Pull Requestをさっと送る、くらいの力があるとスムーズに仕事を進めやすい。
コスト管理 / コスト削減のスキル
これはどの会社でもやってたし、大体半年から一年に一回コスト削減のタスクが動いている印象がある。SaaSを使うことでデータ基盤を構築 / 運用すること自体は10年前と比べると飛躍的にやりやすくなっているが、何も考えないでやっているとモリモリ増えていくのがコスト。
データエンジニアは他にもやるべきことがあるので、闇雲にコスト削減をやっても埒があかない。INFORMATION_SCHEMAなどのメタデータを駆使して、どこにコストがかかっているか / ボトルネックになっているか、その上でエンジニアリングの知見も生かしながら改善のコスパはどれからやっていくのがいいかを見極めていく必要がある。入社したらまずコスト管理を抑える、くらいのノリでやって損をすることはほとんどないであろう。
データエンジニアで気を付けておくべきコストとしてはクエリを回すためのコンピューティングコストとストレージコストが大まかな二大巨頭になると思う。ただ、ストレージコストは最近本当に安くなってきているので、特に管理や削減が求められるのはコンピューティングコストについてが多いかなと思う。
ソフトウェアエンジニアとしてのスキル
Managed SaaSができて「ノーコードでデータ基盤も運用できます」みたいなことは理想*1ではあるが、まあソフトウェアエンジニアリングのスキルはデータエンジニアであっても必要とされる。というか、データエンジニアである前に、それなりのソフトウェアエンジニアである必要がある。
SaaSが便利といっても、SaaSとSaaSを繋ぐ隙間家具的なスクリプトや小さいツールを書くことは非常に多いし、SaaSが提供してくれるまで自分たちで何とか凌ぐ必要がある場面は結構多い。そういう場面はソフトウェアエンジニアとしてのスキルのあるなしでケイパビリティが大きく変わってくる。
様々なデータソースを扱う中でどういう抽象化を挟むと扱いやすくなるのか、データユーザーにはどういったインターフェイスを提供するのか(privateな関数やフィールドにして隠蔽するのか)、関連するデータパイプラインのスキーマ管理やそれを壊れにくく/壊れたことをどうやったら検知できるのか、といったあたりはソフトウェアエンジニアとしての能力が必要になるところだと思う。
DataOpsやアラートのハンドリング能力
データパイプラインが最初から全部自動化されていて、データの問題も全くない、なんてことはありえないと思っておいたほうがいい。
最初はPoCで手動(スプレッドシートに手で入力、SaaSから不定期にcsvを手動でimportなど)からやってみましょう、と始まるのがデータ界隈だとよくある。それ自体はよくある話だが、運用負荷や活用状況ががどのくらいになってきたらDataOpsの自動化をしていくか考える必要が出てくる。オーバーエンジニアリングはし過ぎない程度に、とはいえ求められる品質は満たせるようにバランス感覚が求められる。データエンジニアは面倒を見ないといけないバッチやスクリプトも多くなりがちなので、CI/CDの自動化なども早めにやっておくのがよい。
アラート対応にも慣れておく必要がある。どれくらい急ぎで見る必要があるアラートなのかを判断できるようにそもそもしておいたり、アラートが鳴ったときにやるべきオペレーションが分かるようにしておく必要がある。どれくらいの頻度でアラートがくるのであれば恒久対応をする必要があるのかを判断できることも必要だし、大きめな障害であれば、関係チームを巻き込んで対応できる力も必要である(特にデータ提供とデータ活用に距離がある場合には、それぞれの言葉を翻訳する必要なども出てくる)。
分析用のSQLを書く力
データエンジニアは特にSQLを書く時間が長いと思う。この5年で一番書いたコードはsql / yaml / bash / pythonの順番で多いような気がする。pythonも100~200行程度のスクリプトで済む場合がかなり多い。データエンジニアがSQLを書く場面を上げてみると
- アドホックな集計
- クエリを書くことよりも依頼されたクエリを読み解くほうが多いかもしれない
- DWHやデータマートの構築
- モノができればいい、というクエリではなく品質高くテストできるように設計する力
- データオペレーションなどで必要なメタデータを集計する場面
などがあると思う。Webアプリケーションで書くようなクエリと分析用のクエリは考え方やメンタルモデルが結構違うので慣れるまでは大変ではあるが、三ヶ月から半年くらい書きまくってれば嫌でも慣れてくるし、慣れておけば今後10年くらいまだまだ食っていけそうなスキルであるため、押さえておいて損はない。というか、書けないと仕事にならない。
古いテーブルやデータパイプラインを置き換えていくスキルや胆力
データ基盤を提供していると、DWHやデータパイプラインが複数存在してしまっていることは珍しくない。新しい基盤を作りながら古い基盤をメンテナンスしていくのは本当に大変だし、キツいし、辛いし、楽しくない。とはいえ、こうしたものは意識しないと撤退が難しいものではあるので、関連部署と連携を取りつつ歯を食いしばりながら、時には障害を起こしたりすることもあるかもしれないが、お尻を決めて頑張って撤退していく力が必要になることが多い。データエンジニアとしての力はもちろんそうだが、根性や筋力や胆力が最も必要な部類の仕事かもしれない。これがきちんとできる人は同僚のデータエンジニアから信頼させると思う。
あるとやりやすいスキル
関連部署の動きを何となく把握しておく力
データに関する課題は色々決まってからだと調整が難しいことも多い。「もっと早く呼んでくれれば、お互いもっと楽になったのに...」と感じることも経験的には多い。
そういったことを避けるためには、関連する部署の情報をそれとなく知っておくことができると便利。Slackでよく流れてくるキーワードや発言者を見ているとキーマンが誰なのか見えてくるし、他の部門の目標や進捗管理のNotionページなどを見ているとそろそろ出てきそうな依頼や相談事が前倒しで分かったりする。
情報収集ばっかりやっていても仕方ないが、ローコストにこの辺を収集できる術や癖が付いていると、データエンジニアとしてはやりやすくなるように思う。エンジニアの仕事の数割はシステム考古学であるという説を信じている。
自分はデータエンジニアをやり始めてからほぼフルリモートなので、これらのことはオフラインでの会話が必須かと言われるとNoの立場ではあるが、相談してもらいやすくする雰囲気作りなどはオンラインであっても重要。
id:onkさんほどはやってないけど、似たようなことをやっている。情報ジャンキーなだけかもしれない。
属人化を避けるスキル
これは会社やチームの文化によるところが大きいかもしれない。Web開発をスプリントで回す場合、タスクは誰でも取れるようになっていることが望まれることが多いように思うし、そうなってない場合は後々属人化を剥ぎ取れるようにしていくことが望まれるケースが多い。
自分が所属していたデータエンジニアのチームは少人数2~3人、場合によっては一人ということもあったので、Web開発と比較すると属人化を許容している場面がかなり多かった。とはいえ、自分が休みのときや引き継ぎなども当然出てくるわけで、そういった場合に大変になり過ぎない程度には属人化を避けられるようなドキュメンテーション能力やチーム運営の能力があるとよい。
コンピュータサイエンスの知識
ここも事業内容などに寄りそう。そもそもデータよりのSaaSを作っている会社やリアルタイム / 大規模データ処理をやる必要があるデータエンジニアであれば、コンピュータサイエンスの知識は必須になることが多いだろう。とはいえ、事業会社のデータエンジニアだとこの知識がしょっちゅう必要になるかというと、現実的にはそうではないかなという肌感。年に1~2回くらいこういうのを発揮させると解決する問題が出てくることがあって、それを自分で実装できるとかなり綺麗にできてめでたい、という感じ。
日頃から競技プログラミングコンテストをやっているわけではないので、書籍やWebで調べてみたり、識者にポインタを教えてもらって、それらが自分で実装できるとなおよいですね、というくらいの気持ちで暮らしている。
メタデータを使い倒すスキル
前述したように、データエンジニアはやるべきことが多いので、優先順位を付けていくためにもデータ基盤全体を包括的に見る必要がある。こうした場合、一個一個のテーブルを見ていってもラチがあかないので、メタデータをゴリゴリと使い倒して作戦を考えたり、日常のオペレーションを簡単にしたり、といったことができると生産性をぐっと上げることができる。
Modern Data Stackの知識
Modern Data Stackを使うと、自分たちで実装すべきことが札束で解決できることもあるので、この辺の領域の知識があるに越したことはないが、優先度としては高くない。
データエンジニアリング関連のコンサルをやっているのであれば優先的に押さえておくといいかもしれないが、事業会社でデータエンジニアをやっているのであれば、アーリーアダプターに必ずしもなる必要はない。イケてる感に惑わされて、社内や事業に価値を提供できているかは常に考えよう。
所感
10年後もデータエンジニアをやっているかがそもそも謎だけど、5年か10年後くらいに必要になっているスキルと比べてみると面白そうですね。
*1:自分はこれも理想ではないと思ってるけど
