5.1企画・開発の統制評価

システム監査人は、開発したシステムそのものを作る側ではなく、開発の各工程に適切なコントロールが整備され、かつ実際に運用されているかを独立した立場から評価する側です。企画・開発工程では、プロジェクト管理・要件定義・テスト・移行・本番リリースの各段階にリスクがあり、それぞれに予防統制（誤りやリスクの発生自体を防ぐ）と発見統制（発生した誤りを検知する）が設計されます。この節では、監査人がこれらの統制の整備状況（デザインが妥当か）と運用状況（デザイン通りに実施されているか）を評価し、不備を「整備上の不備」か「運用上の不備」かに切り分けて診断する視点を学びます。

5.1.1開発各工程の統制と監査の着眼点

• 要件定義の統制＝要件が利用部門と合意され、承認記録が残り、変更が管理されているか。監査人は要件定義書への承認証跡の有無や、要件変更が無統制に膨張していないか（スコープクリープ）を確かめる。
• テストの統制＝テスト計画・テストケース・結果記録が整備され、要件を網羅しているか。監査人はテスト証跡（誰がいつ何を確認したか）を証拠として査閲し、未消化の不具合が残ったままリリースされていないかを評価する。
• 移行・本番リリースの統制＝リリース前の承認、切戻し（ロールバック）手順、旧データからの移行検証があるか。予防統制として「本番反映前に責任者の承認を必須にする」、発見統制として「移行後の件数・金額の突合で異常を検知する」が典型。

5.1.2開発と運用の職務分掌（予防統制の中核）

• 職務分掌（Segregation of Duties）＝相互に牽制すべき職務を別々の担当者に分けることで、単独での不正・誤りを防ぐ予防統制。開発領域では「開発担当者（プログラムを作成・変更する者）」と「運用担当者（本番環境へ反映・実行する者）」を分けることが中核となる。
• この分掌が欠けると、開発者が自らの変更を検証なしに本番へ直接反映できてしまい、意図的な不正コードの混入や、レビュー・承認を経ない未検証コードの本番稼働というリスクが生じる。監査人はまず「開発者に本番環境への直接書込権限があるか」を確かめ、あればこれを整備上の不備（統制のデザインそのものが不十分）として指摘する。