# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、QAエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方や、リスナーのあなたと、 テストや品質の世界を広げていきます。 # 「品質を数値化する」ってどういうこと？ こんにちは、救援エンジニアの紗美です。 今週も振り返っていますか? 今回はですね、品質を数値化するってどういうこと? というお話をしていきます。 話の構成としては、まず最初に今回このトピックを取り上げたきっかけというのかな、 理由みたいなところで私の今の課題感をお話をして、 その後、今回このトピックテーマで話すにあたって 2冊本を買ったんですよ。 そのうちの1冊ですね、データ思考のソフトウェア品質マネジメントという本を読んで、 なるほどなと思ったところとかをいくつか今日ピックアップをします。 そして最後3つ目が、YSの数値化ってどこからやったらいいんだっけ? 最初何したらいいんだっけ?というお話をしていこうかなというふうに考えています。 はい、ということでまず最初は、 そもそもこのトピックを選んだ理由とか課題感についてです。 例えば品質良くなりました。 例えば不具合の件数がこれだけ減りましたって言ったところでですね、なかなかそれって伝わりにくいんですね。 他の人だったり、例えばあるいはビジネス職の方だったり、 経営層の人だったりとか全然伝わらなくてですね、 会社でウォッチしている指標じゃないですけれど、 やっぱりインパクトの大きい不具合というものが起きていないよね、増えていないよねっていうのは毎月見てるわけなんですけれど、 その数字件数が減ったっていう時に、 なかなか自分の活動とか貢献度合いみたいなところまでをロジカルにっていうのかな、 データをベースにして説明できなかったなっていうのがすごい心残りというか、 もうちょっとうまくできないかなというふうなのが課題感です。 なのでもう少し品質を数値化することができれば、 ロジカルに誰が見ても分かるという状態で品質が良くなったねというふうに言えるのではないか、 あるいは改善活動を日々ポストモーテルだったり振り返りをして、 じゃあこういう風にプロセス改善をやっていこうってなって、 本当にそれがやった結果良くなっているのかみたいなところの振り返りという意味でも、 数値化できるととてもいいんじゃないかなみたいなことを考えていて、 そんな課題感を持っていて、 今回の品質を数値化するってどういうことなのというふうなテーマにしました。 私なりの品質を数値化するってどういうことなのかという答えなんですけれど、 品質というのはとても主観的で時代にもよって変わってくるし、 主観的だと思っているので目に見えないものなんですけど、 それを客観的でディスカッション可能にするというのが品質を数値化するということなのかなというふうに考えております。 先ほどの課題感でお話しした通り、 自分たちがリードしている品質改善活動によってどのくらい良くなったのかみたいなところをもう少し明確にと言いますか、 訂正的にではなくて定量的に何か説明できる方法はないだろうかというふうに考えています。 ということでここまでが最初のセクションと言いますか、 今回のこのトピックを選んだ背景だったり課題感についてお話をしました。 続いてがですね、今回本を2冊買ったんですよ。 昨日の夜に届いたので2冊読むことを諦めて今回は1冊を読んでいます。 日課期限から出ているデータ思考のソフトウェア品質マネジメント、 メトリフィックス分析による事実に基づく管理の実践という本です。 買った2冊の本は概要欄にタイトルだけ入れておりますので気になる方はそちらをご覧ください。 本を読んでなるほどなぁとか思った点がいくつかあったのでご紹介をしていこうと思います。 最初がですね、本当最初なんですけど第1章の3ページ目のところで、 ソフトウェア品質マネジメントとは何なのかというのが説明されていました。 ここから引用します。 JIS-9901-2008では品質マネジメントを品質に関して組織を指揮し管理するための調整された活動というふうに定義していると書かれています。 この言葉を読んでですね、まさに自分が最近やっていることだな、ここ数年やっていることだなというのを すごい改めて感じました。 品質に関して組織を指揮する、リードをするというのと、管理するための調整された活動ということで色々品質を管理するために行っている活動なのかなというふうに私は解釈したので、 例えばポストモーテムとか振り返りを通してこういうことをやっていったらいいよねっていう改善案を考えてそれを実行していくっていうのが品質マネジメントの一つのアクションなんだなというふうなことを理解しました。 その後にもですね、この本の中には品質計画、品質管理、品質保障、品質改善というものが品質マネジメントには含まれますよというふうに書かれていたので、 まさに最近行っている品質改善というのが品質マネジメントの一種、一つの活動なんだなということを理解しました。 続いてですね、1.2の品質データ分析の基本というところで、お作法が9個書かれているんですけれど、特に印象的だったのが作法9のソフトウェア品質データの信頼性の低さを理解するというお作法でした。 他のお作法はですね、正しい問題を設定しましょうとか、ちゃんと目的と整合性のあるメトリクスを決めましょうねとか、それはそうだよなというか、 これまでの勉強とかでも知っていた内容だったんですけど、この作法の9番ではソフトウェア品質データの信頼性が低いんだよということが書いてあって、 え、そうなのというふうに意外に感じたりをしました。 なぜ信頼性が低いのかというと、基本的にはソフトウェア品質データというのは人の作業の結果とかインプットだったりもするので、人の違いによってばらつきというのも起きてくるし、 例えばソースコードの量数に関しても、開発者の知識、スキルレベルによって同じものを実現できるものであっても、ソースコードの量数って変わってきちゃうしというところなので、 ソースコードの量が多いから良いとか悪いとか、そういうふうに違いには言えないですよね、確かに。 なので、何だろうな、あくまでも一つのデータというか情報ということで、ちゃんとその数字、データを見ていくのが大事なのかなというのを読んで感じましたし、 あとは正しい手法と、ソフトウェア品質データの信頼性の問題というののバランスをしっかりとるのが大事なんだなというので、 やっぱり品質のデータ分析って難しいんだなというのも読んで改めて感じたりしました。 本の紹介は三つ目というかもう一つで終わりにしようかなと思っているんですけれど、 この本の良いところはなんか事例として書かれているのがすごく良いなというのが感じていたりはするんですけれど、 特にパラパラと読んでいて気になったのが、2.4のソフトウェア開発における品質コスト分析というのがすごく気になりました。 この品質コスト分析って何だろうという話なんですけど、 やっぱりソフトウェア開発において不具合の検出が後行程になればなるほどコスト修正にかかる、コストかかるよねというのはよく最近と言いますか言われていることだとは思います。 なのでなるべく上流で不具合を見つける、結果を見つけるだったりとか、 あとは防ぐということですかねというのが大事ですよねというのはよく言われている話だと思っていて、 じゃあ実際にそのどのくらいのコストかかっているんだっけというのってちゃんと数字で出したことないなあってこの2.4の章のところを読んでて思ったわけです。 すごくなるほどなって思ったのが、品質コスト分析があるんですけど、品質活動を4つに分類しているんですよね。 4つが何かというと、予防、評価、内部失敗、外部失敗とこの4つにコスト分類して把握をしているというのが、そういう見方があるんだというのがすごく学びというか新しい視点でした。 欧米を中心に日本でも特に製造業で使われている層なんですけれど、これをソフトウェア開発に置き換えると基本的にその品質のコスト分析というか内容は、 コストというのはほとんどが人件費なので、そこの人件費を計算する時間と、例えば平均単価とかその辺をかければ品質コストというのが出せるはずなんですよね。 何となくこれまでの自分の頭の中では、この4つの分類でいうと、外部失敗のコストをちゃんと数字として出すというのはやりたいなというのは何となく考えていたんですけども、 全体感としては、予防、評価、内部失敗、外部失敗、悪不不の4つになるんだなというのはふむふむと思いながら読んでいました。 ちなみにこのそれぞれが何かというと、予防というのがレビューの実行コースとかですね、例えば、欠陥の混入と発生を早期に防止するためのコストが予防コストです。 続いて評価コストというのが、テストなどで品質を評価することによって品質レベルを維持するためのコスト。 内部失敗コストというのが、プロダクトリリース前に不甲斐や欠陥が発見された場合に発生する修正コスト。 外部失敗コストというのが、プロダクトリリースの後に不甲斐や欠陥が発見された場合に発生する修正やユーザー対応などのコストというふうに書かれています。 この定義を見てみると、評価コストとかで、主導の部分メニューになりますけど、テストの実行時間とかはとっていたりするので、ある意味時間の計測はしていて、 あと内部失敗のところリリースの前か後かというところをよく見ていたりする分類をしていたりするので、時間は計測してそうです。 # 続き アイテムを読んでみてですね、外部失敗コストのところ、特にそのプロダクトリリース後に見つかった不具合だったりの修正とかユーザー対応のコストみたいなところはこのくらいかかるんですよ。 で、Kチームとしてはこういう活動を推進して、その結果このくらいのコストを削減できてるんですよみたいなところが、 金額として説明できるととてもいいのかなというのを改めて感じたので、ちょっと計算出してみたいななんて考えております。 はい、ここまでが2つ目の話ですね。本の紹介と、あと自分の考えていることを話をしました。 最後3つ目がですね、まあとはいえ最初に何したらいいのっていうところの話をしていこうと思います。 今回紹介している本だと結構難易度が高そうと言いますか、例えば不具合を可視化することによって開発終盤の品質状況とかちゃんと不具合検出できるかできているのかの確認だったりとか、 あとレビューのプロセスが妥当なのかみたいなところの評価だったりとかですかね。 あとは不具合検出率の話とか、不具合曲線の話とかも書いてある。信頼度成長曲線ですね。 話とかもあるので、興味ある方はぜひ読んでみてくださいという感じなんですけど、データ分析とか全然やったことなくてみたいな方にはですね、 お勧めしたいのが、テストの実行工数の推移とか、余実さを出してみるっていうのはまずお勧めをします。 どちらかというと、ウォーターフォールとかがっつりこのテストケースを今回実行するぞっていうのが決まっているものを今イメージしながらお話をしているんですけれど、 例えば1週間とか1ヶ月とかでテストを実行しきりますという時に、じゃあ実際に毎日、今日は何件進んだ、何件終わったとか、毎日記録をとっていってますよね。 それがその数字を見ながら、余実比を予定と実績みたいなところを見て、ちゃんと予定の期間で終わるのかなみたいなところは毎日とっていくっていうのは、 まず最初にやってみるのをお勧めします。 すでにどうなんだろう、テストレールとか使っていれば、割りかし簡単にグラフで出せたような気はするんですけれど、 スプレッドシートとかでも関数を組んで、全体が例えば100件あります、今日は10件終わったので残りが90件です。 残りの日付予定の、例えば1週間、ご営業日でワルゴすると、あと何日分か、このスピードだとあと何日で終わりますっていうのは出せますよね。 100件あって最初の1日目で10件しか進んでないと、残りの4回で終わらないんですけど、 そんな感じでテストの実行が進捗、進捗が順調なのかっていうところを見るっていうのをまずやってみるのはどうでしょうか。 今ちょっとテストの実行の項数と実行数のテストケース数、ちょっと混ぜて話をしてしまったんですけど、 2つ軸があると思っていて、テスト実行の項数ですね、時間、何時間ぐらいかかる予定で、実際このくらい何%消化しているというか、 何時間使ったのかっていう観点と、その時間を使って何ケース分が進んだのかっていうところ、 この2つ合わせて両方の数値を見ていくと、予定している期間内にちゃんとテスト実行が終わるのかというのを、 とてもロジカルに数字で表現することができるかなと思います。 もちろんテストの実行って最初は順調にいって、残りの10件が一番時間がかかるとか大変だったりするんですけれど、 でもテスト実行の序盤とかで、明らかにこのスケジュールじゃ終わらないよねみたいなのがあれば、 早くアラートが上げられるので、その数字で進捗を見せるというところもとても大事かなというふうに考えております。 ということで、今回は品質を数値化するってどういうことなのというお話をしました。 品質のメトリックスとかデータ分析っていうのは、まだまだ自分も勉強していきたい分野なので、 また何か新しい知見だったりとか、やってみた実例とか事例とかっていうところがあれば、別の放送でお話しできればなと思っております。 # AIコソコソ話🍶🍻打ち上げの場所探し AIコソコソ話のコーナーです。 今回は打ち上げの場所を探すのにジェミニーを使ってみたよというお話をします。 今ですね、趣味でやっているオーケストラの打ち上げ感じみたいなものをやっているんですよね。 所持場ありまして、三軒座屋付近でだいたい50名ぐらい入れる店を毎回探さなきゃいけないんですよ。 そもそも三軒座屋って結構小さなお店が多かったりもするので、50人入れる箇所がなかなかないっていうのと、なるべくその演奏会の本番の会場から近いところが良いですし、 かつあと楽器とか荷物もとにかく多かったりするので、荷物を置く場所も必要だったりするんですよ。 という状況で、去年の春ぐらいのタイミングで一回休日に三軒座屋をウロウロしながら、実際お店の雰囲気とかサイズ感を見ながら、これなら入れそうかなみたいなのを見ながら足で調査していたんですよね。 なかなかいいお店が見つからなくて、毎回違う場所を開拓中なんですけど、ふと今回のお店を探すときにですね、ちょっとジェミニーに聞いてみようかななんて思ったわけです。 今履歴見てたらめっちゃジェミニーって言ってたんですけど、チャットGPTでした。まあいいや。 で、チャットGPTにお願いしたのは、三軒座屋で50名が入れるレストランを探してますと、まあそんな風に送ったわけですね。 そしたらですね、1,2,3,4,5件教えてくれました。 最初は1件目私も知ってた場所なんですけど、ちょっとお値段が高くて頼めないなという感じだったんですけど、 他にも4つお店書いてくれていて、50名って言ってるのに最大35名様とかっていう風に書いてたりする場所もあるんですけど、 私が知らない店を教えてくれたのでとても助かりました。 この後はですね、そのサイトを見て何人まで入れそうかなみたいなところをちゃんと確認をして、 ちょっと今回このチャットGPTで見つけたお店を予約しようかななんて思っております。 以上、AIコソコソ話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、ウェブアプリケーションとモバイルアプリケーションのテストの違いとは何かというお話をしようと思っております。 これはですね、先日のJUST TOKYOで私自身が登壇したセッションでいただいた質問になります。 今回の放送を聞いて、なるほどな、確かにな学びになったなと思った方は、 ぜひ画面右下ハンドマークでいいねを押していただけると、とっても励みになります。 SNSや口コミでのシェアもぜひぜひよろしくお願いします。 それではまたお会いしましょう。おきげんよう。