自動化はテスター撲滅の夢を見るか？JaSSTで語られたテストの未来、品質の未来 #JaSST

2019年3月27日、日本大学理工学部駿河台校舎１号館にて、「JaSST’19 Tokyo」が開催されました。初日のセッション B2「テストの未来、品質の未来～自動化はテスター撲滅の夢を見るか？～」において、生まれて初めてモデレータをさせていただき、自動化を中心としたテストの未来、品質の未来を議論しました。この記事はそのセッションログをまとめたものです。

このセッションについて

（文章を読みやすくするために内容を変えないように書き起こしています）

藤原：みなさん、こんにちは。よろしくおねがいいたします。本日は「自動化はテスター撲滅の夢を見るか」というパネルディスカッションということで、5人の方をお招きしてお話をさせていただきたいと思います。司会はメルカリでAutomation & QA グループ（以下：AQA）のエンジニアリングマネージャをしている藤原と申します。よろしくおねがいします。

セッションチェアは米山さん、同じくメルカリのQAエンジニアなんですけれども、一緒にこのセッションを作り上げてきました。

ハッシュタグも作ってみたので、ご自由にお使いください（#jasstb2）。このセッションは結構時間がギリギリになるかもしれませんので、質問とかがあればぜひこのハッシュタグを使っていただければと思います。

ではさっそく、話を進めさせていただきたいのですが、まず、パネリストの方々のご紹介をさせていただきたいと思います。

山口鉄平氏（以下、山口）：ヤフー株式会社の山口と申します。今日の話は前の仕事の話なので「元」という形を使わせていただいてますが、システム統括本部という全社の開発基盤、サービス基盤、社内情報システムなどを作っている大きな部門の1セクションで、テストとかテスト自動化の社内普及をやっていました。

もともとは組み込みのソフトウェア書いたりとか、ソフトウェア開発技術の研究開発を努めた後に、アジャイルコーチでヤフーに来て、そのあとにテスト自動化普及といった仕事をさせていただいていました。

当社の場合は大きなサービスから小さなサービスまで、多種多様なものがありまして、いろんなサービスがいろんな作り方でつくられています。私自身はユニットテストのトレーニングやその導入、エンドツーエンド（以下、E2E）からAPIなど幅広く活動していました。

ヤフー社内の構造は、プロダクトの単位で分かれていて、その中にすべての機能（職能）が入っています。ここではDEVとだけ書いていますが、DEV以外にももちろんデザイナー、ディレクション、ビジネス、企画といった方がいる形になっています。そして、その単位でプロダクトですとかサービスが動いていく形になっていて、テストはその中で、その組織の中において責任を持って実施をする形になっております。

そこに我々のような間接支援部門が、入っていく形になっていて、QAというロールは社内にありませんし、QAというプロセスが全社的に存在しません。この点は、ひょっとするとみなさまの会社と違うかなと思っております。

藤原：ありがとうございます。今回自己紹介と一緒に、働いている組織の形もまとめてみたので、ぜひこちらも参考にしていただければと思います。山口さんの場合は、やっぱり職能がDEVしかない（「〜エンジニア」みたいに細かく分けてない）のと、QAというプロセスがないという点が、とても印象的かなと思います。

つづきまして、Lineの大園さん。よろしくおねがいします。

大園博昭氏（以下、大園）：Line Fukuokaの大園ともうします。今、開発室というところでUIテストオートメーションチームのマネージャをやっております。弊社におきましては、おもにUIテスト、E2EのUIテストをおもに自動テストで行っております。

ここではQAエンジニアから今のロールと書いてあるのですが、実際には、ちょっとアカデミックなことをやったのち、今の会社にひろっていただいているという経歴を持っています。

Lineグループも様々なプロダクトややりかたがあるため、今回お話するのは私のチームが関わっている、主に福岡の話題をさせていただこうと思っております。

基本的にはプロダクト単位でチームを組んでおりまして、そのなかに開発者、プロダクトマネージャ、プロジェクトマネージャ、QA、デザイナ、いろんなロールの方たちと一緒にやっています。私のチームのメンバーもその中にテスト自動化エンジニアというロールで、プロダクト開発の一員として中に入って活動する構造になっています。

藤原：ありがとうございます。Lineさんの場合は、ちょっとよこのメモにも書かせていただいたのですが、役割分担がちゃんとされていて、テスト自動化チームとSoftware Engineer in Test（以下、SET）が別にあったりとか、QAが発達した組織としてあるのが印象的かなぁと思います。つづきまして、ライフルの木住野さん、よろしくおねがいいたします。

木住野奈夫人氏（以下、木住野）：株式会社LIFULL（ライフル）の木住野です。所属としてはSETグループにいまして、SETという役割で働いています。経歴については、もともと開発志向があって、新卒でQAチームに配属されました。QAチームでの仕事は、テストのサポート活動、それとプラス、テスト自動化、CI/CD（継続的インテグレーション/継続的デリバリ）の支援というのがあって、約半年前ほど前に、QAチームから分離する形でSETグループが作られました。私はそのチームのリーダーをやっております。

現在は、3人でSETチームを運営していて、E2Eをメインに活動していて、かつ、CI/CDの整備と拡充なども行っております。メインにしているサービスはHOME’Sという不動産情報サイトになりまして、少し開発規模の話をさせていただくと、全体で数十チームあり、1チームが4〜5名で、週4回のリリースがあって、いろいろな施策がどんどんリリースされています。

これが体制の概要図なんですけど、チームがいくつかあって、各チームのリリースがまとまってリリースパッケージになるのですけれども、そのリリースパッケージに対するE2Eを主に開発運用していて、あとは、チームごとにかかえる開発リスクや不安があった場合に、自動テストでその不安を解消できないかという相談の対応をしています。

藤原：ありがとうございます。去年の10月SET立ち上げされたばかりという、比較的新しいチームの活動を今日紹介していただこうかなと思っております。つづきまして、メルカリの根本さんよろしくおねがいいたします。

根本征氏（以下、根本）：根本征と申します。3年前に新卒でメルカリに入社しまして、最初、WebのバックエンドエンジニアとしてPHPとかJavascriptを書いてたんですけども、そのあと、SETチームにうつり、次に現在のAQAチームにいます。主には、iOSとかAndroidとかWebのUIテストとか、CI/CDをメインに行なっています。

現在のAQAですけれども、自動化するエンジニアと、QAエンジニアが一緒にいるチームになっています。別にSETという形もいまして、どちらかというと現在はテストがメインと言うよりは開発環境、検証環境、開発者の生産性を向上するためのDevOps的なことをやっている人がいます。

我々自動化エンジニアは、これまでQAエンジニアと協業で自動化を進めてきたんですけれども、それもやりつつ、開発組織の中でマイクロサービス化や、既存のサービスのアーキテクチャを変えるプロジェクトが増えてきたため、既存機能が壊れていないことの確認だけでなく、よりリリースをはやくするために、直接プロジェクトに入ってE2E UIテスト開発をして貢献するということをやっています。

藤原：ありがとうございます。じゃ、最後は松尾さん、よろしくおねがいいたします。

松尾和昭氏（以下、松尾）：Headspinという会社で働いている松尾です。少し前まではクックパッドのテストエンジニアとして活動していて、その後、僕は今Appium（Tariqさんが今朝話しした中にも出てきたのですが）のメイン開発者として活動もしていて、現在はHeadspinという米国のスタートアップに転職して今に至ります。なので、時期が来たら向こう（US)に行く予定です。

今回、自動テストが焦点になると思うので、クックパッドでの過去の経験をベースにお話をさせて頂く予定です。経験としては、今はソフトウェアエンジニアとして開発もしているので、ユニットテストだったり、UIを使ったE2Eテストだったり、プロセス改善、プロセスを作っていく、（開発の）フローを作る、そういうところもクオリティエンジニアとして過去活動をやっていました。

僕がいたときのクックパッドの体制を例にとってきています。クックパッドでは国内外の開発にいろいろたずさわっていたんですけど、そのころのは大きく分けて、ひとつはプロダクトに対していろいろなサービス（機能）ですね。たとえば、投稿するとか検索するとか。そういう単位でわかれていた部署に対して、テストやクオリティエンジニアに従事する役割として僕がひとりめで入って、どこかに属している形ではなくて、基盤グループみたいな感じで横断的にまたがって、いろんなところにかかわったりしていました。

僕がいなくなるときも、特定のサービスに完全に属する形ではなく、横断的に見る形で活動をしていました。今現在のクックパッドの体制がこうなっているかどうかはわからないので、過去のベースで話をしています。

藤原：ありがとうございます。松尾さんに事前インタビューさせていただいたときに一番の印象的だったのは、テストの破綻を見越してこういう基盤グループでテストエンジニアとして活躍されていて、自動テストをほぼ完璧にやられていいたのが印象的です。

みなさまありがとうございました。このセッションは「自動化はテスター撲滅の夢を見るか」ということで、自動化を中心とした議論をもとに、テストの未来、品質の未来というものをお話させていただこうかなと思っております。

このセッションの元ネタは、事前にパネリストの方と自動化に興味がある20人の方（20戦士とここでは呼んでいます）にアンケートさせていただいて、その中で、集まってきた情報をもとに質問を組ませていただいています。また、パネリストの方とは事前インタビューをさせていただきアンケート内容の詳細を伺いました。

アンケート内容については書いているとおりで、現在の開発体制ですとか、テスト自動化に対してどんな課題がありましたかなど聞いています。複数回答ありなので、トータルの回答率が100％にならない場合もありますがご了承ください。

このセッション、前半の45分ぐらいで自動化の課題部分を、ぜひ実践されている方々から語っていただこうとかなと思っていまして、後半は、その自動化によってQA、テスター、SET、自動化エンジニアを含め、どういう働き方になって、どういう組織になっていくのか。そういうことを考えながら、未来をちょっとでも感じ取っていただければと思っております。

セッション内での用語集についても軽くまとめているんですけれども、テスト自動化はテスト自動化すること。テストというのはUT（ユニットテスト）のような小さいレベルから、E2Eのような大きいレベルまで全部含めています。

自動テストはテスト自動化したもので、テスターはテストを実行するのを主としている人、QAエンジニアは品質管理に関わる方全般を指しています。SETや自動化エンジニアは、自動化エンジニアでまとめております。

自己紹介でもあったとおり、組織の体制って本当にそれぞれ違うんですよね。今回、アプリとかWebを中心にした企業の方に集まっていただいているので、もしかしたら、自分たちの環境とは違う部分があるかもしれません。

よって、このパネルディスカッションはあくまで一説なので、「ほんとかよ？」ぐらいで考えていただければよいかなと思っております。特に大きな組織だと、様々なサービスを抱える場合もありますし、サービスごとのコンテキストが違って、なかなかうちではなーと思うところもあるとおもいます。

ただ、パネリストの方々は面白い経験をされている方々なので、ぜひご自身が自動化などにかかわるときに、参考にしていただければと思っております。

はたして自動化によってコスト削減できるのか

まず、前半戦はテスト自動化に対する課題をパネリストから伺ったのですが、まずテスト自動化をはじめたときの話を聞いてみました。質問は「テスト自動化への期待とその結果」。どういう期待を持って自動化をはじめて、その結果、現段階でどうなったのかを聞いています。

アンケート結果はこちらです。左側の白い文字で書かれているのが期待で、右の黄色い文字が結果です。

おもしろいのがですね、期待も結果もすばやいフィードバックと答えた方がほとんどで、その次にでてくるのがテストの効率化、コスト削減、素早いデリバリー、これらはみなさん考えられたことがあるのかなと思いますし、心の平安のように「安心するためのテスト」もあるのでしょう。。

なによりも面白いのがですね、この結果を見るとコスト削減が消えているんですよね。おそらく、やってみて、それじゃないなと気がついたのではないかと僕は感じていたんですけど、まさにそういう回答をしていただいたのがLine大園さんとメルカリ根本さんでした。

藤原：二人に聞きたいのですが、まずは大園さん。なぜ、コスト削減が消えてしまったのが教えていただけないですか？

大園：はい。まず前提の話をさせていただくと、私が今の会社でテスト自動化のチームを作ったのが約1年半〜2年前なんですけれども、まったくのゼロからスタートした感じでした。

当初は、手動のQAチームがいて、そこがものすごく細かく回帰テストだったり、新規機能のテストだったり、すべてをこうカバーしてくれているんですけど、そのコストを削減したいというのが一番の目的でスタートしました。

その中で、いろいろと要求が出てきて、コストも削減したいけど品質ももちろん担保したいし、いろいろな効果を狙った結果、全部中途半端になってしまうという大失敗を一回やらかしまして、そこで一旦ストップして、ちょっと歩みをとめて、「何からやろうか？」という話をして、まずは品質の担保からいこうときめて、あえてコスト削減をそのときはずしました。

現在は、あるサービスにおいては90数％までリグレッションテストを自動化しているんですけれども、人的コストに関していうと、手動テストの工数はもちろん減っています。その分、自動テストのスクリプトを組むためのコストっていうのは増えてきているので、結果とんとんになっているというのが私のチームの現状です。

今はそれでいいかなと思っていて、次のフェーズでコスト削減をもしかしたら狙えるかもしれない。そのときにまた考えようっていう感じです。

藤原：そうですね。コストと一言でいえてもいろんなコストがあると思いますが、おっしゃっていた人的コストはたしかにとんとんというか、マニュアルでやってたことを自動化する人コストがかかるし、特に何かテストが減ったわけではないですし、逆にメンテなど増えたコストもあるのかなと。

ただ、作ったものを使いつづけられれば、さきほど話されたように、品質担保が終わったあとに、戻ってくるものは結構多い。これが自動テストの効果ですかね。

あと、根本さんに聞きたいのですが、コスト削減、うちらも狙ってましたよね。どうですか自動化やってみて。大体2年前ぐらいですかね。

根本：ちょうど2年前に、僕と藤原でテスト自動化を立ち上げて、はじめた当時は、組織に対して目に見える成果ってとても大事だなぁと感じ、その中でコスト削減、この時間ぐらい削減できました、というのはすごく見えやすいと思います。最近だと、RPAを使って何万時間も削減しましたとかもあります。

ただ、先程大園さんがおっしゃっていたように、メンテナンスコストだったりとか、そういうスキルを持っている人を採用するとか、そういうのを含めるととんとんかなーと思っていて、多分、より本質は「すばやいフィードバック」とか、そっちにシフトしていかないと、難しいのかなぁと思いました。

藤原：ありがとうございます。興味深いですね。よくコスト削減を期待されるんですけど、逆になかなかうまくいかない部分もあるということですね。

テスト自動化におけるもっとも大きな課題とは？

藤原：次の質問からは、自動化の課題とその対策の話をさせていただきますが、ここで全部紹介するのは無理なので、パネリストへのインタビューの中でおもしろいトピックがあがってきたものを選んでいます。

課題については、Automation Pattern Wikiというサイトがあって、自動化の課題パターンがまとめられているので、あとでぜひ調べてみてください。その課題を日本語訳にして、整理して、みなさんに回答や投票していただきました。％は投票率と考えていただければとおもいます。

まずはじめの課題がこちら「テストが失敗したわけではないのに別の要因でテストに失敗してしまう」というものです。これは一番多かった課題で、投票率も80％と高くて、20戦士のアンケートでも60％を超えて高いものでした。類似の課題で、テスト用サーバーが少ないとか、ネットワークが弱いとか、環境が悪くて不安定というのも多くみられました。

ここで松尾さんに伺いたいのですが、環境の課題がトップを占めています。ご自身のご経験でもありましたか？

松尾：あるときは成功するのにたまに失敗するとか、いわゆるネットワークのような外的要因が原因というのは多いと思います。

今回のパネルが指す自動テストの範囲が、UTからE2Eを対象としていますが、何も考えずに実環境においてE2Eを組んだ場合、たとえば東京近辺の混雑する時間帯でネットワーク遅延が起きるとかあったりして、その時間にたまたまテスト実行して失敗するとか。

そういう本当にテストスクリプトの外的要因、それをひっくるめたE2Eテストなので、目的を持ってやるべきものなんですが、失敗したけどリトライして成功とかありますよね。意図して書いたスクリプトが変わらなくとも、その外的要因（考慮していた要因、考慮不足だった要因）が原因で失敗するのはたくさんありました。

僕はクックパッドでとくにモバイルアプリの自動化をやり続けてきたんですけど、テストの実行基盤がどれほど安定して運用できるかがポイントでした。なので、ユニットテストなり、E2Eとテストなり、大抵はテスト基盤をどれほど保全できるかが、不安定さをへらす大きなものになります。

Headspinにうつったのも、モバイルアプリのテストは、実行環境とかをエミュレータとかシミュレータにしない限りはまだいろいろ不安定だったり、端末を管理しなければならなかったり、そういう外的な失敗要因をだんだん減らして、失敗が少ない安定した環境を提供したかったからです。さらに、実環境に近い環境やメトリクスの提供を安定して提供できるする必要があると感じていました。

テストが失敗する原因はいろいろありますが、その軽減として安定したテスト基盤が必要不可欠で、とくにモバイルの世界、さらには実端末の世界では、すごくむずかしい段階だなと感じています。

藤原：たしかに。メルカリもアプリの会社ですけれども、テスト環境の安定化が運用のほとんどになっている現状があります。

この環境の問題が一番にでてきたのですが、テストコーチ、アジャイルコーチとして百戦錬磨の山口さんにぜひ伺いたいのですが、こういう課題っていろんなところで出てくると思うのですけれども、どう避けられてきましたか？

山口：やはり、この手の安定性ってすごく大切で、そもそも安定しないとテスト自体の信頼性がゼロになってしまいますし、実際、安定しないから「自動テストをやらない」になりやすいので、コーチとしてテストを書いていただく立場でたち振る舞っているので、極力、そういう課題を先まわりして提供して、回避をしていく形をとっています。

逆に、そういう外的要因が発生しにくい部分からテストを積み上げていき、安定しないテストがどでてきたところで「じゃ、どうしようか？」と考えたりもします。もちろんそうなる前に安定させられるのであれば、極力安定させていくんですけれども、どうしても実端末とかで制御しきれないところはあるので、外的要因が起きにくい部分からテストをはじめるのもやっておりました。

実際、そこでつまづかなくても、自動テストのメリットが享受できるエリアは多いので、そこでやめてしまうというのは僕からしたらもったいないと思っているので、そこじゃないところからきちっとやればいいんじゃないかとよく伝えていました。

藤原：そのあたりが流石ですね。コーチとか教える立場でいて、できるだけ課題を想定して動かれていますよね。だからか、直面した課題にチェックとか、山口さんほぼつけてないんですよね。「ほんとかよ！」と思ったのですが（笑）、実際に話を聞いてみると、そうならないように、どこからやるかとかをちゃんと考えられていたので、僕もアジャイルコーチとかしていた時代があったので、本当に勉強になりました。

テスト自動化チームの立ち上げと人材獲得

藤原：次の課題に行きたいと思います。2番目は「テスト自動化チームがいない、または、立ち上げが難しい。人材がいない、または少ない」が多かったです。

大園さん、Line Fukuoka で自動化チームを立ち上げされましたが、このへんの課題についてはどうでしたか？

大園：私に関して言うと、立ち上げに難しいというのは正直なかったですね。まぁ、がむしゃらにやっていたというのもあるんですけれども、むしろ今、拡大フェーズに入ってきて、もっとチームを拡大したいんだけれども、なかなか採用が難しいというのがちょっとあるかもしれないですね。

先程、お話がでましたけれども、僕の中ではE2Eテストってシステムを作るのとかわらないと思っているんですよね。そのシステムを作るにあたって、基礎的なエンジニア力は必要ですし、自動テストを単に書いているだけだと、ちょっと難しいというのもあるので、エンジニア採用とあんまり変わらないかなと思っております。

藤原：ありがとうございます。スケール段階を迎えているということで、逆に山口さん、自動化チームのスケールについてどうおもわれますか？ヤフー結構でかいですよね？

山口： そうですね。だいたいモノづくりにたずさわっているのが、今3000名ぐらいいるんですけれども、そこに対して、SETチームや自動化チームで対処するのは、気持ちはわかるけど現実的ではないんですよね。

むしろ、各チームごとでやっていくのが必要になってくると思っていて、そうなると、各現場で自動テストを書けるようになる、作れるようになる、E2Eシステムを作れるようになるっていうのが必要になってきます。

だから、人を増やすというよりも、その人達ができるようになっていく形に切り替えていかないといけなくて、自動化チーム自身、立ち上げですとか、人材いないというとかあるんですけれども、そこを強化するよりもその先をめざして、実際のサービスの現場に自動テストを伝えたり、教えたり、一緒に動ける人が増えるようにしなければならなくて、実際にできる人をきちっと配置、起用することが必要かなと思っています。

藤原： できる人のポイントはありますか？

山口：先程、大園さんもおっしゃっていたんですけれども、やっぱり、結局の所、自動テストシステムを作っているので、その観点はある程度必要かなと思いますし、テストをなるべく無駄なく効果的にやりたいので、その点も必要になると思います。

ある程度の理解や知識、経験が必要かなと思っていますが、いずれにしても自動テストって一夜で全部ができない世界です。徐々にできてくるので、それにあわせて学べる人、学び続けて動ける人がいればいいのかなと思います。

テスト自動化の見積もりと計画づくり

藤原： 次の課題どんどん行きたいと思いますが、「何を自動化の対象にするか、どのテストを自動化するか、スコープや計画や準備がきちんとできていない」が50％となっており、20戦士アンケートも58％とけっこう多かったです。たくさんの方が計画や準備といった、どこをどうやるのかという点で苦労されているみたいです。

ここでもいくつか質問があるのですが、LIFULL木住野さん。えいやーとテストを作って失敗された話をインタビューでされていたとおもいますが、その経験を教えていただけますか？

木住野： はい。私達のシステムテストは、2012年くらいからスタートしていて、とにかく当初、常識というかセオリーというのがなかったので、まずテストカバレッジを増やす。増やせば品質が担保できると考えて、そのときは進んでいました。結果としてとにかく機能を洗い出して、とにかくそのテストを実装したので、1000ケースほど実装しました。

しかし、このテストで何を守りたいのかを不明確なまま進めてしまい、不明確なままで運用を続けていった結果、さきほど週4回リリースと話したのですが、当時は週2回リリースで、その都度リリース前に自動テストを当時のQAチームが実行していました。

その自動テストを運用している人が4人いて、その4人全員がまる1日使って、テスト結果を確認して、メンテナンスを行う・・・といういわゆるアンチパターンにおちいっていました。その後、リリースが週2回から4回に増えたんですけれども、開発プロセスを改善して週4回リリースに高速化するときに、それがボトルネックになってきたんですね。

そこからテストを減らす、テストを最適化する話になっていくのですが、どうやって最適化したかというと、テストの対象が明確ではなかったので、単純にテスト計画を作りました。QAやテストをやっている方から見ると当たり前の話だと思いますが、私達の自動テストにはそれがなかったので、それを行いました。具体的にはテスト対象をしぼりました。これも当たり前の話だと思います。そして、手動テストと自動テストで、どちらのテストで何をカバーするんだっけ？を明確にしました。

そのあとも、自動テストでカバーすべき範囲がまだ不明確で大きかったので、そのなかさらに、どういったテストを対象にするかを2つの方針を決めました。ひとつが「ビジネスにおいて壊れてはいけない機能は絶対守りましょう」、もうひとつは「過去に障害が起きてしまった機能は絶対ケアしましょう」です。

さらに、ビジネスにおいて壊れたら困る機能ってなんだろう？という定義をより明確にしていく必要があって、そのために、取得しているログをGoogle Analytics（以下、GA）で解析し「このページはどのくらいPVがあるか」や「ページの価値」を調べ、そこからページの優先度を決めて、そのページにある機能は優先度高いと決めて、テスト対象をしぼっていきました。

藤原：ページの価値をPVとかで見ているのって面白いですね。数値化しているってことですね。

木住野：GAには、PVとページの価値という2つの値があって、それをかけ合わせてページの価値を定量的にはかっていく形になります。その内容をテストに落とし込んでいった結果として、今、SETグループ3人なんですけれども、長くて1〜2時間程度で確認が終わるようにまでプロセス改善できました。

藤原：おなじく大園さんも作り直しを経験したんですよね。それはどういう失敗だったんですか？何が足りなくて失敗されたんですかね？

大園：はい。もうスクラッチから、スクラッチから、スクラッチから3回ぐらいやりましたね。今おっしゃっていたこととほとんど本質は同じだと思うんですけれども、本当になにも考えずにどんどんスクリプトを作ってしまったというのが、多分一番の失敗の原因だと思います。そこで、何をロギングするか？何を評価するか？というプロセスがすぽんと抜けて、とりあえずテストいっぱい回したよ。すごいでしょ！みたいなそういう雰囲気を一番最初にやってしまった感じですね。

つい最近、立ち上げ時からぼくと一緒にやってくれている相棒と、僕らどんな失敗したっけというのをホワイトボードにどばーっと書き出したんですけれど、一面ぜんぶうまりましたｗ

藤原：ホワイトボードなのにホワイトな部分がなくなったんですね（笑）。

大園：はい。ホワイトボードなのにぜんぶ真っ黒にうまりました（笑）。それぐらい失敗した数は多かったと思います。でも、それのおかげで何が大切かを学ぶこともできましたし、必要な失敗だったと今は思っています。

藤原：ありがとうございます。あとは根本さん、我々もメルカリで失敗というか、自動テストを作りまくった経験がありますよね。どうでしたか？

根本： そうですね。本当に一緒で、一番最初にえいやーと手動でやることを自動化していたんですけれども、課題になっていたのはテストケースで、新しい機能がふえたときなどに更新されてなかったりとか、自動化エンジニアがケースを確認したときにどういう意図でこれが作られたのかっていうのが誰もわからなかったりとかしました。

あとは、新しくケースが追加されたときに、それがちゃんと自動化されるまでのプロセスにはいってなかったりとかも問題になりました。作り直した経緯としては、テストケースを新しく作り変えましょう。それにあわせて自動化も作り直して、プロセスを作っていきましょうという形でした。

マニュアルテストを自動化してしまうアンチパターン

藤原： この課題は次の課題にもつながるんですけれど、同じく50％で「手動のテストケースをそのまま自動化してしまって、テスト効率が悪い」という課題もあるようです。

僕自身も手動テストの自動化や、そのメンテをしているんですが、結構この課題ってアンチパターンじゃないかなと思う部分があります。なぜなら、手動テストって手動のためのものなので、自動テストのようにパーツを共通化したりとか、自動ならではの省略をしたりとかができていない。

どうでしょう、松尾さん、マニュアルテストをそのまま自動化すると失敗する確率が高くなるのではないかなと思うんですけれども。

松尾：そうですね。具体的にいうと、たとえばアプリのUIテストをするときに、手動テストだと、システムの設定をonにして、こういうふうにして、これを実行する・・・みたいなケースを書いたとします。その設定は、いくつかのUIを経由して設定画面に行って行う必要があるとすると、手動テストではそれを愚直に書いて、その手順通りにやっていく。これを自動化用シナリオにするのは、とてももったいない。無駄が多いですね。

というのも、とくにAndroidとかだと楽なんですけれども、そういう設定をオン・オフできる方法は、裏側でスクリプトを動かしたり、Helperアプリを作ったりするとできるんですね。それを短縮せずに自動化プログラムを組んでやると、UIのアニメーションによる失敗が発生したり、さきほどもあったテストが不安定になる環境に遭遇しやすくなります。

藤原：メルカリでもこの問題が大きくなっていて、マニュアルテストを更新した人と自動化する人の間でも確認に時間がかかるんですよね。だから、最近はいきなり自動化用テストケースを作ったほうがいいんじゃないかと思い、方針を変えようと思っています。

さらに、きしのさんとのインタビューでおもしろかったのですが、自動テストケースをつくったときにマニュアルケースがなかったんですよね？だから、いきなり自動ケースを作る必要があったと。そのとき困った点はありませんでしたか？

木住野： 当時（8年ほど前）はデグレなどがとても発生していて、それが障害につながってしまう状況になってしまっていました。そして、テストにかける工数をQAも開発チームも取れない。手動テストケースに起こしたところで手動で実行もできない。アンチパターンも考えずに自動化するしかないという状況でした。

藤原：なるほど。最近だと、自動テストをいきなり書き出すケースもあると聞いているので、結構これはアンチパターンではないか思います。まだチャレンジしているところなのでわからないんですが、結果がでたら共有させていただきたいなと思っています。

テスターは自動テストを書くべきか？

藤原：次の課題は「テストを実行する人が自動化用テストケースを書けない」です。テスターがテストコードをメンテナンスできない問題ですね。大園さんと木住野さん、もともとQAエンジニアから自動化エンジニア、SETというキャリアをつまれていますが、今スクリプト書けてますよね。苦労とかありませんでしたか？

木住野：そうですね。僕自身はプログラミングできなかったという苦労はなかったですね。なぜかというと、私はQAチームに所属していたんですが、当初からそこに自動テストシステムがあって、プログラムを学ばざるを得ない部分があったので、苦労はなかったです。

別の苦労になりますが、「テストスキルがそもそもなかった」のが僕自身一番苦労したところで、先程失敗した例でもありましたけれど、何をテストすべきかというのはその当時わからなかったので、大園さんもおっしゃっていましたけど、テストを自動化すること自体が、ブラウザが自動で動くこと自体が楽しいというハイに陥ってしまうと、もうわからなくなって、ああいう失敗に陥ってしまうので、テストスキルを学んで、自動テスト以外にもQAのテストにちゃんとかかわって、計画を作り、設計も書いて仕様に落としこむ・・・。ここまでできるようになるのに一番苦労したかなと思っています。

藤原：大園さんも同じくSET、自動化エンジニアになられてますが、苦労はなされましたか？

大園：なかったと思います。QAからのロールチェンジと言うと語弊があるというか、QAを半年もやってないんですね。だから、テストに精通してたというわけでは特になくて、もともと科学演算とかをやっていたという流れで、ソフトウェア自体にはちょっと明るかったところもあったので、そんなに苦労はなかったかなと思います。

藤原：Line Fukuokaさんの自動化チームに入ってこられる方はエンジニアが多いですか？

大園：僕のチームは今もうほとんどエンジニアですね。

藤原：メルカリも同じです。エンジニアの方が多くて、海外の人は特にQAエンジニアから自動化エンジニアというキャリアの方が多いですね。

テスト自動化推進の組織的な理解

藤原：次の課題に続きますが「テスト自動化チームがマネジメント層やテスター、他の関係者から十分なサポートをもらえない」が20％と低いんですけれども、一応課題としてやっぱ出てくる部分もあるようです。このあたりで根本さんは苦労されていますか？まぁ、一応、私、あなたのマネージャーですけれども。いいんですよ。言ってくれて（笑）。

根本： マネージャはありがたいんですけれども（笑）、実際には（開発を担当する）エンジニアだったり、QAエンジニアと働いてますが、結論から言うと一番仕事しやすいのは、品質だったりとか、生産性に責任がある人。メルカリだと特にTech Leadと呼ばれる技術的責任を持っている人やエンジニアリングマネージャ。そういった方とはすごく働きやすいなぁと思います。

サポートする立場でいうと、短期的な施策の中で、テスト自動化で価値を出すのはとても難しいと思います。なぜかというと、その人が次のプロジェクトに移ったり、責任から離れてしまったりするときもあります。

プロジェクトが佳境を迎える中で、テスト自動化大事ですよっていってもなかなか難しい。砂漠の中で食べ物や水がない人に向かって「森って大事ですよね」といっても伝わらないじゃないですか。ほしいのは水や食料ですから。

藤原：ありがとうございます。じゃ、次に山口さんに伺いたいのですが、こういった課題はご自身のコーチ経験の中でありましたか？どんどん現場に入っていく仕事ですよね。

山口：はい。ヤフーの仕事のやりかたを少しご説明しないと、このへんは話せないかなと思うのですが、基本的にヤフーの中において、明確に上から仕事がやってきて「必ずこれをやらなければならない」とか「これ以外はやってはいけない」とか、そういった仕事のやりかた、サービスづくりしている人はいないです。

ある程度の自由度があり、もちろん厳しいルールや条件にはさらされているんですけれど、「何かをしてはいけない」というような仕事をしていないので、僕らが社内に行くときには、実際にプログラム（コード）を書いている人にアクセスしていて、困っている人のところに行くという形でやっています。そうすると、その人が「自動テストいいな」と思えば、それをその人のマネージャやチームメンバーに伝えていけば伝わっていくので、サポートもらえなくて困るってことは僕の中ではないですね。

逆にトップダウンで入れたほうが良いときもあるので、それはもちろん、効果とかをマネージャや経営層に伝えて、上からトップダウンで施策を進めますが、そういったときはこっちから自動化を仕掛けていく形なので、「サポートをもらう」というより「サポートをください」なので、今のこの課題とは違うかなと思います。

藤原：かっこいいですね！「サポートもらえなくて困ったことない」って言ってみたいですね。こういうアプローチが許される環境というのは、すばらしいと思います。

私もマネージャとして施策を考えるときがあるんですけれども、成功する秘訣はわからないんですけれども、だいたい失敗するときって「カバレッジを正確にもとめてくるやつが現れたとき」とか、そういうときはだいたい失敗するんですよね。もとのケースが悪ければ、カバレッジ上げるだけでは効果が大きくならないし、トラブルもおきちゃいます。指標の説明は難しいのですが、人的、お金的なリソースとかの補助とかはしていただきたいので、その意味や意義を理解してもらうための説明も大切だなと感じています。

ここから業務連絡なんですけれども、ちょうど45分ぐらいで順調です（笑）。この調子でお願いします。

テスト自動化のための理想の体制とロール

藤原：後半は本題「自動化はテスター撲滅の夢を見るか」についてになります。実際にテスト自動化の課題を経験されて、みなさん今どう思いますか？テスト自動化のための理想の体制やロールがあれば教えてくださいという質問をさせていただきました。

回答者のほとんどがアプリとかウェブの会社なので、（一部取り入れているもふくめ）基本的にアジャイル開発で職能横断的チーム（小さなクロスファンクショナルなチーム）があたりまえのようです。よって、今回はQAエンジニアとかテスターといったロール（役割）について聞いてみました。

まずはこの会場のみなさんにも伺いたいのですが、テスターを主としてやられているかたってどれぐらいいらっしゃいますか？はずかしがらずにぜひ（笑）

（5分の1ぐらいの手が上がる）

結構いらっしゃいますね。QAエンジニアと名乗っている方。

（4分の1ぐらい）

エンジニアの方。

（4分の1ぐらい）

それ以外の方。プロマネとかいろいろありますよね。

（5分の1ぐらい）

ありがとうございます。結構ばらばらに散っている感じですね。

テスト自動化チームは必要なのか？

藤原：まずははじめの意見なのですが、「自動化チームは必要か？」という質問で、こういうふうにわかれました。その理由をぜひ聞いていきたいんですけれども、まずは根本さん。自動化チームに現在所属する上で、どうしてこう思うのかとを教えていただけますか。

根本：自分がそのチームにいるってのもあります。そして、それぞれのチームの中で、自動テストを書く人が増えるのは一番いいとはおもいます。でも、現場に行くと、今のメルカリだと技術の変化をすごく感じます。たとえでいうと、マイクロサービス化だったり。モバイルからフロントエンドにおいてマイクロサービス化されているところなんですね。そういった中で、今までモノリシックなWebのアプリケーションであれば、UTやUIテストを現場で書けるとは思うのですが、マイクロサービスなどになることで技術的にキャッチアップが難しくなってくると感じています。

このように技術が発達していく中で、それをキャッチアップしながら、いかに良いテストを書いていくのか？という人やチームへの投資は必要なのかなと思っています。

藤原：ありがとうございます。逆にきしのさん、根本さんの存在を真っ向から否定していると思うんですけれども（笑）、その理由をぜひ教えていただけますか。

木住野：否定するわけではないんですけれども（笑）、自動化エンジニアを「自動テストの運用とCI/CDまわりの自動化をすすめるエンジニア」としてお話しますが、そういった自動化は、開発チームが自立して行うのが理想だろうと考えています。なぜなら、サービスと開発プロセスを理解している方のほうが、より適切な自動化を、より迅速にできるからで、おそらくみなさん同意してくださるとおもいます。

たとえば、レビュープロセスにボトルネックがあるとすれば、そこに自動レビューツールを入れようとか、こういう判断は開発プロセスをしっかり熟知していて、開発に携わっている人のほうが迅速に考えられるからです。

ただし、これは開発チームが自動化を実施するスキルをもちあわせていて、かつ、それを実行できること。根本さんもおっしゃっていましたけど、技術的キャッチアップをするところにも、しっかりとリソースを投下できるのが大前提として必要になってくるんですけれども、そういった状況になるなら「自動化チームがいない」という世界が一番理想かなと私は感じています。

藤原：ありがとうございます。松尾さんにも質問したいんですけれども「自動化チームはケースによっては必要ない」とおっしゃっていましたね。どういうケースだといらなくて、どういうケースだと有効的に動くとお考えですかね？

松尾：あるサービスを開発するチームが自動化を行っていて、そこにその情報をキャッチアップする人達が入ってきて、そういう人たちがいろんなところにいて、横断的なコミュニティのようにお互いに情報交換をしながら新しい情報をキャッチアップする。そういうつながりができるのであれば、「チーム」という一つの独立したある部署が存在する必要はないと思います。僕はそういう形になるのがいいなと思って過去活動していました。

でも、どこから導入していこうか？というようにそこに至る前の段階だと、いわゆる開発基盤チームのような横断的部署や役割も必要だと思います。導入をする一番はじめの段階は、いろんなところに関わりながら、だんだん浸透させていくという活動も必要になります。

藤原：中に入り込んでやっていけばそういうチームがなくてもいいし、必要としても最低限、情報交換ができればいいんじゃないかということですね。

QAエンジニアは必要なのか？

藤原：次の質問なんですけれども、「QAエンジニアは必要か？」について質問をさせていただきました。これは未来の話です。自動化がすすんでいったらどうなるかを想像してみてください。ここでまさに会場の4分の1ぐらいのQAエンジニアを敵にまわしているが、木住野さんなんですけれども（笑）、ぜひご意見をいただけますか？

木住野：私が必要ないと言っているのは、おそらく、QAエンジニアの役割が変わるだろう思っているからです。何をテストで担保したいかを決めるのは、結局の所、開発チーム、もしくは、プロダクトオーナーが決めればいいと思っています。しかし、ソフトウェアテストのスキルや、品質保証活動の経験がない場合は、それが決められないというのが現状だと思います。

今のQAエンジニアのメインの仕事は、テストについて納得感を作ることです。この「納得しているか？」というところが、QAエンジニアのメインの仕事だと私は捉えていて、その納得のために必要なスキルを補うことができれば、QAエンジニアは必要なくなるかなと考えています。

そのために必要な教育とか、QAとしての経験値を蓄積して、みんなが自動テストを使えるような仕組みを作り上げるとか、そういった活動を行うのがQAエンジニアがやるべきことなのかなと私は考えています。

藤原：ありがとうございます。山口さんは「サービスによる」と回答されたんですけれども、ヤフーさんにはQAエンジニアというかQAというフェーズがないんですよね。

山口：ヤフーにはないです。僕自身はヤフーのサービスにおいて、QAエンジニアが必要なサービスやプロダクトは個人的にはあんまりないかなと思っています。だから、この質問だと「必要がない」ほうに入るかなとちょっと感じています。

その理由は、先程木住野さんがおっしゃったように、開発者が改善していけるサービスやプロダクトの規模があり、障害や不具合が発生したとしても、すぐ修正してリリースするほうが、コスト的にベストなものが多いと感じているからです。

ただ、一方で、組み込みのように、一回障害が出ると、売上が吹っ飛んでしまうようなプロダクトや、人の生死にかかわるプロダクトににおいては、開発者たちが「品質に対して全責任を持つ」というのはちょっと現実的ではないと思います。プロダクトオーナや企画のような作りたいモノを考える人も全能ではないので、そういった人たちをアシストするようなQAエンジニアは必要かなと思っています。

藤原： 私も最近自動化やQAの組織づくりについて、他社さんのサポートをさせていただりしているんですけれども、テストが全然なかったり、リグレッションとかもやってなかったりするんですよね。でも「自動化したい」と言う。さらに「今この状態で困っていることあるんですか？」と聞くと、ちょっと考えて「特にトラブルもおきてない・・・」となったり。

Webとかアプリとかだと、結構出してしまうのが先という状況が多いので、山口さんの意見にはとても賛成できると思いました。

おっしゃるとおり、モノ系やライフライン系ですね。そこが「自動テストしています」と言っているとさすがにちょっとひきますね（笑）。たとえば、自分はそんなシステムが動いている飛行機に乗りたくないなと思うんですけれど、使い分けは必要なのかなと思います。

テスターは必要か？

藤原：つづきましては「テスターは必要あるか？」という主題なんですけれども、必要あると4人がおっしゃる中で、大園さんがひとり「仕事内容が変わる」と回答されました。ぜひお話をいただけますか？

大園： 具体的なイメージがわいているわけではないのであくまで僕の感覚の話になるんですが、弊社にも結構QAエンジニア、テスターがいて、皆さん多様化してきている印象があります。

テスターといっても、決められたテストケースを単にテストするだけではなくて、たとえばプランナーさんに寄りそうように、仕様作成から入っていく場合もあります。あとは、UXエンジニアのように「これはユーザ的にだめじゃない？」という指摘を、数値も持って具体的についてくる人もいます。

テスターというロールだけでなく、こういうロールももつ方もちらほら見ることがあって、まさにここに回答したとおり、仕事の内容を自分たちで変えていくんじゃないか？という期待を僕は持っています。

今ちょっと自動化エンジニアってのがもてはやされていると思うんですけれども、それ以外の分野にも面白いことやっている人がいっぱいいると思うんですよね。そういうところを、期待してこういう書き方をしました。

藤原：ありがとうございます。「テスターは必要ない」と言っている悪い四人組については（笑）、次のスライドでもうちょっと詳しく聞かせていただこうと思います。

藤原：では、その仕事内容はどうか？「部分的に置き換わるだろう」という意見と「完全に置き換わるだろう」という意見に分かれました。どれぐらい変わるか？どのように変わるか？を伺ってもいいでしょうか？

山口：先程大園さんがおっしゃっていたように、テストケースの一覧にもとづいて、上から順に実行する単純な作業はなくなっていくと思っていますし、なくしていきたいと思っています。とはいえ、バグを感覚的に、探索的に見つけてくれる人は残るし、その価値は高いかなと思います。

木住野： 私はテスターの仕事の内容を「単純な手動テストを実施する人」と解釈して回答したのですが、そういったテストは自動化されると考えています。ただし、それがどのぐらい変わるかは、組織の成熟度や自動化の進み具合によると思います。技術トレンドを追うリソースを持っていて、どんどん開発の中に取り込んでいけるチームであれば、どんどん自動化して、どんどん手動の簡単なテストがなくなるでしょう。

ただし、リーン開発のように「まずはビジネスの価値を明確に追求しよう」という環境では、テスターに探索的テストや手動テストをまずやっていただいて、自動化をあとにしてしまう場合も可能性としてある思います。よって、「部分的に自動化される」と答えました。

根本：いわゆるリグレッションテストというような、毎回機能的に壊れてないか確認するものは、どんどん置き換えていくべきだし、していきたいなと思っています。ただ、スクリプトを書く作業がAIに置き換わるかは、まだわからないんですが、スクリプトを書くのと、手でやるのとで、どちらがはやいかわからない状況ってあるんですよね。

たとえば、新しい新機能が特にそうだと思うんですけれど、そういう場合はたぶんマニュアルが優先されて自動化されないし、マニュアルテストが求められるのかなと。今後はそこに自動化への力を割いていきたいなと思っています。藤

松尾：置き換わる部分に関しては皆さんが言ってくれたと思います。今回の定義にあるように実施するだけの人、オペレーションだけする人は置き換えられるでしょう。

僕の新しい会社の話になりますが、特定の国のリアルネットワーク回線を使って自分たちのサービスを使うとどうなるか？といったレベルだともう自動化する環境は整ってきています。たとえば、日本で開発しながら、インドネシアやアフリカの国の地域の人たちが、実際に利用する携帯回線を使って、自分たちのサービスを使うとどうなのか？こういうケースはサービスの利用で解決する時代になってきているので、これからもどんどん置き換わっていくでしょう。

ただ、現地で生活をしたり、実際に移動したり、探索的テストしたり・・・という領域は当面、AIを考慮したとしても、まだ置き換わらないし、人の作業を取りのぞけられないと感じています。

藤原：ありがとうございます。4人とは違って、完全に置き換えてやるぜーっと回答してくださった大園さんはどういうお考えなのか教えてください（笑）。

大園：若干狙ったところもあります（笑）。私の希望が7割ぐらい入っていると思っていただきたいのですが、前提条件をいくつかつけてお話させていただくと、完全に置き換えるのであれば、開発プロセス自体であったりとか、今のQA体制であったりとか、そういったところにもメスを入れる必要がでてきます。今手動でやっているところをぜんぶ自動にするだけではなくて、そのプロセス自体を全部見直す必要が必ずでてくるとおもいます。見直した結果、完全に置き換えられる可能性とはゼロではないと思ってますし、そこを目指していくようなシステムを僕らが作っていくべきではないかなと思います。

藤原：なるほど。そのシステムを作る仕事ってなかなか難しそうですね。そこに到達するのってどれぐらい？何年後？とかって見えていますか？

大園： 僕は今担当しているサービスの中で、チームの課題として、直近でそれをやるべき、やらないといけないと考えています。僕のチームはスクリプトを書いたりメンテンナンスしたりするのも主務のひとつに入ってはいるんですけれども、僕らがそこをやらずに、（開発を担当する）エンジニアやQAエンジニアだけで全部管理できる・・・ような環境ですね。環境をつくるのが僕らの仕事かなと。そのために、今手動でやっているテストのうち、できるところをすべて自動テストで置き換えるのが、今の一番の狙いかなと思っています。

藤原：このへんは山口さん、先程おっしゃられたコーチングの肝な部分に近いかなという感じがするんですがどうですかね？

山口： 何を外の環境（現場とは別の場所）とするのかもあると思っていて、外にすればするだけ、実際の現場で開発している人から距離が出てくるので違うものになりやすいんですよね。一番理想はやっぱり、開発の人ができること。それができないのであれば、「なぜできないか？」というのをどんどん取り除いていければいいと思ってます。

藤原：ありがとうございます。木住野さん、リグレッションテストケースをかなり作られていると思うんですが、エンジニアが作って自分自身の仕事がなくなるような状況まで、すぐ達成できそうですかね？

木住野： すぐ達成できるとはいいきれないですけど、そこを目指しています。

私達が使っている自動テストツールは、AIとかは使ってないんですが、だれでもメンテナンスできて、WindowsでもLinuxでもMacでも自動テスト環境が作れる仕組みを作り、それを配布する取り組みを行っています。開発者自身も、結構、乗り気でやってくれているので、そういった世界をすぐに描けるんじゃないかと思っています。

藤原： 難易度は高いけれど、目指す方向はそこなんですね。

Agile、DevOps時代の人材像

では最後の質問です。ひとりずつうかがいたいのですが、Web業界とかアプリ業界は特に、今の時代、アジャイル開発やDevOps、CI/CDがメインストリームになってきました。こんな時代だと、プロセスの中にテストフェーズ作ってしまうとそこがボトルネックになりがちです。

だから、自動化が流行ってきているのかなと思うのですが、自動化というものをかなり経験されてきたパネリストに質問したいのは、「アジャイル、DevOpsがあたりまえの時代に、どういう人材が求められているか？」、さらに「ご自身がどういう人材になりたいのか？」というのを聞かせてください。

藤原：まずは山口さん。「プログラマがだせない価値を出せる人」。こちらについてぜひおしえていただけないでしょうか？あ、結構、時間が、余裕が出てきました。なので、語っていただいても大丈夫です（笑）。

山口： 語るほどの話はないと思いますが（笑）、みなさんがすでに語られていたと思います。プログラミングのような、ものづくりをするという行為、サービス開発をするという行為において、プログラマが主たるパフォーマンスを出せる領域がありますが、それ以外の領域もそれなりにあると思っていて、その領域で価値を出せる人が必要かなと思っております。

もちろん、プログラマ自身がその範囲を広げるのも、人の育成もひっくるめて考えるとまだまだですよね。多様性というか、領域は山ほどあって、そういう領域で、価値を出せる人っていうのは、今後もずっとパフォーマンスや価値を出せるし、求められる人材になるんじゃないかなと思います。

藤原： 追加で聞きたいんですけれども、インタビューでもあったと思うのですが、プログラミングスキルっているんですかね？

山口： プログラミングがまったくわからないっていうのは、何を作っているかわからなくなってしまうので、流石にちょっと苦しいかなと思っています。詳しく知る必要はないんですけれども、どう作られているのか、どういうプロセスがあるのかは知っておく必要があると思いますし、それで十分だと思っています。そして、それに基づいて「何が必要になんだっけ？」とかをきちんと考えられて、きちんと提供できれば十分だと思っています。

藤原： 先程もちょっとでてきた、開発環境やプロセスですね。たしか木住野さんもおっしゃっていたと思うのですが、そのへんを理解したうえでのQAであったり、自動化であったりというのが肝になるのですね。ありがとうございます。

藤原：つづきまして、大園さん。「誰もやっていないことに果敢にチャレンジする人」。これはもうご自身の経験をふまえてだったと思うんですけれども、たしかインタビューしたときは「失敗ならいくらでも語れます！」という話をされていたのが印象的で、そのなかで今、スクラッチをくりかえしながら、今の位置にいるのでしょうが、このメッセージはどういう意味を持つのでしょうか?

大園：どちらかというと僕のチームは若いチームで、まだできたばっかりで、テスト自動化というのもはじめて二年ぐらいで、ここ1年以内ぐらいでSETチームができあがって、いろんなことをターゲットにしていて、メンバーはソフトウェアエンジニアからロールチェンジして来られた方が中心になっています。

まだ、だれも考えもしなかったことをいきなりポーンとだしてきて、「それ面白いね！一緒にやろうよ！」と盛り上がっているパターンが、結構社内のいろんなところでおきているんですが、うちのチームが狙っているところがまさにそういうところで、今までエンジニアが「やれるんだけどめんどくさいなぁ」と思っているところを、僕らがうまく拾い上げると言うか、エンジニアが、機能開発に集中できる環境をつくるのが、僕のチームの大事な目標のひとつかなと思ってやっているところもあります。

「それを開発するためにはどうしよう？」というのをみずからキャッチアップしてきて、自らそれを実践して、失敗しても全然大丈夫ですし、うちの上司もふくめ私もふくめ、みんな失敗だらけでやっていますが、チャレンジするっていうことをひとつのテーマにやっているところもあるので、そういうチャレンジを一緒に楽しんでくれる人と僕は一緒に仕事したいなぁと思っています。

藤原： 熱いメッセージですね！

藤原：つづきまして、木住野さんは「技術スキルを持ち、継続的な改善を推進する人」。こちらもご自身の活動に重ねてだと思うんですけれども、ぜひ教えてください。

木住野： 技術スキルがなぜ必要なのかという話をまずしようと思うのですが、「最適なテクノロジーを選んで、最適な自動化、最高の価値を生み出す」ためには、どうしても技術スキルを自分も持っていて、それを理解して、どれが最適かってのを選び取る必要があります。

そのためには、技術スキルが絶対必要で、たとえば、サーバがどう動いているのか？ネットワークがどう繋がっているのか？実際にデプロイがどう行われているのか？自分自身が理解していかないと、それをどういった形にするのが最適なのかつきつめることができません。

次に、「継続的な改善」ですけれども、これは僕自身の経験からでてきているもので、誰もが最初から正解を選ぶのは難しいと思っていて、かつ、最初に正解がたまたま低確率ででたとしても、それは時間の経過とともに、周りの環境との間で不正解になることもよくあると思うんですよね。だから、継続的にそれを見直して、問題を見つけて、改善を行って。問題を解決へと改善できる人。この2つが自分自身に対してもですし、こういう人と一緒に仕事していきたいなと思っています。

藤原： ありがとうございます。つづきましてが、メルカリ根本さん。越境する人。これを詳しく教えてください

根本： 今回、パネルディスカッションで、僕のマネージャが何度も「テスター撲滅」と言ってましたけれども（笑）、いわゆるE2Eテストを書いていると、僕らの仕事もなくなるかなと思っていて、むしろテスターよりはやくなくなるんじゃないかなと個人的に思っています。

たとえば、今回基調講演にあったAI For Testingだったりとか、そういったものによって、スクリプトを書かなくてもどんどん自動化されていく時代が、すぐ近にあるのかなと思っています。そういった中で、ひとつの専門性を持ちながら、他の領域もキャッチアップして貢献できる人が必要になってくる、求められるのかなと思っています。

先程大園さんが言っていたとおり、メルカリの現場でも、デザイナーさんがデザインだけじゃなくて、フロントエンドのコンポーネントを作ったりとか、SREエンジニアのようなインフラを専門としながら、たとえばパフォーマンスが悪いときに、実際のアプリケーションコードをがしがし改善していくとか、そういった人がより求められる時代になってくるのかなと思っています。

だから自分としては、たぶん技術力だけじゃなくて、自動化を専門にしながら、他の領域に行って、実際に現場に入っていって、貢献していく・・・のをやっていきたいなと思っています。

藤原： ありがとうございます。「自分の領域を超えて」というのは、ちょっと前に福岡でイベントやったときに、松尾さんと一緒にこういう話をしたんですけれども、そのときも「境目を越えられる人」がトピックになって、根本パクったな・・・と僕は思っています（笑）。でも、たしかにおっしゃるとおり、SETもエンジニアとQA、エンジニアとテスターの間だったりするわけで、そういう境目のところに広がっていくのは今後もあると思っていて、全体を通して企画に参加するQAとか大園さんもおっしゃっていましたけど、そういうところがまさに「越境」なのかなと感じました。

藤原：最後は松尾さんですね。「学びを続けられる人」。

松尾： かなり一般的な話になるんですけれど、僕の知人とか、日本人以外の人達を見ていても、やっぱり思うのは、たとえば、自分たちが活躍しているチームで足りないものは何かとか、カスタマーとか、サービスを享受するユーザとか、そういう人たちに対して自分たちはどう動けばいいか考えていて、自分たちがいたらないのであれば、新しいものを学ぶなり取り入れるなりしていく・・・という印象が強いですね。

今生き残っている人たちは、それがモチベーションとしてとても強くて、そのモチベーションを維持し続ける人は、少なくともアジャイルみたいなひとつの風潮がおわったあとでも、生き残る道を模索しつづけられる人になって強いんじゃないかなと思います。それらをまるっとくくって、「学びを続けられる」というふうにしました。

あたらしい環境とか、変わっていくのが常なので、そういうふうにいかに自分たちが貢献したり、それを教授する人たちを、それはそれでいいのかというのを考えながら動ける人はいいなと思います。

藤原： ありがとうございます。ご自身もAppiumのコミッタとしての視点をお持ちだと思うんですけれども、自分もやっていて思うんですけれども、特にモバイル業界、結構技術の進化も速いですし、どんどんツールもでてくるじゃないですか。ご自身もツール提供のベンダーと思うんですけれど、やっぱりどれもどんどん試していくとか、自動化エンジニア、QA、テスター含め、学んでいくべきなんですかね？

松尾： 使ったりするのはいいとは思うんですけど、たとえば、モバイルアプリのファンクショナルな部分で自動化ができているけれども、性能評価のモニタリングはプロダクションに出したあとに頼りっきりで良いのか？そういうところに疑問に思って、ユーザがいる地域でリリースをする前のモニタリングができる環境を作れるHeadspinに今回転職をしたんですね。

ためしてみるというよりは、こういうことをしたほうが、自分たちのサービスをうけるユーザとかが、よりよい体験になると思うのにそれができないのはなぜか？という点に対して、ちゃんと取り組んでいけるように開拓をするとか、Appiumのコミッタとかやっているとすごく重要だなと感じますね。

そういう人たちが新しいものに取り組んだり、今回のAIのような領域にもコラボレーションしていったり、いろんなところでいろんな技術を作りながらそれを統合していって、最終的にたとえば、AndroidやiOSのテスト自動化プラットフォームなどに、自分たちがいなくなったとしてもそこに還元される。だからそれはそれでいい。これによって数年前、自分たちにできなかったことが今では普通になっているとか、それが安いとか、無料とか、もしくは有償だけれどもすぐに使えるとか。

そういう世界がくるといいなというのがモチベーションの源泉ですね。

藤原： ありがとうございます。面白いですね。これでいいのか？と問いかけ、見つけたサービスを選んで転職。しかもスタートアップでアメリカに行く。もうシンデレラストーリーですよね。すごいチャレンジだと思います。

まとめ：自動化はテスター撲滅の夢を見るか？

藤原：そろそろ時間になってきたので、まとめに入りたいと思いますが、あくまでこれは仮説の話になります。このセッションのテーマでも書かせていただいたんですけれども「自動化はテスター撲滅の夢を見るか」。

たぶん、今までの話を聞いていてうすうすと気づいていたかもしれないんですけれども、この話、テスターだけじゃないんですよね。QAエンジニアもしかり、エンジニアもしかり、自動化エンジニアもしかり。特に私はSET、自動化エンジニアをやっていて、ずっとテストコードを書く仕事ってやりたくないよねっていう話も根本とかとも話します。

Autometorという仕事も海外にはあるみたいなんですけれども、それだけではなんかつまらないというか、モチベーションの源泉たるものをみつけなきゃねということで、どんどんどんどんシフトレフト、より違う方向に越境してこうと思っています。

先程ちょっと紹介させていただいた「テスターの仕事は自動化によってどうなるか？」というアンケートなんですけれども、パネリスト＋アンケートに答えてくださった20戦士の合計値を見ると、こういう形になっているんですよね。

92％の人が「全部ではなく部分的に置き換わる」であろうと答えている。これはまあ、みんな同じ意見です。回答した方がテストや自動化、QAに関わる人達なので、その人達の意見としては、結構高い数字だといえますよね。

そして、完全に置き換えると答えたのは大園さんだと思うので、大園さんにはあとでちょっと身の危険を守っていただければと思いますが（笑）、そういう意見もある。私もどちらかというと大園さんの意見に賛成で、完全に置き換えてやろうとおもって自動化を進めているので、この方向性は変わらないだろうと思っています。

そして、圧倒的な事実がここからわかるんですけれども、「テスターの仕事は自動化によって置き換わらない」とおもっている人がひとりもいないんですよね。これが結構面白い事実かなと思っていて、撲滅と言うとちょっといいすぎかもしれないんですけれども、あきらかに仕事の価値が変わってきている部分があるんじゃないかなと思っています。

私のはメルカリでマネージャはじめて2年目ぐらいになるんですけれども、もともとQAエンジニア経験がない中で、QAエンジニア採用でどうやってスキルを見極めようかをいろいろ考えていました。そして、対外的にも内部的にも言っているんですけれども、メルカリにはテスターはいないです。

もちろん、テストを主としている人はいるかもしれないですけれども、「テストするだけ」という意識で働いている人はそもそも採用しないです。なぜならば、誤解を恐れずに言うと、そこに価値を僕は感じてないからです。

さらにいうと、エンジニアリングマネージャとしてメンバーの育成やキャリアプランを考える、支援する仕事もあるんですけど、それを考えたときに、今の時代だとテストだけを極めようという人のキャリアを作るのが難しいなと考えていますし（もちろん極められるならそれはそれで大歓迎なんですけれども）、職能横断的なプロジェクトの現場にQAエンジニアが入っていって、エンジニアと肩を並べてあーだこーだいいながらモノを作り上げていく開発の中では、なかなかテストをやっているだけでは価値が上がらないんですよね。極端にいうと給料があがらないんですよ。

さすがにそういう状況をすすめられないから、採用基準としてもテストだけのひとは雇わないとしていて、もしもそういう人が入ってくるとしても、それ以外のポテンシャルを持っているか？それ以外の領域に価値を広げられるか？ってところを必ず重視して見るようにしています。

もうひとつ、このセッションに関して、「テストの未来、品質の未来」という話もありましたが、これについては自分が最近に感じていることをまとめてみました。

私もマネージャーとしてメンバーとディスカッションしたり、海外のカンファレンス情報を集めたりしておもうところがあります。

たとえばですよ。超高速な環境ができて、モバイルテストでもWebテストでも1分以内で終わることができるようになったらどうでしょう？すごいじゃないですか？でも、実際にそれってもうできるんですよね。松尾さんはクックパットでやられていて（参考：x3 Speed Up Android CI at Cookpad）、根本さんも同じくメルカリでやっていて（参考：Docker × Android エミュレータで、自動テスト(Appium)を並列化・爆速にする環境を作ったお話）、クラウド上の高性能サーバーを利用して、今だと100〜150ケースで1時間半ぐらいかかっているテストが、10〜15分ぐらいで実行できて、どんどんどんどん短くなっている。10〜15分になると、毎コミットごとにE2Eが流せる時代がくるかもしれない。ここにはぜひ投資したいなと思っています。

さらに、AIやMLは今回のJaSSTの主題のひとつでもあると思うんですけれども、たとえば自然なシナリオを自動生成できるようになったらどうなるのでしょう？一部、OSSで公開されたアプリのエレメントを自動で見つけるプラグインみたいなのもでてきていて（参考：AppiumのAIによる要素セレクタを試してみたら、自動テストの未来を感じた）、できるようになってきているのが現状なんですよね。しかも、数年で実用化されるだろうという予想も立ってきている。

さらにさらに、これらを提供するテストサービスが登場したらどうなるか？これもすごいあるんですよね（参考：「テストエンジニア採用は不要」——日本人初、AIを活用したソフトウェア自動テストツール「Autify」が米国アクセラレータ「Alchemist Accelerator」プログラム卒業を発表）。国内だとまだ少ないかもしれませんが、海外のイベントとか行くと、この会場の三倍ぐらいのところにテストベンダーのブースがたくさん集まっていて、「仕様書を送ってくれれば全部自動化しますよ」と言っています。

もしもこれらが本当に使えるのであれば。

「コスト高になるE2Eを作りすぎない」というテストピラミッドのような常識がひっくりかえるかもしれないし、探索テストやテスト設計手法ですら必要なくなるかもしれない。なぜならば、はやく実行できるから全件網羅すればいいんですよね。全件網羅ですらも、自動で見つけてもらえばいいんですよね。そして、テスト、QAエンジニア、自動化エンジニアが必要なくなるかもしれませんよね。だって、サービス使えばいいんだから。

完全自動で、全ケース網羅して、高速実行する。こういう未来が訪れるかもしれないし、その一歩は踏み出しているように感じていて、このセッションにおいて、そういう事実を語り合いたいなと思っていました。

「かもね」と書いているとおり、あくまで仮説であり、どういう未来が来るかはわかりませんが、先程の0％と言う事実ですよね。結構高い角度で来るかもしれないですよね。

そんな時代の中、我々がどうやって生きていくか？どういうふうにキャリアを築くか？どういう人材を集めるべきか？なるべきか？たぶん、パネリストのみなさんの一言にまとまっていると思います。

価値の移動が起こっている中で、自分の価値をどう生かしていくか？今の価値が下がっていくならば、上げるためにどうするべきか？もしくは違うところにその価値を高めていくのか？

次に、チャレンジです。その価値がなにもせずに上がるのは「ない」と思います。うちのメンバーにも「プロジェクトに参加して仕事しているだけでスキルがあがるの？とか聞いているんですよね。あがるときもあるけど、そうじゃないときも多いですよね。とくにデスマーチになっていたら全部下がってしまうかもしれない。だからチャレンジを必ずしましょうと。

そして、継続的な改善。これはアジャイルコミュニティでよくいわれる言葉ですけれども、ちょっとずつ継続的な改善は本質なのかなと。急激な改善は起きないと思うんですよね。

さらに根本さんのおっしゃっていた越境。自分の領域をどう超えていくか？これも価値に繋がる部分があります。

やっていることをずっとやっていけば許される時代はたぶん終わっていて、変化が激しい世の中に対して、自分もどう変化していくか？そのために、松尾さんがおっしゃっていたようなな、国内外とわず、コミッターとしてOSSに貢献して学び続ける。これはすごい意志ですよね。

今回パネリストの方々にいろいろお話を聞かせていただいて、その意見をセッションに向けてまとめながら、こういった本質にたどりついたのは、とても面白い体験でした。

簡単で早口でまとめてしまいましたが、以上をまとめとさせていただきました。

（ここで質問をひとついただきました）

質問： リグレッションテストなどのテスト自動化をすすめる活動をいています。現場で改善をすすめるうえで、最先端の情報とか、新しいツールとか手法とか試してみたいと思っています。でも、リソースも限られているので、現場の改善を優先するのか？そういった新しい手法を試すのか？バランスをとるのが難しいと感じているのですが、そこに対してどう気をつけているのか？どうバランスを取っているのか？アドバイスがあればぜひお答えいただきたいです。

藤原：目の前の仕事が忙しいけれども、未来への投資とかの勉強も大切だよね。そのバランスをとるのが難しいけれどみなさんどうされてますか？という質問ですかね。挙手制にしますか？いい話できる方、ぜひ手を上げてください（笑）。

大園： 参考になるかはわからないんですが、私の場合、チャレンジしようという風土をすごく作ってくれていて、コスト度外視で完全に独立部隊のチームを作ってもらいました。新しいことはじめるんだったら失敗していい。コストもかけていい。好きにやっていい。ただ、失敗した場合はどんどんそれを学んで、組織にいずれ返してくださいと。そんなかんじでうちの上司は背中を押してくれましたね。

藤原：それはやっぱり目の前の仕事ありつつの、そういう投資もしつつもなんですかね？

大園： ひとつだけ補足しておくと、QA環境もかなり固まっている状態でした。そこから、新しいことをはじめる状態だったので、環境に助けられた部分もあるかなと思います。

（ここで時間となりました）

藤原：最後にですね、今日、いろいろな意見をくださったパネリストのみなさまには、多大なお時間を頂きました。そして、アンケートに答えてくださった20戦士の方々もたぶんこの中に何人かいらっしゃると思うのですが、ぜひ、大きな拍手をいただければ幸いです。本日はどうもありがとうございました。