QAエンジニアが切り拓く、開発の未来

この投稿を読んでいる方は、QAエンジニアでしょうか。はたまた開発系の方でしょうか。もしかすると、人事やビジネスサイドの人かもしれません。

QA、品質保証、テスト。どことなく地味で、単調な作業を想像してしまいがちなこのポジションですが、今日は「QAってこんなに大事なんだぜ」っていう話をしたいと思います。

以下、基本的にソフトウェアをつくってマネタイズする会社でのソフトウェアQAを想定して書きます。（ハードウェアの生産においては歩留まりの良し悪しやサービス/保証率で収益性に直接インパクトがあり、議論がぶれるので）

QAがプロダクトの進化スピードを定義する

皆さんの会社では、リリースはどういうリズムでやっていますか？弊社のようにスクラムを採用している会社だと、だいたい２週間から４週間ぐらいが大多数でしょうか。

では、なぜその期間を採用しているのでしょうか。

いろいろな答えがあると思います。組織によっては、４週間だとダレやすいから２週間にしている。変更の案内を顧客にきちんとするために長めのスパンにしている。Appleの審査が数日かかるから、それを考慮した結果３週間になった・・・などなど。事業やサービス、組織の特性によって、良いやり方は変わってくるので、チームの皆（とお客さん）がハッピーならそれで良いのだ、と思います。

でも、例えば、毎日リリースしたい、となったらどうでしょうか。

実際に毎日やるかはおいておいて、やろうと思ったらできる、というのは、突然のトラブルに対する対応力もそうですし、A/Bテストなどを用いて計量的な検証を進める際には、とても重要なんじゃないかと思います。ビジネストーク的に言えば、PDCAがより早く回るよね、ということです。毎日ちょっとずつ方向転換が出来て、市場からのフィードバックにより早く反応できたら、１年後、２年後には複利的に差が広がることになります。

マネージャー「たった１行の変更なのに何でそんなに渋るの？君それでもプロなの？」

まあ今時こんなことを言う（うんこ）マネジャーはそうそういないと思いますが、マネジャーの気持ち的には、早く出してお客さんを安心させたい。でも開発としては、その１行がどこに影響を与えうるかわからないし、下手な仕事はしたくない。ちゃんとテストしたい。

このギャップを埋めるには、結局のところ、任意の変更およびリリースに対するオーバーヘッド（≒作業量）を小さくしていくしかないのです。オンデマンドな変更が出来るのか、これがすべて。

ここでエンジニアの方は、あーはいはい、Continuous Integrationのツールと、DevOpsのプラクティスの話ね、となると思いますが、まさにそういうことなのです。ビルドからテスト、リリースに至るまでをいかに短縮し、かつ手戻りを少なく実行するかが、プロダクトの進化スピードを決めると言って良いと思います。

この中でも、テストに関しては、桁が変わるような進化は多くなく、まだまだ工夫や発明が色々できるところなのかなと思っています。もちろん、ベータ版の配布などのtoolingは日々進化していますが。開発時に書くテストコードと、昔ながらの手動のテスト、この二段構えのところがほとんどなのかなと。もちろん、WebプロジェクトならSelenium使うとか、いくつかやりようはあるんですけどね。

当然、プロジェクトによっても濃淡はあるべき。みんな大好きSQLiteなんかはコードベースの大半がテストコードだったりしますね。

余談ですが、新卒で入った某社の某チームでは、100万行以上のコードのビルドがなぜか手作業で、しかも当番制（毎回新しい人が手順書を見て実行するので、低くない確率で間違える）という笑えない状況だったので、上司に直訴して、１ヶ月ほどかけて段階的にPythonとshellで自動化した、という経験があります。

AI/機械学習が一般化するにつれて、QAの仕事は高度化する

ほんとかよ。

理屈は簡単です。

QAは基本的に、境界条件と手続き（deterministic）・連続試行回数（リーク、不正な状態遷移）・単純試行回数（タイミング）で出来ています。基本的には「Aの手順をすればB」「Cの手順をすればD」といったテストケースに加えて、たまにしか出ない不具合を洗い出して潰す、という作業ですね。

任意の変更がデグレ（degradation、劣化）を招いた場合も、基本的に上の３つのうちのどれかが悪い方向に傾いた、ということになります。

このデグレの定義が、機械学習のような統計的なシステムになってくると、やややっかいなのですね。というのも、品質目線を、機械学習で解決するタスクそのものの設計に織り込んでやる必要があるのです。

２年ほど前にTwitterの会話ボットが流行ったときに、差別的な発言を学習してしまってサービス停止に追い込まれた、ということがありました。

実際の実装がオンライン学習だったのかバッチ学習だったのかは定かではありませんが、自動的にモデルが更新される実装になっていたのではないでしょうか。自動更新自体は、サービスの進化がより早くなるので、ユーザーにとっても良いことだと思うのですが、機械学習システムの挙動がアルゴリズムとデータに基づいて統計的に変わる以上、本来はここも広義のQAの対象として見ておくべきだと思うのです。

さらに言うと、演算リソースをより必要とするこれらのアプリケーションでは、演算効率面のデグレもバカにならないことがあります。まあこれは、ユーザあたりの処理量が大きくなくても、ユーザ数が莫大になれば同じことが言えますが。性能劣化をリリース前に検知するためには、何らかの静的解析をするのが良いでしょう。PythonやJavaだったらバイトコードを検証するフックをかますのが良いかもしれません。

この辺は、G社とかA社、F社、S社あたりでは十年以上前から当たり前かもしれませんが、特定の技術が民主化、一般化すると、当然それに隣接する仕事も変わるんだな、と思います。

最後に、格言っぽいことを言って〆たいと思います。