ITパスポート 2009年 春期 問43

発注したソフトウェアが納品されたときに確認する項目【ITパスポート 解説】

正解の理由

• 納品の目的は「約束された機能・品質が提供されているかの確認」であるため、仕様との照合と動作確認が最優先です。

解法ステップ

1. 納品物の範囲を確認する
   • 仕様書や契約書で約束された機能・成果物をリストアップする。
2. 受入基準（合格の条件）を用意する
   • どの条件を満たせば合格とするかを明確にする（例：機能Aが正常に動作、応答時間がX秒以内、ログが出力される等）。
3. 実際に動かして確認する（受入試験）
   • ユーザー受入試験（UAT：User Acceptance Testing）や操作確認を行い、仕様どおり機能するかをテストする。
4. 証跡を残す
   • テスト結果、スクリーンショット、エラーログ、検収書などを保存する。
5. 不合格時の対応を決める
   • 不具合があれば修正・再納品の手順や期日を明確にする。

選択肢別の誤答解説

• ア: 委託先から提出された費用見積りの内容が妥当であること
  • 見積り（どれだけ費用がかかるかの予測）は発注前や発注時に検討・合意すべき事項です。納品時に確認するのは遅く、納品の主目的ではありません。
• イ: 作業報告書の記述から作業が遅れなく進捗していること
  • 作業報告書（進捗や作業内容を記録した文書）は開発中の管理に使います。納品時には進捗履歴は参考になりますが、納品物そのものが仕様どおりかどうかを判断する根拠にはなりません。
• エ: 品質管理の計画が立案されていること
  • 品質管理の計画（品質を確保するための手順や基準）はプロジェクトのある段階で確認すべき「プロセス」の話です。納品時に重要なのは「計画が立てられているか」ではなく、計画どおりに品質が確保され、成果物が基準を満たしているかです。

よくある誤解

1. 「見積りや計画が正しければ納品も問題ない」
   • 見積りや計画は大事ですが、計画どおりに実行されて成果が出ているかを必ず確認してください。計画の存在＝完成ではありません。
2. 「作業報告書が良ければ完成とみなせる」
   • 報告書は参考情報ですが、実際にソフトを動かして機能や動作を確認することが最終判断です。
3. 「仕様書が曖昧でも納品時に細かく詰めればよい」
   • 仕様が曖昧だと検収基準が不明確になりトラブルの元です。納品前に受入基準を明確にしておくことが重要です。

補足コラム

• 機能確認：仕様書に書かれた各機能が期待通りに動くか
• 非機能確認：性能（応答時間）、安定性、セキュリティ要件など
• ドキュメント確認：操作マニュアル、設計書、ライセンス情報が揃っているか
• インストール確認：実際の導入手順で問題なく稼働するか
• テスト証跡：テスト結果やログを保存して、後でトラブル対応できるようにする

• 仕様Aの機能が動作するか → 合格/不合格
• 応答時間が基準内か → 合格/不合格
• マニュアルが最新か → 有/無
• インストール手順でエラーが出ないか → 合格/不合格

FAQ