経営者は、一般的なシステム管理における有効なIT統制として、「準拠性」「信頼性」「可用性」「機密性」という目標を求められています。
そして、その目標を達成するための主なIT統制活動として、IT全般統制とIT業務処理統制があります。
実施基準によると、IT全般統制とは、IT業務処理統制が有効に機能する環境を保証するための統制活動のことをいい、具体的な統制項目としては、以下のものがあります。
- システムの開発、保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
この記事では、この項目のうち「システムの開発、保守に係る管理」に関連する統制活動について、簡単にまとめました。
システムの開発、保守に係る管理
「システムの開発、保守に係る管理」について、主にシステム企画、システム開発、システム変更・保守というようなプロセスにおいて、IT基盤の構築や承認手続き、導入前テスト等が適切に行われるための統制を整備します。
システムの企画
組織目標を達成するために、そもそもどのようなシステムを導入し、如何ほどIT投資するのかを意思決定しなければなりません。
中期経営計画策定の際に、IT戦略やIT投資計画を明らかにし、スケジュールやベンダー選定、ハードウェア・ソフトウェア検討等の開発計画が決定されることになります。
リスクと統制の例
例１：経営戦略と整合しないシステム開発となってしまう
⇒予算管理規程等に基づき、IT戦略を含めた中期経営計画が策定され、経営陣の承認を受け、また適時見直します。
例２：ユーザー部門のニーズが反映されず、ユーザー部門が使用しないシステム開発となってしまう
⇒システム部門とユーザー部門の間でITシステム関連のミーティングを定期的に開催し、システムに関しての要望や現行システムの改善点等に関する情報を共有しておきます。
システムの開発
組織目標を達成するために、システム企画での意思決定を受けて、開発・調達したシステムを導入する場合があります。
当然のことながら、意図したとおりに機能しないシステムを導入するようなことにならないために、IT全般統制の整備が必要になります。
システム開発手順
一般的にシステム開発に関する活動は、
課題の識別と解決策の効果分析 → 要件定義 → （外部・内部）設計 → プログラミング → テスト → 導入
という流れになります。
※調達の場合は、「（外部・内部）設計→プログラミング」は「ソフトウェア選定→カスタマイズ」という手順に代わります。
●課題の識別と解決策の効果分析
最新のIT技術の動向や、現存する他システムとの適合、リスク評価と費用対効果等を検討し、現状課題の解決可能な情報システムの判断を行います。
●要件定義
システムによって実現したいユーザーの要求を明確にし、その要件を設計へ反映させるための要件定義書を作成します。
要件には、「業務要件」「システム要件」「機能要件」「非機能要件」等があります。
- 業務要件：導入するシステムによって実現すべき業務
- システム要件：業務要件を実現するために構築すべきシステム
- 機能要件：システム要件のうち、システムが備えるべき機能についての要件
- 非機能要件：システム要件のうち、機能以外に満たすべき事項（性能、容量、セキュリティ等）についての要件
●設計
要件定義によって決定された予備的な設計に基づき、機能や仕様等の詳細な設計し、仕様書を作成します。
主に「外部設計」「内部設計」等があります。
- 外部設計：主に画面のレイアウトや操作方法、データ出力帳票等のユーザーから見える部分の設計
- 内部設計：モジュールの分割やシステム内部のデータファイル等の外部からは見えにくい部分の設計
●プログラミング
システム設計で作成された仕様書をプログラムコードに変換します。
●テスト
システムが設計されたとおりに正しく機能するかを評価したり、バグを検出するためにテストを行います。
テストには、「単体テスト」「統合テスト」「システムテスト」「受け入れテスト」等があります。
- 単体テスト：個々のプログラムやモジュールなど、比較的小さい単位で行うテスト
- 統合テスト：複数の構成部品の連動に着目して評価するテスト
- システムテスト：システムを集合的に構成させ、一連の動作が想定どおりに正しく実施されるかを確認するテスト
- 受け入れテスト：仕様書どおりに動作するかを確認し、さらに要件定義書に記された要件を満たしているかを評価するテスト
●導入
テスト結果に問題がなければ、プログラムを本番環境に移行し、システムを実稼働させます。
また、一定期間経過後にその導入効果のレビューを行います。
なお、現行システムから新システムに移行させる場合、以下のような手法があります。
- 並行移行：新旧システムの両方を一定期間並行運用する保守的な移行方法
- 一括移行：特定日に旧システムから新システムに一斉に移行する、リスクを伴う方法
- パイロット移行：一旦特定の部署に試験的に導入し、その結果を検証したのち、全体的に完全移行する手法
- 段階的移行：業務や機能、拠点単位など、段階的に新システムに切り替える方法で、一括移行するには時間がかかりすぎたり、データ量が多すぎる場合等に行われる
システム開発手法
開発するシステムの規模や目的等によって、適合する開発手法を選択する必要があります。
代表的な開発手法として、「ウォーターフォール型」、「アジャイル型」、「プロトタイピング型」等があります。
●ウォーターフォール型
「要件定義 → （外部・内部）設計 → プログラミング → テスト → 導入」の順序どおりに開発工程を進め、後戻りしない開発手法です。
順序どおりに進めるため、進捗管理は容易ですが、手戻りを想定していないため、要件定義の役割が重くなり、また、もし手戻りが発生すると、進捗管理に大きな影響を及ぼします。
●プロトタイプ型
「予備設計 → プロトタイプの開発 → 試用 → 修正 → 再使用 → 再修正・・・」のように、まずプロトタイプを作成し、ユーザー等による検証を受けて修正する、というプロセスを繰り返して開発する手法です。
ユーザーの意見を取り入れながら開発するため、開発側とユーザー側の認識の相違が起こりにくくなります。
ただし、プロトタイプを作成する時間と費用等がかかり、また、修正を何度も繰り返すとさらに時間と費用等がかかるため、開発完了とするラインを決めておく必要があります。
●アジャイル型
小さな単位で「計画 → 設計 → プログラミング → テスト → 計画・・・」という開発工程を繰り返す手法です。
仕様変更へ柔軟に対応でき、優先順位の高い要件から開発を進めるので、導入とシステムのブラッシュアップが早くなり、開発期間の短縮が可能です。
ただし、小さい単位で開発を進めるため、システム全体の方向性を見失わないように注意が必要です。
リスクと統制の例
例１：ユーザー部門の要望する要件が反映されないシステムが導入される
⇒要件定義や外部設計、テスト等にユーザー部門が参加し、十分にテストが実施され、導入前にユーザー部門の責任者のレビューを受け、承認される手続きを設けます。
例２：要件定義や設計、プログラミング等のシステム開発の各段階において文書化が不足しており、設計やプログラミングが要件を満たしておらず、システムが適正に機能しない、もしくはプログラム修正が頻発する
⇒システム開発の各段階において作成が必要な文書を明らかにし、適時に文書化を行い、適切な者がこれをレビューし、承認する手続きを設けます。
システムの変更・保守
適切なプロセスを経て開発されたシステムでも、運用していく過程で新たに課題が見つかったり、業務ニーズの変化等により、システムを改修する必要が生じる場合があります。
また、OS等のソフトウェアのバージョンアップや、サーバのリプレイス、ネットワークの設定変更等のITインフラの変更も起こり得ます。
システム変更・保守の際に、システムトラブルが発生することが少なくないため、意図しない変更が起こらないようにIT全般統制を整備します。
リスクと統制の例
例１：経営戦略に整合しないシステム変更が行われる
⇒情報システム管理規程等で変更手続が定められており、システム変更の依頼に対してシステム運用部門やユーザー部門の責任者の承認を受けます。
例２：システム変更が依頼部門の要求どおりになっていない
⇒本番環境へ登録する前に、テスト結果報告についてシステム運用部門やユーザー部門の責任者の承認を受けます。
例３：適正な変更手続が取られず、不正なプログラム変更が行われる
⇒本番環境へ登録する権限を、システム保守部門ではなく、システム運用部門に付与します。
システムの開発、保守の主要な統制
前述のとおり、システムの開発、保守に係る有効な予防的統制として、主に「職務分掌」と「手続きの規定・運用」、発見的統制として主に「履歴（ログ）のレビュー」が挙げられます。
職務分掌
経理体制における経理担当と財務担当の分離と同様に、IT統制においても、職務の分離は重要な概念です。
システムの開発および変更・保守手順として、まずシステム開発担当者が開発環境においてプログラム開発および単体テストを行います。
次に、システム開発担当者やユーザー側がテスト環境において統合テストや受け入れテストを実施します。
そしてテストが完了すれば、システム運用担当者がプログラムを本番環境に導入します。
このように、新システムもしくは変更されたシステムの本番環境への導入には、システム開発側とシステム運用側が職務を分離して相互牽制する体制を構築することが重要です。
手続きの定義・運用
システムの開発および変更・保守は、社内規程やマニュアル等で手続きを定め、それを遵守して行われる必要があります。
たとえば、ユーザー部門の要求によるプログラム変更の場合、ユーザー部門の担当者からの変更依頼書による起案から始まり、
→変更依頼書のユーザー部門の権限者の承認
→システム開発部門が変更内容と現行システムとの整合性を確認したうえでプログラム変更およびテストの実施
→システム運用部門およびユーザー部門による本番環境への変更実施の承認
→システム運用部門によるプログラム変更実施
→システム運用部門やユーザー部門による変更後レビュー
というような手続きが考えられます。
履歴（ログ）のレビュー
職務の分離や手続きの定義・運用は、リスクの発生を未然に防ぐ予防的統制であり、優先的に整備すべきものです。
しかし、職務の分離の場合、小規模企業であれば人員不足によりそれが困難な場合があります。
そのため、リスク発生事後の発見的統制として、システムの変更履歴（ログ）が記録される仕組みを整え、補完的に機能させることを考慮することも必要になります。
システムの開発、保守に係るIT全般統制の評価
IT全般統制の評価においては、業務プロセスに係る内部統制の評価と同様に、整備状況の評価と運用状況の評価を行います。
整備状況の評価
整備状況の評価においては、手法としてウォークスルーを実施します。
システムの開発および変更・保守について規定された一連の手続きを理解し、関連帳票等を確認して、リスクを低減する統制が適切に整備されているかを検討します。
運用状況の評価
運用状況の評価においては、手法としてサンプルテストを実施します。
システムの開発および変更・保守のプロセスに内在するキーコントロールを対象に、変更履歴（ログ）等からサンプルを抽出し、証憑となる帳票等を閲覧して、統制が設計どおりに運用されているかを確認します。
閲覧する帳票の例としては、プログラム開発・変更依頼書、テスト結果報告書、本番登録申請書等が考えられます。
