# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、Qエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 ゲストの方やリスナーのあなたと、テストや品質の世界を広げていきます。 # 3つのステップ こんにちは、キュウエンジニアのサミーです。 今回はコストダウンを求められた時に 実行した3つのステップの話をします。 まず最初に、その3つのステップとは何かですね。 1つ目、ステップ1、一番コストがかかっている箇所を炙り出す。 ステップ2、がっつり減らせる方法を考える。 ステップ3、考えたアクションを実行し、実行と検証を繰り返す。 この3つのステップというのは、私がいろいろ実行実験ですかね、 試してみた結果、この3つのステップになったなと分かった学びなので、 私がどういう課題にぶち当たっていて、どういうふうに考えて行動していたのかという具体的な事例の話をこの後、 次はしていこうと思っています。 状況としては、コストダウンが求められていましたというところなんですけど、 もう少し具体的に言うと、リグレッションテストですね。 毎週アプリのリリースをしていまして、そのリリースの前にリグレッションテストを行っています。 そこのコストが、ここ数ヶ月増えていて、 適正値まで戻してほしいというオーダーが上司、マネージャーの方からありました。 最初は失敗談のお話なんですけれど、テストケースの数が2000件超えていたんですね。 これは確かに時間がかかるだろうなと思って、ケースが多いのが原因、コストがかかっている、時間がかかっている原因だと考えたんですね。 特に根拠もなく、こんだけあったらそれは時間かかるよねと思ったので、 まずリグレッションテストケースを数ヶ月ぐらいかけてですね、刷新といいますか更新をしました。 ところがですね、テストの実行時間、コストというところは変わりませんでした。 それで、ちょっとこれはいかんなというふうに反省をしまして、改めて今どこに一番コストがかかっているのかを分析しました。 月額の費用はもちろんのこと、単価と時間、稼働時間、あとは予算、目標の金額このくらいという目標があったので、 そこと比較してどのくらい差分があるのかというところを計算をして、スプッシーとか表にまとめながら分析をしました。 それで分かったんですけどね、ちょっとやそっとの改善じゃ全然目標を達成しないということに、そのタイミングでようやく気づきました。 イメージをお知らせするために言うと、イメージとしては時間、コストは半分ぐらいにしないといけないという計算ですね。 リグレーションテストのプロセスを分解してみて、一番どこに時間かかっているかというのを炙り出すためにプロセスの洗い出しをしたわけなんですけれど、 ざっくりテストケース、また新しい機能ができたらテストケースを追加します。 実行する方は新しい工夫がされている部分、あるいは更新されている部分の読み込みだったり、読み込みプラス使用理解、新しい機能の使用理解があります。 次がテストデータの準備、必要に応じて、例えば毎月のデータが必要な場合は、月初にテストデータを作る必要があります。 テストの実行を、その後に不具合が見つかったら不具合の再現ですね。手順確認とか不具合再現があって、不具合報告があって、 場合によっては不具合の修正確認もあるかもしれませんという感じですね。 あとは完了報告、実行の完了報告というところを、ざっくりリグレーションテストのプロセスを分解してみるとこんな感じです。 どこに時間がかかっていたかというと、圧倒的にテストの実行のところに時間がかかっていたわけです。 なので、コストを半分にするためには、このテストの実行時間を圧倒的に半分ぐらいに下げる必要があるということになります。 ここからがステップ2の、がっつり減らせる方法を考えるというところに入っていきます。 苦渋の決断をしまして、毎週2つのアプリをテストしてリリースしていたんですけど、1つずつにさせてほしいという話をしました。 最初はマネージャーの方と話をして、それでやってみましょうという合意をもらいつつ、 開発チームのリーダーの方にも話をして、ちょっと挑戦させてほしいと。 やってみて問題があったら元に戻すのでというような話をしながら、チャレンジをさせてもらいました。 そこから毎週、予定の時間というんですかね、稼働時間と実績がどうだったのかというところを見て、 どういうときに稼働時間が増えてしまうのかというところを数字で計測を始めるようにしました。 あと数字だけじゃなくて月の単位でも稼働時間がこのくらいに入っていれば、 月の予算というところは達成できるんじゃないかというふうに仮説を立てて、 毎週数字を入れて、データを入れて、週の振り返りと月の振り返りというところを何回か繰り返してみました。 ところが、その想定していた工数、稼働時間に抑えても、なぜか月次の予算にはまで下がっていないということが判明しました。 それでまた何でだろうというところで、実績の数値で請求書の金額だったり、稼働時間だったり、不具合報告数だったり、 あるいはリリースの数だったりというところをいろいろ数字を見ていく中で、 ここは考慮してなかった部分で時間がかかっていたとかお金がかかっていたということが判明しました。 3つ目のステップにぬるっと入ってしまったんですけど、ステップ3は変数の仮説を立て実行を検証を繰り返すです。 ここで言っている変数というのは、安藤光大さんの本ですね。 確か数値化の鬼だったかなと思うんですけど、数値化の鬼の三部作に確か書いてあった言葉だと思っていて、 何かしらの事象にインパクトを与える要素というか変数が何なのかというところをしっかり見極めるのが大事だなというのを本から学びまして、 それを実践してみたということになります。 レギュレーションテストの話に戻ってくるんですけれど、見ていくとやっぱり不具合報告数が多いとトータルのレギュレーションテストのコストというところも増えるということなんですね。 再現に時間がかかったりとかスクショとか動画撮ったりとかというところもあるので、不具合の報告数が増えるとどうしても全体のコストがかかってしまうということも分かってきました。 なのでここで言う変数、レギュレーションテストのコストにおける変数というのが不具合報告数であることが分かります。 もちろん変数は一つだけではないんですけれど、そこで不具合報告数を減らすためにはどうしたらよいのか。 もちろん根本的に不具合をもう少し前の工程で見つけるとか防ぐというところもあるんですけれど、 レギュレーションテストの中ではどういうふうに減らせるかなみたいなところを考えてアクションをしてというアクション、実行と検証を繰り返しています。 現時点では振り返ってみると、一番多かったコストが増えてしまっていたところと比べると半分ぐらいにはなっていて、一定効果は出ているのかなというふうに考えています。 あとはテスト実行、レギュレーションテストの実行のコストの見積もりがすごくしやすくなりました。 だいたいこのくらいだろうなという、裸感といいますか新しい機能をリリースするときはこのくらいかかる。 そうじゃない小さい改善とか不具合修正しかない場合はこのくらいかかるというところが約束できるようになりました。 コストがコストダウンできたというところも一定嬉しい成果が出て嬉しい部分でもあるんですけれど、それ以上に予測ができるようになったというところの方がやってみた、 変数が何かというところを仮説を立てて実行と検証を繰り返すというのをやってみた結果、一番嬉しかったことかなというふうに考えています。 はい、ということでコストダウンを求められたときに実行した3つのステップの話でした。 ステップ1、一番コストがかかっていることをあぶり出す。ステップ2、がっつり減らせる方法を考える。ステップ3、変数の仮説を立て実行と検証を繰り返すでした。 # 今日のほっこり話 今日のホッコリ話です。 12月24日に会社でクリスマスパーティーを企画してやりましたという話です。 イベントごとを考えたり企画したりやるのがすごい好きなんですよね。 今月12月はクリスマスパーティーやりたいなと思って企画をしました。 せっかくならプレゼント交換やりたいなぁとか思いましてプレゼント交換もしたんですけれど、 ただ単に交換するだけじゃ面白くないなぁなんてことを考えてまして、 ボードゲームと言いますかカードのゲームで買った人からプレゼントを選ぶ、 くじを引いてプレゼントを選ぶみたいな形式にしてみました。 今回音速反転っていうカード、かわいいカードがあるんですよ。 カードゲームって言うんですかね。ボードゲームのカードって言うんですかね。 それをポチッとAmazonでポチりまして、 あとドブルも買ったんですけど、音速反転とドブルを買ってやってみました。 すごい盛り上がって、私も楽しかったですし、参加した方からも楽しかったですって言ってもらえたので、 企画してよかったなぁと思いました。 以上今日のほっこり話でした。 # スタンプをぺたっとコメントで送信してみてください📝コメント強化期間📝 引き続きコメント強化期間です。 先日はですね、私の方でコメントを書いて、今の気持ちは?というコメントを書いて、それに対して、いいねを押してもらうということをやっていただいたんですけど、 Miru999さんとKouhei Katsuyaさんからいいねをいただきました。ありがとうございます。 パチパチパチパチ。 ところがなんですけど、そのいいねをしていただいた時の通知が、Voicyの再生アプリの方に来るんですよね。 私ずっと収録のアプリ、再生のアプリと収録のアプリで別なんですけど、収録アプリの方で通知が来ないなというか、通知をウォッチしていて、 ちょっと気づきづらかったというところがあるので、ちょっとやり方を変えてみようと思います。 放送の再生中でも、再生後でもいいんですけれど、スタンプをペタッとコメントで送信してみてください。 皆さんの気持ちでもいいですし、放送を聞いてみてでもいいですし、ぜひスタンプをペタッと押してみてください。 あなたのスタンプペタッ、お待ちしております。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回は仕事英語で一番恥ずかしかったスペルミスのエピソードをお話ししようと思っています。 いいねと、もしこの放送とかチャンネルいいなと思っていただけましたら、SNSでのシェアをしていただけるととても嬉しいです。 それではまたお会いしましょう。ごきげんよう。