いきなりですが、
みなさんのところではバグチケットの流れって、このようになっていませんか？？
1. バグを発見したらチケットを起票して開発に報告
2. 開発担当者に修正してもらう
3. チケットが帰ってきたら修正確認をしてクローズ
4. 再びテストケースを消化していく作業に戻る。
これ自体はぜんぜん悪いとは思いません。
QAはあれこれ頭を悩ませてテストケースを作り、それを消化していくことで
リリース時に重大なバグが残っていない（と思われる）ということを保証する役割があるからです。
上記のバグのライフサイクルの中で、 「これと同じようなバグ、前にも起票しなかったっけ？？」 と思うことありませんか？
この記事では、そんな「既視感のあるバグ」に注目してみることで
バグ起票に終われるQA、バグ修正に追われて計画通りにに進まない新機能の開発、という
極悪非道の循環を断ち切れるかもしれない、、、
そんな可能性を製造業の品質保証の観点からご紹介したいと思います。
遅ればせながら自己紹介
- 社会人としての入り口はソフトウェアQAです。
- 機器の中の限られたメモリで動いているファームウェアや、PCと機器をつなぐことで機器の性能を引き出すミドルウェアの品質保証がスタート地点。
- プリンタ・デジタル腕時計・LINUX向けドライバ・OSの内蔵ドライバ
- その後、足掛け10年をいろんな製造業で品質を守ることに費やしてきました。
（リーマンショックのおかげで、地方での転職は困難を極めました） - 自販機のお釣りを返す部分や、商品を取り出すあのパカパカ部分を動かす金属製のシャフト
- 麻婆豆腐の素に入っている調味料・サバ缶の味噌
- AEDを動かしているプリント基板...etc,
- WEBシステムやアプリのQAはここ5年くらいです。
特技はフォークリフトの運転です。
（出入荷が忙しい時はよくトラックの積み下ろしを手伝っていました）
既視感のあるバグに注目しよう
閑話休題（自己紹介が長すぎた）
テスト項目を進めていくと、度々バグを発見することになるでしょう。（あんまり度々じゃ困るんだけど）
それをチケットに起票して、、という流れは前述の通りです。
今回注目したいのは「既視感のあるバグ」です。
1.「またデザインと違う表示になってる…」
2. 「ん？またこの画面でバグが発生してる！」
3. 「むむむ？なんでこの条件の時だけ他の機能と連動しないの！？」
チケットを起票していくとこんな既視感を覚えることがあるかと思います。（あんまり度々じゃ困るんだけど…2回目）
その既視感こそが品質を向上させる「最初の気づき」です。
ここでいう品質の向上とは、下流工程でバグを見つけられない状態を指します
「システムテストでテスターが頑張ったけどバグは出ませんでした…orz」という状態です。
根本的な共通原因を探る
さて、同じようなバグが散見されるということは、担当者の疲労度合いなどとは別の「根本的な要因」があるはずです。
根本的な要因を突き止めて、そこに手を打ってしまえば同じようなバグは2度と現れないはずです。
というのも製造業には昔から「ハインリッヒの法則」という労災防止のための考え方があります。
1件の重大事故の背後には、重大事故に至らなかった29件の軽微な事故が隠れている。
さらにその背後には事故寸前だった300件の危険認識（ヒヤリとしたりハッとしたりする危険な状態）が隠れている。
大抵の製造業の現場では「危ない！」と思ったこと(これをヒヤリハットと言う)を随時上長に報告する文化があります。
報告を受けた上長は、このヒヤリハットが発生しないように手を打ちます。
そうすることで、そこから発生しうる重大な労働災害を予測して先手を打つことができます。
300件のヒヤリハットに対応することが、従業員の生命と身体の安全を守ることにつながるのです。
＜ハインリッヒの法則＞
QAのお仕事に置き換えるときは、逆から読んだ方がわかりやすいかもしれませんね。
1件のバグに根本的な対処をすることで、29件ある軽微な類似バグの発生を防ぐことができる と言えそうです
ということでヒヤリハット的に先ほどのバグの根本原因を探ってみると、こんな感じでしょうか、、
1.「またデザイン仕様と違う表示になってる…」
2. 「ん？またこの画面でバグが発生してる！」
3. 「むむむ？なんでこの条件の時だけ他の機能と連動しないの！？」
| No, | 現象 | 原因 | 根本原因 |
|---|---|---|---|
| 1. | デザインとの相違 | 部分的にデザインが古かった | 構成管理がうまくいってない |
| 2. | 特定の箇所に頻発 | バックエンドとの繋ぎ込み | DB構造が可視化されていない |
| 3. | 特定の条件で頻発 | 特定の条件時の動作が決まってない | 仕様の検討もれ |
おそらくもう少し深掘りすると、プロジェクトの体勢とか進め方とか仕組みの構造的な問題が見つかるかもしれませんが、、本稿ではあえてこのあたりにしておきましょう。
仮説として抜き出した根本原因ですが、既視感のある他のバグに対しても同じことが言えるのであれば、説としては合っていそうですね！
解決策の提示（ハッピーエンド）
根本原因がわかれば、あとは解決策を提案するだけです。
1. ワイヤーフレームの構成管理を見直す（デザインと開発の同期をとる）
2. DBのCRUD図とかをザックリ書いて共有してみる
3. 漏れている仕様を洗い出す（私たちテストエンジニアお得意のテスト技法の出番です！）
プロジェクトとして、この三点の解決策が実行できれば、これ以上の類似バグが作り込まれることは防止できますね！
つまり、リリース後に「まだ類似バグが潜んでいるかも...」と怯える日々から解放されるわけです。
似たようなバグチケットを起票する日々からも解放されます。
開発担当の方も、バグ修正に使っていた時間を新機能開発に全振りできるようになります。
まとめ
気軽に読むには長すぎる記事になってしまったかもしれません。
申し訳ありません。（反省はしている。後悔はしていない）
普段から、「QAは下流工程でテストだけをする人」という認識を少しでも変えていけたら良いなぁと思っていて、その取っ掛かりとしてこの記事を書きました。
「QAは品質向上のための活動だったら、なんでもやる人」でありたいと思っています。
ちなみに製造業的な品質保証やカイゼンのやり方は、まだまだ沢山あるのですが、
話し始めると止まらなくなってしまいますので、今日のところはこの辺りで自主規制します...
ではまた！！