過去このあたりでお話しましたが、自分はQAエンジニアではあるものの、自分がテストその他手を動かす割合は少なく「イネーブリングQA」的な動きをしています。

イネーブリングQAというのは勝手に作った造語で、かつ厳密に定義しているわけではないので、今後違った表現をする可能性はあります。が、ここでは

QAエンジニア以外の、開発組織の他ロールに対して「QA的な考え方や業務」をできるようイネーブリングしていく

というイメージで捉えてください。

このイネーブリングQAとして、テストや開発プロセスを整理しようと試みたり、あとはテスト技法を開発者に伝えたりなど行っているわけですが、なかなかに難しさがあるなと日々感じています。

QAが居なくていい状態を作る難しさ

私のところだけではなく、ここ数年「イネーブリングQA」とは言っていないもののそれに近いような考え方のQAチームが各社にある、と感じています。

QAが居ることで品質が高まるのではなく、QAが「居なくても」品質のよいものが作れる状態を実現する、という方向性でやっているという発表やWeb記事を見かけるようになりました。

この「居なくてもいい状態を作る」という考え方には非常に共感しつつ、その実現方法はまだまだ世の中的にも固まっていないように思います。

これまたよく職場で話すのですが、一般的に「QAエンジニアを入れて品質を高めよう」と思った場合どうなるかというと、QAエンジニアがチームに居る前提の開発プロセス変わっていくんですね。

たとえば、これはあえて悪い例ですが

開発が一通り完了して単体テストが済んだ時点で、アプリケーションと仕様書をQAエンジニアに渡します。そこからテストをやって、開発に対してテスト結果をリターンしてください。

といったプロセスになることもあります。品質向上という点では悪い例ですが、これでも

  • QAへのインプット
  • QAからのアウトプット
  • タスク発生のタイミング

が明確になっている点は良い、とも言えます。

このように、QAエンジニアがチームに入って活動する場合、QAエンジニアの出番はここ!というのを事前に明確にして始まるか、もしくはプロジェクトを進めていく中でなんとなく自然に固まっていくわけです。

話をイネーブリングQAに戻すと、イネーブリングQAは「自分たちがいなくてもいい状態を作る」ことを目指しているので、上記の例のように開発プロセスがQAエンジニアの存在を前提としたものに変わってしまうと都合が悪いはずです。居なくなるときに困るので。

もちろん、半年とか1年とか期間を決めて抜ける前提で話を進めるという手もありますが、だいたい「今は困る」とか「このプロジェクトが終わってから」等とズルズルっといったりするものです。もしかしたら、RED・GREEN・REFACTORINGのサイクルように、一度QAが居るプロセスを通ってからQAがいなくともよい状態に抜けるうまい方法があるのかもしれません。が、今のところ自分にはそのイメージがわかず・・・

QAの存在を前提とした開発プロセスを作ってしまうことを避けつつ、開発者中心に品質を担保(しかも効果的に)できるようにするための方法はないだろうか、を模索しているところです。

入りこまないと成果が表現しづらい

開発チームに入りこまずに外からイネーブリング活動をする、というのは、やるだけなら別に難しさはありません。ただ、QAエンジニアとしての成果が非常に見えづらかったり、見えるまでに時間がかかったりするのが難点だなと感じています。開発プロセスに入り込んで「ここはQAの出番です!」という部分を作ってしまえば、仕事している感も出ますし、少なくとも開発プロセスの一部を担っているわけで、必要な存在でいられます。

しかし開発プロセスの外にいて、「別にQAが居なくても回るしな・・・」という状態のままだと、QAとしての成果はどうなのかと言われると苦しいところです。

いなくても回る。けど居てくれるともっと良くなる。

というのが理想なのかな、というのが最近の考えていることです。「不可欠な存在」になってしまうとそれはイネーブリングという目的とは反してしまうので、居なくても良い開発ができる、でも居てくれたらすごく良い開発ができる、的な存在になれるといいんだろうなーと思います。そして、それが具体的にどのような要素を満たすQAなのかは・・・要議論ですね。


このあたり興味・関心がある方、ぜひどこかでお話しましょう。月一でオンラインMTGとかでも面白そうですし。