前回に引き続き、日本版SOX法対応プロジェクトの「基本計画ステージ」で検討・実施すべきことについて解説する。今回は「タスクの定義」「ロードマップの作成」「プロジェクト体制の構築」を取り上げる。
IBM ビジネスコンサルティング サービス
【４】プロジェクト・タスク定義、ロードマップ作成
これまでの作業によって、重要な勘定科目、拠点、プロセスが分かってきましたので、それを具体的に可視化する作業の計画を立てます。我々の事例では、現在基本としているタスク・スケジュールをベースにして、日程を割り当てたものを作成しています（図7・8）。
 |
図7●タスクの詳細 [画像のクリックで拡大表示] |
 |
図8●タスク・スケジュール [画像のクリックで拡大表示] |
●既に業務改革（BPR）プロジェクトが実行中である場合には、内部統制プロジェクトとどういう関係になるのか?
この論点は、プロジェクト目的設定時にも登場しがちなもので、内部統制に関する理解そのものにからむ難しい問題です。内部統制が既に定着している運用後の状態とまさに内部統制をこれから構築していこうという運用前の状況に分けて説明します。
（ア）運用後の状態
内部統制が運用後の状態を示したものが図9です。COSOや、日本版SOX法が要請している内部統制が構築されている場合のBPRプロジェクトやシステム構築プロジェクトは、図に示すような関係になっています。内部統制プロセスは、それが構築されていれば業務の有効性や法令順守が自動的にうまくいっているような便利なものではありません。これまでの定義を見ていただければ、なんとなく分かると思いますが、内部統制は企業の最新状態の業務およびリスクの状況、リスクが顕在化している場合の対処方法などのトレースが得られますが、最適経営の自動操縦システムではありません。放っておいても、内部統制さえしっかりできていれば、あたかも決算早期化や抜本的業務改善などが自動的に行われるようなものではないのです。
 |
図9●ほかの改革プロジェクトと内部統制プロジェクトの関係 [画像のクリックで拡大表示] |
内部統制で提供される様々な情報や活動が契機、あるいは参考となって、経営者は最適な業務の再構成やシステム開発を行うのが本来の形です。従来のような可視化されていない状況では、BPRプロジェクトなどが発足するたびに業務を分析したり、課題を洗ったりしますが、新しい内部統制プロセスが軌道にのっていれば、これらの作業が大幅に割愛されます。すなわち、全社業務改善プロジェクトにしろ、ERP（統合基幹業務）パッケージのビッグバン導入的なシステム再構築にしろ、現状分析資料は、一定の形でほとんど全部のプロセスで提供されていますから、必要な部分を詳細化すればよくなり、すばやくTO-BE設計の検討にいけるようになります。
また、これらのプロジェクトが完了して、新しいプロセスが誕生すれば、それをAS-ISとして内部統制で必要な文書として随時更新されていくわけです。これが本来の状態であると考えられます。
（イ）BPRプロジェクトなどが先行している場合
このような内部統制を実現している会社は現時点では少なく、むしろBPRプロジェクトなどが先行して存在している会社のほうが多いでしょう。なぜ、（ア）を先に紹介したのかと言うと、内部統制で狙っている効果とは、（ア）のような状態なので、仮にBPRやシステム構築が先行していたとしても、内部統制プロジェクトで提供できることは変わらないと考えるからです。
したがって、これからプロジェクトを立ち上げる会社で、このような背景がある場合には、「そもそも内部統制が機能した状態でできることは何か?」を認識する必要があります。
ほかのプロジェクトが先行しているような場合、特に問題となるのは、次の問いに集約されます。「内部統制プロジェクトで、内部統制の観点から業務あるいはシステム上の欠陥が判明したらどうするのか? 内部統制チームが全体を統括しないといけないのではないか?」
内部統制が構築された状態のほかのプロジェクトとの関係が（ア）の状態である以上、内部統制の守備範囲とほかのプロジェクトのそれとは役割が異なっています。まず、普通の会社では、これをやらないと内部統制は致命的に不備という状態はあまり考えられません。万一、このような状態であるなら、現状はノーコントロールということですから、ここに内部統制上のコントロールを入れるということは抜本的な業務改革ということになります。今までの自由放任状態から管理下に置かれるわけですから大きな抵抗も予想されます。この作業は、BPRプロジェクトの守備範囲とするのが順当でしょう。
このように、明らかに内部統制上、現状では致命的であるときには、SOX法の期限までにBPRが間に合うかどうかの瀬戸際になります。米国の例ではBPRには三年程度かかるのが一般的なので、事実上二年しか期間がなかったために、できるところの小改善をした結果の可視化でプロジェクトは終わっています。どこの会社でも「できるならBPRやシステム改善も併せて」と考えたのですが実証例からは、これは困難であったということです。そのために、「アフターSOX」などの話題が最近出てきています。
したがって、普通は致命的とはいえない内部統制上の欠陥があった場合にどうするかが問題です。内部統制上の観点からは、これを人手によるマニュアル作業でカバーしてもシステムで自動的にカバーしても任意です。システム要件の変更可能期間であれば、開発コストとマニュアルによる非効率性を勘案して、システム開発するかどうかを決定することになります。このようなことができるようになるためには、ほかのプロジェクトと内部統制プロジェクトとの間で定期的な合同会議を開いて、内部統制上認識された課題を随時共有するようにすることが必要です。内部統制プロジェクト発足時には、このような会議を体制として盛り込んでおくと良いと思います（図10）。
 |
図10●プロジェクト間で課題を共有する [画像のクリックで拡大表示] |
【５】プロジェクト体制構築
図11は、事業親会社から見た体制図のサンプルです。なお、プロジェクト事務局は、将来は内部統制推進組織に変化していくものですが、各業務処理統制そのものを実行する部隊ではありません。業務処理統制そのものを実行していくのは現場の人ですが、その責任者が第2章で言及したプロセスオーナーという役割です。
 |
図11●事業親会社から見た体制図 [画像のクリックで拡大表示] |
プロセスオーナーの概念は日本では新しいと思いますが、今後は職責として必要になります。したがって、体制構築時には、現場で自らの業務を定義しリスクを分析し常時最新の状態を知っておくべき責任者としてプロセスオーナーの概念を説明します。将来その職責を果たしそうな人を現場側でアサインしておく必要があります。
【６】パイロット実施ステージ計画策定
続いて、パイロット実施ステージに移行するので、その計画を立てる必要があります。パイロットステージは、自社の「お手本」と「そのお手本を使って作業する全体量の見積もり」を行います。基本ステージで実施するプロセス整理によって、全体の多様性の概観がつかめます。これが多ければ多いほど、投入できる人間が少なければ少ないほど作業量と期間は増大します。
パイロットの作業は、基本的に内部統制を理解しているメンバーが現場のプロセスオーナーあるいはその委任を受けた担当者と、業務の可視化作業をサンプルとして行っていきます。一つのプロセス（売り上げ-債権回収）をフローチャートとして記述するだけでも数回のヒアリングが必要です。現実的に投入できる人数のコマ割りをしてみて計画を立てることになります。いずれにしても実際にやってみないと確かなことは分かりません。事例では、パイロットに三カ月から六カ月くらいの幅がありました。これらの差は、多様性と投入可能な要員数に起因すると思われます。我々は、パイロットはできる限り時間をかけたほうが安全と考えます。
（次回へ）
|
