イネイブリング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を実現していく場合です。
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
