バグゼロとは

バグゼロとは以下のいずれかとします。

リリース後に発見されたバグがゼロ件だった
バグ修正により検出済みのバグがゼロ件になった

なぜバグゼロになるのか

リリース後に発見されたバグがゼロ件になるのはなぜでしょう。
リリース前のテストで全てのバグを見つけ出せばそうなります。
それは、テストが過剰だった可能性があります。

検出済みのバグがゼロ件になるのはなぜでしょう。
バグ修正を高い優先度で対応するとそうなります。
それは、バグ修正より価値のある開発タスクが存在しない可能性があります。

テストが過剰だとバグゼロになる。
価値のある開発タスクが存在しないとバグゼロになる。
バグゼロは良いことだと思っていたのに・・。

※念のためですが、クリティカルなバグを残してよいという意味ではありません。

バグゼロが示す兆候とは

テストが過剰な状態。
それは、テストのコスパが悪い状態です。
プロダクトの価値を高める開発に時間を奪っていると言えます。

価値のある開発タスクが存在しない状態。
それは、プロダクトが新たな価値を生み出せない状態です。
プロダクトが終焉に向かいかねない危機的状況だと言えます。

バグゼロはプロダクトが悪い状態に陥っている兆候です。
できれば「バグゼロになりそうだ」というタイミングで気付きたいところです。

注意として、バグゼロはあくまで兆候です。
実際に悪い状態に陥っているか落ち着いて確認し、必要ならば手を打ちます。

バグゼロに陥らないための行動と心構え

バグゼロの原因は「テスト過剰」と「価値のある開発タスクが存在しない」でした。
この原因から考えることで、バグゼロに陥らないための行動は見えてきます。

コスパのよいテストをおこなう
価値の高い開発タスクを作り、着手可能にする

しかし、実際に行動するには心理的な壁があるかもしれません。

そうはいってもバグは出したくない
バグを放置して新規開発することに抵抗感がある
品質を担う QA がバグを放置するなんて無責任だと思う
「バグってる」とか「バグが残ってる」とか「バグバグ」言われたくない

この心理的な壁を乗り越えるには、プロダクトの視点で考える必要があります。

NG: 自分にとって、バグを放置することに抵抗感がある
OK: プロダクトにとって、軽微なバグ修正より機能開発する方が価値が高い

以下の心構えがあれば、心理的な壁を越えやすいと思います。

プロダクトの視点で考える
プロダクトの価値を最大化する行動を考える

QA は何をすればよいのか

ここからはプロダクトの品質に深く関わる QA の立場で考えます。
チームとしてやるべきことは以下でした。

コスパのよいテストをおこなう（クリティカルなバグを見逃さない）
価値の高い開発タスクを作り、着手可能にする

コスパのよいテストはイメージしやすいと思います。
それでは価値の高い開発タスクを作り、着手可能にするとはどういうことでしょうか。

「弥生請求 Next」を開発しているチームの実例を 2 つ紹介します。

要件や仕様を決めるための材料を出す
運用や非機能に関する要件を出す

要件や仕様を決めるための材料を出す

計画中の機能を開発着手可能にするには、要件や仕様を明確にする必要があります。
そこで、次のような情報をまとめてプロダクトオーナーに渡します。

要件や仕様に含めた方がよいことの一覧
要件や仕様の具体案や選択肢

プロダクトオーナーは多くのことを意思決定しなければなりません。
また、判断材料を集めることに意外と時間も期間もかかるものです。
「これを決めてください」「あれを教えてください」では負担を増やしてしまいます。
意思決定に必要な材料を準備し、あとは判断すればよいだけの状態を目指して行動します。

NG: 「要件は何ですか？」
NG: 「仕様を教えてください」
OK: 「メール送信機能の要件に DMARC 対応を入れてほしいです」
OK: 「予約実行系の機能は “○時に実行” ではなく “○時台に実行” という仕様にしてほしいです」
OK: 「非機能要件を決める材料として販売計画から 1 年後の想定データ量をまとめました」

意思決定に必要な材料は、全てを自分で集める必要はありません。
次のように調査タスクを作れば、分担して進めることができます。

次のように少しでも前に進めることを意識します。

要件が未検討の状態 → 要件が検討可能な状態
仕様が未検討の状態 → 仕様として決めるべきことが明確な状態
何を調査すべきか分からない状態 → 何を調査するべきか明確な状態
...

「QA はテスターとは違い上流工程にも参加する」と説明されることがあります。
この「上流工程に参加する」を「上流工程に同席する」に取り違えないように注意します。

NG: 要件や仕様を決める場に同席し、思いつくままに指摘するだけ
OK: 適切な要件や仕様を決められるように、先手先手で判断材料や案を出す

ミーティングに同席し、聞くだけの存在になってはもったいないです。
反対に、問題を指摘するだけのご意見番ではマイナスになりかねません。
上流工程で品質を作りこめるように、口だけではなく、手を動かします。

運用や非機能に関する要件を出す

プロダクトオーナーは顧客に価値を提供するために頭を悩ませます。
そのため、運用や非機能を十分に考慮する余裕がないこともあります。
運用や非機能に含まれるものはいろいろあります。

十分なパフォーマンスを出してほしい
十分なセキュリティを確保してほしい
適切なサービスレベルを設定してほしい
障害対応などの運用体制を整えてほしい
…

例えばパフォーマンスについては以下をおこないました。

1 年後の想定データ量・アクセス数を試算する
パフォーマンステストに対する要件（達成基準）を作成する
パフォーマンステストのシナリオ案を作成する

要件（達成基準）として出した内容は以下です。

要件

以下のいずれかを満たすこと

(1) 2025年10月時点の想定データ量・アクセス量に耐えることができる、またはアーキテクチャを変更せずに対応できる

例: 現時点で耐えることができる

例: ECS のタスク数を増やせば対応できる

(2) アーキテクチャ変更が必要であることを事前に検知でき、余裕のあるスケジュールで対応できる

例: DynamoDB によるセッション管理が破綻する 3 か月前に検知でき、3 か月あれば余裕のあるスケジュールで対応できる

要件に対する補足:

アーキテクチャ変更が必要になった場合でも1年あれば計画的に対応できると考え、正式リリースの1年後である2025年10月を基準とした。

ただし、余裕のあるスケジュールで対応できれば猶予期間が 1 年である必要はないため、(2) を加えた。

シナリオ案として以下を作成しました。

テストシナリオ

シナリオに含めること

同時ログイン

セッション管理に使用している DynamoDB がボトルネックになるかどうか確認するため

オンデマンドで負荷に耐えられない場合はプロビジョニングモードに変更するか、DynamoDB をやめる判断が必要となるため

ホーム画面

大量データを登録した場合に十分なパフォーマンスを出せるか確認するため

請求書の新規作成

参照系よりも負荷が高くなる登録系の処理を 1 つは含めたいため

PDF ダウンロード

キャッシュしていることで十分なパフォーマンスを出せるか確認するため