皆さんの中にもJSOX法対応のための内部統制プロジェクトにアサインされた方もいると思います。
今回は、内部統制プロジェクトのプロジェクト自体の問題点を考えてみたいと思います。
よくあるケースとして、プロジェクトメンバーが経理経験者を中心として構成されているところが多いのではないでしょうか。プロジェクト経験も少ないのではないでしょうか。
このような構成の場合、事務局だけがプロジェクトマネジメントすれば良い、メンバーはタスクを実行するのみと考えていないでしょうか。マネジメントは、個々のタスクレベルから、プロジェクト全体まであります。マネジメントが連動しなければプロジェクトは成功しません。
詳細な計画を立てていますか？
実行可能な計画を立てていますか？
詳細な計画を立てずに実行すると、
求められる品質レベルを達成できず、作成文書の品質レベルがばらばらになる。
何度も文書修正が発生し、手戻りばかりが表面化する。
ステークホルダーが非常に多岐にわたり、現場の状況に引きずられ、スケジュールどおりに進まない。
評価が属人的になり、一貫した評価とならない。
タスクとして定義した項目を実行しない。
スケジュールの遅れが表面化するのが、マイルストン直前になる。
リカバリープランが立てられない。
スケジュールの遅れを理由に、勝手に手順を変更する。
プロジェクトオーナー、プロジェクトマネジャーの思いがメンバーに伝わらない。
こんなことが実際に起こります。
これらは、何も内部統制プロジェクトだけに起こることではありません。ITプロジェクトでも、どのようなプロジェクトでも起こることです。
実際に、私が支援しているプロジェクトでも起こっています。泣けてきます。
品質レベルを決める、評価の標準化をするというようなこと以外にも非常に大事ですが、忘れていたことが大きく影響することもあります。
私のように、企業の外部から参加している者にとって、プロジェクトに対してその企業の文化が大きく影響することを痛切に感じました。プロジェクトメンバーが、あまりにも現場の状況に気を使いすぎる。
現場の理解が不十分だから、何をするにしても、まず、現場に内部統制の意味から説明しなければならない。啓蒙活動が足らない。現場に依頼したことが期待した結果とならない。
今回のプロジェクトは、法律対応ですから、やらなければならない。しかし、トップのコミットメントが感じられない。
いろいろと悪い面が多く見えてくるのも事実です。
このような状態になったときは、あせらず、1つ1つその原因を分析することが必要です。
リスクだとは薄々感じていたが、何も対応策を考えなかった...
品質レベルを定義せず、文書化手順だけを決めていた...
整備状況の評価手順を決めていたが、メンバーに周知徹底していなかった...
プロジェクトの計画変更に関する手続きを決めていなかった...
メンバーのスキルが足らなかった...
このようなことが見えてきます。
これらに対して、有効な手段を講じることは言うまでもありません。
マネジメント手続きを決め、それに従ってプロジェクトを実行する。計画を変更する場合は、手続きに沿って変更する。
当たり前のことができないのがプロジェクトという魔物です。
これができるようになって初めて、内部統制整備を声高に言えるのではないでしょうか。プロジェクト自体の内部統制が機能しなければ、会社の内部統制を評価することはできません。
コメントする