QAアウトソーシング業者選定ガイド · 2026

QA外注は一つの仕事ではありません。大きく三つに分かれます。品質基準とリリースゲートを立ててほしいという診断・コンサルティング、合意した範囲を代わりに実行してほしいという実行代行、デプロイのたびに繰り返す回帰を資産へ移してほしいという自動化です。三つは選ぶ物差しも契約の形も異なります。リリース日が目前なのにコンサルティング中心の供給元を呼べば、診断文書だけが残ったまま当日が来ます。逆にチームごとに欠陥等級がばらばらな組織が実行要員だけを受け入れると、要員が抜けた瞬間に元の状態へ戻ります。提案依頼書を書く前に、いま欠けているのが判断の体系か、実行の手か、繰り返しの費用かを一行で書き出す必要があります。この区分なしに受け取った見積もりは別々の仕事に値を付けた文書なので、並べても比較が成り立ちません。契約形態は範囲の確定度と変更の可能性に合わせて決めます。成果物が定まる区間は固定価格、継続的な実行は期間と要員規模で提案を受けられます。自動化は構築分と維持分を分けます。一つの契約に複数の業務を含める場合も、項目別の範囲と金額を区別すれば変更理由を追跡できます。三つの筋の外に置かれる仕事も先に分けます。性能と負荷、障害復旧の検証は実行代行と名前が似ていますが、負荷モデルを作る準備が実行より大きい別の仕事です。三つの筋を一社が続けて受けられるかも併せて見ます。診断で立てた判定の物差しを実行がそのまま使い、実行で積み上がったケースが自動化の対象になれば、途中ごとに生じる引き継ぎの損失がなくなります。

結果表を渡すことと、リリース可否を判定することは同じ仕事ではありません。合格件数と不合格件数だけを受け取れば、その数字を読んでリリースを決める役割が再び発注側へ戻ってきます。判定まで委ねるには三つを確認します。第一に、判定の語が文書で先に定義されているかです。リリース可・READY WITH CONDITIONS・保留のように三つの値が固定されていれば、会議で解釈が割れません。第二に、確認できなかった領域が結果と同じ文書に書かれるかです。検証していない箇所を書かない報告書は、合格率を実際より広く読ませます。第三に、結果の作成者と検討者、リリース承認者を確認します。IXCのリリース前QA検証のうちRelease Readiness Reviewでは、シン・ミンギュCTOが結果、除外範囲、前提、残存リスクを検討したうえで署名したメモを渡します。アウトソーシング契約の検討・報告の役割は、その範囲に合わせて決めます。社内QAも外部QAも、合意した基準と追跡可能な結果が必要です。外部検証は開発から独立した視点を加え、同じ様式の根拠がリリース会議の判断を支えます。判定文書の寿命も尋ねます。監査や事故調査で再び取り出すとき、要件とテスト、欠陥と対応、承認記録が一本の線でつながる形でなければ根拠を集め直すことになります。延期を勧める際に、何がそろえば再び判断できるかまで書かれるかも同じ軸の問いです。

範囲が開いた契約は値が増える方向にしか動きません。着手前に文書で固める項目は決まっています。対象ビルド数、製品領域数、主要フロー数、合意シナリオ数、再テスト回数です。ここに除外範囲を同じ文書へ書きます。セキュリティ認証の適合性やコード品質の評価のように、検証の名で期待されながら実際は別の仕事である項目は先に切り分けておかなければ、終了時点で争いになります。範囲を広げる、あるいは狭める手続きも文書に入れます。誰が要請し誰が承認し、値がどう変わるかがなければ、変更要請が口頭で積み上がり最後に一括で請求されます。提案書に期間と人数だけがあり、この五つの数値が空いていれば、その値はまだ見積もりではなく見込みです。候補ごとの数値と成果物をそろえると、見積もり差のうち範囲の違いが占める部分を確認できます。期間契約だからといって範囲の固定が免除されるわけではありません。常駐要員を数か月置く契約でも、その期間に何をどの深さで見るかは着手週に文書で定める必要があります。そうしなければ要請が来るたびに仕事が付き、契約後半で最も重要な回帰の区間が押し出されます。範囲を狭める決定も同じ重さで書きます。今回のリリースで見ないと決めた領域は次のリリースの第一候補になるため、除外一覧は捨てるものではなく次の計画の入力です。

外注期間が終われば人は去ります。残るものを契約書に書いておかなければ、次のリリースで同じ値を再び払うことになります。残す一覧は四つです。実行したテストケースとシナリオ文書、自動化スクリプトと実行環境の設定、深刻度と再現条件まで付いた欠陥台帳、判定の物差しとリリースゲートの定義です。形式も併せて決めます。文書ファイルと元データを一緒に受け取るか、自動化資産がリポジトリのアクセス権とともに渡るかが、実際に再利用できるかを分けます。供給元の専用ツールの中にだけ資産が積み上がる構造なら、契約が終わった瞬間に読めない資産になります。引き継ぎ後の問い合わせ対応期間も併せて書きます。IXCはテスト資産と運用方法を社内チームへ渡したうえで、4週間は問い合わせ対応を続けます。この期間がなければ、引き継ぎ文書は受け取ったのに最初の失敗の前で尋ねる先がなくなります。引き継ぎは終了週にまとめて行う行事ではありません。判定の物差しと報告様式を着手段階で社内チームと決めておけば、契約期間を通じて同じ文書が積み上がり、終了時点では渡すものが既にできあがっています。最後に引き継ぎ文書を新たに書く供給元は、その文書を実際の作業ではなく記憶で書きます。社内にQA組織が既にあるなら、問題は引き継ぎではなく分担です。どの領域を社内が持ち続け、どの領域を渡すのか、欠陥深刻度の物差しと報告様式をどちらのものに統一するのかを着手前に決めます。

自動化は構築件数とともに、繰り返しの実行と維持に必要な作業を見ます。件数だけでは運用上の価値を判断できません。尋ねるべきは三つです。失敗した実行を製品欠陥と環境の問題、スクリプトの老朽に分ける手続きがあるか。結果が揺れるケースを隔離して別に直す担当と周期が決まっているか。自動化しないと決めた領域が理由とともに文書に残るか。三つがなければ、誰も信じない赤い失敗一覧が積み上がり、チームはやがて結果を見なくなります。ツールは製品の構成が決めます。ウェブはPlaywrightとSelenium、モバイルはAppium、負荷生成はJMeterのように階層ごとに通用する選択肢があり、IXCは対象の規格に合わせて選びます。供給元が扱うツール一つに製品を合わせろという提案が来たなら、順序が逆になっています。画面変更の多い領域をAPI水準へ下ろすか、手動検証として残すかの判断を併せて示すかも見ます。実行結果がどこに積み上がるかも同じ問いです。パイプラインに付いてデプロイのたびに自動で回り、画面キャプチャとログが一か所に束ねられていれば、デプロイ担当は別途の依頼なしに合否を読みます。手動で起動する自動化も反復作業を減らせます。必要な周期で漏れなく実行できるか、パイプラインや定期実行への接続が必要かを確認します。テストデータの扱い方も確認します。アカウントや商品、注文のような事前条件を実行時点で作り、終われば戻す仕組みがなければ、先の実行が残したデータで結果が揺れ、その揺れはやがて失敗一覧を無視する習慣につながります。

人数と期間は案件ごとに異なります。重要なのは、その値を何が決めたのかが提案書に書かれているかです。まず常駐の要否から見ます。社内ネットワークでしか開かないテスト環境、持ち出しが禁じられたデータ、保管場所が定められた実機があれば常駐が要ります。そうでなければリモートが基本で、IXCもリモートを基本としつつ必要であれば常駐も担います。常駐を選ぶなら、アカウント発行の範囲と持ち出し禁止項目を先に定めたうえで人数と期間を決める順序が正しい形です。規模を動かす変数は四つです。検証対象のプラットフォームと端末の組み合わせ数、デプロイと回帰の周期、リリースまでの残り期間、自動化資産の有無です。組み合わせが増えれば実行回数は掛け算で増え、回帰の周期が短ければ同じ実行が毎月繰り返されます。提案書に人数と期間だけがあり、この四つがなければ問い直します。値を決めた根拠を説明できない供給元は、範囲が変わったときにも説明できません。リモートを選んだなら、報告の周期と窓口を契約に入れます。週1回同じ様式で欠陥と残存リスクが上がり、緊急時の連絡経路が定まっていれば、物理的な距離は問題になりません。時差のあるチームと分担する場合は、責任の境界を文書で分けておくことで、同じ欠陥を双方が同時に拾う、あるいは誰も拾わないという事態がなくなります。最後に規模が変わる区間を先に印を付けます。大規模な回帰が回る週と安定化の区間では必要な人数が異なるため、リード一名が契約期間を通じて固定され実行要員が区間ごとに付く形を使えば、人数が増減しても判定の物差しは揺れません。