内部統制プロジェクトの品質

過去に経験をしたことがないプロジェクトを実施しています。内部統制プロジェクトをどのように実施したかという事例は、ほとんど外部に公表されていません。
企業としては当然でしょう。しかし、事例を知れば、どのようなことを考慮してプロジェクトをマネジメントするか、その方法がおぼろげながら分かります。
ウォークスルー、運用テストと連続して行い、統制の有効性を評価するわけですが、実施してみるといろいろな問題が出てきます。いわば、ITプロジェクトのテストフェーズです。ただし、単体テストレベルですが。
ここで、バグを洗い出すわけです。文書に書かれてあることが実施されていない、内容に漏れが発見される、例外処理が発見される、実施している統制が処理量が多く、統制の意味合いを持っていない…など、非常に多くのことが発見されます。


これらのことは、文書化時点で、記述方針を詳細に決定していても出てきます。バグが皆無になることがないのと同じです。
従って、作成した文書をどのようなタイミングで、どのような場合に修正するかを計画しておかなければなりません。内部統制プロジェクトは文書の修正が何度も入ります。
業務記述書の内容の不備、フローチャートの粒度の問題、業務内容の確認など最初の文書化で決めておいても発生します。
文書の書き方、フローチャートの書き方などの標準化をどのようにするか、また、文書化時点では必要ないと思われた情報が必要になってきたりします。いくら標準化したといってもそのとおり行かないものです。
メンバーへの徹底も絡みます。
例えば、業務記述書で、5W1Hを書くのは当たり前ですが、その業務処理量は運用テストに入る前に必要となります。全体を俯瞰して、どのような情報がどの時点で必要になるかを考え、最初から計画を立てておかなければなりません。そうでないと、何度も現場に足を運ぶことになってしまいます。(今痛感しています。)
また、業務プロセスのシナリオが1つではなく、数個のサブプロセスに分かれる場合にプロセス自体を分けて文書化するか、1つのプロセスに含めて文書化するといったことも予め決めておかなければなりません。
プロジェクトマネジメントとして、「段階的詳細化」と言えば聞こえは良いのですが、何かすっきりしません。
さらに、プロジェクト自体は財務リスクをスコープとして実施する場合でも、ウォークスルーを実施すれば、業務リスクが見えてきます。その場合、見つかった業務リスクをどのように扱うかも決めておかなければなりません。
例えば、業務リスクを現場責任者へ報告するのみでプロジェクトとしては提言しないなどの方針です。本当にこれで良いのかという疑問が常に頭によぎります。
財務リスクよりも、業務リスクの方が、はるかに企業に与える影響度は大きなものになります。これを他人任せにしてよいのかと言う疑問です。
しかし、プロジェクト的には、正解です。むやみやたらにスコープを広げていけば、プロジェクトは完了しません。
結局のところ、プロジェクトとしての品質をどの程度にするかという問題にたどり着いていしまいます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*