データ指向アプリケーションデザインは本当に良い本なのであれをちゃんと読んでいる時点でかなりのアドバンテージがあります。

仕事で複雑なSQLを書く必要がある人に一冊僕が薦めるなら10年戦えるデータ分析入門 がおすすめです。 教科書的なSQLではなく現場で要求される複雑なSQLを書くのに役立ちます。Sparkで何かを書く仕事をしてきませんでしたのでSparkの良書はすいませんが心当たりがありません。

データエンジニアリングはまだ各社手探りの段階で、新しい仕事がどういう哲学や方針なのかわからないので以下は想像で書きますが参考になれば幸いです。

• データを集積し可用性を保ちながらアクセス権を適切に管理・運用しつつスキーマ等のメタデータと共に鮮度を保ち続けるのは多大なコストがかかります。企業が利益を追求する立場である以上、そのコストに見合ったメリットが提供できている事を立証し続けるのは並々ならぬ努力が必要です。そのために会社のより重要なデータを率先して握り、複数の他部署に「データエンジニアリングをしてもらわないと仕事が回らない」と認めさせる事が重要です。

• データの次元数が増えると直感が通じなくなる「次元の呪い」は有名ですが、それほど多次元でなくてもデータが100万件を超えてくると例えばその中の0.02%というデータがどれほどのビジネス的な重要性を持った集団なのか適切に認識することが難しくなります。それが無視できる外れ値なのか、ハインリッヒの法則のように重要な示唆のある指標なのかは現場を知る人にしかわかりません。データ分析結果を元に何かを改善するよう働きかける事自体はアラをつつけばいくらでもできますが「見つけた欠陥だから優先して直そう、何故なら見つけたからだ」とか「分析できる範囲で探した欠陥だから解決すべき」というような提案になってしまっていないかは厳しく内省する必要があります。帰路で落とした家の鍵を探すために電灯の下だけを探し「ここに電灯があるからここに落ちてると助かる」みたいなアプローチばかりを続けるとコストに見合わない価値しか出せていない組織になってしまいます。

• 手元にあるデータが世の中のすべてを網羅できているはずもありませんが「あると助かるデータ」を定義するのは簡単でもその中でも「集めるのにコストがかかるデータ」も「コストがかかってでも集めないとどうしようもないデータ」もあり、利益追求の観点ではコストパフォーマンスが良いものから列挙して上から順にやっていく事が理想ですがそのパフォーマンスを論じるためには自ずとビジネスのドメイン知識が重要になります。ドメイン知識を注入し尽くした結果、時にはそのデータ活用施策を中止する事を選択肢に入れる事すらあるでしょう。

データエンジニアリングのような先進的な取り組みを行う部署に配属されるとのことですので定型的な業務ではなく柔軟かつ革新的な活躍を期待されてのことだと思います。選り好みせず様々な事を学んで、率先してこれまでにない価値を出していける事を祈っています。