parallel

先日、これから金融商品取引法の内部統制報告制度に対応する企業とプロジェクトの進め方を打合せする機会がありました。

状況を聞いてみると、現在、会計システムを含む基幹業務の情報システムを全面的に刷新しようするプロジェクトが進行していました。

そのため、全体スケジュールの中で、システム開発の影響を受ける業務プロセスに係る内部統制(IT全般統制を含む)の進め方は、別途走っているシステムプロジェクトを考慮しなければなりません。

特に、基幹システムの支援領域と対象範囲が重なるプロセス、すなわち、業務プロセスに係る内部統制のうち、事業目的と関連する勘定科目(一般事業会社で言えば、売上・売掛金・棚卸資産などに該当する勘定科目)に至る業務プロセスの文書化の進め方が議論となりました。

販売プロセスほか基幹業務システムはスクラッチ開発を採用しており、まだシステム要件定義が完了した段階でシステムの開発はこれからだったため、モノがない/今後機能が変わっていくという状況の中、どのように文書化を進めるのが良いかが問題でした。

まだシステムが出来ていないのであれば、外部仕様書で内部統制を設計する

この状況で考えなければいけない前提が次の二つです。

  • システム開発の構築フェーズでは、ユーザー業務手続の構築がある
  • 内部統制の文書化フェーズでは、業務を可視化する

前者には、新システムに関するユーザーの業務トレーニング、受入テストシナリオ、稼働後の業務マニュアルなどユーザー業務手続の構築作業におけるアウトプットとして「業務フロー」があります。

後者には、監査資料としてのリスク・コントロールマトリクス(RCM)と合わせて、業務を理解するための「業務フロー」があります。

この二つの「業務フロー」は、実は共有することができ、それはユーザーの外部仕様(画面設計・帳票設計)が定義されたドキュメントを活用して内部統制の設計をすることがポイントになっています。

なぜ、同じ業務フロー利用することができるのか

たしかに、業務フローは作成目的が異なれば範囲、様式・ツール、粒度も異なります。

例えば、システムプロジェクトにおいて要件定義段階でベンダーが作成する業務フローは、名称は「業務フロー」であっても、内容はシステムの「処理フロー」であることがほとんどです。

なぜならば、その段階では、会社全体として必要な業務機能からシステム要求事項を定義するのが目的だからです。

このような目的のもとでは、「受注処理」「出荷指示処理」「出荷処理」「売上処理」「請求処理」のような○○処理というシステムの機能の連鎖を業務フローと呼びます。

しかし、システムプロジェクトも構築段階に入った場合には、新システムを利用した業務運用をイメージして、事前に種々の課題を検討しなければなりませんので、単なる処理フローではなく、ユーザーが現場で利用することができる、すなわち業務マニュアルとしても利用することができるドキュメントが必要になります。

そして、そのようなドキュメントとして作成される業務フローは、リスクの発生ポイントを識別したり、コントロールの実施ポイントや不足している状況を明確化できるという意味で、内部統制プロジェクトでも十分活用することができるのです。

危ないプロジェクトとそのリスク

ところで、このようにシステムプロジェクトと内部統制プロジェクトの二つを進めなければいけない場合、この二つを別々のプロジェクトとして、アウトプットドキュメントの共有はおろか、ほとんどコミュニケーションを取らずに進めることがあります。

外から見ていると、プロジェクトの計画段階で次のような状況になっていることが多いと思います。

  • システムプロジェクトの構築フェーズで「ユーザー業務手続の構築」がないか、その作業を軽視している(例えば期間が短い)
  • 内部統制プロジェクトがシステム稼働後に文書化をスタートするスケジュールとなっている
  • プロジェクト間のコミュニケーションをとる会議体やプロジェクトの管理プロセスがない

これらの事象がすべて該当するプロジェクトは、品質やコストの面で、例えば次のようなリスクの発生可能性が高いプロジェクトと言えます。

  1. 新システムを利用した業務運用について稼働前に十分な検証ができないため、稼働後に業務・システム上の課題が出やすい
  2. 内部統制の文書化は、内部統制の評価目的でのみ利用される文書となりやすい
  3. 内部統制上の要件から、自動化統制や手作業統制で使用するシステム機能・帳票作成などの機能が出てきた場合、単純な追加開発となりコストが発生しやすい

1や2はそれぞれ単独のプロジェクトとして実施した場合にも起こり得ることですが、3は今回のケース特有の問題となります。

例えば、会計上の売上に直接的に影響するような入力画面における単価の入力チェック機能や入力内容が正しいことを確認するために使う入力プルーフリスト、異常な値引きを事後的にチェックする例外レポートなど、業務をスムーズに流すためのシステム処理では通常拾いにくい機能があります。このような財務報告の信頼性を確保するための内部統制のように、ブレーキをかける機能があり、これらがシステム開発の工程が進んだ後で気づくと、プロジェクトコストにも影響する場合があります。

二つのプロジェクトで最初に擦り合わせるべき事項

今回のプロジェクトでは、情報システム開発時における内部統制設計のポイントに関する説明に対して、経営者から十分な理解と賛同が得られたことから、プロジェクト方針や体制はうまく連携をとれる形で立ち上げることができました。

ここでは、プロジェクト初期段階で二つのプロジェクトの間でコンセンサスを得ておくべき事項を列挙しておきます。

  • 二つのプロジェクトで可視化の対象とするプロセス/サブプロセス
  • 上記のうち、業務プロセスに係る内部統制の評価対象範囲(作成の優先順位、RCM作成対象の明確化)
  • 業務フローの表記ルール
  • 業務フローの文書化ツール
  • 作業分担と可視化/レビュースケジュール

ウォークスルーや運用テストはシステム稼働後となるため、内部統制プロジェクトとしては、同時並行で文書化作業を早めにスタートできる分、スケジュール上の余裕があると思うかもしれませんが、そんなことはありません。

相互に影響を与える関係にある二つのプロジェクトを調整しながら進めるには、業務プロセスの可視化を通じて二つのプロジェクトの連携を図ることが重要であり、プロジェクトの難度としては高い方だと思います。