NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'21 Hokuriku
HOME > 活動報告 > イベント報告 > JaSST'21 Hokuriku
2021年1月24日(金) 於 オンライン開催
実行委員長の前川氏から開会の挨拶があった。内容は以下の通り。
全国的なコロナ禍で、さらに北陸では大雪に見舞われる中、準備をしてきた。地域のＩＴエンジニアに向け、知識や情報に触れられる機会を提供し、元気な北陸を目指して活動している。本日は173名という多数の参加があり、講演と並列する「テスト設計初心者向けチュートリアル」には50名が参加予定である。
はじめに山崎氏から自己紹介があった。よく金髪アフロのカツラを被っており（自己紹介スライドに写真あり）、特技がソフトウェアテストで、趣味がソフトウェアテスト、一言でいうとテストが大好きです、と語った。そして、ソフトウェアテストに正解はないが、本質を考えることが大切であり、本日の講演でお伝えする私の意見を参考にしていただきたい、と前置きし、講演が始まった。
講演概要は以下の通りである。
ハードウェアは物理化学法則に基づくが、ソフトウェアはそうではなく自由度が高すぎるため、文書やコードに欠陥（バグ）が混入する。そのため、開発したソフトウェアを、自信を持ってリリースするために必要な技術領域の一つがテストである。テストとは、品質に関わる新たな情報を得るための諸活動である。
テストの価値は情報収集と情報提供である。なぜなら、テストは完全ではない。テストの７原則では、原則１「欠陥がないことは示せない」、原則２「全数テストは不可能」などと書かれている。確信を持ってソフトウェアをリリースできるためのテストの着地点は、収集した情報に基づいた合意形成しかない。
テストを理解するための第一歩は言葉を知ることからである。ただしテストという言葉を含む用語が多く、それらの用語を区別できることが大切である。共通言語としてJSTQB-FLの取得をお勧めする。
テストを理解するには、テストの軸を理解することが重要である。テストレベル、テストタイプ、テストプロセスについて、それぞれ説明する。
テストレベル
コンポーネントテスト、統合テスト、システムテスト、受入れテストに分類される。対象や作り方によって適切にレベリングすることが大切である。ソフトウェアライフサイクルのどこにおいてどういったテストをすることで、自分たちは確信度合いを持って開発したり運用し続けたりすることができるか、に到達できる。テストレベルの本質を考える＝ソフトウェアライフサイクル全般におけるテストの全体像を考えることに繋がる。
テストタイプ
機能テスト、非機能テスト、ホワイトボックステスト、変更関連のテストに分類される。テストタイプの本質を考える＝製品やサービスに求められていることや、それらの存在意義といった根源的なことに繋がる。思考停止することなく、どのテストが必要なのかを突き詰める。
テストプロセス
JSTQBでは、以下のように示されている。
（テスト計画→テスト分析→テスト設計→テスト実装→テスト実行→テスト完了）＋モニタリングとコントロール
テストレベルやテストタイプにはそれぞれ特徴があり、テストの中でやりたいことを実現するためのプロセスを自分で設計することが必要である。次に、テストがリリースのボトルネックとならないよう、開発プロセスなど、テスト以外のプロセスと融合させることが大切である。テストプロセスの本質を考える＝ソフトウェア開発のライフサイクルやソフトウェアライフサイクルとの融合やパイプライン化に繋がる。
テスト技術などの要素を考える際、上記で示したテストの空間（３つの軸）の、どこに対しての要素であるかを意識することが理解を促す。また、テスト以外のスキルや知識を習得し、テストとテスト以外の領域をいかにしてつなげて考えるかが重要である。テストを通じてソフトウェアの本質に深く深く潜っていこう。
学ぶことや育成の方法に銀の弾丸はない。テストに興味を持っていない人に働きかけても難しい。対象者が、テストを学ぶ必要に迫られたりテストに関心を持ったりした時がチャンスである。そのためにも、普段からテストの楽しさや面白さなどを醸し出しておこう。また、必要がなくなると熱が冷めてしまいがちなので、社外に送り出して、知見を広め、刺激を得てもらおう。テストを楽しいと感じ、テストを好きになれば自ら成長する。みなさん、テストの全体観を持ち、テストに強みを持った技術者になろう。
ソフトウェアテストについて、３つの軸ごとに本質を追究することで、理解が深まることを実感できた。山崎氏がＱ＆Ａの際に、「テスト分析やテスト設計をしている時に、とてもわくわくする」と語っていて、そのわくわく感が講演内容に盛り込まれていたと感じた。日々の仕事がわくわくするためには、常に本質を追究することが大切であると学んだ。
金子氏による自己紹介の後、講演が始まった。講演の途中では、クイズや問い掛けがあり、ツールの挙手機能で人数をカウントしてフィードバックを活用していた。
講演概要は以下の通りである。
異なる製品やサービスがインターネットを通じてつながり、新たなサービスや価値が提供される「IoT時代」が実現しつつある。一方、異なる製品やサービスがつながることで、安全性（セーフティとセキュリティ）の問題が懸念されている。
IoTシステムへの脅威事例は日増しに増加している。IoTセキュリティの課題は、脅威となる対象の洗い出し、目標を設定するセキュリティ要求分析手法・リスク評価の手法、要件を可視化する技術の確立、である。
そこで、安全なシステム・ソフトウェアの開発「セキュリティ・バイ・デザイン」が注目されている。情報セキュリティを企画・設計段階から確保するための方策であり、システム・ソフトウェアの中に脅威への対抗手段を含めることが、より根本的な対策になる。
セキュリティ・バイ・デザインのメリット
開発者向け「つながる世界の開発指針」の実践に向けた手引きをIPAで公開している。観点は、ライフサイクルと実装位置である。IoT機器・システムやサービスのライフサイクルを考慮し、保守・運用の視点で開始と終了の間を予防・検知・回復にわけて整理している。また、クラウド・フォグ・エッジ等の機能配置を考慮している。
設計段階から考慮してほしい要件として、利用開始後の利用条件や環境の変化を見据えた設計が必要となるため、保守運用における5つの視点「開始」「予防」「検知」「回復」「終了」で整理し、それをさらに12の機能要件に細分化し、23のIoT高信頼化機能（初期設定や認証など）と紐付けている。
IoT時代では、Safetyを考えることが非常に重要である。さらに、複雑化するシステムに対応するために、Safety理論をベースにSecurityを再構築していく必要があると考え、Safetyを学んで来た。
Safety について
Safety2.0とは、人と機械による「協調安全」と呼ばれる、日本発の新しい取り組みである。その背景として、以下の理由により、新しい安全解析手法が必要とされている。
安全対策をしていても事故を防げない現状から、複雑化したシステムに対応した新しい解析手法・事故モデルが必要となる。また、コンピューターシステムはハードウェア主体からIoT時代へ移った。ソフトウェアの持つ特性は以下の通りである。
安全性と信頼性の観点では、コンポーネントや機能の故障を防ぐだけでは不十分である。そこでSTAMPという新しい事故モデルが生まれた。
STAMPの考え方
現在の複雑な組込みシステムは、ソフトウェアや人間・組織を含むサブシステムやコンポーネントで構成されており、コンポーネントに不具合がなくともサブシステムやコンポーネントの相互作用によってハザードが発生する。従って、従来型のリスク分析手法では限界がある。
既存手法とSTAMPの考え方の違いについて、自動車を例に示す。
STAMPの概念
システム事故の多くは、構成要素の故障ではなく、システムの中で安全のための制御を行なう要素（制御要素と被制御要素）の相互作用が働かない事によって起きることを前提とする。欧米ではSTAMP活用が普及しつつあるが、日本では未だ認知度は十分ではなく、取り組みが遅れている。
レジリエンスエンジニアリング
レジリエンスエンジニアリングが提唱することの一つは、安全を「物事が正しい方向へと向かうことを保証する、すなわち、うまくいっていることから学ぶ」という新たな考え方への変革を促すことである。複雑な工学システムにおいては、重大な事故や損失が起こってから対応するのでは社会的影響が大きすぎるため、この考え方を取り入れることが必須である。
機能共鳴分析手法（FRAM：Functional Resonance Analysis Method）を用いて、システムの成功要因・リスク要因を識別する。FRAMは、システムが持つ「機能」を取り出し、機能と機能がどのように結びついているかによってシステムの様相を明らかにする。
システム理論に基づく安全性・リスク・事故分析などの様々な分析技術と、その技術を用いた取り組みとして、STAMP S&Sのような統合フレームワークが登場している。
セーフティとセキュリティの違いは以下の通りである。
脅威と脆弱性の違いは以下の通りである。
社会への影響も含めた階層的モデルが必要とされている。どの階層でも改善をしつつ、セーフティとセキュリティを確立し、社会への影響をシナリオ分析しニーズをとらえる。アウトプットは仕様や標準となり、社会技術システムの安全安心の確立につながる。
安全確保の分野を長年研究されている金子氏にとって、近年システムが急激に複雑化する中での安全確保が重要な課題であることがわかった。また、講演の途中で紹介される多くの事例によって、内容の理解が進んだ。
冒頭で及部氏から、レビューのイメージについて思い浮かんだ単語をチャットに書いてください、というリクエストがあった。その回答を見ながら、レビューに対してネガティブなイメージを持っている人が多いと感じる、と語った。レビューは繰り返し実施するものなので、より良いレビューを考えていきましょう、と前置きがあった。また、講演の途中でもチャットを活用して、聴衆からのフィードバックを参考にしていた。
講演概要は以下の通りである。
モブプログラミングとは、チーム全員で同じ仕事を同じ時間に同じ場所で同じコンピューターですることである。今のコロナ禍では、オフライン／オンラインに関わらず、技術やツールの進化によって、同じ空間・同じマシンでなくても、同じ環境を共有できるようになった。
分担作業とモブプログラミングのどちらが良い悪いということではなく、私たちのチームでは、仕事の質や状況に応じて、分担作業とモブプログラミングを組み合わせている。明示的なレビューはしなくなった。レビューを「する」から、チームにレビューが「ある」という状態に習慣化することが大切である。
レビューの目的は、品質向上・バグの発見・コードの均一化・メンバーのスキル教育・スキルトランスファーなどが挙げられる。目的を「検査」「学習」「強化」に分類することができ、中でも、「検査」の観点で、外部品質に着目したい。内部品質に偏向してしまうと、作りすぎを防ぐことができないと実感している。開発者が外部品質に深く関わることで、良いプロダクトを作ることができる。また、小さなプロダクトにすることが品質向上に貢献する。外部品質と内部品質の両方の情報を得ることで、自信と説得力を持ってプロダクトを小さく保つことができる。
モブプログラミングと、従来のレビューは、以下の通り補完関係にある。そのため、私たちのレビューを強化するために、従来のレビューも取り入れている。
モブプログラミング
レビュー
思考が偏って留まると濁ってしまう。「レビューをもっと自由に」という発想で、実験を繰り返して自分たちのレビュースタイルをつくっている。
世の中で良いと言われている様々なプラクティスなどを活用して自分たちの活動をより良くすることためには、その本質を追究することが大切と感じた。
実行委員長の前川氏から閉会の挨拶があった。内容は以下の通り。
及部氏に影響を受け、私もＴシャツに着替えてみた。北陸および全国のＩＴエンジニアを対象として今後も開催していきたいと思っている。また、実行委員も募集中である。
３つの講演は、テスト、セーフティ＆セキュリティ、レビューという幅広いテーマだった。近年ますます複雑化するソフトウェアにＩＴエンジニアが対応していくことが求められており、このような場に参加して幅広い分野の知識を仕入れることができることは、とても有意義だと実感した。私は、セーフティ＆セキュリティの分野には詳しくないため、とても新鮮な気持ちで講演を聴講することができた。オンライン開催だから気軽に参加できることをメリットと考え、今後も様々な分野のことを積極的に学んでいきたいと思った。
記：和田 憲明（ASTER）