こんにちは。Data Platform部に専任QAとしてジョインし、現在QAチームの立ち上げに奮闘しているokanです。
皆さんはQAチームの立ち上げと聞いて、どのような状況を想像しますか？ 「テストが全くない無法地帯に秩序をもたらす」「バグだらけのプロダクトを立て直す」…。 私も最初はそんな火消しのようなミッションを想像し、「これまでの経験を活かして、バリバリテストを回すぞ！」と意気込んでいました。 しかし、いざData Platformチームに入ってみると、そこには嬉しい想定外が待っていたのです。
今回は、すでにエンジニアの品質意識が高い組織において、立ち上げ直後のQAがどのように立ち回り、価値を出そうとしているのかという、現在進行形のリアルな試行錯誤をお届けします。
【本記事の主張（お伝えしたいこと）】
優秀なエンジニアが揃う組織において、QAはバグを見つけるテスターやプロセスを守らせる警察になっていけません。属人的な品質担保から脱却し、チームが最速かつ安全にスケールするための仕組みを作るアーキテクト（ギルドマスター）になるべきだ、ということです。
目次
- あれ？すでに品質、めっちゃ高くない？
- 警察ではなくギルドマスターへ。インテリ武闘派QAの誕生
- チームの課題を状態異常として可視化する（TCG風まとめ）
- データ品質はポーション。立ち上げた3つのKR
- 理想と現実。泥臭い試行錯誤の現在地
- おわりに
あれ？すでに品質、めっちゃ高くない？
チームに入って真っ先に驚いたのは、エンジニア陣が日常的に作成しているドキュメントと、その品質に対する解像度の高さでした。 例えば、インフラのバージョンアップの際、エンジニアから以下のような構成のドキュメントが当たり前のように提出されます。
【提出される検証ドキュメントの構成例】
- 破壊的変更（Breaking Change）の特定
- 既存設定（JMXやキャッシュ等）との互換性分析
- 各レイヤーでのテスト計画（Unit / E2E / パフォーマンス）
- 万が一問題が起きた場合のフォールバック（Cloud Tasksを用いた再実行スクリプト等の添付）
また、QAへ依頼が来る際も、単に「ここを作ったからテストして」ではありません。 変更内容とセットで、想定する影響範囲とリスク、なぜ問題ないと言えるのかの技術的根拠、さらには万が一問題が起きた場合のフォールバック（復旧手順や影響の極小化）までが表形式で言語化されています。それをベースに、stg環境で何をテストすべきかがエンジニア側からすでに提案されている状態だったのです。さらに、エラー発生時のリトライやリカバリ手順も、誰でも実行可能なレベルでスクリプト化・手順化されていました。
これは本当に素晴らしいことですよね。しかし、同時に立ち上げを任された私は強い焦りを感じました。
ここまでエンジニア自身でリスク評価とテスト設計を高いレベルで完結できる組織で、私が単にテスト設計・実行する人になっても、全くバリューを出せないぞ…？
エンジニア個々人の高い意識によって品質が担保されている状態は、見方を変えれば属人性が高い状態でもあります。QC（品質管理）の観点から見ると、人の注意力に依存するプロセスは、組織がスケールした際にヒューマンエラーによるばらつきを生みます。 私は自らの役割を従来のいわゆるQAから、専門知識を活かして人ではなく仕組みで解決するアーキテクトへと再定義する必要がありました。
警察ではなくギルドマスターへ。インテリ武闘派QAの誕生
そこで私は、自らの立ち位置をインテリ武闘派QAと名付けました。
- インテリQA（マーケター視点）
市場や顧客の声を分析し、「そのデータは誰が、何の意思決定に使うのか」というデータリネージの最下流（価値）から逆算して、無駄な開発を防ぐ視点 - 武闘派QA（技術・伴走視点）
シフトレフトを実践し、コードレベルの技術的な会話を通じてチーム全体での品質向上を主導する品質の伝道師
QAがいないのが当たり前だった組織に、いきなり正論を振りかざして武器を取り上げる警察になっても、現場は引いてしまいます。私が目指したのは、開発者に最強のバフ（品質保証）をかけるギルドマスターとしての振る舞いでした。
「この設計で罠にかからない？」と地図（Design Doc）を持ち込んでくれれば一緒に罠を探し（＝アーキテクチャレビューでのエッジケースや非機能要件の抽出）、「リリースが怖い」と言われれば自動テストという結界を張る（＝CIパイプラインへのE2Eテスト自動実行の組み込み）。 そんな関係性を築くための第一歩として、お互いのことを知り、課題を共に解決していくことを願い、まずは各チームとざっくばらんに話す会を開催しました。
チームの課題を状態異常として可視化する（TCG風まとめ）
実はこのヒアリングを通して、もう一つ見えてきた組織の課題がありました。それはチーム間の横の繋がりです。 各チームが高度な専門性を持っているからこそ、開発の終盤になって他チームとの認識が噛み合っていないことが発覚するなど、コミュニケーションのすれ違いによる手戻りが発生しており、非常にもったいないと感じる場面があったのです。
お互いの強みを最大限に活かすには、まず部全体が他チームの特性や現在の課題を楽しく知るきっかけが必要だと考えました。 そこで、ヒアリングした内容をただの議事録（テキスト）で共有するのではなく、自身の愛犬をモデルに、QA TCG（トレーディングカードゲーム）風にまとめて各チームに展開したのです。
単なるお遊びではなく、チームの特性を以下の5つのパラメータに分類・言語化するフレームワークとして活用しています。チームの強みと課題を切り分けることで、QAがどこに介入すべきかが明確になります
- 属性 / クラス：チームの役割（例：Platform, AI Researcherなど）
- HP / MP：チームのリソース状況や、技術的な尖り具合
- 特殊能力 (Skill)：そのチームならではの強みや特徴
- 状態異常 (Debuff)：今抱えている課題や悩み（ボトルネック）
- 召喚コスト (QA Request)：QAにしてほしいこと（＝QAが支払う工数）
【TCG化例】
この遊び心を取り入れた取り組みにより、単なるテスト実行者ではなく、チームごとの特性を理解して一緒に状態異常を治してくれる仲間として認識してもらう良いスタートダッシュが切れたはず…？きっと。
データ品質はポーション。立ち上げた3つのKR
チームごとの課題が見えてきた今、ようやく私の持っているソフトウェア品質の専門知識（JSTQB、JCSQE、IT検証技術者など）を解決策として落とし込むフェーズに入っています。
私はデータ品質をRPGのポーションに例えてチームに浸透させようとしています。ボス戦の最中に飲んだポーションが期限切れだったり、毒だったりすれば全滅してしまいます。 そして、その品質を改善するためには、まずは現状を正しく測定・定義するしかありません。属人化を排除し、誰もが安心して開発できる仕組みを作るため、QAチームのロードマップとして以下の3つのKR（Key Result）を策定し、実行に移し始めました。
- KR1: データ品質の共通言語を定義し、設計プロセスへ導入する
「品質とは何か」「どう記録するか」というルール作りです。なんとなくの勘で行われているテスト設計に対し、同値分割や直交表などの専門性を注入しつつ、スキーマ変更時の影響範囲特定やデータ鮮度（Freshness）の許容値などを盛り込んだTestDocのテンプレート化を進めています。また、起票ルールやバグ管理のフォーマット統一を行うことで、ステークホルダー間の認識のズレをなくし、属人化の解消を目指しています。
- KR2: 部全体が異常にすぐ気づける基準を確立する
「本当にこれで出して大丈夫か？」という疑心暗鬼を払拭するため、定量的な基準を作ります。具体的には、データのサイレントな不整合を検知した際のリリース判定Gatekeeper基準や、Bugfix/Hotfixの優先度を判断するトリアージラインの策定です。ゆくゆくはSLO/SLAなどの稼働水準策定や、異常検知後のインシデント対応の整備まで踏み込みたいです（自称インシデント大臣として腕の見せ所です！）。 - KR3: 変更時の事故を防ぐ開発ガードレールの運用を開始する
不具合の流出を物理的・システム的に防ぐため、通常開発・リリース承認・Bugfix・Hotfixそれぞれのワークフローを明文化し、安全な手順を整備しています。また、変更によるデグレを防ぐためのリグレッションテスト項目の作成やテストデータの準備など、実際に手を動かす泥臭いプロセスにも着手しはじめています。
理想と現実。泥臭い試行錯誤の現在地
と、それっぽいことを書いていますが、現実は泥臭い試行錯誤の連続です。Data Platform特有の技術コンテキスト（ETL、分散処理、BigQueryの複雑なクエリなど）のキャッチアップに必死で、最初はエンジニアの書いた高度な影響範囲分析のレビューに全く歯が立たないこともありました。 また、仕組み化を急ぐあまり、ガチガチの承認フローを提案してしまい「それだとリリースの速度が死ぬ」とエンジニアからフィードバックをもらったこともあります（猛省）。開発のアジリティ（速度）を落としてしまわないよう、「この変更はリスクが低いからQAレビューをスキップする」といったリスクベースでのエンジニアとの責任分界点を日々探り合っています。
おわりに
品質意識がすでに高い組織における、QAチーム立ち上げのミッション。 それはゼロからテストの文化を作ることではなく、すでに存在する優れた文化をスケールさせるための、揺るぎないQAプロセスの礎（いしずえ）を築くことです。
もし皆さんの組織が「エンジニアの品質意識は高いけれど、属人化やリリースの重さに悩んでいる」のであれば、まずはQAが警察ではなくギルドマスターとして現場に入り込み、チームの状態異常を可視化することから始めてみてください。きっと、エンジニアたちは最高の協力者になってくれるはずです。
まだまだ手探りの状態ですが、これからもインテリ武闘派QAとして、Data Platform部という最強のパーティの価値最大化に貢献していきたいと思っています。
※すでに品質が高い組織を仕組みでさらにブーストさせるという挑戦にワクワクした方、ぜひ一度ざっくばらんにお話ししましょう！
