業務ツールが届いて、説明どおり画面が動いた。それでも「これで確認完了としてよいのか」と迷うことがあります。
結論は、普段の仕事を最後まで進められるか、例外が起きたときに判断できるか、別の担当者に引き継げるかを、事前に合意した範囲で確かめることです。見た目の感想だけでは、業務に使える状態かを判断しにくいためです。
この記事は、専任のIT担当者がいない小さな会社でも使える確認の考え方です。特定のツールの操作手順や、契約上の検収条件を定めるものではありません。
まず「何を頼んだか」に戻る
納品物を見ると、便利にしたい点が次々に見つかります。ただ、最初に頼んだ内容の確認と、新しく思いついた要望を混ぜると、どこまで終わったのか分からなくなります。
合意した目的と対象業務を読み返し、それぞれに「何を見れば確認できるか」を一つずつ対応させます。「使いやすい」だけではなく、「普段の担当者が説明を見て必要な仕事を終えられる」といった観察できる状態に言い換えます。
合意内容が曖昧な箇所は、確認前に双方で認識を合わせます。納品後に一方だけで条件を追加する進め方は避けたいところです。
1. 普段の仕事が最後まで終わるか
個々のボタンより、仕事の始まりから終わりまでを見ます。
- 必要な情報を用意できるか
- いつもの担当者が迷わず扱えるか
- 出てきた結果を次の仕事で使えるか
- 終わった仕事と、まだ途中の仕事を区別できるか
確認に使う情報は、利用が認められた安全なサンプルにします。実際の顧客情報や秘密情報を、確認のためだけに渡す必要はありません。
説明を受けた直後だけでなく、担当者自身が操作してみることにも意味があります。作った人の補助がないと進まない箇所は、説明の不足なのか、合意した使い方との違いなのかを切り分けます。
2. 例外のとき、困ったままにならないか
普段どおりの入力が通るだけでは、確認が偏ります。対象範囲に含まれる「情報が足りない」「対象外の依頼が来る」「途中でやめる」といった場面も考えます。
ここで求めるのは、あらゆる例外を自動処理することではありません。処理できないことが分かり、誰が次を判断するかが決まっていれば、人が扱う運用も選べます。
未確認の状況は未確認のまま記録します。「試していない」と「問題がなかった」は別です。
3. 結果を確かめられるか
完了表示が出たことと、結果が目的に合っていることを分けて見ます。確認者が期待する結果を先に用意し、実際の結果と比べます。
AIを含む場合は、文章が自然かだけで判断しません。必要な情報があるか、根拠のない内容が混ざっていないか、分からない場合に断定していないかも確認します。一度の成功だけで、毎回同じ品質になるとは限りません。
誤りがあった場合は、「操作した場面」「期待した結果」「実際の結果」を分けて伝えます。感想だけより、確認をやり直しやすくなります。
4. 納品後の担当者が決まっているか
誰が使うかに加えて、内容が変わったときに誰が相談するか、困ったときの連絡先、受け取る説明資料の有無を確認します。必要な利用権限も、合意した担当者にあるか確かめます。パスワードの共有で済ませる話とは分けましょう。
保守や修正が含まれるか、どの範囲までかは契約や個別の合意で異なります。「納品後だから全部無料」「使い始めたから全部追加」と決めつけず、合意した範囲と照らして相談します。
結果は3つに分ける
確認した項目は、確認済み・未確認・要相談に分けるだけでも整理できます。要相談には、合意内容との違いなのか、新しい要望なのかも添えます。
特に重要な仕事が未確認なら、確認完了とまとめず、その点を明示して次の確認方法を決めます。完璧なチェック表を作ることより、何を確かめ、何が残っているかを双方が同じように理解できることが大切です。
参考資料
IPA「ユーザのための要件定義ガイド 第2版」は、業務部門の利用者が要件定義に主体的に関わる考え方を扱っています。2019年公開のアーカイブ資料です。本記事の4つの確認観点は、小規模な業務ツール向けに独自に整理したもので、同資料の公式チェックリストではありません。