技術本部 Quality Assuranceグループの横田です。前回記事を書かせてもらってから、3回くらい組織名の変更があった気がしますが、きっと気のせいです。
先日（と言ってもずいぶん時間が経ってしまいましたが）、株式会社SHIFT様主催のウェビナーに登壇させていただく機会がありました。
info.shiftinc.jp
今回はそこでお話ししたことをちょっと書ければと思います。
お話ししたこと
「事業を成長させるQA体制のつくり方」と題して発表させていただきました。
具体的にどんなことを話したかは上記のスライドを見てもらうとして、こちらの記事では大まかに内容をかいつまみつつ、簡単に補足ができればと思います。
QA体制3つのパターン
SansanのQAを始めて、関わってきたプロダクトが、それぞれがどういうニーズでQAの支援を依頼してきたかに触れました。
改めて振り返ってみると、現場や状況に応じて必要のされ方が三者三様であることに気づきます。
そして、それらはいずれもQCDのいずれかにマッピングすることができます。
何か仕組んだわけではないのですが、同じ事業の中の話のはずなのにここまで違うのは実に興味深いです。
ちなみに、当時の発表ではあまり細かいことは説明しませんでしたが、SansanのQA活動は、手動でのテストを中心とした活動が多いです。
歴代多くの開発者が関わってきた10年もののプロダクトで、QAがない状態からスタートしました。
開発者がプロジェクトの最後にテストをする時代が長く続き、QAがいる環境で仕事をしたことがないエンジニアが多数の中、手探りであるところは大いにあります。
少しずつ少しずつ、必要とされるところに入って、メリットを感じてもらい、ようやく日常のロールとして定着してきたので、ここから発展させていけるだろうか、という段階だと思います。
ウェビナーのテーマが「攻めのQA」だったので、技術的に先進的な取り組みをしているとか、そういうものを期待されていたら申し訳なかったなというところです。
何を攻めてるの？
じゃあ何を攻めてるのか、となりますよね。そこでお話ししたのがこちらです。
個人的には、QAが攻めるというよりは、プロダクトや事業が攻めに転じれること、攻めのカードを増やせることが一番重要なのではと思います。
そして、その攻めのモードに入れるためのアシストができるのがQAなのだろうと思います。
少しでもインシデントを減らして新しいことに取り組む時間を作るには何をしたらいいのか。
開発できる時間を増やすために何をしたらいいのか。
期日に間に合わせつつもできる限り品質のいい状態でリリースできるようにするには何をしたらいいのか。
目的さえ見失わなければ、開発の早い段階から協力できる方法はないかとか、必要十分なテストを効率よく確実にやりきるにはどうしたらいいかとか、自然とそういう方向に考えが向くものだと思うし、気がついたら教科書的に語られるようなスタイルに徐々に近づいていくのではという気がしています。
まずは守破離の守をきちんとできて初めて、次の段階に行けるのでは、と思う次第です。
終わりに
地味に【人生ではじめての登壇】という実績を解除したのですが、オンラインでの登壇は（おそらく）オフラインでの登壇とはまた違う緊張感がありました。
リスナーの反応は読みにくかったですが、後からそこそこに良い感触をいただいていたと教えてもらいました。温かく受け入れていただいたのには感謝しかありません。
事前に準備したスクリプトがしっかり使えて途中で頭が真っ白になるような事態はありませんでしたし、正直、終わった後はすごくほっとしました。
時間もストップウォッチを動かしながら見ておけば、タイムマネジメントにも失敗しにくいですね。
終盤になるまで動いてないことに気づかず、タイムマネジメントに失敗した自分が言うのもアレですけどもね。
お後がよろしいようで。ではでは。
