HOME > 活動報告 > イベント報告 > JaSST'21 Kansai

イベント報告
 ソフトウェアテストシンポジウム 2021 関西

2021年6月26日(土) 於 オンライン開催

ソフトウェアテストシンポジウム 2021 関西
「テストエンジニアのサバイバル術~After DXの世界に生き残るには」

Opening

司会の河内氏から実行委員長の堀川氏が紹介され、開会の挨拶があった。内容は以下の通り。

本年度は15年目の節目の開催である。この15年は、ソフトウェアテスト・QA活動における技術・プロセス・マインドが発展してきたが、近年の変化は更に激しいと感じている。その変化への対応が迫られるテストエンジニアの技術格差・意識格差に大きな危機感を覚えた。技術者がソフトウェアテストなどの技術を学ぶ理由を模索する中で、DX(デジタルトランスフォーメーション)という言葉に繋がった。変革を意味するDXの推進は、ビジネスの在り方、開発技術、プロセスの変化・進化であり、ソフトウェアテスト・QA活動も例外なくそれらの渦中であり、追従していかなくてはならない。これは、進化論を唱えたダーウィンの概念「適者生存」にも通じる。

上記から、今年のテーマは「テストエンジニアのサバイバル術~After DXの世界に生き残るには」とした。私たちは今回のプログラムを通して、何を想定し、何を備えるのか、学び、気付くきっかけを作りたいと考えている。DX時代を逞しく生きる強いテストエンジニアを共に目指そう。

基調講演-1
「AIによるゲーム分野テスト自動化の研究開発事例」
本城 嘉太郎 氏(monoAI technology/AIQVE ONE)

はじめに

本城氏が設立したAIQVEONE社のAIQA事業について、本城氏からスライドと動画で説明があった後、本題である「AIによる自動プレイ研究事例」が紹介された。講演概要は以下の通りである。

概要
「3Dアクションゲーム+強化学習で通しプレイAIを作る」

ゲーム開発時に通しプレイで障害を検知したいが、変更が頻繁に発生することが課題である。ビルドのたびに人間の手でデバッグをするのは手間だが、自動プレイAIをルールベースで作成する場合も、仕様変更のたびに修正する必要があり、手間である。この研究では、2つの方法を試した。模倣学習AI(人間のデモプレイを学習する)と、模倣なし強化学習AI(ランダムな行動で学習する)である。

対象のゲームはUnity付属の3Dアクションゲームで、ゲームを学習する仕組みとしてUnity ML-Agentsというプラグインを利用した。学習させる準備として、AIに与える情報と報酬を決め、レイキャスト(プレイヤーからレイを飛ばす)を用いた敵オブジェクトを検出した。

模倣なし学習で3日間学習させてみたが、最初の報酬(武器)にすらたどりつけない結果となった。自由に3Dフィールドを歩き回れるゲームに対しては、完全ランダムは現実的ではないことがわかった。

次に模倣学習を試した。Deep Q-Learning from Demonstrations(DQfD) という手法を用いた。使用したマシンは、常識の範囲内でのマシンスペックに収めた。結果は、広大なマップでも攻略できた。人間によるテストプレイの動きをある程度再現できた。ちょっとした地形の変化に対しては、ランダムでジャンプするなどの工夫を加えた。ボス戦は戦術が必要で、とても時間がかかった。なんとかボスを倒してステージを攻略することができた。しかし次のステージは、横に足場が移動する部分でタイミング良くジャンプすることが難しく、攻略できなかった。

模倣学習の研究成果としては、広大なマップでも現実的な学習コストである程度攻略できることがわかった。報酬の設定と特徴量に対するエンジニアリングが必要であること、仕様変更のたびにデモを作成しなければならない可能性があることが課題である。

まとめ

2年前からゲーム業界のQAコストが上がりすぎ、バグを取りきれない状況が続いている。それを解決するためにAIテストの研究を開始した。業界でも注目が高く、浸透してきている。業界全体として研究開発していこう。

主なQ&A
Q:
どのような不具合を対象にしている?
A:
ウAIで見つけやすいもの。壁の当たり、通しプレイでエラーで止まらない、など。特定のフィールドに立ち止まって、戦い続ける、アイテムを取り続ける、などの物量系が向いている。夜中に実行して朝に結果を確認する。
Q:
ウAIが障害を発見した際にどういう報告ができるか?
A:
ウ人間ならすぐわかる障害(OK表示の時にキャンセル表示、サウンドエフェクトが変)は、AIは苦手。止まる、異常な動作などを検出し、slackなどに報告を投稿する。
Q:
ウ神デバッガーの勘のようなものを取り入れられると理想だが?
A:
ウ複数プレーヤーでのタイミング抜けなど、当たり抜けの検出は神デバッガーの勘が頼り。それをAI化しようとしている。
Q:
ウテスト観点の反映は?
A:
ウ報酬設計の調整が該当する。ただし、AIエンジニアが毎回調整しているとボトルネックになることが課題である。
Q:
ウステージ2は学習回数を増やすと攻略できたと思うか?
A:
ウ今回は限定されたマシンスペックだった。学習回数を増やすだけでなく、異なる技術を組み合わせることも有効と思う。
筆者感想

まず、3Dフィールドを自由に動けるアクションゲームでも、AIがフィールドを進み、アイテムを集め、ボスを倒してステージ攻略できることに驚いた。ゲームのデバッグだけでなく、様々な分野での応用が考えられると思った。

基調講演-2
「品質重視のアジャイル開発 ~生き残りの鍵は、技術力と定量化~」
誉田 直美 氏(イデソン/公立はこだて未来大学)

講演概要は以下の通りである。

概要

不確実な時代だからこそアジャイル開発が求められており、実践も増えているが、顧客から品質確保の説明を求められて困っているなど、品質面での悩みが多く、テストエンジニアが活躍する時である。

ソフトウェア品質保証の原則は、プロセス品質とプロダクト品質の両面から保証することであり、この2つは相互に関連している。アジャイル開発でも基本的な考え方は同じである。品質保証は、顧客が「品質要求事項が満たされている」という確信を与えることが重要であり、証拠をもって示す必要がある。

アジャイル開発の品質確保の難しさは「短期間」というところにある。ウォーターフォールモデルやスパイラルなどの繰り返し開発と異なり、分析・設計・実装・テストをブレンドして実施することを理解し、品質保証を考える際に発想の転換が必要である。アジャイル開発の課題を挙げる。アジャイル開発宣言から20年経ち、標準的なプラクティスは、ほぼ決まっているが、知られていない。問題解決法として「自己組織化」を重視するが、時間がかかるし、客観的に判断できない。日本の品質レベルを支えてきた技術(レビュー、なぜなぜ分析と水平展開、品質ゲート、など)の利用が不十分である。アジャイル開発の主要なメトリクス(ストーリーポイントなど)が相対値であり、客観性を担保しにくい。

この状況をブレークスルーするための提言は以下の通り。ポイントは、アジャイル開発の品質保証を難しくしている「短期間」への対応である。プロセス品質:初めから品質を作り込むために、技術系プラクティスの実践と開発チーム編成を重視する。テスト系プラクティスとバグにこだわる日本の技術は、テストエンジニアの領域である。推奨する開発チーム編成は、優秀な技術リーダを置き、開発チーム員は「適用する技法を使って自由裁量部分を遂行できる」レベル以上の人材とする。プロダクト品質:品質が作り込まれていることを常に確認するDoneの定義と定量化分析し、過去や他のチームと比較分析する。推奨するDoneの定義(出荷OKの基準)を決め、客観的に審査する。

アジャイル開発はDX時代の主流になるので、品質重視のアジャイル開発で基本を学び、そこから変化させる。従来以上に技術力が求められる。テスト系プラクティスは品質保証の要であり、バグにこだわる日本の技術を活用してほしい。定量化による客観的な分析と比較は、ソフトウェア開発の基本中の基本であり、顧客の納得性を高める。テストエンジニアの生き残りの鍵は技術力と定量化である。著書「品質重視のアジャイル開発」を活用いただきたい。

主なQ&A
Q:
プラクティスの流行り廃りはないのか?
A:
アンケートによれば、上位のプラクティスは10年以上変わっていない。やるべきことは変わらない。
Q:
アジャイル開発宣言にはプロセスよりコミュニケーションと書かれているが?
A:
結果が全て。プロセスを軽視した結果として品質がダメならプロセスを重視すべき。
Q:
プロセス品質のDoneの定義についてイメージが沸かなかったのですが?
A:
静的解析・カバレッジ・自動テスト実行、設計に関する文書化を第三者が確認することを推奨している。
Q:
アジャイル技術者の育成に対する考え方は?
A:
技術者にはアジャイル開発に対する向き不向きがある。全員を転換しようとしなくて良いと思う。
Q:
新人の教育にはアジャイル開発はお勧めではないのか?
A:
新人は技術があってやる気もあるが、ソフトウェア開発の基礎がわかっていないので、新人だけでは失敗する。
Q:
ストーリーポイントの使い方を難しいと感じている。結局時間に換算してしまうのでは?
A:
ストーリーポイントを使う理由はチーム内で上手く会話するためのもの。第三者にはわからなくて良い。
Q:
定量化に関して。ウォーターフォールモデルでは細かく収集すると煩雑になってしまって毛嫌いされた経験がある。
A:
アジャイル開発ではタスクに分割して実績を記録したものを集計すれば良い。ウォーターフォールモデルよりも収集は簡単と思う。
筆者感想

メーカーで長年品質活動に関わっていた誉田氏によるアジャイル開発の講演では、ウォーターフォール開発が主流だった日本企業について納得のいく内容だったと思う。アジャイル開発の特徴である「短期間での開発・品質確保」に対応するためには基本を踏まえた上で発想の転換が必要であること、日本企業が築き上げてきた「品質の作り込み」の考え方がアジャイル開発でも有効なことを学んだ。

招待講演
「QAチームの役割の拡大と、QAエンジニアに求められるスキル」
田中 学二 氏(メルペイ)

講演概要は以下の通りである。

概要

DXが推進されている現状として、身の回りのDXでは生活スタイルが変わり、仕事でのDXでは仕事のスタイルが変わってきている。多くのソフトウェアが開発される中、ソフトウェアの特性に合わせて様々な開発手法が適用されている。中でもアジャイル開発手法の導入が更に進んでいく。今後は、ビジネス環境への変化に対応し加速させるために、データドリブンでの運営と継続的な改善が行なわれる。DevOpsのような会社全体でコラボレーションしてサービスを提供することが必要である。

上記を支えるためのQAチームの活動も変化する。継続的にリリースする中で、全ての開発フェーズでQA活動を行えるよう体制を構築する。プロジェクトの規模に合わせて柔軟に変化できるチーム作り、同時並行で運用と新規開発プロジェクトでQA活動を行なう。このように、QAチームの活動はDevOpsにより範囲が広がっている。

QAエンジニアに求められるスキルも広がっている。基本的なソフトウェアテストスキルだけでなく、アジャイル/DevOpsの知識、コミュニケーションの能力、自己解決の能力、テスト自動化、ツール利用、プログラミングスキルも必要である。このように、開発プロセス全てでQA活動を行なえるQAエンジニアスキルが求められている。

メルペイのQAチームでは以下の活動をしている。

  • 計画フェーズ:テスト自動化を含めたテスト計画
  • 要件定義フェーズ:各マイクロサービスに対する横串でのアドバイス、新しい仕様が既存仕様にもたらす問題の指摘
  • 設計フェーズ:再利用可能なテストケースの作成、関係者全員を集めたレビュー会、テストコードの実装
  • 実装フェーズ:フロントより先に開発されるバックエンド側のAPIテスト、リグレッションテスト、バグ分析
  • リリース後:機能改善・課題解決の推進、主要機能の自動テストを作成しリリースを支援

QAエンジニアが不足している。AIや自動化に置き換わってきているが、優れたQAエンジニアを採用していくかが課題。

QAチームは、変化に対応しながらテクノロジーを用いてお客様に選ばれる品質のサービスを継続的に提供する活動を全員で行なう。メルペイでは「全員品質」と呼んでいる。QAエンジニアは、技術や知識が変化する中、「誰かに価値のあるサービスを届けるという熱い思いが一番大切な点は変わらない。そして、経営側もDevOpsに深く入り込み、サービスを使ってみることなどが経営層/マネジメント層に求められている。

主なQ&A
Q:
QA活動が経営層に認められるには?
A:
メルペイでは最初から認められている。QAは開発やPMに対して強く提言できる環境にある。
Q:
要件定義フェーズでユーザー視点のフィードバックをするために、QAチームにはどのような教育をしているか?
A:
共通的な教育ではなく、普段の業務を通して自分が必要と思ったら自ら学べる環境作りをしている。
Q:
マニュアルテストを主体としている現場から自動テスト導入に対する抵抗があった場合の対処は?
A:
自動テスト導入については、QAチームではなく開発組織全体で推進した。開発プロセスの中に自動テストを組み込みリグレッションテストを実施すると決めた。
Q:
多岐に渡る活動をするQAエンジニアの評価はどのようにしているか?
A:
四半期の最初にQAエンジニアと話して目標を決める。エンジニアのグレードに合わせて目標と達成度を決め、それを追跡する。状況の変化は1on1で調整する。
Q:
フルスタックエンジニアを目指す際に一番大切なスキルは?
A:
テスト設計のスキル。テストを自動化する目的を考えられること。コードを書けるだけでは不十分と思う。
Q:
幅広いスキルが求められるQAエンジニアの立ち上げに必要な期間は?
A:
3ヶ月は必要。QAのスキル以外にも複雑な業務仕様の理解が必要。マイクロサービスが多数あるので関係性の把握も必要。様々な業務上の条件も覚える必要がある。
筆者感想

変革の真っ只中にいる企業において、基幹となるサービスの成功を支えるQAエンジニアの活動領域や動機付けを日々考えているマネジメント層のリアルな活動と悩みを聞くことができた。今後多くの日本企業が同じ課題を抱えることになると思うので、先行する方々からの貴重なヒントを活かしたい。

基調テーマパネルセッション
「After DXの世界に生き残る」
パネリスト:
 榎 真治 氏(LibreOffice日本語チーム)
 田中 学二 氏(メルペイ)
 堀川 透陽 氏(ベリサーブ)
 誉田 直美 氏(イデソン/公立はこだて未来大学)
 松井 淳 氏(アイ・ティ・イノベーション/派生開発推進協議会)
モデレータ:
 宿口 雅弘 氏(イーソル)

モデレータの宿口氏がリードし、各パネリストが下記の項目についてそれぞれの思いを語り、討論が行なわれた。その概要を筆者が下記の通りまとめた。

概要
1. ソフトウェア開発の変革について

あらゆることがソフトウェアによりデジタル化され、ビジネスを継続かつ加速的に変革する一方、ソフトウェア開発自体に革新的な変化を求めている。既に変わり始めているし、これからも変わり続けるだろう。テーマのひとつは、ソフトウェアによるビジネスへの貢献である。次に、プライバシー、公平性、その判断の透明性など、倫理に関わるところもテーマである。そしてこれらは解答がない世界である。

2. ソフトウェア開発変革のソフトウェア品質活動への影響

産業が変わっていくので様々なチャンスが生まれる。QAエンジニアにとってもビジネスチャンスが来た。不確実性の時代だから要求も不確実であることを受入れ、その中で仮説検証(トライ&エラー)を繰り返して、アーキテクチャや要求を探索する必要がある。あいまいな中で様々なことを決めながら進んでいかないといけないが、エンジニアのスキル不足などにより、これまで避けてきたことである。ここに向き合うためには、マネジメント層の強化が不可欠である。

3. 上記(1,2,)を踏まえてテストエンジニア、QAエンジニアの在り方について

QAエンジニアのマインドを高めることが大切である。QAエンジニアの役割を限定して幅を狭めてはいけない。例えば、QAエンジニアとして良いサービスを提供することに貢献しようと伝えるなど、マネジメントの活動が必要である。もし、エンジニアの活動が限定されているのであれば、転職して新しい活動の場を探すことも選択肢のひとつになってきたのではないか。このような循環は、エンジニアも、そして企業にとっても変化すべきと気づくきっかけになる。また、エンジニアに対して技術力だけではなくビジネス視点も求められている。この循環の中でエンジニアが生き残るには、自分の武器を見つけて磨くなど、学び続けないといけない。その領域については、QAなどに限定せず、幅広いエンジニアを目指すべき。

4. 変革したソフトウェア開発における品質観点・ソフトウェアテスト観点

変化の中で、変わらないものとそうでないものがある。例えば品質の分野では、プロセス品質とプロダクト品質の考え方については変わらない。そこを見極めて、どこに重点を置くかを自分で考えることが大切である。定年も延長になり、シニアエンジニアも、好奇心を持ち続け、新しい技術を触ってみることをする。品質活動は、これからますます自動化が進む中で、QAチームだけの活動ではなく、プロダクト/サービスに関わる全ての人の活動になるだろう。日本のソフトウェア業界構造が大きく変わろうとしており、自分の技術力を磨いて自分の強みを持ち、自分の意見を言えるプロフェッショナルだけが生き残る時代になる。

筆者感想

DXというキーワードをきっかけとして、ソフトウェア業界が大きく変わろうとしていると痛感した。変革の必要性と、メルペイなどの新興企業を中心に進んでいた変革事例がこのような場で共有されることで、これから真剣に変革に取り組む企業のヒントになってほしいと思う。

Closing

実行委員長の堀川氏から閉会の挨拶があった。内容は以下の通り。

今日得ることができた多くの学びを実践に活かしてほしい。それを発表して議論の場に乗せてほしい。全国のJaSSTではLTを募集しており、発表のハードルを下げた JaSST nano も始まった。JaSSTでの活動を、テスト業界全体の発展につなげていこう。また、JaSST関西では実行委員を大募集中であり、SNSなどで実行委員を検索して気軽に問い合わせていただきたい。

最後に、司会の河内氏から「本日のJaSSTがみなさまのエンジニアライフの一助となれば幸いです」という言葉で締めくくられた。

筆者感想(全体)

JaSSTは、ソフトウェアテストというテーマから、ソフトウェアに関する品質活動全般に拡大していることを実感した。3つの講演+パネルディスカッションを通して、社会の中でソフトウェア産業が担う役割がどんどん変化している実感と、今後もエンジニアとして活躍するための心構えを学んだ。これらは以前から大きなテーマだったが、DXというキーワードで顕在化した。これらのテーマに真剣に向き合わなければならないという危機感を持った。

記:和田 憲明(ASTER)

[ページトップへ]