JaSST'24 Tokyo 1日目 / A1 Tangible software quality

yocaji
·

※発表を聞きながら取っていたメモを元にしているため、誤りがあるかもしれません。あくまで個人のメモということでご了承いただければと思います。修正が必要な場合はDiscordのid:yocajiまでお知らせいただければ幸いです。

登壇者

Gojko Adzicさん

導入

測定できる(しやすい)メトリクスではなく、意思決定を起点として必要なことを測定するべき。

バグがないから品質が良いとは言えなくて、バグがあっても価値あるソフトはある。昔のWindowsとか。

品質のピラミッド

  1. SUCCESSFUL

    私たち(組織)にとってのアウトカム

  2. USEFUL

    ユーザーにとってのアウトカム

  3. USABLE

  4. PERFORMANT SECURE

  5. DEPLOYABLE FUNCTIONALLY OK

  • すべて定量的に測定可能

  • 1~2はデプロイされないと測定できない

    • たとえば2ではユーザーにどれだけ使われているかなどを見る

  • 3~5はデプロイ前に測定可能

    • 品質が十分と言えるラインがあり、それ以上上げても意味がない

QAはSUCCESSFUL、USEFUL、USABLEを測定する部分に関わらなくてはならない。ただし意思決定とは別で、プロダクトの意思決定はプロダクト側が行うべきで、QAは必要な情報を集め、意思決定をサポートする。

まとめ

  1. MEASURE PRESENCE, not absence

    測定するべきは存在することであり、存在しないことではない

  2. Describe multiple QUALITIES

    一つの品質(メトリクス)にとらわれず、複数の品質を見る

  3. Trade-offs are a PRODUCT DECISION

    トレードオフはプロダクトの意思決定

  4. Shape priorities with a MODEL

    モデルを使って優先順位をつける

  5. VISUALISE and ACT

    情報を可視化して行動する

感想

「リアルタイム」ってリアルタイムじゃないんかい、っていう行き違いの話がちょっと面白かった。こういう言葉の行き違いはどこでもある話なんだ。