こんにちは。QAエンジニアをしている有名じゃない方の高橋です。
JaSST2023 B7シフトレフトの失敗事例から学ぶ次のアプローチにて、GQM法について多く質問頂いたので追加説明と、おまけの紹介です。
JaSSTとは
JaSSTとは「ソフトウェアテストおよびソフトウェア品質に関心のある方が深い学びを得ることを目指して、 ソフトウェアテスト分野の幅広い情報と、参加者同士の交流や議論ができる場を提供」するため、特定非営利活動法人ソフトウェアテスト技術振興協会 (ASTER)が主催する日本最大級のソフトウェアテストのシンポジウムになります。
JaSST’23 Tokyoのテーマは「相互理解で広がる世界」ということで、関連するセッションが多数催されました。
B7シフトレフトの失敗事例から学ぶ次のアプローチセッション
今回縁があって3/10(金)11:30~ B7「シフトレフトの失敗事例から学ぶ次のアプローチ」にて登壇しました。発表に使用した資料は近日共有されますのでお楽しみに。
発表内容は、シフトレフトを目指して施策導入し成功や失敗した話、よりよいシフトレフトを目指す話になります。この中で導入の失敗事例で紹介した「GQM法による品質特性毎のメトリクス設定」について皆さん興味や質問を多く頂きました。
せっかくなので説明を補足します。
GQM法について
詳細は下記を参照ください。
目標（Goal）を据 えたうえで、目標達成を評価する質問（Question）およびその回答に必要なデータを得るための測定法 （Metric）を決定する。 特に、抽象的で本来不可視なソフトウェアの品質を捉えるうえで重要である。
実践的ソフトウェア品質測定評価のための 4 つの「落とし穴」と7 つの「コツ」より
セッションで頂いた質問へ補足回答
セッションで頂いた質問の一つに「GQM法で実際に設定されたゴールと問いの組み合わせのパターンの一例を教えていただけないでしょうか？」とありました。
セッションの中で「お客様先で作成した資料のため持ち出し出来ないので紹介できません」と回答しました。作成したものを見せることは出来ませんが、IPAが作成した「つながる世界のソフトウェア品質ガイド」に参考にした具体事例がありますので紹介します。
各品質特性毎に「品質測定量」の項目があるのでメトリクスの参考にしてください。
またセッションの中ではお伝え出来ていませんが、そもそもすべての品質特性にゴール、クエスチョン、メトリクスを設定する必要はないと考えます。
プロダクトの特性に応じて必要な品質特性を決めて、該当するものに対してGQMを設定すべきです。例えば人命リスクや金銭リスクが発生する可能性のあるプロダクトや、24時間稼働を求められるインフラ系プロダクトと携帯ゲームでは必要とされる品質特性が異なりますよね。必要なものを必要なだけ。この見極めが重要です。
また他の質問では「GQM法は失敗だったとありますが、逆にどのようなことをすれば成功の糸口があったとありますか？」とありました。
回答としては、「小さく始める」になります。
まず規模、4～5人程度の小規模で実施します。この時に出来る限りプロジェクトのキーマンに協力してもらえるようにします。このキーマンに説明して協力を得られないようでしたらそもそも成功の確率は低いです。
次に対象、「必要なものを必要なだけ」の考えのもと必要な品質特性を見極め、その中で一つだけ対象とします。例えば機能適合性、互換性、移植性の３つが必要とするとその中で今回は互換性のみ測定対象とする。
規模と対象、この２つを「小さく始める」ことで成功の糸口はあると思います。
GQM法は品質だけでなく課題解決にも利用できる汎用的な計測モデル手法です。
興味を持った方は是非活用してみてください。
おまけ
<Sqripts>ではJaSST’23Tokyoのまとめブログが公開されます。
きっとあなたの見逃したセッション、少し気になるセッションもブログ化されるのではないでしょうか。ご期待ください。
以上、あとがきとおまけでした。
