前回の連載では、1人目QAとしてチームを立ち上げていく部分、組織づくりに関する内容についてお伝えしました。
筆者はQAエンジニアとして業務をしていますが、特定の開発チームに所属してテスト業務や品質改善を行っている、という動き方が中心ではありません。どちらかといえば、開発チームに対して外から関わり、開発者へのテスト・QA技術の伝達や、効果的に品質向上ができるような支援を行っています。
こうした関わり方について、他社のQAの方から「自分たちもそのような形を目指しているが、うまくいかない」「ヒントがほしい」といった声をいただくことがあります。そのため、自分なりの取り組みについて語ることも意味があるだろう、と思い今回連載のテーマとして選びました。
本連載では、QAチームを立ち上げている間もしくはチームが形になってきたあとで、実際に開発チームに貢献する形の1つとしての「イネイブリングQA」の概念と、メリットや注意点についてお伝えしたのち、開発組織に品質技術を根付かせたその先の姿についても考えてみたいと思います。
「自社でもイネイブリングQAを目指しているものの、開発チームとの連携がうまくいかない」「どのように品質技術を伝達すればいいか具体的な方法がわからない」といった課題を持つQAエンジニアの皆さんへ、本連載が解決の糸口となることを願っています。
イネイブリングQAとはなにか
まずはじめに、イネイブリングQAという概念についてご説明します。
イネイブリングQAというのは厳密に定義された用語ではありませんが、私の観測範囲では2023, 4年ごろから用いられているようです。
- なぜQAエンジニアがSLO導入をリードしたのか – tebiki_techblog
- SmartHRのライティング組織の3つの役割｜otapo
- チームメンバー全員で品質を向上させる。タイミーのQA EnablingTeamとは？｜Timee
私の考えるイネイブリングQAは、このあとご説明するイネイブリングのスタイルで業務にあたっているQAエンジニアおよび業務そのものを意味しています。
ITエンジニアの界隈で「イネイブリング」という言葉が使われるようになったのは、『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』がきっかけでしょう。
■チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
（マシュー・スケルトン 著／マニュエル・パイス 著／原田 騎郎 訳／永瀬 美穂 訳／吉羽 龍太郎 訳／JMAM）
この書籍は開発組織のチーム構成を「ストリームアイランドチーム」や「イネイブリングチーム」などの概念で説明していて、イネイブリングチームは以下のように書かれています。
イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。
イネイブリングチームはスペシャリストで構成される小さくて長続きするグループで、ある時点では１チームもしくは少数のチームだけ担当し、チームの能力と認知を向上させることに集中する。
『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が出版されたのが2021年末（※原著は2019年に出版）なので、日本で目にするようになったのはここ数年の間です。
この「特定ドメインのスペシャリストが、開発チームの能力ギャップを埋めるのを助ける」という概念、すなわち開発チームになんらかの技術を伝え身につけてもらうという動き方を私は「イネイブリング」と捉えていて、この概念をQAに当てはめたものを「イネイブリングQA」と読んでいます。
整理すると、イネイブリングQAとは
- 開発チームに対して自分たちがQA業務を直接担うのではなく
- 従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを
- 開発者に移譲していく取り組みおよびそれを行うQAエンジニア
のことです。たとえば、テスト設計技法やテストプロセスに関するナレッジをまとめて開発者に対してレクチャーを行うなどの活動が該当します。
イネイブリングQAという呼称自体は新しいものの、その概念は以前から存在しており、たとえば1999年出版の『Automated Software Testing』（邦訳：『自動ソフトウェアテスト 導入から、管理・実践まで 効果的な自動テスト環境の構築を目指して』）に登場する「システム方法論およびテスト（SMT）チーム」の活動と共通点が見られます。
SMTチームの活動として
チームメンバーは、次から次へとさまざまなプロジェクト開発チームの主任と一緒に作業をして、知識移転、その他の活動を遂行する。
と述べられており、私はイネイブリングQAに近い概念だと捉えています。
このように、イネイブリングQAという呼称自体は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』をきっかけに徐々に出てきている状態ですが、その概念や考え方自体は以前からあるもののようです。
開発組織とQAとの関わり方をイネイブリングQAに転換する動き
イネイブリングQAのような形での開発組織への関わり方を目指すのは、どのような理由からなのでしょうか。
ひとつには、採用や体制面の都合があると見ています。
最近はITエンジニア全般的に採用が大変だ、という声を耳にします。QAエンジニアも同様で、募集を出しているけれどもなかなか集まらない、という会社さんもあるようです。システムテストなどテストの実務的な部分を担うエンジニアを、それに足るだけの人数採用するというのは、かなり大変です。そうなると、テスト・QAエンジニアだけではなく、開発者自身がテスト等の業務も行うような業務設計にならざるを得ません。
実態としては、このような会社ではもともと開発者自身でテストなどの品質関連の業務を行っているか、もしくは外部のテスト会社の力を借りている場合が多いようです。とくに前者の場合、内製のQAエンジニア組織を立ち上げることになったとしても、開発者が主体となって品質関連の業務を行っているというメリットは活かしたまま、QAエンジニアを採用してイネイブリングを中心とした活動を行うのは理にかなっていると思われます。
他のパターンとしては、開発組織の中にテスト・QA組織がすでにあるものの、開発効率や品質意識の向上を目指してイネイブリングQAにシフトしていきたい、という場合もあります。
開発チームとテスト・QAチームがある程度別れており、開発プロセスにおいて「後工程での品質担保」が常態化してしまっている場合があります。このような組織では、シフトレフトを目指して開発者を積極的に品質向上に巻き込んでいくため、QAチームの業務をイネイブリング主体に切り替えようという動きが出てきます。
上記のような理由で、QA組織の動き方、とくにテストに関連する部分の動き方を「自分たちがテスト計画から実行・報告までをすべて担う」から「開発者がそれらの活動を行うのを助け、技術移転する」というイネイブリングQAへの転換をする動きが見られています。
今後の連載トピック：イネイブリングQAの課題と考慮すべきこと
このあとに続く連載の各回では、以下のトピックについて触れる予定です。
- イネイブリングの注意点
- イネイブリングに必要なスキル
- イネイブリングした先の姿
- QAは何をイネイブリングされたらいいのか、イネイブリングすることと引き換えに何をするのか
先に挙げた組織課題などに対する解のひとつとしてイネイブリングQAを志向し、実現に向かって動いているQA組織もあるようです。しかし、「QAは手を動かしません」「開発者や他のロールの皆さんを中心に品質を担保します」と宣言するだけでは、おそらくうまくいきません。
「開発者がテストの重要性を理解してくれない」「品質向上に必要なスキル習得に時間を割けない」「QAチームが単なる『口を出すだけの存在』と見なされてしまう」といった問題も発生する可能性があります。
今後の連載においては、そうしたイネイブリングQAを進めていくうえでの注意点や、必要となるスキルについてご説明し、イネイブリングQAを進めた先で我々QAエンジニアはどうなるのかについて考えていきます。
