【最終回】イネイブリングQAは肩代わりではなく先回り｜QA活動のスキル伝達「イネイブリングQA」

前回は、QAイネイブリングを進めた先におけるQAエンジニアの動き方・位置づけの変化についてお話しました。QAエンジニアから他のロールへの技術移転を行っていくとQAエンジニアは不要になるのか、という問いに対し、

ニーズは変化しつつも不要にはならないはず
イネイブリング後の姿を描くことが大切である

というのが私の考えです。

今回は、この「ニーズの変化」への対応や、いわゆる「この先生きのこるには」に関連して、QAエンジニア側はどうすればよいのかを考えていきましょう。

＜QA活動のスキル伝達「イネイブリングQA」　記事一覧＞※クリックで開きます

開発者へのイネイブリング圧と、QA側に求められること
- イネイブリング≠タスクの再分配
アジャイルテスターの動き方
肩代わりではなく先回りをし続ける存在がイネイブリングQA

開発者へのイネイブリング圧と、QA側に求められること

本連載の第2回で、開発者への「イネイブリング圧」について触れました。
とくに昨今は開発者に対してさまざまなロールからさまざまな知識・スキルを移転される傾向にあります。そのぶん開発者に求められることが増え、効率化しているはずが忙しくなってしまうことも多いように思います。QAエンジニア側からイネイブリング活動を行う際には、この点に注意が必要です。

そして開発者は色々なことをイネイブリングされているわけですから、「自分たちが品質に関するスキルや知識を得て業務に活かすべきなのはわかった。では、QA側はどんなスキルや知識を得て業務に活かすの？」と考えても、不思議ではありません。とくにシフトレフトを掲げてテストの実務の一部を開発者に移譲している場合などは、このような意見が出そうです。

イネイブリング≠タスクの再分配

QAから開発者にタスクが移ったのであれば、そのぶん開発タスクの一部を担ってくれよ、という気持ちを抱くのは自然です。イネイブリングとは無関係なところでも、一般にQA・テストチームができるだけ開発者を頼らず（手を煩わせず）に色々な業務ができるようにしよう、という動きは存在します。

たとえばDBへのアクセスを可能にしてもらって、テストデータの準備や環境のリセットをQA自身が行えるようにクエリの書き方を身につける、等ですね。

しかしここで確認しておきたいのは、イネイブリングはけっしてタスクの再分配ではないということです。

これまでの連載で、イネイブリングQAについて

開発チームに対して自分たちがQA業務を直接担うのではなく
従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを
開発者に移譲していく取り組みおよびそれを行うQAエンジニア

のこと、と説明してきました。

このうち、業務やタスクの実行主体を移していくことのみにフォーカスしてしまうと、イネイブリングで本来実現したいことから逸れていってしまいます。イネイブリングは知識やスキルの移転を伴う点が大事で、単なるタスクの剥離と別ロールへの再分配ではありません。

アジャイルテスターの動き方

では、QA→開発者など他ロールという一見一方通行の移転に対する直接的な回答にはなっていないように見えてしまう状況について、どのように考えればよいのでしょうか。

書籍『アジャイルサムライ』^※にはアジャイルチームにおけるテスターの動き方が出てきます。これは原著が2010年、邦訳が2011年に出版された本ですが、今回考えているイネイブリングQAに関するヒントになりそうな点が載っています。（書籍上はアジャイルテスターという表現ですが、これらの点はテスターやテストエンジニアに限らずQAエンジニアに対しても通じるものです。）

アジャイルテスターの仕事として、以下の例が挙げられています。

ユーザーストーリーのテストを書くのを手伝う
ストーリーが期待通りに動くことを確認する
テストの全体像を考える

これらの仕事は、2025年時点ではアジャイル開発か否かを問わず、QA・テストエンジニアに対して当たり前に求められている部分です。たまに「QAがテストだけをしていれば良い時代は終わった」と言われることがありますが、（そのような時代があったかどうかはさておき）主戦場とみなされがちなシステムテストに限らず、広い範囲での活動が求められます。

また、アジャイルチームにおける役割の前提として、以下のようにも書かれています。

アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりとは分かれていない。（中略）プロジェクトの成功に寄与することなら何だって協力する。肩書も役割も関係ない。もちろん、その人ならではの強みというものはある。しかし一方で、人は自分の得意分野にこだわりすぎる傾向もある。だからアジャイルプロジェクトでは、あらかじめ細かく定義された役割というものは用意しない。アナリスト。プログラマ。テスター。少なくとも、旧来の意味合いでのこういう役割は存在しないと思ってもらっていい。
アジャイルサムライ――達人開発者への道

完全に役割分担のないチーム、というのはそれほど多くはないと思います。しかし上記の記述は、2025年現在のソフトウェア開発組織やその中における役割分担に関する世の中の傾向とも合致しているのではないでしょうか。各ロールの担う範囲が拡大し、役割分担の境界が曖昧になり、まさにそれぞれが「プロジェクトの成功に寄与することなら何だって協力する」ことを求められているか、もしくはそのような状態を目指している開発組織も増えていそうです。

※アジャイルサムライ――達人開発者への道
Jonathan Rasmusson 著／西村直人・角谷信太郎監訳／近藤修平・角掛拓未訳／オーム社

肩代わりではなく先回りをし続ける存在がイネイブリングQA

ここまでの話を整理します。

イネイブリングQAの活動を進めていくと、QA→開発者という向きのイネイブリング＝知識・技術や業務の移転が行われます。だからといって逆向き、すなわち開発者→QAという向きで同じくらいの業務を移転しよう、と考えてしまうとイネイブリングで実現したい組織全体の向上からは逸れてしまいます。そのようなタスクの再分配を行うのではなく、10年以上前に『アジャイルサムライ』等で書かれていたように、各ロールの役割にとらわれずに範囲を拡大しプロジェクトのために何でも行うべきです。

イネイブリングは、皆がプロジェクトのために何でもできるように、知識・スキルを移転する活動、といえるでしょう。ここで大事になってくるのは、肩代わりではなく先回りをしよう、という発想だと思っています。つまり、たとえばテスト技法を開発者に伝えられたらイネイブリングは完了！のような区切りがあるものではなく、イネイブリングは「ずっと行い続けるもの」なのではないか、というのが今時点での私の考えです。

前回の記事および本記事冒頭でもふれた「個々のQAエンジニアが生き残るために必要なのはなにか」がまさにこの点です。これを身につければOK、という事項は存在せず、そのときどきでチームに必要な（しかしまだチームとして身についていない）ことを率先してキャッチアップし、チーム全体に対してイネイブリングすること。そしてそれを継続すること。これが生き残る方法のひとつです。

昨今は人手不足や開発組織の体制などの都合もあり、私個人の体感としては、一定規模のテスト・QA専門のチームを設ける会社の割合はあまり増えていないように感じています。結果として、イネイブリングができるQAのニーズがじわじわと増えていると思っています。

皆様の組織でQAのイネイブリング活動を行う際に本連載が参考になれば幸いです。また、ぜひ全体としてのQAイネイブリング活動自体の質向上のため、いろいろな会社での事例やナレッジの共有をいただきたいと思っています。

【連載】QA活動のスキル伝達「イネイブリングQA」記事一覧

【Sqripts編集部より】
伊藤由貴さんの連載記事『QA活動のスキル伝達「イネイブリングQA」』はいかがでしたでしょうか。
読者のみなさまからの感想や今後の連載のリクエストをぜひお寄せください！
Sqriptsお問い合わせ、または公式XアカウントのDMでも受け付けています。