こんにちは😆
はいチーズ！のデザイナー🍓いちご（@suigyooza_）です！

私ごとですが、最近ようやくX始めました・・😏

先日、弊社のスーパーつよつよQAエンジニア🥸 のSaito氏（@two_pack）が、品質についてあらゆる側面から考え直す社内勉強会を自チームに対して開催をしてくれました！

勉強会はギクリっのオンパレードでした・・！

今回は、この勉強会を経ての私の成長をお届けします🚀❤️‍🔥

あらためまして

品質について「世に出すものなので、品質は完璧ではなくてはいけない！」という意識は確かにありました。

しかし改めて品質について問われると、誰がどのタイミングでどのようにして品質を確実なものにするべきなのかの意識がカスッカスだったことに今回気付かされました・・💦

勉強会を通して『品質』と『テスト』について考え直したので、デザイナーとしてのお気持ち表明をここに宣言しようと思います✨🫡

👇勉強会前の私のテストへの知識レベル

前職：受託の制作会社のディレクター時代、表記ミス挙動不備デザインの相違のチェックを穴が出るほど見る「確認作業」をしていた
現在：１年前から自チームでの「受け入れ検証」を担当するようになった
V字モデル知らない
W字モデル知らない

品質界隈から見れば、こんな奴が受け入れ検証を担当していたのか！かも。穴があったら隠れたい🫥

隠し通せないほどの品質🔰なので、今回のブログは『品質』や『テスト』の本質の話は全く触れません⚠️⚠️

ただただ開発に携わるデザイナーのお気持ち表明に過ぎません＆勉強会の内容を完全網羅してませんので、どうぞご理解のほどよろしくお願いします🎍🐍

今の気持ち

これに尽きます。

受け入れ検証への心構え、何ひとつ正しくなかった！

勉強会の開始早々から薄々感じてたのですが、終わった時には確信に変わり「これまでをやり直したい・・」と天を仰でました👼（責任感強過ぎ）

直近の起きた問題、受け入れ検証の心構えの間違いで起きたんでは・・~~私の責任~~・・の気持ちになりましたが、Saito氏は何度も「みんなでQAする」という言葉を散りばめてたので、反省はもちろん大事だけど、１人で責任を背負うことは禁制なので線引きます🤣

1年前から自チームで受け入れ検証を担当するようになったんですが、入社してからそれまで実装後の検証に入ることはありませんでした。

自分がずっと実装してくれているエンジニアと同じチームにいない期間が多かった、という特殊な環境下だったこともあり、実装の進捗や内容の確認などで、ちらっと目にすることはあっても「確認お願いしますー！」のターンはなかったんです。

前職ではクライアントワークということもあり、穴が出るほど確認していた手前入社してからずっとソワソワしていたので、

やっと参加できる💪🔥の気持ちで受け入れ検証を行っています！

QAとは

弊社にはQAチームがいます。
QAという言葉を知ったのは、チーム名から。しかも入社して1年弱経過した頃にチームの存在を知りました。

ある時「Figmaの閲覧権限ください」という連絡を突然もらい「えっ誰ですか？何してる人ですか？」と逆質問したのを鮮明に思い出します。（失礼すぎるだろ）

補足：入社してすぐに1年がかりの大プロジェクトにjoinしたのですが、最中にXDからFigmaの移行を勝手に決断したため、なんかFigmaに変わったぽい！見れない！と連絡をもらったという流れです🤭

👇そのFigma移行はデザインシステムに絡んでいるので、下記ブログでスルッと記載してます！
プロダクト横断デザインシステム導入のあゆみ／（３）構築開始から本格始動までの苦悩 - SEN PRODUCT BLOG

勉強会に出るまで『QAチームは割と大きいプロジェクトに入ってくれて、めっちゃテストしてバグを発見してくれる最後の砦』という他責感満載の認識をしていました。

QAチームとは、品質上げるための最高の壁打ち相手である。

え・・QAってチーム名にするのダメじゃない？あたかも品質はQAチームに一任するみたいな気持ちにさせてくる・・🤫（※個人の見解です）

「QAできていますか？（＝品質に確信持ててますか？）」のSaito氏投げかけ

「世に出すものなので、品質は完璧ではなくてはいけない！」という意識はあった、って前段で書いてるんだから、QAしてるはずですよね。

しかし「QAしてるか」を自分に問うと「自信がない〜😫」の気持ちになりました。

QAとは、チームを構成する個々人が作業や成果物に対して、品質を満たすと確信し説明できるようにする活動である。

そうですよね。携わる者が皆、確固たる確信持たなければ、喜ばれる開発はできない！！！

みんなでQAしたい！！

見つめ直しの作業

1. 開発作業をブレークダウン

勉強会の開始早々、まず開発作業を簡単に分解しました。

一般的な大分類
チームの分類
作業をどうやっている？
だれが？

の横軸をもとに、各々付箋で書き出します（5分くらい）

そして次に、テストの文脈を追加・・

それぞれの開発作業の延長線上のテストは何かを付箋で出しました（5分くらい）

ユーザーインタビューや社内要望に対するテストは『受け入れ検証』
補足：ここに『ユーザビリティテスト』も入るんだろうなと今は思っていますが、その時は気づいていません。

自分で付箋を繋げて書きました。書かされていません。書くことによって初めてその認識をしてギクリっ

2. 効果的・効率的なテストの見直し

今まで何度かチームの会話で『効率的に』『効果的に』という単語は上がってましたし、みんなで考えてました。

でも、そのテストは”コード上のテスト”と頭で置き換えていたのか、受け入れ検証のことは関係ない気がしていたんですよね。

その気持ちに気づきました。

”みんなで考えてました”ではなく”考えているところを目撃していた”が正しいかもしれません😫

潜在意識より怖いものはないですね・・😫

重複してテストしない。

わかってたはずなのに、この言葉にまたしてもギクリっ
思い返すと、重複しかしてないかも・・。

テストの種類によって検出できる問題は異なる。

それぞれのテストで、見つかる問題は違うのであれば、重複しかしてない＝自分のしていた受け入れ検証は無意味なことしかしてなかったことになります。

ギクリっ

あまりにも辛い現実・・

でもあることにも気付いたんです。

「何がなんでも要件定義で問題を洗い出して決めなきゃいけない！」
「受け入れ検証でコード以外の全部見なきゃいけない！」

というプレッシャーに駆られていたことに。

そっか・・問題が浮き彫りになるたびに「気づかなかった・・！ごめんなさい😭！」って思っていたけれど、問題の内容によっては「その観点が！要件定義では見えてこなかった！さすが！」って思っていいんだ・・。

要件定義では『見えてこない問題』がある。
受け入れ検証では『見つけられない問題』がある。

のSaito氏の言葉に、それはそれはかなりの肩の荷がおりました👼✨

お気持ち表明

そんなギクリっを経て、自分なりの「今後の心構え」が見えてきました。

今まで勝手に抱いていた(※1)受け入れ検証への心構え
勉強会で生まれ変わった今の受け入れ検証への心構え

それでは開示させていただきます🫡

(※1) 受け入れ検証を担当するにあたり、この心構えで挑むようにというお達しは誰からも命じられていません。今の今まで自分の責務と勝手に勘違いしていただけ・・です。そこだけはお見知り置きを😉

今までの心構え🐣

検討した仕様が全て網羅されているか、動作や挙動は問題ないかを隈なく見る！それが受け入れ検証！

生まれ変わった心構え🐉

ユーザーの立場になって、ユーザーの環境下に身を置いて、ユーザーの作業フローに沿って、検討した仕様が問題なく反映されているかを隈なく見る！それが受け入れ検証！

生まれ変わった心構えを勉強会の終了間際に、このお気持ち表明をしたんです。

2日に勉強会が分かれてたから表明できた感は大いにあります🤣
1日目はギクリっのオンパレードで頭追いついてなかったので🤣

「これはやった甲斐ありましたね☺️」とSaito氏の顔はほころび、終了した後Slackでチームメイトが表明に対してコメントをくれました❤️‍🔥