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

Opening

実行委員長の山田氏から開会の挨拶があった。内容は以下の通り。

今回は4回目の開催で、参加者は約220人と前回よりも多く参加していただいた。
開催準備で関わった方々に感謝を申し上げたい。
このJaSST北陸は地域のITエンジニアや若手のエンジニアにソフトウェアの最新技術、研究や実践事例などを共有することで、技術力を向上していただくことを目的としている。

基調講演
「アジャイル開発で本当は、本当に、大切なこと ～ビジネスとプログラマとテスター協働チームづくり～」
　平鍋 健児 氏（永和システムマネジメント）

セッション概要

まず、現状の市場について、説明があった。
近年コロナ渦の影響もあり、市場の不確実性が急上昇してきているとのこと。

次に、大規模化するソフトウェア開発の難しさについて以下の4点の説明があった。

• 要求全体を定義することが困難にもかかわらず、明確に定義して発注しなければならない
• 作業見積もりが困難にもかかわらず、人月等で見積もりを行わなければならない
• 成果物の価値が明らかになるまで時間がかかる
• 欲しい側と作る側が分かれているため、顧客が求めていないプロダクトを開発してしまう

次に、アジャイル開発について解説があった。
アジャイル開発は短いサイクルで、分析、設計、実装、テストを並列に行うものであり、動くものが徐々にできあがる。
そのため、市場からのフィードバックをもらいやすい。
また、市場、ビジネスとITが一体となって開発するため、市場にあったプロダクトを提供しやすい。

しかし、アジャイル開発、特にスクラムでは、最低限のこと（3つの責任、5つのイベント、3つの成果物）しか決まっていない。
そのため、開発の進め方は自分たちで確立する必要がある。
確立するには、自律し、助け合うチームを作りが必須である。

次に、アジャイル開発におけるチームを作りについて解説があった。
平鍋氏は具体的な方法として以下の2つをあげている。

• プロジェクトの可視化
  • タスクかんばん、ポータブルカンバン、バーンダウンチャート等の方法がある
    • どれも手書きで行い、メンバー全員が常に確認できるようにする
  • 掲載する情報は、ステークホルダー全員が関係あるもの、信憑性のある情報にする
  • タスクをサインアップ型にすると、自然に助け合いが生まれる
• スルーしない取り組み
  • 朝会で作業を明確にする
  • ふりかえりで改善活動を行う
    • 特にふりかえりはフィードバックを受けながら、自分たちのやり方を確立させるために重要

次に、リモートでのチーム作りの難しさについて説明があった。
対面では人との対話を通じて共感が生まれていたが、リモートでは生まれにくい。
リモートの場合、発信者側が多くの表現方法を持っている。
そのため、発信者側が過剰に表現する方が相手に伝わりやすい。

また、従来のように合宿などのビッグイベントでチームビルディングができないため、以下のような方法で継続的なチーム作りを行う必要がある。

• 雑談チャネルを作る
• ミーティングにアイスブレイクを設ける

平鍋氏は最後に、自分から動いて、考えて、また動くことを繰り返して、良いチーム作りを行っていきましょう、と語っていた。

主なQ&A

Q1.

ウォーターフォールからアジャイルに変わる過程で、人により適応のスピードに差が出てくるが、そのギャップを埋めるorケアするような知見はあるか？

A1.

チーム全員でそのギャップを埋めていく必要がある。アジャイルを回していくうちに、自分たちのやり方にあってくる。しかし、全員アジャイル初心者だと難しいため、経験者を入れる必要がある。

Q2.

スクラム開発を契約する場合の契約の考え方、見積りの考え方について触りだけでも教えてほしい

A2.

「IPA契約」で調べると、アジャイルの契約資料がある。アジャイル開発には準委任契約が適している。プロダクトオーナーには予算に権限がある人を選ぶ。

Q3.

スクラムマスターになるには何からはじめれば良いか？

A3.

スクラムマスター研修を受講することをオススメする。もしくは、フリーランスのスクラムマスターを招いて、一緒にスクラムを進めながら学ぶのも1つである。

Q4.

開発チームとテストチームが別々にスクラムで進めている体制において、認識を合わせるために効果的な方法はあるか。

A4.

開発チーム/テストチームともに、同じ情報を同じタイミングでみられる/話せる時間を設けると良い。

筆者感想

私はアジャイル開発の現場に携わっていなかったため、アジャイル開発の概要と重要なことを把握でき、とても有意義だった。
またチーム作りの部分については、アジャイル開発以外でも適用できる部分があると感じた。
私は普段、業務の可視化やふりかえりを行っているが、形だけ実施している部分があったため、改めて自分のやり方を見直そうと思った。

招待講演1
「プロジェクトに寄り添ったレビュー改善の実践と効果」
　久連石 圭 氏（東芝）

はじめに

全社にSPI（Software Process Improvement）を推進している久連石氏より、レビュープロセスの改善事例が紹介された。
講演概要は以下の通りである。

概要

まず、改善の背景について説明があった。
対象プロジェクトは社会インフラ製品に搭載するソフトウェア開発プロジェクトで、短納期かつ市場の不具合ゼロが求められている。
しかし、市場で不具合が発生しており、原因は設計時に欠陥が混入していることだった。
当プロジェクトでは、レビュー会議の進め方に以下の課題があり、レビュー効果が出ていない状況だった。

• レビュー会議が説明・議論の場となり、指摘を出す時間が取れない
• 指摘する人に偏りがある
• ファシリテータがいないため、スムーズに進行しない

次に、改善推進者が行った活動と効果について説明があった。
効果的なレビューを行えるように以下の活動を行った。

• レビュープロセス教育の実施
  • 効率的・効果的なレビューを実施するためのテクニックやノウハウを研修で提供
  • より多くの方に参加してもらうために、1時間（講義30分、演習30分）という短い時間で実施
• レビューファシリテータの育成
  • レビュー会議に改善推進者が直接参加し、対象者の現状を分析する
    • その分析結果を対象者に伝える
  • ディスカッションを中心としたレビューファシリテータ教育を実施
  • 教育した内容を対象者が現場で実践
    • 改善推進者も参加し、フィードバックを行う
  • 現場で実践した内容をワークショップ形式でふりかえり、取り組み内容、工夫点、課題を共有する

改善活動を行った結果、以下の効果がみられた。

• 現場でも時間管理やファシリテーションが機能し、レビュー会議をスムーズに進めていた
• 指摘の割合として、設計の漏れや誤りなど致命的な欠陥の検出割合が増えた
• 当初の課題であった、市場の不具合ゼロを達成した
• 改善実施から2年経っても、ほとんどのチームが効率的/効果的なレビューを行えていた

最後に改善の勘所について、以下の4点の説明があった。

• 現場・現実・現物を正しく確認すること
• レビュープロセスやガイドを作成、展開するだけでは、不十分。現場に寄り添って、改善を進めること
• 改善者と開発者それぞれ視点が異なるため、お互いを尊重しながら改善を実施すること
• 改善の効果を対象者とともに確認すること

主なQ&A

Q1.

ドキュメント上でのレビューを改善した事例はあるか？

A1.

机上レビューのやり方そのものを変えた話はないが、レビュー記録方法などのプロセス面の改善はある

Q2.

改善開始から2年経つまでの間に、SEPGとして定着を促すためにどのような働きかけをしたのか。

A2.

オンライン会議のポイントをまとめるぐらいしか行っていない。後は現場の改善担当者が現状を確認していた。

Q3.

情報開示に消極的、問題を抱えるシステム・担当者が偏る、開発側の当事者意識の改善等、対するアプローチがあるか。

A3.

結構難しい問題であるが、以下のアプローチがある。

• トップから改善の必要性を伝えてもらう
• あらさがしをする/否定する/人格否定はやらないと宣言する
• 仲間意識を作る
• 開発側も忙しいため、お願いはできるだけ最小限にする

筆者感想

改善活動が終わっても、一定の効果を発揮しているという点で、相手に寄り添った改善を行うことでより効果が出るということを改めて実感した講演だった。
また、今回の講演を通して、私は以下ができていないと気づけた。

• 抜け漏れを意識したレビュー
• レビューの目的や観点の明確化
• 改善効果の測り方を計画すること

この講演を参考に、今後のレビュー業務を改善していきたいと思った。

招待講演2
「なぜ大規模Slerで探索的テストを推進しているのか？～2021ver～」
　熊川 一平 氏（NTTデータ）

はじめに

ソフトウェアテスト/ソフトウェア品質保証を中心としたR&D活動と現場適用支援に従事している熊川氏から、テストの可監査性・客観性が求められるSIerで、探索的テストを推進している事例が紹介された。
概要は以下の通り。

セッション概要

まず、探索的テストについて解説があった。
探索的テストはテスト実行後のふるまいを観察して、さらなるテストにつなげ、バグを「探索」する方法である。
このテストでは成果物が無形であるため、テストの客観性が求められるSIerには向いていない。

次に、探索的テストを推進している背景について説明があった。
ソフトウェアの品質に問題がないことやテストの十分性を客観的に証明するのは困難である。
そのため、論理的な解決よりも現実的な効果を積み上げていく方が良いのではないかと考えた。

ソフトウェアテストの現実的な効果は、バグの検出や仕様改善である。
過去の実績から探索的テストはスクリプトテストよりもバグ検出は10倍、仕様改善は100倍効果があった。
これらの理由から探索的テストを推進することにした。

次に、探索的テストの推進方法について説明があった。
探索的テストを、今のプロジェクトで実施しているテストとは別に、非公式なテストとして導入するように推進。
探索的テストをより多くのプロジェクトに導入してもらうため、以下の2点を実施した。

• 探索的テストの用途をまとめ、展開
• 探索的テストの効果を実感してもらうための研修を実施

上記の施策を行った結果、さまざまなPRJに探索的テストを導入してもらった。
また、バグの検出率も増え、現実的な効果を出せた。

最後に、現在熊川氏が進めていることについて以下の2点の説明があった。

• 探索的テストに可監査性・客観性を持たせるために、LatteArtというツールを用いてSONAR Testingを実施
• 改善経験を積むために、改善に伴走するプロセス改善研修を実施

主なQ&A

Q1.

LatteArtは簡単に扱えるツールか？

A1.

日本語のドキュメントもある。導入のハードルを下げるようにしたため、簡単に扱えるツールである。

Q2.

探索的テストとスクリプトテストの工数比率はどのくらいか？

A2.

決めていないが、PLの投資として探索的テストをしているため、1日だけ実施というところもある。

Q3.

探索的テストの研修の時に、他の技法も紹介しているのか？

A3.

事前のインプットとして、テスト設計技法の研修を行っている。

Q4.

SONAR Testingは、テストリーダーとテスターは仕様や設計内容を十分に理解していることが前提なのか。また、テストリーダー、テスターは開発者自身なのかテスト部門のどちらを想定しているか？

A4.

SONAR Testingは仕様を十分に把握する必要がある。ロールは特に分けていないが、問題分析や解決策、ソフトウェアの立ち位置を理解している人がリーダーとして進めるべき

Q5.

探索的テストの効果はテストする人に依存するがどうやって教育しているか？

A5.

具体的には以下の2点を行っている。

• ペアテストで仕様のノウハウを伝える
• 探索的テストを実施している人を集めて、何をテストしたのか、なぜそのテストをしたのかを共有している

筆者感想

元々探索的テストには興味があり、探索的テストの魅力をより感じられた講演だった。
特に、スクリプトテストよりバグ検出・仕様改善効果が大幅にあるというところは非常に魅力的だと感じ、時間を見つけ次第、LatteArtを触って探索的テストをしたいと思った。
また私は解決が難しい問題に対して、単純化しすぎるところがあるので、今後は現実的な効果というものも考えながら、業務をしていきたいと思った。

Closing

実行委員長の山田氏から閉会の挨拶があった。内容は以下の通り。

JaSST北陸は継続して開催する予定であるため、講師でも良いので、皆様のご参加をお待ちしている。
アンケートに今後の期待を書いてほしい。
また、2021年度最後のシンポジウムとして、JaSST Tokyoが開催されるのでぜひ参加してほしい。

筆者感想（全体）

3つの講演は、アジャイル開発におけるチーム作り、レビュー改善、探索的テストの推進と分野がそれぞれ異なったが、「どうやって浸透させていくか」という点で共通していた。
そのため、今回のお話はどの分野でも活用できると感じ、とても有意義な時間だと感じた。
また私はアジャイル開発に携わっていないため、今回の基調講演はとても新鮮であり、講演最後の「スタートはいつも自分から」という言葉は印象に残った。
普段の業務では触れていない分野の情報も収集できるという面で、今後もJaSSTに参加して多くのことを学んでいきたいと思った。