データエンジニア · 業務ごと

取り込みの経路をつくる

よくある供給元へのつなぎは、いまや書くのではなく買うものであり、変換のコードは生成が扱える程度に仕様がはっきりしている。この仕事が二十年にわたり会社をまたいで似た形で繰り返されてきたことこそ、ある業務を安くする条件そのものである。

経路が回っていることは、数字が正しいことと同じではない。成熟したデータのチームで時間が消えていたのは、つくることではなかった。本当であり続けさせることだった。

データが誤っているのに、何もエラーが出ていないとき

静かな誤りこそこの仕事を特徴づける失敗であり、それは道具を良くすれば解ける検出の問題ではない——その数字が事業にとって何を意味するはずなのかを知っていることが要り、それはスキーマではなく人のなかにある。テストが捕まえるのは、試そうと思いついたことだけである。

失敗の性質についての判断であって、それがどれくらいの頻度で起きるかを測ったものではない。無言のまま進むデータの誤りは、どこでも数量化されていない——理由のひとつは、定義からして、それらは遅れて見つかるか、まったく見つからないかのどちらかだということにある。

数字が何を意味するかを引き受ける

文から SQL を出す道具は問い合わせを安くし、それによって定義をより荷を支えるものにする。誰でも問える瞬間から、答えは、モデルがどの定義を拾ったかに完全に依るからである。アナリストのページの証拠も同じ向きを指している——実際の企業のデータ基盤からつくられたベンチマークで素のモデルの得点は0だった。公開ベンチマークでは80から90%である。そしてその差は SQL ではなく、スキーマと意味づけである。

そのベンチマークは、誰が定義を持つかではなく問い合わせについてのものであり、著者は代替の系を売っている——アナリストのページの記録がそう述べている。示しているのは、企業のスキーマがいまのモデルを打ち負かすということであって、意味づけを維持するために誰かが雇われているということではない。

問い続けるのにいくらかかるか

データ基盤はいまや、高くついている問い合わせを自分から示し、直し方まで提案する。それは本物の助けである。残るのは、その答えにその金を払う価値があるかどうかの判断であり、それには、その数字を誰が何のために使っているかを知っていることが要る。

費用が全体として上がっているのか下がっているのかについては何も言っていない。問い合わせが安くなると問いの数が増えがちであり、それは請求額をどちらの向きにも動かしうる。

何を残し、消し、そもそも集めてはならないか

これは取り込みの経路のなかに実装された法的義務であり、法的義務は仕組みにではなく人につく。誰かが規則を決めたあと、それを強制することは道具にできる。決めること、そしてあとから適合を示せることが、残る部分である。

要件は市場によっても、データの種類によっても大きく違う。この業務を決着させるのは、会社全体ではなくデータのチームの保存や削除の運用を名指しした執行の事例——誰が何を、いつまでに消すはずだったのかを当局が述べたもの——である。

文章で答える仕組みに食べさせる

検索の質はいまや、AIの札を下げたデータの問題であり、それがここに落ちるのは、モデルではなく、取り込みの経路と権限と鮮度の問題だからである。生成の機能が製品に載るまで、職としては存在しなかった。

新しい仕事が現れることは、新しい人員ではない。大半の会社でこれは、すでにデータ基盤を持っている人に吸収されており、ここにはそれ以外のことは何も書かれていない。