イネイブリングQAについての連載、今回は第2回となります。
＜QA活動のスキル伝達「イネイブリングQA」 記事一覧＞※クリックで開きます
第1回では、イネイブリングQAということばの私なりの定義や、QA組織をイネイブリングチームの形に変えていく動きについてお話しました。
今回は、イネイブリングQAを目指すうえでの注意点について解説します。
イネイブリングQAの背景（おさらい）
QAのイネイブリングとは
前回の記事で詳しく説明した通り、イネイブリングQAとは：
- 開発チームに対して自分たちがQA業務を直接担うのではなく
- 従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを
- 開発者に移譲していく取り組みおよびそれを行うQAエンジニア
のことです。
つまりイネイブリングQAは、QAエンジニアが持っているテスト・品質関連のスキルや、場合によっては実務の一部を開発者に移譲していく動きになります。組織全体や開発サイクル、プロダクトのことを考えたときに、そのほうがメリットが大きいと判断しているわけです。
QAエンジニアの界隈でも、「QAエンジニアやテストエンジニアだけが品質に対して責任を持つわけではない。全員で品質を高めよう！」などと言われたりします。そのためには、開発者にも品質のことを知り、担ってもらう必要があるというのは自然な流れでしょう。
開発者が抱える「イネイブリング圧」の現状
開発者を取り巻く厳しい状況
このようなイネイブリングの動きは、QAに関することだけではありません。
たとえばSRE（Site Reliability Engineering）の文脈でも、開発者に対するイネイブリングが行われています。
SREの他にも、開発者に対しては
- DevOps推進：開発と運用の統合
- AI活用推進：AIエージェント活用と定量改善成果の要求
など、さまざまなスキルや知識を身に着け、改善することが求められています。
これらの取り組みは、個々に見ていくと当然やったほうが良いことであり、意義のあることです。
しかし開発者を取り巻くこの状況は、例えるならばあなたのもとに「管理栄養士です！」「フィットネストレーナーです！」「ファイナンシャルプランナーです！」「メンタルコーチです！」「「「「さあ、豊かな人生のためにがんばりましょう！」」」」と言われているようなものです。そう考えてみると、かなり厳しい状態に追い込まれていますよね。
イネイブリングをする側は皆、「自分たちの持っている知見や技術を伝えて、組織全体を良くしたい」という思いを持っています。しかし、それを受け取る側にも事情やキャパシティがあり、すべてをこなしていくのは困難です。
このような状況を踏まえると、イネイブリングQAを進める際には、開発者の負担を考慮した慎重なアプローチが必要になります。
具体的な注意点：どのように進めるべきか
イネイブリングに重要な視点
開発者や開発組織は、さまざまな「イネイブリング圧」の下にある可能性がある。このような前提で、開発組織にアプローチしていかなければならないと、私は考えています。
そこで大事になるのは、開発者や開発組織を楽にする・効率的にするという視点です。
イネイブリングに限らず、なんらかの改善施策というのは、一時的な負担増を伴う場合があります。いままでのやり方を変え、新しいやり方をキャッチアップしなければならないとなると、当然ながら学習のための時間が必要です。また、変化に対しては心理的な負担も発生します。
とくに注意が必要な組織形態
とくに丁寧な動き方が求められるのは、開発チームとQA・テストチームという形でそれぞれが別のチームとして業務分担がなされている組織で、イネイブリングQAを実現していく場合です。
QAチームが行っていたテストの一部を、開発者により早いタイミングで実施するように開発プロセス自体を変更する、といった施策も考えられます。
開発チームからすると「なぜ今までQA側でやっていたことを開発側でもやらなければならないんだ」と反発したくなるかもしれません。単純にQAチームの仕事が減り、開発チームの仕事が増える、という見え方をしてしまうとこのような誤解につながります。
そうではなく、
- 最終的には今より楽になる
- 手間は増えるけれどもそれ以上のリターンが見込める
など、開発チームにとってのメリットをまず理解してもらうことが重要です。
事例：開発チームにテスト分析・設計を取り入れる
ある開発組織では、開発者が各テストレベルのテストを考え、実施していました。しかし、テストベースからそのままテストケースを導出するやり方で進めており、テストの充分性や「そもそもこのやり方で合っているのか」といった疑問を抱えていました。
そこで、イネイブリングQAから「テストケースを考える際には、何をテストするか→どうテストするかの順で段階的に考えましょう」というアドバイスを行い、テスト分析・設計相当の活動を取り入れました。
テスト実装前にテスト設計とレビューが追加されることになり、一見手間が増えるようにも見えます。しかし、いきなりテストケースを作成したあとにレビューで網羅性などを確認する負担と比べ、設計→レビュー→実装と進めたほうがレビュワーの負担が軽減されることを説明し、実践。実際に開発チームのリーダーからは「レビューがしやすくなった」というフィードバックが得られました。
このエピソードでは、あくまでもテスト分析・設計「風」の活動を取り入れたにとどまっています。しかし、QAエンジニアと同等のやり方をいきなり開発者に求めるのではなく、まずは簡易版としてのプラクティスを導入し、必要に応じてやり方を強化していくというのも有効だと考えています。
まとめ：今後の展望
本記事では、開発組織におけるイネイブリングがQAのみならず多方面から行われていることや、その中でイネイブリングを進めるうえで重要な視点についてお伝えしました。
イネイブリングQAを進めることで開発組織全体にメリットがあるのはもちろんですが、現場の開発者にとってもメリットがないとなかなか進みません。
メリットを実感してもらうためには、たとえば
- 口を出すだけでなく、手も動かす。QAが自分たちから動いて、課題などを引き出し、解消していく。
- 開発とQA両者のニーズをつなげる。開発チームの課題を解決することと、イネイブリングQA側がやるべきだと思っていることを結びつけ、取り組む。
- 楽になる未来を見せつつ改善を進める。
などが必要になってくるでしょう。このあたりは、次回以降の記事でも触れていく予定です。
