もう一つのコツ、これは非常に使えることだと思います。リスクの種類、リスクの発生箇所のパターンを覚えてしまう。ＩＴを使って財務会計データを作成している以上、財務報告に係るリスクの発生箇所というのは決まってきます。 　一つ目のリスクの発生箇所は、承認時点です。承認が必要とされた時点には常に承認が漏れるリスクがあります。 　二つ目がシステムへの入力時点。データを入力するときはもちろん間違って入力するリスクもありますし、漏らしてしまうリスクもありますし、二重に入れてしまうリスクもある。財務報告に係るリスクにひもをつけるならば、入力が漏れる、重複するとか、入力を誤る。あとは、今日やるべき入力を翌月になってやったというのであれば適時に処理されない、適切な期間に処理されないというリスクも入力時点、このポイントで認識されることになります。 　三つ目がシステム間のインタフェース時です。サブシステムから財務会計システムにデータを移行する際に発生するリスクです。オンラインのバッチ処理で持っていっているというときに、通常その場合は正確性というのは担保されていると考えていますが、漏れるリスクはないのか。何件送って何件受け取ったということはモニターされていますか。処理が漏れるリスクというのは、常にシステム間のインタフェースの場所において認識されるべきリスクです。 　四つ目がＩＴの処理プロセスです。ＩＴで計算している部分というのはすべて自動計算しています。それは全部システムでコントロールされていますということですけれども、この処理が誤るケースというのもありえない話ではない。システムのバグが完全に取り除かれている保証はないのです。システムコントロールで処理を誤るリスク。あとは手で計算しているような場合には、処理を誤るリスクというのは常に存在します。 　最後にデータの保存場所とか資産の保存場所におきましては、承認なしにデータが書き替えられてしまう、承認なしに資産が払い出されてしまう、適切な手続を経ることなくデータが書き替えられたり資産が払い出されてしまうという資産保全のリスクというものもあります。これは、必要な承認がなされないで処理がなされるリスクとして認識するのが一般的なのかなと思います。 　この五つのリスクはワンパターンで覚えて、フローを書いていて、こういう場所があったら常にそのリスクを（リスクを三角マークにするならば）、その三角マークを打っていく。三角マークは発生箇所に対応するリスクのどれか、または複数打たれることもありますが、それを打っていく。これをワンパターンでやっていただくと財務報告に係るリスクが漏れることもないのかなと思います。リスクを漏らすというのが文書化で一番問題です。認識すべきリスクを漏らしてそのまま作業が進行していって、後から日程が押し迫ってから指摘されると大変です。余計なリスクを打ってしまうということもありますが、それは余計な作業がふえるだけでそれほど問題とはならない。後で削除すればいいという話です。