メルカリのQAさんと話してて浮かんだ次世代テストエンジニア組織のこと

たまたまメルカリのQAさんとお話する機会がありました。さすが今一番ホットとも言えるサービスだけあって、触発されていろいろ妄想がふくらみました。次世代QA組織とかテストエンジニアの役割とか、議論した内容をメモ。

はじめに

僕の興味は「速さ」です。「速さはすべてを超越する！」「速さと品質は両立できる！」と信じて、アジャイル開発とかリーン開発、業務改善を仕事で活用しようとしています。また、サービス開発会社で働いているので、作ることが仕事ではありません。作ったらサービスが死んじゃうまで開発運用が続くので、漸進的な開発が求められます。

この記事も前に書いたQAネタと同じく、素人ながら、経験したことをベースに、自分の置かれた環境に対して、あるべき姿を主観的に考えています。

これまでのQA

僕はSIerにいたので、そのときのQAのイメージが強いのですが、日本はSIerが多いので、QAのイメージの基盤にあるのはそれなのかなと。もしそれを「これまでのQA」と表現した場合・・・

工程にマッチするテストをそれぞれ行っていく、Vモデルのような考え方が根強い
SQiPでの講演を依頼されて思ったのは、アカデミックな要素が高い。だから、バグをロジカルに撲滅する力が強そう。
要件のときとできあがったときに登場するので、開発と近くない。ほぼ一緒にいない。

というイメージがあります。あんまり開発と仲良いイメージないですね。でもって、Vモデルの問題点である

テストの最終段階にならないと、企画当初の要求が正しく実現されているかを検証できない。参考： V字モデルとは｜第三者検証なら株式会社ウェブレッジ

が、サービス開発では（それ以外でもそうかもしれないけど）とても致命的です。なぜなら、変化が多い環境だから。完璧な状態よりも、ある程度動いた時点で見たり見せたりすることが重要な場合が多いからからそう思いました。

例えば、「要件＝成果物」ではなくて、「要件＝満たして欲しいことの最低レベル」であり、それよりいいアイデアが開発中に浮かんだり、出来上がったものを見て気がついてもいいわけです。ソフトウェアはやわらかいので、（時と場合によりますが）やりなおせます。

そして、「仕様＝満たすべきこと」でもなく「仕様＝多分これが正解っていう仮説」に近い感覚。どっちが正しいかわからないときはABテストでユーザに結果を委ねたりもするので、作るときの仕様と作った後の仕様は、一致するときもあるけれど、一致しないときもあります。

また、バグのないサービスやプロダクトはすばらしいですが、速さとの勝負の場合、「致命的でなければリリースする」場合もあります。上とかぶりますが、求めているのは完璧な機能というより、タイミングとそのとき必要なレベルの質。

そして、こういった開発は近い場所でゴニョゴニョできたり、当事者意識を求めます。複数案件を効率的にまわすより、どれだけそのサービスに貢献できたか？エンジニアと似たような期待です。

では、サービス開発にあったQAってなんだろう？そういった話をメルカリさんたちとしました。

これからのテストエンジニアに求められるもの

「DeNAが取り組む Software Engineer in Test」にもあるように「SET（Software Engineer in Test）」と呼ばれる人が今後増えそうです。『テストから見えてくるグーグルのソフトウェア開発』が発売されたのが2013年だから、単純計算アメリカより3年以上遅れでの登場。技術に力を入れているDeNAさんならではの取り組みですね。

Google Wayがすべての企業にマッチするとは思えませんが、やっぱりGoogleは強い。その思想やそこから生み出した方法は、自分たちの課題解決に役立つのも事実です。もちょっとこの本を読みこまないとだめなのですが、例えば

役割や責任範囲
評価基準やキャリアプラン
育成や採用

等をどうしていくか？どこにも答えはないはずなので、先に取り組んで経験から見つけていくしかないのでしょう。だとすると、早くやったほうがいい（競争ではないけども）。

そして、こういった考えが「これまでのQA」から生まれるか？今のところイメージが湧かないんですよね。やりたい人は多いのかもしれないけど、できないというより、ジャンルがそもそも違うというか。進化のためには根本的なところをハックしないとだめな気がしています。

それに、幾つかのテストベンダーさんと話しても、海外のベンダーは欧米企業が取引先にいるのでSETのようなやりかたを経験してました。でも、国内は「やれると思うがノウハウを一緒に作っていくしかない」という回答ばかり。あんまりニーズがないんですかねぇ。

だったらやっぱり、自分たちでやるほうが今は速いのかもしれない。そして速いもんがち。

これからのQA組織に求められること

まず採用。国内だと「プログラム書けるテスター」を探すのは難しいので、

https://daipresents.wordpress.com/2016/qa-testing/

採用戦略が重要になりそう。何個か思いついたけど、それはメルカリさんとのひ、み、つ。知りたい方はぜひランチしましょう！

次に役割分担。開発とQAの関係性にもよりますが、誰が何をテストするかがきっと変わる。

https://daipresents.wordpress.com/2016/agile-testing/

誤解を恐れずに言うと、サービス開発、特にフロントエンドのような変化の多い場所ではTDDまで求められていない気がします。あまりにもコストがかかるんですよね。それよりももっと楽にテストで囲い込むことができる時代です。

また、テストケースを管理するツールがあんまりないので、GitHubみたいなツールを作っても面白そう。テストケースがプログラムになればGitで管理できるけど、テストがソースに合わせなくても、テストはテストでツールを考えてもいいんじゃないかって思いました。手動テストは表形式だけど、自動化されている部分は実行ボタンがあるだけとか。