IT担当者向けの上場準備 - 全体像を一気に理解。IT統制でラクするコツも知っちゃおう
こんにちは、株式会社うるる 取締役の長屋です。
今週も、妻と子と猫と楽しく暮らしています。
うちのニャンコは、最近抱っこが大好きです。子供を抱っこしていると、「俺も抱っこしてくれよー」というテンションで甘えてきます。
本日は「IT担当者向けの上場準備」を記事にしてみました。
弊社が2017年に東証マザーズに上場し、数年間運用する中で理解できたことを、できるだけ分かりやすく書いたつもりです。一気に全体像を理解することで、IPO準備が少しでもラクになれば嬉しいです。
なお、IT担当者とは、エンジニアや情シスの方を想定して書きました。
「上場を目指している会社のIT担当者」だけでなく、「すでに上場している会社のIT担当者」の方にもオススメです。全体像を理解することで、皆さんの「めんどくさい」の改善が加速することを願っています！
なお、できるだけ分かりやすくお伝えしたかったので、ポイントを絞って書いており、すべてを網羅的に記載できておりません。詳細は省庁公表の資料や、他のコンテンツを参考にしてください。
監査法人ってなに？
監査法人だけでなく、「監査」って名前がつく方がたくさん登場してくるので、よく分からなくなりますよね。簡単に図示してみましたが、とにかく皆さん連携して監査（正しいことをチェック）してくれています。
彼らの活躍が無いと、上場企業は決算を発表することができません！
もう少しだけ掘り下げるため、まず Wikipedia を見てみましょう。
簡単に言うと、「監査法人は、上場企業が公表する決算（業績数字）をレビューして、内容が正しいことを証明する方々」ってことですね。
監査法人（かんさほうじん）とは、他人の求めに応じ報酬を得て、財務書類の監査又は証明を組織的に行うことを目的として、公認会計士法34条の2の2第1項によって、公認会計士が共同して設立した法人をいう（公認会計士法1条の3第3項）。
なお、監査法人のお墨付き（監査証明）が出なければ決算発表ができません。このため、決算発表が延期される事態が稀に発生します。投資家さんの信頼を損なう事象なので、上場企業としてはぜひ避けたい事態です。
私がサッと思い出した決算遅延はこちらでした。スイマセン東芝さん、悪意は本当にありません。
PwCあらた有限責任監査法人は、東芝が提出した四半期報告書について、「結論の表明の基礎となる証拠を入手することができなかった」として意見を表明しなかった。
監査法人は、この調査について評価が終了しておらず、過去の工事損失引当金の認識時期など、ほかにも評価が終了していない調査事項があるとして、結論について表明しないことを決めたと説明している。
内部監査ってなにするの？
「内部監査」と混同しやすい言葉に「内部統制」があります。この違いを頭に入れておくと、理解が進みやすいです。
結論から言うと「内部統制はルール、内部監査はチェック」です。
内部統制は、企業が適切に経営や事業を進めていくためのルールや仕組み
内部監査は、内部統制が正しく機能しているかチェックをすることです
つまり、ちゃんと理解すべきは「内部統制」です。理解を進めていくために、金融庁の公表する資料での定義を確認していきましょう。内部統制の4つの目的が明記されており、特に「財務報告の信頼性」がIT部門の上場対応に影響を与えます。
業務の有効性及び効率性
財務報告の信頼性
法令等の遵守
資産の保全
内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の４つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内の全ての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びＩＴ（情報技術）への対応の６つの基本的要素から構成される。
IT統制が必要になる理由
財務報告とは、公表する決算（業績数字）のことです。いまどきは、元となるデータは殆どがシステムで処理されますよね？ このため、データを作り出すシステムの信頼性が求められ、「IT統制（情報システムに関する内部統制）」が必要になるって寸法です。
「IT統制（情報システムに関する内部統制）」と言われても良くわからないですよね。統制とは適切に業務を進めるためのルールや仕組みですので、「IT統制は、情報システムに関連するルールや仕組み」と理解しておきましょう。一般的に構成要素は3つと言われており、以下のとおりです。
IT全社的統制 = ITシステムを管理する仕組み（体制やルール）を作る事
IT全般統制 = ITシステムを適切に運用するための活動（リスクと対策）
IT業務処理統制 = ITシステムで作られたデータを確認する人の作業
上場対応を行う中で、仕組み（体制やルールなど）を作ることになるので、IT全社的統制は自然とクリアできます。また、システムで作られたデータをチェックするのは事業部門であることが多いので、IT業務処理統制もIT担当はあまりやることがありません。
つまり「上場対応として、IT部門の人が頑張るのはIT全般統制」です。システム屋として、システムの信頼性を維持していくミッションを果たしていきましょう！
IT全般統制で必要になるRCM
RCMとは「リスク・コントロール・マトリクス」のことです。
RCMの作成は必須ではないものの、内部統制の基本的要素に「リスクの評価と対応」があるため、「整理に便利だからRCMを利用している会社が多い」のが実情なんだと思います。
内部統制の定義を確認すると６つの基本的要素が明記されており、リスクに関する言及もあることが分かります。
統制環境
リスクの評価と対応
統制活動
情報と伝達
モニタリング（監視活動）
ＩＴ（情報技術）
内部統制とは、基本的に、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守並びに資産の保全の４つの目的が達成されているとの合理的な保証を得るために、業務に組み込まれ、組織内の全ての者によって遂行されるプロセスをいい、統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング（監視活動）及びＩＴ（情報技術）への対応の６つの基本的要素から構成される。
リスクを評価するためには頭の中だけでは出来ませんので、文章化を行っていくことになります。この時出てくるのが、内部統制やJ-SOXで目にすることが多い「３点セット（フローチャート、業務記述書、RCM）」です。
ちなみに、金融庁の公表では「３点セット（RCM含む）の作成は必須ではない」と仰ってますが、なんだかんだ便利だからRCMを作成している会社が多いのだと私は想像しています。
2.特別な文書化が必要か
(誤解)
フローチャートの作成など、内部統制のため新たに特別な文書化等を行わなければな らない。
(実際)
企業の作成・使用している記録等を適宜、利用。
(具体例)
フローチャート、業務記述書などの作成は必ずしも求めておらず、企業の作成・使用してい る記録等を利用し、必要に応じて補足を行うことで可。
RCMの中身を見てみよう
今回は、経済産業省が公表する下記ドキュメントの「付録6-2 IT全般統制評価記述書」を題材に、一緒に具体的なRCMの中身を見ていきましょう。
システム管理基準 追補版 (財務報告に係る IT 統制ガイダンス) 平成19年3月30日 経済産業省
統制目標（リスク）の確認
このサンプルにおける統制目標のポイントは、大きく２つです。
リスクは統制目標の裏返しとも言えますので、以下のように捉えることもできます。
リスク：プログラムが改ざんされる
リスク：プログラムが勝手に変更される
私は「リスクｘコントロール（対策）」の図式の方が考えやすく、より目的に対して仕事がダイレクトに進められるよう感じるので、リスクを中心に列挙していくことが好みです。では少し解説していきます。
目標：プログラムが改ざんされない
「改ざん」と聞くと、危険な響きに聞こえますよね。外部から攻撃を受けて、勝手にプログラムが変更されてしまうイメージかと思います。
IT全般統制的には「内部の人が勝手に（他の人の確認無しに）変更できては駄目だよ」と理解するのが良いです。レガシーなやり方だと「開発担当とリリース担当を分けて、開発者が勝手にリリースできないようにする」などが採用されていたとお聞きしたりします。
今どきでしたら「基本的にリリースを自動化して、GitHub マージブロックで承認する」などの対応が考えられますね。
目標：プログラムが承認なく変更されない
承認の意味する対象が多岐に渡る可能性があるのが、このコントロールのややこしい所です。
リリース承認であれば前述のGitHubマージブロッカーだけでいいのですが、着手承認や受け入れテスト的な承認など、「開発プロセス上の重要な承認をすべて適切に通過」しなければいけません。
どの会社さんでも業務上やっていることも多いと思うので、自然と承認の記録が残るように設計していくのが良いと思います。
統制評価（内部監査）の確認
次は同じサンプルの統制評価（内部監査）の手続きです。
この会社では、以下の仕組みとチェックを採用していることが読み取れます。
統制評価はサンプリング方式。25件抽出して、ルールが守られているか？を評価している
承認の記録には押印を利用している
統制評価はサンプリング方式
よくある手法だと思います。ランダムに抽出するのがポイントです。
25件なら余裕じゃん！と思うかもしれませんが、エビデンスを全て集めるのはなかなか骨が折れます…。画面キャプチャが多用される世界です。
承認の記録には押印
サンプルは平成19年の文章なので、押印で承認する会社が実際に多かったんだと想像しています。今どきは開発ツール（プロジェクト管理ツール等）上で、何かしら承認の記録を残す方々が多いと思います。
なんとなくRCMが理解できましたか？
まずは「なんとなく」で十分ですが、これを以下のようなシステム開発のシーンにそって、整備・運用していく必要があると理解してください。
各業務フローに存在する様々なリスクを明らかにして、リスト毎にコントロール（対策）を決定していく必要があります。ご想像どおり、なかなか骨が折れる作業です。
システムを開発する（開発稟議、テスト、リリース）
システムを運用する（バックアップ、ジョブ、監視、セキュリティ）
システムを管理する（アカウント管理、適切な権限、モニタリング）
運用も監査対応も大変
ルールを作るのも大変ですが、運用するのも、監査対応をするのも大変なんです。まぁ普通に「めんどくせー」と不満を言いたくなりますよね！
結果、RCMがスピードを阻害し、現場から不満が吹き出すわけです...。
RCMを利用してリスクと対策が明確になり、監査の結果が記録されるということには勿論メリットがあります。業務フローが明確になり、属人化が排除され、ミスが減り、働きやすくなっていくことに繋がります。
ただ、いきなりは難しいですよね？ 手間が増えるのは事実ですから...。
このため「なぜやるのか？を説明し、意義を見出しながら、一歩ずつ文化を作っていくことが大切」だと、本当に感じています。弊社もまだまだ良い文化を実現できていないと感じますので、一緒に頑張っていきましょう！
ラクしてリスクをコントロールするコツ
文化作りはさておき、ラクをするのは正義ですよね。
ではどうやって、解決の糸口を見い出していけばよいのでしょうか？
私は「ルールは自分たちが決めるもの」がポイントだと感じています。
「内部統制は、企業が適切に経営や事業を進めていくためのルールや仕組み」です。しかしながら、絶対的なルールが世の中に存在するわけではないんです。人間誰しも答えを求めがちですが、この勘違いのお陰で私は無駄な動きをしてしまった時期がありました。「正しいルールは何？」ではなく「良いルールを自分で考える」が正解です。
なので当たり前のことですが、改めて皆さんには認識しておいていただきたいです。「自分の会社のルールは、自分で決めるもの」です。コンプライアンス（法令遵守）を実現しつつ。ぜひ、適切にリスクをコントロールできるルールを、自社にフィットするように自分たちで作っていってください！
「なるほど...。だけど、もっと具体的なコツを知りたいです。ラクをしたいですよ！」ごもっとも。私の知ってるコツを共有しますね。
自動化を進める
前述の通り、皆さんが大好きなGitHubのマージブロックは、立派なコントロールの仕組みです。自動化と組み合わせることで、以下の論理を組み立てることが出来ると思います。
「レビューしないと、マージできない仕組み」があり
「マージできなければ、リリースできない仕組み」があれば
内部監査上は「マージブロックの設定が適切なことだけをチェックすれば良い」
自動化すると人が介入する要素が無くなるので、ミスをする可能性も、ズルをする可能性も生じません。皆さんの大好きなDevOpsを、内部統制も考えながら進めていけば良いと思います。
監査法人のチェック範囲を限定する
1つの巨大なシステムの中で、サービス提供も勘定データ作成も行っていると、システム全体が統制対象（決算のための監査の評価対象）になってしまいます。
昨今流行りのマイクロサービスアーキテクチャへの移行は簡単ではないですが、上手にシステムを分割することができれば、統制対象をせばめることができ、統制の運用負荷を下げることができます。
もちろん統制対象から外れたとはいえ、品質維持のために似たようなリスクコントロールを行うケースは多いと思います。しかしながら、ルール設計の自由度が増しますので、開発チームがスピーディーにフローを改善していくことが可能になります。
自社がB2BのWebサービスを提供しているのであれば、決算に関するデータは販売管理システム（SFA）に任せて、プロダクトに集中することで顧客満足を追求するのは、良い作戦ではないでしょうか？もちろん、販売管理システムの内部統制は必要になりますので、お忘れなく！
ついでに知りたいFAQ
よくありそうな Q&A を、勝手に FAQ 形式でまとめてみました。
参考になれば嬉しいです。追加すべき内容があれば、ぜひ教えてください！
Q) すべてのリスクに対策する必要があるのか？
リスクを評価した上で、リスクを受容することも可能です。
ただし、リスクの受容が妥当であることを、内部監査室・監査法人からお墨付きを得なければいけません。結果、追加のコントロールを行うことになることも多いです。
例えば「業務フロー上、アカウント発行は承認無しで進めざるをえないが、定期的に棚卸しすることでリスクに対処する」などが考えられます。
Q) 内部統制ルールを変えたい、誰と話して、どう進めればよいか？
基本的には、IT統制を担当チーム（RCMを作成する方々）で話し合い、ルールの改定を進めていけば良いと思います。ただし、出来上がったルールは内部監査室にレビューしてもらいましょう。
場合によっては、「監査法人と協議しましょう」となる場合もありますが、内部監査室の方々が判断してくれると思います。
Q) 新規事業はスピード命。統制なんて無理なんだけど...？
結論から言えば、「新規事業は、ほぼ内部統制の評価範囲外」です。
なぜなら、新規事業の売上が、全体の5%を占めることは起こりにくいからです。金融庁は公表する資料で、売上の95%を内部統制の評価範囲としてカバーするように示しています。
（問３）【全社的な内部統制の評価範囲】
例えば、売上高で全体の 95%に入らないような連結子会社は僅少なものとしてはずすといった取扱いは一般的なものであると承知している。
ちなみに、最終的な評価範囲は、売上割合だけでなく「業務プロセスの評価範囲」を加味して決定されます。1つずつ丁寧に判断していく選定プロセスが存在しますが、ITエンジニア的には「売上の95%」というマジックナンバーだけでも覚えておけば良いと思います。
Q) SaaSを組み合わせて業務してる、どうしたらいい？
財務報告（決算作成）のインプットとなるデータを作成しているSaaSを、IT統制の対象としましょう。その上で、SaaSの設定変更をシステム開発と同等に捉えて、リスクをコントロールしていけば良いと思います。
まとめ
いかがでしたでしょうか？上場準備の全体像を、一気に理解することができましたか？至らない点があれば、ぜひ教えて下さい。どんどんアップデートしていきます。それでは今日のポイントのおさらいです。
IT担当者の上場準備 ＝ 内部統制 ＝ IT全般統制
IT全般統制では、RCMが外せない
自動化を進めて、IT全般統制をラクにしていこう！
範囲を限定して、IT全般統制をラクにしていこう！
「ラクをするのは正義」。私のとても好きな言葉です。
とはいえ、黙っていてもラクはできません。ラクをするための努力が必要ですよね。共に頑張っていきましょう！
協働すると言えば、「RCMを晒し合う会」を個人的にはやってみたいな〜と思っています！お互いのノウハウを交換して、仲間になって、お互いの統制がスムーズに進んだら最高ですよね。
ご興味ある方いれば、ぜひご連絡ください〜。
この記事が気に入ったらサポートをしてみませんか？