監査の深度をどう区分するか。名前の付け方が現場の判断を変える

内部監査の規程を整備していると、「監査の深度を三段階に分ける」という設計はごく自然に出てきます。すべての監査を同じ密度で行うことはできない以上、どこまで踏み込むかを段階として持っておくのは合理的です。ところが実務では、その三段階に何と名前をつけるかで現場の選択が目に見えて変わります。名前は定義に添えられた飾りではなく、運用そのものを規定します。

段階の呼び名は、実務者が最初に読む定義です。定義文にたどり着く前に、名前だけで意味を受け取ってしまいます。

深度は、二つの軸を同時に動かしている

まず整理しておきたいのは、深度という一語が何を選んでいるのかです。実際には二つの軸が動いています。

• どのコントロールを取り上げるか：すべてのコントロールを見るのか、リスクの低減に主要な役割を果たすものに絞るのか。
• 取り上げたコントロールについて何を確かめるか：整備状況と運用状況の両方を検証するのか、整備状況の検証を中心に置くのか。

この二軸で三段階を組むと、段階の間で動くのは常にどちらか一方だけ、という形に整理できます。差が一目で読めるようになり、選ぶ側も迷いません。逆に、深度の定義を「監査手続を実施する程度」とだけ書いてしまうと二つ目の軸しか指しておらず、片方の軸が定義から抜け落ちます。定義が片肺のまま運用に入ると、同じ段階を選んだはずの監査人どうしで、対象とするコントロールの数が食い違います。

「簡易」という呼び名が持っていた副作用

三段階の呼び名として最初に置かれがちなのが「詳細・標準・簡易」です。素直で、意味も通ります。ただ、この並びには見過ごしにくい副作用があります。簡易と詳細を両端に置くと、手間の多寡がそのまま丁寧さの序列に読めるのです。

リスク・ベースの内部監査では、すべてのコントロールを検証することは上位の行為ではありません。リスクの低い領域に深く入るのはむしろ資源配分の失敗です。それなのに呼び名のほうが「簡易＝手を抜いた監査／詳細＝ちゃんとやった監査」というメッセージを出してしまう。名前が方法論と逆の価値観を伝えている状態で、これは設計上の欠陥だと考えるべきです。

ここを「俯瞰・標準・詳細」に改めると、両端が視点の距離という中立な一軸になります。遠くから全体を見るのか、近づいて細部を見るのか。どちらが上ということはありません。呼び名を一語入れ替えただけで、伝わる価値観が変わります。

「網羅」も検討して、退けた

同じ議論の中で「網羅・標準・俯瞰」という案も出ました。網羅＝すべてのコントロール、俯瞰＝主要なコントロールのみ、という対応です。一見すると筋が通っていますが、これは採用しませんでした。

理由は単純で、網羅も俯瞰も、どちらも「全体」を連想させる語だからです。定義のうえでは網羅が最も広く、俯瞰は主要なコントロールに絞る（＝標準と同じ広さ）のですが、言葉の印象からは俯瞰のほうが広く感じられます。予備知識のない読み手は必ずここで止まります。

ここから引ける一般則があります。等級の両端に、同じイメージを喚起する語を置かない。両端は意味の対比が最も強く出る位置なので、ここで読み手を迷わせると、中間の段階まで読めなくなります。

定義文は、隣の段階と並べて読む

呼び名が決まったあと、定義文の側でもう一つ躓きがありました。当初、最も深い段階をこう書いていました——「整備状況および運用状況の双方を検証するもの」。

問題は、その一つ手前の段階も整備状況と運用状況の両方を見る設計だったことです。それなのに「双方」という強調が最も深い段階にだけ付いているため、手前の段階が片方しか見ないように読めてしまう。強調のつもりで足した一語が、隣の段階の意味を書き換えていたわけです。「双方」を落としただけで、三段階の差が正しく見えるようになりました。

定義文は単独で推敲しても粗が見つかりません。必ず隣の段階と並べ、動いている語と動いていない語を突き合わせて読む。等級を定義するときの基本動作です。

「優劣ではない」と書くと、並び順の根拠が消える

三段階の後ろに、一文を添えました。「これらは、検証の方法の違いを表すものであり、優劣を示すものではない」。読み手の誤解を先回りして断つための文です。

ところが、この一文を入れた瞬間に別の問題が動きます。同じ規程の中で、評定の区分、発見事項の水準、保証水準といった列挙はいずれも上位から順に並べていました。等級であるからこそ、降順にそろえる意味があったのです。深度についても当初は同じ理由で降順に置いていました。

しかし「優劣を示すものではない」と明記した以上、深度はもう等級ではありません。降順を要求していた根拠は、自分で書いた一文によって消えています。そこで深度だけは実務の順序——遠くから全体を見て、必要に応じて近づいていく順——に合わせ、昇順に置き直しました。横串の統一ルールは、それが及ぶ範囲まで含めて点検する必要があるという一例です。

比喩は、規程には書かない

深度の議論を現場で説明するときには、比喩がよく使われます。まず鳥の目で俯瞰し、次に虫の目で見て、本当に大きなリスクが見込まれるならさらに細部へ。直感的で、伝わりやすい説明です。

ただし、これを規程に括弧書きで持ち込むことはおすすめしません。定義と比喩の二重管理になり、定義を見直したときに比喩を直し忘れます。規程に置くべきなのは比喩そのものではなく、比喩が伝えたかったこと——視点の距離の違いであって優劣ではない——を述べた一文です。比喩を文書に残したいなら、置き場所は規程ではなく、当該年度の監査方針のような、毎年書き換わる文書のほうが適しています。

おわりに：名前は運用の一部

深度の設計で時間がかかるのは、段階をいくつにするかではありません。何と呼び、どう定義するかのほうです。そして呼び名は、監査計画の様式、調書のテンプレート、報告書の記載へと波及し、いったん運用が始まると直しにくくなります。制定の前に、定義文を読まずに名前だけを見た人が何を受け取るかを、一度確かめておく価値があります。

「AuditX-SaaS」は、監査計画から調書、報告、フォローアップまでを一つの基盤の上で扱います。深度のような設計上の決めごとを様式に落とし込み、運用のなかで一貫して使い続けられる状態をつくる。その土台づくりを、私たちはお手伝いします。