確認作業は非常に大事です。「見たつもり」で後々大きなトラブルが発生することもあります。
信頼関係のある企業であっても、確認については慎重に行いましょう。
業務システム開発では、要件定義書や設計書、試験仕様書など、さまざまなドキュメントが作成されます。
これらを正しくレビューし、内容を確認・評価することは、以下のようなリスクを防ぐために不可欠です。
✅ 複数人でレビューする
→ 業務担当者、システム部門、現場利用者など、異なる視点で確認することで抜け漏れを防げる
✅ チェックリストを使う
→ 「業務フローに沿っているか」「例外処理が記載されているか」など、確認項目を明文化する
✅ レビューコメントは具体的に書く
→ 「わかりにくい」ではなく「この処理の対象条件が曖昧です」など、指摘の意図を明確に
✅ レビュー結果を記録に残す
→ 指摘内容と対応状況を一覧化し、後から見返せるようにする
✅ 承認は“納得してから”行う
→ 疑問点があるまま承認せず、納得できるまで確認・相談する
| トラブル内容 | 原因となった確認漏れ | 発生後の影響 |
|---|---|---|
| 顧客マスタに不要な項目が追加された | 要件定義書のレビューで業務担当が確認を省略 | 開発後に仕様変更、追加費用と納期遅延 |
| 帳票の金額表示が税抜になっていた | 設計書のフォーマット仕様を見落とした | リリース後にクレーム、再リリース対応 |
| テスト項目に例外処理が含まれていなかった | 試験仕様書のレビューが形式的だった | 本番でエラー発生、緊急対応が必要に |
| 操作マニュアルが専門用語だらけ | 現場ユーザーによるレビューがなかった | 利用者が使い方を理解できず、問い合わせが殺到 |