[レポート] Tangible software quality （JaSST’24 Tokyo 基調講演） #jassttokyo

こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。

私は2024年3月14日~3月15日に開催されているJaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyoに参加させていただいています。

今回は聴講したセッションのうち、基調講演であるTangible software qualityについて私なりの概要や感想ついてまとめたいと思います。

Tangible software quality

講演者

• Gojko Adzic 氏

JaSST Tokyoに記載されている講演者の情報はこちらです。

Gojko Adzic はNeuri Consulting LLPのパートナーです。彼は2019 年の AWS Serverless Heroes の 1 人であり、2016 年のEuropean Software Testing Outstanding Achievement Award、および2011 年の Most Influential Agile Testing Professional Awardを受賞しています。Gojko 氏の著書『 Specification by Example』は 2012 年の最優秀書籍として Jolt Award を受賞し、彼のブログは 2010 年の最優秀オンライン出版物として UK Agile Award を受賞しました。

Gojko は、ソフトウェア開発カンファレンスで頻繁に講演しており、 またMindMupとNarakeetの製作者の 1 人としてもご活躍されております。

Gojko はコンサルタントとして、大手金融機関から小規模な革新的なスタートアップ企業に至るまで、世界中の企業のソフトウェアのデリバリーを支援してきました。Gojko は、アジャイルでリーンな品質改善、特にインパクト マッピング、アジャイル テスト、specification by example、およびBDDを専門としています。

概要

以下はセッション概要より引用したセッションの概要です。

品質は直接的にテストすることはできません。しかしながら製品に組み込む必要があります。 そのため、適切な品質ニーズを納品計画と要件に反映することは、ソフトウェアの構築が始まってから今日にいたるまで ソフトウェアデリバリーにおける最大の課題の 1 つであり、それはこれからも同じです。 しかし、品質を定義することは決して簡単な作業ではありません。 人によって違うことがある視点、ニーズ、期待、そしてそれらすべてを統合する仕事を単一の一貫した構造にまとめるのは、ほとんど不可能に近いほど困難です。 Gojkoは、品質の定義に役立ついくつかのモデルを紹介します。 ソフトウェア品質を神秘的なトピックから議論し、把握し、管理することが可能な、具体的なものに変えます。 重要なビジネスバリューと重要な視点がすべて適切に表現され、デリバリー中に評価されることを保証します。

発表資料

2024年3月14日 19時頃ではまだ資料のアップを確認できておりませんので、もし公開があったら更新いたします。

私なりの概要

講演中のメモをベースにしているため必ずしも正しくありませんが、私としては以下のようにセッションの内容を受け取っています。

まとめ

• 講演者の Gojko Adzic 氏 は2019年 AWS Serveless Heros の一人でもあります
• アジャイルでリーンな品質改善、アジャイルにおけるテストを専門とされており、特にBDD（振る舞い駆動テスト）を得意とされている
• 品質は直接的にテストすることはできないけど・・・
  • 一方で製品には品質を組み込む必要がある
  • よって何らかのメトリクスを定義・収集して品質を図ろうとする
  • (私の感想)
    • かための言葉でいうと代用特性というかと思います
    • 講演者も使っていた例ですが、「人間が健康か」ということを直接測ることは難しいですよね？
    • そのために「体温」を図ったり、「体重」というメトリクスを収集して一つの指標にすると思います
• このセッションでは品質の定義に役立ついくつかのモデルを紹介する
  • アイディアは講演者の経験と実践からも来ているもののようです
• 講演者の経験からいくつかの過去プロジェクトの例を出していただく
  • あるプロジェクトでは
    • 関係者とのコミュニケーションもバッチリ
    • 当然のように継続的にテストをしていたし、ほとんど自動テストとしていた
    • それでも会社としては資金難に陥ってしまった
  • とあるプロジェクトでは850万のアクティブユーザーがいた
    • こちらは収益もあがっていたので、「ユーザーもプロダクトから価値を得ていた」と言えそう
  • うまくいっていたプロジェクトでは「正しいことを測定できていた」だと気づいた
    • How to Measure Anythingという書籍にビジネス上の意思決定を行うための測定について書かれていると参考書籍を紹介されていた
• 正しいメトリクスを定義して収集する必要がある
  • ありがちな例
    • コードカバレッジだけを収集
      • 測定も簡単で正確に数字を出すことができる
      • が、本当にカバレッジに執着する価値があるのか？
      • どういう時に、どのように効果があるのか？まで考えられているのか？
    • バグの件数だけを収集して、報告に終始するのみ
      • バグがあっても成功しているソフトウェアも多くある
      • 使う人が重視する品質がバグがあるということよりも重要だった
• メトリクスを収集するにあたって重要な5つのルールを紹介する
• 1 Measure presence , not absence
  • 和訳すると「不在ではなく存在を測定する」となるか？
  • （私の感想）
    • おそらく「バグが発見されなかった」というようなことだけではなく、「保守性がある」とか「機能適合性がある」とかいう求められる品質にあったものを測定する必要があるということかと思いました
  • 頻繁に測定できて、様々な指標を測定して提供しないといけない。
  • だから「どんな判断」「どんな意思決定がしたいのか」というところから逆算して考える
  • そのビジネスにとって重要な判断をするにあたって不確実性を下げることに貢献できる情報を収集する
• 2 Describe multiple qualities
  • （私の感想）
    • こちらは良く聞き取ることができませんでした・・・
    • ただ講演者は「ビジネスとにとって重要な判断をするにあたって不確実性を下げる」ということを何度もおっしゃっていました
    • また、そのために「たった一つのメトリクス」ではなくて「判断をできるように」、必要な品質の特性を説明できるように様々なメトリクスを取った方が良いということを仰っていたように思います
      • 品質の特性の例: 「美しさ」「面白さ」など
      • 例えば製品の収益性や顧客の多さ、などさまざまな指標を取る必要がある
• 3 Trade offs are a product decision
  • 時間やお金は限られていて、すべてを無限にテストしてリスクを0にすることはできない
  • そのためトレードオフを理解して、「何が」「どのくらい重要なのか」ということを考えること
  • 「UIはどのくらいきれいであればよいのか？」や「どのくらいリアルタイム性があればよいのか」など
• 4 Shape priorities with a model
  • ↑のようにトレードオフを理解してビジネス上必要なことの優先順位を決める必要がある
  • そのためにビジネスサイドの方や、開発者などすべての人がわかるようなモデルを作っておくことが重要
  • 講演者がよく利用されたり、好まれているモデルをご紹介してくださいました
    • QUPER model
    • （私の感想）
      • ぜひ講演者本人の↑のブログ記事をご覧いただきたいです
      • 製品の品質を考えるうえで「利益」と「コスト」の3つのブレイクポイントが紹介されています
      • 1: 有用性
        • これを下回っていると市場では通用しないようなポイント
      • 2: 差別化
        • 競合よりも優れているというレベル
      • 3: 飽和点
        • 市場にとって製品が品質が良すぎるというレベル
        • つまり「誰も気づいてくれない」ようなレベル
      • このモデルは「市場にとってどうか」という観点で品質を考えることができるというのが好きなポイントの一つだとおっしゃっていたように思います
        • ビジネスである以上、収益を得る必要があるので「市場」を中心に品質を考えるというのは確かに合理的なような気がしますね
      • 「他の会計ソフトと比べてUIが洗練されていて美しい」で良いのか。「会計ソフトでありながら、ファッションサイトよりもUIが美しい」必要があるのか？
      • 何をどこまでやれば良いのか、クロージングできるのか
    • マズローの5段階欲求モデル
      • （私の感想）
        • いきなりマズローの話が品質の話で出てくると考えておらずおどろきました
        • ぜひ↑の講演者のブログの図だけでも見てほしいのですが、私達が知っているあの5段階欲求のモデルを利用されています
        • 例えば生理的欲求として「水」は必要ですが、必要以上の量をもらってもそれだけ満足度があがらないですよね
        • ソフトウェアの品質で何をどこまでやるかということを考えるときにもこのモデルが使えるようです
        • まずそもそも「デプロイができない」のであれば品質は0ですよね。そもそもお客様になんの価値も届けられていませんし
        • ではそれを満たしたら次は「機能が意図通りに動作しているか」「セキュリティレベルは？」というように「何を」「どの順番で」どこまでやるのかということを図示化できてとても良さそうです
      • なおこのモデルはビジネスによって当然カスタマイズが必要であり、講演者ブログに書いてある順番がすべてではないとのことです
• 5 Visualise and act
  • （私の感想）
    • こちらも聞き漏らしてしまいました
    • モデルを作って「何を」「どのくらいまで」品質を高めるべきかということを決めたら、それのためのメトリクスを収集して可視化するという意味だと思います
    • ソフトウェアの品質は「触れるものである必要がある」というようなことを仰っていたと思います
    • ビジネス上の判断をするのはテスターの仕事ではないが、ビジネス上の判断をできるように可視化して提示できるようにするのはテスターの領分だというように発言されていたかと思います

感想

• 「良い単体テストを書くための技法を知りたい」という方よりも、「私達のプロダクトにとって品質とは何か？どうやって考えればよいのか？」という疑問を持っている方に合うと思いました
• 総じて「お客様にとっての価値を提供できているか？」や「収益性など自分たちにとっての価値を生み出す製品になっているか？」といった観点で品質というものを考える必要があるなと強く感じました
• いろいろな方がおっしゃる言葉で「テストはバグを見つけるということが必ずしも目的ではない」「誰かに必要な情報や気付きを与えることも目的だ」ということがあります
• まさに今回は「ビジネス上の重要な判断について不確実性を下げるために」「メトリクスを集めて可視化して情報を提供しよう」ということがテーマだったように感じており、「テスト活動」だけではない「QA活動」というものの奥深さを考えさせられました