5.1企画・開発の統制評価

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

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

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

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

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

あるシステム監査人が、基幹システムの開発体制を評価するために現地調査とインタビューを行ったとします。監査人は、本番環境への反映手続を確認する過程で、開発担当者が自分で作成・変更したプログラムを、第三者のレビューや運用担当者の承認を経ずに、直接本番環境へリリースできる権限を持っているという体制を発見しました。監査人はこれを、たまたま今回は問題が起きていないという「運用上の不備」ではなく、統制のデザインそのものが牽制を欠いている「整備上の不備」であると診断します。なぜなら、この体制では担当者一人の判断で未検証・未承認のコードが本番稼働してしまう可能性が構造的に存在し、不正コードの混入や重大なバグの見逃しを予防する仕組みが最初から設計されていないからです。監査人は改善勧告として、予防統制である「開発と運用の職務分掌」の確立——具体的には、開発者に本番環境への直接書込権限を与えず、本番反映は独立した運用担当者が、レビュー・承認を経たリリース物に限って行う体制——を提言します。さらに、予防統制を補完する発見統制として、本番環境への変更履歴（誰がいつ何を反映したか）を記録するログを取得し、職務分掌に反する反映が行われていないかを定期的に突合・監視することも併せて勧告します。このように、単に「統制が無い」と述べるのではなく、それが予防すべきどのリスクに対応する統制で、整備上の不備なのか運用上の不備なのかを切り分け、対応する統制種別（予防／発見）で改善を勧告することが、コントロール評価における監査人の判断です。

5.1.3この節のまとめ

• 監査人は企画・開発の各工程の統制を、整備状況（デザイン）と運用状況（実施）の両面で評価し、不備を整備上の不備／運用上の不備に切り分ける
• 開発と運用の職務分掌は予防統制の中核で、開発者が本番へ直接リリースできる体制は整備上の不備として指摘する
• 改善勧告は、リスクに対応する予防統制（承認・職務分掌）と発見統制（変更ログの突合・監視）を組み合わせて提言する