NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'19 Tokai
HOME > 活動報告 > イベント報告 > JaSST'19 Tokai
2019年10月4日(金) 於 刈谷市総合文化センター アイリス（愛知県刈谷市）
第11回となるJaSST Tokaiが開催された。今回のテーマは「令和元年、改めて考えるソフト品質 ～ 真に安全なシステムを目指して ～」であり、基調講演、スポンサーセッション、ポスターセッション、特別講演、そしてSIG／ワークショップ／チュートリアルの並行セッション、最後に情報交換会が行われた。各講演資料は公式サイト（末尾にリンクあり）から公開されているので、合わせてご覧いただきたい。
会場は綺麗なホールで、階段状に椅子が並ぶ。10時になり、司会の相羽氏の発声でJaSST'19 Tokai が始まった。その後、実行委員長代理の森氏が開会宣言を行なった。
JaSST Tokai は11年目に入った。本日は品質について改めて考えたい。楽しく議論しましょう。参加者への事前アンケートから、参加者の傾向は右記の通り。自動車関連：全体の41%（昨年は27%）、組込み技術者：全体の68%、職歴10年以上：52%、JaSST Tokai 初参加：約60%。
JaSST Tokai は以前から自動車関連、組込み技術者の参加割合が高いと思っていたが、近年更に増えていると感じた。自動車の自動運転に代表されるように、安全とソフトウェアが強く結びついており、ソフトウェア技術者にとって、当シンポジウムのような、新しいことを学ぶ場が必要とされていると感じた。
酒井氏は医療系の組込みソフトウェアエンジニアで、国際規格のエキスパートでもある。近年は開発現場を支援する立場で、品質管理部門と現場の橋渡しをしているとのこと。著書は『組込みソフトエンジニアを極める』など。ちなみに、この本は最近また売れているそうである。
以下に講演の概要を示す。
ハードウェアの不具合は確率論的に発生するが、ソフトウェアの不具合は、確率論的ではなく、決定論的に発生するため、発生確率を推定することは困難である。開発のプロセスやライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない、やっかいなものである。
1960年代はZD(Zero Defect)運動が盛んだったが、ソフトウェアで欠陥ゼロはありえないため、1990年代あたりから、プロセス重視、（特に日本では）価値・顧客満足重視の考え方が台頭している。
日本では、サプライヤーから供給された部品をアセンブリして商品化する製造工程を永年続けてきたため、部品の信頼性を高めることで製品の信頼性も高まると考えているのではないか？ その考え方は、数百万行を超えた規模のソフトウェアシステムには通用しなくなっている。来るべきEV時代には、個別最適の発想から全体最適の発想（フェール・セーフ、フォールト・トレランス、エラー・プルーフ）に向かわないといけない。
JMAC GD3 吉村達彦センター長はトヨタとGMの品質保証担当を努め、USと日本の違いを実感した。意識、ルール／責任、システム／ツールの３つの要素を考えると、USは意識以外の要素を重視するが、日本は意識（Awareness：品質を心配する意識）を重視するという違いがある。その背景を知らずに欧米流のやり方を持ち込もうとしてもうまくいかないのではないか。
国際規格は、各国の代表が議論を重ね、最終的には投票で決めるもの。各国の主張も色濃く反映され、人間が決めるもの。よって、国際規格だからといって、それを神格化して、何も考えずに取り入れるべきものではない。背景や目的を理解し、自分たちにとって役立つものかどうかを判断する必要がある。
良い面として、第三者に認められた、など継続のためのモチベーションが上がる。悪い面として、適合が目的化してしまい、目的が忘れられてしまう。Awarenessの強い日本では、特に目的（安全など）に役立つという確信がなければ、活動を続けることは困難だろう。
製品毎に利用シーンが大きく異なる医療系では、ハザード分析およびリスクアセスメント、安全妥当性確認が重視されている。EV時代の自動車業界でも、これから重視されるだろう。構成管理、変更管理を含むソフトウェアのプロセスアプローチは、ソフトウェアが肥大化する今後は大切だろう。この規格が、安全にどう役立つかを考えないといけない。
日本では、OEM9社、サプライヤー19社がISO26262の運営に関わるワーキンググループに参加しているので、使いにくいものなどには、どんどん意見を言った方がよい。
安全の技術は事故の再発防止のためにある。日本では、技術者の気づき（Awareness）で未然に防いでいたのではないかと思う。今後のEV時代でも、同じようにAwarenessで事故を防ぐことができるのだろうか。今後、自動車の利用シーンが多様化し、新規参入を含め様々な企業が自動車ドメインに参入する。自動車がネットワークに接続し、ソフトウェアが「走る」「止まる」「曲がる」の基本機能・基本性能も制御するようになる。エンジニアが利用シーンをイメージできない状況も考えられるため、Awarenessに頼っていては、ソフトウェア起因の事故を防げないだろう。
自動車のソフトウェアが「曲がる」と「止まる」の両方を制御するようになった事例から。高凝縮・低結合というソフトウェアのセオリーが通じなくなってきており、新たな安全対策案が考案されている。
自動車のブレーキシステム事例から。ソフトウェアが制御する対象が複雑になってきているが、ソフトウェアは目に見えないため、外からわからない状態になっている。
エレベータは、 扉が開いている状態では通常は動かない。しかし、エレベータ内部の床と停止したフロアの床の高さの差が、ごくわずかであれば、扉が開いた状態で停止高の位置調整を行う。このように、より良いサービスを実現するためにソフトウェアの処理が複雑化する中、ソフトウェアの処理だけで安全制御を実行するのは難しい。そのため、クラス毎に責務をはっきりさせたり、ハードでの安全制御を併用するなど、工夫が必要である。
電子メスでは切開と凝固の2つのモードの切り替えをソフトウェアが制御している。ハードではこのソフト制御の障害発生を知る方法が無い。この例のように、ハードで安全制御することが困難な問題が出てきており、FTAやFMEAを活用して安全を実現する。
医療業界では、ネットワークで機器同士が相互につながることで、新たなサービスが生み出されている。自動車業界では、いくつかの部品を組み合わせて機能を実現するようになってきている。ロボット業界では、Intended Use（意図する使用）が定まらないため、リスク分析が難しい。そのような場合は、リスクベースアプローチにより、個別最適ではなく、全体最適の発想で問題を解決すると良い。
EV時代を迎える自動車業界には様々な課題があり、その一つである「ソフトウェアによる安全の実現」を教えていただいた。ますます複雑になるソフトウェアで、これまで通りの安全を実現するために、ソフトウェア技術の発展が期待されていると感じた。
ポスターセッションでは、大きな部屋に10台のホワイトボードを並べ、スポンサー／コミュニティ／一般参加者による、説明と展示が行なわれた。各ホワイトボードには、パンフレットや事例スライドが貼りだされ、説明員が熱心に説明していた。多くの参加者が部屋を訪れ、質問していた。
あっという間の30分だった。ポスターを見て説明員に質問したり、他の参加者が説明員と会話している内容を聞いたり、配布物を集めたり、短時間で様々な知識を得ることができた。とても充実したセッションだった。
柴田氏は、1984年に社会人となってから、単純なプロセス間通信で構築したFuji Xerox 6060 Workstation、複雑なマルチスレッドプログラミングで構築したFuji Xerox DocuStation IM200、完全なテスト駆動開発で2度開発したデジタル複合機コントローラ（C++言語とGo言語）、そして、スマホ決済サービスであるMerpayの加盟店管理画面用のマイクロサービス開発などを経験されている。
それらの経験を通して、本日はソフトウェアのテストがどのように変遷してきたかを振り返る。特に、今日では当たり前となっている「テスト駆動開発」や「継続的インテグレーション」への取り組み、マルチスレッドプログラミングにおける問題の複雑さとそれにどのように対処したかについて話してくださった。
以下に講演の概要を示す。
1990年代までは、自動化されたテストは常識ではなかった。当時の書籍によれば、テストの実行は自動化されても、結果は人間が目視していた。2000年前後にパラダイムシフトが起き、テスト実行と結果の確認をコードが行なうようになってきた。テスト自動化は、最初は難しいが、慣れると当たり前になる。テストコードのないプロダクトコードは、リファクタリングしていないので、腐る原因になる。本当に腐る。
九州工業大学時代に、コンピュータネットワークを作った。通信コントローラボードの組立とハードウェアデバッグ、通信ソフトウェアの開発を行なった。ソースは8インチフロッピーで管理した。ソフトウェアを2KBのROMに焼き付けた。
ワークステーションを作りたくて富士ゼロックスに入社した。3機種を担当した。アプリケーション毎にビッグバン・インテグレーションを行なっていた。テストは手作業、怪しい箇所にデバッグ文を入れてデバッグしていた。
計4回、複合機コントローラソフトウェア開発に従事した。そこでマルチスレッドプログラミングに向きあう機会を得た。Take-1では、2週間毎のビッグバン・インテグレーションが必ず失敗するため、夜間ビルドに挑戦し、2週間のフィードバックは長すぎるという教訓を得た。メモリリークに直面し、FAX機能搭載機では24時間稼働のため問題になり、メモリ管理機構を実装した。Take-2では、最初からメモリ管理ライブラリを導入した。Take-3,4でも引き続き様々な挑戦をした。
これまでの経験で得たことは「マルチスレッドプログラミングの困難さ」である。マルチコアおよびマルチスレッドの経験・有識者が設計やレビューに関わらないといけない。自動テストによるテストは、一回動作したからと言ってプログラムの正しさは保証されない。ハングしたらその場で徹底して調査する。ログ出力コードを入れて再現させようと思っても再現しないことが多い。
これまで組込みソフトウェア開発に従事してきたが、最近はウェブサービスのバックエンド側でAPIをGo言語で実装している。マイクロサービスの並行開発が行なわれているなかで、単体テスト、e2e(End-to-End)テスト、サービステストを完了させる。
ハード/OSの知識が必要で、プラットフォームも構築する組込みシステムと違い、ウェブサービスはプラットフォームが整備されており、自分たちのサービスのロジックに専念できる。しかし、プラットフォーム自身も発展しており、常に学ぶ必要がある。ハード/OSの基礎知識は不要、マルチスレッドプログラミングも不要。
今日のソフトウェア開発では、早い段階からソフトウェア品質の作り込みが重要で、テスト駆動開発と継続的インテグレーションは今日のソフトウェア開発では必須である。ソフトウェア開発部門とQA部門は、開発の早い段階から、ソフトウェアの品質を作り込むために協業すべき時代となっている。「作業はコンピュータに、人は創造的な活動を。」
40年以上もソフトウェア技術者として活躍する柴田氏の話は刺激的だった。新しい技術に挑戦し続けることの大切さを、柴田氏の経験談を通して思い出した。筆者は中学の時にボケコンを購入してBASICでプログラミングを始めてから20年間プログラミングに関わってきたが、近年は関わっていないので、再度プログラミングを学ぼうと思った。
この時間帯は、5つのセッションが並行して行われた。筆者が参加したセッションについてレポートする。
昨年同様、OST（Open Space Technology）形式で、井戸端会議が行なわれた。参加者は7名で、招待講演の柴田氏も参加されていた。各自が議論したいテーマを出し（例：TDDの広め方、アジャイルでの品質管理）、30分×3セッションにテーマを割り振り、司会のkyon_mm氏も入り、全員で意見を述べ合った。
印象に残っているのは、TDD／テスト自動化への関心が高かったことである。JaSSTというシンポジウムだからか、東海という土地柄なのかはわからないが、参加者の方々が技術的なプラクティスを重視していることから、現場の技術者が現状の課題を技術で打開したい動機で参加しているのだと思った。
SIG／ワークショップ／チュートリアルのセッションリーダ5名から、状況が報告された。その後、実行委員長代理の森氏から閉会の挨拶があった。品質のために、テストという観点でどんなことができるのか、色々と考える一日になったと思う。本日得たものを事務所で試すまでがJaSSTです、と締めくくった。
基調講演者、特別講演者、SIG、ワークショップ、チュートリアルのリーダが7つのテーブルに分かれ、参加者と意見交換できる場が設けられた。30分×3セッションで、最大3つのテーブルに参加することができた。テーブルには模造紙とペンが用意され、参加者が気づきをメモしていたため、前のセッションでどんなことが話されたのか、ある程度理解することができた。
筆者は、基調講演者の酒井氏、はじめての組込みCI、そしてアジャイル井戸端会議のテーブルに参加した。講演者やSIGリーダの方々、そして他の参加者と近い距離でゆっくりと話ができた贅沢な時間だった。
筆者は、基幹系など業務システム分野のソフトウェアを対象としており、普段は組込み分野の方々と意見交換する機会は少ない。JaSST Tokai では、組込みの話題が中心であり、とても刺激を受けた。更に組込み分野でもCIなどアジャイルの取り組みが広まりつつあることに、喜びを感じた。ある組込み技術者から、これまでは外部に発注してソースコード作成／テストを依頼していたが、アジャイル開発を実践し始めてから、自分たちでコードを書いてテストすることに面白さを感じているという意見を伺った。来年以降も JaSST Tokai に参加して組込みの方々のお話を聞きたいと思った。
記：和田 憲明（ASTER）