QA（品質保証）とは？MTのQAエンジニアに聞いてみた-Six Apart ブログ｜オウンドメディア運営者のための実践的情報とコミュニティ

シックス・アパートでQAを務める井上です。

QA は「Quality Assurance」の略で、品質保証という意味ですが、あまり聞き慣れない言葉かと思います。QAという仕事は世間から脚光を浴びることも少ないので、どんなことをしているのだろうと思う方もいらっしゃるのではないでしょうか。

QAの仕事のフロー、役割や期待されていること、セオリー、はたまたQAあるあるについて、まとめてみます。

QAの仕事とは

Movable Type や Lekumo など、シックス・アパートの製品やサービスの品質に問題がないかを確認して、ユーザーの皆さんに安心して利用していただける状態を保つのがミッションです。期待通りに動作するか、使いやすいか、どのブラウザでも同様に動作するか、セキュリティや性能に問題はないか、など様々な視点でチェックして品質を評価します。

日々のお仕事フローってこんなかんじ

製品に新機能を追加する場合、まず「機能の仕様に問題がないか」、「他の機能と整合性が取れているか」を確認することから始めます。その後、どのようなテストが必要か検討し、実際に機能のテストを行います。

テスト中に問題を見つけたらバグトラッキングシステム（社内ではGitHubやFogBugzを利用しています）を通してチームに報告します。登録された問題点がエンジニアによって修正されたら、それが妥当かどうかを検証し、問題点が解消されれば完了。修正が不十分である場合は、エンジニアに再修正を依頼してもう一度検証するというサイクルになります。

新機能のテストや修正確認の他にも、バグの深刻度を評価して修正の方針やその優先度をエンジニアたちと検討したり（Bug Triage）、ユーザーの皆さんからの問い合わせやバグ報告、機能要望を製品に反映させるための橋渡しもします。テストに利用する検証環境の構築やメンテナンスも仕事のひとつです。

Movable Typeは10年以上の歴史があり、MTタグもいまや600近い数になりました。過去のバージョンからバージョンアップしてもそのまま使い続けられるよう、下位互換性の確認には特に力を入れています。年々機能も増えているので、気が遠くなるような確認作業をすることもしばしばあります。

一方、Lekumoも数多くのユーザーが24時間利用し続けているサービスで、Movable Typeとは違った緊張感、品質を継続的に担保し続けることの難しさがあります。

QAのセオリー

まずソフトウェアテストのベースとなるセオリーをもとに、テストパターンを考えます。ただやみくもにテストを行うのではなく、継続的に同じ品質のテストを行えるよう、事前にテストの全体像を作っておいてから検証作業に取りかかるように気を付けています。

テストには、ここまで終えたら絶対大丈夫というのはありません。異常な値が入力されるケースや、例外的な現象が発生した時のケースも考えると、実際には無数のパターンがあります。テストは量も重要ですが、製品が達成すべき品質のゴールを設定して、その目標を達成するためにテストケースを絞ったり、優先順位をつけたりして、テストそのものの質を高める作業も大切です。

エンジニアとは共同作業をする関係で、時に意見がぶつかることもあれば、お互い良い意味で気を遣い合うこともあります。見方によっては、夫婦っぽい面もあるかもしれません（笑）。

シックス・アパートに入社した経緯

もともとMovable Typeを使ったウェブ制作の仕事をしていました。前職を辞めた後、今度はMovable Typeという製品そのものを作る立場に回ってみたらどうかと、シックス・アパートの求人募集を見てみたのが始まりです。

ただ、どの Job description を読んでも業務内容がハッキリわからなかったので、とりあえずエイッと応募して、結果的に採用に至ったのが入社した経緯です。なので、もともとQAを志望して入社したわけではありません。

面接で、当時の私が「MTでご飯三杯食べられる（くらい好きだ）」と言ったという噂になっているんですが、そんなこと言いましたっけ。もちろん当時から好きだったのですが（笑）。

チームでやる場合の作業分担とか役割の違いについて

以前は、製品毎にQAチームが分かれていましたが、現在はひとつのチームで運営しています。今でもメンバー毎に主に担当する製品を決めていますが、他の製品のテストに加勢する機会も多いです。誰がいつどのようなテストでも担当できるような体制にすることをチームの方針にしていて、個々のテスト行程についてもできるだけ属人化しないように気をつけています。

QAチームのスケジュール

テスト期間の見積もりやスケジューリングは事前に行いますが、製品企画や開発が遅れや仕様変更の影響を受けやすいので、なかなか計画通りに進まないのが実状です。特に比較的コードが不安定な状態で行う序盤のテストでは、思わぬトラブルでテスト自体を勧められないようなこともあります。どのプロダクトにも共通しますが、リリースに向かって徐々に忙しくなっていき、リリース直前にピークを迎えます。

QAあるある

どのチームもそういう面があるとは思いますが、褒められにくく、責められやすいという特徴はあるかなと思います。バグは無くて当然ですから（笑）。

QAの仕事は、コードの変更や、変更による影響度を少なくしてもらった方が楽になります。ただ、モチベーションはそれには比例しません。さほど本質的に問題を解決しない小さな変更をテストをするよりも、大きな改善につながるハイリスクな変更な方が実際燃えます。QAチームはM体質なんですかね。

QAに求められる性格やスキルとは

性格については特に無いと思いますが、強いて言えば、細かい気配りができることが大切かもしれません。細かな気遣いから見逃しそうな問題を発見したり、ユーザーの心理を想像することでユーザービリティを改善する方法を思いついたりすることがあるからです。一方、木を見て森を見ずでは重要な問題を見逃してしまうという面もあるので、難しいところです。

必須のスキルはありませんが、最終的には実際に製品を開発しているエンジニアと同様のスキルを身につけていく必要があると思います。製品のコードを書くわけではありませんが、変更されたコードには目を通すことで、テストパターンの漏れに気づいたり、問題が起きそうな場所にアタリをつけることができるからです。

チームのメンバーには、開発者が倒れたら代わりに開発できるくらいの気概を持っていて欲しいなと思います。実際、何か言語を覚えておくと、テストの自動化などテスト業務そのものの改善にも貢献できるので一石二鳥です。

それと、“製品愛”が必要なのは言わずもがなですね。

QAをネット以外のモノに置き換えると

中華料理屋のラーメン屋の人が、お客さんに出す前のスープを味見する役みたいなかんじでしょうか。あるいは、自動車ならテストドライバーですかね。

製品が出荷された後

リリース直後はドキドキします。テクニカルサポートに届く声を聞いたり、ブログや SNS での評判をチラ見することもあります。が、実はその時点で次のリリースの準備が始まっていたり、他プロダクトのプロジェクトも並行して進行しているので、ドキドキしている場合ではなかったりします（笑）。

QAから仕様提案することは日常的

バグレポートだけではなく、使ってみてのフィードバックや機能提案をすることもよくあります。技術的な調査だけではなく、ユーザー目線で行うテストも大切な検証のひとつだからです。「これを言うとあとで自分の作業が増えて大変なことになる」とわかっていても、つい一言言ってしまうことも多いです。

以上、Quality Assuranceについてご理解いただけたでしょうか？シックス・アパートでは、ユーザーの皆さんからいただいたフィードバック全てに目を通し、製品をもっと愛されるものにできないか真剣に検討しています。お気づきの点があれば、お気軽にご意見をお寄せください。

他にもいろんな職種の役割について知りたい方には、こちらの記事もオススメです

また、人材も募集しています。Movable Type でご飯を三杯食べられる必要はないですが、製品やユーザーに対して愛情を持って考えることができる方からの募集をお待ちしています（笑）。