2020年11月25日に開催されたCTO meetupではアジャイルコーチとして豊富な経験を持つ藤原 大 氏をお招きし、トークセッションを行いました。

現在テスト自動化やQA組織の立ち上げが注目されている理由や実際に自動化を導入した事例、さらにQA組織に必要な人材要件や組織体制に至るまで、幅広いテーマについて語っておりますので、QA組織の立ち上げを考えている方や組織に課題を感じている方は、ぜひ参考にしてみてください。

パネラー

テスト自動化やQA組織の立ち上げがなぜ注目されるのか？

パネラー自己紹介

株式会社サーキュレーション FLEXY事業部 リーダー 岡田 一喜（以下、岡田）：
今回ファシリテーターをさせていただきます岡田です。本日はどうぞよろしくお願いします。

アジャイルコーチ / テスト自動化コンサルタント 藤原 大 氏（以下、藤原氏）：
よろしくお願いします、藤原です。簡単に自己紹介をさせていただくと、私はもともとエンジニアで、楽天に入社してからアジャイルコーチを名乗って活動をしていました。その後入社したメルカリではテスト自動化やQA組織の立ち上げを行っており、現在はフリーランスです。アジャイルコーチとしてはトータルで10年ほど活動しています。

岡田：
ありがとうございます。私もFLEXYでどのような仕事をしているのか簡単に紹介いたしますと、企業様から経営や技術的な課題をいただき、そこにマッチするプロ人材をアサインするコンサルティングのようなことをしています。

テスト自動化であれば、QAエンジニア不在の状態でどのように品質保証をするのか、あるいは自動化してからどのように組織を動かすのかといった案件を多く受けております。

時代背景 | 20年の間に何度も起きたアジャイル開発ブーム

岡田：
では早速、時代背景という部分からトークに入らせていただきます。藤原さんから事前に2000年代、2010年代、2020年代という大きく3つの年代で変化が起きているとお伺いしていますが、これはどういうことでしょうか。

藤原氏：
今回のテーマであるテスト自動化やQA組織の立ち上げがなぜ注目されるようになったのかを、簡単にまとめてみたいと思います。

藤原氏：
まず、大体10年おきにアジャイル開発ブームが来ています。まず2000年代はXPブームが起こり、2001年頃に日本で初めてコミュニティが誕生しました。2010年頃になるとジョナサン・ラスマセンの『アジャイルサムライ』という本が登場しましたし、2020年現在はDXがブームになったことで、より大規模・大人数のアジャイルが広まってきたと感じています。

いずれのブームにおいても、共通する課題は「開発が遅い」「変化に弱い」といったことです。時代が流れ技術が進化してもこれらはなかなか解決できていないのが現状で、だからこそアジャイル開発が注目されてきたのだと思います。

QAからQEの必要性

アジャイル開発を前進させるために求められたテスト自動化

【QAからQEの必要性】

• アジャイル開発はもう20年の歴史がある
• 開発面は技術進化してその恩恵を受けられるようになった
• QAがボトルネック

岡田：
アジャイル開発にはすでに20年の歴史があり、開発面では技術進化の恩恵を受けられるようになってきました。その一方で、QAがボトルネックになっている側面があるということですが……。

藤原氏：
エンジニアの生産性を上げていくための開発環境整備はかなり進んでいると思います。

しかし、開発速度が速くなっていった結果、最後のテストフェーズが詰まって遅くなり、アジャイルにどんどんリリースができないという状況が出てきました。私自身も前職で似たような出来事に遭遇しましたし、その中でテスト自動化やCI/CDなどが注目されるようになったと感じています。

こうした状況ではQAから新たにQEの必要性が出てきます。Quality Assurance、品質保証という言葉は以前からありますが、テストのボトルネックを取り除くためには自動化などエンジニアリングで何とかするしかないという部分が大きくなってきたということです。

岡田：
自動化を進めるにあたり、どこまで自動化をしてどこを人力でやらなければならないのかといった部分に課題を抱えている企業様も多いのですが、こういった課題もQEにつながるのでしょうか。

藤原氏：
そうですね。自動化といっても手段の一つですから、例えば100人で一気にテストする体制を構築してスピードを上げるという方法もあります。

ただ、現実的にそれは難しい。FLEXYさんにも相談があると思いますが、良いQAエンジニアが見つからないという状況はざらです。人数でなんとかするというのは無理があります。

また、テストを自動化しないとよりアジャイルにならないという点もあります。最終的には自動化せざるを得ない部分が出てくるので、いずれにせよ技術的な面は必要になるのだと感じます。

岡田：
IT人材という大きなくくりで見ても、現在は「2025年の崖」が叫ばれていますし、人材も2030年には60万人不足するというデータが出ています。いわゆるSESの業界構造が日本には残っており、多重請けの構造の中で辞めてしまう人材が多い中で、自動化はQAのみならずどんどん必須になっていきそうですね。

自動化の具体例

ケース1 | QAエンジニアなしで自動化を活用

岡田：
ここからは具体的な事例についてご紹介いただければと思います。希少価値の高いQAエンジニア不在の状態で自動化を活用されたことがあるそうですが、詳しくお聞かせいただけますでしょうか。

藤原氏：
FLEXYさんからの依頼ですとサービスの特性上、QAリソースをどうするか、QA組織の立ち上げにあたってどういうチームを作るべきかといったご相談が多いのですが、この事例はそもそもQA組織が無い状況での相談でした。そこで一人目の採用から始め、その人を中心としてQA活動を広げていきました。

ただ、メンバー1人では限界もありますし、ほかに注力すべきプロジェクトにその人がアサインされてしまった関係でなかなかQA活動ができず、テストも間に合わないという問題が起きました。

そこで私とエンジニア1名で、mabl（メイブル）というサービスを使って、まずはレグレッションテストと呼ばれる機能全体を確認するテストの自動化に取り組みました。その結果、自動化によって「機能が壊れていない」と確認できることによる自信がつき、1日に何度もリリースできる状況を作れています。

その企業は大体10名未満で運営するようなサービスが多かったのですが、最終的にはサービスごとに250件ほどのシナリオが毎日実行され、月あたり5,000件ほどのテストが自動で動くような形でした。最終的にメンテナンスコストはほぼゼロになり、朝出勤してオールグリーンだと確認をしたらそれで終わるという日もあったくらいです。

修正漏れや影響範囲に誤りがあればすぐに気付けるので、こうした状況を作れたことが、この事例では大きな成果になったのではと思います。

岡田：
すごい話ですね。この事例ではQA組織の一人目を採用した点が大きいかと思うのですが、そのあたりはどうやって採用したのでしょうか。

藤原氏：
一人目はやはり難しいので、会社に合うかどうかにプラスしてスキルをどう見るのか、クライアントと一緒に面接の練習をしましたね。

自動化だけをするというよりは、QAチームのマネジメントもしてほしいということだったので、チーム運営やOKRを作るなどエンジニアリングマネージャーのような立場で支援をしました。

岡田：
5,000件テストが動いてメンテナンスがほぼゼロになり、自信を持ってリリースができるようになったということですが、やはりこういった取り組みでメンタル面にも影響が出て、チームの雰囲気が良くなる部分もあるのでしょうか。

藤原氏：
毎日オールグリーンだと「やったね」という気分になりますし、何か修正したときには明日不具合が出るかもしれないというアナウンスが来るので、みんなでチェックするといった取り組みもしやすいです。

ケース2 | 自動化を始めたが、なかなか上手くいかない

岡田：
では次の事例についてお願いします。

藤原氏：
この事例では、企業がテスト専門のベンダーに依頼して、テスト自動化ツールを作っていました。ベンダー側も一生懸命要件を出して開発したのですが、結果としてはニーズがマッチしない状況に陥っており、そこに私が入った形です。

このときはまず関係者を集め、「そもそもの課題から解きほぐさないと自動化はできない」とお話ししました。さらにヒアリングをしてアクションプランを立てた上で議論を進め、最終的に利用するツールを決定してロードマップまで提供しましたね。

契約はロードマップを提供したところで一旦終了したため、その後のことはわかりませんが、この事例では「なぜ自動化が必要なのか」という点が他人事になっており、あとはベンダーに頼んだら解決してくれると考えていた点が印象的でした。

テストや品質に関してはQA組織だけではなく開発組織も巻き込んで議論すべきですし、導入時の効果や開発組織に対してどのように成果をアピールするべきなのかも握らなければいけません。こういった取り組みをせずに「とりあえず自動化」という状況になるのは、よくあることなのかなと感じます。

岡田：
なぜ、ベンダーを活用して要件定義がズレる、とりあえず自動化して失敗するという問題に陥りやすくなるのでしょうか。

藤原氏：
自動化によるコスト削減の計算は企業や人によって異なるため非常に難しいからです。自動化して時間削減はできたとしても、費用対効果はよくよく見ないとわかりません。導入以前とさほど変わらないという事態もあり得ます。しかもその中には、「壊れていない安心感」などは入っていません。そうなると、逆にコストが増えるということが起こるのです。

ケース3 | 自動テストの運用コスト問題を解決

岡田：
では、最後の事例についてお願いします。

藤原氏：
この事例ではすでにテスト自動化がされていたのですが、私が支援に入った当初はSlack上に壊れたものが流れてくるという状況でした。

自動化をしていきたいという文化は企業内にあったので、ここでは自分で自動化ツールを作るべきかどうかという判断をしましたね。最終的にはこちらもmabl（メイブル）を導入して壊れにくいテストを増やし、過去利用していたテストをどんどんマイグレーションしています。

自動化ツールを使って解決したい問題は非常に多く、それらも一つずつ潰していきました。例えば実行時間コストです。当時は直列実行しかできずテストに6時間ほどかかってしまっていたところ、並列実行をできるようにして1時間以内に終わるようにしました。

あとはメンテナンスコストですね。
ほぼノーコードなので、極端に言えばビジネスサイドでもテストを作れるような環境を構築しました。それぞれの困り事を見ていくと、大体の課題はツールで解決できたという事例でかかった期間は半年か1年ほどです。

岡田：
メンテナンスする人の幅を広く浅くできるようになったという状況なんですね。

藤原氏：
ただこれも難しい面がありまして、非エンジニアが書きやすいフォーマットにしてもやっぱり書かないんです。

岡田：
なぜですか？

藤原氏：
面倒だったり時間がなかったりするからです。書きやすさを求めてノーコードにするだけではまだ弱くて、もっと上手いやり方を考えないといけないのかなと思います。いかに書いてもらえるようにするか、あるいは書きたくなるようにするかというモチベーションはツールだけではどうにもなりません。

この事例の場合は全社的に「テストを書いていこう」という機運が生まれ、開発の全体会議でテスト事例を出して話し合ったり、エンジニアが率先して作ったものを見せたりして文化を作っていましたね。

次世代QA組織の人材について

自動化が増える中でテスターに求められる3つのスキル

岡田：
では次は組織周りのテーマに移れればと思います。

次世代QA組織の人材について、藤原さんのお考えを聞かせていただけますでしょうか。

藤原氏：
ちょうど1、2年前に参加したイベントで、「自動化がテスターを撲滅するのではないか」というパネルディスカッションをさせていただきました。コミュニティで有名な方々が5名ほど集まって話しましたが、みなさんの共通意見は「自動化によってテスターがいなくなりはしないが、テスターの仕事は変わる」というものでした。

その上でどんな人材が必要だと思うかを質問したところ、出てきたのが以下の３つの要素です。

【次世代QA組織の人材について】

• プログラミングを含む技術スキル
• 継続的な改善やチャレンジができるスキル
• 自分の範囲をどんどん広げられるスキル

藤原氏：
一つはプログラミングスキルです。当時Yahooの方は、「自分たちの使うテスト対象がソフトウェアであるならば、ソフトウェアの作りは知っておいたほうがいい」とおっしゃっていました。知らずにテストすると、奥深くまで探ることが難しいからです。プログラムを書けるかどうかではなく、そもそもどういう仕組みでソフトウェアが動いているのかを技術的に理解すべきだということですね。

2つ目は、言うまでもなく技術進化や今後出てくるだろう課題、変化に対して継続的な改善やチャレンジができるスキルです。今日もちょうどQAエンジニアの方と話していましたが、テストというスキルを自分から引いたときに残るような、プログラミングやプロジェクトマネジメントといった柱を育てていかなければ、キャリアを築くのは難しくなります。

最後が、自分の範囲をどんどん広げられるスキルです。当時は「越境」と言っていました。開発に関わるみなさんが感じていることだと思いますが、コードだけを書いたりテストだけをやっていても、プロジェクトはなかなか上手くいきません。もちろんフロントエンドはフロントエンドだけと役割を分けることはできますが、分ければ分けるほどつなぎの部分にコストがかかります。ですから自分の範囲を広げてフロントエンドにもバックエンド側にもコメントできるようなテスターは、どんどん活躍できる素晴らしい人材と言えます。

体制づくりのキーワードは「越境」と「当事者意識」

岡田：
体制づくりについても事前に3つのキーワードを出していただいていますが、これはどういった内容ですか？

【次世代QA組織の体制ついて】

• QAチーム、SETチーム、Autometorチーム
• 小さい開発チームに参加する、支援する形が多い
• QAチームではなく、QA活動を開発全体に広げる

藤原氏：
大企業も中小企業もいろいろと工夫しながら組織づくりをしていますが、どこにも正解はありません。

成功しているパターンがあったとしても、自社ではできないという面は多々あります。そのあたりをあえてパターン化してみると、大体各社はQAチーム、SETチーム、Automatorチームなどを組み合わせ、各組織の下、または横につけるといった形で試行錯誤しています。

私が支援する企業には大体小さな開発チームがあり、アジャイルにプロダクト開発をするケースが多いです。その中でQAチームがどう振る舞うか、役割として何をすべきかという部分で私に相談が来ます。一つ考えられるのは、QA、SET、Automatorの各チームが越境をしなければならないという状態ですね。

私自身はメルカリにいたときにSETとQAを見ていて、2つのチームを1つにして協力体制を作りました。ただ、私が辞めた後にAutomatorチームがなくなったようで、やはりなかなか上手くはいかないようです。恐らく開発チームとも協働する体制にしなければいけなかったのだと思います。とはいえ、チームを1つにすると人数が増えるので分けたくなる。ここが組織づくりの難しい部分です。

最終的には全員が当事者意識を持ち、「誰かがやってくれるだろう」という考えを持たないチームが勝つはずです。今は過去メルカリで失敗したことを考えながら、「上手く活動できるQA組織づくり」というものにチャレンジしているところです。

岡田：
越境と言っても難しい部分ですよね。メルカリでは失敗したと仰っていましたが、藤原さんが今メルカリと全く同じ状況の企業の支援に入った場合はどうしますか？

藤原氏：
やはり人それぞれですね。テスト部分を外注して上手くいくなら別にそれでもいいと思います。ただ、内製化の傾向がある中で安い外注に振るということなので、そういう考えで価値提供を高められるのかというと、私個人の意見では「できない」と考えています。

だとすれば、プロダクト開発に夢中で参加してくれるQAエンジニアを雇うほうがポジティブですし、育成もやりやすいのではと思います。

モチベーション維持という意味でも、「あなたの仕事は外部の人間をマネジメントするだけで、その先のキャリアはありません」と言って来てくれる人はいません。実際問題としてSIの業界ではそういうことが起きていますが、より良いプロダクトを作るためにはもっと良いアイディアがあるはずです。

総括

QEのニーズは高まるが、QAとしてやるべきことも多い

岡田：
では最後に「QAからQE」という部分について、改めて藤原さんのお考えをまとめてお話しいただけますでしょうか。また、藤原さんがおっしゃったように外注に投げるだけではやりたいことを実現できない中で、我々FLEXYはどういう部分に意義を見いだせるのか、お聞かせください。

藤原氏：
私はもともとエンジニアリング側の人間だったので、どちらかといえば技術の力で何とかしたいタイプです。これまでQAをやってきた方からしてみると「本当にできるのか」と思う部分もあるかもしれませんが、それでもQEでできると思いながらやっている感じです。

とはいえ必ずQEが勝つといった話ではなく、QAとしてやれることはたくさんあるし、QEとしてやれることも今後増えていくと感じています。QEは恐らく必須条件になってくるでしょうし、そのためには開発全体にQA活動を広められるような組織体制を考えなければなりません。

こういった状況におけるFLEXYの意義は、やはりプロフェッショナルなQAエンジニアやテスターが私の周りにもなかなか少ないという部分にあります。スポットで価値提供ができる副業が当たり前になり、企業側がFLEXYを活用してくれれば私もコラボがしやすいですし、逆に私ができない部分を助けてもらうことで新たな価値提供ができるのではと思います。そういう意味ではとても期待していますね。

企業サイドとしては、まず自分たちでなんとかする力を持てればそれでいいと思います。一方で専門家に頼ることでスピードを上げ、数段飛ばしでゴールに近づきビジネスの発展につなげていただければ、私としても働きがいがあるなと感じます。

岡田：
藤原さんとお話しさせていただき、改めて今はQAだけでは難しい時代で、越境が一つのキーワードになると感じました。

今回イベントに参加いただいた方々の役職や働き方もどんどん変化していきますから、本日のセッション内容をぜひ会社や個人の仕事に活かしていただければ幸いです。本日はありがとうございました。

企画/編集：FLEXY編集部

LINEでフリーランスの案件情報や最新Tipsを受け取る