チェックリストの作り方

デバッグシートの作り方|スプレッドシートでチェックシートを作る手順とテンプレ

デバッグシートの作り方|スプレッドシートでチェックシートを作る手順とテンプレ

※本記事にはPR(アフィリエイトリンク)を含みます。
著者:転すけ(元デバッグバイト / 現ITフリーランス) | プロフィール
紹介サービスは編集方針に基づき、読者の参考になる観点で選定しています。

デバッグ(QA)業務に少し慣れてくると、次のステップとして「チェックシート(テスト仕様書)の作成」を任される機会が増えてくると思います。

しかし、いざ初めて作成しようとすると「全く何から手をつければいいのかわからない」と途方に暮れてしまう方も少なくありません。その主な原因は、大きく以下の3点にあると考えられます。

  • ツールの操作不安:Excelやスプレッドシートの関数・機能がわからず、単純入力しかできない。
  • 構成の基準が不明:そもそも「何が含まれていればチェックシートとして成立するのか」がわからない。
  • 共有ルールの欠如:社内・社外へ共有する際の設定や運用ルールがわからない。

これらの点が曖昧なまま自己流で進めてしまうと、大幅な作り直しが発生したり、最悪の場合は現場で使い物にならないシートになってしまったりするリスクがあります。

そこでこの記事では、必要最小限の項目だけで運用できる、シンプルなデバッグシートのテンプレートを最初に配布します。

まずは土台を手に入れ、そのあとに「入力ミスを減らす設定(プルダウン・条件付き書式)」や「チーム共有時のトラブルを防ぐ権限設定」を加えて仕上げていきましょう。

「まずは型を作る → ミスを減らす工夫をする → 安全に共有する」。この順序で進めれば、明日からの作成業務で迷うことはなくなります。

結論 デバッグで必要なスプレッドシートはこれだけ

この見出しでわかること:最小構成の列と、最低限覚えるスプレッドシート操作がわかります。

スプレッドシートで作成したデバッグシートの完成例

デバッグシートで最低限必要な列

デバッグシートは凝り始めると列が増えます。最初は、次の6列で十分回ります。
大事なのは「誰が見ても同じ判断で埋められる」形に寄せることです。

No:1、2、3…の連番(後で参照しやすい)

カテゴリ:どの画面・機能か(例:ログイン、課金、バトル、設定)

確認項目:何をするか(操作と期待結果がセットになっていると強い)

期待結果:正しい状態(できれば一文で)

結果:OK / NG / 未実施(この3つに揃える)

メモ:補足(再現手順の断片、端末、バージョン、スクショ有無など)

実務では、ここに「担当」「優先度」「環境」「ビルド番号」などが足されます。
初期段階で全部入れるより、まず6列で回し、必要になった列だけ増やす方が崩れません。

まず覚える操作 入力 罫線 プルダウン 条件付き書式 共有

スプレッドシートで最初に覚える操作は、実は難しくありません。
「入力しやすい形」「ミスしにくい形」「他の人と一緒に使える形」を作るために、次の5つだけ押さえればOKです。

入力:セルに入力、コピー、オートフィル(同じ形式を増やす)

罫線:表として崩れないように枠線を付ける

プルダウン:結果欄を選択式にして表記ゆれを消す

条件付き書式:OK/NGを色で見分けられるようにする

共有:閲覧だけ/コメント可/編集可の違いを理解する

このあと、テンプレをコピペしてから、上の操作を順番に当てていきます。

コピペで作れるデバッグシートのテンプレ

この見出しでわかること:最小テンプレをそのまま貼って使える形にし、結果欄のルールと、項目の考え方がわかります。

デバッグシートの列構成テンプレ(No、画面、手順、期待結果、結果、備考)

最小テンプレの列構成(コピペOK)

まずは「完成度60点でいいので、運用できる形」を作ります。
下のテンプレを、スプレッドシートのA1セルから貼り付けてください(あとで列幅や罫線を整えます)。

Noカテゴリ確認項目期待結果結果メモ
1ログインID/パスを入力してログインするホームが表示される未実施
2ログイン誤ったパスワードでログインするエラーメッセージが表示される未実施
3設定BGM音量を変更する音量が反映される未実施
4設定アプリを再起動する前回の設定が保持される未実施

貼り付けた瞬間から、もう“土台”はできています。
次にやるのは、結果欄のルールを固定して、シートが荒れないようにすることです。


テンプレ提示の直後に、関連する作り方もあわせて確認できます。
QAデバッグのチェックリストの作り方とテンプレ

結果欄のルール例 OK NG 未実施

結果欄は、チーム運用で一番崩れやすい場所です。
最初から次の3つに固定しておくと、集計や確認が楽になります。

OK:期待結果どおり

NG:期待結果どおりにならない(不具合の可能性)

未実施:まだ確認していない/保留

「要確認」「たぶんOK」「微妙」などが混ざると、あとから見返す人が困ります。
迷ったら、いったん 未実施 にしてメモ欄に状況を書き、後で判断する運用が安全です。

もう1つ、効果的なルールがあります。
NGのときはメモ欄に“再現手順の断片”を残すことです。全部書き切らなくて大丈夫です。

  • どの画面から
  • 何を押して
  • 何が起きたか
  • 端末やOS(ビルド番号が分かればそれも記載)

尚、不具合報告のまとめ方については以下を参考にしてください。
不具合報告の書き方テンプレ

項目が思いつかないときの考え方

チェック項目が思いつかないときは、センスの問題ではなく「切り口」を知らないだけのことが多いです。
ここでは要点だけ押さえます。具体例つきの練習は次の記事で確認できます。

よく使う切り口は、次の3つです。

  • 基本動作:正常系(普通に使ったらどうなるか)
  • 境界:上限/下限、空欄、最大文字数、0、1、9999みたいな境目
  • 例外:通信切断、アプリ再起動、権限不足、ログイン切れ

ゲームなら、ここに「長時間プレイ」「端末差」「フレームレート」「バックグラウンド復帰」などが乗ります。
最初から全部入れず、まずは基本動作+境界だけで十分です。

尚、観点の出し方の基本を整理したい場合はこちらにまとめています。
テスト観点の洗い出し入門(初心者向け)

5分で完成する作成手順

この見出しでわかること:テンプレを貼ったシートを、見やすく・使いやすく整える手順がわかります。

スプレッドシートを開く

Googleスプレッドシートを開き、新しいシートを作ります。
ファイル名は、後で探しやすい名前にしておくと便利です。

例:プロジェクト名_デバッグシート_YYYYMMDD

例:アプリ名_回帰テスト_チェックシート

テンプレを貼るだけでも使えますが、次の整形を入れると“現場で使える感”が一気に上がります。

ヘッダーを入れて列幅と罫線を整える

まず、1行目(ヘッダー行)を固定します。
スクロールしても項目が見える状態だと、入力ミスが減ります。

表の1行目を選択
表示メニューから固定(上部に固定)を設定

次に、列幅を整えます。目安は↓こんなイメージ↓です。

No:狭め

カテゴリ:短め

確認項目:広め

期待結果:広め

結果:狭め

メモ:広め

最後に罫線です。
外枠と内側の線が入っているだけで、「表」としての完成度が上がり、共有したときも読みやすくなります。

連番を自動で振る(ROW関数の最小だけ)

No列を手入力で増やしていくと、途中で抜けたりズレたりしがちです。
ここは ROW関数(行番号を返す関数) で自動化しておくと楽です。

やり方はシンプルです。

A2セル(Noの最初のデータ行)に数式を入れる

下にコピーして増やす

A2セルに入れる例:
=ROW()-1

この式は「行番号から1を引く」ので、A2なら1、A3なら2…と連番になります。
ヘッダーが1行目で、データが2行目から始まる構成と相性がいいです。

もっと凝った連番(途中に空行があっても詰めたい等)は、現場で必要になったらで大丈夫です。
まずは最小のROW関数だけ覚えるのが、挫折しないコツです。

見やすくする色と文字設定

見やすさは「凝ったデザイン」ではなく「迷わない配置」を意識します。
最初にやると効果が大きい設定だけに絞ります。

・ヘッダー行を薄いグレーで塗る

・ヘッダーの文字を太字にする

・文字は基本11〜12ptで統一する

・行の高さを少し広げる(詰まりすぎを防ぐ)

・折り返し表示(確認項目・期待結果・メモ)をONにする

この状態で、デバッグ担当が増えても崩れにくくなります。

入力ミスが減る設定

この見出しでわかること:結果欄を選択式にし、OK/NGが色で見える状態にできます。

スプレッドシートで結果欄をプルダウンにする設定画面

結果欄をプルダウンにする

結果欄が手入力だと、「OK」「ok」「〇」「問題なし」みたいに表記が割れます。
これが起きると、集計や確認が一気に面倒になります。

ここは プルダウン(選択肢から選べる入力) にして、最初から揺れを消します。

手順のイメージは次の通りです。

・結果列(例:E列)の入力範囲を選択(E2〜E1000など)

・データの入力規則で、選択肢を追加

・「OK」「NG」「未実施」を登録

・保存

運用上のポイントがあります。
選択肢は増やしすぎない方が良いです。迷いが生まれて入力が止まります。
最初は3つ固定でOKです。

OKとNGで色が変わるようにする

条件付き書式でOKとNGを色分けする設定画面

プルダウンにしたら、次は視認性を上げます。
一覧で見たときに、NGが埋もれない状態にするのが目的です。

条件付き書式(条件に合うセルの見た目を変える機能) を使って、次のルールを入れます。

結果が「OK」なら背景を薄い緑

結果が「NG」なら背景を薄い赤

結果が「未実施」なら背景を薄いグレー(任意)

これだけで、視認性が向上し確認がかなり早くなります。
「NGだけフィルタして見る」運用にもつながるので、チーム規模が大きくなるほど効きます。

経験者はまず相談:Midworks

対象:デバッグ/QA 実務1年以上|まず条件・単価の相場を知りたい人

※無料相談/オンラインOK

未経験・経歴に不安があるなら
将来への不安を解消し、未経験から安定した環境への就職を目指す相談イメージ

対象:「ホワイト企業」厳選。まずは適職相談から始めたい人

※無料相談/オンラインOK

チームで使うための共有設定

この見出しでわかること:共有の手順と、権限の選び方の考え方がわかります。

スプレッドシートの共有設定と権限(閲覧・コメント・編集)の選び方

共有の手順

個人で作ったデバッグシートをチームで回すなら、共有は避けて通れません。
手順は次の流れです。

・スプレッドシート右上の「共有」を開く

・共有したい相手(メール)を追加、またはリンク共有をONにする

・権限(閲覧者/コメント可/編集者)を選ぶ

・送信またはリンクを共有する

ここで迷うのが「リンク共有をONにしていいのか」です。
プロジェクトのルール次第ですが、外部に漏れるリスクがある環境では、まずメール指定で共有する方が無難です。

権限はどれを選ぶべきか

権限選びは、正解が1つというより「事故が起きにくい設計」を選ぶ話になります。
おすすめの考え方は次の通りです。

・入力担当が複数いる:基本は「編集者」

・レビュー担当は入力しない:レビュー担当は「閲覧者」または「コメント可」

・テンプレを守りたい:列やルールを変えられる人を絞る(編集者を最小限に)

特に「列を増やした」「プルダウンを消した」「条件付き書式を壊した」などは、あるあるの事故です。
運用が落ち着くまでは、編集できる人を絞り、他はコメント可にするだけでも崩れにくくなります。

集計や進捗率まで作りたい人へ

この見出しでわかること:このページの範囲と、次に何ができるようになるかがわかります。

できるようになること

最小テンプレが安定して回るようになると、「どれくらい終わったか」「NGが何件か」を見える化したくなります。
そこで次のような集計に進めます。

・OK/NG/未実施の件数集計

・カテゴリ別の残件数

・進捗率(%)の表示

・フィルタやピボットでの簡易ダッシュボード

ここまで作ると、リーダーやPMに状況を伝えるのが楽になります。

具体例つきで確認する

進捗率や集計の具体例は、手順と例をまとめたページで確認できます。

スプレッドシートで進捗率や集計を作る方法

よくある質問

この見出しでわかること:エクセル対応・未経験の到達点・実務で求められるレベルがわかります。

エクセルでも同じように作れるか

基本的に同じ使い方が可能です。
プルダウン、条件付き書式、フィルタ、固定などもExcel側に機能があります。

デバッグ業務はチームで同時編集を行う場面が多いため、リアルタイム更新が得意なGoogleスプレッドシートが相性が良いとされています。

一方で、案件によっては機密保持の観点から「オンラインツールの利用NG」といった制約があり、Excelでの運用が必須となるケースも少なくありません。

ですが、今回解説するシート作成のノウハウや関数スキルは、Excelを使う現場でも問題なく応用可能です。どちらの環境でも通用するスキルとして身につけておきましょう。

未経験でもここまでできれば十分

未経験や経験が浅い段階では、機能満載の「立派なシート」を目指すよりも、「迷わず確実に埋められるシート」を作れる方が現場では重宝されます。

このページで紹介する最小構成が作れれば、自然と以下のメリットが生まれます。

表記が統一される(OK / NG / 未実施 が揃う)

異常に気づける(NG箇所が色で可視化される)

共有がスムーズ(適切な権限設定で事故を防ぐ)

拡張しやすい(列がシンプルなので崩れにくい)

実は、こうした「チーム全体がミスなく使える仕組み」を想像できるかどうかが、実力を見極めるポイントになります。
そのため、面接や現場においても、単に複雑な関数を知っている人より、
「どうすれば運用が崩れないか(リスク回避)を理解している人」の方が高く評価される傾向にあります。

実務ではどこまで求められる

現場によって差はありますが、最初に求められる品質は、意外とシンプルな以下の3点です。

表記揺れがない(入力ルールや結果の書き方が統一されている)

状況が追える(誰が見返しても内容や進捗が分かる)

安全に回せる(最低限の権限設定・共有ルールがある)

最初から高度な集計やマクロが求められるケースは多くありません。 難しい機能は最初から盛り込まず、「必要になったらその都度作る」というスタンスで十分間に合います。

まとめ

この見出しでわかること:今日やることが整理でき、次の行動につなげられます。

デバッグシートは「完璧に作ること」より「崩れない運用」に価値があります。
最初は6列の最小テンプレで回し、結果欄をプルダウン化し、条件付き書式でOK/NGが見える状態にする。
最後に、共有の権限を整理して、チームでも同じルールで埋められるようにする。
ここまでできれば、現場で困る場面がかなり減ります。

経験者は案件比較:Midworks

対象:デバッグ/QA 実務1年以上|案件を比較して単価・条件を上げたい人

※無料相談/オンラインOK(条件面の相談は面談で確認)

未経験からホワイト企業へ:Tamesy
一般には公開されていない未経験可の優良求人や特別枠情報の紹介イメージ

対象:厳しい基準で「ホワイト企業」を厳選。未経験OKの優良求人だけを紹介

※無料相談/オンラインOK(紹介可否は面談で確認)

年収を上げる動き方まで、全体像を先に掴んでおくと判断が早くなります。
年収400〜500万円を狙うロードマップ

関連記事