今回は、エッセイになります。私がQA初心者だったころから思っていたことを主観で書きます。

何のためにリリースするんだろう

今日、ソフトウェアは「無形固定資産」として計上されるぐらい、会計上でも認められたものになっていますが、何のために製品を作っているのか、と問おうとすると、「売り上げのため」「誰かの価値のため」という内容も、少なからず含まれてくるでしょう。

こんな画面があったとします

例えば、こんなふるまいが自社製品にあったとします。

ECサイトにて、[ Home ] というボタンを押したとして、リンク先がじつは全然関係ない、マイページ画面だったとします。理由は、そのアカウントの権限では、Homeは見せられないから、という仕様だったとします。ですが、[ Home ] ボタンを押したユーザーの期待値は、当然ホーム画面に行くことであり、マイページが表示されるのは、期待値とは言えないでしょう。Homeを、適切な権限のないアカウントに見せない、という目的は達成できますが、ユーザーの体験としては、どう思われるでしょう。ちょっと雑に見えませんか？

これを、「仕様です（by design)」で、手間をかけずに終わらせますか？
それとも、周りを調整して直しますか？
チームメンバーは、リリースに追われてとても忙しそうです。
また、直したからと言って給料が上がる保証はありません。
リソースは常に足りません。

私が自社製品のQAにこだわる理由が、ここにあります。
自社製品のQAは、利害関係が自分にもあるので、例えば、具体的に手間をかけずに顧客体験を上げていく提案ができます。メッセージをちょっと変えるだけでも全然印象が変わることも多いです。そういった、手間をかけずに良くしていく方法を日々考えて実現しやすいのです。

お客様の「不」に、目をつぶらない

"提案までやってほしい"、という、依頼側の希望を聞くこともそれなりにありますが、契約した内容を終わらせれば問題ない、というシチュエーションになりがちなことも多いです（もちろん、すべてがそうというわけではありませんが）。また、意欲的に不備を洗い出しても、忙しさに追われて手付かずのままリリースされてしまい、モチベーションを落としていく例もあります。

第三者検証の立場では、こういったシーンに遭うことは珍しくないと、経験上感じていました。また、効率重視の観点から、アプリケーションが最初の意図通りに動けば正しい、とする経験豊富なテストマネージャーもいらっしゃいました。利益を考える場合、これも一つの正解です。一方で、少数ですが、コミュニケーションスキルが高く、こういう場合でもお客様に上手に働きかけて修正を促す、意欲的な第三者検証のエンジニアもいます。これは、本人の資質のみならず、所属元の会社のスタンスも大きいように感じます。

ソフトウェアの「テスト」と、品質保証の「評価」

QAエンジニアは、日々品質と向き合っているわけですが、仕様通りに動けばよい、というスタンスでいると、上記のように、確実に顧客満足から離れるであろう内容であっても、「仕様だから」と、それ以上考えるのをやめてしまいがちです。早くデリバリーすることで、早く失敗し、リカバリーし、最終的な顧客満足に近づく、というのも、今となっては王道の一つです。

ただ、「仕様通りに動いているから」というだけで、テストは終了、とするのは、ものづくりを考えた場合、もったいないなと思います。こういった、お客様の「不」を見つけるためのテスト技法も存在します。そうした「不」に、ストレートにフィードバックを出せるのも、QAチームの価値だと考えます。

顧客価値を生み出すためには、仕事を依頼する側、請け負って品質保証をする側、双方の働きが必要になるでしょう。そしてこういったクライテリアは、少なからず経営方針に影響を受けます。QAが経営の思う以上の活動が出いないといわれるのは、こういった事情からと考えます。新しくQAチームを発足する場合、品質をどう変えたいのか、どういう動きで対応できそうなのかは、周りの協力なくして推進するのは難しいです。チームを作る前に、社内の文化が変化に対応して進めていけるのかは考えたいポイントです。

「アプリケーションとして正しい物」と、「製品としてあるべきもの」を、考えてポリシーを作っていく。ここが、その製品の品質（印象）を決めるうえで、要になるのではないでしょうか。