ソフトウェアQA外注の費用・工数見積もりガイド

QAの見積もりを受け取ったとき、最初に目に入る値は期間と人数です。ところがこの二つは結果であって原因ではありません。原因は範囲です。範囲は五つの数値で書かれます。対象ビルド数、製品領域数、主要フロー数、合意シナリオ数、再テスト回数です。この五つが書かれた見積もり同士は並べて比較できます。空欄の見積もりは比較表に載りません。実際、候補間の金額差の大半は実力差ではなく範囲差です。一社が主要フロー三つとシナリオ三十を想定し、別の一社が製品全体を想定していたなら、金額が違うのは当然です。ですから予算を立てる順序は、先に金額を集めることではなく、この五つの数値を自分たちで先に書き出すことです。数値を決めにくければ逆から尋ねても構いません。決めた予算の中でこの五つをそれぞれいくつに置けるかを問い返せば、同じ金額に入る内容の差が見えてきます。除外範囲も同じ文書に書きます。セキュリティ認証の適合性やコード品質の評価のように、検証の名で期待されながら実際は別の仕事である項目を先に切り分けておかなければ、終了時点の争いと追加請求が生じます。範囲変更の手続きも金額の一部です。誰が要請し誰が承認し、金額がどう変わるかが契約書になければ、変更要請が口頭で積み上がり最終月に一括で請求されます。予算を安定させる最も安い手当ては、変更一件ごとに何がどれだけ増えるかを一行で書く規則を設けることです。範囲を決める物差しは製品リスクです。失敗したときに売上が止まる、あるいはデータが食い違う流れを先頭に置き、そこから下へ降りながら切ります。予算がどこで尽きても、上側は既に確保された状態になります。

同じ一日分の工数でも、種類によって何に使われるかが異なります。機能検証はシナリオ数にほぼ正比例します。ケースを書く時間と実行する時間がともに増えるため、数を減らせば金額もその分下がります。探索的テストは数ではなく時間で買います。仕様にない条件を掘る仕事なので事前に数えられる単位がなく、代わりに何時間をどの領域に使うかで契約します。回帰は実行自体は単純ですが対象の幅が広く繰り返しが多いため、累積工数が最も大きくなります。性能と負荷の検証は性格がまた違います。運用ログから時間帯別の流入分布と機能別の呼び出し比率を取り出し負荷モデルへ移す準備作業が実行より大きく、結果をボトルネックの位置と改善順序へ移す分析にも時間が付きます。障害注入と復旧検証は別環境と中断基準の合意が先に要るため、準備項目がもう一つ乗ります。見積書でこれらの種類が一行にまとめられていれば、分けてほしいと依頼します。種類別に分けてこそ、予算が足りないときに何を落とすかが判断できます。種類によって準備期間の位置も違います。機能検証は着手とほぼ同時に実行が始まります。性能と障害の検証は環境とデータがそろうまで実行が始まりません。この準備区間を日程から外して金額を立てると、実行期間が後ろへずれ、要員が待機する日がそのまま費用になります。文書のない製品は種類とは別にもう一項目が付きます。画面とコードから実際に実装された規則を取り出し要件を復元する作業です。この区間を見積もりから外すと、実行担当は何を合格と見るか分からないまま始めることになります。

最も過小評価されやすい変数です。シナリオを三十に確定しても、ブラウザとOS、端末と解像度の組み合わせが四つあれば実行回数は百二十回です。組み合わせが八つなら二百四十回になります。シナリオを減らすより組み合わせを減らすほうが、金額をはるかに速く下げます。組み合わせを決める根拠は好みではなく実際の利用者分布です。アクセス統計から上位の組み合わせを取り出し、どこまで切るかを決めます。切り落とした組み合わせは除外範囲に名前で書きます。実機が必要な場合は項目が増えます。機器の確保と保管、OSバージョンの管理が工数として入り、機器が発注側にあれば常駐の要否とも絡みます。逆にクラウド端末サービスで代替できる区間なら、機器費用が実行時間の費用に置き換わります。ここに言語と地域設定が加わると組み合わせが再び掛け算になるため、多言語サービスでは初期に検証対象の地域を確定することが金額を分ける最大の決定になります。組み合わせを減らすもう一つの方法は、確認地点を階層で下ろすことです。画面でしか確認していなかった項目の相当数はサーバーインターフェースの水準で同じ結論が出て、その階層は端末の組み合わせと無関係に一度回せば済みます。組み合わせごとに必ず画面で見るべき項目が何かを選り分ければ、実行回数は目に見えて減ります。

一度検証して終わる仕事と、デプロイのたびに繰り返す仕事は別の契約です。リリース前検証のようにビルド一つを見る仕事は一回限りの金額で終わります。リリース前QA検証は、こうした一回限りの検証を三つの固定金額で提供しています。重要フローレビュー（¥66,000）は、リリース候補ビルド1件と製品領域1つを対象に重要フロー1つと合意した最大10シナリオを確認し、再テストは含みません。リリース準備度レビュー（¥198,000）は同じビルドと製品領域を5営業日で検証し、重要フロー3つと合意した最大30シナリオを確認します。このレビューには、合意した修正の1回の再テストと、シン・ミンギュCTOが署名したリリースメモが含まれます。拡張レビュー（¥330,000）は、より広い1回のリリースを対象に最大2領域、重要フロー5つ、合意した最大50シナリオを確認し、1回再テストします。回帰はデプロイ周期の分だけ掛け算され、毎月出ていく費用になります。週1回のデプロイと1日数回のデプロイは、同じシナリオを使っても年間工数が大きく分かれます。ですから見積もりを読むときは、総額とともに1回あたりの金額と年間の繰り返し回数を分けて見る必要があります。再テストの条件もここに付きます。合意した修正分を一度だけ見直すのか、修正が出るたびに見るのかで実行回数が変わり、それがそのまま金額になります。繰り返し回数がある線を越えると自動化の構築費が回収されます。その線は、実行頻度と画面変更の周期、テストデータ準備の難しさ、失敗時に原因を分析する時間を同じ表に置いて計算します。実行頻度だけが高く画面が頻繁に変わる領域は自動化しても回収されないため、手動で残すほうが安く済みます。回帰の範囲を狭めることも金額を下げる手段です。修正一件がどの機能に触れるかを判定して見直す対象を選び出せば、デプロイのたびに全部を見直さずに済みます。この判定がない組織は安全を理由に毎回全体を回し、その選択が回帰費用を最も大きくする原因になります。デプロイ周期の短い組織は実行の時間帯も金額に入れます。夜間や週末に回る実行、緊急デプロイに付く即時検証は平常時の実行とは条件が異なるため、対応時間とともに契約へ書いておかなければ後から協議で処理されることになります。

常駐はリモートより金額が大きくなります。移動と座席、アカウント発行と持ち出し規定の確認が実行以外の工数として付くためです。ですから常駐を求める前に理由を確認します。社内ネットワークでしか開かないテスト環境が理由なら、制限付きアカウントとアクセス経路で代替できるかをまず見ます。持ち出しが禁じられたデータや保管場所の定まった実機が理由なら常駐が適切で、その場合はアカウント発行の範囲と持ち出し禁止項目を先に定めてから人数と期間を決める順序が金額を安定させます。IXCはリモートを基本としつつ常駐も担い、いずれの場合も人数と期間は前述の変数が決めます。自動化は方向が二つに分かれます。構築の区間では同じ範囲を手動で見るより金額が大きくなります。スクリプトだけでなく、自動化専用の識別子の規則、画面単位をオブジェクトへ束ねる階層、実行環境とテストデータの仕組みまで併せて作るためです。その代わり以降は繰り返し分がなくなり、維持工数が毎月付く代わりに実行工数が抜けます。見積書で自動化が一塊で書かれていれば、構築分と維持分を分けてほしいと依頼します。維持分には失敗分析が入ります。実行が失敗したとき製品欠陥か環境の問題かスクリプトの老朽かを分ける時間が自動化運用の実際の工数であり、この手続きがなければ失敗一覧が積み上がり、やがて誰も結果を読まない状態になって構築費が丸ごと失われます。

同じ範囲を同じ期間で見ても、何を残すかで金額が分かれます。結果要約一枚を受け取ることと、シナリオごとの結果に確認できなかった領域と残存リスクを付け、署名されたリリースメモまで受け取ることは別の仕事です。欠陥台帳に深刻度と再現条件を付ける作業、要件とテストと欠陥と承認記録を一本の線でつなぐ追跡表、次のリリースで再び使うテストケースと自動化資産、社内チームが引き継ぐ運用引き継ぎ書が、それぞれ工数です。どこまで必要かは、この検証を一度きりにするかで分かれます。一度きりなら判定文書までで十分で、繰り返すなら再利用資産を残すほうが二度目のリリースから金額を下げます。監査や事故調査に備える組織なら、追跡表は選択ではなく必須の項目になります。見積もりを依頼する際に成果物の一覧を先に書いて送れば、返ってきた金額がなぜ違うのかがその一覧の上で説明されます。引き継ぎの項目も成果物に入れます。自動化資産をリポジトリのアクセス権とともに渡すのか、引き継ぎ後の問い合わせ対応期間が何日かが書かれていてこそ、次のリリースの費用が読めます。IXCはテスト資産と運用方法を社内チームへ渡したうえで4週間は問い合わせ対応を続け、この期間は成果物とともに着手前に文書で定めます。