テスト見積もりは掛け算2つで出せる

テスト見積もりの「だいたい○○ケース」は、多くの現場で経験と勘によって決められている。前回と同程度の規模感だから、経験的にこの機能なら、という根拠で数字が出てくる。この記事が面白いのは、その勘の中身を分解し、2つの掛け算に直せると示した点だ。テストボリューム（ケース数やステップ数）を生産性で割れば工数が出る。筆者は、勘が通用しない初めての領域、上席への説明責任、見積もる人による2〜3倍のばらつきという3つの困りごとを挙げている。 AIの鬼の視点で言えば、ここで効いているのは数式そのものより「分解すること」だ。経験者の頭の中にあった「オブジェクト×観点」のマッピングを外に出せば、見積もりは人の記憶から引き出す作業ではなく、検証できる資産に変わる。一方で、記事が示す生産性の目安はIPAの統計やSHIFT社の実務知見に基づく相場観にすぎない。業界に絶対的なベンチマークは存在しない。目安を下回ったらプロセスを疑い、超えたいならやり方を変える、という使い方が現実的だ。数字を権威として崇めず、自社の実績で補正し続けることが本音の結論である。AIが効くのは仕様書からのオブジェクト抽出、観点のマッピング、係数の算出の3箇所だが、画面に出ない暗黙の仕様は抜けるので、人のレビューが欠かせない。 中小企業の実務に落とすなら、次の一手は単純だ。テスト管理ツールに設計と実行にかけた時間を記録し、過去数スプリント分の自社係数を作る。その係数を使えば、「なぜこの工数なのか」をケース数で説明できるようになる。記事の架空の例では、勘で2〜3人日とされた見積もりが、ケース単位の分解で4.3人日になり、時刻入力の境界値テストや状態遷移テストといった抜けが見えた。当てることより、説明できる見積もりにすることが、上司への最大の武器になるということだ。