この記事は弥生 Advent Calendar 2022の19日目のエントリーです。

こんにちは！QAエンジニアのふくだです。

最近買ったノイズキャンセリングイヤホンの使い勝手がかなりよく、イヤホン沼に片足を突っ込んでいる今日この頃です（ズブズブ）。ブラックフライデーで買った方もいるのではないでしょうか。ガジェット欲は何歳になっても収まる気配がないですね。技術の進歩を感じます。

さて、今日はQAの話です。
実は私、つい昨年まで他社でPDM（プロダクトマネージャー）として働いていたのですが、QAの道を突き進みたい！よりレベルアップしたい！という思いが再燃し、元々働いていた弥生に再入社しました。まだまだ未熟者ではありますが、「ふーん」というくらいで適当に読み流していただければと思います。なお、この記事における「QA」とは、「テスト計画、テスト設計、テスト実施、障害管理」を指しています。

前職で直接QAの仕事はしていませんが、QAを依頼する立場ということもあり、現職との違いで様々な苦労がありました。大きな違いは、「QAを自社でやるか他社でやるか？」。そこで今回は、「結局、自社QAと他社QAどっちがいいの？」 というテーマで書きたいと思います。

自社QAか他社QAか

結論から言うと、個人的には「現職の自チームの場合、自社QAの方が費用対効果が高い」と感じました。

前職のQAで起こっていたこと

QAのリソース不足により一部のQAをオフショアに

前職では、QA部門（自社QA）と開発チームが体制上明確に分かれていました。それなりの開発規模なので、QAは大忙し。6つくらいの開発チームからQAを依頼されますが、リソースが足りず開発チーム間でQAの争奪戦となってしまっている状況でした。

そこで、QA部門は一部の案件をオフショアで行うようになりました。しかし、これがなかなかうまく行かないのです。

伝言ゲームのはじまり

ここからは、あくまでPDMの視点でのお話になります。
察しの良い方はもうお気づきかと思いますが、開発チーム、QA、オフショア先の3者間で伝言ゲームが始まります。開発チームがQAに依頼した検証内容は、下記の通りでした。

〇月〇日から、A機能の計算ロジックが変わる。一部のロジックはそのままだが、変わるものもある。ロジックが変わる項目については新ロジックで、ロジックが変わらない項目については旧ロジックで計算されていることを確認したい。年内（12月）にQAが完了するスケジュールで調整したい。

しかし、オフショア先から開発チームに納品された見積書は簡単にまとめれば、下記のような内容でした。

A機能の計算ロジックが現行と変わらないことを確認する。リグレッションテストが中心となる。年始（1月）いっぱいまで実施を行う。

な、なんじゃこりゃぁ～！どうしてこうなった・・・。なにひとつ合っていないじゃないか・・。
（信じがたいかもしれませんが、事実です。）

QA経由で状況を確認するも・・

さすがにこれではテストにならないので、開発チームはQAに問い合わせ、QAとオフショア先の間で認識合わせのミーティングが実施されます。そして後日、開発チームに修正後の仕様書が再納品されます。しかし肝心の要件は意図通りに伝わっておらず、スケジュールや細かなテスト項目の修正に留まっていました。結局、QAも他の対応に追われてパンク状態なのです。委託しているので詳しく事情も把握できておらず、結果的にらちが明かなくなり、オフショア先と開発チームが直接話し合うことになりました。

QAを依頼した開発チームがQAの作業をすることに

ただし、この話し合いも一筋縄にはいきません。そもそも要件が意図通りに伝わっていないので、成果物は一から再作成が必要な状態です。しかし、今から作成していてはスケジュールが間に合わない。結局、オフショア先が作成したテストケースを開発チームが大幅に手直しすることで、納期内に収めるという結論になりました。 QAをお願いしたかったはずの開発チームが、実質的にQAの作業を実施しているような結果になってしまったのです。

情報は共有されない

テストケースの見直しが完了したら、テスト実施です。しかしここでも問題は発生します。開発チームの案件は複数あるため、当然複数のプロジェクトのQAを依頼しています。しかし、オフショア先の会社は同一だったとしてもチームが別々のため、仕様に関して同じような質問がすべてのチームから別々に来るのです。全く同じような内容の質問が3つのチームから別々に飛んできたこともありました。さすがにこれは効率が悪いと感じました。

QAとオフショア先の情報共有が改善

このままでは開発チームが質問対応に追われ、パンクしてしまいます。QA、オフショア先と3者間で急遽、臨時ミーティングを開催。開発チームへの問い合わせ前に、内部で情報共有を行っていただくようお願いしました。具体的には、

・使いまわしができそうなテストデータをチーム間で共有する
・仕様の確認をチーム相互で行う
・他チームの起票済みの問合せ内容を事前に確認する

などです。
また、QAもオフショア先へのヒアリングを定例で実施し、コミュニケーションの頻度を増やしました。それからは特に大きな問題もなく進み、無事納期通りにQAが完了しました！

他社QAのメリットは？

ここまでひたすらデメリットを挙げてきたような感じになっていますが、当然他社QAによるメリットを感じる瞬間もありました。個人的に他社QAで良かったと感じたのは下記の点です。

・第3者による検証なのでバイアスが入りにくい。自社の場合と比べて、仕様を熟知していないことが多いので、開発者が気づかない盲点に気づきやすい
・品質に対するフィードバックを通じて自社の弱みや課題が見えてくる
・検証結果に客観性を持たせられるので、リリース可否の判定に有効なエビデンスとなる

特に、私が魅力に感じたのは1点目と2点目です。

「今回の改修範囲ではないが、今回のリリースから障害として顕在化してしまう」という内容の隠れたバグを見事検知することができました。自社でQAを行っていると、仕様を熟知しているがゆえに、違和感や細かな仕様の不整合に気づきにくいと感じることがあります。他社QAの場合、客観的な視点でテストできるのでそのような見落としに気づく可能性があります。

また、QA結果のフィードバックを通じて、他社と比べてどういった個所に品質面の弱みや課題があるか、把握しやすくなるという点も魅力的です。第3者検証会社は他社のQAも幅広く行っているため、客観的な視点で改善すべきポイントが把握でき、品質を向上させることができます。

現職との比較

さて、ひたすら前職の話をしてきましたが、現職の自チームはテスト実施を除き、基本的に自社でQAを行っています。冒頭で「現職の自チームの場合、自社QAの方が費用対効果が高い」と書きましたが、それはなぜなのでしょうか。理由をお話しする上で必要な情報を下記に整理してみました。

	前職	現職の自チーム ※チームにより若干の差異があります
プロダクトの内容	個人消費者向けWebサービス	事業者（法人、個人事業主）向け業務ソフト
開発内容	Webアプリケーション中心	デスクトップアプリケーション、Webアプリケーション
開発規模、工数	大	小～中
QAの形態	自社QA70%、他社QA30%（テスト計画、テスト設計も含む）	自社QA（テスト実施のみ専門チームに依頼）
QA部門の特徴	開発チームから独立した別部門	各開発チームにQAエンジニアがおり、テスト計画、設計を行う。テスト実施は専門チームに依頼

大きな違いは、取り扱っているプロダクトの性質です。

業務ソフトなので、製品の仕様に限らず、税務、労務、財務など幅広い専門知識が求められます。テスト設計を行う上ではこれらの知識が前提となるため、QAを丸ごと外部へ委託するとなると相当な教育コストがかかります。また、コストを払って教育できたとしても、担当者が変わればまた一からスタートです。なので、他社にQAを委託するとかえって効率が悪くなってしまうのではないかと個人的には考えています。

なお、現職ではテスト実施のみをテスト専門チームにお任せしています。自社QAのメリットを活かしつつ、他社QAの「客観性」といった部分もある程度補えるような体制となっているので、基本は自社QAですが、他社QAのいいとこ取りもしていると言えるかもしれません。

さいごに

これまでのお話をもとに、自社QA、他社QAのメリットとデメリットをまとめると、下記の通りとなります。結論としては、自チームの場合は自社QAの方が得られるメリットが大きく、「テスト専門チームでのテスト実施」で「客観性」というデメリットを補っているということになります。

	メリット	デメリット
自社QA	業務知識、製品知識に精通しているのでQAが円滑に進められる	テスト工数がかかる、要件や仕様に精通しているゆえにバイアスが生じる可能性がある
他社QA	客観性が向上する、自社の品質面の弱みや課題が分かる	業務理解、仕様理解の難易度が高く、コミュニケーションコストも含めイニシャルコストがかなり高い