FDE（フォワード・デプロイド・エンジニア）の紹介を読むと、顧客の現場に入り込み、要件が固まる前に動くものを作る姿が目立ちます。
けれども、その「動くもの」が中身を持つには、まず顧客の手元に散らばったデータが流れていなければなりません。
アプリより先に、データの取り出しと整備でつまずく場面は、想像以上に多そうです。
FDE の仕事でデータ統合がどんな位置を占めているのか、気になったことはないでしょうか。
私は FDE の経験がなく、この役割を学んでいる途中です。
目指すのは、FDE という職種を生んだ Palantir の公開資料をたどり、データ統合まわりで何が求められているかを言葉にできるところまでです。
FDE の仕事の足元にはデータ統合がある
手がかりになるのが、Palantir の公式ブログが2020年に公開したインタビュー記事です。
登場する FDSE（同社での FDE の呼び名）は、当時米国防総省の顧客向けにデータ統合のソリューションを届ける仕事に取り組んでいると紹介されていました。
同氏は必要なスキルの幅を、ソフトウェア開発からデータエンジニアリング、顧客との関わり、創造的な問題解決まで、と表現しています。
記事に並ぶ技術的な課題の例も、データの話が中心です。
たとえば、業務の要になるワークフローへ流し込むテラバイト規模のデータパイプラインを、どう作り、広げ、保守するかという問題です。
顧客ごとの規制やコンプライアンスに合わせて、データとワークフローへのアクセス権をどう設定するかも、課題の一つです。
新しいデータモデルを設定する作業も、日々の仕事の一部として挙がっていました。
「現場で速く作る」は、データが流れる土台があってはじめて成り立つ、と読むのが自然だと感じます。
インタビューの全文は「A Day in the Life of a Palantir Forward Deployed Software Engineer」で公開されています。
取り出すときは「失敗する前提」で設計する
では、顧客のシステムからデータを取り出すとき、何に気をつけるのでしょうか。
Palantir の製品 Foundry には、外部システムとデータを同期する Data Connection という機能があります。
そのドキュメントは冒頭で、システム間のデータ連携は失敗しやすく、しかも失敗から立て直すのが難しいとはっきり書いていました。
原因として挙がるのは、ネットワークの不調、ディスクの故障、応答しない接続元のシステムなど、使う側の手が届かないものばかりです。
こうした失敗は同期を止めるだけでなく、その先にある分析のパイプラインまで壊してしまいます。
さらに、欠けたデータや壊れたデータが気づかれないまま使われると、組織にとって危険にもなりうる、と指摘されていました。
対策として説明されているのは、失敗時の自動リトライと、接続元から少量ずつ単純なクエリで取り出す作り、そしてデータの健全性を監視して重大な失敗を知らせる仕組みの三つです。
ここから持ち帰れるのは、取り出しは一度成功すれば終わりではなく、失敗し続ける前提で見張るものという考え方でしょう。
設計の原則は Data Connection の概要 にまとまっています。
加工は取り込んだ後、記録が残る場所でやる
同じドキュメントでもう一つ目を引くのが、加工をどこでやるかという方針です。
Foundry は、データをいちばん生の状態のまま、外部で前処理せずに取り込むという考え方をとっています。
理由は、ブランチとバージョン管理のある Foundry 側のパイプラインを、生データに加えたすべての変更の記録場所にするためです。
途中で問題が起きても、その経路の中で原因を特定して直せる、という説明でした。
実際、Data Connection は取り込み前の変換の選択肢を意図的に少なくしているそうです。
裏返すと、現場で急いで手元のスクリプトで値を直してから渡すと、どこで値が変わったのかを後から追えなくなります。
FDE は顧客の目の前で素早く結果を出す役割だからこそ、加工の履歴を一か所に残す規律が効いてくるのだと思います。
接続先の多様さにも触れられていて、リレーショナルデータベースや S3、SFTP などの定番には標準の連携を用意しつつ、新しい種類のシステムにも対応できる作りだと書かれていました。
新しいシステムでも既存のプラグインを小さな変更で使い回せる場合が多く、スケジュール実行やアップロードのような共通部分は標準化されている、と説明されています。
毎回変わるのは「接続」だけにして、それ以外は使い回すという分け方は、自前の仕組みで連携を組むときにも参考になりそうです。
権限とデータの形は後回しにしない
データを取り出せたら終わり、ではありません。
先ほどのインタビュー記事は、自分の解決策を点検する問いとして「将来アクセス制御の要件が変わっても耐えられるか」を挙げていました。
規制やコンプライアンスの事情は顧客ごとに違い、しかも途中で変わることもあります。
最初に誰が何を見てよいかを雑に決めると、要件が変わったときに作り直しになるという意味だと受け取れます。
同じ記事には、「自分の解決策は、利用者がプラットフォームの中で自力で協力し、発見できるようにしているか」という問いも並んでいました。
データを整えるゴールは、FDE が分析して見せることではなく、現場の人が自分でデータを探して使える状態にある、と読み取れる問いです。
データモデルの設定が日々の仕事に含まれているのも、この「使う人に分かる形」を作るためだと考えると筋が通ります。
なお、ここで参照した資料はいずれも Palantir のもので、自社製品を前提にした書き方である点は差し引いて読んでください。
最後に
FDE のデータ統合で求められているのは、失敗を前提にした取り出し、加工の記録を一か所に残すこと、そして権限とデータの形を最初から設計することの三つでした。
動くものを速く出すための速さは、地味なデータの規律に支えられている、というのが今回たどり着いた整理です。
FDE がどんな順番で仕事を進めるのかは、要件が固まる前に動かして確かめる進め方を扱った記事にまとめています。
役割そのものの定義や、Palantir でこの職種が生まれた背景は、FDE とは何かを整理した記事で扱いました。
私自身も、データを「取れた」で満足せず、次に壊れたとき気づけるかを確かめる習慣から身につけていこうと思います。
以上です。
コメントを残す