皆様こんにちは、ざわ です。
2024年8月23日(金)に開催された、JaSST’24 Hokkaidoに参加してきました。
初めてのJaSST参加で緊張しましたが、有意義な時間を過ごすことができました！
基調講演の内容を主に、参加レポートを書いていきたいと思います。
今回のテーマ：りすっきりんぐテスト(テストリスキリング)
今回のテーマは、「りすっきりんぐテスト」とし、テスト技術・知識を学び直し、より深くそして新たに身につけることを目指します。
(中略)
みなさんと一緒に学び直し、新たな可能性を考え、再度(Re)すっきりとした気持ちでテストに向き合える。そんなシンポジウムにしたいと思います。
JaSST’24 Hokkaido 開催要項
日々、技術が進歩していく中で、自分の技術はその進歩に追いついているだろうか？ また、追いつくために今、何を学び、身につけていけばいいのだろう？ そんなことを考えていた私にとって、「リスキリング」というテーマは特に心に響くものでした。
(「りすっきりんぐ」が可愛らしくて、ぐっと肩に入っていた力が抜けたのは秘密。。。)
普段、テスト設計やテスト実装を主に担当する中で、すでに知っていて活用している内容もあれば、普段あまり触れない部分の話もありました。知っているからと、振り返ることを怠っていた部分も、新たな知識とともに見直すことで、見落としていたかもしれない部分が見えてきました。まさに「再度(Re)すっきり」という気持ちです。
基調講演：「ソフトウェア品質のダンジョンマッピング」
登壇されたのは、株式会社 日立製作所 サービスプラットフォーム品質保証本部 担当部長の鈴木一裕様です。
広く奥深いソフトウェア品質の世界を、RPGの剣と魔法のダンジョンに見立て、戦士や僧侶などのRPG職業がそれぞれQAで何が得意なのかを考え、自分が現場から離れている今、どの職業に該当するか…そうか、マッパーだ！ という発想から、このタイトルになっているようです。(マッパーという職業は初耳でした！)
ソフトウェア品質のダンジョンを進みながら、次々と登場するキーワードを数珠繋ぎにしていく中で、自分が知らなかった分野を学び、リスキリングのネタを見つけてほしいというお話でした。(RPGに例えられるとワクワクしますね！)
基調講演は90分間でしたが、大変面白く、また興味深く拝聴したので、あっという間に感じました。
大まかな講演の流れ
「ソフトウェア品質保証」という広大なダンジョンに、どこから踏み込んでいくのか…。まず、多くの人々が入口とするであろう「テスト実行」から始まり、次に「バグ管理とバグ分析」→「テスト管理・計画」→「テスト実装」→「テスト分析・設計」→「レビュー」→「プロセス改善」→「品質と価値」→「QAエンジニアの仕事」という流れで進んでいきます。
最後に「90分ではとても歩き切れませんでした」とおっしゃっていましたが、こうして概要を見ただけでも、ソフトウェア品質のダンジョンがいかに広く深いかが伝わってきますよね。すべてについて語りたいところですが、ダンジョンはあまりにも深遠ですので、今回は特に重要なポイントをピックアップしてレポートしたいと思います。
なぜあなたのテスト実行は退屈なのか？
ダンジョンは「テスト実行が退屈だという方はいますか？」という問いかけから始まりました。
この問いかけに積極的に手を挙げることはなかったとしても、誰しもがテスト実行中に「退屈だ」と感じる瞬間があるかもしれません。会場内の皆様も同じように感じたのではないでしょうか…私もそうでしたし、私の席から見える範囲では、挙手された方はほとんどいませんでした。(とはいえ、鈴木様もこれを想定されていたのか、会場を和ませる笑いに変えてくださいました)
テスト実行が退屈に感じられる要因として、以下の点が挙げられました。
- 要因1: 単調な繰り返し
- 要因2: テストの必要性が不明
- 要因3: 厳密すぎる手順
- 要因4: 無秩序なプロセス
- 要因5: バグが出ないことへの苦しさ
これらの要因は、これまでの経験からもよく理解できるものばかりです。それに対して、対策として以下の5つのアプローチが示されました。
- 自動化
- テスト分析・設計
- 柔軟なテストおよび探索的テスト
- ユーザ価値の深い理解
- テストの目的の確認
ただし、各要因に対する対策は一つだけではなく、複数のアプローチが有効であることが多いです。
例えば、要因3の「厳密すぎる手順」については、対策として「テストの自動化」と「柔軟なテストおよび探索的テスト」が示されています。テスト実行は本来、知識や理解力、観察眼、さらにはコミュニケーション能力など、さまざまな能力が求められる難易度の高い作業です。プロダクトを理解し、お客様にとっての価値を判断するのは、結局のところ人間の力によるものであり、そのため「テスト実行を推していこうよ」という考え方が示されました。確かに、QAは上流の作業だけでは完結しません。
手動でテスト設計を主な業務としている私にとって、求められているテストがどのようなものであるか、そしてプロダクトの価値をしっかりと見極めて分析・設計を明確に行うことは、非常に重要であり、またすぐにでも実践すべきことだと思います。それは「退屈でない」テスト実施だけでなく、QAの質を向上させることにも繋がるのではないでしょうか。
テスト設計を進めるうえで、改めて「分析」の重要性を見直し、明確で価値のあるQAを実践していきたいと考えています。例えば、過去の事例から学ぶことも大いに有効だと思いますので、まずは鈴木様が紹介されていた本を読んでみるつもりです。過去事例を知り、知見を広めていくことで、同様のケースでなくても応用できると思いますし、自分とは異なる考え方を知ることができ、そうして取り入れた知識や視点でプロダクトに向き合うことで「分析」の一助になるのではないかと思っています。
テスト実行に限らず、他の点についても同様ですが、多角的な視点で物事を見つめることが重要であると感じました。
▼関連記事
テスト分析の必要性
テスト設計技術も進化しており、従来の技法の親戚的な技法や、アジャイル開発、機械学習、AIとともに普及が進んだ技法、非機能要件やドメイン固有のテスト技法が挙げられています。この分野は常に進化し続けており、勉強のし甲斐があるというお話がありました。
基調講演から話は逸れますが、今回のワークショップ「技法を探せ！」では、示されたお題に従ってどのようなテスト技法を適用できるかを探し、また他の参加者が見つけたテスト技法を知ることで、今後のテスト設計に役立てることが目的とされました。
限られた時間の中ではなかなか難しく、知識や技術をうまく応用するためには、やはり勉強を続けて身につけていく必要があると感じました。
「テスト分析の必要性」という見出しをつけましたが、設計の話に移ってしまいました。なぜなら、これらの設計技術を活用してテスト設計を行うには、「テスト分析」が先に行われるべきだからです。
テスト設計は「プロダクトの何をテストするのか」という点から始まりますが、その「何」を決めるためにはテスト分析が不可欠です。テスト分析は「テストを通じてどのように品質保証するのか」という全体像を描く技術として位置づけられています。
テスト設計を進める中でテスト分析を行っているつもりでも、全体像を描けているかというと、まだ足りないと感じることがあります。「QAエンジニアとして、この全体像を描く技術を身に着けるべきだ」との指摘がありましたが、「全体像を描く」というスキルはテスト設計だけでなく、管理などの分野にも重要であると感じました。
生成AIの活用
今回の基調講演では、生成AIの活用についても言及されました。
- バグ分析：生成AIを使ってバグ分析を行うようになる可能性
- テスト設計：生成AIを活用したテストの適用により、機械学習におけるテスト設計の課題を解決していく
- レビュー：「チェックリストベース」のレビューを生成AIで実施できるようになる可能性
様々な部分で活用が進められているAIですが、具体的な用例とともに言及されたのは、AIをうまく活用するためには「言語化能力」が改めて求められるという点です。
確かに、生成AIに対して内容が明確でない問いかけを行うと、求めている答えとは異なる返答が返ってくることがあります。単なる趣味で一文尋ねた場合でもそのように感じることがあるため、QAの各分野に活用する際には、人間側のロジカルな言語化能力を鍛える必要があると感じます。
QAとは直接関係がないのですが、小学生の社会・算数・理科の成績と国語の成績には高い相関関係があるという学術記事を読んだことがあります。かなり古い記事なので、その内容が現在も学術的に認められているかは分かりません。
しかし、読解力や表現力などの国語の基礎学力が他の教科に影響を及ぼすという点と、生成AIに内容を理解してもらうために言語化能力が必要だという話は、人間とAIのやり取りにも相関関係があるように感じられて、興味深いと思いました。
技術の勉強は、学んだ直後にすぐ応用できるほど簡単なものだけではないかもしれません。しかし、技術の習得を続ける中で、それを自分なりに理解し、応用できるようになるためには、ロジカルな思考力と表現力が必要だと改めて感じました。
これらの能力は、QAの分野だけでなく、社内外でのコミュニケーションにおいても重要だと思います。「日本人はハイコンテキストであることを自覚する」というお話もありましたが、私自身、つい「こう言えばこう伝わるはず」と前提を置いて話してしまい、言葉が足りなくなることがあります。
「伝える」ということは、自分がしっかりと理解していないと難しいものです。例えば、ユーザー目線のテストを行う際にペルソナを用意するように、知識がない状態をイメージし、その状態でどのような伝え方をすれば理解を促せるかを考えることは、自分の中で情報を整理し、かみ砕いて理解するための有効な手段だと思います。
技術やツールについての情報を取り入れることも重要ですが、こうした考え方を取り入れることで、今すぐにでも実践できることから始めていきたいと考えています。そうして技術だけでなく、言語化といった基本的な能力も鍛えていきたいと考えています。
「今」の品質
従来の品質メトリクスとアジャイル開発における品質メトリクスの違いについて、旧来のメトリクスは「開発」にフォーカスし達成した状態を評価しているのに対し、アジャイルでは「開発」と「運用」が一体となり、達成する能力そのものが品質として評価されるという点を比較して紹介されていました。
私自身はアジャイル開発に携わったことはありませんが、アジャイル開発に限らず、近年のQAの進化により、後者のアプローチが求められているように感じることがあります。それは、QAの手法が日々進化し、よりユーザ視点での「価値」を重視するようになってきているからかもしれません。
求められる品質を理解し、ユーザ視点での「価値」を開発側に伝えることが重要だと感じています。先に述べた「こうしていきたい」という考えにも関連しますが、「しっかりと分析」し、「ロジカルに言語化」することで、「品質」への理解が深まるのではないかと思います。これらのスキルを磨いて、自分のQAをより価値のあるものにしていきたいと考えています。
おわりに
いくつかの点に絞ってレポートしましたが、いかがでしたでしょうか。私の感想としては、今の生成AIでは担えない「人間」としてのQAエンジニアの価値を見出していけたらいいなと強く感じた90分間でした。
基調講演では、面白く興味深いお話もあれば、つい背筋が伸びてしまうような重要なお話も盛りだくさんでした。ソフトウェア品質ダンジョンの広さを感じつつも、少しだけ覗けたという印象です。その中で、「リスキリングのタネ」も随所に見つけることができました。
鈴木様が公開されている講演スライドは、ソフトウェア品質ダンジョンのマップを手に入れたい方にとって有益ですので、ぜひ見てみてください。私はこれからもソフトウェア品質ダンジョンに潜り、リスキリングのタネを育てていきたいと思います。
最後まで読んでいただきありがとうございました。
