NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'22 Tokyo
HOME > 活動報告 > イベント報告 > JaSST'22 Tokyo
2022年3月10日(木)～11日(金) 於 オンライン開催
本会は前年に引き続きオンラインにて開催された。プラットフォームではVimeoでの動画配信及びDiscordでのコミュニケーションを行いつつの開催となった。
JaSST'22 Tokyo 共同実行委員長 片山氏よりJaSSTの開催状況やJSTQB含むASTERの概要について説明があった。
YouTubeやTwitterを用いての情報の告知や専門知識の解説も行っている。
開発を進めていくにあたって、本セッションでは成長している企業がどういった視点で世界を見ているのかと、どういう見方が違うのかの二つの観点にて説明していく。
成長している企業がどういった視点で世界を見ているのかについて、開発を行うには全てスタートアップから始まるが成功している企業は製品と市場間のフィットを最重視している。学びながら修正していくことを繰り返し行い、初めから完全なものを作るのが目的ではない。
プロジェクトを考えた企業（ここではプロジェクト企業とする）の問題点としては成果物を一回のみ作成し、修正等を行うことがない・目標を期間内に作成した・予算内に収まったという考え方が問題点として挙げられる。それに対して成功している企業（ここではテック企業とする）は目標が、顧客からのフィードバックを基に改善を続けていくことである。またテック企業では、スクアッドが自分自身でミッションの見積もり、維持を行っていく。
ただ、そこで発生するスクアッドの問題点として、ミッションの共有が組織の一部に閉じられてしまう、トライブ内で情報が閉鎖的になってしまう等が挙げられる。それに対して、トライブの中のみではなく、ギルドを作成してトライブ間のナレッジの共有をし、会社内で生じている問題を優先順位で起こし対応を行った。
テック企業がどういったテストを行っているのかについて、アプローチは企業にて異なる。ここではSpotifyを例として挙げる。
マニュアルテストについて、初めは全ての機能に対してマニュアルテストを行っていたが、規模が拡大することによって負荷が多くなっていった。その為順次自動化を行った。しかし、UIテストを行う中で規模が大きくなるにつれ、テスト実施に時間がかかるようになってしまった。
その対策として、エンジニアをテストに関与するようにし、テストの留意を行った。"Fix It Week"という週間を作りその週では、開発をやめ、業務の向上の為に必要な作業を行う時間を設けることとした。
コンサルタントがより良いテストを行うかつ、テストをレベルごとに分けどのレベルで行っているか一目できるようにPandaというシステムを設けた。
POとしてはチームを信頼し、システムや環境などエンジニアが求めるものを渡し、エンジニア自身に責任感を持ってもらうことでシステムの担保を行った。
エンジニアとQAとが、上手くコミュニケーションをとっていく必要があるアジャイル開発の中で、チーム全体の方針や意識を1つにするという考えや動きはとても重要に感じた。エンジニアやQAという枠組みはあるが、その中で何を目的としていくか。チームとして目的を共有できているかを改めて考えていきたい。
昨今のSI業界では保守や追加開発を行うプロジェクトと、顧客の声を取り入れたAgileやDevOpsを取り入れたプロジェクトでは、格差が大きいレガシープロジェクトが増えている。この格差を「負債」と呼ぶ。
既にプロジェクトがウォーターフォール開発で進んでおり、後からAgileやDevOpsを様々な起因により取り入れることができなくても、開発システムとして部分的に取り入れていくことは可能である。モダナイズ前のファイルの取り扱いなどについても修正箇所の依頼自体の手間や第三者への情報伝達の不足等が発生していたが、プロセス改善としてGit導入後は改善され、作業の効率が上がった。
プロセス改善後の問題として外部より改善用のメンバーが所属している間は改善が進むが、離れると元に戻ってしまう。「負債」が増えるにつれて改善の負荷は増えていく。
プロジェクトごとに改善方法や開発に必要となるシステムは異なる。その為必要なのは開発用のシステムなのではなく、開発メンバーが進んで改善をしてくことが大切となる。
プロセス改善のOJT型の研修の内容として2日間の座学研修にて開発技術を学ぶことができる。研修完了後、2週間にわたって改善用の計画を立ててもらい講師のレビューや上部へのエスカレーションを行う。その後3週間にかけて計画の実践を行い、3週間完了後振り返り及び状況、課題の共有を講師と主に行い、繰り返し改善を行っていく。
その中で、実際に適応した技術の紹介として改善が成功していくと、現在の開発方法に対する問題に気づけ、モチベーションの向上へとつながる。実際に成功した人の特徴として、自分自身の手を動かしていること、賛同者・仲間を得ていること、スモールスタートからはじめ計画の見直しをこまめに行っていること、改善のみではなく定着させる為の方針を検討していること、以上のことができている人があげられた。
アジャイル開発を取り入れようとしているが迷っている、実際に取り入れたが実際に効率が上がらない、といった問題を抱えているプロジェクトも多くあると思う。その中でも段階的に改善していけるというのはプロジェクトを改善していきやすいのではないかと思う。
また、本セッションにて改めて現案件でのアジャイル開発として上手く回せていない部分等を見直す機会となったと思う。
品質の作りこみが難しいプロジェクトにて開発コストをどうして下げていくかを考えた。開発コストの中で検証コストを下げることへ着目し、闇雲にではなく検証コストを下げる為、ファイルの欠陥混入の可能性があるデータを基に行った。
バグチケットには修正差分のURLを記載しファイルごとに欠陥混入数を評価するデータに対し機械学習を基に作成し、変更した際に想定される欠陥を目視できるようにした。
ファイルの更新及び業務学習を踏まえると精度の改善は必要となる。
修正箇所やコードによってバグの指標がわかるというのはテストまでの工数も割り出すことができるので、スケジュールの把握や全体の工数の見積もりを決める際にも効率化が図れると思った。
本講演は参加者向けに公開された動画を後日視聴した。
テスト設計の成果物について以下の課題が挙げられた。
成果物を未レビューのままテスト実施、レビュー会にて無反応のままやケースの説明のみで終わってしまうなど。
上記はレビュー依頼者（テスト設計者）主観での問題だが、レビューを受ける側としてもケースのみ渡されたのでは抜け漏れの確認に工数がかかってしまうことや、テストに対する必要性、期待結果が異なることもあり、このままではテスト実施するうえでも無駄なテストとなってしまう。
この中で井芹氏はテスト設計成果物をベースに開発者と設計者の対話を進め、互いの理解を促進することを推奨した。
JSTQBにおけるテスト開発のプロセスを基に更なるプロセスの細分化を行い、設計意図がわかりやすいように、更には設計成果物を作るうえで参照した情報を共有することで短い時間で設計意図を共有できるとした。
筆者もテスト設計を行う中で設計成果物のレビューを行う機会はあるが、レビューが実際に上手くいっているのか主観としては中々判別しにくい。そういった中、成果物の作成段階でのプロセスを開発者へ共有することで上手く設計意図を共有できるという知識をぜひ取り入れたいと思った。
プロダクトの成果を最大化する為にスクラムチームとの働き方について、プロダクトマネージャー（以下PdM）は根本課題を定義する、課題をよりよく解決する、チームのモチベーションを上げる為の課題を考える、等の責務が蜂須賀氏のチームでは与えられている。QAについてはWhy,What,How等を基にユーザーストーリーを管理し、運用までを行うというプロダクトの品質を司る責務が与えられ、ソフトウェアエンジニア（SWE）はそれを基にプロダクトビジネスの成果の具現化を行う。
実際のプロジェクトの進め方として、スプリント内にてProduct Requirements Document(以下PRD)の策定、その後QA、基本設計を行い、見積もり、実装、テストを通してPRDを更新していく。PRDを起点に課題解決方法、成功失敗基準、計測基準、ユーザーストーリーの定義、バックログを考えていく。
プロダクトにおけるQAのかかわり方として、プロダクトライフサイクルを基にチーム内での対話、深掘り、それを自分の言葉で語ることでロードマップにおける理解、更には進展へとつなぐことができる。
現在の様々な企業内におけるQAに対する期待度としては"テスターとして"や"人手として"という意見が多く、そこまで期待度は高くないという声が多かった。
それに対し、QAとしての期待度を上げる人材を育てる為に、品質保証を行う他業種より学べることとして以下のことが挙げられた。
現案件での課題感としてチームのモチベーションの管理について話が上がっており、とてもタイムリーな話を聞けた。QAとエンジニアとの意識の共有の為にもモチベーションの維持やロードマップの共通化等は意識していけると感じた。
現場のPMからQAに対しての率直な意見を聞くことができ、自分自身のQAとしての意識を見直すとてもいい機会となった。今回挙げられた他業種から学ぶべき点についても日頃の意識から変えていける部分は多くあり、チームにも持ち帰るべき部分だと大きく感じた。
本講演は参加者向けに公開された動画を後日視聴した。
本講演では柿崎氏、島根氏、泰楽氏、原氏の四名が山本氏の用意した質疑に対して、それぞれ一問一答で回答をする形にて発表を行った。
本講演にて用意された質問「一人目QAを迎える側に準備してほしいとかは？」に対し、出た回答として、品質管理に対する経営者側の理解・課題感や状況の共有・実環境や開発環境での権限の付与等が挙げられた。
また、他の質問として「1人QAのやりがい」について自己の裁量や力量によって様々なことにチャレンジできる・リアクションをダイレクトに感じられる・成果によって社会的責任が増えていくのがわかるなどが挙げられた。
筆者のQAとして参画した案件の中はいずれも既にQAチームが出来上がった状態での参画であった。その為、本講演にて聞くことができた内容についてすぐに共感できる部分は多くはなかったが、課題感の状況の把握についてはいつ参画するにせよ発生しうる問題だとは思う。QA側がその課題感を把握し、上手く消化していくことで成果もよくなっていくのだと思った。
ソフトウェアエンジニアに向けた開発や品質の改善方法などについて記載がされている「実践ソフトウェアエンジニアリング（第9版）」が2021年12月に発行された。
本セッションでは原著となった「Software Engineering: A Practitioner's Approach」を踏まえての概要の説明や日本語版を出版するまでのプロジェクトの紹介や成り立ち並びに本書内の概要の説明を行う。
本書では、ソフトウェアエンジニアリングのナレッジのみではなく、ベースとなる特定企業・ドメイン知識もまとめている。
情勢や、技術の開発によって変化し、コンテンツが追加されるだけではなく、陳腐化したノウハウや技術は添削されていく。
本書で記載されている、第15章「品質の概念」について紹介する。David Garvin氏の主張では品質とは「超越的な観点、ユーザーの観点、製品の観点、価値に基づく観点」としている。
また、第16章「レビューの推奨手法」ではソフトウェアプロセス内におけるエラーの50%～65%は設計時に発生しており、レビューの技術を用いた場合には設計上の欠陥の内最大75%まで効果を発揮する。
その他、第19章「ソフトウェアテスト-コンポーネントレベル」では品質とプロセスにおけるテストのアプローチの仕方や、第20章「ソフトウェアテスト-統合レベル」ではなぜ統合テストが必要なのか、テストと並行したアーキテクチャの構築などについて説明をしていく。
テストのナレッジなどは個々で深めていくことが今まで多かったが、様々なアプローチからプロジェクトやテストに対する観点を得ることができた。
本セッションでは実践ソフトウェアエンジニアリング（第9版）」の中でも注力された部分、今のテスト界隈のトレンドに近い部分にフォーカスを挙げて説明があったが、その他内容についてもとても多く知ることができると思う。また、内容も随時更新されている為、新しい知見を多く得られる文献となると感じた。
登氏が掲げた現在の日本のICTの課題としてプラットフォーム技術や産業を生み出せるICTの人材がいないというものがある。この課題に対して「自律的なコンピュータ・プログラミング環境」を設けることと、「自律的なネットワーク環境」を構築させることが重要とした。前者に関しては個人的な環境要因等の問題となるが、後者に関してはプロトコル等の要因もかかわってくる。
独立行政法人 情報処理推進機構（以下IPA）では「シン・テレワーク」、「自治体テレワークシステム for LGWAN」等のシステムがあるが、2017年より市販のファイアウォールを使わず、自分達によってBGPでインターネット接続し、管理・監視システムを自作して運用している。結果としては5年間でセキュリティ事故は0件であり、極めて高いセキュリティが実現されている。
しかし昨今(2000年以降)ではインターネットやシステムソフトウェア、クラウドサービスの進歩によってOS、セキュリティ、通信システム等の低レイヤーの維持を行う人材が大学、企業、研究所から減っていってしまった。その為現代の若い世代の低レイヤーを学ぶ機会が減り、日本では負のスパイラルに陥っている。
現在のICT組織でもLANやHUBが大量にあるデータセンターがあり、こういったところがICTの開発環境となっている。
ICT人材を育成するにあたってIPAが現在主体となり自由なICT試行錯誤を許容する為の環境の日本各組織に提供を勧めている。
本セッションでは情報システムの知見のみではなく、ICTの発展の為にどういったことを考えていくかを知る為のとてもいい機会となった。
筆者はQAとしてテストに携わる前の前職にてインフラの管理をしていたことがあったが、改めてインフラの知識をQAとして、更にはQAの知識をICTの発展の為につなげていけるのではないかと感じた。
本セッションを通してICT業界のみではなく、様々な業界が日本の技術発展に対して考えていけるのではないかと感じた。
善吾賞と論文特別賞の発表が行われた。善吾賞は伊藤 弘将氏、松原 豊氏、高田 広章氏による「ミドルウェアに対するCoverage-base Greybox Fuzzingの適応」である。論文特別賞は国分 佑樹氏、喜久里 陽氏の「ソフトウェアシンポジウム」である。
最後に、実行委員長である上野 彩子氏から、閉会のあいさつが語られた。オンラインの中、多くの登壇者、参加者による活発な意見の交換を目の当たりにすることができ、業界の更なる発展を期待したいと思う。
2日間にわたってオンラインにて開催が行われたが、オンラインだとは思わせぬ程Discordを用いてのコミュニケーションが活発に行われていた。セッションの動画のみではなく、チャットでも多くの知識を深めることができる機会だったと思う。また、本会を通して私自身がQAとして個人として求められているものではなく、QAチーム全体として求められているものを考えていく必要があると感じた。またQAとしてのみではなく、様々な分野の知見も深めていきたいと思えた。
記：大森 雄登（SHIFT）