なぜシナリオテストは高コストになるのか
シナリオテスト（受入テスト）の見積もりが膨らむ最大の原因は、テストを書く人と業務を知っている人が分離していることです。開発会社が「業務を推測しながら」テストシナリオを書くため、業務側で確認すると「この前提は違う」「このパターンが抜けている」と差し戻しが発生し、書き直しコストが工数を圧迫します。
具体的には次のような構造でコストが発生します。
- 業務ヒアリング → エンジニアが業務を理解する時間（数日〜数週間）
- シナリオ起案 → エンジニアが推測でケースを書く工数
- 業務側レビュー → 「現場ではこうなる」のフィードバック
- 差し戻し対応 → 1〜3往復は当たり前
- 本番投入後の漏れ修正 → 想定外シナリオの追加対応
この5段階のうち、業務ヒアリング・差し戻し対応・漏れ修正は「業務知識がエンジニア側に無いこと」が原因で発生する純粋な無駄です。発注側が業務を構造化して開発会社に渡せば、ここの工数を直接削れます。
ユーザーストーリーとシナリオが揃っていれば、発注側もテストできる
シナリオテストは「業務シナリオを実機で再現して期待結果と一致するか確認する」作業です。プログラミングは不要で、業務を知っている人が一番得意な仕事に近い。問題は「何をテストすればいいか」が言語化されていないこと。
逆に言えば、次の3点セットが発注側の手元にあれば、テスト実施は発注側が大半を担えます。
- ユーザーストーリー: 誰が何をなぜしたいか。テストの「目的」を定める
- EARS記法の受入条件: 何が満たされれば合格か。曖昧さなく数値・条件で書く
- Gherkin（Given/When/Then）シナリオ: 具体的なテスト手順。クリック手順レベルまで書ける
この3点が揃っていれば、開発会社はテスト基盤（テストデータ準備・自動化フレームワーク・CI連携）に集中でき、シナリオを「書く」工数は発注側が吸収できます。
必要な3点セット：ユーザーストーリー、EARS、Gherkin
ユーザーストーリー（テストの目的を定める）
ユーザーストーリーは「誰が・何を・なぜ」したいかを1文で書く形式です。テストの設計に使うときは、各ストーリーが「合格／不合格」を判定できる粒度であることが重要です。詳細な書き方はユーザーストーリーの書き方完全ガイドを参照してください。
EARS記法（受入条件を曖昧さなく書く）
EARS記法は「常時／イベント駆動／状態駆動／オプション機能／異常系」の5パターンで要件を書く形式です。「速やかに」「使いやすく」のような形容詞を排除し、テストで合否を機械判定できる文面にします。詳細はEARS記法とはを参照してください。
Gherkin（具体的なテスト手順を書く）
GherkinはGiven/When/Thenの3要素で1シナリオを表現します。Given（前提）、When（操作）、Then（期待結果）が明確なので、業務担当者が手で再現できる手順書としても、自動テストの仕様書としても使えます。詳細はGherkin入門を参照してください。
Feature: 商品検索
店舗マネージャーが在庫を素早く確認できるよう、商品名・コード・カテゴリで在庫を検索できる。
Scenario: キーワードでの正常検索
- Given商品マスタに「やかん」が10件登録されている
- Andユーザーは検索画面を開いている
- When検索ボックスに「やかん」を入力する
- And検索ボタンをクリックする
- Then1秒以内に10件の検索結果が表示される
- And各結果に商品名・在庫数・最終更新日が含まれる
Scenario: 該当なし
- Given商品マスタに「該当無し商品」は登録されていない
- When検索ボックスに「該当無し商品」を入力して検索する
- Then「該当する商品がありません」が表示される
- And検索結果リストは空である
発注側参画でコストが下がる具体パターン
受入テストフェーズ
本番投入前の受入テストで、発注側がGherkinシナリオを手で実行して結果を記録する形に切り替えると、開発会社の受入テスト工数を半分以下にできます。Gherkinが書けていれば「クリック手順 → 期待結果」の対応が明確なので、業務担当者でもブレずに実行できます。
回帰テスト
機能追加や改修のたびに「今までの機能がまだ動くか」を確認する回帰テストは、開発会社に丸投げすると毎回数十万円の工数になります。Gherkinが資産として残っていれば、業務側で月次・四半期に1回まとめて回す運用に切り替えられ、外注を最小化できます。
本番投入後の確認
リリース直後の挙動確認も、業務側で実シナリオを回すのが最も精度が高い検証です。エンジニアが「動作確認OK」と言っても業務上の例外パターンは見落とされやすい。発注側がGherkinに沿って5分で1シナリオ回せば、リリース直後の品質保証として機能します。
コスト削減の試算例
同規模の業務システム開発で、フル外注パターンと協業パターンを比較した場合の試算例です（あくまで目安、案件規模で大きく変動）。
項目 | フル外注 | 協業（発注側参画） |
|---|---|---|
業務ヒアリング | 40時間 | 10時間（ストーリー渡し前提） |
シナリオ起案 | 60時間 | 20時間（発注側起案、開発会社レビュー） |
受入テスト実施 | 40時間 | 15時間（自動化部分のみ） |
合計 | 140時間 | 45時間 |
単価1.5万円/時間で換算すると、外注費は210万円→67.5万円（約-68%）。差分の約140万円が、発注側の工数（業務担当者2名で1〜2週間程度）と引き換えに浮く計算になります。発注側の人件費はもともとサンクコストなので、純粋にキャッシュアウトを抑えられる構造です。
それでも開発会社に任せるべき領域
すべてを発注側で巻き取るのは現実的ではありません。次の領域は専門性が必要なので開発会社に任せるのが合理的です。
- ユニットテスト: 関数単位の自動テスト。コードの中身を理解する必要がある
- 非機能テスト: 負荷／セキュリティ／パフォーマンス。専用ツールと知見が必要
- テスト自動化基盤: PlaywrightやCypress等のCI連携。一度作れば長期で効く投資
- テストデータ準備: 大量データ生成、本番想定の偏りを再現する設計
発注側が担うのはあくまで「業務シナリオの起案と受入確認」。開発会社は「テスト基盤と自動化、専門領域のテスト」に集中する分業が、品質・コストの両面で最も効率的です。
協業を成立させるための準備
協業によるコスト削減を実際に成立させるには、発注側と開発会社が次の流れで設計フェーズを共有する必要があります。
業務知識を持つ人が書ける粒度で、技術用語は不要。
「発注側がストーリーとEARSを起案 → 生成AIでGherkinに変換 → エンジニアが補正・実装 → 同じGherkinをデモ／受入テスト／CI回帰テストに使う」のサイクルが成立すると、要件定義からテストまでが1本の資産で繋がります。詳細はEARS×Gherkin｜要件定義からデモ／シナリオテストまでを生成AIで一直線につなぐを参照してください。
Beekleの取り組み：シナリオを発注側と一緒に書き、テストも一緒に回す
Beekleは、要件定義フェーズで発注側のビジネスサイドと一緒にユーザーストーリー・EARS受入条件・Gherkinシナリオを作る進め方を標準としています。「開発会社が裏でテストシナリオを書いて納品する」ではなく、発注側がシナリオの主導権を持ち、開発会社はテスト基盤と自動化に集中する分業を契約条項に含めます。
発注側のシナリオ起案を支援
Beekleはユーザーストーリー・EARS・Gherkinの書き方を発注側に学習資料と一緒に提供し、最初の数本は伴走しながら起案します。慣れたら発注側が独立して書けるようになるので、案件が増えても発注側のテスト工数は増えにくい構造になります。
生成AIでGherkin変換を自動化
EARSの受入条件をGherkinに変換する作業は、生成AIで大半を自動化できます。Beekleは発注側がEARSを書ければ、Gherkinへの変換と初稿レビューを生成AIワークフローで支援する体制を組みます。
ゼロスタートで「協業の進め方」を発注前に体験
Beekleのゼロスタート（プロトタイプ無料体験）では、初期費用0円のMVP開発・PoC開発の段階でこの協業フローを実際に試せます。発注前に「自社にこの協業ができるか」を低コストで確認できるため、本契約後のコスト削減効果を見極めてから判断できます。
よくある質問
Q1. 業務担当者にユーザーストーリーやGherkinを書くスキルはありませんが、可能ですか？
A. はい、書き方は1〜2日のトレーニングで身につく形式です。プログラミング知識は不要で、業務知識がある人なら誰でも書けます。Beekleは最初の数本を伴走して書き、慣れたら発注側が独立して書けるようになるので、長期的には発注側の自走を前提に進めます。
Q2. ユーザーストーリーとEARSとGherkinの3つを全部書く必要がありますか？
A. 全部書くのが理想ですが、案件規模に応じて省略できます。小規模ならユーザーストーリー＋Gherkinの2点で十分なケースもあります。中規模以上はEARSも入れた方が、機能要件と非機能要件の漏れが減って結果的にコストが下がります。
Q3. 発注側が参加するとテストの品質が下がりませんか？
A. むしろ上がります。業務知識がある人が直接シナリオを書くため、エンジニアが推測で書くより「現場で起きる例外パターン」が漏れにくくなります。本番投入後の「想定外シナリオでバグ発覚」も減るため、トータルの品質コストは下がります。
Q4. 開発会社が「自社で書きます」と言ってきた場合はどうすればいいですか？
A. 「テストシナリオの著作権と再利用権が誰にあるか」「次回改修時に同じシナリオを再利用できるか」を契約で明確にしてください。開発会社が抱え込むと、ベンダーロックインが発生して保守費用が高止まりします。発注側資産として残す前提で進めるのが正解です。
Q5. 自動テストと手動テスト、発注側はどちらを担当すべきですか？
A. シナリオの起案は両方担当、実行は手動を中心に発注側、自動化部分は開発会社、という分業が現実的です。Gherkinが書けていれば、後から自動テスト化するのも開発会社側で機械的にできます。
Q6. シナリオテスト協業の費用効果はどのくらいで現れますか？
A. 案件規模にもよりますが、最初の1案件で工数50%減、2件目以降は60〜70%減の効果が出やすいです。1件目は発注側のスキル習得コストが入るため効果が薄く見えますが、2件目以降はストーリー資産が再利用できるため効果が加速します。
Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。