PR

Part3では,IT部門はこれから,どのようなことに注意しながら作業を進めればよいのか,どのような文書を作れば監査に耐えうるのかを見ていくとともに,システム開発の現場において最低限注意すべきポイントについて,説明しましょう。

 IT部門はこれから,どのようなことに注意しながら作業を進めればよいのでしょうか。

 内部統制の整備業務の多くは,文書化作業にあてられます。内部統制にかかわる文書は,業務を制度化・標準化するという社内利用における目的のみならず,内部統制監査という社外の第三者への証拠資料にもなるのです。したがって,内部統制監査に耐えうるレベルで作成する必要があります。

 それでは,どのような文書を作れば,監査に耐えうるのでしょうか。実施基準においては,「内部統制に係る記録の範囲,形式及び方法は一律に規定できない」(実施基準II.3.(7) (1))としながらも,以下のようなものが例示がされています(図8)。

図8●内部統制の記録
図8●内部統制の記録

 また,実務上,業務プロセスに係る内部統制の整備にあたっては,次の3つの文章を作成するのが,一般的です。

(1)業務記述書
個々の業務における作業内容や手順を記述した文書。管理方針や職務分掌なども含まれる。

(2)業務フローチャート
業務の流れをフローチャートの形式で記述した文書。

(3)リスク・コントロール・マトリックス(RCM)
業務プロセスのどこにリスクがあり,それをどのようにコントロール(統制)しているのかを記述した文書。

アサーションとは

 図8で示した記録の例示の中に,「実在性,網羅性,権利と義務の帰属,評価の妥当性,期間配分の適切性,表示の妥当性」という記述が含まれていますが,これらは,「適切な財務情報を作成するための要件」であり,「アサーション」とも呼ばれます(図9)。

図9●アサーション
図9●アサーション

 このアサーション(assertions)という英単語は,本来,「主張」という意味があります。経営者は,適正な財務諸表を作成する責任を有しています。そこで,自らが作成した財務諸表の適正性を証明するためには,これらの要件を第三者に対して「主張」できなければならないのです。

 財務報告に係る内部統制の整備は,最終的には,これらアサーションに対するコントロール(統制)が十分か否かがポイントになります。このため,文書化においても,アサーションとコントロールの関係が明らかになるように記述する必要があるのです。

「今,ここにある危機」にどう対処するのか

 内部統制が法制化されたことによって,ITシステムに課せられたハードルは益々高くなったといえるでしょう。その中でも,筆者が最も憂慮しているのは,既存のシステムよりも,むしろ現在開発中のシステムです。

 既存システムが有する内部統制上の不備は,開発時点では考慮できなかったものとして許容せざるを得ないともいえますが,内部統制が法制化された以降,まさに現在開発しているシステムが,稼働直後に内部統制上の不備を指摘されてしまったらどうでしょうか。製品の瑕疵(かし)ともとられかねません。

 その一方で,この厄介な内部統制の知識を開発メンバーに教育し直すだけの時間の余裕もないのが現実でしょう。

 そこで,システム開発の現場において最低限注意すべきポイントを4つに絞り込みました。システム開発をする際には,常に以下の4つの視点を意識してください(図10)。

図10●開発現場における4つの視点
図10●開発現場における4つの視点

(1)実在性

 ここでいう「実在性」は,適切な承認を受けたものであるかという正当性や準拠性といった概念も含んでいます。システム開発に携わる方々ならば,通常持ち合わせている「正確なデータ」という感覚でとらえていただいて結構です。

(2)網羅性

 取引の漏れがないかという「網羅性」を確認することは,大変,難しい作業になります。したがって,この網羅性を確保または確認する手続きは,システム設計時に考慮しておく必要があります。後から対応するのは困難です。

(3)適時性

 「適時性」という概念は,各取引が適切な会計期間に計上されるかという「期間帰属」の妥当性を意味しています。これは,完全に会計上の議論ですから,システム的な視点だけでは,見落とされてしまうのです。その反面,取引の期間帰属(監査用語では「カット・オフ」といいます)という論点は会計監査や税務調査において,必ず確認されるところですから,十分な注意が必要になります。

(4)分類の妥当性

 最後の「分類の妥当性」というのは,システム的に言い換えれば,適切な勘定科目が設定されるかということです。金額も期間帰属も正しく,適切な承認が行われていても,最後に付与される勘定科目が間違っていては,元も子もありません。システム設計時には,各データに付与される勘定科目(および消費税区分など)が,どの時点でどのような手続きで決定されるかを確認し,その信頼度を検討してください。

 この4つの視点は,筆者の経験則から抽出したものであり,内部統制上の論点を網羅したものではありません。しかし,内部統制監査が財務報告に係る内部統制を対象にしているためアサーションが重要になることや,システム開発の対象は期中における継続的・反復的な業務が中心であり,期末時点で行われる評価・見積もりといった業務は通常,対象から除かれることを考慮すれば,まずはこの4つの視点に注力することによって,致命的な見落としを避けることができると考えます。

 内部統制が法制化されたからといって,いたずらに恐れる必要はありません。求められる要件のほとんどは,従来からのシステム開発においても当然に考慮されていたものだからです。

 とはいっても,既存のシステムが内部統制上の要件をすべて満たしているわけではありませんから「財務報告」や「監査」という新たな視点からシステムを見直すことで,不備を一つずつ改善していかなければなりません。それらを受身にとらえるのではなく,システムの品質向上の一環として前向きに取り組んでいきましょう。