課題管理表のテンプレート｜QA表で確認事項を漏らさない

テスト中の質問や懸念、決定事項を漏らさないには、課題管理表のテンプレートを1つ決めておくのが近道です。テストを進めると、バグとは呼べない「確認したいこと」が次々に出てくるからです。仕様書にない挙動、判断を保留した画面、クライアントの返事待ちの項目などです。

こうした確認事項は、チャットや打ち合わせの口頭で処理されがちです。その結果、リリース直前に「あの件、結局どうなりましたか」が噴き出します。

この記事では、テスト期間中の確認事項を管理する課題管理表（QA表）の作り方を紹介します。列項目と記入例、区分とステータスの定義、回答期限やクローズ条件の決め方まで、そのまま現場に持ち込める形で整理しました。

なお、このサイトでは「QA」を品質保証の意味でも使います。本記事で扱うのは質問と回答を管理するQA表（質疑応答表）のことで、課題管理表とほぼ同じ意味で使っています。

テスト期間に確認事項が漏れる3つの場面

確認事項が漏れるのは、担当者の注意力が足りないからではありません。多くの場合、記録する場所が決まっていないことが原因です。

テスト期間中に確認事項が発生する場面は、大きく3つに分かれます。

場面	典型的な状況	放置すると起きること
仕様の曖昧さ	仕様書に記載がない、または解釈が2通りある	テスト担当が独自解釈で合否を付ける
テスト中の判断保留	期待結果を決めきれず、テストを「保留」にする	保留のまま最終週を迎え、消化が間に合わない
クライアント確認待ち	業務ルールや表示文言の確認を依頼した	回答が来ないまま、誰も催促しない

仕様の曖昧さは「書かれていないこと」から生まれる

仕様書は、正常な流れを中心に書かれます。異常系や境界の扱いは、書かれていないことが珍しくありません。

たとえば「検索結果は新しい順に表示する」とだけ書かれていたとします。同じ日時のデータが複数あったときの並び順は、仕様書のどこにも書かれていません。

テスト担当は、ここで判断を迫られます。開発者に聞けば、実装済みの挙動が「正しい」と返ってくることもあります。しかし、それがクライアントの期待と一致しているかは別の問題です。

判断保留とクライアント確認待ちは「ボールの所在」が見えなくなる

判断保留とクライアント確認待ちに共通するのは、次に誰が動くのかが見えなくなることです。

• 質問を投げた本人は「回答を待っている」と思っている
• クライアント側は「社内で検討中」のまま忘れている
• PMは「テスト担当が追いかけている」と思っている

三者が全員「誰かが持っている」と考えている状態が、最も危険です。確認事項は、記録されていないものから順に消えていきます。

この状態を解消する手段が課題管理表です。ITプロジェクト全般で起きる情報の行き違いについては、コミュニケーションロスの原因と対策を整理した記事もあわせて確認してみてください。

そのまま使える課題管理表のテンプレート（列項目と記入例）

ここからが本題です。テスト期間中の確認事項を管理するための列項目を、必須と任意に分けて示します。

列は多ければ良いわけではありません。最初は必須列だけで始め、運用しながら任意列を足すのが続けるコツです。

起票時に埋める列

起票者が、質問を書いた時点で埋める列です。ここが空欄のまま起票を認めると、後から誰も埋めません。

列名	必須	書く内容	記入例
No	必須	通し番号。区分の頭文字を付けると検索しやすい	Q-012
起票日	必須	起票した日付	10/14
起票者	必須	質問を書いた人の名前	テスト担当A
区分	必須	質問／懸念／決定／リスクのいずれか	質問
件名	必須	一覧で見て内容が分かる短い題	同一日時データの並び順
内容	必須	何が分からず、何を決めてほしいのか	同一日時の場合の表示順が未定義。ID順でよいか
関連画面・機能	必須	画面名または機能名	検索結果一覧
根拠資料	任意	参照した仕様書の章や版	画面仕様書 v1.3 4.2節
影響範囲	必須	回答次第で影響を受けるテストや画面	検索系テストケース約20件
優先度	必須	高／中／低（定義は後述）	中
回答者	必須	回答してほしい人。個人名まで書く	クライアント担当B
依頼日	必須	回答者に依頼した日。期限の起点になる	10/14
回答期限	必須	いつまでに回答がほしいか	10/17

特に重要なのは「内容」の書き方です。質問は「何が分からないか」だけでなく、「何を決めてほしいか」まで書くと回答が速くなります。

「並び順はどうなっていますか」と聞くと、相手は調べるところから始めます。「ID順でよいですか」と選択肢を添えると、相手は判断するだけで済みます。

回答・クローズで埋まる列

回答が返ってきてから埋まる列です。ここを埋める責任者を決めておかないと、回答はチャットに残ったまま表に転記されません。

列名	必須	書く内容	記入例
回答	必須	回答の要旨。原文の所在も書く	ID昇順で可（10/16 定例で口頭回答、議事録に記載）
回答日	必須	回答を受け取った日	10/16
対応方針	必須	回答を受けて何をするか	期待結果を確定し、テストケースを更新
反映先	必須	回答を書き戻した資料	画面仕様書 v1.4、テストケース TC-0412〜0431
ステータス	必須	定義は後述	クローズ
クローズ日	必須	クローズした日	10/17
クローズ確認者	任意	クローズ条件を確認した人	PM
備考	任意	経緯や関連No	関連：Q-008

「反映先」は見落とされやすい列です。回答を表に書いただけでは、仕様書もテストケースも古いままです。次の改修で同じ質問がまた出てきます。

テスト仕様書側の列設計や、期待結果の書き方はシステムテスト仕様書テンプレートの記入例で詳しく扱っています。回答を書き戻す先として、あわせて整えておくと効果が上がります。

記入例：区分ごとの1行

実際に埋めた状態をイメージできるよう、区分ごとに1行ずつ記入例を示します。列は主要なものに絞っています。

No	区分	件名	内容	回答者	回答期限	ステータス
Q-012	質問	同一日時データの並び順	同一日時の表示順が未定義。ID順でよいか	クライアント担当B	10/17	クローズ
K-003	懸念	パスワード再設定メールの有効期限	仕様に期限の記載がない。無期限だと安全上の懸念がある	開発リーダーC	10/18	回答待ち（社内）
D-005	決定	タブレット横向きの扱い	横向き表示は今回の対象外とすることで合意	クライアント担当B	該当なし	クローズ
R-002	リスク	外部決済のテスト環境	環境提供が遅れると決済系テストが2日以上ずれ込む	PM	10/20	対応中

決定事項の行は、回答期限を持たないことが多くなります。その場合も空欄にせず「該当なし」と書きます。空欄は「書き忘れ」と区別できないためです。

スプレッドシートで作るときの設定

専用ツールがなくても、ExcelやGoogleスプレッドシートで十分に運用できます。1行目には、次の列名をそのまま貼り付けて使ってください。

No,起票日,起票者,区分,件名,内容,関連画面・機能,根拠資料,影響範囲,優先度,回答者,依頼日,回答期限,回答,回答日,対応方針,反映先,ステータス,クローズ日,クローズ確認者,備考

貼り付けた後に「テキストを列に分割」などの機能で、区切り文字にカンマを指定すると列に分かれます。

列を作ったら、次の4つの設定を入れておくと入力の揺れと見落としが減ります。

• 入力規則（プルダウン）：区分・優先度・ステータスは選択式にして、自由入力をさせない
• 条件付き書式：回答期限が今日より前で、ステータスがクローズ以外の行を赤くする
• 経過日数の列：依頼日から今日までの日数を計算式で出し、滞留を数字で見えるようにする
• フィルタ：ステータスと回答者で絞り込めるよう、見出し行にフィルタを設定する

期限超過の行が自動で色付くだけで、催促の漏れは目に見えて減ります。人の注意力に頼らず、表の側で気づける仕組みにしておくのがポイントです。

区分の決め方：質問・懸念・決定・リスクを分ける

課題管理表に入れるものは、すべてが「質問」ではありません。区分を分けておくと、定例で何から話すべきかがすぐに分かります。

4つの区分の定義とクローズ条件

区分ごとに、起票のきっかけとクローズ条件が異なります。次の表を、プロジェクトの最初に関係者と共有しておくと運用がぶれません。

区分	定義	起票のきっかけ	クローズ条件
質問	答えがあれば解消する不明点	仕様書に記載がない、解釈が割れる	回答を受け取り、反映先に書き戻した
懸念	仕様どおりでも問題が起きそうな点	使い勝手や安全面で引っかかる	対応する／しないの判断が記録された
決定	合意した内容の記録	打ち合わせやチャットで結論が出た	合意者と日付を記録した時点で即クローズ
リスク	将来起きうるテスト進行上の問題	環境・データ・人員の遅れが見えた	発生しなかった、または対策を実施した

「懸念」と「質問」の違いは、答えの有無です。質問は正解があり、聞けば解消します。懸念は正解がなく、誰かが「対応する／しない」を判断する必要があります。

懸念は「回答」ではなく「判断」でクローズすると決めておくと、宙に浮いた行が減ります。

何を起票するかの判断基準

すべての疑問を起票すると、表が膨らんで誰も読まなくなります。逆に絞りすぎると、口頭で済ませた内容が消えます。

次のいずれかに当てはまるものは、起票します。

• テストの合否判定に影響する
• 回答者がテストチームの外にいる（クライアント、他チーム、外部ベンダー）
• 回答に1営業日以上かかりそう
• 同じ質問が2人以上から出た
• 結論が仕様書やテストケースの変更を伴う

反対に、次のようなものは起票しなくて構いません。

• 隣の席の開発者に聞けばその場で解決し、仕様変更を伴わない
• 誤字脱字など、明らかな記載ミスの指摘（レビュー指摘として別に扱う）
• 再現する不具合（不具合管理表へ）

迷ったら起票する、が原則です。起票して「起票不要だった」と取り下げるコストは、記録がなくて揉めるコストよりずっと小さいからです。

「決定」を記録する習慣が後の揉め事を防ぐ

4区分のうち、最も軽視されるのが「決定」です。質問が出ていないので、表に書く必要を感じないからです。

しかし、受託開発で後から問題になるのは、多くが「言った・言わない」です。打ち合わせで「その画面は今回対象外でいいですよ」と言われた内容は、記録しなければ合意になりません。

決定を記録するときは、次の3点を必ず残します。

1. 何を決めたか（対象と範囲）
2. 誰が合意したか（クライアント側の名前まで）
3. いつ、どの場で決めたか（議事録やチャットの所在）

ステータス定義と運用ルール

列と区分が決まったら、次はステータスです。課題管理表のステータスは、不具合管理表よりも「待ち」の状態が多くなります。回答者がテストチームの外にいることが多いためです。

ステータスの定義

ステータスは、次に誰が動くかが読める名前にします。「確認中」「検討中」のような名前は、誰が確認しているのかが分かりません。

ステータス	意味	次に動く人	次のステータス
起票	登録直後、回答者への依頼前	PM（内容確認と回答者の割り当て）	回答待ち（顧客／社内）
回答待ち（顧客）	クライアントに回答を依頼済み	クライアント	回答済（確認待ち）
回答待ち（社内）	開発チームや社内の判断待ち	開発リーダーまたはPM	回答済（確認待ち）
回答済（確認待ち）	回答を受け取り、起票者の確認前	起票者	反映待ち／再質問
再質問	回答が不十分で追加確認が必要	起票者（追記して再依頼）	回答待ち（顧客／社内）
反映待ち	回答は確定、資料への書き戻し前	反映担当者	クローズ
クローズ	クローズ条件を満たした	該当なし	該当なし
取り下げ	起票不要と判明した	該当なし（理由を備考に記載）	該当なし

「回答待ち」を顧客と社内に分けているのがポイントです。定例でクライアントに確認すべき行だけを、フィルタ1回で抜き出せます。

ステータスを「回答待ち（顧客）」で絞り込めば、それがそのまま定例のアジェンダになります。

優先度と回答期限の決め方

回答期限は、起票者の希望だけで決めると全行が「至急」になります。優先度ごとに標準の期限を決めておき、例外だけを個別に交渉するのが現実的です。

以下は、テスト期間が数週間程度の案件を想定した目安です。案件の期間や定例の頻度に合わせて調整してください。

優先度	判断基準	標準の回答期限（目安）	期限超過時の扱い
高	回答がないとテストが止まる、または広範囲に影響する	起票から1〜2営業日	当日中にPMから先方の責任者へ連絡
中	一部のテストを後回しにすれば進められる	起票から3〜5営業日、または次回定例	定例で口頭確認し、その場で期限を再設定
低	合否判定には影響しないが、記録として確定したい	テスト期間の終了前まで	最終週の棚卸しで一括確認

期限の起点は「起票日」ではなく「回答者に依頼した日」にします。起票から依頼までに時間が空くと、回答者にとって理不尽な期限になるためです。

期限超過時のエスカレーション

期限を過ぎた行を放置すると、期限という列自体が形骸化します。超過したときの動きを、あらかじめ段階で決めておきます。

1. 期限当日：起票者が回答者に個別に催促する（チャットで可）
2. 超過1営業日：PMが定例または個別連絡で、先方の窓口に状況を確認する
3. 超過3営業日：先方の責任者を含めて、仮置きで進めるかを判断してもらう
4. 判断が出ない場合：未確定のまま進めた範囲を、テスト結果報告書に明記する

ここで重要なのは、段階3の「仮置き」です。回答を待ち続けるより、「回答がない場合は〇〇として進める」と決めてテストを進めた方が、全体の遅れは小さくなります。

クローズ条件を明文化する

「回答が来たらクローズ」にすると、回答が仕様書に反映されないまま行が閉じます。クローズは、次の3つがそろった時点とします。

• 回答者からの回答が記録されている（原文の所在を含む）
• 起票者が回答を確認し、追加の質問がないと判断した
• 「反映先」列に、書き戻した資料名と版が記載されている

決定区分だけは例外で、合意者と日付が記録された時点でクローズします。取り下げは、理由が備考に書かれていればクローズ扱いとします。

クライアントと最初に合意しておく5つのこと

課題管理表は、テストチームだけで運用しても機能しません。回答者の多くはクライアント側にいるからです。テスト開始前のキックオフで、次の5点を合意しておきます。

合意事項	決める内容	合意しないと起きること
窓口	質問を受ける担当者と、その代理	質問が担当者不在で止まる
回答期限	優先度ごとの標準期限	全件が「確認します」のまま止まる
回答の形式	表への記入、またはチャットで回答し転記	口頭回答だけが残り、記録が抜ける
確認の場	定例の頻度と、表を見る時間の確保	表が誰にも見られなくなる
仮置きの扱い	期限超過時に仮置きで進めてよいか	回答待ちのままテストが止まる

回答期限の合意は「お願い」ではなく「段取り」として伝える

回答期限を先方に求めるのは、言い出しにくいものです。「お忙しいところ恐縮ですが」と遠慮すると、期限は守られなくなります。

伝え方のコツは、期限をテストの段取りとして説明することです。たとえば次のように伝えます。

• 「優先度が高い質問は、回答をいただけないとその機能のテストを止めることになります」
• 「そのため、高優先度は2営業日以内を目安にご回答いただけると、全体の日程を守れます」
• 「期限内に難しい場合は、仮の方針だけでも先にいただければ進めます」

期限の根拠がテスト日程にあると分かれば、先方も社内で優先順位を付けやすくなります。回答期限は、クライアントを急かすためではなく日程を守るための共通ルールとして合意します。

仮置きの合意は書面で残す

仮置きで進めたテストは、後から回答が変わると手戻りになります。それでも、止まるよりは進めた方が損失は小さいことがほとんどです。

ただし、仮置きの合意は必ず記録します。課題管理表の「決定」区分で、次のように1行起票しておきます。

列名	記入例
区分	決定
件名	Q-012 の仮置き方針
内容	回答期限超過のため、同一日時はID昇順として仮置きでテストを進める。回答が異なる場合は該当ケースを再実施する
合意者	クライアント担当B、PM
備考	関連：Q-012。10/18 定例で合意

こうしておけば、後で回答が変わっても再実施の範囲がすぐに分かります。「仮置きで進めた結果の手戻り」は、合意済みの作業として扱えます。

こうした合意事項は、テスト計画の段階で決めておくのが理想です。計画書に盛り込む項目の整理には、テスト計画の立て方を解説した記事が参考になります。

不具合管理表・レビュー指摘表との使い分け

課題管理表を導入すると、「これは不具合管理表に書くべきか、課題管理表に書くべきか」で迷う場面が出てきます。迷ったまま両方に書くと、片方だけ更新されて食い違います。

3つの表の役割の違い

使い分けの基本は、扱う対象が何かです。次の表で整理します。

比較項目	課題管理表（QA表）	不具合管理表	レビュー指摘表
扱う対象	確認事項・懸念・決定事項	期待結果と異なる動作	成果物の記載の誤りや不足
起票のタイミング	判断に迷った時点	テスト実行で事象を確認した時点	ドキュメントのレビュー時
主な回答者	クライアント・PM・開発リーダー	開発担当者	成果物の作成者
クローズ条件	回答・判断が記録され、資料に反映	修正後の再テストで合格	指摘箇所の修正を確認
主な読者	クライアントを含む関係者全員	開発チームとテスト担当	作成者とレビュアー
正解の有無	正解がないものも含む	期待結果という正解がある	記載基準という正解がある

不具合は「期待結果と違う」ことが分かっている状態です。一方、課題管理表に入るのは、そもそも期待結果が決まっていない状態のものです。

「仕様か不具合か分からない」ときの流れ

最も迷うのは、挙動がおかしいと感じたものの、仕様かどうか判断できないケースです。この場合は、次の流れに統一します。

1. まず課題管理表に「質問」として起票する（例：この挙動は仕様どおりですか）
2. 回答が「仕様どおり」なら、課題管理表でクローズする
3. 回答が「仕様と異なる」なら、不具合管理表に起票する
4. 課題管理表の備考に不具合のNoを、不具合管理表の備考に課題のNoを書く

1つの事象を2つの表で同時に管理しない、と決めるだけで食い違いはほぼなくなります。

不具合管理表側の列設計やステータスの考え方は、不具合管理表テンプレートの項目設計と運用ルールで詳しく解説しています。2つの表を並べて設計すると、列名や番号の付け方を揃えやすくなります。

用語の揃え方

表を分けると、同じ言葉を別の意味で使ってしまうことがあります。「課題」「障害」「インシデント」などは、人によって指す範囲が違います。

用語の定義に迷ったときは、公的な物差しを使うと関係者間の解釈を揃えやすくなります。JSTQBのテスト技術者資格の公式サイトで公開されているシラバスや、ISTQBの用語集（日本語版）が代表的です。たとえばISTQBの用語集では、テスト分析と設計の拠り所となる情報を「テストベース」と呼びます。課題管理表は、このテストベースの不足を埋める道具だと考えると位置づけが明確になります。

課題管理表でよくある失敗と回避策

最後に、課題管理表の運用でつまずきやすい失敗を整理します。特定の案件ではなく、受託開発で起きやすい典型パターンとしてまとめたものです。

失敗	起きること	回避策
1行に複数の質問を書く	片方だけ回答されてクローズされる	1行1質問を徹底し、関連は備考でつなぐ
回答がチャットにしか残らない	表を見ても結論が分からない	転記担当を決め、ステータス変更とセットで転記する
回答者が「先方」としか書かれていない	誰も自分宛てだと思わない	回答者は個人名で書く
反映先を書かずにクローズする	次の改修で同じ質問が再燃する	反映先の記載をクローズ条件にする
回答期限を空欄にする	最終週に未回答が一斉に噴き出す	優先度ごとの標準期限を自動で入れる
社内メモを顧客共有の表に書く	率直な記述が顧客の目に触れる	社内用と共有用でファイルを分ける

失敗例1：テスト最終週に未回答が噴き出す

よくあるのは、テスト開始直後から課題管理表を用意したものの、回答期限の列がないケースです。質問は起票されるだけで、誰も期限を意識しません。

テスト最終週に棚卸しをすると、未回答の質問がまとまって見つかります。その中には、回答次第でテストケースの書き直しが必要なものが混ざっています。

結果として、回答を急いでもらいながら、並行して再テストを行うことになります。リリース判定の場では、未確定の項目を「既知の制約」として説明せざるを得なくなります。

回避策は単純で、起票時に回答期限を必須にすることです。さらに、週1回の定例で「期限超過」の行だけを確認する時間を5分取ります。

失敗例2：口頭で決めた「対象外」が覆る

打ち合わせで「その機能は今回のテスト対象外でよい」と口頭で合意するのは、珍しいことではありません。ところが、議事録の片隅には残っていても、課題管理表にも仕様書にも反映されないことがあります。

リリース後にその機能で問題が見つかると、話がこじれます。クライアント側の担当者が交代していれば、「対象外にした覚えはない」と言われることもあります。

議事録を探し出して事実を示せても、信頼関係には傷が残ります。決定区分の行が1行あれば、すぐに示せた内容です。

合意は、課題管理表に「決定」として1行起票した時点で初めて記録になります。

失敗例3：表が育ちすぎて誰も見なくなる

逆のパターンもあります。列をどんどん増やし、全員が細かく記入するルールにした結果、更新が止まってしまうケースです。

入力に時間がかかると、テスト担当はチャットで質問するようになります。表は形だけ残り、実態はチャットに戻ってしまいます。

列は、本記事の必須列から始めるのがおすすめです。任意列は「後から何度も聞かれた情報」だけを追加します。

少人数で回すときの割り切り方

専任のテスト担当がいない体制では、表の更新そのものが負担になります。その場合は、役割を次のように割り切ると続けやすくなります。

作業	担当	頻度
起票	質問を思いついた人（開発者・テスト担当）	発生の都度
回答者の割り当てと依頼	PM	1日1回まとめて
回答の転記とステータス更新	PM（または当番制の1名）	1日1回まとめて
期限超過の確認	PM	週1回の定例で5分

更新を1人に寄せると、その人の負担は増えます。それでも、全員が気まぐれに更新するより表の鮮度は保たれます。

未クローズの課題はテスト結果報告書に載せる

テスト期間が終わっても、すべての行がクローズするとは限りません。未クローズの課題は、隠さずにテスト結果報告書に記載します。

• 未回答の質問と、仮置きで進めた範囲
• 対応を見送った懸念と、その判断者
• 発生の可能性が残っているリスク

未クローズ課題を一覧で示すと、リリース判定の材料として機能します。報告書の章立ては、テスト結果報告書の書き方とテンプレートを参考にしてください。

まとめ：課題管理表のテンプレートは合意とセットで使う

課題管理表は、テスト期間中に生まれる「バグではない確認事項」を漏らさないための道具です。ただし、表を用意しただけでは機能しません。

最後に、導入時に押さえるポイントを振り返ります。

• 必須列は「内容」「回答者」「回答期限」「反映先」を中心に、まず最小限で始める
• 区分は質問・懸念・決定・リスクの4つに分け、区分ごとにクローズ条件を決める
• ステータスは「次に誰が動くか」が読める名前にし、回答待ちは顧客と社内で分ける
• 回答期限と仮置きの扱いは、テスト開始前にクライアントと合意する
• 不具合管理表とは対象で使い分け、1つの事象を2つの表で同時に管理しない
• 未クローズの課題は、テスト結果報告書に明記する

課題管理表のテンプレートを配っても、それだけで運用は回りません。回答期限と仮置きのルールを関係者と合意してこそ、表は確認事項の漏れを防ぐ仕組みになります。

まずは次の案件で、必須列だけの表を作り、キックオフで回答期限の目安を共有するところから始めてみてください。

テスト期間中の確認事項の管理や、クライアントとの進め方に悩まれている方は、テスト体制の見直しについて相談することもできます。お気軽にお問い合わせください。

次に読むならこの記事

• 品質管理におけるソフトウェアテストの重要性とは
• テスト工数の見積もり精度｜外れる原因と改善策
• QCDとは？QCDSとの違いと品質・コスト・納期の優先順位の決め方

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する