この記事はうるる Advent Calendar 2022の20日目の記事になります。
はじめに
うるるの技術戦略課でエンジニアをしております。
技術戦略課の業務の一部として、IT統制の支援をさせていただいております。
社内のエンジニアや外部のエンジニアの方と会話する機会があり、IT統制についてよく分かっていないエンジニアの方が多いことを知りました。
IT統制を理解することでエンジニアとしてもプラスの部分があると感じているのと、上場企業でエンジニアをしているのであれば知っておいてほしい内容なので、
今回は、上場企業所属エンジニアがIT全般統制を理解しておくべき2つの理由 を記述させていただき、少しでもIT統制に興味をもっていただくきっかけになれば幸いです。
※ IT統制はとっつきにくい内容なので、難しい説明はとばしていきたいと思います。
対象読者
- 働いている企業にIT全般統制が存在するエンジニアの方
- IT統制について全く知らないエンジニアの方
IT全般統制とは
まずはIT全般統制とはなんぞやの部分を簡単に記載させていただきます。
目的
業務プロセスにおける不正や誤りを防ぐための仕組み(業務処理統制）が、有効に機能する環境を保証するための統制
関係図
IT全般統制までの流れ
1. 上場企業は決算の開示が義務づけられている
2. 監査法人に決算内容が適切かどうかを第3者の立場からチェックをしてもらう必要がある
3. 社内で定めた内部統制というルールを内部監査室(※経営層)が監査する
4. 内部統制の一部にIT統制が存在する
5. IT統制の中に「IT全般統制」・「IT業務処理統制」が存在する
6. 「IT全般統制」はIT業務処理統制が有効に機能する環境を保証する統制である
7. IT全般統制で定めた内容を1年間を通して監査する必要がある
8. IT全般統制を実施するためにRCM(Risk Control Matrix)を定めている企業が多い
IT全般統制とRCMの関係性
「IT全般統制」はIT業務処理統制が有効に機能する環境を保証する統制です。
つまり、決算に利用するデータをITシステムで管理・出力している場合はIT全般統制を利用して、ITシステムを開発する際の業務プロセスにおける不正や誤りを防ぐための仕組みを整えないといけない
また、IT全般統制は4つの項目から成り立っており、
4つの項目を満たすことで業務プロセスにおける不正や誤りを防ぐための仕組みになっています。
・ システムの開発、保守に係る管理
・ システムの運用・管理
・ 内外からのアクセス管理等のシステムの安全性の確保
・ 外部委託に関する契約の管理
一般的に上記4つの内容をRCMとしてまとめていることが多い！
なので、RCMとIT全般統制は意味合いとしては同じであり、
各システムの開発業務プロセスや、発生するリスクから考えた対応策が記載されているものになっております。
もっと詳しく知りたい方
うるるCISOの長屋洋介さんのIT統制に関する記事をご確認いただけると幸いです。
今回のQiita記事で説明を省略している部分を補って頂けている内容になっております。
IT全般統制を理解しておくべき2つの理由
そんなIT全般統制を担当して、エンジニアが理解をしておくべきだと思った理由が下記になります。
理由① 各システム開発の全体像が理解できる
皆さんは自分たちが所属している事業部のシステムの全体像や、開発プロセスの全体を理解していますでしょうか？
理解しているまたは、理解しようとしていると思います。
多くの企業はサービス内に決算に利用するデータを保持していることが多いと思われます。
サービス内に決算に利用するデータを保持している場合は、IT全般統制の対象範囲もサービス全体になります。
その場合、サービス全体のシステムの開発業務プロセスや、発生するリスクから考えた対応策を実施必要があります。
なので、一部を除きIT全般統制にはサービス全体の業務プロセス内容や、システムの全体像の内容を記述されていることが多いので、
システム開発の全体像を一気に理解するのにとても良い内容になっております。
おすすめとしては、新しく入って頂いたエンジニアの方や新卒エンジニアの方に是非一度IT全般統制を読んで頂き、システム開発の全体像を掴んでいただければと思っております。
理由② IT全般統制のいいなりにならなくてよくなる
内部監査室などから年に1~2回IT全般統制の証跡の提出を求められたことがあると思います。
なぜその証跡を提出しなければいけないのか理解していますでしょうか？
また、IT全般統制で定めている開発業務プロセスがあるので、柔軟に開発プロセスの変更ができなかったり、システムの変更ができないといった経験はございませんでしょうか？
実は、IT全般統制の内容を理解していると、統制に振り回されないで、エンジニアが本来実施していきたい開発に集中することができるようになります。
年に1〜2回ある証跡に関しても、もっと楽に証跡を取得できる方法を仕組み化することもできますし、証跡の取得内容も変更することができます。
IT全般統制の内容で開発プロセスが固定されているに関しても、各事業部の開発方式にあわせた開発プロセスに柔軟に変更ができます。
事業部がやりたい内容をIT統制のしがらみをなくして開発ができるようにできます。
全て、IT全般統制のリスクと紐づく対応を理解していれば、各システムに合わせた柔軟なリスクコントロールの設計ができ、
IT全般統制に縛られない開発ができ、監査の手間がなくなり、リスク・コントロールをより効率的に実施することができます。
なので、是非、現在定まっているIT全般統制だけを信じずに、なぜやるのかを考え、
開発体制の変更にしたがってIT全般統制も柔軟に変化できるようにすればエンジニアの開発効率・開発組織力がより良くなると私は考えております。
最後に
IT全般統制(※RCM)はどこの会社も一緒の内容が多いそうです。
理由としては、上場したタイミングで作成する際に利用するフレームワークが同じだからです。
また、IT統制の知識があるエンジニアがあまりいないので、現場から声がでず最初に作ったのをそのまま利用するパターンがよくあります。
しかし、うるるでは各サービスに合わせたIT全般統制を作り直しに注力しており、より実情にあわせた内容に作り変えております。
今後もIT統制で縛られない開発ができ、監査の手間がなくなり、リスク・コントロールを効率的に実施できるようなIT全般統制の内容を作っていければと思います。
少しでも、上場企業所属エンジニアの方がIT統制について興味を持って、現状の開発プロセスをより良くしていく人が増えていくといいなと思っております。
以上です！！
明日21日目は @k_yamaki さんの記事になります！
お楽しみに！