開発工程と外部委託の監査チェックポイント
開発の各工程（設計・プログラミング・テスト・移行）と外部委託について、監査人が「どこを確認するか」「何を指摘事項にするか」を選べるようになる。
この分野は「チェックポイントはどれか」「指摘事項はどれか」という形で、毎年ほぼ同じ考え方の問題が出る。判断の物差しを3本持っておけば、初めて見る選択肢でも消去法で解ける。
このレッスンで稽古する（用語チェック・過去問）結論：監査人が使う物差しは3本
この分野の問題は、ほぼ次の3本の物差しで解ける。
- 使う人（利用部門）が関わっているか：設計レビュー・受入れテスト・移行の検証が開発側だけで済んでいたら指摘事項。
- 漏れなく確認しているか（網羅性）：テストケースは網羅的に作る。サンプリング（一部だけを抜き出すこと）で済ませていたら指摘事項。
- 任せきりにしていないか：外部委託していても、進捗・媒体の扱い・委託先が倒れたときの備えを発注側が管理しているか。
指摘事項は、監査人が「ここに問題がある」と監査報告書に書く事項のこと。**コントロール（統制）**は、リスクを減らすための仕組みやルールを指す。
工程別の早見表
| 工程 | 防ぎたいリスク | OK（チェックポイント） | NG（指摘事項） |
|---|---|---|---|
| システム設計 | 利用者の要件が満たされない | 利用部門が参画して設計書をレビューしている | 開発側だけで設計を確定している |
| プログラミング | バグが残る | 全ロジックパスからテスト項目を作る・結果を記録する・作成者以外がテストする | テスト項目をサンプリングで選んでいる |
| システムテスト | 全体として正しく動かない | テストケースが網羅的 | 利用者側だけで承認・実施している／本番環境で実施している |
| 受入れテスト | 業務で使えない | 利用部門（委託なら委託者）が要件定義に基づいて実施している | システム部門だけ、または受託者だけで実施・承認している |
| 移行 | 移行結果が業務に合わない | 計画どおりに移行し、利用部門や運用部門も結果を検証している | 開発部門内の検証だけで移行完了にしている |
設計段階：利用部門のレビューが正解（最頻出）
問われ方はほぼ1パターン。「利用者要件が充足されないリスクを低減するコントロール」のチェックポイントを問われたら、答えは 「利用部門が参画して、システム設計書のレビューを行っていること」。
注文住宅にたとえると分かりやすい。設計図を施主（住む人）に見せずに工務店だけで決めると、完成してから「台所が使いにくい」と言われる。要件を一番よく知っているのは使う人なので、設計段階で使う人に確認してもらうのが最も効く統制になる。
ひっかけの選択肢は、どれも正しい統制ではあるが、別のリスクへの対策になっている。
| 選択肢 | 何のための統制か |
|---|---|
| 設計書に基づいてプログラム仕様書を作る | 設計と製造のずれを防ぐ |
| テスト計画を運用部門の責任者が承認する | テストの品質・運用への引継ぎ |
| プログラミング標準に従う | 品質をそろえ、保守しやすくする |
| 利用部門が設計書をレビューする | 利用者要件の充足 ← 正解 |
問題文にあるリスクの言葉（利用者要件）と、選択肢の主語（利用部門）が対応しているものを選ぶ。
プログラミングとシステムテスト：網羅性を見る
プログラミングの信頼性を監査するときは、単体テスト（プログラムを1本ずつ確かめるテスト）の項目をすべてのロジックパス（処理が通りうる分岐の道筋）から作っているかを見る。サンプリングで一部だけ選んでいたら網羅性が足りず、指摘事項になる。設計書どおりに作る・結果を記録して保管する・作成者以外の第三者がテストする、はいずれも適切な状態。
システムテスト（全体を組み合わせ、設計どおりに動くかを確かめるテスト）のチェックポイントは テストケースが網羅的に想定されていること。
- 利用者側の責任者だけで承認する → 開発側の責任も必要なので不適切
- 利用者側の担当者だけで実施する → 同じ理由で不適切
- **実際に業務が行われている環境（本番環境）**で実施する → 業務データを壊すおそれがある。テスト環境は本番と分ける
「だけ」が付いた選択肢は、まず誤りを疑ってよい。
受入れテストと移行：主役はユーザ
ユーザ受入れテスト（利用者が「この仕様で受け取ってよいか」を確かめる最終テスト）の主役は利用部門。システム部門だけで実施・承認していたら指摘事項になる。
外部委託の場合の着眼点は、委託者（発注側＝ユーザ）が要件定義に基づいて納品物をテストしているか。受託者がテストを実施する・受託者が計画書を納品する・監査人が計画を作る、はいずれも誤り。監査人は自分で計画を作る立場ではなく、独立した立場から確認する役割を持つ。
| 比較 | システムテスト | ユーザ受入れテスト |
|---|---|---|
| 確かめること | システム全体が設計どおり動くか | 要件どおり業務で使えるか |
| 主体 | 開発側（利用部門も承認に参加） | 利用部門（委託なら委託者） |
| 監査の着眼点 | テストケースの網羅性 | ユーザが主体として参画しているか、要求を網羅しているか |
| 環境 | 本番とは分ける | 本番とは隔離する |
システム移行も考え方は同じ。移行結果の検証を開発部門の中だけで行って完了にしていたら指摘事項。計画どおりの移行、操作教育、移行ツールによる検証は適切な状態。
バージョン管理：機密性ならアクセスコントロール
バージョン管理システム（ソースコードの変更履歴を保存・管理する仕組み。Git など）を導入したとき、機密性のチェックポイントは アクセスコントロール（誰が見られるか・触れるかの制限）の設定が適切か。
情報セキュリティの3要素で整理すれば迷わない。
| 要素 | 意味 | この問題の選択肢 |
|---|---|---|
| 機密性 | 許された人だけが見られる | アクセスコントロールの設定 ← 正解 |
| 完全性 | 内容が正しく、勝手に変わらない | 変更結果を責任者が承認する |
| 可用性 | 使いたいときに使える | （この問題では出てこない） |
導入コストが適正かどうか、どの部門が選定したかは、機密性とは関係がない。
外部委託：丸投げしない
外部委託の基本は丸投げしないこと。
- 進捗管理：発注側も進捗を把握し、問題を早く見つけて対処する。監査で提出すべき資料は 委託先から定期的に受け取っている業務報告と、その検証結果。検収方法・ソフトウェアの預託・資料の廃棄方法は、進捗管理とは別の論点。
- 「業務に精通した委託先に、業務仕様の決定まで一括で任せる」「信頼できる委託先だから受入検査を簡単に済ませる」は丸投げなので不適切。逆に「担当者の作業まで細かく指示する」もやりすぎで誤り（作業の進め方は委託先の責任）。
- バックアップ媒体の引渡し：機密情報の入った媒体を段ボール箱に入れて渡すだけでは、紛失・盗難・中身の露見への対策がなく、指摘事項になる。機密保持契約を結ぶ、引渡しの記録と受領印を残す、保管状況を定期的に確認する、はいずれも適切。
- エスクロウ：委託先が経営破綻してもソフトウェアの保守を続けられるように、ソースコードなどを第三者に預けておく契約条項。貸金庫に合鍵を預けておき、持ち主に何かあっても取り出せるようにしておくイメージ。
| 契約条項 | 何に備えるか |
|---|---|
| エスクロウ条項 | 委託先の破綻で保守を受けられなくなる ← 破綻への備えはこれ |
| 瑕疵担保責任条項 | 納品物の欠陥の修補・賠償（現在の民法では契約不適合責任） |
| SLA 条項 | サービス品質の水準を合意し、評価する |
| 再委託禁止条項 | 責任の所在があいまいになるのを防ぐ |
試験での問われ方
出題形式は2種類ある。最初に問い方の向きを確認するのがコツ。
| 問い方 | 探すもの |
|---|---|
| 「チェックポイントはどれか」「着眼点はどれか」 | 正しい（あるべき）状態 |
| 「指摘事項に該当するものはどれか」 | 問題がある状態（1つだけ） |
指摘事項を問う問題では、4つの選択肢のうち3つはお手本どおりの状態で、残り1つにだけ「開発側だけ」「サンプリング」「段ボールで渡すだけ」のような欠けがある。3本の物差し（利用部門・網羅性・丸投げしない）を当てて、欠けている1つを見つける。
「指摘事項はどれか」の解き方（ユーザ受入れテスト）
ア システム部門だけでテストを行い，テスト結果をその責任者が承認した。
イ 当該業務に精通したユーザが参画してテストを行った。
ウ ユーザ受入れテストの実施環境は本番環境と隔離させた。
エ ユーザ要求をすべてテスト対象としたテストケースを設定した。
解き方と答えを見る
- 問い方を確認する：「指摘事項に該当するもの」なので、問題がある状態を1つ探す。
- 物差しを決める：受入れテストの主役は利用部門。あわせて網羅性も見る。
- ア：システム部門だけで実施し、その責任者が承認 → 利用部門が関わっていない。問題あり。
- イ：業務に精通したユーザが参画 → あるべき状態。
- ウ：実施環境を本番環境から隔離 → 本番データを守る適切な措置。
- エ：ユーザ要求をすべてテスト対象にした → 網羅性があり、あるべき状態。
答え：ア（システム部門だけでテストし、承認している）
契約条項の選び方（委託先の経営破綻への備え）
ア 開発したソフトウェアの瑕疵担保責任条項
イ 外部委託先のサービスを評価するための SLA 条項
ウ 責任の所在を明確にするためのソフトウェア開発の再委託禁止条項
エ ソフトウェアのソースコードなどを第三者へ預託するエスクロウ条項
出典：基本情報技術者試験 科目A免除 修了試験 20181209 実施分 問59
解き方と答えを見る
- リスクを特定する：委託先の経営破綻で、ソフトウェアの保守を受けられなくなる。
- 破綻した委託先には何も頼めないので、委託先以外を頼れる仕組みが必要だと考える。
- ア：瑕疵担保責任は欠陥への責任で、委託先が存続していることが前提。イ：SLA はサービス品質の水準。ウ：再委託禁止は責任の所在を明確にするためのもの。
- エ：ソースコードを第三者に預託しておけば、破綻後もそれを使って別の業者が保守できる。
答え：エ（エスクロウ条項）
要点（試験直前に読む）
- 設計段階で利用者要件の未充足を防ぐ統制は「利用部門が参画した設計書レビュー」。
- テストは網羅性が命。単体テストのサンプリングは指摘事項、システムテストの着眼点は網羅的なテストケース。
- 受入れテストと移行の検証は利用部門（委託者）が主体。開発側・受託者だけで済ませたら指摘事項。
- バージョン管理の機密性はアクセスコントロール。変更の承認は完全性。
- 外部委託では、進捗は定期的な業務報告とその検証結果で管理し、媒体は段ボールで渡すだけにしない。破綻への備えはエスクロウ。
ひっかけ
- 「指摘事項はどれか」と「チェックポイントはどれか」は向きが逆。最初に問い方を確認し、指摘事項の問題では欠けている1つを探す。
- 「利用者側だけ」「システム部門だけ」のように「だけ」で片側に寄った選択肢は、承認・実施の体制が不十分なことが多い。
- システムテストを「実際に業務が行われている環境（本番環境）」で実施するのは正しそうに見えるが誤り。テスト環境は本番と分ける。
- プログラム仕様書の作成やプログラミング標準の遵守は、正しい統制だが要件充足のための統制ではない。どのリスクへの対策かを対応させる。
- 「業務に精通した委託先に一括して任せる」は丸投げなので誤り。破綻対策の条項を問われたら、瑕疵担保・SLA・再委託禁止ではなくエスクロウを選ぶ。
用語（17）
独立した監査人が、情報システムのリスクに対する統制が適切に整備・運用されているかを確かめ、評価すること。
監査で見つかった、改善が必要な問題点として監査報告書に記載する事項。
⚠ 「チェックポイント」はあるべき状態、「指摘事項」は問題がある状態。問い方の向きを逆に取らないこと。
リスクを低く抑えるために組織が設ける仕組みやルール。
⚠ どのリスクに効く統制なのかを対応させる。利用者要件の充足に効くのは利用部門のレビュー。
システムを実際に業務で使う部門。要件を一番よく知っている。
⚠ システム部門（開発部門）は作る側、運用部門は動かし続ける側。
システム設計書の内容を関係者で確認し、誤りや要件の漏れを見つける作業。
プログラムを1本（1モジュール）ずつ動かして、正しく動くかを確かめるテスト。
⚠ システムテストは全体を組み合わせたテスト、受入れテストは利用者が受け取るかどうかを判断するテスト。
プログラムの分岐によって処理が通りうる道筋。単体テストではすべての道筋を確かめる。
全体の中から一部だけを抜き出して確かめること。
⚠ テスト項目の選び方としては網羅性が足りず指摘事項になる。
プログラムを組み合わせたシステム全体が、設計どおりに動くかを確かめるテスト。
⚠ 受入れテストとの違いは主体。システムテストは開発側が中心、受入れテストは利用部門が主体。
利用部門（委託者）が要件定義に基づき、納品されたシステムを受け取ってよいか確かめるテスト。
⚠ システム部門だけ、受託者だけ、監査人が計画する、はいずれも誤り。
旧システムから新システムへ、データや業務を切り替える作業。
⚠ 移行結果の検証を開発部門内だけで完結させるのは指摘事項。
ソースコードの変更履歴を保存し、誰がいつ何を変えたかを管理する仕組み。
誰がどの情報を見たり変更したりできるかを制限する仕組み。
⚠ 機密性の対策。変更の承認は完全性の対策。
許可された人だけが情報にアクセスできる性質。
⚠ 完全性は内容が正しく改ざんされていないこと、可用性は必要なときに使えること。
委託先が経営破綻しても保守を続けられるように、ソースコードなどを第三者に預けておく仕組み。
⚠ 瑕疵担保責任（欠陥への責任）や SLA（品質水準）は破綻への備えにならない。
提供するサービスの品質水準を、委託元と委託先で合意して文書にしたもの。
⚠ 品質の評価に使うもので、委託先の破綻対策ではない。破綻対策はエスクロウ。
納品物に欠陥があったとき、作った側が修補や賠償を負う責任。現在の民法では契約不適合責任と呼ぶ。
⚠ 委託先が存続していることが前提なので、破綻への備えにはならない。
このレッスンの過去問
- システム設計段階の監査チェックポイント(利用部門のレビュー参画)平成26年度 春期 基本情報技術者試験 午前 問59
- プログラミング信頼性の監査指摘事項平成23年度 秋期 基本情報技術者試験 午前 問59
- システムテストの監査チェックポイント令和元年度 秋期 基本情報技術者試験 午前 問58
- ユーザ受入れテストの監査チェックポイント平成22年度 秋期 基本情報技術者試験 午前 問60
- システム移行の監査チェックポイント(利用部門による検証)基本情報技術者試験 科目A免除 修了試験 20140727 実施分 問58
- バージョン管理システムの機密性チェックポイント平成27年度 秋期 基本情報技術者試験 午前 問59
- システム開発外部委託時の留意点(進捗の把握)基本情報技術者試験 科目A免除 修了試験 20160124 実施分 問59
- 外部委託時のバックアップ媒体管理の監査指摘平成30年度 秋期 基本情報技術者試験 午前 問59
- ソースコード預託(エスクロウ)条項の監査基本情報技術者試験 科目A免除 修了試験 20181209 実施分 問59