2022の19日目のエントリーです。こんにちは!QAエンジニアのふくだです。最近買ったノイズキャンセリングイヤホンの使い勝手がかなりよく、イヤホン沼に片足を突っ込んでいる今日この頃です(ズブズブ)。ブラックフライデーで買った方もいるのではないでしょうか。ガジェット欲は何歳になっても収まる気配がないですね。技術の進歩を感じます。実は私、つい昨年まで他社でPDM(プロダクトマネージャー)として働いていたのですが、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の方が費用対効果が高い」と書きましたが、それはなぜなのでしょうか。理由をお話しする上で必要な情報を下記に整理してみました。各開発チームにQAエンジニアがおり、テスト計画、設計を行う。大きな違いは、取り扱っているプロダクトの性質です。幅広い専門知識が求められます。テスト設計を行う上ではこれらの知識が前提となるため、QAを丸ごと外部へ委託するとなると相当な教育コストがかかります。コストを払って教育できたとしても、担当者が変わればまた一からスタートです。他社にQAを委託するとかえって効率が悪くなってしまうのではないかと個人的には考えています。現職ではテスト実施のみをテスト専門チームにお任せしています。自社QAのメリットを活かしつつ、他社QAの「客観性」といった部分もある程度補えるような体制となっているので、基本は自社QAですが、他社QAのいいとこ取りもしていると言えるかもしれません。さいごにこれまでのお話をもとに、自社QA、他社QAのメリットとデメリットをまとめると、下記の通りとなります。結論としては、自チームの場合は自社QAの方が得られるメリットが大きく、「テスト専門チームでのテスト実施」で「客観性」というデメリットを補っているということになります。難易度が高く、コミュニケーションコストも含めイニシャルコストがかなり高い少しでも参考になれば幸いです。ご覧いただきありがとうございました。こんにちは、エンジニアのウエタケです。チームでエンジニアをやらせても...2024-06-05元QAエンジニアが、PMの立場でQAエンジニアのイベントに参加してみたこんにちは、弥生のシダです。私は弥生でsubPM*1として活動し...2023-07-28スクラムマスターに俺はなる!......かもしれないこんにちは、カトです。弥生でQAエンジニアをしています。弥生は第23回Quesに協賛します。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。