あらゆるビジネスの成長において、品質保証は信頼性だけでなく他社との競争力を高める点においても重要です。成長スピードの早いWebサービスにおいては、QA部門単独での品質保証から、組織が横断して品質向上に取り組む体制がトレンド化しています。品質保証を組織全体で考えるためには、さまざまなハードルや問題点をクリアしなければなりません。
そこで今回は第一線で活躍されている現役のQAエンジニアを招いて、「プロダクトの品質が競争力を高めビジネスの成長を後押しする 今だからこそ全社で取り組みたい品質保証」と題したセミナーを2023年5月10日に開催しました。
パネルディスカッションで話題となったトレードオフの問題、アジャイル開発におけるシフトレフトなどを一部ピックアップしてご紹介します。
セミナー概要
【セミナー名】
プロダクトの品質が競争力を高めビジネスの成長を後押しする 今だからこそ全社で取り組みたい品質保証
【開催日時】
2023年5月10日（水）14:00～15:00
【概要】
従来型のQA部門単独での品質保証から、組織横断的に品質を向上していく体制に移行するために有効な考え方や具体的な方法について、プロダクトの品質保証に向き合うAGESTとAutifyがそれぞれの立場からパネルディスカッション形式でお話しします。
【登壇者】
若林 剛史 氏
株式会社AGEST QA事業本部 アドバンステストソリューション部 部長
ゲームデバッグから始まったキャリアは、その後ソフトウェアテストの領域に移る。海外にも拠点を立ち上げて、現在はテスト自動化サービスを主導している。新しいツールや技術の取り組みにも積極的で、社内ではマネジメントも担当している。
末村 拓也
オーティファイ株式会社 Senior Technical Support Engineer
フォークリフトオペレーターを経験したのちにExcelVBA、Web開発、QAエンジニアなどを経験して、現在はAutify社のテクニカルサポートエンジニア（テスト自動化スペシャリスト）として活躍。JassT Online実行委員でもあり、E2E自動テスト技術全般に詳しい。
‐ なぜ全社で取り組む必要があるのか
近年の開発を取り巻く環境は、過去5年で見ると他社との競合関係が厳しくなっていると回答した企業は53%にのぼります。これには開発環境や顧客のニーズに加えて、市場の変化も重なり素早い開発サイクルの実現が必須になりつつあるといえます。あらゆるビジネスの中核にソフトウェアがあり、ソフトウェアはビジネスに柔軟に対応する必要があるのです。
また柔軟なソフトウェア開発を実現するためにはスクラム体制が必要不可欠になり、アジャイル開発の導入スピートは急速に広まっています。しかし現実にはデプロイのリリースサイクルは週1回や月1回が多数派を占めており、機能開発に想定以上の時間がかかっている状態です。
原因としてはリリース前に想定以上のバグが出る、またはバグが多くテスト期間が長期化してなかなかリリースできない、そもそもQAエンジニアのリソースが確保できないなど様々です。
結果的にAgility（素早さ）とQuality（品質）がトレードオフになってしまい、システムを改修してビジネスを先に進めると、ソフトウェア品質が犠牲になってしまう。反対にソフトウェアの品質を高めようとすると、リリースサイクルが犠牲になるというジレンマに陥ってしまうのです。
Agility VS Quality
開発チームのパフォーマンスを4つの分類にしたマトリックス表において、表の右側は品質の高さ、表の上部は変化に対する適応速度を示しています。ローンチ直後は左上の「Low quality trade-off層」になりがちで、特徴としては不具合に寛容なユーザーが多い傾向にあります。これはQualityよりAgilityを優先するという特徴が見て取れます。
ローンチから時間が経過すると、一般的なライトユーザーが増えてきます。ユーザー数が増えることで品質の期待値が高まり、バグがなくて当たり前という考え方が多数派を占めるともいえるでしょう。機能が追加されることでプロダクトもより複雑化することで、不具合を見つけにくくリスクが高まります。この状況から脱却するためには、AgilityよりQualityを優先することに舵を切らなければなりません。これによりAgilityとQualityのトレードオフが生じるのです。
ですが最終的にはElite層を目指さないと迅速に市場の要求に答えられず、せっかくシステムをローンチしてもビジネスとしては失敗するかもしれません。
Agility & Quality
AgilityとQualityをいかにトレードオフにせず両立させるか、今回のトピックとなる「プロダクトの品質が競争力を高めビジネスの成長を後押しする」の重要性について考えます。
たったひとつの機能をリリースするだけでも、複数のプログラムやコンポーネントが組み合わさることでQAエンジニアの負担が大きくなります。開発チームの負担は積み上げ式といえますが、QAエンジニアは関連箇所すべてを確認する必要性があり負担は大きくなる一方です。
リリースサイクルを遅くするか、障害のリスクを許容するか天秤にかけることは難しいでしょう。結局ビジネスと既存ユーザーのどちらかが犠牲になり、カスタマーサディスファクションは実現できずビジネス自体が失敗する可能性も高くなってしまいます。
そこでテスト自動化の導入が求められるのですが、実際には自動化を行なうための人手が不足していたり、自動化に関わるメンテナンスコストが上がったりと導入へのハードルが高いとされていました。
これらの解決策として、AutifyではAIを用いたE2Eアプリケーションのテスト自動化サービスを提供しています。学習コストがなるべく低い自動化ツールであれば、ビジネスの加速化にも貢献できるのではないでしょうか。
– なぜ品質保証部門だけでなく、開発組織全体で品質意識を高める必要があるのか？
-末村
昨今の組織形態として部門が細分化（開発は開発部門、テストはテスト部門）から、内製化などの影響もあり、組織全体をひとつにまとめる潮流が多くみられるようになりました。若林さんが所属する株式会社AGE末村Tでは、部門を丸ごと支援する点がユニークであり強みでもありますよね。品質だけでなく開発も含めた全体、いわばアジャイル開発での体制はプロダクトにとってどのような良い影響がありますか。
-若林
明らかにアジャイル開発での体制は増えてきましたね。元々は手動テストだけを行なっていた時期もあったんですが、アジャイル開発の普及で開発とテストの境界が徐々に曖昧になってきた気がしてきたんです。テストだけをやってきた人は活躍できる場所がどんどん少なくなってきて、いろいろな知識を持っていないと品質を上げられないと思ったんです。その影響もあり手動テストから領域を広げたという経緯があります。
すべて実装してから最終工程でテストをするのではなく、もっと前の段階でシフトレフトする動きも活発ですよね。単体テストの領域に手を出したくても、テスト担当だけではうまくいかない。知識的にも難しいので、開発に知見のある人間が参加しなければなりません。場合によってはテストエンジニアがアジャイル開発のスクラムチームに入って品質の価値を共有することで、開発知識を持った人間が品質向上に取り組むようになり早い段階でバグ潰しができるメリットも生まれるのではないでしょうか。
-末村
テストを最終工程にするのではなく、早い段階に移して実施することがシフトレフトですよね。
-若林
不具合を早いタイミングで見つけられると、修正コストは圧倒的に安くなります。低コストの間にどうやってバグを潰すか考えることを、もっと重要視すべきだと思います。
-末村
幅広い視点でプロダクトを作る、いわゆるプロダクトマネージャーやステークホルダーにもテストに参加してもらうメリットはありますか。
-若林
そうですね、どのみち受入れテストには参加してもらう必要があるので。スクラム開発はスプリントごとに（反復しながら）受け入れテストを実施して、プロダクトオーナーに確認してもらう流れは大事だと思っています。早い段階で目的の成果物に向かっているか、品質も含めて確認してもらうメリットはあると思いますね。
-末村
何をつくるのか考える役割の人が最後にチェックするのではなく、最初から参加して共通認識を持つこともシフトレフトになりますよね。
-若林
その考え方もおもしろいですね、テスト担当が要件定義から参加して「品質管理の観点でテストをしよう」という意見はありますけど。そもそもクライアントからの正しい要求なのか、作りたいシステムなのかという目線で、プロジェクトマネージャーやステークホルダーに見てもらうことは効果があると思います。
-末村
最終的に要件にそぐわない、間違った仕様のシステムは作られにくくなりますよね。機能が正しく動作していても、間違ったものを作ってしまったら開発側がうまく回っていないかもしれません。
-若林
開発と品質部門は元々独立して動いていましたが、スクラムが盛んになりアジャイル開発が主流になれば一緒にやらざるを得ないので。ですが実際の組織ではうまくいかなかったケースもあるんです。
とあるプロジェクトで開発の人がテストに対して協力的でプロジェクトが成功したにもかかわらず、後に退職してしまったんです。理由を聞いてみるとテストのお手伝いは開発部門としては評価の対象にはならなかったと。せっかく協力関係が出来ていたのに、組織として評価されないことは悲しいリスクを生んでしまいました。
優良なプロダクトをお客様に提供することが、組織としての目的にしてほしい。本来スクラムというのは、開発とテストの縦割りがないはずですからね。組織として一体的に取り組むことがより重要なんだと思います。
– 手動でテストすべき領域とテスト自動化が向いている領域とは
-若林
テスト自動化に一番向いているのは、手順が確立されている、期待値を明確にできる、機械的に繰り返し実施できることが本筋だと思います。ですがもっと重要なのは、手動と自動の切り分けることで品質を向上できるか、品質を守れるのかという目線だと思っています。
自動テストでおこなう回帰テストやリグレッションテストは、品質が守られていることを確認することに当てはまるでしょう。一方で新しい機能や新規でリリースといった対応は、これから品質を上げていきたい機能です。
使いやすさといったUI/UXのユーザビリティの確認をしたい、探索など込み入ったテストという領域は手動テストでないとできません。人間の目線で品質をもっと上げる、ゼロから100に品質を上げてリリースすることは、手動テストが向いていると思いますね。自動テストにおいては技術的な部分などで、昔はできなかったけど今はできることなどありますか？
-末村
技術の進歩で一番大きいのは、ビジュアルリグレッションテストだと思います。昔と今のスクリーンショットを比較して、どれだけ差分があるかを確認する機能です。従来のやり方だとピクセル単位の単純な比較しかできず、1ピクセルずれると差分が100%になってしまいました。今はスクリーンショットから各UIコンポーネントを解析、比較して差分確認ができるようになりつつあります。人の目でしかできなかったことが、できるようになった一番いい事例だと思います。
-若林
より使いやすいという目線のテスト、たとえばYesとNoのボタン位置が一部の画面だけ逆になっているケースは、意図がない限り指摘をします。UIを意識してあえて変えているなど、ユーザービリティ向上を機械的に検出できる要素はこの先ありそうですか？
-末村
ABテストが比較的それに近いのではないでしょうか。複数のユーザー層にランダムでいくつかのユーザーインターフェースを見せることです。たとえばボタンの色でどちらがコンバージョン率が高くなるか、「購入する」と「カートに入れる」の違いでどちらがより商品を購入するのか。本番環境で実施するテストですが、傾向を調べるテストの実験としてはアリですよね。
-若林
現時点において自動テストは単純作業、繰り返し作業、膨大なデータトリブンで行なうテストなど機械的な部分になりがちですが、自動化ツールを提供している側としてテストを自動化して欲しい部分はありますか？
-末村
たとえばゲームデバッグでよくある壁抜けテストは、AIなどを利用したオートパイロット（自動で動くロボット）でテストするケースが多いんですよ。手動でやると果てしなく時間がかかるので、このようなツールはどの企業も内製で作っていると思います。
-若林
そうすると品質を上げるためのテストは、必ずしも手動が良いことではないかもしれませんね。
-末村
正解を決められないものは、やはり手動テストがいいと思います。壁抜けテストはできないことができてしまう確認をするためのテストですよね。分類としては「純然たる自動テスト」「自動と手動のハイブリッド」「純然たる手動テスト」みたいにグラデーションのような状態がいいのではないでしょうか。
-若林
自動テストはあくまでも手段のひとつであり、何を実現したいのかでテストの領域は変わってきます。コストを考えるのであればコスト重視によるテストのやり方、スピードならスピード重視の分け方でもいい。膨大なリソースをかけてもいいから、とにかくバグを潰したいであればすべてを自動化するのが最善かもしれません。目的を見据えてどのように達成できるのか、正解を模索している状態が一番いいと思います。
– 最後に
Autifyならノーコードでテストが簡単に作成できるので、エンジニアかどうかを問わず、チームでQAに取り組むことが可能です。また、作成後のテストシナリオはAIがメンテナンスをサポートし、使い方に困った際のサポートセンターも充実しています。本レポートを見て、テスト自動化に興味を持たれた方は、ぜひAutifyの14日間無料トライアルをお試しください。
Autifyではこの他にも品質保証やテスト、アジャイル開発に役立つ資料を無料で公開していますので、ぜひこちらからご覧ください。