はじめに
「ちょっとお願いしたいんだけど…このプロダクト、テストお願いできますか？」
そう言われて見せられたのは、完成間近の画面と、簡単な概要だけ。
「仕様書…は、まだなくて。とりあえず触ってみて、バグがないか見てほしいです！」
──実はこれ、QAとしてご相談いただく中でも、とてもよくあるシチュエーションなんです。
個人開発や小規模チームでは、「正式な仕様書を用意する余裕がない」なんてこと、めずらしくありません。
でも、そんなときでも、テストを始める方法はちゃんとあります。
今回は、私がこれまでに実際やってきた「仕様がない状態からのQA」について、お話してみます。
「仕様がない」ってどういうこと？
まず、「仕様がない」というのは、本当に“何も決まっていない”という意味ではないんですよね。
たとえば…
・開発者さんの頭の中にある
・Slackのメッセージでざっくり話した
・FigmaやNotionにUIだけはある
・以前のバージョンがなんとなくベースになってる
こんなふうに、言語化・明文化されてないだけで、実は“期待される動き”は存在していることが多いんです。
なので、QAとして最初にやるのは、「仕様があるかないか」じゃなくて、
どこに“仕様のヒント”が隠れているか？を探す
というアプローチだったりします。
私が実際にやっていること
では、そんなときにQAとしてどう動くか？
いくつか、私の定番パターンをご紹介しますね。
● まずはユーザー視点で触ってみる
いわゆる“アドホックテスト”のように、ざっくり触ってみて違和感や気づきを拾います。
「これってこう動くと思ったけど、実際は違う？」といったポイントは、仕様を考えるうえでのヒントになります。
● チームメンバーに聞いてみる
エンジニアさんや企画者さんに「ここって、どういう動きにしたいんですか？」と率直に聞いてみます。
会話の中から「こうしたかったんだよね」という本音や背景が見えることもあります。
● 類似サービスをチェックする
仕様が見えないときには、過去の類似事例や世の中の標準的なUI/UXを参考にします。
「このタイプのアプリなら、こういう挙動が自然だよね」と、仮の仕様を立てる材料になります。
それでも見えないときは？
正直、「何のヒントもない」ということもあります。
でも、そんなときでもやれることはあります。
● 共通観点でチェックリストをつくる
たとえば、こんな観点は汎用的に使えます：
・テキストの入力制限はある？
・保存して再表示するとどうなる？
・エラーが起きたとき、わかりやすく表示される？
こうした共通観点ベースでチェック項目を作成し、そこから見えてきた動きをもとに仮設を立てていきます。
● QAの経験を活かして“期待される品質”を形にする
ある意味、QAって「明文化されていない“期待値”を可視化する仕事」でもあるんですよね。
仕様がなくても、「たぶんこうあってほしい」という仮説を立てて、そこから逆算で品質をチェックしていきます。
まとめ：「仕様がない」は、出発点になる
「仕様がない」と言われると、ちょっと不安になりますよね。
でも、QAの視点から見ると、「何が仕様になりうるかを探す旅」の始まりでもあります。
「これってどうあるべき？」を一緒に考えながら、品質を少しずつ形にしていく──
そんな役割が、QAにはあるのだと思っています。
おわりに：こんなとき、ぜひご相談ください
「これ仕様ってどう捉えればいい？」
「何をテストしたらいいかわからないけど、なんか不安…」
そんなときは、ユーザー視点とQAの知見でサポートできます。
“ふわっとした不安”の整理からでも大歓迎です。
お気軽にご相談くださいね。
Rua｜現役QAリードが品質支援
👉 プロフィールを見る
👉 出品サービスを見る
