システムが完成したと聞いて画面を触ってみたら、「あれ、この操作はどこでやるのだろう」「毎月の締め処理ができない」と気づいた。納品間際になってから、業務に必要な操作が足りないと分かるのは、発注者にとって本当に心が痛い場面です。
「完成した画面を触ってみたら、業務で必要な操作が足りなかった。受け入れ確認のときに何を見ればよかったのか」
先に結論をお伝えします。受け入れ確認では、画面や機能を一つずつ眺めるのではなく、「実際の業務を最初から最後まで通して」触ることが効きます。画面ごとの確認だと、各画面は仕様どおりでも「画面と画面のあいだ」「例外の場面」の抜けは見つかりません。
この記事では、受け入れ確認（＝完成したシステムが依頼どおりかを発注者が確かめる作業）で「業務の流れ」を軸に確認する方法を、確認シートの作り方・見落としやすい場面・開発会社への質問例とあわせて解説します。足りない操作が見つかったときの扱い方も取り上げます。
受け入れ確認で「必要な操作の不足」に気づくのが遅れる3つの理由
理由1：仕様書の一覧どおりに作ると、画面は揃っても業務は回らないことがある
開発会社は、合意した要件や仕様書に書かれた機能を作ります。ところが、仕様書は画面や機能の一覧として書かれることが多く、「月初にこの順番で作業して、最後にこの帳票を出す」という仕事の流れまでは載っていないことがあります。
そのため、一覧のとおりに全部できていても、実際の業務に当てはめると「間をつなぐ操作」が欠けていた、ということが起こります。
理由2：発注者にとっての「当たり前」は、書かれずに残りやすい
「締め処理のあとは修正できない」「取引先ごとに請求書の様式が違う」といった業務の事情は、社内では常識です。常識だからこそ要望として口に出されず、要件定義書にも残らないまま、開発が進むことがあります。
要件定義（＝何を作るかを文章で決める工程）の責任については、IPA（情報処理推進機構）が次のように整理しています。
📰 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」
このガイドは、システムを使って業務に役立てる立場のユーザ（発注者側）が、要件を定義する主体であるという考え方を示しています。つまり、業務の流れを一番よく知っている発注者が、確認の場面でも主役になる必要があります。
理由3：完成物を触るのが、納品直前の1回だけになりがち
最初に完成品を触るのが納品直前だと、足りない操作が見つかっても、直す時間も予算も残っていません。途中の画面を見せてもらう機会があれば、もっと早い段階で気づけます。
詳しくは次の記事で解説しています。途中で動くものを見せてほしいと頼む方法は、この記事の「早めに見つける」工夫と組み合わせられます。
受け入れ確認は「業務の流れ」で組み立てる
ステップ1：実際の1日・1か月の仕事を書き出す
まず、そのシステムで行う仕事を、作業する人の目線で順番に書き出します。システムの機能名ではなく、普段の言葉で書くのがコツです。
例：「受注の連絡を受ける → 内容を入力する → 見積書を作る → 承認をもらう → 取引先へ送る → 請求の月末処理をする」
書き出すときは、次の3つを分けておくと確認がしやすくなります。
| 種類 | 内容 | 例 |
|---|---|---|
| いつもの流れ | 毎日・毎月ふつうに行う手順 | 受注入力から請求書の発行まで |
| たまに起きる場面 | 月末・年度末・繁忙期だけの手順 | 締め処理、年次の集計 |
| 例外の場面 | ふだんは起きないが、起きると困ること | 入力ミスの取り消し、キャンセル、返品 |
ステップ2：流れを通して触る「確認シート」を作る
書き出した流れを、1行ずつ「やる人・やること・期待する結果」にして表にします。Excelで十分です。
| No. | やる人 | やること | 期待する結果 | 結果（○／×） | メモ |
|---|---|---|---|---|---|
| 1 | 営業担当 | 新しい取引先を登録する | 取引先一覧に表示される | ||
| 2 | 営業担当 | 見積書を作り、承認を依頼する | 上長に通知が届く | ||
| 3 | 上長 | 見積書を差し戻す | 担当者に理由つきで戻る |
ここでのポイントは、実際に使う人に触ってもらうことです。システムを担当する人だけでなく、現場で毎日その作業をしている人に、普段の資料や実際のデータに近い内容で試してもらうと、抜けに気づきやすくなります。
ステップ3：見落としやすい場面を重点的に試す
画面の確認では、次のような場面が抜けやすいと言われます。いつもの流れを終えたあとに、重点的に試してみてください。
- 取り消し・やり直し：入力を間違えたとき、保存したあとに直せるか、元に戻せるか
- 締め処理のあとの修正：締めたあとの修正が許される業務か、許されない業務か
- データの出し入れ：Excelで管理していた過去データを取り込めるか、集計結果をCSVなどで取り出せるか
- 帳票・書類：請求書や納品書など、社外に出す書類の様式が現状と合っているか
- 権限：担当者、上長、経理など、立場ごとに見られる情報・押せるボタンが業務に合っているか
- 通知・連絡：承認依頼や差し戻しが、気づける形で相手に伝わるか
- 量が多いとき：実際の件数（数百件、数千件）で、一覧の表示や検索が使えるスピードか
ステップ4：「足りない」を見つけたら、すぐに分類する
確認で気になる点が見つかったら、感想として伝えるのではなく、次の3つに分けて開発会社へ伝えます。
| 分類 | 状態 | 一般的な扱いの考え方 |
|---|---|---|
| 仕様どおりでない | 合意した仕様と動きが違う | 不具合として直してもらう対象になりやすい |
| 仕様にはないが、業務に必要 | 合意した範囲に書かれていない | 追加の変更として、費用・期間を相談する対象になりやすい |
| どちらか分からない | 仕様の解釈が分かれる | 打ち合わせ記録・要件定義書を一緒に見て確認する |
どれに当たるかは、契約の内容や、やり取りの記録によって変わります。判断に迷う場合や、金額で意見が分かれる場合は、弁護士などの専門家や公的な相談窓口への確認をおすすめします。
仕様どおりでない不具合なのか、仕様変更なのかの分け方は、次の記事でより詳しく扱っています。
やりがちな失敗
- 画面を1枚ずつ確認して終わる：各画面は問題なくても、画面をまたぐ流れで抜けが出ます
- 確認する人がシステム担当者だけ：現場の事情を知る人が触らないと、「当たり前」の抜けは見つかりません
- テスト用の少ないデータで確認する：実際の件数や、実際の取引先名・金額での不具合は、少ないデータでは出てきません
- 気になる点を口頭で伝える：後から「聞いていない」「言った」となりやすいので、確認シートに残し、メールなど記録の残る形で伝えます
- 確認期間を短く見積もる：業務を通して触るには、思ったより時間がかかります。現場の人の予定を先に押さえておきます
発注者がやること チェックリスト
- ☐ 開発の中盤までに、そのシステムで行う仕事の流れ（1日・月末・例外）を書き出した
- ☐ 流れに沿った確認シート（やる人・やること・期待する結果）を作った
- ☐ 現場で実際にその作業をする人に、確認への参加を依頼した
- ☐ 実際の件数・実際の書式に近いデータを用意した
- ☐ 取り消し・締め処理・帳票・権限の場面を確認項目に入れた
- ☐ 気になる点を「仕様どおりでない／業務に必要で仕様にない／判断に迷う」に分けて記録した
- ☐ 確認の期間と、指摘から修正までの段取りを、開発会社と事前に決めた
開発会社への質問例
打ち合わせでそのまま使える形にしました。
- 「受け入れ確認は、画面ごとではなく、業務の流れに沿って行いたいのですが、そのための確認シートをこちらで作ってもよいでしょうか」
- 「完成前の中間の段階で、実際の業務の流れを通して触れるタイミングは、いつ頃ありますか」
- 「受け入れ確認で見つかった内容は、どのような基準で『修正』と『追加の変更』に分けて扱いますか。流れや費用の考え方を教えてください」
- 「実際の件数に近いデータで確認したいのですが、テスト用のデータを入れる方法はありますか」
- 「受け入れ確認の期間は何日を想定していますか。指摘を出してから、修正が戻ってくるまでの目安はどのくらいですか」
こうした質問への答え方からも、確認を一緒に進めようとしてくれる開発会社かどうかが見えてきます。
まとめ：画面の確認から「業務を通す確認」へ
業務に必要な操作が足りないと気づくのが遅れるのは、確認の仕方が画面中心になりやすいためです。次の点を押さえておくと、納品間際の驚きを減らせます。
- 仕事の流れ（いつもの・たまに・例外）を、発注者側で書き出す
- 流れに沿った確認シートを作り、現場の人に触ってもらう
- 取り消し・締め処理・帳票・権限・データ量を重点的に試す
- 見つかった点は、記録の残る形で分類して伝える
- 受け入れ確認の前に、中間の段階でも一度、流れを通して触る
受け入れ確認で見つかる「足りない」は、発注者と開発会社のどちらかの落ち度とは限りません。業務の流れを共有する手順が、途中に1回足りなかっただけ、ということも多くあります。まずは、自社の1か月の仕事の流れを書き出すところから始めてみてください。
