PR

土居 貢
KPMGビジネスアシュアランス
マネージングディレクター

ユーザー企業のPM(プロジェクト・マネジャ)にとって、「内部統制」や「日本版SOX法」といったキーワードは無視できないものになりつつある。企業のビジネスに情報システムが欠かせない存在になっている以上、要件定義の段階から内部統制を意識してシステムを開発していく姿勢が必要になる。

 企業が対応しなければならない経営課題はさまざまある。なかでも多くの企業が取り組むべき課題として急浮上しているのが、日本版SOX法(企業改革法)を見すえた内部統制への対応であることに異論はないだろう。内部統制および日本版SOX法については、すでに日経コンピュータで多く説明されており、書籍やWebサイトでも情報を容易に入手できるので、詳細はそちらをご覧いただきたい。

 ここで強調したいのは、PMはシステム開発プロジェクトを運営する際に、各工程で「内部統制をいかに確保するか」に配慮する必要があるということだ。今回は要件定義フェーズにおける注意点に触れる。

 これまでの連載では実際のエピソードを紹介してきたが、今回は趣向を変えて、近い将来に繰り広げられるであろう光景をご覧いただきたい。

「統制の状況を説明してください」

 流通業A社は購買システムを再構築した。その直後、PMのB氏は利用部門である商品管理部のC氏とともに、内部監査室のX氏からヒアリングを受けることになった。

 X氏はB氏に対して、「この購買伝票を正確にシステムに入力するための統制はどのようなものがありますか」と尋ねた。B氏は、用意していたいくつかのドキュメントを机に並べる。購買システムにかかわる業務の流れを示した「業務フロー図」、想定されるリスクや、それらに対する統制(コントロール)を業務ごとにまとめた「リスク・コントロール・マトリックス(RCM)」、および「統制目標一覧表」である。いずれもプロジェクトの要件定義工程で作成したものだ。

 B氏はこれらをX氏に見せながら、質問に答え始めた。「購買伝票の入力画面では、金額欄に数字しか入力できないガードをかけています。また、商品コードによって金額の範囲にチェックをかける仕組みを採っています。入力された金額や数量が一定以上になると上席者に通知が行きます。上席者が承認しない限り、伝票の処理は完了しません」。同席していたC氏も、「17時の締め処理時に当日入力一覧表を出力し、原票と突き合わせ確認を実施しています」と説明した─。

 言うまでもなく、内部統制の有効性評価に関するヒアリングの様子である。日本版SOX法の施行を機に、こうしたやり取りが多くの企業でなされるようになるだろう。

 A社の例は「業務処理統制(アプリケーション・コントロール)」に関して示している。ご存知の方も多いと思うが、ITにかかわる内部統制には大きく業務処理統制と「全般統制(ゼネラル・コントロール)」の二つがある。前者は売り上げ管理、購買管理、在庫管理、生産管理といった業務にかかわる統制を、後者はシステム開発や運用を含めた、利用部門の業務を間接的に補完する作業にかかわる統制を指す。全般統制に関しては、次回に詳しく説明したい。もうひとつ、近い将来起こりそうな例をご覧いただきたい。

「どうして証明できるんですか?」

 D銀行で会計システムを担当するP氏は、会計監査人のZ氏から内部統制の有効性評価に関する質問を受けた。「この会計システムが出力する日計表の正確性は、どのように証明できるのですか?」。

 P氏は、「このシステムは本稼働から5年以上たっています。初期には多少のトラブルはありましたが、ここ数年は安定していてトラブルは全く発生していません。まず信用して大丈夫だと思いますよ」と答えた。

 Z氏は続けて、「安定稼働しているのは分かりますが、システムにどのような統制が組み込まれているんですか?」と聞いた。P氏は、「つまり、プログラムが正確な処理を行っているということですよ」と答えた。これに対し、Z氏は「プログラムが正確に処理していると、どうして証明できるんですか?」とさらに突っ込んだ。「ですから、プログラムは開発時点で十分テストをしていまして…」。P氏は困った様子で返答を続けた。

 D銀行の例も、業務処理統制に関するものだ。ただ、A社の例はユーザー・インタフェースのような「見えるモノ」に関する統制なのに対し、D銀行の例はプログラムのロジックのような「見えないモノ」に関する統制であるという違いがある(図1)。ここで「見えない」は、業務部門のユーザーや内部監査人、会計監査人にとって見えにくいという意味で使っている。

図1●PMは要件定義の段階で内部統制を意識しなければならない
図1●PMは要件定義の段階で内部統制を意識しなければならない
[画像のクリックで拡大表示]

 内部統制を説明しやすいのは、前者の見えるモノのほうである。ただ、見えるか見えないかにかかわらず、内部統制に関して説明できるようにするには、システム開発プロジェクトの要件定義段階での作業が不可欠になる。この段階で、内部統制を意識して業務要件やシステムの機能要件を検討し、その結果を「見える化」したドキュメントを作らなければならない。

業務要件の項目ごとに統制を定める

 見えるモノに対する統制は、通常のプロジェクトにおける業務要件定義をより詳細に実施すると考えればよい。

 A社の例に即して言えば、最もシンプルな要件定義は「商品購入伝票を入力する。入力内容は商品コード、数量、単価、金額」といった形になるだろう。その際に、何らかの形で誤入力を防止する仕組みを組み込むのが普通だ。内部統制の観点では、個々の項目ごとに誤入力を防止する統制を定義することが重要である。例えば、商品コードの入力ミスを防ぐために、コードを直接入力させるのではなく、商品一覧からプルダウン・メニューで選択できるようにする。単価は商品マスターに持たせて、入力しなくてすむようにする、のように決めていく。

 こうして挙げてみると、当たり前のことのように思われるかもしれない。確かにその通りなのだが、それらをすべて要件定義書に明確に記載しているかというと、必ずしもそうではないのがほとんどだろう。

 理想を言えば、業務分析作業の一環として、システムの利用手順を含む業務プロセス図を作成し、そのプロセスにおけるリスク(日本版SOX法の場合は、財務報告の虚偽表示につながるリスク)とそれに対する統制をまとめたドキュメントを作成しておくのが有効だ(図2)。最低でも、要件定義書を作成する際には正確性を担保する統制目標を記載しておきたい。A社の例なら、「伝票が正確に入力され、財務報告の虚偽表示を防止できる機能を付加する」といった具合である。

図2●見えるモノに対する業務処理統制で必要な作業の例
図2●見えるモノに対する業務処理統制で必要な作業の例
[画像のクリックで拡大表示]