はじめに
こんにちは、@glassmonekey です。Ubie 株式会社でソフトウェアエンジニア（SWE）をしています。
最近、テックリードとしての活動に加えて、データプロダクトマネージャーという役割に踏み込み始めました。同じようにキャリアの方向性を考えているエンジニアの方に、参考になればと思って書きます。
AI時代にエンジニアが向き合うキャリアの問い
みなさんは最近、AIがコードを書く時代に自分のエンジニアとしての価値はどこにあるのだろう、と考えたことはないでしょうか？
私も例に漏れず、コードを書くこと自体が目的になっていないか、自分の技術力が一番活きる場所は本当にここなのか、考えることが増えました。
この問いに対して、同僚の @shikichee が書いた「AI時代のプロダクト開発の役割の変化」という記事が 1 つの方向性を示してくれました。
詳細は元記事に譲りますが、要点は「実装のコモディティ化により、エンジニアの価値は『How』から『What/Why』へ、そして量産されるコードの『品質と設計を見極めること』へシフトする」ということです。自分はそう受け取りました。
自分の感じていたモヤモヤを言語化してもらえた気がしましたし、自分がデータプロダクトマネージャーに踏み込んでいく後押しにもなりました。
テックリードからデータプロダクトマネージャーへの変遷
テックリード：システムを設計する
入社以来、基盤システムのテックリードとして設計・開発をリードしてきました。1300 万ユーザー規模の Web コンテンツ配信基盤リプレースでは、複雑なシステムをどう設計し、どうチームで動かすかに取り組んでいました。
テックリード+α：プロダクトマネジメント入門
Web コンテンツ配信基盤のリリース後は、配信基盤システムのテックリードとして、システムを使った社内活用や新規事業立ち上げが活動の中心でした。その中で、プロダクトの方向性や優先順位を決める場面が自然と増えていきました。ただ、自分の役割としてはテックリードの延長でしかなく、「システムが動くこと」の先にある「データが価値を生んでいるか」という問いには踏み込みきれていませんでした。
データプロダクトマネージャー：データそのものにプロダクトとして向き合う
そして現在、データそのものをプロダクトとして捉え、蓄積・品質・設計・ガバナンスまで含めてマネジメントする役割に踏み込みました。データプロダクトマネージャー（Data Product Manager、以下 Data PdM）です。
Ubie ではデータそのものが事業価値を生み出す源泉であり、データ基盤は「コストセンター」ではなくビジネスの主役です。その品質が売上を左右します。だからこそ、データにプロダクトマネジメントが必要でした。
価値を届ける先は、症状検索エンジン「ユビー」の利用者、医療機関、製薬企業といった事業の顧客から、社内のデータ活用メンバーまで多岐にわたります。
データにプロダクトマネジメントが必要だった理由
ボトムアップでは全体設計が追いつかない
Ubie には各チームが自律的に動くカルチャーがあります。プロダクトの立ち上げや改善のスピードにおいて、これは大きな強みです。データの扱いも同様で、各プロダクトチームがそれぞれの課題に合わせてデータパイプラインを開発し、素早く価値を届けてきました。実際に、月 35 人以上の開発者が dbt リポジトリにコミットしており、その多くはデータ専任ではないプロダクトエンジニアです。
一方で、チームごとに独自にデータを扱っていくと、設計思想や管理方法がバラバラになり、品質の担保が個人のスキルや努力に依存しがちです。プロダクト横断で見ると一貫性が取れていない。これは誰かが悪いのではなく、全体最適の設計が追いついていないという構造の問題です。
この課題に対して、プロダクト開発・データ基盤・分析のそれぞれの担当者が集まり、横断的に議論する取り組みが始まりました。各チームの自律性を活かしたボトムアップの動きとして、早期に課題を共有し連携する機能を果たし始めていました。
しかし、議論を重ねるほど見えてきたのは、全体を俯瞰する視点の不足でした。個別の課題は拾えても、事業価値から逆算して優先順位を決める機能がない。ボトムアップで横断的に向き合おうとしたからこそ、トップダウンの設計視点が必要だと気づけました。
決定的だったのは、データマネジメントの専門家である @syou6162 氏による外部アセスメントです。外部の視点で評価してもらうことで、この構造的な課題がはっきりと言語化されました。氏の現職でのアセスメント実施事例も参考になります。
データ品質が事業価値を左右する
Ubie の事業価値は「人々を適切な医療に案内する」という意思決定の支援に凝縮されています。症状と疾患の関係性、医療機関の情報、ユーザーの行動データ。この案内の精度を決定づけるのが、背後にあるデータの品質です。
体調に不安を抱えながら適切な医療行動が取れない、いわゆる「医療迷子」を解消するプロダクトだからこそ、データ品質の低下は案内の信頼性を直接損ないます。
これら一連のデータの取得・蓄積・活用は、Ubie の事業価値に直結するアセットそのものです。一方で、扱うのは要配慮個人情報を含む医療領域のデータです。「攻めの活用」と「守りのガバナンス」を高度に両立させる必要があり、これを個々の開発者の裁量に委ねることは、スケールにおけるボトルネックであり、リスクでもあります。
だからこそ、データの品質を個人の努力ではなく仕組みで担保する必要があります。自分たちのチームでも仕組み化を進めてきました。
- パイプライン管理とテストの自動化：dbt でデータパイプラインを管理し、テストや lint を CI に組み込んでいる
- データパイプラインのレイヤリング：再利用性や保守性を構造的に担保するため、データの流れを明確な層に分離し参照方向を制約している（dbt best practices に沿った設計）
- データソースの鮮度監視：Source Freshness によるデータソースの鮮度監視を導入している
- オブザーバビリティの導入と可視化：Elementary などの Data Observability ツールで異常検知やデータリネージの可視化を進めている
- データセキュリティのガバナンス設計：要配慮個人情報に対するアクセス制御をデータセキュリティの仕組みとして設計している
しかし、パイプラインの自動化は進んでも、ビジネスロジックに踏み込んだ品質保証はまだ人が頑張らないと回らない状態です。
- ビジネスロジック検証の属人化：テストの大半がスキーマレベルの制約チェックに偏っており、ビジネスロジックの検証は書ける人の判断に委ねられている
- アラートの形骸化：日々アラートが鳴る中で、どれが本当に重要かの判断が属人化している
- 障害影響の調査が経験依存：上流の仕様変更や欠損でパイプラインが壊れたとき、影響範囲の特定と対応が個人の経験に依存している
- データ定義のサイロ化：データの定義やオーナーシップがプロダクト横断で統一されておらず、同じ指標でもチームごとに解釈が異なる
ツールは揃いつつあるのに、テストの中身と運用が追いついていない。やるべきことが山積みの中で、すべてのデータを完璧に保つアプローチには限界があります。
この状況に対して、チームではデータモデルに信頼性レベル（Tier）を定義し、事業価値の高いデータから優先的に品質を固める取り組みを始めました。Tier 定義は単なる分類ではなく、「どのデータが落ちたら、どの事業 KPI の意思決定が止まるか」という問いについてビジネス側と合意した上で、データの重要性を階層的に表現したものです。
組織としてデータマネジメントに正面から向き合い始めた一例です。
AI時代のデータ品質にはプラットフォームエンジニアリングが必要になる
チームではこれまでも、データディスカバリーや分析業務への生成 AI 活用、dbt の民主化と LLM による開発ブーストなど、データ業務への AI 活用をボトムアップで進めてきました。しかし、データマネジメントに組織として取り組むまでには至っていませんでした。
前セクションで触れたように、今はデータ品質の肝心なところが人の判断と経験に依存しています。しかし、データを扱う主役は人から AI へと移りつつあります。AI Agent がデータを自律的に扱い、示唆を出し、意思決定を支援する。そうなったとき、品質の担保を人の頑張りに頼ったままでは成り立ちません。基盤が不安定なら Agent のアウトプットも不安定になります。
この状況を打破するヒントになったのが、Google Cloud の Richard Seroter 氏が提唱する「シフトダウン」という考え方です。
品質の責任を個人の努力ではなくプラットフォームに押し下げ、テストや異常検知、修復提案までを自動化する。AI が安全に「自走」できる状態をプラットフォーム側で作ります。
そしてこのシフトダウンを実現する上で、SWE の原則がそのまま武器になります。DMBOK（データマネジメント知識体系）から、自分が特に重要だと感じている対応をピックアップしました。
| 品質特性 | ソフトウェア設計原則 | DMBOK の対応領域 |
|---|---|---|
| 一貫性 | 単一の信頼できる情報源（SSOT） | マスターデータ管理（第10章） |
| 正確性 | シフトレフト | データ品質管理（第13章） |
| 保守性 | 関心の分離 | データアーキテクチャ（第4章） |
| 信頼性 | 明白なオーナーシップ | データガバナンス（第3章） |
| 発見容易性 | 透明性の確保 | メタデータ管理（第12章） |
| 安全性 | デフォルトでの安全 | データセキュリティ（第7章） |
- 一貫性：同じデータの定義が複数箇所に散在すると、どれが正しいのかわからなくなります。マスターを 1 つに定め、他はそこを参照する設計にすることで一貫性を保ちます。
- 正確性：パイプラインの末端で品質問題に気づくのでは手遅れです。データの入口で検証を組み込み、正確性を早期に担保します。
- 保守性：テーブル間の依存関係を整理し、一箇所の変更が全体へ波及しない構造にします。上流の仕様変更でパイプラインが壊れるリスクを、設計の保守性で抑えます。
- 信頼性：データを最もよく知るチームが、そのデータの品質と提供に責任を持つ。責任の所在が明確になることで、信頼性が担保されます。
- 発見容易性：データの所在や意味を人が探し回るのではなく、パイプラインの実行やスキーマ定義からメタデータが自動的に収集・カタログ化される状態を目指します。
- 安全性：要配慮個人情報のマスキングやアクセス制御を個々の実装に委ねるのではなく、プラットフォーム側でデフォルトとして適用する。開発者が意識しなくても安全が担保される設計です。
エンジニアが培ってきた思考法を、プラットフォームとして実装していく。AI 時代のデータマネジメントには、この視点が不可欠です。
エンジニア出身データプロダクトマネージャーのこれから
Data PdM に踏み込んだと言うと、「エンジニアやめたの？」と思われるかもしれません。
しかし、「PdM だからコードを書かない」「エンジニアだからプロダクトの意思決定はしない」という役割の壁は、もう前時代的だと思っています。AI がコードを書く時代に、人間の役割を職種で区切ること自体がナンセンスになりつつある。
実際、自分は Data PdM を名乗っていますが、SWE としての矜持はむしろ強まっています。データの設計に向き合うほど、SWE の原則の強さを実感するからです。Data PdM をやることで SWE を捨てたのではなく、SWE の考え方をより広い領域で発揮するために Data PdM という手段を選んだ、と考えています。
ただ、正直なところ簡単ではありません。Data PdM として顧客やステークホルダーに向き合う時間が求められる以上、チーム内の開発に割く時間は自分で減らす必要があります。
そのために、意図的に手を止める場面も増えました。自分がコードを書くべきだと思った場面でも、あえて「一人の開発者」として振る舞うのをやめ、AI やチームが正しく動くための仕様と制約を設計することに時間を使っています。AI がうまくいかなければ、それは実装者のスキル不足ではなく、システムの疎結合化が不十分であるというシグナルです。コードを直接修正するのではなく、AI が推論しやすいようにデータモデルを正規化し、境界を再定義する。それでも難しい場面はチームメンバーを頼ります。
だからこそ、いつでも移譲できるよう、設計意図や判断の背景を透明化することに力を入れています。
元々プログラミングが好きなので、「自分で書いた方が早い」という葛藤は今もあります。しかし、この時代だからこそコンフォートゾーンを抜け出して、自分にしかできないことに向き合うべきだと思いました。データエンジニアリングと SWE の両方をかじってきた自分だからこそ、その交差点に立って課題を見渡せる。顧客やステークホルダーに向き合う時間が増えたことで何が本当に重要かがわかるようになり、その本質的な課題を解くためにこそ、SWE のプラクティスをデータ領域へ輸入する余地は十分にあります。
おわりに
エンジニアのキャリアとして、テックリード、アーキテクト、EM、PdM といった方向性が語られます。自分は PdM を目指していたわけではなく、エンジニアリングの考え方で課題を追いかけていたら、気づけばその領域に踏み込んでいました。たまたまデータ領域でしたが、この話は領域を問わないと思っています。
データの信頼性レベルの設計、テスト観点の拡充、アラートの濃淡設計、データプロダクトとしての品質向上。やることはまだ山ほどあります。完成した話ではなく、現在進行形の話です。
AI の進化によって、エンジニアが「手を動かす人」から「何をどう守るかを設計する人」へとシフトしていく流れは加速します。自分が持っているエンジニアリングの考え方を、コードの外側にも適用していく。そういうキャリアの形もあっていいんじゃないか、と思っています。
もしよかったら@glassmonekeyをフォローしていただけると喜びます。
この記事で触れたような課題へ一緒に取り組んでくれる仲間を探しています。興味がある方はぜひご覧ください。
Discussion