はじめに
こんにちは、estieでQAエンジニアをしている macho です。
先日、アーキテクチャConference 2025 に弊社開発組織のメンバーと登壇してきました！
「アーキテクチャConferenceにQAエンジニアが出るの珍しいね！」現地でそんなリアクションをいただいたこともあり、改めてブログに残したいと思ったので書いてみます。
この記事は以下の3本立てでお届けします。
- カンファレンス登壇内容の紹介
- estieでQAがデータ品質に向き合う意義
- これからデータ品質領域で取り組みたいこと
アーキテクチャConference とは？
その前にアーキテクチャConferenceについて簡単に説明しますと、その名の通りソフトウェアや組織の「アーキテクチャ」にフォーカスした技術イベントです。
私自身初参加だったのですが、技術の変化が加速し組織やツールが多様化する中で「最適なアーキテクチャをどう描くか」について各社事例ベースでリアルな知見を共有する場となっていました。
詳細は 公式サイト もチェックしてみてください。
登壇内容について
今回estieは「マルチプロダクトを支えるスケーラブルなデータパイプライン設計 〜速度と品質を両立するチームと技術〜」というテーマで以下3名でグループ登壇をしてきました。
詳細については当日の スライド を公開しておりますので合わせてご覧ください！
これまでのチーム変遷とマルチプロダクト化の課題 (丸島さんパート)
このパートでは、estieがこれまでどのようなアーキテクチャの変遷を辿ってきたのかについてお話ししています。
1.プロダクトが少数だった時代は、データ開発もアプリ開発も1つのチームでまるっと担当していた
2.メンバーのスキルスタックの偏りから自然と「データ開発を中心に行う人」と「アプリ開発を中心に行う人」が分かれ始める
3.プロダクトの増加に伴いデータ開発とアプリ開発が事業部として分割される
- 分割した結果メリットもあったが新たな課題も見えてくる
スケールするデータパイプライン開発(Linさんパート)
このパートではマルチプロダクト展開を進める中で、チームが分割したことで低下した開発効率をどう解消していったかについてお話ししています。
- 秘匿データは分離した上でデータパイプラインを 社内オープンソース化 し、アプリ開発チームがコミット可能な状態を作る。
- データパイプラインの開発に必要な知識はデータチームがenablingしていく
- その結果…
- アプリ開発チームもパイプライン開発にコミット可能になり開発はスケールするようになった🎉
- 一方で取り扱うデータの種類や量が増えたことでデータ品質の担保が新たな課題として浮かび上がる…
QAの品質向上に向けた取り組み(machoパート)
このパートでは、Data as a Serviceの特性上サービスのコアであるデータにコミットできていなかったQAの私がデータチームとコラボレーションによりどのようにデータ品質に貢献し始めたかについて話しています。
データ品質の取り組みは以前別のブログにまとめているので こちら も合わせてご覧ください！
- データチームとのコラボレーション以前の私の担当領域
- データパイプライン領域の不具合が目立つようになってきたことでデータチームとコラボした対応を開始
- QA主導で、プロダクトチームに蓄積したドメイン知識を活用しプロダクトとして担保したいデータコントラクトを整備
- ここでいうデータコントラクトとは、データ提供者(データパイプライン)と利用者(アプリケーション)間で交わされる契約で、基本的には利用者側が求めるデータの状態を定義し提供者側との合意により決定し、データパイプライン内にテストとして実装されます
- データチーム主導で、生成されたデータがデータコントラクトに違反した場合にプロダクトのデータ更新を遮断する仕組みであるサーキットブレーカーの導入
- QA主導で、プロダクトチームに蓄積したドメイン知識を活用しプロダクトとして担保したいデータコントラクトを整備
- データ起因での異常を検知し、プロダクトデータに意図しない更新をしないことでインシデントを未然に防げる体制ができた🎉
まとめ
これらの活動によりいくつかの課題が解決に向かいはじめました🎉
- データパイプラインの開発がスケールしない → パイプラインの社内オープンソース化により、プロダクト側も巻き込んで開発できるようになった
- データ品質の担保が追いつかない → データコントラクト＆サーキットブレーカーの導入により、データ異常検知とインシデントの予防ができるようになった
一方で、まだ解決していない課題も残っています。
- データパイプラインの実行はスケールしていない（処理時間が延びてきている）
- データテストも完全ではない（偽陽性対応や、異常時の原因調査の難しさ）
- データのデグレは防げるようになってきたが、「もともと汚れているデータ」が自動的に綺麗になるわけではない
これらの課題にも引き続き取り組みながらスケーラブルなデータパイプラインをアップデートし続けていきたいと思います。
estieでQAがデータ品質に向き合う意義
今回の登壇を通して、改めて「estieでQAエンジニアがデータ品質に向き合う意義」を考えてみました。
私が所属しているマーケットリサーチ事業本部では、複数のData as a Serviceプロダクトを提供しています。
各アセットタイプごとに、建物情報・募集賃料・テナント情報など、とにかく大量のデータを扱っています。
かつ、この手のプロダクトではフロントエンド・バックエンドが不具合なく正常に動いていても、データの欠損や誤りがユーザーへの提供価値を大きく低下させてしまう 場合があります。
以前書いたブログでも触れましたが極端な例として、建物の削除判定に使われるカラムが何かのきっかけで全てtrueになってしまった場合、サービス上から全てのビル情報が消えてしまいユーザーが利用できない状態になってしまいます。
ここまで極端でなくても、データソースの変更やデータパイプラインのロジックミスによりユーザーの価値を毀損させてしまう可能性は常に存在します。
こういったケースは、アプリケーションのテストだけで守り切るのは難しい領域です。
なぜ QA がやるのか？
一般的には、パイプラインで生成されるデータの責務はデータチームが持つことが多いと思います。
実際、estieでもデータチームがオーナーシップを持っています。
一方で、estieのアプリ開発チーム（QA含む）はビジネスサイドとの垣根が低く、ユーザーに近い距離で開発している、という特徴があります。
- ユーザーが実際にどんな使い方をしているかを把握しやすい
- プロダクトのどのデータが「ビジネス的にクリティカルか」を把握している
さらにQAは、複数のプロダクト開発に一部横断的に携わっているため、この「ユーザー理解」と「ドメイン知識」へアクセスしやすいポジションにいます。
- どのデータにどんなテストを書くべきか
- どのレベルの異常なら更新を止めるべきか
といった品質基準を整える役割を、QAがやることに意義があると感じています。
これからデータ品質領域で取り組みたいこと
今回の登壇でお話ししたデータ品質の取り組みとしてはまだ道半ばで、ここからまだまだやりたいことがあります。具体例をいくつか挙げてみると
1. サーキットブレーカーの横展開
データチームが作ってくれたサーキットブレーカーはデータインシデントの予防に有効です。
すでに導入が進んでいるプロダクトも存在するものの、そこまで手が回らず未導入のプロダクトも存在します。
新規機能開発をガンガン進めているプロダクトフェーズにあるチームでは、導入が後手に回ってしまうケースも想像されるためそこをQAが拾うことで導入の推進していきます。
2. 導入後の運用改善
とはいえ、導入後の運用はプロダクトチームの責務でもあります。
現在は、誤検知により一時的にデータ更新が停止するリスクより、不具合を見逃してデータ品質が低下するリスクを重視 した運用をとっているため偽陽性が時々発生してしまいますがこの状態を長く続けてしまうと運用疲れに繋がってしまうためいくつかの改善活動を進めていきたいと考えています。
- 偽陽性を減らすための適切な閾値チューニング
- 重要度の低いテストを無作為に増やさないためテスト精査
- 異常検知時の調査を楽にするための改善
- 調査に役立つメタデータやツールの整備、調査およびトリアージフローの整備
3. データテストにより見えてきた汚れたデータの改善
こちらはサーキットブレーカーとは異なり、データの正確性よりの改善です。
サーキットブレーカーの導入によりデータ品質の低下を防ぐことはできるようになってきた一方、データ品質が向上したわけではありません。
データコントラクトの整備により汚れた(正しくない可能性の高い)データが徐々に可視化されてきているので改めてそれらのデータを修正していくことでデータ品質の向上を図りたいと考えています。
estieのQAチームについて
ここまでデータ品質にフォーカスして話をしてきましたが、estieのQAチームは「プロダクトの信頼性」と「組織の生産性」への貢献を職務としています。
開発組織はPdMやデザイナー等を含めると50名を超える規模で、扱っているプロダクトは10個以上存在します。現在も新規プロダクトが続々と立ち上がっています。
そのような開発組織の中でQAは現在3名体制と少数チームです。
1つのプロダクトに深く関わるフェーズもあれば、横断的に複数プロダクトへ関わるフェーズもあり、その時々で組織が抱える課題に合わせて、関わり方を柔軟に変えていけるチームでありたいと考えています。
今回取り上げたデータ品質改善も課題の一つとして、引き続きデータチームとコラボレーションしながら取り組んでいく予定です。
最後に
ここまで読んでくださり、ありがとうございます。
estieは一緒に働く仲間を探しています。
今回の登壇やQAチームの活動に少しでも興味を持っていただけましたらぜひカジュアル面談しましょう！
下記フォームからでも、XのDMからでも、お気軽にご連絡ください！
