シェア
はてブ
皆様こんにちは。QAエンジニアのブロッコリーこと風間裕也（@nihonbuson）と申します。私は本業で株式会社10XのQAエンジニアとして勤務する一方、副業としてB-Testingを開業し、さまざまな会社でQAに関する相談に乗ったり、登壇や執筆活動を行っています。
また社外活動として、WACATE（ソフトウェアテストの合宿型ワークショップ形式勉強会）の実行委員長や、ソフトウェアテスト技術振興協会（ASTER）の主催するJaSST Review（ソフトウェアレビューのシンポジウム）の実行委員長を務めています。
本記事では、私がどうしてQAエンジニアというキャリアを歩んでいるのか、そして品質保証（QA、Quality Assurance）という分野でどのように開発チームと協調しながら開発してきたのかをお話しします。
- 学術と企業のギャップに驚いてテストの浸透に動く
- 自動テストを考えるよりも前にすべきことがある
- 自分の主張や特長に共感してくれる企業に転職する
- 「開発との協力が何よりも大切」と発信し続ける
- 「高速道路の出口案内」のようなQAでありたい
学術と企業のギャップに驚いてテストの浸透に動く
私は高校卒業後、電気通信大学のシステム工学科（当時）に入学しました。数学が得意だったこととパソコンが好きだったという理由だけで、きちんと理解できていないままシステムエンジニアリングを学び始めることになったのですが、学んだ内容が社会人になってからも生きているという点で、この学科を選んで良かったと思っています。
さらに良かったこととして、当時の電気通信大学のシステム工学科には、品質を専門とする教授や講師が数多く在籍していました。そのため、品質やテストのことに学生時代から触れることができました。
そのまま電気通信大学大学院修士課程を修了し、パッケージベンダーに新卒入社しました。新卒研修後、とある部署の社内ツール開発を担当することになりました。そこではCI/CDの基盤作りを担当しつつ、部署内で開発していたプロダクトの品質についても触れることになりました。
そこで気付いたのは、学生時代に学んでいた品質やテストの考え方が、企業では全く浸透していないという現実でした。これは、その会社が極端にひどかったということではなく、WACATEなどのコミュニティを通じて聞いた事情から、他社でも同様に浸透していないと気付くことができました。
そこで私は、社内でテストの必要性を訴えることにしました。まず勉強会を開き、どのようにテストを考えればよいのかを啓蒙していきました。初回はチーム内で実施して参加者も20名程度でしたが、噂を聞きつけた技術部署の計らいで会社全体の勉強会として行うことになり、100名弱が参加する勉強会を計3回実施しました。
そのまま新卒研修のコンテンツとして追加され、毎年100名を超える新卒生に向けて数年間伝えました。そしてこの活動を知ったマネージャーの薦めで、QAの部署へ異動になりました。
テスト技術に磨きをかけるために有益だったワークショップの存在
QAの部署に異動してからは、よりテスト技術に磨きをかけるようになりました。その際、JSTQB（国際資格ISTQBと連携したテスト技術者認定団体）のFoundation Level認定資格を取得したことや、JaSST（ソフトウェアテストのシンポジウム）、SQiPシンポジウム（ソフトウェア品質のシンポジウム）、そしてWACATEに参加したことが、自分自身の技術にとってプラスの経験になりました。
特に、半年に一度開催されるWACATEへの参加は非常に大きかったです。WACATEは2日間使ってワークショップを行うため、ただ発表をインプットするだけでなく、自分で実際に試すことができます。さらにグループワークで行うため、全く同じ題材に対してメンバー間での違いを感じることができます。
例えば2018年夏の開催では、とあるWebサービスに対して状態遷移図を書いたのですが、メンバーそれぞれで図が微妙に異なっていました。この経験から次のような学びを得ることができました。
- 実際に書いてみることで、状態遷移テストに対して理解できていない部分があると気付けた
- そもそも絶対的な解は存在せず、メンバー間で認識の違いを言語化した上で議論することが大事
こういった経験の多くは、実際の現場でも生かすことができます。そんなWACATEというイベントにはこれからもずっと携わっていきたいと思い、初参加の後はほぼ毎回参加し、実行委員にも立候補し、現在は実行委員長を務めています。
自動テストを考えるよりも前にすべきことがある
テスト技術を磨きつつQAエンジニアとして働いていたある日、新設された自動テストのチームへ異動することになりました。
ここでは、E2E（End to End、コードレベルではなく実際のアプリケーション上での振る舞いレベル）の自動テストの構築に携わりました。 CI/CDパイプラインにE2Eのスモークテスト（正常系でも本当によく使われる部分のみのテスト）を自動テストで組み込み、自動テストが通ったら評価環境に自動デプロイして、さらにQAチームがテストする形を取るようにしました。
しかし、問題が発生します。このスモークテストの自動テストが成功して評価環境にデプロイされる頻度が非常に少なかったのです。この経験から「E2Eの自動テストを頑張る以前に、もっと行うべき手立てがあるのではないか？」と考えるようになりました。
そもそもE2Eの自動テストは、実装が一通り完了したあと、開発工程の最後に行います。一般的に後ろの工程になればなるほど、欠陥を修復するのに多大な手戻りコストが発生します（下記のグラフ参照）。
我々が注力すべきなのは、もっと手前の段階で品質を作り込む活動なのではないか。そこで私は設計のレビューに入るようになります。同時期にJaSST Reviewの実行委員長を務めることになり、レビューに対して磨きをかけることもできました。
※ NIST（アメリカ国立標準技術研究所）の論文「The Economic Impacts of Inadequate Infrastructure for Software Testing [PDF]」の表5-1をもとに作成。
実装前にテストのことを考えることの大切さ
設計レビューに入ってからは、大学で学んだことやQAエンジニアとしての経験を最大限に生かすことができました。開発の方針を聞いた上で「もしもこの機能のテストをするとしたら……」という想像を働かせて、不具合になりそうな部分を伝えるようになりました。
学生の頃を思い出してください。先生が授業中に「『応仁の乱』は試験に出すぞー」と言ったなら、あなたはきっと「応仁の乱は覚えておかなくちゃ」とメモしておくでしょう。その結果、試験では応仁の乱の問題を正解できたのではないかと思います。これと同じように、ソフトウェアテストにおいても事前に予告しておけることは大事です。
予告することの効果は非常に大きいと感じています。予告は設計の段階で行うため、まだプログラムは1行も書かれていません。実装前に伝えることで、「あ、この部分、テストの際に確認するって言ってたな……」と考えながら開発することにつながり、その部分で不具合の発生を防ぐ可能性が高まります。
もし、プログラムを書き終わった後にテストして不具合が見つかったとしたなら、以下のようなコストがかかるでしょう。
- 不具合報告のチケットを起票するコスト
- そもそもどんな開発をしていたのかを思い出すコスト
- 修正するコスト
- 再度テストするコスト
- 関連する他機能をテストするコスト
- チケットをクローズするコスト
テストについて実装前に伝えることで、こういったコストを減らすことが期待できます。
自分の主張や特長に共感してくれる企業に転職する
設計レビューで一定の成果を得て、担当していたプロダクトがひと段落したタイミングで、転職することにしました。
その頃から社内だけでなく、社外にもテストの大切さを発信していたため、ありがたいことに「テストのことをいろいろと伝えている人」と認識してもらえていました。そのため転職活動の際にも「自分の伝えていることに対して、どの程度共感してもらえているか」を念頭に、次の職場を選定できました。
転職活動は「企業が求職者を選定するもの」と捉えられがちですが、そうではなく「企業と転職者が、お互いにマッチングするかを確認するもの」だと思っています。たとえ企業が「採用したい」と希望したとしても、求職者が「合わない」と感じたなら断ることが大事です。そのために、普段から自分が行っていることを言語化しておく必要があります。
QAエンジニアはどのように成果を言語化すべきか
個人的に、QAエンジニアには自分がやってきたことの言語化が苦手な人が多いような気がします。開発ならば「◯◯というプロダクトで△△という機能を開発した」とアピールできますが、QAエンジニアの場合は「テスト設計を3年間やっていた」というアピールになってしまうことが多いようです。
同じように採用側でも、QAエンジニアの良さを面接時に言語化させて引き出すことができる人は少ないように感じます。これは採用担当者に能力がないと言いたいのではなく、それまでQAの経験がない人が採用担当になることが多く、そもそも何を引き出せばよいのか分からないのだと思っています。
そのため求職者は、テスト設計を何年間やったと伝えることとあわせて「どのように工夫できたのか？」を伝えることも大事です。その工夫はテスト技術に関することでもよいですし、普段の業務のちょっとした効率化でもよいでしょう。工夫を伝えることが、マッチングの材料になります。
例えば「テスト設計時に、◯◯というテスト技術を使って……」とアピールしたとしましょう。ある企業は「そういうテスト技術を当社でもどんどん使ってほしい！」と思うかもしれませんし、別の企業は「そのテスト技術よりも、当社独自のテスト技術を使いこなしてほしい」と思うかもしれません。
このようにきちんとアピールすることで、きっと前者の企業からは採用をもらえ、後者の企業からはお見送りされるでしょう。けれど、それでいいんです。仮に後者の企業に入ってしまうと、企業も求職者本人も入社後に苦痛になります。それを入社前に判断できることが大事です。
私の場合、当時の執行役員にも考えを共感してもらえたので、すんなりと初めての転職を終えることができました。
海外カンファレンスをキッカケに自分の行動に確信を持つ
2社目に転職して1年ほどたった頃、Agile Testing Daysという海外カンファレンスに参加する機会が訪れました。私にとって初の海外カンファレンスでしたが、会社の経済的支援があってたいへん助かりました。
このカンファレンスでは『実践アジャイルテスト』の著者であるJanet GregoryとLisa Crispinに出会い、アジャイル開発におけるテストの実践について2人が執筆した『Agile Testing Condensed』を翻訳することになりました。
▶ 日本語翻訳版『Agile Testing Condensed Japanese Edition』
Thank you for exchange the book!
— broccoli (@nihonbuson) November 5, 2019
And, I'm glad you calling me Broccoli!@lisacrispin and @janetgregoryca #AgileTD pic.twitter.com/SooEljqnL7
Agile Testing Daysや書籍『Agile Testing Condensed』では、私自身のサプライズになるようなことはあまりありませんでしたが、普段から行っていたことや感じていたことが見事に言語化されていました。これにより、自分の行動が世界的にも間違っていないのだなと確信を得ることができました。
「開発との協力が何よりも大切」と発信し続ける
実装前からQAがレビューにも参加して不具合を防ぐ活動をするには、QAだけで頑張るのではなく、開発との協力が大切です。
それを訴えるためにも、社内外で開発者に向けた発信を意図的に増やしています。JaSSTをはじめとしたテスト系のカンファレンスに登壇するだけでなく、Developers Summitをはじめとした開発系のカンファレンスや、RSGT（Regional Scrum Gathering Tokyo）をはじめとしたアジャイル系のカンファレンスにも数多く登壇しています。
最初の頃は「開発系のカンファレンスでテストのことを話しても受け入れてもらえるのかな……？」と不安になっていましたが、むしろ大歓迎だったように見えます。「テスト系の話も聞きたかったんだけど、今までは話してくれる人がなかなか見つからなかった」と言ってくれた運営の方もいました。
そのコメントを聞いてからは、自分がQAエンジニアであることを全面に出しつつ、どのようにすれば開発者自身がテストを行えるのかをテーマに登壇することが多いです。
登壇やコミュニティ参加がその後のキャリアにつながる
2社目でも担当していたプロダクトがひと段落したタイミングで、次の転職を考えるようになりました。上述した通り、転職活動において自分が行っていることを言語化することは大事ですが、同時にコミュニティによる縁も大切だと思っています。
WACATEというコミュニティによる縁は特に大切に感じています。平日の業務時間後に開催される2時間弱の勉強会では、隣に座った人と親しくなれる確率は低いですし、次に会った時にはおそらくお互いに覚えていないでしょう。一方、半年に一度開催されるWACATEでは、1泊2日の宿泊形式でグループワークを行います。そうすると、絶対に知り合いが増えます。
そういった知り合いとは別のイベントの懇親会でも会話する機会がありますし、さらに別の知り合いを紹介してもらって挨拶できる可能性も増えます。こうした知り合いは、いずれ転職する際に、求職者である私の代弁者として社内の同僚や採用担当者に紹介してくれることもあるでしょう。もちろん、知り合いであることが効果を発揮するのは選考に入るまでだけであり、選考開始以降は知り合いを採用担当に入れないで純粋に判断すべきです。
私の場合も、現職に既にジョインしていた知り合いのQAエンジニアとカジュアル面談をした後、約1ヶ月のトライアル（一定の社内情報などにアクセス可能な状態でポジション・候補者の方に応じた各テーマに対するイシューに取り組む）による選考を経て、転職しました。
QAエンジニアも登壇のチャンスを逃さず発信しよう
考えてみると、QAエンジニアは総じて内向き志向であり、あまり開発向けに発表しないように見えます。それは以下のような要素があるためです。
- プログラミングに挫折したり、プログラミング未経験である状態でQAエンジニアになったりしているため、開発に対して劣等感がある
- 社会人初期の私のように、自分たちがテストで頑張ることが大事だと考えており、開発のマインドを変えるところまで至っていない
- 自社の不具合はネガティブな情報であり、そういった内容を発表することは社内規定上NGである
しかし先述したように、テスト系の発表を待ち望んでいる開発系のカンファレンスはかなりあります。私はQAこそ、開発系のカンファレンスでもっと発信すべきだと感じています。
「高速道路の出口案内」のようなQAでありたい
設計レビューに入るようになる前の私自身は、「QAはテストによって不具合を見つけることが仕事だ」と思っていました。ですが、現在は違った感覚でいます。
現在、私は「高速道路の出口標識のようなQAでありたい」と思っています。
高速道路では、出口のかなり手前から「○○出口まであと2km」と書かれた標識が案内してくれます。これによって、運転手はスムーズに出口に向かうことができます。出口の直前になって急に車線変更するためスピードを落とすこともなくなり、車の事故も少なくなるでしょう。
車のスピードを開発速度とし、出口がリリースだとすると、事前に「○○のテストをしますよ」と伝えておくことで開発速度を落とすことなく、テストNGとなることも少ない状態でリリースに向かうことができます。このような状態を目指していきたいと考えています。
これからもテストの大切さを伝えていきたい
現職でも、普段のQA業務を行いながら、社内外でテストや品質保証の大切さを伝えています。しかし現状では、品質保証について学んでいる人は国内でも世界でも非常に少ないように感じます。
理由として、まず学生時代にテストや品質を学んだ経験のある人の割合が非常に少ないです。プログラミングや開発手法について学んでいる学生は多くても、ソフトウェアテストまで学ぶ学生はあまりいないでしょう。そして現在だけではなく、昔から少ないため、社会人になってもソフトウェアテストについて教えてくれる先輩社員は非常に稀な存在だと思います。
実際に、転職活動中にカジュアル面談等を通じて複数の企業から相談を受けた経験がありますが、相談者であるCTOやVPoEの方々から「品質やテストをなんとかしたい」「けど、やり方が分からない」という話をよく聞きます。
これまでの経験を元に私がご相談に乗ることも可能ですが、私一人だけでは限界があります。ソフトウェアテストや品質保証という分野は、開発と比べるとニッチではあります。しかし、需要に対して供給が少ない分野とも言えます。そこで、本記事で語ったようなテストのマインドを持った人を増やしていきたいという想いがあります。
本記事を通じて、少しでもこの分野に興味を持ち、WACATEやJaSSTに参加してもらい、共に進む仲間ができると嬉しいです。
編集・制作：はてな編集部
風間 裕也（かざま・ゆうや）
電気通信大学大学院修士課程修了。ワークスアプリケーションズに入社後、学生時代から興味のあった品質やテストに関わるためQAチームへ異動。ビズリーチを経て2023年5月から10Xの品質所属部に所属し、現職。B-Testingを開設し、社内外問わず「どのようにテストを考えればよいか」を日々エンジニアに伝えている。
Blog: ブロッコリーのブログ
