自己紹介

6月からNewsPicksのQAエンジニアとして入社した西薗（にしぞの）です。SIerでアプリケーション寄りのエンジニアを6年ほど経験した後、ベトナムのテストベンダーで2年弱、QAエンジニアをやっていました。得意、というか好きな領域はソフトウェアテストです。

多くのITエンジニアにとって、「やりたいこと」は設計や実装であり、ソフトウェアテストというのは「やらなくてはいけないこと」だと思います。一方で私はというと、設計書を読んでロジックの穴を見つけたり、つらつらと文章で書かれた仕様を図や表で書き直したり、そうやって整理したものを元にテストケースをちまちまと作ったり、という作業が嫌いではありませんでした。

このIT業界、センスや地頭の良さも必要だとは思いますが、一番必要なのは「自分の仕事の道具をどれだけ好きでいられるか」だと思います。私にプログラミングのセンスはありませんし、週末プログラマをやるほどには好きにもなれませんでしたが、ソフトウェアテストに関してだけは休日に勉強会へ出かけたり、書籍を買い漁って読む程度に好きでいられました。

一社目のSIerでプログラマやプロジェクトマネージャをやりつつ、何となく今後ソフトウェアテストを仕事にしていこうと思い始めた頃に、ご縁あってベトナムのテストベンダーへ転職。無事、職歴にもQAエンジニアと書けるようになったものの、コロナ禍で日本に帰国して無職となり、慣れない転職活動をなんとか開始し、なんだかんだあって今に至るというわけです。

一人目なんです

QAエンジニアとして入社した、と言いましたが、NewsPicksに所属するQAエンジニアは現在私一人です。これからQA組織を立ち上げ、QAやっていきましょう、というのが私のここでの仕事ということですね。

NewsPicksに必要なQAとは何か、NewsPicksにおけるQAエンジニアとは、というそもそもの問いに答えが出ていない中での立ち上げで、0から10まで自分の意見を言える環境にワクワクしています。一方で、もはやユーザにとっての情報収集インフラとなったNewsPicksという巨大なアプリケーションを前に途方に暮れている、というのも現状です。

とはいえ呆然としていても進まないので、いま考えていることをいくつか書いてみます。

NewsPicksのリスクって？

NewsPicksでのQAを考えるにあたって、まずNewsPicksというサービスにとっての避けるべき重大なリスクとはなんだろうか、ということを考えました。例えば、NewsPicksの特徴でもある「ニュースへのコメント」を通じた情報収集や学びができない、しづらい状況は望ましくありません。それはおそらく、設定画面の表示崩れよりは重大なことです。

ただ、ユーザーは一人ではありません。毎朝、特定のプロピッカーのコメントを探す人や、午前と午後で設定を変更する人、気になる通知が届いた時だけアプリを起動する人、など、そのユースケースは様々でしょう。このように正解が見つけづらい、むしろ常に正解を探し続けなければいけない世界なのだな、と、ウェブ業界で働くこと自体が初めての私は感じます。

何が必要なのだろう？

NewsPicksにとってのQAとは、開発を加速させるための装置なのだろう、と考えています。かっちりしたレビューやテストのプロセスでもって、どんな不具合も逃さない……という世界もありますが、それとは異なるはずです。例えば、エンジニアみんなが自動化されたリグレッションテストを信頼していて、品質指標が常に見える形で表現されて改善サイクルが回っており、それによって開発の効率化、高速化が実現されている世界。一方、それだけではなく、スピードよりも慎重さが必要なところではかっちりと締める、ということも必要でしょう。このような、力の抜きどころを見極めた開発の仕方を見つけていく必要がありそうです。

UzabaseグループのQAとの違い

ところでUzabaseグループのTech Blogを見ていると、グループに所属するQAエンジニアの活躍が垣間見えるかと思います。一方で、NewsPicksはこれからQA組織を立ち上げるというフェーズにいます。これにはプロダクト自体の誕生の経緯だったり、そのターゲットの違いだったり（他のプロダクトが主にtoBであるのに対し、NewsPicksはtoCですね）が関係しています。同じグループではありますが、一方のやり方がそのまま通用するものでもありません。当然、先輩たちの積み上げられてきたものは存分に活用させてもらうつもりでいますが、気持ちとしては「一人目QA」としてなんとか理想を見つけ、形にしていきたい、と思っています。

これから何を目指していくか

先程述べた通り、これまでNewsPicksにQAを担う組織はありませんでした。ただそれは、テストや品質といった領域に誰も興味を持たなかった、ということではありません。NewsPicksのエンジニアみんなが、開発であったり、インフラであったりという「本業」を抱えつつ、さまざまな改善を行ってきた歴史があります。テストケースのレビューが行われていて、テストデータの復元の仕組みもあり、プルリクエストのたびに自動テストだって動いています。

ただ、人が多くなり、プロダクトが成長するにつれ、個々人の努力だけで賄いきれなくなってきた、という状況だと思います。コード全体を把握している人は数えるほどになり、修正を加えれば何が壊れるかと戦々恐々とし、バグチケットは消化が追い付かない。その状況自体にも組織内でグラデーションがあり、あっちで上手くいっていることが、こっちでは最大の課題だったりする。状況の把握すら一人では困難で、思いが届き切らない。そろそろこの状況に対してフルコミットで向き合う人が必要だ、ということなのでしょう。

このように、NewsPicksのQAはエンジニアみんなで担ってきました。そして、これからもそれは変えません。QAとは誰か一人、どこか一つの部署が担えば良い仕事ではなく、そこにいるあらゆる人間が少しずつ担うことによって成り立つ仕事だと考えています。QAタスクを切り出して私がそれを担うという形ではなく、全てのエンジニアがより上手くQAすることを目指します。

ここで私が特に大事にしたいのは、「エンジニアが気持ちよく開発ができる」状況を作り、守ること。私も含め、エンジニアという生き物は腹落ちしていないルールやプロセスを守ることが嫌いです。品質向上を謳った面倒なルールが増え、エンジニアが開発に集中できなくなることだけは避けたい。ですので、エンジニアの皆さんにやらされ感が生まれないよう、丁寧な説明やゴールの共有を行い、みんなで同じ方向を向いて協力し合える環境を作っていきます。同じルールであっても、嫌々守るより、例えば「来月の自分のために自動テストを書く」であったり、「あのテスト分析の資料が仕様把握で役に立ったから、自分も似たような資料を残すようにしよう」というような姿勢で臨んだ方が気持ちが良いものですし、開発にも集中できるはず。そこまでいって初めて、全員でQAできた、と言えるのだろうと思います。

ということで、NewsPicksのみんなでQA、やっていきます。