0
会員になると、いいね！でマイページに保存できます。
ビジネスを取り巻くGRC（ガバナンス・リスク・コンプライアンス）への適切な対応が求められる昨今、どういう場合にどのように判断してGRCツールを選ぶべきだろうか。本記事ではGRCツール選定のポイントについてお伝えしたい。これは、「経営層」と「部・課長層」の両方からよく聞かれる質問なので、それぞれの層に分けてポイントを記載する。なお、文中の意見に関する記述は筆者の私見であり、所属する法人などの公式見解ではないことを、あらかじめご了解いただきたい。
「経営層」として検討する際のポイント
前回の記事では、日本企業やグローバル企業におけるGRCツールの活用事例やその違いをお伝えした。GRCおよびGRCツールの価値/機能についても、そちらを参考にしていただきたい。
前回記事
今回は、「経営層」と「部・課長層」に分けて、GRCツール選定のポイントを解説する。まず経営層のニーズは、自分が見たい情報を一元的に表示でき、詳細情報までドリルダウンできるダッシュボードだ。特に外資系企業などの経営を歴任する「プロ経営者」やITリテラシーが高い「スタートアップ企業の経営者」からのニーズだ。
彼らに共通する特徴がいくつかある。（1）既存の指揮報告系統だけに頼らず、重要な数値やデータを自ら収集している。（2）収集した数値やデータを確認し、全体を把握し、先を見通して、具体的な実務について適任者に確認し指示する。（3）ステークホルダーに対しても透明性の高い具体的な情報を利用して戦略や計画について議論・説明をしている。組織運営のスタイルが比較的フラットで経営の透明性も高い。彼らの「右腕」がGRCツールだ。
もしもあなたがGRC領域に関する経営層で、
図2のマネジメントを目指すならGRCツールを検討すべきだ。
「部・課長層」として検討する際のポイント
部・課長層のニーズは、主に自部門の業務の効率化だ。統合リスク管理、事務リスク管理、ITリスク管理、コンプライアンス、内部監査、事務事故・インシデント管理などを所管する部門で、エクセル、ワード、メール、共有フォルダなどを多用している業務を効率化したいという。これらの業務に反復定例的な作業が含まれるならGRCツールやRPAを検討したほうがよい。この他、現場とのコミュニケーション強化による取り組みの活性化などのニーズもある。GRC領域の部・課長としてGRCツールの導入を判断するために以下の質問を検討してほしい。
GRCツールを導入すべきか？ チェックシート
□ 部下もしくは現場に毎日のように口頭（電話）で進捗を確認している
□ 部下もしくは現場からの報告様式がバラバラになっている
□ 部下もしくは現場は依頼を受けた業務が全社もしくは自部門の目標とどう関係しているかを理解していない
□ 部下もしくは現場への進捗確認に時間をさき、アドバイスには時間をさけていない
□ 複数の部下もしくは現場から報告を受けても、自部門全体としての目標達成状況を簡単に把握できない
□ 自部門の業務遂行にあたり最新資料や過去情報を探すのが困難である
□ 自部門の業務には情報の転記（コピーペースト）や定型的な資料作成などの定常作業が感覚的に20％以上ある
もしもYesの数が4個以上であったなら、GRCツールを検討すべきだ。
どのように判断してGRCツールを選ぶべきか
GRCツールを選定する際の検討要素は３つある。
（１） 活用する業務領域
（２） 活用する業務の複雑性
（３） 動かす基盤・インフラ
（１）活用する業務領域
GRCツールは、ERM、RCSA（注1）、コンプライアンス、インシデント報告・管理、内部監査、CSIRT（注2）支援など個別の領域・機能のみでも利用できるが、これらの機能を組み合わせた利用も可能だ。
注1：リスクコントロールセルフアセスメント
注2：Computer Security Incident Response Team、シーサート
現状、日本企業では個別領域での利用が中心だが、予算都合などで複数の部署・領域で同じGRCツールを利用する場合もある。
個別領域のみで利用する場合は、各GRC製品の機能に多少の得意不得意があり、個社のニーズも異なるため、実際のデモやPOC（注3）を用いて評価するのがよい。自社で当たり前にやっていることが実は好事例で、ツールが対応していないこともある。各製品の特徴の紹介は、この記事では申し訳ないが控えさせていただく。
注3：Proof Of Concept（製品実証実験）。要件に応じたGRCツール全体を一通り作り上げる試作（プロトタイプ）の前段階で、重要な要件・要望などの実現可能性のみを明らかにするために行われる、不完全あるいは部分的な施策やデモンストレーションなどを意味する
主なGRCツール（順不同）
・RSA Archer GRC Platform （デル）
・IBM OpenPage GRC Platform （IBM）
・MetricStream GRC Platform （MetricStream）
・Rsam （Rsam）
・Keylight （LockPath）
・SAP GRC （SAP）
・SAS Enterprise GRC （SAS）
・AutoAudit、Conflicts Compliance （トムソン・ロイター）
・Risk Organizer （GRCS、旧社名はNANAROQ）
・ServiceNow （ServiceNow）
（編集部調べ）
複数の領域で利用する場合は、デモやPOCも有用だが、グローバル調査会社などの調査レポートがまずは参考になる。主な調査レポートは各製品を「活用の範囲」と「使いやすさ」の2軸で評価しているので右上象限に位置されるものから選択するとよい。製品ベンダーの説明では「活用できる」機能であっても、実際の導入事例がないものや使いづらいものもある。調査レポートでは各製品を定期的かつ客観的に分析・評価している。
（２）活用する業務の複雑性
GRCツールには、画面やワークフロー、レポートなどが「ツール標準」として設定されており、ユーザーのニーズを反映して通常年に２～３回程度のバージョンアップで更新されているため、一般的なGRC業務には耐えうる。導入を契機に「ツール標準」に業務を合わせるのか、業務に合うように「ツール標準」を変更するのかもツール選定のポイントだ。
仮に「ツール標準」に近づけるならデモやPOCの結果や製品の導入実績で判断すればよい。
逆に「ツール標準」を変更する場合、詳細な変更が得意な製品かどうかに注意が必要だ。変更を大幅に行う場合、それぞれの変更に矛盾や検討漏れがないかを確認する必要がある。よくある失敗はこのあたりで発生しがちだ。
経験上、ツールに変更を加える意思決定は業務の複雑性に依存する。たとえば、ERM業務におけるリスク評価（リスクマップ作成など）において、親会社、子会社、孫会社でリスク評価する場合（注4）、最下層の組織で最重要と評価されたリスクを上位層、最上位層でどう評価するかについて、いくつかの考え方・評価方法がある。詳細は別の機会に譲るが、組織階層およびリスク特性にかかわらず同一の評価方法を採るのか、複数の異なる評価方法を採るのかはERMにおける重要な検討ポイントだ。一般的には後者を薦めるが、GRCツールとして対応できる製品と対応できない製品がある。この他、内部監査のリスクアセスメントでも標準のリスクカテゴリや評価手法を使うのか、リスクや地域ごとにそれらを変更したいのかなどが業務の複雑性の例となる。
注4：全社、事業部、部や本社、海外統括会社、子会社などの階層も同様
（３）動かす基盤・インフラ
GRCツールは、webベースが主流となっており、オンプレミス（注5）にもクラウド（注6）にも対応している。オンプレミスとクラウドでは、資産計上になるのか経費になるのかキャッシュアウトのタイミングなどの費用構成、データ保護規制なども含めた情報セキュリティ、保守メンテナンスの負担などが異なる。
これらの差異はGRCツール特有ではないので詳細は割愛するが、クラウドの場合は、各GRC製品のクラウドサービスが自社のセキュリティ要件を満たしているか、満たすオプションがあるかについて確認すべきだ。
注5：自社施設内にサーバー等を設置してGRCツールを構築・運用すること
注6：外部事業者が用意したGRCツールをネットワーク経由で利用すること
【次ページ】GRCツールに関する「本当によくある」問題と、共通の原因、回避方法まで
関連タグ
