レギュラー観点の出し方｜テスト観点を4分類で洗い出すチェックリスト例

「観点を出して」と言われても、手が止まる。
画面を見ているのに、何を確認すればいいかが言語化できない。デバッグを始めて少し経つほど、こういう壁に当たりやすいです。

先に答えを言うと、レギュラー観点は4つに分けて考えるのが一番ラクです。
表示・動作・ロジック・条件の掛け合わせ。この4分類を“毎回の型”として持っておくと、観点が安定して増えます。

前提の基本だけ押さえたい場合、まずは↓こちら↓を読んだ後で本ページを読むのがオススメです。
→テスト観点の洗い出しの基本はこちら

この記事では、4分類をゲームデバッグの具体例に落として、コピペで使えるテンプレまで用意します。読み終えたら、そのまま自分の案件の画面に当てて使ってください。

レギュラー観点は4つに分けると漏れにくい

この見出しでわかること：レギュラー観点を4分類で捉え、何をどこまで見ればいいかの“枠”が作れます。

レギュラー観点は、ざっくり言うと「その機能で毎回必ず確認する基本の観点」です。
アプリでもゲームでも、画面が変わっても、最低限ここを押さえれば“穴が空きにくい”という土台になります。

表示を確認する観点

表示観点は「見えるもの全部」が対象です。感覚で眺めるのではなく、次の切り口で機械的に拾うと漏れにくいです。

• 文言：表記ゆれ, 誤字, 言い回し, 敬体の揃い
• レイアウト：位置, 余白, はみ出し, 重なり, 折り返し
• 数値の見え方：桁区切り, 単位, 端数処理, 丸め
• 画像：欠け, ぼけ, 差し替え漏れ, 解像度違い
• 状態の表示：選択中, 未選択, 押下中, 読み込み中, エラー時

ポイントは「表示＝UIの皮」だけで終わらせないことです。状態によって表示が変わる画面ほど、表示観点は増やせます。

動作を確認する観点

動作観点は「触ったらどうなるか」です。画面遷移だけでなく、反応の仕方まで含めます。

• 押せる／押せない：押下できる条件, できない条件
• 遷移：遷移先が正しいか, 戻る挙動, 二重遷移の有無
• 入力：入力できる文字, 上限, 禁止文字, コピー＆ペースト
• レスポンス：反応の速度, 連打耐性, 通信中の操作可否
• 再現性：同じ操作で同じ結果になるか（ランダム要素は除く）

「ボタンを押したら次へ行く」だけだと観点が少なく見えます。
押下できる条件や、通信中・連打・戻るなどの“人がやりがちな操作”を入れると、動作観点は一気に増えます。

ロジックを確認する観点

ロジック観点は「結果が合っているか」です。見た目が正しくても、中身が間違っていることがあるので、ここが抜けると痛いです。

• 計算：加算・減算・倍率・端数処理・上限下限
• 付与／消費：アイテム, 通貨, チケット, スタミナの増減
• 判定：達成条件, 解放条件, 抽選条件, 優先順位
• 保存：再起動後の保持, 途中で落ちたときの整合性
• ログ：履歴, 表示される実績, 受け取り済みフラグ

ロジックは仕様書に書かれていることも多いですが、画面だけ見ていると抜けやすいです。
「この画面は何を増やす／減らす？」「何の条件判定がある？」と自問すると、観点が出しやすくなります。

条件を掛け合わせて確認する観点

掛け合わせは「同じ操作でも条件が違うと結果が変わる」部分を拾う観点です。
全部を網羅する必要はありません。バグが混ざりやすい掛け合わせだけを作ります。

よく使う条件の例はこちらです。

• ユーザー状態：新規／既存, チュートリアル中／後, 未課金／課金
• 所持状況：アイテムあり／なし, 上限付近, 受け取り済み
• 通信状態：良好／遅い／瞬断, 機内モード, 復帰
• 端末状態：低容量, バックグラウンド復帰, スリープ復帰
• 時間：日付跨ぎ, イベント開始直後／終了直前

掛け合わせのコツは「最も事故りそうな条件」を先に決めることです。
条件が無限に見えるときほど、“実害が大きい順”で作ると整理できます。

レギュラー観点が弱いとテスト漏れが起きる理由

この見出しでわかること：なぜ観点の弱さがテスト漏れに直結するか、現場で起きる形で理解できます。

観点が出ない状態は、頑張りが足りないというより「チェックの型がまだ手元にない」だけです。
型がないと、どうしても目に見える部分（表示や遷移）に寄って、ロジックや掛け合わせが抜けやすくなります。

デバッグの進め方そのものを整えたい場合は、手順の基本をこちらで確認できます。
→デバッグの進め方の基本

見た目は仕様通りに見えても内部的なバグも潜んでいる

たとえば、文言もレイアウトも合っていて、ボタンも押せる。
それでもバグが潜んでいる典型は、次のようなものです。

• 表示は正しいのに、内部の所持数だけ増減が間違っている
• 抽選結果の表示は合っているのに、履歴や受け取りフラグがズレている
• 成功メッセージは出るのに、再起動すると反映されていない

こういうバグは、表示・動作だけで終わると拾えません。
だからこそ、レギュラー観点の中にロジックと掛け合わせを“必ず入れる”のが効きます。

観点がないと人によって品質がブレる

観点が頭の中だけにあると、同じ画面を見ても人によって確認範囲が変わります。
結果として起きるのは、次の2つです。

• 同じ指摘が何度も出る（別の人が見落として再発する）
• レビューで説明が難しい（何を基準にOKと言ったか言語化できない）

4分類のテンプレを使うと、「表示・動作・ロジック・掛け合わせを一通り見た」と説明できるようになります。
この“説明できる”が、次の評価にも繋がりやすいです。

レギュラー観点の洗い出し手順

この見出しでわかること：4分類を使って、実際に観点を増やす手順がわかります。

ここからは、実務での手順に落とします。
細かい書き方は現場で多少変わりますが、流れはシンプルです。まずUIを出して、表示・動作を当てて、最後にロジックと掛け合わせを足します。

手順1 画面のUIを全部書き出す

最初にやるのは、観点づくりではなくUIの棚卸しです。
ボタン、テキスト、画像、タブ、リスト、ポップアップ、入力欄。画面に存在する要素を、上から順に書き出します。

コツは「見えるもの」を機械的に拾うことです。
ここで漏れると、後の観点も全部漏れます。

手順2 UIごとに表示観点を当てる

UIが並んだら、各UIに対して表示観点を当てます。
全UIに同じ観点を機械的に当てるだけでも、最低限の抜けが減ります。

• 文言は正しいか
• 桁・単位・表記は正しいか
• 収まりは崩れていないか
• 状態で表示が変わるなら、その差分は合っているか

「画面全体を眺める」より、「UI単位で当てる」ほうが漏れにくいです。

手順3 UIごとに動作観点を当てる

次に、同じUIに動作観点を当てます。
押下、長押し、連打、スクロール、入力、戻る。UIによって“触り方”が違うので、UIごとに作るのが早いです。

• 押下できる条件／できない条件
• 遷移先と戻り
• 通信中の挙動（連打や二重送信）
• 入力なら、上限・禁止・貼り付け

ここまでで、表示・動作のレギュラー観点は揃ってきます。

手順4 目に見えないロジック観点を足す

最後に、ロジック観点を足します。
考え方は「この画面は何を確定させる画面か」です。

• 何が増える／減るのか（通貨、アイテム、回数、ポイント）
• 何が判定されるのか（達成、抽選、解放、付与条件）
• 何が保存されるのか（履歴、フラグ、受け取り済み）

UIからは見えないので、ここは“画面の目的”から逆算すると作りやすいです。

手順5 条件の掛け合わせを作るコツ

掛け合わせは、全部を作ろうとすると破綻します。
実務では、次の順で絞ると回ります。

• 結果が変わる条件だけを拾う（結果が同じなら作らない）
• 事故の実害が大きい条件を優先する（課金、報酬、進行不可）
• 過去に壊れた条件を優先する（既知の地雷は強い）

掛け合わせは“最後のひと押し”です。
表示・動作・ロジックの土台ができてから作ると、意味のある条件だけが残ります。

コピペで使える レギュラー観点テンプレ

この見出しでわかること：レギュラー観点を表にして、毎回同じ型で埋められます。

テンプレは「画面 × UI」の粒度で作ると、現場で使いやすいです。
まずはこの形をコピペして、1画面だけでいいので埋めてみてください。

観点テンプレ

そのまま貼って使える表テンプレは以下。

画面	UI	表示	動作	ロジック	条件の掛け合わせ	メモ
		文言／桁／収まり／状態表示	押下可否／遷移／連打／通信中	増減／判定／保存／履歴	ユーザー状態／所持状況／通信／端末／時間

「どこから埋めればいいか迷う」ときは、UI要素を先に埋めてから、表示→動作→ロジック→掛け合わせの順で横に埋めるのが早いです。

そのままテストケースに落とすときの注意点

このテンプレは“観点の棚卸し”なので、ここからテストケースに落とすときは、次の点だけ意識すると事故が減ります。

• 1観点＝1ケースにしない：まずは同じ前提条件のものをまとめる
• 期待結果を必ず言語化する：OKの条件が曖昧だとレビューで詰まる
• 条件の掛け合わせは優先順位をつける：全部やらず、実害が大きい順に並べる

テストケースの作り方や、テンプレから落とす具体手順は、こちらにまとまっています。
→テストケースの作り方とテンプレはこちら

具体例 ガチャ画面で観点を作る

この見出しでわかること：実際の画面を想定して、4分類で観点が増える感覚を掴めます。

ここでは例として、ガチャ画面を想定します。
「提供割合」「所持通貨」「10連ボタン」「確認ポップアップ」「結果演出」「履歴」といったよくある画面構成を例とします。

表示観点の例

ガチャ画面での表示観点を、具体的に列挙します。

• ガチャ名、開催期間、注意事項の文言が正しい
• 通貨の所持数の桁区切り・単位・上限表記が正しい
• 10連の価格表示が、1回価格×10と一致している
• 提供割合の表示が崩れていない（折り返し、スクロール、はみ出し）
• 確認ポップアップの文言が、実際に消費される通貨・回数と一致している
• 結果画面で、レア度表示やアイコン欠けがない

表示観点は「文言・桁・収まり・状態」を各箇所に漏れなくあてはめるだけで、かなりの要素が拾えます。

動作観点の例

ガチャ画面での動作観点を、具体的に列挙します。

• 1回／10連ボタンが、所持通貨不足で押せない（押せない表示も正しい）
• 連打しても二重購入にならない（通信中の入力制御）
• 確認ポップアップでキャンセルした場合、消費されない
• 結果演出中のスキップ操作の可否が仕様どおり
• 演出後に戻る／再抽選の導線が仕様どおり
• 通信エラー時にリトライでき、状態が壊れない

動作観点は「押下可否」「連打」「通信中」「戻る」の4点を入れると強くなります。

ロジック観点の例

ガチャ画面でのロジック観点を、具体的に列挙します。

• 抽選後、所持通貨が正しく減る（端数やチケット優先消費の仕様があれば確認）
• 付与されたアイテムが正しく所持に反映される（上限時の扱い含む）
• 履歴に正しく残る（時間、内容、回数）
• 初回無料や割引がある場合、適用条件と計算が正しい
• ボーナス付与（おまけ、天井カウント）がある場合、判定が正しい
• 再起動後も結果・所持・履歴の整合性が保たれる

見た目上は問題がないように見えても、実は表示と内部データでズレが生じているケースもあります。ユーザー影響が大きいので、ロジック観点は必ず入れます。

条件掛け合わせの例

掛け合わせは、実害が大きい順で作ります。

• 所持通貨：ちょうど足りる／1不足／上限付近
• ユーザー状態：初回無料対象／対象外
• 通信：抽選確定直前で瞬断→復帰（二重消費や二重付与の芽）
• 時間：終了直前に実行→終了跨ぎ（提供内容や表示の整合性）
• 所持上限：付与で上限超え（溢れ分の扱い）

ここまで作れれば、ガチャ画面のレギュラー観点はかなり堅くなります。

漏れやすいポイントだけ先に潰す

この見出しでわかること：時間がない現場でも、致命傷になりやすい漏れを先回りできます。

観点を増やそうとしても、納期が近いと全部は見きれません。
そんなときは、バグが混ざりやすい“型”だけ先に潰すのが現実的です。ここではレギュラー観点の中でも、特に漏れやすいポイントに絞ります。

文言と桁と収まり

表示で一番多いのは、次の3つです。

• 文言：誤字、表記ゆれ、句読点、機種依存文字
• 桁：単位、端数処理、桁区切り、上限表記
• 収まり：折り返し、はみ出し、重なり、極端に長い名前

確認のコツは「長い文言」「大きい数字」「最小画面」を意識して当てることです。
普段の条件だけ見ていると、ここは抜けます。

活性非活性と遷移先の分岐

ボタン等の動作で漏れやすいのは、「押せる前提」でテストしてしまうことです。
「押せない状態」があることも観点にしないとバグの取りこぼしが起きやすいです。

• 条件未達でボタンが押せない（表示と理由が正しいか）
• 押せないはずなのに押せる（誤って進める）
• 同じボタンでも条件で遷移先が分岐する（Aなら詳細、Bなら購入など）
• 戻るで前の画面に戻ったとき、状態が保持される／されないの仕様

遷移は「行けたか」より、「どの条件でどこへ行くか」を観点にすると強くなります。

時限とマスタと例外パターン

ゲームや運用アプリは、時間とデータ更新で壊れやすいです。
次の3つは、掛け合わせの代表として入れておくと効きます。

• 時限：日付跨ぎ、開始直後、終了直前、メンテ前後
• マスタ：文言や報酬の差し替え、提供割合の更新、対象フラグの変更
• 例外：所持上限、在庫なし、対象外、すでに受け取り済み

よくある質問として、「毎回ここまで見るべき？」と迷います。
答えはシンプルで、“毎回全部”ではありません。実害が大きい画面（課金、報酬、進行）ほど、時限・マスタ・例外を優先して入れるのが安全です。

次に覚えるべき観点はイレギュラー観点

この見出しでわかること：レギュラー観点を固めた次に、何を伸ばせばいいかがわかります。

レギュラー観点が安定してくると、次に壁になるのは「想定外の動き」です。
ここから先は、日常の操作だけでは拾えないバグ（例外操作、変則手順、想定外入力など）を扱います。

イレギュラー観点に進む前に押さえること

イレギュラー観点に進む前の準備として、まずは次を確認してください。

• 4分類（表示・動作・ロジック・掛け合わせ）で、毎回観点が出せる
• テンプレが手元にあり、画面ごとに埋められる
• 掛け合わせを“実害が大きい順”で絞れる

この3つが揃っていると、イレギュラー観点が単なる思いつきではなく、再現性のある武器になります。

次はイレギュラー観点を確認する

次のステップは、こちらで確認できます。
→次はイレギュラー観点を確認する

デバッグ経験を年収アップにつなげる

観点を作れるようになると、作業スピードが上がるだけでは終わりません。
「漏れにくい」「説明できる」「再現性がある」という形で、周りから見える成果になります。

この記事の内容を、年収アップの道筋に繋げて整理したいなら、最初にこちらを読むのが早いです。
→デバッグ経験1年から年収500万を狙うロードマップ

観点が作れると評価されやすい理由

現場で評価されやすいのは、次の動きができる人です。

• 「何を見たか」を言語化して共有できる
• レビューで突っ込まれても、基準を説明できる
• 属人化せず、テンプレで再現できる
• 掛け合わせを絞って、優先順位をつけられる

観点が作れる状態は、単にチェック項目が多い人ではなく、「品質を設計できる人」に近づきます。
だから、同じ年数でも評価が分かれやすいです。

年収400〜500万円を狙うロードマップへ

次の行動を具体化したい場合は、ロードマップを先に見ておくと迷いが減ります。
→デバッグ経験1年から年収500万を狙うロードマップ

一つの現場で頑張っている人ほど、「作業は増えるのに評価が伸びない」状態になりがちです。
「評価される型」を身につけ、努力が報われる働き方へシフトしましょう。