これだけはやめよう！嫌われる内部監査報告書
「嫌われ役」で本当によいのか？
「内部監査は社内の嫌われ役になってもいい、問題をきちんと指摘してくれ。」内部監査の人間が時折耳にする言葉です。しかし、この「嫌われる」ことはとてつもなく大きな弊害です。
先ず何か指摘しても改善は部門の責任で行われます。内部監査に反感を持たれては、改善自体のモチベーションが低くなり結果として実施がされなくなります。これでは指摘も何の意味もありません。
また反感を受けることで次の仕事がやりにくくなります。監査の後はフォローアップがありますし、また翌年度に別のテーマ監査をすることもあるでしょう。この際に協力が得られにくくなると、とても困りますよね。
最後に内部監査に一生いるとは限りません。社内ローテーションで異動する際、あちこちの部門から嫌われていては行き先がなくなります。また異動後も辛い立場になる可能性もあります。
今回は「嫌われる」大きな原因の一つとなる監査報告書についてお伝えします。監査報告書は役員など「上の人たち」にも配布されます。このため監査報告の内容は被監査部門にとっては、多かれ少なかれプレッシャーとなるため、内容によっては怒りを買うこともしばしばです。
嫌われる報告書達
嫌われる報告書のパターンを見ていきましょう。
発見事項しか記載していない報告書
良好な活動や取り組みが何も記載されず、問題点だけ記載してある報告書は、100%嫌われると言っていいでしょう。
もちろん建前としては内部監査の目的が価値の付加、つまり業務改善にある以上、出来ている点よりも出来ていないことを改善する方が意味はあります。またリスクアプローチの結果、問題を集中的に発見することもあるでしょう。
しかし全体として見た際、実施できている事項が何もないということは先ずないはずです。設定した監査基準に照らすと活動の水準が低かったとしても、適切な活動が少しでもあればきちんと言及することが良いでしょう。
【嫌われる報告書のイメージ】
本監査では社内規定に基づき、システム部門のセキュリティ管理態勢の整備・運用について監査を実施した。
その結果、情報資産台帳の未更新・不要なアクセス権限の残存・ネットワークし設定の定期レビュー未実施等複数の問題点を発見した。これらは社内規定からの逸脱であり、早期の改善が必要である。
【上記報告書の改善例】
本監査では社内規定に基づき、システム部門のセキュリティ管理態勢の整備・運用について監査を実施した。
全体的には規定に準拠した活動が実施され重要な問題は確認されなかった。特にアクセス権限管理においては職務グループの業務単位に権限付与基準を作成し、当該基準に即した付与を実施するという独自の良好な活動もされていた。
ただし、管理する情報資産台帳の更新やネットワーク設定のレビュー等については、定められた期間内に実施されていなかった。実際に必要な設定の検証漏れが一部発生しており、これらは早期の改善が必要である。
上の2つは基本的に同じ内容を述べたものですが、受ける印象が大分違うと思います。
重要なのは後者の報告例のほうが全体としての意見や良好な点についても言及しているため、不備しか記載されてない報告書より、客観的で公平な印象を与えることです。
内部監査としては改善に目が向くあまり、問題や課題について言及しがちな場合がありますが、バランスを取ることが重要です。
小さな問題を大袈裟に述べる報告書
監査上設定した基準と実際の活動が乖離し一定の改善が必要な問題を見つけたとしても、適切なリスクコミュニケーションをして問題の大きさに見合う改善を提案する必要があります。
その問題の大きさ・態様・程度・頻度を踏まえない抽象化された指摘は、必要以上に問題を強調して相手を怒らせる可能性があります。
【嫌われる報告書のイメージ】
セキュリティ監査を実施した結果、複数のシステムにおいて不要なアクセス権限が削除されておらず、権限管理が適切に実施されていなかった。
これらは規定からの逸脱であり、早期の改善が必要である。
【上記報告書の改善例】
セキュリティ監査において、人事部が所管する5つの業務システムにおけるアクセス権限管理について検証した。
その結果、社員以外の重要な個人情報を扱う「採用管理システム」、及び従業員の個人情報を扱う「人事評価システム」「勤怠管理システム」では必要最小限の権限付与が実施されていた。
教育研修のコンテンツを管理する「Eラーニングシステム」及び従業員のメールアドレスや電話番号・写真等の公開情報を社内に共有するための「社員情報公開システム」でも、管理者権限・オーナー権限は適切に付与され概ね妥当な活動であった。
ただし、上記2システムでは前四半期に異動した社員の権限が3件削除されていなかった。これらは異動後の引継ぎのための経過措置として付与していたが、現在は不要であると回答された。
各システムは重要な個人情報等の機微情報は扱わず該当権限も参照のみ可能であり、権限未削除は情報管理上の大きなリスクがある問題ではないが、権限管理をより適切に行うため、及び両システムはライセンス料が発生するため不要な費用を削減する意味で改善が望ましいと考える。
いかがでしょうか。「嫌われる報告書」では非常に抽象度が高い分アクセス権限管理が全体的に適切ではない、という印象を与えます。
これに対して改善例では、重要な情報を扱うシステム及びその他システムでも管理者権限等の特権は適切に管理されているため全体的には適切であったものの、一部参照権限が少しの期間削除漏れであったというごく軽微な問題が残っていた、というように理解されるはずです。
問題の量的・質的な評価を適切に行えないと、改善の範囲・内容・強度も適切に提案できません。そして、問題の大きさに見合う提案でなければ費用対効果に合わない過剰な改善提案になりかねません。
また「針小棒大」「問題を誇張している」という誹りも免れません。
伝達も適切でなく相手からも嫌われるなら何も良いことはありません。問題の性質・リスク度合いをよく考慮して適切な表現を検討しましょう。
スキル・能力・姿勢の問題を取り上げる報告書
内部監査ではプロセスや体制など、改善可能な主体に対して指摘を行うべきであり、個人の知識や技能などに問題の原因を求めることは基本的には避ける方がよいでしょう。
何故なら仮にスキル不足で問題が生じていても、「スキルを上げてくれ」とか「スキルの高い人材をアサインせよ」という改善提案は現実的ではないからです。
そして内部監査は人事評価ではなく、センシティブな個人の力量に軽々に触れることは、不要なハレーションの原因となります。
【嫌われる報告書のイメージ】
「マインナンバー管理システム」が予定していたリリース時期を3カ月遅延した。
これはプロジェクトマネージャーである人事部A氏は採用畑のキャリアで、アプリケーションに関する技術的な知識やシステム開発プロジェクトの経験がなく、ベンダーに開発業務を丸投げしていたことが原因である。
このため開発ベンダー側の成果物が仕様と異なる点、開発自体も遅延していた点を確認を怠り、その結果修正やテストに時間を要して遅延に至った。
【上記報告書の改善例】
「マイナンバー管理システム」が予定していたリリース時期を3カ月遅延した。
関係者へのヒアリングをした結果、本件の原因は下記であると判断する。
①要件定義・仕様検証手続きの不足
・本プロジェクトでは口頭で機能要件を伝達し、機能・非機能要件を明確に定義した文書を作成していない。
・また要件定義の後ベンダーが作成した「外部設計書」をレビューしていなかった。
上記によりセキュリティ要件の漏れや意図した仕様と実装の差異が生じ修正が必要となり、本遅延の直接的な原因となった。
②進捗管理の仕組み・ルールの不足
・本プロジェクトでは各開発工程やユーザーテスト期間を考慮したマスタースケジュールが作成されていなかった。
・関連して工程の具体的な進捗率や課題発生状況を確認するめたの進捗管理のルールや確認方法は整備されていなかった。このためベンダーは月次定例会で口頭で簡単に進捗報告を行うのみであった。
上記により、ベンダー側のキーパーソン退職に伴う開発業務自体の進捗遅延傾向を把握できなかった。
例えばプロジェクトに品質や遅延の問題があっても、プロジェクトマネージャーの能力不足・指導不足ではなく、品質管理や進捗管理などのマネジメントプロセスの改善を促すことが必要です。
また上記ほど露骨でなくても「〇〇を怠り～」「不適切な〇〇をしていた」「〇〇を放置していた」などの能力や姿勢に間接的に言及される表現も使わず、単に「何カ月間〇〇の手続きは実施されなかった」などのファクトベースの記載を行いましょう。
個人の責任追及は犯人探しにしかなりません。ハラスメントのような特異な場合を除き、あくまでも組織としての改善をポジティブなメッセージとして提案することがとても重要です。
最後に:最も効率的に嫌われる方法とは？
「最も効率的に嫌わられる方法、それは正論を言い続けること」という言葉があります。
相手は感情のある人間であり誇りを持っています。また現場の活動あって初めて内部監査のようなライン外の仕事は存在し得ます。
常に相手なら最大限のリスペクトの念を持ち、メッセージを発することが大切ではないでしょうか。
【管理部門特化型エージェントNo.1のMS-Japan】
Follow me!
投稿者プロフィール
- ネット系事業会社 内部監査室 室長
- J-SOXバブル時に内部統制コンサルに。以来通算13年間内部監査・内部統制・リスクマネジメント・セキュリティ業務に従事しています。
自身の学びも兼ねて、縁があって内部監査を始めよう/既にしている方達に少しでも役に立つ、現場の情報をお伝えしたいと思います。
【保有資格】
・公認内部監査人（CIA）
・公認情報システム監査人（CISA）
・内部統制評価指導士（CCSA）
・公認情報セキュリティマネージャー（CISM）
・Certified Data Privacy Solutions Engineer（CDPSE）
【所属】
・日本内部監査協会会員
・ISACA東京支部会員
ちょうど２年経過してのコメントで失礼します。
私の報告書もまさに「嫌われる内部監査報告書」の典型的な事例と同じです。
一時は「上記報告書の改善例」を書いていたこともありますが、事例と同様文章が長くなり、文字数が増えてしまいます。と同時に問題点が霞んで良い点を中心にとらえる部門管理者は少なくないこと、さらに忙しいこともあって文章読解力が十分でなく、「少し悪い点はあるものの、非常に良い点が取れた。基本的に問題ない。」と独自解釈する人もいるので、今は嫌われるコメントに戻っています。
改善提案の際に「具体的に何をどうするか」を伝えてフォローするようにしています。
何が悪いかを先に端的に伝える報告は、嫌われて効果も低いとの指摘に理解するとともに戸惑いを感じています。
監査項目毎に「問題があり、指摘する」／「良好な旨を記載する」と白黒つける記載ではいかがでしょうか？
コメントありがとうございます。
監査報告の在り方は、監査テーマや扱うリスク、問題の程度や部門の立ち位置によっても変わりますが、最終的に効果的な改善の促しが出来ているのでしたら、それがその会社にとって良い形かと思います。
この記事は私の過去の失敗談を踏まえて書きました。以前は問題指摘が先行し過ぎる報告になりがちで、実情以上に問題が強調されて見える面があり、改善とのバランス含めて反省が多くありました。
そのため、具体的に「何が出来ていないか」を説明するためにも「出来ていること」への言及は重要かと考えた次第です。
最後に改善提案に繋げるため、出来ている点→検出事項(問題点)→改善提案、という流れで記載することが個人的にはしっくり来ています。
また部門との関係性も、良好な点を明記するようにしてから格段に協力的になり改善自体も行われるようになり、監査以外でも相談を受けることが増えてきました。
もちろん、冗長になりがちであったり読み手に却って問題が伝わりにくくなるのでは、というご指摘もごもっともだと思います。バランスを持って伝えることが大切かもしれません。