(翻訳) データエンジニアの没落
訳者まえがき
下記の翻訳記事と対になる、データエンジニアの役割についての記事を翻訳しました。
オリジナルの記事は下記のリンク先のもので、原著者は上記記事と同様に、Apache Airflow や Apache Superset のクリエーターで現在は Lyft で Data Engineer をしている Maxime Beauchemin です。
以下から、翻訳記事の内容です。
データエンジニアの没落（翻訳）
この記事では、データエンジニアリングを定義しようとした最近のブログ記事である「The Rise of the Data Engineer」（訳者注: 拙訳「データエンジニアの始まり」）をフォローアップし、この新しい役割がデータ空間において歴史的、現代的な役割にどのように関係しているかを説明します。 この記事では、データエンジニアを悩ませる課題とリスクを明らかにし、思春期を過ぎるに際しこの学問分野に対抗して働く力を列挙したいと考えています。
この記事のタイトルはセンセーショナルで、内容は非常に悲観的ですが、私はデータエンジニアリングを強く信じていることに留意してください。前の記事と対比的な強いタイトルが必要でした。その役割が直面している逆境を理解し明らかにすることは、解決策を見出すための第一歩です。
また、ここに記す意見は私自身のものであり、シリコンバレーの数十のデータチームの人々と会話をしながら観察した結果に基づいています。これらの見解は私の雇用主の見解ではなく、現在の私の立場に直接関係しています。
退屈 ＆ コンテキストの切り替え
ペンキが乾くのを見ることは、Extract Transform and Load（ETL）ロジックを記述して維持することと比べ、エキサイティングです。ほとんどのETLジョブは実行に長い時間がかかり、エラーまたは問題は実行時に発生する傾向があり、実行後のアサーションとなりがちです。開発時間と実行時間の比率は通常低いため、高い生産性を保つことは複数のパイプラインを同時に処理することを意味し、本質的に多くのコンテキストの切り替えを実行することを意味します。あなたの5つの 「ビッグデータジョブ」のうちの1つが終了する頃には、何時間も前の精神空間に戻り、次のイテレーションを作り上げる必要があります。どのようにカフェインを摂取しているか、最後のイテレーションからどれぐらいの時間が経過しているか、あなたがどのくらい計画的かに依存しますが、短期記憶の中の完全なコンテキストを取り戻すことはできないでしょう。これは時間を無駄にする全体的で愚かなエラーにつながります。
イテレーションサイクルごとの待機時間を1時間ごとにカウントすることにより、「皿回し」状態を維持することに取り憑かれてしまいます。午後11時30分の5-10分の仕事により翌日の2-4時間が節約できる場合、不健全なワークライフバランスになりがちです。
コンセンサスの追求
旧来のデータウェアハウジングの概念が消えつつあるとあなた考えているかどうかにかかわらず、対応付けられたディメンションとメトリックを達成することの追求は、それまで通り関連があります。私たちの多くは、人々が依然として一日おきに「Single Source of Truth（信頼できる唯一の情報源）」と言っているのを聞いています。データウェアハウスはビジネスを反映する必要があり、ビジネスの分析方法を明確にする必要があります。異なる名前空間または「データマート」にわたる矛盾した命名法と矛盾したデータは問題となります。意思決定を支援するために信頼を構築したい場合は、一貫性と整合性が最低限必要です。現代の大規模な組織では分析プロセスにおけるデータ生成に何百人もの人々が関与していますが、コンセンサスの追求は、直ちに不可能ではないにしろチャレンジングなものです。
歴史的に、さまざまなプラットフォームに散在する不均一な分析や一致しない参照用データに関する問題を名付けるために、人々は「データサイロ」という蔑称を使用しました。サイロはプロジェクトの開始に伴って自然に生まれ、データの取得が発生する際に必然的にチームは混乱します。Master Data Management（MDM）、データ統合、野心的なデータウェアハウジングプログラムなどのコンセンサスを取り付けるための方法論を使用し、これらの問題を解決することがビジネスインテリジェンス（現在のデータエンジニアリング）チームのタスクです。近年、現代の変化のペースが早い企業において、サイロの問題は急速に拡大しています。そこでは、「ダークマター」という用語を使用して、起こっている混乱の拡大の結果を表現することができます。適任ではない人々の集団がことを始めると、パイプラインのネットワークはすぐに混沌とし、調和のない無駄なものとなる可能性があります。データエンジニアが「データウェアハウスの図書館員」だとしたら、彼らの使命は巨大なリサイクルプラントでの出版物の分類作業のようだと感じるかもしれません。
ダッシュボードのライフサイクルが数週間ごとに数えられるような世界では、コンセンサスは、ビジネスの変化率や転換に追いつかないバックグラウンドのプロセスになります。伝統主義者はデータ・スチュワードシップとオーナーシップ・プログラムの開始を提案していますが、一定の規模とペースにおいては、こうした努力は拡大には見合わない弱い勢力となっています。
変更管理
有用なデータセットが広く使用され、大規模かつ複雑な依存性の有向非循環グラフ（DAG）を使用した方法で生み出されるようになると、ロジックもしくはソースデータを変更により下流の構造を破壊および/または無効にしがちです。上流の変更を反映するために、派生データセット、レポート、ダッシュボード、サービスおよび機械学習モデルのような下流のノードは変更および/または再計算が必要です。一般にデータ系統に関するメタデータは、通常は不完全であるかコード中に埋め込まれており、選ばれし少数の人々のみが読むための能力と忍耐力を有しています。上流の変更は必然的に、下流のエンティティを複雑な方法で破壊し無効にします。組織がどの程度精度よりも安定性を評価するかによっては、変化は恐ろしいもので、パイプラインの便秘につながる可能性があります。データエンジニアのインセンティブが安定性と連動している場合、彼らは、何も壊さない最良の方法は何も変えないことである、と速やかに学ぶでしょうです。
パイプラインは一般的に大規模で高価なため、適切なユニットテストや統合テストの実施は多少なりとも比例的である可能性があります。ここでの要点は、サンプリングされたデータとドライランで検証できるのはごくわずかというです。そして、あなたが扱えないほど単一の環境が混乱していると思ったら、複雑で異なるコードとデータを使用する開発環境とステージング環境を捨てやったとしても、正常な状態にしてください！私の経験上、大規模データの世界では、まともな開発環境やテスト環境を見つけるのはまれです。多くの場合、あなたが見つけられる最高のものは、文書化されていなくとも人々が適切であるとするプロセスをサポートするために使用する、名前空間の「サンドボックス」です。
データエンジニアリングでは、「DevOpsのムーブメント」についてのボートを見逃してしまい、現代のエンジニアに提供される心の平安と平穏の恩恵を受けることはめったにありません。彼らは姿を表さなかったのでボートを逃したのではなく、貨物のためのチケットが高価すぎたのでボートを逃したのです。
テーブルの最悪の座席
現代のチームの動きは速いですが、組織がエンジニアリング駆動、PM駆動、デザイン駆動のいずれであっても、そしてデータ駆動型であると考えているかどうかに関わらず、データエンジニアはそれほど駆り立てられないでしょう。インフラストラクチャーの役割と考えるべきです。その役割は、人々が当然のことを考えるものであり、壊れているときや約束が満たされていないときに注意を集めるものです。
会話に参加しているデータエンジニアがいる場合は、おそらくデータサイエンティストとアナリストが必要としているデータを収集するのを手助けします。対象のデータがデータウェアハウスの構造化された部分でまだ利用可能でない場合、その機会はデータエンジニアがデータを適切に記録し最終的にそのデータをウェアハウスに運ぶのを助ける一方、アナリストは生データをクエリする短期的な解決策を進めることとなるでしょう。ほとんどの場合で回答はタイムリーに必要であり、新しいディメンションとメトリックがウェアハウスに埋め戻される頃には、すでに古いニュースであり、皆は他に移っています。アナリストはその洞察に対する名誉を得て、その他の皆はこの新しい情報をウェアハウスに統合する時間のかかるバックグラウンドプロセスの必要性について疑問を呈するかもしれません。
従業員の業績レビューでは「インパクト」（速度と混乱を意味する）が最も求められていますが、データエンジニアリングは小さな短期間のインパクトであり、時間のかかるバックグラウンドプロセスであると責められます。データエンジニアたちは、「目立った変化を起こす」人から取り除かれた等級に位置します。
運用負荷
運用負荷は、自らが構築するシステムをサポートする専門職にとっては難しい現実です。 Q/Aチームは、「自らで構築したものは自らでサポートする」というモットーとこのアイデアに集まった現場の人々に大部分が置き換えられました。このアプローチは、技術者の意識を高め、技術的負債の蓄積に責任をもたせる適切な方法とみなされています。
データエンジニアリングには通常メンテナンスにかなりの負担がかかりますので、運用負荷は早く現れ、エンジニアを雇うよりも早くエンジニアを武装解除させます。もちろん、現代的なツールは人々の生産性を向上させますが、それはおそらくパイプラインビルダーが一度に多くの円盤を回転させることを可能にする機械に過ぎないでしょう。
さらに、運用負荷によって従業員の転職率が高くなる可能性があり、最終的には品質が低く一貫性がなく、維持できないめちゃくちゃなものとなってしまいます。
本当のソフトウェアエンジニアか？
この分野の人々は、データエンジニアが「本当のソフトウェアエンジニア」であるのか、異なるクラスのエンジニアであるのかについての議論を聞いています。一部の組織では、役割は異なり、異なる（低い）給与バンドを持っているかもしれません。カジュアルな観測では、コンピュータサイエンスの学位を持つデータエンジニアの割合は、ソフトウェアエンジニアリング全体のそれよりも著しく低いようです。
この記事で述べた理由により、その役割は悪循環を生む悪評判を被る可能性があります。
しかし、待って - まだ希望がある！
まだ立ち去らないでください！データが重要な競争優位性を持つという大きなコンセンサスは存在しており、企業はこれまで以上に分析に投資しています。 「データ成熟度」は予測可能な成長曲線に従い、それは最終的にはデータエンジニアリングが非常に重要であるという認識につながります。これまで示してきたように、何百もの企業が長期的なデータ戦略を倍増させ、データエンジニアリングに投資しています。その役割は存続しており、成長しています。
多くの企業がデータROIを安定水準に保ち、「データ運用の先端」に対する不満を感じると、今後のイノベーションがここで述べた苦労点に対処し、最終的にはデータ工学の新しい時代を創造することは間違いありません。
可能性のある方向性は非専門化であると言えます。適切なツールが揃うようになった場合、おそらく単純な作業を情報作業者に委ねることができます。継続的デリバリー技術と方法論が登場した一方でQ/A やリリースエンジニアに起こったことのように、より複雑なワークロードは共通のソフトウェアエンジニアリング作業の範囲となるでしょう。
いずれにしても、適切なツールと方法論によりその役割の方向性は定義され、この記事で述べられている懸念につながる根本原因の大部分は解決可能であると、私は期待しています。
私は今後「次世代のデータ対応型ETL」というタイトルのブログ記事を計画しています。ここでは、アクセシビリティと保守性が非常に重要となる新しいフレームワークの設計を提案します。このまだ構築されていないフレームワークには厳しい制約がありますが、代わりにベストプラクティスを強制することで強力な保証を提供します。乞うご期待！
