概要
前提
ゆめみでの職位
アソシエイト（年収目安　500万~580万）
プロフェッショナル（年収目安　560万~670万）
リーダー（年収目安　650万~950万）
シニア（年収目安　900万~1150万）
派生職種（マルチスタック）
アナリティクスエンジニア
MLOps エンジニア（機械学習エンジニア）
出典・引用・参考

💡

ぜひコメントやご意見お待ちしています

概要

の上で、データエンジニアとして自分の給与を定めるための補助シート。社内外でのスキルアップのためのロードマップとしても活用できます。

🦉

ゆめみは評価制度や上司がいない組織であり、給与自己決定制度により給与決定が運用されていますので、下記ガイドラインに関わらず、人材市場評価も勘案しながら、本人が給与は自己決定をします。給与はえいや！ですまた、「ガイドライン」とは、その定義から、それを参考にした上で本人が自己決定する手がかりでしかありません。チェックリストを満たしたら単純に給与が上がるというものではないですし、チェックリストを満たしていないから給与が上げられないわけでもありません。細分化した役割、期待、能力を設定している理由は、本人が自ら能力開発目標を立てるための助けになるとして設定しています。また、新卒やアソシエイトだけでなく、あらゆる職位で育成を行う事を明確にして、日本で最も人材育成に力を入れている企業を目指して育成を進めていく方針です。その上で、本ガイドラインを外部にオープンにする事により、エンジニアがより適正に評価され、能力開発が進む事を期待します。

前提

以下を参考・引用している。詳細な情報は以下へ飛んで確認してください。

またRDBやソフトスキルなどに関する内容を考慮し、アプリケーションエンジニア職位ガイドラインのチェックリストとセットで利用することを前提とします。

ゆめみでの職位

アソシエイト（年収目安　500万~580万）

Erik Stoltermanが提唱したDXの定義を知っている [1]

The digital transformation can be understood as the changes that digital technology caused or influences in all aspects of human life.

経済産業省のDXの定義を知っている [2]

企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること

DXの推進に向けて企業や経営者が実施すべき事項を取りまとめた文書である「デジタルガバナンス・コード 2.0」の内容を説明でき、円滑にコミュニケーションできる [2]

Bill Inmonが提唱したDWH（統合された中央集権型アーキテクチャ）の内容を説明でき、円滑にコミュニケーションできる [3]

Ralph Kimballが提唱したdimensional modeling・star schemaの内容を説明でき、円滑にコミュニケーションできる [4]

Dan Linstedtが提唱したDataVolt（Scott AmblerのAgileを取り入れたデータマート開発のメソドロジー）の内容を説明でき、円滑にコミュニケーションできる [5]

hub

link

satellite

Zhamak Dehghaniが提唱したData Mesh（分散されたメッシュ型アーキテクチャ）の内容を説明でき、円滑にコミュニケーションできる [6]

CDP・CRM・DMP・MA・SFAとDWHの違いを説明でき、円滑にコミュニケーションできる [30]

	目的	備考
DWH	データ統合・分析	一元管理
CDP	顧客理解	自社の会員情報など（1st Party Data）を利用、ID
DMP	汎用的なデジタル広告最適化	匿名情報（3rd Party Data）を利用、Cookie
MA	見込み客の獲得や管理、育成	ナーチャチング
SFA	商談から受注のプロセス管理	営業活動の最適化・効率化
CRM	既存顧客との信頼関係の構築	リピート

DAMA-DMBoKで定められた11の知識領域の内容を説明でき、円滑にコミュニケーションできる [7][9]

Peter Aiken's framework のピラミッドの内容を説明でき、円滑にコミュニケーションできる

ゆずたそ氏の「データマネジメントが30分でわかる本」で書かれている内容を説明でき、円滑にコミュニケーションできる

‣

11の知識領域

Data Governance	planning, oversight, and control over management of data and the use of data and data-related resources. While we understand that governance covers ‘processes’, not ‘things’, the common term is Data Governance, and so we will use this term.
Data Architecture	the overall structure of data and data-related resources as an integral part of the enterprise architecture
Data Modeling & Design	analysis, design, building, testing, and maintenance (was Data Development in the DAMA-DMBOK 1st edition)
Data Storage & Operations	structured physical data assets storage deployment and management (was Data Operations in the DAMA- DMBOK 1st edition)
Data Security	ensuring privacy, confidentiality and appropriate access to PII, PHI and an individuals private data. Ensuring network security as well
Data Integration & Interoperability	acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support ( a Knowledge Area new in DMBOK2)
Documents & Content	storing, protecting, indexing, and enabling access to data found in unstructured sources (electronic files and physical records), and making this data available for integration and interoperability with structured (database) data.
Reference & Master Data	Managing shared data to reduce redundancy and ensure better data quality through standardized definition and use of data values.
Data Warehousing & Business Intelligence	managing analytical data processing and enabling access to decision support data for reporting and analysis.
Metadata	collecting, categorizing, maintaining, integrating, controlling, managing, and delivering metadata.
Data Quality	defining, monitoring, maintaining data integrity, and improving data quality.

CMMI 協会のデータ管理成熟度モデルの内容を説明でき、円滑にコミュニケーションできる [8]

実施された
管理された
定義された
定量的に管理された
最適化している

ISO/IEC 25012（データそのものの品質）の内容を説明でき、円滑にコミュニケーションできる [9]

ISO/IEC 25024（データを使ったサービス実現プロセスに関する品質）の内容を説明でき、円滑にコミュニケーションできる [9]

ISO/TS 8000-61（データの整備から活用までの管理プロセスに関する品質）の内容を説明でき、円滑にコミュニケーションできる [9]

データ基盤に関するポストモーテムの内容を説明でき、対応ができる [27] [35] [36] [37]

dbtを利用した開発ができる

OLAP・OLTPの内容を説明でき、円滑にコミュニケーションできる

SQL・Pythonを利用したETLが実装できる

Mike JulianのPractical Monitoringの内容を説明でき、円滑にコミュニケーションできる [10]

apache airflowなどのワークフローツールを利用した開発ができる

John Boydが提唱したOODAの内容を説明でき、円滑にコミュニケーションできる [11] [12]

SSOT（Single Source of Truth）の内容を説明でき、円滑にコミュニケーションできる [13]

カラムナデータベースの内容を説明でき、円滑にコミュニケーションできる

TerraformなどのIaaSを利用したデータインフラが構築できる

Data Observabilityの5つの柱であるうちの一つであるData Lineageの内容を説明でき、円滑にコミュニケーションできる [23] [24]

DBのインデックスについて説明できる [31]

HDFS、Hadoop、MapReduceなどの分散システムの基礎知識について説明できる

RDB・NoSQL（Graph・KeyValue・WideColumn・Document）などのデータベースの違いについて説明できる

プロフェッショナル（年収目安　560万~670万）

Google Cloud Professional Data Engineerと同等の知識を持ち、実装できる

AWS Certified Big Data - Specialityと同等の知識を持ち、実装できる

dbt Analytics Engineering Certificationと同等の知識を持ち、実装できる

DAMA-DMBoKで定められた11の知識領域を考慮した設計ができる [7][9]

‣

11の知識領域

Data Governance	planning, oversight, and control over management of data and the use of data and data-related resources. While we understand that governance covers ‘processes’, not ‘things’, the common term is Data Governance, and so we will use this term.
Data Architecture	the overall structure of data and data-related resources as an integral part of the enterprise architecture
Data Modeling & Design	analysis, design, building, testing, and maintenance (was Data Development in the DAMA-DMBOK 1st edition)
Data Storage & Operations	structured physical data assets storage deployment and management (was Data Operations in the DAMA- DMBOK 1st edition)
Data Security	ensuring privacy, confidentiality and appropriate access to PII, PHI and an individuals private data. Ensuring network security as well
Data Integration & Interoperability	acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support ( a Knowledge Area new in DMBOK2)
Documents & Content	storing, protecting, indexing, and enabling access to data found in unstructured sources (electronic files and physical records), and making this data available for integration and interoperability with structured (database) data.
Reference & Master Data	Managing shared data to reduce redundancy and ensure better data quality through standardized definition and use of data values.
Data Warehousing & Business Intelligence	managing analytical data processing and enabling access to decision support data for reporting and analysis.
Metadata	collecting, categorizing, maintaining, integrating, controlling, managing, and delivering metadata.
Data Quality	defining, monitoring, maintaining data integrity, and improving data quality.

個人情報・個人データの違いを理解し、パーソナルデータを適切に扱うことができる [26]

A Taxonomy of Privacyなどプライバシーデータに関するリスクの内容を説明でき、円滑にコミュニケーションできる [14] [15]

以下の6つのデータ品質評価軸を考慮した設計ができる [7] [9] [37]

正確性	データが表そうとしている実体が正しく示されていること
完全性	すべてのデータ要素が揃っていること
一貫性	同じ実体を表す2つ以上のデータに不整合がないこと
最新性	データが期限内の実体を示していること
精度	データの詳細度（有効桁数など）が十分であること
プライバシー	アクセス制御と利用監視がなされていること
妥当性	対象の業務内容においてデータの整合性が取れていること
参照整合性	参照元のデータが存在すること
適時性	必要な時に速やかにデータが利用できること
一意性	同じ実体を表すデータが1つだけ存在すること
有効性	データが定められた属性（型・形式・精度・文字コード等）が有効範囲に収まっていること

適時性を考慮してSLA / SLO / SLIが設計できる [27][28]

以下の4つのデータセキュリティを考慮した設計ができる [7][9]

認証
認可
監査
保護

TerraformなどのIaaSを利用したデータインフラが設計できる

dbtを利用し、適切なデータモデリングができる [7][9][25]

概念レベル

論理レベル

物理レベル

pandera・dbt・great expectationsなどを用いてテストが実装できる

Singular tests

Generic tests

バッチ処理とストリーミング処理を適切に使い分けられる

ELTとETLを考慮した設計ができる [29]

パーティショニングなどのデータウェアハウスの最適化を考慮したDWHを設計できる

特定のステークホルダー・データオーナーとデータ連携できる

Data Lineageを意識したETL設計ができる [23] [24]

DataOps（自動化されたCICDなど）で開発できる [22]

カラムナなど適切なデータフォーマットを選択できる

Pub/SubやKafkaなどのメッセージキューを利用した分散システム設計ができる

Apache BeamやSpark、Hadoopなどの分散処理フレームワークを利用したストリーミング設計ができる

apache airflow・dagsterなどのワークフローツールを利用した設計ができる

冪等性を考慮したバッチ処理の設計ができる

Observabilityを考慮したデータパイプラインを設計できる

Meilisearch・Elasticsearchなどの検索エンジンを考慮した設計ができる

5つ以上のデータソースを統合した基盤が構築できる

3つ以上の異なるSLAを持ったデータソースを統合した基盤が構築できる

リーダー（年収目安　650万~950万）

DWHの選択など、要件にあった適切なシステム設計ができる

Data Activationの要件に沿って適切にreverse ETLを設計できる [21]

Data Contractを理解し、安全な基盤設計ができる [42]

要件に応じて適切にBI（LookerStudio・Tablaeu・Superset）を選択できる

新卒等にデータエンジニアリングに関してオンボーディングができる

市場動向を理解し、日頃から追従している

チームメンバーの能力を継続的に底上げする働きがけができる

三隅二不二氏が提唱した行動理論（スタイル論）に基づくPM理論を理解し、行動できる [33] [34]

チームをマネジメントし、OODA loopを回すことができる [11] [12]

dbtなどのデータエンジニアリングに関するOSSを開発に貢献できる

データ基盤の問題点を明確化し、継続的に改善できる

データビジネスにおいて、新たなData Integrationの提案等ができる [20]

様々なデータに対するドメイン知識がある

データエンジニアリングに関するOSSへの貢献ができている

ビジネス目的から要件を抽出してデータアーキテクチャを設計できる

グループダイナミクスにおける集団浅慮、集団圧力、社会的手抜きといった問題を理解した上で対策できている [38] [39]

コンフリクト（生産的・非生産的）を理解した上で、時に交渉することができる [40] [41]

シニア（年収目安　900万~1150万）

https://datatech-jp.github.io/ などで積極的に活動し、業界のデータエンジニアリング・データビジネスの発展に貢献している

テラバイト・ペタバイト級の規模のデータ基盤が設計・運用できる

派生職種（マルチスタック）

以下の職能を兼任する可能性が高く、技術的にも親和性のあるスキルスタックを考慮してマルチスタックの加点要素があります。

アナリティクスエンジニア

さまざまなステークホルダーを巻き込み、積極的かつ継続的なコミュニケーションをファシリテーションできる

データ品質を担保する設計ができる

データの異常・欠損などを監視できる

データのセキュリティを管理できる

データに対するビジネスロジックをテストで保証できる

データに関する継続的なドキュメンテーションができる

統一的なKPI・KGI指標の運用管理ができる

データドリブンにKPIの設計等の議論をファシリテーションできる

Evans, James Rが提唱した3つのアナリティクスを考慮した文化づくりができる [16] [17]

Descriptive Analytics

Predictive Analytics

Prescriptive Analytics

上記の３つのアナリティクスに加え、Gartnerが提唱した4つ目のアナリティクス「Diagnostic Analytics」を考慮した文化づくりができる [18]

意思決定につなげるためのデータマネジメント～今、注目を浴びるアナリティクスエンジニア～

2023年4月6日に、「ガートナーデータ＆アナリティクスサミット 2023」で発表した、山邉の資料です。

speakerdeck.com

意思決定につなげるためのデータマネジメント～今、注目を浴びるアナリティクスエンジニア～

MLOps エンジニア（機械学習エンジニア）

Google Cloud Professional Machine Learning Engineerと同等の知識を持ち、実装できる

AWS Certified Machine Learning - Specialtyと同等の知識を持ち、実装できる

Hidden Technical Debt in Machine Learning Systems (Sculley et al. 2015)の内容を考慮した設計ができる [19] [32]

負債	説明
Entanglement	MLモデルはCACE (Changing Anything Changes Everything) であり、訓練に使用するデータや特徴量設計が変わると、 MLシステムの挙動ごと変化する
Correction Cascades	MLモデルを直列にスタッキングした場合には、上流のモデルの変更が下流のモデルの性能に影響する。そのため独立にモデルの性能を向上させてもMLシステムとして性能が向上するかは不明となる
Undeclared Consumers	MLモデルの出力を、他のどのシステムが使用しているのか未把握である場合、当該モデルの変更による影響を見積もれない。また未把握モデルが当該モデルとフィードバックループを作っているとさらに面倒な問題を生む
Unstable Data Dependencies	訓練データと本番データの性質が異なったり、訓練データに依存して特徴量やルックアップテーブルが作られるアルゴリズムだったりすると、 MLシステムの挙動は思い通りでなくなる可能性がある
Underutilized Data Dependencies	MLシステムで活用されていないデータを入れたままにしていても、モデルは動作するが、後々そのデータに起因した修正の面倒さやバグが発生する可能性がある
Static Analysis of Data Dependencies	プログラムの場合はクラス間などの依存関係を簡単に静的解析で追えるが、 MLシステムでは、使用している種々データ間の依存関係を静的に明確化することが難しく、後々に依存関係の未把握が問題原因になる可能性がある
Direct Feedback Loops	MLシステムの推論結果によって、システム運用時に測定される将来の訓練データが影響を受ける場合、 MLシステムそのものが不安定になる可能性がある
Hidden Feedback Loops	異なるMLシステムを介して互いに推論結果が影響し合っていると、直接フィードバックループ同様にMLシステムそのものが不安定になる可能性がある
Glue Code	MLモデル (MLアルゴリズム)が、 MLシステム内で他のモジュールと連動して使用できるように追加した「接合用コード」が、 utils.pyに大量に含まれていて保守性が悪いパターン
Pipeline Jungles	データの「前処理パイプライン」などに、データの新規追加・増築を繰り返していくうちに、各種パイプラインが保守性・可読性の悪い、ぐちゃぐちゃ状態になるパターン
Dead Experimental Codepaths	試作段階のコードや実験的に追加したコードたち (既に実質的には未使用) が、製品コードに残っていて動作に関わっているパターン
Abstraction Debt	MLシステムの各種コードを抽象的に記述せず、個別具体的に記述・実装することによって、保守性が悪くなるパターン
Common Smells	MLモデルにPythonの生のデータ型が入力されていたり、複数の言語でMLモデルが構築されていたり、試作コードのままの状態で製品レベルにリファクタリングされていない、などのパターン
Configuration Debt	設定ファイル (config) を整備せず、コードにパラメータ値やパイプラインのプロセスなどを直書きしてしまっていることで、変更容易性、可読性が悪い状態
Fixed Thresholds in Dynamic Systems	実環境では入力データの特徴が経時変化するのに対して、 MLモデルの推論のしきい値などを固定値に指定したままにしているせいで、システムの性能が悪化した状態
Monitoring and Testing	実環境での現時点での最新データの特徴や、 MLモデルの推論値の分布などをモニタリングして対処しないことで、MLシステムの性能が悪化する問題
Data Testing Debt	入力データをサニティチェック (健全性確認)したり、その分布を確認したりしないことに起因して発生する問題
Reproducibility Debt	乱数シードなどを固定しておらず、 MLモデルの訓練結果を再現できず、再現性のないMLシステムになっている状態
Process Management Debt	複数のMLモデルが動作するシステムの場合、モデルの更新や障害復旧プロセスなどが管理されていないと、システムを安定動作させづらい問題
Cultural Debt	研究者とエンジニアの文化の違いに起因するチーミング問題

データ・モデル・コードを適切にバージョン管理できる

モデルの品質管理を考慮した設計ができる

モデル負荷を考慮した設計ができる

embedding storeを設計できる

Amazon SageMaker Feature StoreやVertex AI Feature Storeを用いてfeature storeを設計できる

機械学習モデルのCICDを設計できる

機械学習モデルのPoCを開発できる

RMSE・AUC・DCG・IoU・BLEUなどの分野別のモデル評価指標を理解している

VertexAIやsagemakerのエコシステムを利用したモデル開発環境を構築できる

GCP・AWSのAutoMLを実装できる

データエンジニア職位ガイドライン

概要

前提

ゆめみでの職位

アソシエイト（年収目安 500万~580万）

プロフェッショナル（年収目安 560万~670万）

リーダー（年収目安 650万~950万）

シニア（年収目安 900万~1150万）