あなたの3分、わたしの3日

# はじめに

これは社内LTのプレゼンテーション資料です。
ちなみに、当日はビール5缶飲んだ後だったのでうまく発表できなかったです。

---

先日、QAエンジニアのKさんにソフトウェアテスト講義を受けたので、"テストって大事だなぁ"と思って作ったスライドです。

---

今回は、私の過去の職場などの体験を参考に、フィクションでお送りいたします。

---

あなたは、とあるプロダクト開発にジョインしました。

キックオフミーティングでは、次のようなマスタースケジュールが提示されました。

---

# マスタースケジュール

```mermaid
gantt
    axisFormat %m/%d
    todayMarker off
    section 要件定義
        要件定義 :a1, 2023-10-01, 5d

    section システム設計
        システム設計 :b1, after a1, 5d

    section 詳細設計
        詳細設計 :c1, after b1, 5d

    section プログラム開発
        プログラム開発 :d1, after c1, 10d

    section 単体テスト
        単体テスト :e1, after d1, 5d

    section 結合テスト
        結合テスト :f1, after e1, 5d

    section システムテスト
        システムテスト :g1, after f1, 5d

    section 受け入れテスト
        受け入れテスト :h1, after g1, 5d

    リリース : milestone, m1
```

とてもキレイなウォーターフォールです。
条件として、"リリース日は繁忙期前だからマストで！”とのこと。

---

さて、要件定義が始まりました。

---

# 現場で起きてしまったこと

要件定義が伸びに伸びてしまいました。

```mermaid
gantt
    axisFormat %m/%d
    todayMarker off
    section 要件定義
        要件定義 :a1, 2023-10-01, 10d

    section ...
        ... :b1, after a1, 5d

```

このままでは、リリース日に間に合いません。

---

そこで、あなたは名案を思いつきました。

---

# 「安心してください。入ってますよ。」

```mermaid
gantt
    axisFormat %m/%d
    todayMarker off
    section 要件定義
        要件定義 :a1, 2023-10-01, 15d

    section システム設計
        システム設計 :b1, after a1, 5d

    section 詳細設計
        詳細設計 :c1, after b1, 5d

    section プログラム開発
        プログラム開発 :d1, after c1, 15d

    section 単体テスト
        単体テスト :crit, e1, 2023-11-03, 5d

    section 結合テスト
        結合テスト :crit, f1, 2023-11-05, 5d

    section システムテスト
        システムテスト :crit, g1, 2023-11-07, 5d

    section 受け入れテスト
        受け入れテスト :crit, h1, 2023-11-10, 5d

    リリース : milestone, m1

```

あなたは、完璧なスケジューリング能力を発揮してしまいました。
テストを重ねることで、約束のリリース日に間に合わせることができたのです！

---

さて、その結果、何が起きるでしょうか...？

---

# リリースを合図に、アレが作動します

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134221/a02072dc-da1d-49f8-2b41-a3b3178d6dc8.png" width="350" />

（アレね。アレ。優勝のことじゃないよ）
（不具合の時限爆弾ね...）

---

その後、不具合が案の定、見つかりました。

いったい、あなたはどこで間違えたのか？
考えてみました...

---

# 不具合はいつ見つかると良いのか？

A: テストフェーズで見つかる不具合
B: リリース後に見つかる不具合

このAとBでは、何が違うのでしょうか？

---

# テストしない方がリリースは早まる？

```mermaid
gantt
    axisFormat %m/%d
    section テストフェーズ
        実装    :a1, 2023-11-01, 1d
        テスト  :a2, after a1, 3d
        不具合発覚  : milestone, crit, after a1, 4d
        修正  :a3, after a2, 2d
        リリース  : milestone, after a3
    section リリース後
        実装    :b1, 2023-11-01, 1d
        テスト  :b2, after b1, 2d
        修正  :b3, after b2, 1d
        リリース  : milestone, after b3
```

- テストフェーズで不具合が見つかったあ場合、テスト期間や修正期間が伸びて、リリース日も伸びてしまいました
- 一方、テストをおろそかにした場合、修正も発生しないのでリリースを早めることができました
- けれど...

---

# リリース後に見つかる不具合は影響範囲が大きくなる

```mermaid
gantt
    axisFormat %m/%d
    section テストフェーズ
        実装    :a1, 2023-11-01, 1d
        テスト  :a2, after a1, 3d
        不具合発覚  : milestone, crit, after a1, 4d
        修正  :a3, after a2, 2d
        リリース  : milestone, after a3
    section リリース後
        実装    :b1, 2023-11-01, 1d
        テスト  :b2, after b1, 2d
        修正  :b3, after b2, 1d
        リリース  : milestone, after b3
        潜伏期間:done, b4, after b3, 3d
        不具合発覚  : milestone, crit, after b４
        営業対応  :crit, b5, after b4, 2d
        調査&修正  :crit, b6, after b5, 2d
        リリース  : milestone, after b6
        後始末 :crit, b7, after b6, 2d
```

そう、リリース後に見つかった不具合では、お客様からの営業への問い合わせ、社内の連絡、プログラムの調査・修正、その後始末だったり、影響範囲がとても広くなってしまいます。

---

後始末が終わった後、いつも温厚な上司に呼び出されます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134221/477ae25c-6c4d-1b43-045c-2b67c6239bdb.png" width="250" />

---

上司「あなたが3分かけてテストをしていたら、私たちは3日を失わなかった!!」

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/134221/0fd9676f-15b1-f323-9587-32cee1076968.png" width="350" />

（タイトルの伏線回収www）
（人のせいにするのは良くないよね、仕組みを変えないと...）

---

とはいえ、失ったものが3日ですまないケースもありますよね？

---

# 3日ですまないケース

- ABテストの誤った計測が、誤った経営判断に繋がる
- 本番アクセス量に耐えきれずシステムダウン
- システムに脆弱性を埋め込み個人情報が流出する

（失ったものは何か？）

さて...

---

# どうしていたら良かったか

- リリース日が決まっていた場合、Q（品質）、C（コスト）、D（納期）、S（スコープ）で一番調整ができるのはスコープ
    - 『[アジャイルサムライ](https://shop.ohmsha.co.jp/shopdetail/000000001901/)』参照
- スコープを小さくして、小さくリリース、早いフィードバックを得る
- テストをおろそかにしない

---

# テストをおろそかにしない

（大事なことなので2回言いました）

---

とはいえ、人間はミスする生き物。  
不具合は必ず発生するので、ポストモーテムを使って振り返りと対策をやっていきましょう。

---

ご清聴ありがとうございました。