結果的に我流なQA

今回はちょっと長文になってしまった。
でも、いつかは書き残しておきたいと思っている内容だったので、しばしお付き合い頂きたい。

ざっと僕の経歴紹介

今年でもう42歳になるのだが、QAデビュー（IT業界デビューも一緒）は26歳。

デビューから10年近く、組み込みのソフトウェア検証を経験。
30代前半でWeb系プロダクトのQAを担当。
Web系のプロダクトの速さと、リリース判定の基準のギャップにはめっちゃ苦しんだ記憶は強烈に残っている。

組み込み系はリリースして問題があればリコール問題になるので、リリース判定は自ずと厳しくなる。
しかし、web系はそこまでの判定レベルはマッチしない。
そのギャップに苦しんだが、半年かかって身体で覚えた。

気づけばJSTQBとかも持っていた。

我流QAのきっかけ

当時開発兼QAマネージャーだった人が、まぁ頭の回転速い人で、本質や、人を見抜くことに長けていた。
1on1では何もしていないのに、緊張からか僕の脇汗が止まらない。
適当なことを言った時なんか、もう走って会議室から逃げ出したくなるくらいビビった笑

今思えば、どこか少しでも自分をよく見せようとしていたのかもしれない。
まぁそれも見抜かれてるわけだが。

話がそれた。

とあるプロダクトのメンバーを任された時に、今の僕につながる最初の経験を積む。

人も時間も無い中、ユーザに届けられる品質を担保する必要がある。

そんな時、マネージャーからのアドバイスで、

「全機能をまともに検証するのは時間的に不可能だし、ユーザーのリアルなシナリオを考えて、それを軸にやってみたら？」

と言われた。

この時の僕らは正直、言葉としては理解していたと思うが、それによってたどり着く世界の想像は出来ていなかった。

しかし、新しい取り組みだし、面白そうだから素直にやってみることにした。

シナリオはとにかくリアルであることが大事！
シナリオライターになれ！

まるで台本でも書いているかのように、細かく、詳細に、登場人物の背景や目的などを設定していった。

シナリオが完成！
何本のシナリオを当時用意したか、細かくは覚えていないが、少なくとも以下の3つの観点で少なくとも合計で4，5本は作ったと思う。

• 正常系

• 準正常系

• 異常系

また、別の悩みとしては、シナリオでは見れていない箇所をどうするのか？だ。
まったく動作を確認しないというのはどうかと思う。
そこで、シナリオの中で確認し、品質の担保ができることを洗い出し、そこから漏れた内容に関しては以下の2パターンで検討し、バランス良い方を選択した。

• 漏れた内容に特化した、リアルなシナリオを更に作成する

• 漏れた内容だけ、機能の確認として、テスト項目書に落とし込んで、シナリオとは別で実施する

担保すべき内容に対して、網羅したと言えるまで、これを繰り返した。

こんな感じで品質の担保を行い、いざリリース。。。

結果は。。。

問題なし！！！
正直、マジか！！？？っという感想が強かった。

テストを実施している時間より、シナリオ作成と、作成したシナリオで担保できることの分析のほうが大変だった。

無事終わったとはいえ、懸念というか、モヤモヤとして僕の中に残っていた。

• シナリオの精度をもっと上げることはできなかったのか？

• シナリオの精度を上げるのに必要なことは何なのか？

だ。

すごくスマートに品質に対してアプローチできた感触はあったからこそ、ちゃんと構造と現状を理解したかったのだと思う。

その後

会社も変わり、QAのやり方も従来のいわゆるテスト項目書をひたすら実施する方式に戻った。
でも、僕の中で、シナリオベースでの品質担保の経験が忘れられなくて、自分なりに色々と思考を繰り返していた。

シナリオベースでの品質担保を推し進めようとすると、反発や、反対意見も上がり、なかなか次のチャレンジができずにいた。

責任問題になることを恐れているのか、シナリオベースで品質の担保できるなんて信じられないのか分からないが、僕は結局、テスト項目書に沿ってテストを実施する方式で仕事をする他、道は作れなかった。

転機

とあるベンチャーからお誘いが来た。
しかも、プロダクトの品質保証は任せた！！！っと。。。

これはチャンス！！！！！

僕が長年、自分の中で温めてきた仮説をとうとう実践できる！！！

シナリオテストとテスト項目書によるハイブリット型の確立。

ありがたいことに、本当に好き勝手やれた。

大きな障害を出しては意味がない。

自分が信じる方法で、結果も必ず出す。

このプレッシャーも心地よかった。

そして今

シナリオはとにかくリアルであることが大事！
シナリオライターになれ！

この言葉を実際の行動に落とし込んだ結果、僕は部署や立場すら超えたコミュニケーションと情報収集、そしてリアルな実体験を集めるようになった。

• ユーザーは実際、どのように使っているのか？

• 経営サイドから見たら、どういったサービスなのか？

• 企画がどのように新たな機能を考えるのか？

• デザイナーはどんな情報と目線からデザインをするのか？

• エンジニアはどんな目線で要件を捉え、どういったモチベーションで実装するのか？

• そして、QAはどこまで見えていて、サービスについてどこまで理解できているのか？

サービス、プロダクトに関わる関係者の立場や景色を、一緒に見ることで、シナリオのリアルさも磨かれた。
何より、それぞれの立場で重要視する内容も異なるので、クリティカルな問題と言っても、誰にとって何がクリティカルなのかがより細分化できた。

• 立場や関わり方によって異なる品質の理解

• どれだけテストの実施をしなくていいかを同時に考えるスタンス

• 事前にわかることと、リリースしてみないとわからないことの切り分けと認識合わせ

これらをTry＆Errorを繰り返し、僕の中のバランス感覚を磨いていった。

その結果、いわゆる QCD のバランスの取り方が、我流っぽさはあるものの、かなり現状に適したバランスを選択できるまでに磨かれた。

サービスも金融以外（〇〇Payみたいなやつ以外）は実務として経験できたし、僕なりの品質保証のスタイルが確立できた気がする。

我流であっても、
何をどこまで担保し、なぜその担保で大丈夫なのか？
が自信を持って説明できれば良い。
何より結果的に障害が起きなければ良い。
もっというと、リリースをきっかけに関係者みんなが何かしらハッピーになればいい。

なんの後ろ盾も無いことを行うのは勇気と覚悟はいる。
でも、世の中に出てきて、多くの人が良いと言い始めた手法は、その時点でもはや過去のモノ。
ましてや、今、目の前にあるサービスとプロダクト、チームに適した品質保証の方法は当事者である僕にしか作れない。

本気でQAするということは、目の前のサービス、プロダクト、そして、そこに関わる立場の異なる関係者たちと本気で向き合うことなんじゃないかと思っている。

もちろん、我流と思っていたものが、すでに世の中に確立された手法の可能性だってある。
でも、それならそれでよい。
自力で世の中に確立された手法にたどり着けたなら、それはそれですごいじゃんw

さいごに

ここまで僕の好き勝手QAを信じてくれた会社のみんなに心から感謝している。
みんながいなければ、僕はここにたどり着けなかった。
僕はこんなに自由にチャレンジできなかった。

そこからわかるように、QAはみんなで作り上げていくもの。
みんながいないと作れないもの。

その学びと経験が何より大きい。