こんにちは！本日も皆様にお役立ち情報をお届けします！ぜひ最後までご覧ください。

皆さんはit全般統制についてご存じですか？

またそれを統制するチェックリストがあることをご存じですか?ネット社会と言われている世の中で、この言葉を知らなければあなたは今後、時代の流れにますます置いて行かれることでしょう。

そんなあなたにこれからit全般統制について解説します。

it内部統制について

まず始めにit全般統制を知るためには内部統制について知る必要があります。

内部統制とは企業が事業としての活動を継続するために作成する社内ルールや体制のことで、仕事の効率を上げたり、作業中のミスや不正のリスクを減らすことで社員に社内ルールを遵守させます。内部統制を2つに分けて説明します。

it全般統制

it全般統制は各企業のit業務処理統制がきちんと機能するように信頼性を確保し、統制することです。

itを有効活用するには企画、開発、運用、保守といった活動、その活動を支える組織や制度などを作り上げる必要性があります。

it業務処理統制

企業が行う活動においての業務中の流れで機能する統制のこと。業務処理システムの中のデータの情報量、情報が正確であるかどうかや正当であるかどうかを自動で管理しコントロールします。

チェックリストとは

it全般のチェック(評価)を行う上で、システム開発関連の専門用語やitインフラの知識やitに関わる経験などは特に必要ないです。

it全般統制の中の『システム開発』や『システム変更』に関する業務「プロセス」、「リスク」、「コントロール例」、「評価ポイント」について解説をします。

システム開発

システム開発は以下の段階で進めていきます。

システム開発の評価ではシステム部門が承諾しているかどうかだけではなく、ユーザ部門の承諾が行われているかどうかを確認します。

1.企画・選別

プロセス：業務の需要に合ったシステムを検討し、選びます。システムのユーザ部門と連携を図りどんなシステムを導入すればいいのか考えます。

リスク：授与に合ったシステムを作ることが出来ず、業務として動かない可能性がある。

コントロール例：選別した結果を稟議書(何か購入、契約した際に会社の上層部の総意を得るために記入する書類)に添付したり、回覧したりして決裁者が承諾する。

評価ポイント：選別した結果が保管され、決裁者が承諾しているのかしていないのか。

2.要件の定義

プロセス：システムに必要だと思う機能を決めどういった仕様が合うのかを決めます。

リスク：設定をした通りにシステム開発されておらず、利用不可である。

コントロール例：作成済みの要件定義書を見てユーザ部門が承諾する。

評価ポイント：要件の定義書が作成済みでユーザ部門が承諾しているかいないのか。

３.システムの設定

プロセス：システム部門やitベンダーにてどう設計するのかを考えます。このときに2の要件の定義をベースにするのが良いでしょう。

リスク：要求通りのシステム設計が安全かどうか分からない。

コントロール例：システム設計をして、システム部門長から快諾を得られるようにする。

評価ポイント：快諾を得られるかどうかシステム部門に確認。このときに提出するものはシステム設計済みのものである。

4.システムの開発と導入

プロセス：開発、導入を既に設計が終了しているシステムで行います。

リスク：適切に開発や導入を行わないと不正や誤りのリスクがある。

コントロール例：システム部門長からの快諾を得た後はシステム開発が完了したことを報告します。

評価ポイント：システム部門長から快諾が得られているのか得ていないのかを確認。そして開発が完了したものが保管されていること。

５.テスト

プロセス：テストして注文通りに開発されていれば大丈夫。

リスク：安全かどうかが確認出来ないので、条件を達成していないのかもしれない。

コントロール例：ユーザ部門からのテストを受けて定義の内容通りであれば快諾は得られる。

評価ポイント：ユーザ部門からの快諾を得ること。必ずテスト結果が残っていることを確認する。

6.本番に移行する

プロセス：確認をするためにシステムに何か問題があるのかどうかを見ます。過去データを新バージョンにアップデートし、システムをすぐに使えるようにするための準備をします。

リスク：システム移行が万全に済んでおらず、保証が数値で判定不可である。

コントロール例：ユーザ部門からの快諾を得ること。その後本番用に使うデータ移行が完了したことを報告する。

評価ポイント：ユーザ部門からの快諾を得ていること。データの本番用のものの移行が完了していること。

システム変更

下記の手順に沿えばシステム仕様の変更などが行えます。

1.変更の依頼

プロセス：業務変更するとともにユーザ部門からシステム部門へとプログラム変更をします。

リスク：適切ではないシステム変更をしてデータの信頼性がなくなる。

コントロール例：変更申請によって変更を依頼し、ユーザ部門長が承諾する。

評価ポイント：変更の依頼内容の記録が保管されて、ユーザ部門が承諾しているかどうか。

2.変更の実施

プロセス：業務の変更と共にユーザ部門からシステム部門へ変更する。

リスク：適切ではないシステム変更をしてデータの信頼性がなくなる。

コントロール例：快諾を得るためにユーザ部門長に見せます。変更申請書類にて変更依頼する。

評価ポイント：ユーザ部門からの快諾を得られていれば安心。変更依頼書が保管されているのかどうかも確認。

3.変更テスト

プロセス：変更済みのプログラムに影響がないか、依頼内容と一致しているかをユーザ部門がチェック。

リスク：要件が適正か不適正かを確認できず、安全性が欠けてしまう。

コントロール例：変更申請済みのテストを載録したものを残し、ユーザ部門長が承る。

評価ポイント：テストしたという載録されたものが管理され、ユーザ部門が承っている。

4.本番の環境へ移行

プロセス：プログラムを組みテストが完了したらプログラムを本番と同じような環境に移します。

リスク：適正でないプログラムが移され不正処理であるかどうか確かめる。

コントロール例：変更申請された移行した載録されたものをシステム部門長が承る。

評価ポイント：本番の環境へ移してみて載録されたものの管理されてシステム部門が承っているのかいないのか。

5.移行テスト

プロセス：本番の環境へ移したら、ユーザ部門がプログラムに何かしらの影響がないか以来通りの内容になっているのかチェックします。

リスク：ユーザ部門の指示通りにシステム利用できない。

コントロール例：変更を申請した結果をチェックし、ユーザ部門長が承る。

評価ポイント：本番の環境へ移し載録されたものが管理されていてユーザ部門長が承っているのかいないのか。

まとめ

今回はit全般におけるチェックリストについてまとめました。it全般統制とは内部統制をitに任せて行うことです。そうすることによって面倒なことを全て機械にやらせます。

itの全般のチェックを行うにはシステム開発における企画選別、要件定義、システムの設定、システムの開発と設定、テスト、本番に移行という項目にてチェックを行います。

システムの変更においては、変更の依頼をし、変更を実施後テスト行い本番への環境へと移し、移行ができるかテストします。it全般統制にはこれらのチェックリストを用いて確認し、itを有効活用しましょう。