昨日書いたブログ イネイブられたいと思っている開発者は居ない前提で動く - テストウフ の続きです。
QAエンジニアが開発者含む他のロールに対して、QA活動（の一部）ができるようイネイブリングしてく際に、自分たちから進んでアプローチしていかなければならないよね、という話を前回書きました。
これは「そうだね」と思っていただけるのではないでしょうか。そんなに変なことは言っていないつもりでした。
ただ、そこで終わりではないとも思っています。
QAエンジニアから開発者や他のロールにイネイブリングをするということは、ミクロな視点で考えると、開発者たちにとってはやることが増えるわけです。今までよりも覚えることや考えることが増えます。
しかも、昨今「イネイブリングだ！」と言って活動しているのはQAだけではありません。SREなども開発者に対するイネイブリング活動をしているようです。
※これまた少し前にブログに書きました＞イネイブリングQAのヒントをSREに見た - テストウフ
DevOpsも「運用と開発の垣根をとっぱらって、開発者も運用わかる・できるようになろう！」的話が出てきますし。このあたりは『システム運用アンチパターン』を読もう。
この状況、素直に考えると開発者ってかなり大変じゃないですか・・・？
あっちからもこっちからも「開発者もできるようになってね！」という圧が飛んでくる状況。「ホリスティックテスティングがイマドキだよね！」と言って常にテストだと言われる。＞Testing from a holistic point of view - DragonFire Inc.
もちろん、開発者にとってもメリットがあるという理屈はこねられます。テストをうまくやることによって手戻りを減らし、今までよりもスムーズに安心して開発を進められるようになります。現状30のパワーをバグ修正や障害対応に割いているとしたら、20のパワーをQA活動に割くことでバグ修正や障害対応に必要なパワーが5で済むので、トータル25。ほらお得！と。
そうは言っても、これは理想論であって、開発者の体感としては必ずしもそうではない。
じゃあイネイブリングQAはどうすればいいのか。
安直には、QA側もいままでQAのお仕事ではなかった「なにか」をできるように、イネイブられることでおあいこ・平等になると考えられます。
スクラムにおける開発者、
スクラムでは、プログラマー、テスター、アーキテクト、デザイナーなどの明示的な区分けはない。個人の専門分野はあってよく、むしろ強みを持ち寄り、その垣根を超えて貢献しあう。 via アジャイル開発の進め方 | 独立行政法人 情報処理推進機構
として振る舞えるようなスキルを身につけるのも一つかもしれません。ハードルが高いですね。
前に発表した際のお蔵入りスライドにも引用したのですが、ソフトウェアテストと監視は近いという考え方もできます。
TEST Study #2で「ソフトウェアテスト自動化、一歩前へ」という発表をしました - テストウフ
SREとか監視側にQAが手を伸ばすのも、必要なことかもしれません。
少し論が散らかったので整理しなおすと、
- 各種ロールが「イネイブリング」を始めた結果、開発者に求められていることが多すぎでは
- だったらイネイブリングする側になっているQAも、（旧来の）QAの枠にとらわれず色々できるようにイネイブられなければならないのかも
という話です。
QAは守備範囲が広がっている、やることが多い、なんて言われることもありますが、結局全てのロールがそうなんですねきっと。