QAは「最後の砦」だけじゃない。「開発をドライブする」エンジニアを目指して
はじめに
みなさん、QA活動していますか？ 私は普段、エンジニアとして開発業務に携わりながら、並行してチームのQA周りの改善にも取り組んでいます。最近は、フロントエンドからサーバーサイドまでを一気通貫するE2Eテストを整備するなど、開発とQAの隙間を埋める動きで、品質向上に貢献できればと活動しています。
実は以前、専任のQAエンジニアとしてプロジェクトに参画していた時期があります。 当初はテストケースの消化や検証が主な役割でしたが、「仕様のこの部分、矛盾していませんか？」「この要件だと後で手戻りになりませんか？」と、開発の前段階から積極的に意見を出すようにしたところ、プロジェクトの進行が劇的にスムーズになり、気づけばPjMに近い役割を任されるようになっていました。
この経験を通じて、 「QAは単なる受入確認部隊（Gatekeeper）ではなく、開発そのものをドライブする推進役（Navigator）になれるのではないか？」と感じるようになりました。
今回は、私が試行錯誤しながら実践している「シフトレフト」の考え方と、現場を少しずつ良くするためのアプローチについて整理してみたいと思います。
QAエンジニアの役割とは？
そもそも、QAエンジニアの役割とは何でしょうか？
「バグがないことを証明すること」や「バグを見つけて報告すること」はもちろん重要です。
ただ、それだけだと少し受動的で、もったいない気がしてしまうのです。
私は、「QAエンジニアこそ、要件定義や設計の段階から関わり、手戻りを防ぐ『案内役』になれる」と考えています。
ご存知の通り、バグ修正のコストは後工程になればなるほど指数関数的に大きくなります。
だからこそ、テストフェーズでバグを見つけるだけでなく、もっと前の段階——要件定義や設計の段階——から入り込み、品質を作り込む「シフトレフト」が大切だと感じています。
大切にしたい「違和感」と「技術力」
シフトレフトを実践し、開発をスムーズに進めるために、私が意識していること。
それはホワイトボックステストに近い視点を持つことです。
QAの現場では、仕様通りの挙動を確認する「ブラックボックステスト」が基本になることが多いですが、それだけだと見落としてしまうリスクがあります。
私が大切にしているのは、うまく言語化できないのですがバグりそうな臭いや将来困りそうな予感といった、エンジニアとしての直感的な違和感です。
- 「このデータ構造だと、排他制御周りでトラブルが起きそうだな」（即時的なバグの予感）
- 「Phase 1の要件は満たせても、この設計だと次期フェーズの機能拡張で苦労しそうだな」（拡張性の懸念）
- 「ユーザーの要望は今後こう変化していくはずだから、今の作りだとそれに対応できなくなるかもしれない」（中長期視点）
こうした「臭い」は、過去の失敗経験や機能の特性から来るものですが、その裏付けにはやはり技術への理解が必要だと感じています。
アプリケーションの構造やDB設計、そしてビジネスの方向性を理解していないと、この「ホワイトボックス的な勘」はなかなか働きません。
「QAエンジニアはどこまで技術に詳しくあるべきか？」
正解はないと思いますが、私はDB設計やアプリ設計の違和感に気づけるレベルを目指すことで、開発者と同じ目線で議論ができ、結果として手戻りを防ぐことに繋がるのではないかと考えています。
現場を変える魔法「クイックウィン（小さな成功体験）」
とはいえ、いきなり「明日から設計レビューに入らせてください！」「シフトレフトしましょう！」と提案しても、現場はなかなか動きません。
新しいことを始める時って、どうしても「工数がない」「今のままで十分」といった不安や戸惑いが生まれるものです。
私自身、過去に理想を高く掲げすぎて、うまくいかなかった経験があります。
はるか遠くのゴールを目指して壮大な計画を立てると、途中で「他に急ぎのタスクが……」といった事情で後回しになり、結局立ち消えになってしまうのです。
だからこそ、最近はクイックウィン(小さな成功体験)を積み重ねることを大切にしています。
「2時間」なら、最初の一歩が踏み出せる
具体的には、改善タスクを「2時間程度で終わるサイズ」まで小さく切り出して提案するようにしています。
「数日かかる改革」と言われると身構えてしまいますが、「2時間」なら「ちょっと隙間時間でやってみようかな」と思えますよね。
2時間なら、ペアプログラミングで相談しながら一気にやり切ることもできます。
まずは自分で動いて、サクッと小さな成果を見せる。「あ、これなら意外と簡単だね」「便利になったね」と実感してもらうこと。
この小さな「できた！」という成功体験こそが、チームの空気をポジティブに変え、やがて大きな変化へのきっかけになっていくと信じています。
信頼を武器に、開発をドライブする
クイックウィンでチームの信頼を得られたら、いよいよ本格的な「ドライブ」の始まりです。
具体的に、私が新規開発と保守開発それぞれのフェーズで意識している動き方をご紹介します。
1. 新規開発フェーズ：三位一体で「設計の隙間」を埋める
新規開発フェーズでは、QAが開発をドライブする余地が大きくあります。
私が理想的だと感じているのは、PdM（プロダクトマネージャー）、エンジニア、そしてQAが連携する形です。
- PdM： ユーザーの要求定義、経営課題の解決策立案（What/Why）。
- エンジニア： 技術的な解決策の検討（How）。システム関連図、ドメインモデル図、ER図などの作成。
- QA： 二者の意図を汲み取りながら、システムの全体像をイメージし、細部を詰める。
PdMの「やりたいこと」とエンジニアの「設計図」の間には、どうしても認識のズレが生まれます。
そこでQAが、エンジニアの描いたER図を一緒に見ながら、「このデータ構造だと、あのユースケースで矛盾しませんか？」と問いかける。
抽象的な「要求」と具体的な「実装」の間を埋めるパズルを一緒に解いていくことで、手戻りを劇的に減らすことができます。
2. 保守開発フェーズ：AI×QAで「生きた仕様書」を取り戻す
保守開発での課題は、「動いているが、細部の仕様がドキュメント化されていない」ことです。
仕様がコードの中にしかなく、属人化している。これを解決するために、最近はAI（Gemini 3.0やCloud Code）を活用したリバースエンジニアリングに取り組んでいます。
AIにコードを読ませて、仕様やシーケンス図の下書きを出力させるのです。
もちろんAIはハルシネーション（嘘）をつくこともあります。しかし、ここでQAエンジニアの知見が活きます。
普段の動作検証で仕様を深く理解しているQAなら、AIが出したドキュメントを見て「あ、実際の挙動と違う」「ここは重要な例外処理だ」とすぐに気づき、修正できるからです。
AIが下書きを作り、QAが魂（正確性）を吹き込む。 このプロセスで、メンテナンス性の高いドキュメントを効率よく整備することができます。
おわりに
QAエンジニアは、決して開発の下流工程で待ち構えるだけの存在ではありません。
技術的な視点で設計や将来の拡張性にまで気を配り、小さな改善（クイックウィン）でチームを盛り上げ、プロジェクト全体を前に進める。そんな働き方ができれば素敵ですよね。
もし皆さんが「今のやり方でいいのかな」とモヤモヤしているなら、まずは明日の2時間を使って、小さな改善を一つ試してみませんか？
その一歩が、プロジェクトを、そして皆さん自身のキャリアを少しずつ変えていくかもしれません。
Discussion