NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Tokyo

はじめに

2021年3月15日から2日間にわたり、JaSST Tokyoが開催された。2020年は新型コロナウイルス感染症(COVID-19)のため、開催が中止となっていた。今回は三密を避けるため、イベントプラットフォームEventHubを使用しての開催となった。

A0) オープニングセッション
オープニングセッション
(JaSST Tokyo 実行委員会)

オープニングセッションでは、JaSSTを運営しているNPO法人ASTERの概要の説明があった。JaSSTの説明だけでなくテスト設計コンテストや資格認定であるJSTQBの認定者の増加をはじめとした、脈々と続けられている活動の現状について説明があった。
情報の発信チャネルはSNSやYouTubeにも広がっている。SNSではTwitterで「桜子さん（@helpsacchan）」を介してソフトウェア系の用語や質問に回答している。YouTubeでは「ASTERオンラインセミナー」でASTER標準テキストの解説をしている。
また、これまでのJaSSTの講演に関しては、「レジェンドアーカイブ」として纏める活動の最中であるとのことである。

A1）基調講演
「Being Agile about Architecture」
Joseph W. Yoder 氏（Refactory CEO）

アジャイルチームにとって、開発を進めながら品質を高く保つことは非常に重要である。アジャイルとはプロセスではなく在り方である。非常に短いスプリントでフィードバックや改善を繰り返すという在り方である。そのため、ハードウェアでもアジャイルは適用可能で、テスラではスクラムを取り入れている。
しかし、アジャイルですべてを解決できるわけではない。アジャイルのプラクティスを単純に守ることで、持続可能なアーキテクチャが現れるわけではない。ビジネスや技術は常に変化していて、継続的にモニタリングをすることが必要である。
アジャイルチームにとってソフトウェアアーキテクチャを進化させるためのプラクティスに焦点を当てたパターンを紹介する。まず、パターンとは何であろうか。パターンとはグッドプラクティスと言い換えることができる。
知見を共有し、成功したことも失敗したことも共有する。
アーキテクチャを検討する出発地点として"Climbing on the shoulders of Giants."を使用する。これまでの技術を参考にすることを指しており、巨人とはReferenceのことをさしている。例えばMicrosoftはAzure Reference Architecturesを提供している。しかし、Reference Architecturesをそのまま流用するだけでは自身のプロダクトには課題があるかもしれない。そのため、自身のプロダクトの課題を見極めてReference Architecturesを適用することが必要である。その次に、一番問題のある事柄を定義し、いつ品質についての問題を検討するかロードマップを作成する。さらに、アーキテクチャそのものをテストする。これはデータベースや、マイクロサービス等、システムを通じてテストをする。出来るだけ早期にテスト設計を行うことが望ましい。
開発を進めていくと、技術的負債が発生することがある。発生した技術的負債は放置しておくとリリースを妨げる要因になりかねない。そのため、技術的負債にいつ対応するかをバックログに追加し、管理することが重要である。
アジャイルでは改善やフィードバックを繰り返すが、改善するためには立ち止まることが必要である。これをSlack Timeという。走り続けて燃え尽きてしまう可能性があり、また、立ち止まる余裕すらないスケジュールでは問題が起こったときに対応する時間がない。速さは大切であるが、速さと生産性は同じではない。アジャイルチームにとって大切なのは目的を達成することである。時間に余裕があるからといってタスクを次から次に実行するのではなく、アーキテクチャを考える時間にあててほしい。
最後に、アジャイルは無能を救うことはできず、技術力は必須である。皆さんは何に価値を見出しているだろうか。個々人によって違うはずだが、大事にする価値を考え、大切にしてほしい。"If you think good architecture is expensive, try bad architecture." という言葉を引用し、この講演は終わりとする。

筆者感想

アジャイルに関する用語が飛び交っていたので、手元で用語の意味を調べながら聴講していた。初めて聞いた用語としては、Slack Timeがあった。普段の業務では時間に追われ続け、少しでも余裕があったら次の業務や他のメンバーの業務を引き取るというチーム全体の最適化を考えていたが、時間にも心にもゆとりが無くなっていたように思う。ゆとりがないと考え方が硬直したり、ミスも発生しやすかったりしたため、Slack Timeを導入できないか考慮したい。
また、「アジャイルは無能を救うことはできない」というフレーズが心に残った。開発手法によらず、自身が技術研鑽を行うことは必須であり、肝に銘じる。

A3-1）論文セッション
「Excel方眼紙を廃し，仕様書のレビュー効率・品質を向上した事例」
熊川 一平 氏（ＮＴＴデータ）

Excel方眼紙という言葉を耳にしたことはあるだろうか。Excelの行と列の幅を変更して方眼紙のように使用することを指す。ソフトウェア開発でもExcel方眼紙を用いたドキュメントは存在しているが、バージョンの管理が困難であったり、データを採取しにくいといったりした問題があった。さらに、近年のソフトウェア開発でGitやGithubを使用して修正前後の差分を元にレビューするというツールにも馴染まない。さらに、同じファイルに対して複数人が修正をすると衝突が発生することもある。
そこで、「達人プログラマー」という書籍からヒントを得て、プレインテキストでドキュメントの管理を行うこととした。PlantUMLを使用することで、プレインテキストでUMLを管理することも可能であった。
プレインテキストでのドキュメント管理を行うことで、レビュー全体にかかる時間は短縮された。一方で、ユースケース図と画面遷移図だけはレビューにかかる時間が増えた。この理由を探るべく、レビューでの指摘事項を考察した。Excel方眼紙を使用して作成したドキュメントのレビュー指摘事項は、フォーマットに関するものが多くを占めていた。一方で、プレインテキストで作成したドキュメントのレビュー指摘事項は設計内容に関する指摘が多くを占めていた。プレインテキストにすることにより、よりレビューしてほしい観点に集中することができたと言えよう。

筆者感想

「Excel方眼紙」という単語に反応し、このセッションを聴講することを決めた。セル結合されていてデータを抽出しにくい、レビューしようにも前後の差分が分かりにくいといった筆者の実体験にかなり近い内容だと思ったからである。
導入に際して障壁になることが「変化を恐れる心」ということも、非常に興味深かった。変化を望まない理由が怠惰ではなく恐怖であるのなら、その恐怖を解きほぐす活動が必要であると、筆者自身も痛感した。

A3-2）論文セッション
「組込みシステムにおけるロバスト性の検証を目的とした テストケース設計手法の提案」
小口 一浩 氏（宇宙航空研究開発機構（JAXA））

組込みシステムには、大きく2つの特徴がある。1つ目の特徴は、ハードウェアを長時間占有するタスクとなることがある。処理対象のデータが膨大な場合だけでなく、気温などシステムの置かれた環境が影響する。2つ目の特徴は、タスクを実行する外部インタフェースが多種多様ということである。ユーザが直接操作することで実行されるタスクもあれば関連するシステムが実行するタスクもある。これらの特徴により『高負荷タスクによりタスクの実行順序が変わっても、情報の一貫性が保たれる事』というロバスト性の検証が困難となっている。
このロバスト性を検証するためのテスト条件の抽出方法として、①欠陥情報から発生条件の抽出、②リスクシナリオ発生条件の導出、③リスクシナリオの作成、④テスト条件の詳細化、という4段階に分ける方法を提案する。工夫として、①ではデータの入出力という構造ビューと、それを行う時系列のビューを用いることにより欠陥の発生条件を識別する。③ではGSNを用いて多数の欠陥情報から欠陥条件をツリービューとして集約している。さらに④ではガイドワードを使用し、時間経過によって発生する欠陥の発生条件を考慮している。
提案手法の実証実験を行ったところ、提案手法を使用しなかった場合には識別できなかったテスト条件よりテストケースを追加することができた。

筆者感想

普段の業務でロバスト性という単語を耳にする機会が少なかったのだが、タスクを実行する外部要因に目を向ける必要があると気づく機会になった。また、ツリービューもGSNを使用したことで、テスト対象の仕様変更に追従しやすいと感じた。

B5）企画セッション
「WACATE流テスト分析のワークショップを体感してみよう」
風間 裕也 氏（WACATE実行委員）
角田 俊 氏（WACATE実行委員）
常盤 香央里 氏（WACATE実行委員）
中村 仰志 氏（WACATE実行委員）
並木 正典 氏（WACATE実行委員）
山口 寛子 氏（WACATE実行委員）

夏と冬に1泊2日の合宿形式で大規模勉強会を開催しているWACATEというコミュニティがある。その特徴は【ワークショップ形式で参加者が実際に手を動かして学ぶ形式の勉強会】、【参加者・実行委員含めて全員が積極的に発言し考えることでコミュニケーションをとりつつ学ぶ勉強会】という3つである。
ワークショップを通して、自身で気づいて学ぶことに重点を置いている。そのため、まずは自身で手を動かして考え、さらにグループでディスカッションをして気づきを得る。今回はグループでのディスカッションをする代わりに、WACATE実行委員のディスカッションを聴講する。
モデルを使用して電卓のテストを考えるワークを行い、実行委員が行ったディスカッションを聴講した。モデルに用いた言葉の定義に対する認識をそろえていた。さらに電卓というテスト対象への認識のずれが表出し、その認識のずれを否定することなくさらにディスカッションを進めていた。
今回のワークショップでは、モデルを使うことで、広範囲なテスト観点を見つける体験をした。さらに、一人で考えるときとグループディスカッションを通して見つけられるテスト観点に違いがあることを体験した。

筆者感想

実行委員のグループディスカッションで、モデルやテスト観点として挙げた一つ一つの言葉に対して認識をそろえていたのが印象的であった。「入力」「出力」といった一見誰でも同じイメージを描きそうなことでも、「私はこのように理解している」と口にしながらグループとしての合意を形成していた。
また、誰一人として互いの意見に反論をすることなく、一度受け止めてから意見を述べているのが印象的であった。安心して意見を出し合える場であるからこそ、お互いに知識を共有することができるのではないかと感じた。

A6-2）一般公募セッション
「テストツールまるわかりガイドv2.0解説します」
井芹 久美子 氏（ASTER）
伊藤 由貴 氏（ASTER）
須原 秀敏 氏（ASTER）

テストツールの選び方やテストツールのリストが掲載されている『テストツールまるわかりガイドv2.0』が2020年9月に発行された。このガイドの使い方について説明する。
前提として、今回のv2.0はv1.0の内容を踏襲したものであり、すべてを書き換えたわけではない。一方で、v1.0とはドキュメントの構成を変更した箇所もある。
テストツールまるわかりガイドv2.0は、ガイド部とツール部に分かれている。ガイド部にはテストツールに関する基礎知識が掲載されている。ツール部には、テストツールの情報が掲載されている。このツール部は、GoogleスプレッドシートとPDFに分かれている。このツール部の記載がv2.0で工夫をした箇所である。
ツール部のPDFとGoogleスプレッドシートは、状況に応じて使い分けが可能である。PDFはテストツールのカタログとして使用することができる。Googleスプレッドシートは、動作環境や困りごとなど、現状の課題を解決するためのツールを探すことができる。
また、ツール部のうちGoogleスプレッドシートは、新しく記載する内容を一般から公募しており、そのチュートリアルも行った。

筆者感想

テストツールを探すとき、更新頻度が一定かつ客観性の高い文献を探すのに常々骨を折っていた。今回のv2.0からはツール部のGoogleスプレッドシートの部分だけを見て、自身の課題解決に合致するツールを探すことができるため、便利であると感じた。また、Googleスプレッドシートであるため、更新されたらリアルタイムで知ることができるのも利点であろう。
ガイド部も、テストツールだけでなくテストの必要性に立ち返ることが可能な内容となっていたので、テストの入門書として読むのに適しているのではないかと感じた。

D8）一般公募セッション
「仕様整理のためのテスト設計入門」
河野 哲也 氏（DeNA）

多くのWeb系企業のQA組織では、開発組織内でコーディングとテストが行われた後、ある程度出来上がったプロダクトに対してテストを実施する。しかしながら、不具合を見つけた際に起票することにも、それを修正することにも、さらには修正されたことに対するテストにも時間を有する。一般的なアプローチは大きく2つある。不具合を早く見つけることと、不具合の作りこみを防ぐことである。これら2つに対し、テスト設計技法を活用することを提案する。
多く存在するテスト設計技法のうち、同値分割（境界値分析）、デシジョンテーブル、CFD法、状態遷移の4つを取り上げ、演習を行う。

筆者感想

演習を通し、曖昧な表現で書かれた仕様を、テスト設計を通して具体的に考える体験をした。デシジョンテーブルに記載する条件は、実装する場合は条件分岐の上から順に記載することなど、あくまで開発者自身がテスト設計技法を用いて仕様の整理を行うことを考慮している。
一方で、主にテストを担当する筆者自身の学習の助けにもなった。デシジョンテーブルの圧縮手順や、状態遷移図を状態遷移表にする手順は、筆者自身がソフトウェアテストを勉強した当初は書籍を見ても理解しにくく、悩むことの多かった箇所である。
テスト技法について自身が正しく理解しているかふりかえるためにも、とても為になる講演であった。

A9）招待講演
「パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術」
鷲崎 弘宜 氏（早稲田大学 / NII / システム情報 / エクスモーション）

従来型の開発手法では、顧客と開発者の距離が離れてしまう。この距離が離れてしまった期間にビジネスの在り方が変化し、顧客との価値観がずれてしまう。一方で、アジャイルの場合は従来型の開発手法と比べて小刻みに打合せを行うため、顧客と開発者の距離が離れにくい。また、ビジネスをはじめとした変化にも適応しやすい。品質保証の考え方も、従来型の開発手法とアジャイルでは異なる。従来型の開発手法ではゲートキーパーの役割であったが、アジャイルでは開発のロードマップ策定から日々のモニタリングに至るあらゆる段階でチーム全体となって取り組む活動となる。アジャイル品質へと変わっていくためのパターン集を紹介する。
パターン集を紹介する前に、なぜパターンを用いるのかを考える。そもそもパターンとは何であろうか。パターンとは、問題と解決を抽象化してまとめたものを指す。アジャイルの源流に、パターンランゲージと生産・品質管理の考え方が存在する。このため、パターンはアジャイルと馴染みがよいのである。
Quality Assurance to Agile Quality（以下、QA2AQ）より、他のパターンに共通する考え方やプロセスである「障壁の解体（Break Down Barriers）」と「アジャイル品質プロセス（Integrate Quality）」を紹介する。まずは「障壁の解体（Break Down Barriers）」を紹介する。物理的、文化的、専門性といった様々な障壁がチーム内には存在する。QA担当者がチームに早期から参画することで品質に対する考え方をチームに浸透させることができる。そして、品質に対する注意をチーム全員で払うように行動する。次に、「アジャイル品質プロセス（Integrate Quality）」を紹介する。QA担当者をチームに迎え、Oneチームで取り組む。QA担当者は重要な品質を特定し、品質ストーリーの作成を支援する。
品質に関する活動を可視化するために、品質ダッシュボード、品質ラジエータ、品質バックログを使用することもある。可視化をすることで品質のモニタリングを行う。

筆者感想

アジャイル開発に参画する機会が増え、QAとしての在り方を変えていかなければならないと考えていた矢先に、今回の講演があった。エンジニアやプロダクトオーナーと話す機会があるため結果的に橋渡し役をすることもあったが、「障壁の解体（Break Down Barriers）」によって、まずはチーム内に障壁がある可能性を認識した。普段の業務の中では、チームメンバーと共に過ごす時間が長い。そのため文化や専門性の違いがあっても当然と捉えていた。一方で、それが「これは私の役目ではなくあの人の役目」といった他人事で考えてしまうきっかけになっているということに気づけていなかったのではないか、と思い至った。

A10) クロージングセッション
クロージングセッション
（JaSST Tokyo 実行委員会）

善吾賞とベストスピーカー賞の発表が行われた。善吾賞は名倉正剛氏、田口健介氏、高田眞吾氏による「コーディング規約違反メトリクスに基づきソフトウェア変更に対して不具合混入を予測する手法」である。ベストスピーカー賞は熊川一平氏である。
最後に、実行委員長である越中谷氏から、今回のJaSST Tokyoへの想いが語られた。2020年新型コロナウイルス感染症(COVID-19)のため、開催が中止となってしまった。今回は安全性を鑑みて、初のオンラインでの開催となった。一方で、オンラインで開催したことにより、地域や国の垣根を超えることができた。また、AIやQAに関する知識が革新されていると感じた。

おわりに

2日間にわたるオンライン開催であったが、音声トラブル以外は大きな問題もなく聴講することができた。オフラインのように肌で会場の熱意を感じることは難しいかもしれない。一方で、時間・場所・金銭の制約が減少したことにより、参加のハードルはかなり低くなったのではないかと感じた。
基調講演、招待講演だけでなく、これまでのやり方に執着することなく現在の課題に向き合う必要性を痛感した。私自身だけでなく、チームと共に成長する方法を模索しようと思うことのできるシンポジウムであった。