ストック型コストの怖さを理解して品質改善に取り組もう

この記事は freee Developers Advent Calendar の 15日目です。

freeeでQAエンジニアをしている石塚(@mishizuka99)です。

これまでWeb・モバイルアプリテストの自動化、品質向上のための関係者の巻き込み、手動テスト作成、テスト実行チームのマネージメントなどを7年ほどしてきました。その中で「感覚では分かっているけど伝えるのが難しかった」コストについての説明をしてみます。

（QA以外の方にも読んでいただきたいので用語や例は簡略化しています）

こんな経験はありませんか？

効率を良くするための自動化施策のはずなのに、続けるほど苦しくなる（やめたいけど過去の自分を否定するのは悔しいから続けている）
いい施策を思いついたが人員や予算の確保のためどう関係者を説得すればいいかわからない
開発者にテストをお願いされて喜んで引き受けたが、繰り返しやるテストなのでどんどん負担になってきた
「いいテストの仕組みが完成しましたね！さて、次の期は何しましょうか」
「あ、あれメンテが一生続きますよ！」
「！？」
みたいな会話をしたことがある

これらは継続的に積み上がっていくコスト（ここでは「ストック型コスト」と呼びます）のインパクトをイメージしきれてないために起きる問題です。

ストックとは

ビジネスで「ストック」「フロー」というと、収益モデルを指すことが多いです。

ストック型ビジネス → 月額・年額支払いなどで継続的に収益を上げるもの。（NetflixやSpotify、freeeもこれですね）
フロー型ビジネス → 売り切り型ビジネス。普通の小売など、継続課金でないもの。

ストック型は、初期の爆発力はないですが地道に規模を拡大していければとんでもないインパクトを出せるようになります。

これはコストに関しても同じことが言えます。最初は簡単だと思って始めたものが、続けていくうちにとんでもない負担となることがあるのです。

品質向上施策での例

前提

ここで言う「コスト」とはざっくりチームが費やす時間や費用をイメージしています
「一定の成長を続けている企業」つまり社員数、ユーザー数、プロダクトが成長している前提の話です

繰り返し行う手動テストの例

「品質が悪いからユースケースを網羅した手動テストケースを作ろう！今後リリースする度にそのテストケースを回せば安心だね！」
そんなプロジェクトが始まったとします。

担当者はこう考えました。
「よし、1月にテストケースを作りきって2月に運用開始だ！そういえば3月に新機能でるからその分ちょっと3月は大変かな」ぼんやりこんなグラフが頭に浮かびます

繰り返しやる系テストのコストの棒グラフ。縦がコストで横が期間。1月は高く、2月は低く、3月は2月より少し高くなっている

しかし拡大を続けるプロダクトに対し網羅的なテストを回し続けるとなると、実行コストはもちろんメンテナンス(仕様変更や新機能に追随するテストケースの作成)がどんどん発生します。

なので、少し引きで（長めの期間で）見るとこうなります上記グラフの「期間」を長く見た棒グラフ。更に9本の棒が右肩上がりで追加されている

もちろん実際は直線ではなく曲線になったりデコボコしたりもするでしょう。ただ手を打たない限り増えつづけていくことに変わりありません

さらに引いて見ると、、、繰り返しやる系テストのコストをイメージした棒グラフ。80本ほどの棒で右肩上がりのコストを表している。

これがストックの恐ろしさです！

これを踏まえると下記を考える必要があります

このコストの増加を少しでも抑えることはできるのか
誰がこのコストを払い続けるのか
このコストの増え方に対してリターンがあると言い切れるのか

関係者間でこの認識が曖昧のままズルズルいくと、どんどん苦しでいった先に破綻も見えてきてしまいます。特に四半期ごとに目標を設定する文化がある組織（freeeもそうです）では、認識のズレが起きがちになります。

自動テストはどうか

「手動テストはコストが掛かりすぎる、時代は自動だ！」と言う人もいるでしょう。

自動テストもいろいろありますが、手動テストの代わりになるようなE2Eテスト (プログラムしたとおりにブラウザやアプリを自動操作するテスト)で考えてみます。

テスターの動きをコンピューターが代わりに自動してくれるものなので、当然「実行」のコストは大幅に減ります。それ以外にもレポートや通知などコミュニケーションのコストも減らせます。

ただ仕様変更や新機能に追随するテストケースの作成は結局発生するので、対策を打たない限りコストが積み上がっていく構造には変わりません。

自動化は自分も好きなテーマですが、ストック型の脱却にはならないことは理解しておく必要があります。

開発チームとの協力が必要な場合

品質は全社で取り組むべきテーマなので当然他チームと行う施策もあります。

たとえばQAチームが開発者に「一緒にやろうよ」と持ちかける施策はこんなものがあるでしょう

自動テストをやりやすくするためのラベルを作ってもらう
品質関連データが集計できるようタグを入れてもらう

ただ、このグラフのように実は開発者の負担が増え続けるケースだった場合、「こんな大変だって聞いてなかった！」となるかもしれません。 QAのコストと開発者のコストの積み上げ棒グラフ。全体は右肩上がりで、内訳は最初は同じ比率だが、期間が経つに連れて開発者の割合が増えていっている

さらに多くのチームを巻き込む場合

たとえば「社内でバグの報告するときには、QAが分析できるよう詳細な情報を書いてください」といったケースはさらに多くのチームを巻き込むことになります。

。セールス・サポート・開発・QAの4チームのコストを表している積み上げ棒グラフ。全チーム同じような割合で右肩上がりで増えている

こういったコスト負担について、全関係チームが納得感を共有できていることが大事です。

別チームからQAに依頼されるパターン

開発者から「バグが出てしまったので、こういうテストを今後毎回やってほしいです」と頼まれることもあると思います。また、開発者から丸投げではなく、自動テストケースを作ってくれて「QAチーム忙しそうなのでテストは自分で作りました！」のような嬉しいケースもあります。ただ、その後をQAが見ていくとなると継続的なコストを負担し続けることになってしまいます。

ストック型ビジネスがサブスクリプション「契約」に基づくように、ストック型コストの施策についても「契約」（ちょっと大げさですが）のような意識を持つことが必要です。