- 概要
- 前提
- ゆめみでの職位
- アソシエイト（年収目安 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分でわかる本」で書かれている内容を説明でき、円滑にコミュニケーションできる
‣
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]
‣
個人情報・個人データの違いを理解し、パーソナルデータを適切に扱うことができる [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/ などで積極的に活動し、業界のデータエンジニアリング・データビジネスの発展に貢献している
テラバイト・ペタバイト級の規模のデータ基盤が設計・運用できる
派生職種（マルチスタック）
会社ごとに役割は異なりますが以下のスキルは市場価値が高く、マルチスタックの加点要素となります
アナリティクスエンジニア
データ分析の経験が3年以上ある
さまざまなステークホルダーを巻き込み、積極的かつ継続的なコミュニケーションをファシリテーションできる
データ品質を担保する設計ができる
データの異常・欠損などを監視できる
データのセキュリティを管理できる
データに対するビジネスロジックをテストで保証できる
データに関する継続的なドキュメンテーションができる
統一的なKPI・KGI指標の運用管理ができる
データドリブンにKPIの設計等の議論をファシリテーションできる
Evans, James Rが提唱した3つのアナリティクスを考慮した文化づくりができる [16] [17]
Descriptive Analytics
Predictive Analytics
Prescriptive Analytics
上記の３つのアナリティクスに加え、Gartnerが提唱した4つ目のアナリティクス「Diagnostic Analytics」を考慮した文化づくりができる [18]
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を実装できる
出典・引用・参考
- Erik Stolterman, Anna Croon Fors （2004）“Information technology and the good life” Information Systems Research Relevant Theory and Informed Practice,
- デジタルガバナンス・コード2.0
- William H. Inmon, "Bill Inmon, President and Chief Technology Officer, Forest Rim™ Technology LLC Best known as “The Father of Data Warehousing.” Monthly Columnist, Business Intelligence Network and EIM Institute, World Renowned Speaker, Author and Instructor. "
- Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling
- What is DataVault?
- Data Mesh Principles and Logical Architecture Defined
- DMBoK - Data Management Body of KnowledgeDMBoK - Data Management Body of Knowledge
- 「データ成熟度」を評価する具体的な手法とは？
- 政府CIOポータル - データ品質管理ガイドブック
- Practical Monitoring by Mike Julian Released October 2017
- DX SQUARE
- OODA loop
- Single Source of Truthとは？全体的な理解と実践のためのガイド
- 経済産業省 - DX 時代における 企業のプライバシーガバナンスガイドブック ver1.2
- A Taxonomy of Privacy
- Business Analytics: The Next Frontier for Decision Sciences by James R. Evans, Carl H. Lindner College of Business, University of Cincinnati, Decision Science Institute, March 2012
- ビジネスを進める 「処方的アナリティクス」
- Diagnostic Analytics
- Hidden Technical Debt in Machine Learning Systems Part of Advances in Neural Information Processing Systems 28 (NIPS 2015)
- Data integration
- Reverse ETL / Data Activation
- Definition of DataOps - Gartner Glossary
- The Ultimate Guide To Data Lineage
- Incident Prevention for Data Teams: Introducing the 5 Pillars of Data Observability
- 【DMBOKで学ぶ】データモデリング
- プライバシーガバナンス
- タイミーのデータ基盤品質。これまでとこれから。
- SLO Workshop で学ぶ SLO の実践的な理解の促進
- Dataform - ETL vs ELT
- CDPやDWHの違いは？それぞれの活用方法を解説
- 図解 DB インデックス
- CLISP-ML(Q)をはじめとしたMLシステムの品質確保に関する調査
- PM理論とは？SL理論との違いをわかりやすく解説
- 特性理論
- Postmortem Culture: Learning from Failure
- データ基盤 Knile のプロダクトマネジメントの取り組み
- 「データ分析基盤の障害対応事例LT祭り」Data Engineering Study #4イベントレポート
- 会議で集団浅慮になっていませんか？
- グループダイナミクスとは【意味や役割について具体例とともに解説します】
- 社内の「対立」と「和」について考える
- 交渉上手は頭の中にBATNA（バトナ）やZOPA（ゾーパ）などの構造を描く：交渉の基本概念
- Data Contract について調べた