【RCMの作り方】業務フローと整合を取るコツ

RCMを作るときに一番つまずくのは、業務フローとRCMの整合が崩れることです。本記事では、業務フローを起点にリスクと統制を紐づけ、証跡までつなげて更新し続けられるRCMにする手順を、粒度の決め方や運用のコツまで含めて解説します。

RCMとは何か…業務フローとセットで考える理由

RCM【リスクコントロールマトリクス】の基本

RCM【リスクコントロールマトリクス】は、業務の中で起こり得るリスクと、それを防ぐための統制【コントロール】を、対応づけて整理するための一覧表です。 内部統制【J-SOX】の文脈で語られることが多いものの、本質は「事故やミスが起きないように、業務の管理点を明確にする」ことにあります。

RCMは、ざっくり言うと次のような要素をセットで整理します。

ここで重要なのは、RCMは「表だけ作れば完成」ではないという点です。 RCMはあくまで業務の実態に沿って、リスクと統制を正しく紐づけられているかが命です。 そのため、RCMは単独で作るのではなく、業務フローとセットで作り、相互に整合を取る必要があります。

なぜ業務フローなしではRCMが崩れるのか

結論から言うと、業務フローがない状態でRCMを作ろうとすると、ほぼ確実に漏れとズレが発生します。 理由はシンプルで、見えないものは管理できないからです。

業務フローがないままRCMを作ると、次のような問題が起きやすくなります。

• 工程の抜け…「実はここで確認していた」「実は別部署がやっていた」が後から出てくる
• リスクの偏り…想像しやすいリスクだけが並び、実際の事故ポイントが落ちる
• 統制が空回り…統制を書いたが、現場の流れに組み込めず形骸化する
• 責任の所在が曖昧…「誰がやるのか」が曖昧で、結局“やったことにならない”
• 更新できない…業務が変わった時に、どこを直せばいいか分からない

RCMは「リスクと統制の表」ですが、その前提として、どの工程で何が起きているかが明確になっていなければ、リスクも統制も置きようがありません。

特に、内部統制の整備でよくある失敗は、RCMを「テンプレで埋める作業」にしてしまうことです。 テンプレに当てはめるだけだと、見た目は整います。 しかし、業務の実態と合っていないRCMは、監査対応でも運用でも破綻しやすくなります。

だからこそ、RCMは業務フローとセットで設計し、整合を取ることが基本になります。

RCMで扱う範囲…業務の粒度と対象業務の決め方

RCMづくりで最初につまずきやすいのが、「どこまでをRCMの対象にするか」という範囲と粒度です。 ここを決めずに始めると、途中で細かすぎて終わらないか、逆に粗すぎて役に立たないのどちらかになりやすいです。

ポイントは、最初に次の2つを決めることです。

• 対象業務の範囲…どの業務領域をRCMに含めるか
• 粒度…工程をどの細かさで分解するか

この判断で大切なのは、RCMが必要になる場面は「何かを変える」「何かを守る」ための管理であるということです。 つまり、目的に対して必要十分な粒度にするのが正解です。

定型業務から始める

RCMを初めて作るなら、最初に狙うべきは定型業務です。 定型業務とは、決まった手順で、同じ流れで回る業務です。

定型業務から始めると、RCMの整合を取りやすく、運用に乗せやすくなります。 理由は次の通りです。

• 工程が安定している…例外が少なく、フローが描きやすい
• リスクが定義しやすい…何が起きると困るかをパターン化しやすい
• 統制が組み込みやすい…承認や照合などを業務の流れに埋め込みやすい

例えば、経理や管理系の業務は、比較的定型化されていることが多く、RCMの対象として取り組みやすい領域です。 また、BPOの文脈でも、外に出しやすいのは判断を伴わない定型業務です。 この点からも、定型業務は「可視化しやすく、統制設計もしやすい」対象になります。

最初は1プロセス…1業務のように範囲を絞り、成功体験を作ってから横展開する方が、結果的に早く進みます。

イレギュラー業務の扱い…落とし所を先に決める

一方で、イレギュラーが多い業務や、特殊な業務は、RCMの対象にすると急に難易度が上がります。

ここで重要なのは、「イレギュラーをゼロにする」ことではありません。 現実には、イレギュラーは存在します。 だからこそ、最初に落とし所を決めておく必要があります。

落とし所としてよく使える考え方は、次の3つです。

• 例外は別扱いにする…フロー本体には入れず、別紙【例外対応】としてまとめる
• 粒度を粗くする…細部に入らず「判断が発生する工程」としてまとめる
• 対象外と割り切る…最初は扱わず、定型領域の整備が終わってから着手する

イレギュラー業務を最初から完璧に入れようとすると、フローもRCMも膨張します。 結果として「終わらない」「更新できない」状態になり、最も避けたい形骸化に繋がります。

RCMは作ることが目的ではなく、管理できる状態を作ることが目的です。 そのため、イレギュラーは「どこまで管理対象とするか」を先に決め、運用できるサイズに収めるのが重要です。

RCMの作り方…業務フローと整合を取る手順

ここからは、RCM【リスクコントロールマトリクス】を実際に作る手順を、業務フローと整合させながら解説します。 ポイントはRCMを表として埋めるのではなく、業務フロー上の出来事に対してリスクと統制を配置することです。

全体の流れは次の4ステップです。

• 手順1…業務の見える化として業務フローを作る
• 手順2…リスクの洗い出しとしてどこで何が起きるかを置く
• 手順3…統制の設計として誰がどう防ぐかを決める
• 手順4…整合チェックとしてフローとRCMのズレを潰す

手順1【業務の見える化】業務フローを作る

RCMの土台は業務フローです。 なぜなら、RCMは「工程に対して」リスクと統制を置くものだからです。 業務フローが曖昧なままだと、後工程のリスクも統制も、必ず曖昧になります。

ここで意識したいのは、いきなり完璧なフローを作ろうとしないことです。 まずは対象範囲と粒度を決めたうえで、実務で使える最低限のフローを作ります。

スイムレーンで【役割】と【システム】を分ける

業務フローをRCMと整合させるなら、スイムレーンは強力です。 スイムレーンを使うと誰がやるのかとどのシステムで処理されるのかが明確になり、RCMの実施主体や証跡に直結します。

おすすめのレーン設計は次の2軸です。

よくある失敗は、フローの中に「人の作業」と「システムの処理」が混ざり、どこに証跡が残るのかが不明になることです。 スイムレーンで分けておくと、後でRCMを書くときに統制の実施者と証跡を迷いにくくなるので、最初にやっておく価値が高いです。

また、内部統制や監査対応を意識するなら、スイムレーン上で次のような境界も見える化できます。

• 担当と上長の境界…承認の所在が明確になる
• 部署間の境界…引き継ぎミスや責任の抜けが見えやすい
• システム間の境界…転記や二重入力などの事故ポイントが見える

インプットとアウトプットを明確にする

業務フローを描くときは、工程の箱だけでなく、インプットとアウトプットを明確にします。 これは、「プロセスは入力【X】と処理【F】と出力【Y】で捉えられる」という考え方と同じです。

インプットとアウトプットが曖昧だと、次のような問題が起きます。

• 何を受け取って何を作るのかが曖昧になり、リスクが特定できない
• 成果物や記録が曖昧になり、証跡が定義できない
• 判断の根拠が曖昧になり、統制が設計できない

インプットとアウトプットは、すべてを列挙する必要はありません。 RCMと整合を取る観点では、最低限として次を押さえると十分です。

• インプット…依頼、申請、受注情報、請求情報など
• アウトプット…承認結果、登録データ、帳票、支払結果など
• 記録の場所…どのシステム、どのファイル、どの台帳か

ここまで揃うと、RCM側で「どこで何が起きると困るか」「どう防ぐか」を一気に置きやすくなります。

手順2【リスクの洗い出し】どこで何が起きるかを置く

次に、業務フローの各工程に対して、リスクを置いていきます。 このとき重要なのは、リスクを一般論で並べるのではなく、フロー上の工程に紐づけて書くことです。

プロセスごとにリスクを紐づける

リスクを洗い出すときは、工程ごとに「何が起きると困るか」を具体化します。 おすすめは、次の観点で問いを立てる方法です。

ここでのコツは、工程名が同じでも、部署やシステムが違えばリスクの性質が変わる点です。 だからこそ、前段でスイムレーンとインプット・アウトプットを明確にしておくと、リスクが具体化しやすくなります。

よくあるリスク観点…漏れやすいポイント

リスクの洗い出しは、チームでやっても漏れが出やすい工程があります。 特に漏れやすいのは、次のような「境界」の部分です。

• 部署間の引き継ぎ…受け渡し漏れ、認識違い
• システム間の転記…二重入力、転記ミス、更新漏れ
• 例外処理の入口…例外が常態化して統制が外れる
• 承認の前後…承認前に処理が進む、承認後の改ざん
• 締めや集計…締めの手順が属人化しやすい

重要点として、業務が特殊でパターン化しにくい領域ほど、リスクも統制も設計が難しくなります。 その場合は「例外を別管理にする」「粒度を粗くする」など、対象範囲の落とし所を先に決めておくことが効いてきます。

手順3【統制の設計】誰がどう防ぐかを決める

リスクを置いたら、次は統制【コントロール】を設計します。 統制は「気をつける」「注意する」ではなく、仕組みとして再現できる形にするのがポイントです。

統制の種類…予防と発見

統制は大きく分けて、予防と発見の2種類です。 RCMでは両方を意識して設計すると、現実的で運用可能な形になりやすいです。

現場では、予防統制を入れたくても業務スピードの都合で入れられないことがあります。 その場合は、発見統制で現実的な落とし所を作るという考え方も有効です。

統制の実施主体…担当と証跡

統制設計で最重要なのは、誰がやるのかと証跡が残るかです。 ここが曖昧だと、統制は運用されず、監査対応でも弱くなります。

統制をRCMに落とすときは、最低限として次の3点をセットにします。

• 実施主体…担当者、上長、別部門など
• 実施タイミング…都度、日次、月次、締め時など
• 証跡…承認履歴、チェックリスト、ログ、帳票など

特に証跡は「残せるか」だけでなく「後から探せるか」も重要です。 業務フロー側で、統制が実施される工程と、証跡が保存される場所【システム・文書管理】がつながっていると、運用が楽になります。

逆に、Excelや口頭運用に寄りすぎると、証跡が散らばり、更新と確認が重くなりがちです。 ツールや文書管理を使って、証跡へのリンクを整理しておくと、RCMが運用に乗りやすくなります。

手順4【整合チェック】フローとRCMのズレを潰す

RCM作りで最後に必ずやるべきが整合チェックです。 ここを飛ばすと、RCMは「それっぽい表」になり、現場や監査でズレが露呈します。

抜け漏れの見つけ方

抜け漏れは、フローとRCMを相互に見比べることで発見できます。 おすすめのチェック方法は次の通りです。

• フローの工程を左から順に読み…各工程にリスクと統制があるかを確認する
• 境界に注目…部署間、システム間、承認の前後で統制が抜けていないかを見る
• 例外の入口…例外処理の条件と統制が定義されているかを見る

また、リスクが多い工程に統制が薄い場合は、統制が足りない可能性があります。 逆に、統制が多すぎて業務を圧迫している場合は、運用されない可能性が高くなります。 このバランス調整も整合チェックの一部です。

粒度の揃え方

整合が崩れる代表原因が粒度のバラつきです。 例えば、フローでは「請求処理」と1箱で書いているのに、RCMでは「請求書の作成」「請求書の承認」「請求書の送付」まで細かく書かれていると、対応が取りにくくなります。

粒度を揃えるコツは、次の2つです。

• フローの箱を基準にする…RCMの行はフローの工程と同じ単位で揃える
• 細分化するならフローも直す…RCMだけ細かくしない

手順書レベルまで落としすぎると難易度が上がり、終わらなくなります。 目的に対して必要十分な粒度に留めることが、RCMを回すうえでの現実的な解です。

変更に強い管理…更新ルールを先に作る

RCMは、作った瞬間から「変更にさらされる成果物」です。 業務は変わりますし、システムも変わります。 だからこそ、更新ルールを先に決めておくことが、形骸化を防ぐ鍵になります。

更新ルールは、難しく考える必要はありません。 まずは次のような最低限のルールで十分です。

更新ルールを持たずに「作って終わり」にすると、業務の変更とともにRCMはすぐに古くなります。 そして「古いRCM」は、現場にとっても監査にとっても負債になります。

だからこそ、RCMづくりは作成と同時に運用を設計するところまで含めて考えるのが重要です。

RCMを形骸化させない運用…更新と共有の設計

RCMは「作ること」よりも「保つこと」の方が難しい成果物です。 業務は日々変わり、担当者も変わり、システムも改修されます。 その変化に追従できないと、RCMはすぐに古くなり、現場では使われず、監査でも信用されなくなります。

ここでは、RCMを形骸化させないために必要な更新と共有の設計をまとめます。 結論はシンプルで、更新できる状態を先に作り、フローと証跡をつないで運用することです。

見えないものは管理できない…更新できる状態を作る

実際にプロジェクトを推進された方への取材時にも、繰り返し出てきた前提があります。 それが見えないものは管理できないという考え方です。

RCM運用でも同じで、更新が必要なのに更新できない状態だと、RCMは管理されません。 重要なのは、RCMそのものの見た目ではなく、更新が発生したときに誰がどう動けるかを定義しておくことです。

まずは、更新できる状態を作るために「運用の最小セット」を決めます。

さらに実務では、RCM単体の更新だけでは不十分です。 RCMは業務フローとセットで成立するため、フローとRCMの同時改訂を原則にすると形骸化しにくくなります。

• フローが変わったらRCMも更新…工程が変わればリスクと統制も変わる
• 統制が変わったらフローも更新…実施主体や証跡の位置が変わる
• 証跡の保存場所が変わったら両方更新…監査で一番困るズレが出る

「更新できる状態」は、ツール以前に体制の問題でもあります。 現場の協力が得られないと更新は止まります。 だからこそ、可視化や内部統制が会社の業務として必要だという周知と合意は、運用設計の一部として扱う必要があります。

Excel運用で詰まりやすい点…整合が崩れる理由

多くの現場では、最初はExcelでRCMやフローの管理を始めます。 これは自然な流れですが、一定規模を超えると詰まりやすくなります。 詰まる理由は「Excelが悪い」ではなく、整合を保つ仕組みを作りにくいことにあります。

Excel運用で整合が崩れやすい代表例を整理します。

特に重要なのは、Excelだと「フロー図」と「RCM表」と「証跡」が別々に存在しやすく、変更が起きるたびに手で整合を取る作業が発生する点です。 この手作業が積み上がると、更新が遅れ、やがて更新されなくなります。

整合が崩れたRCMは、次のような状態になりがちです。

• フローに存在しない工程のリスクが書かれている
• RCMにある統制の証跡が見つからない
• 担当者やシステムが実態と違う
• 例外処理が増えたのにRCMが追従していない

こうなると、RCMは「監査のための資料」になり、現場の改善に使われません。 RCMを活かすには、更新と整合を低コストで回せる設計が必須になります。

ツール活用の考え方…業務フローと証跡をつなぐ

RCMを形骸化させないためにツールを使う場合、狙いは「作図が楽」だけではありません。 本質は、業務フローと統制と証跡の関係をつなぎ、整合を保つ仕組みを作ることです。

業務フローに情報を足すと、RCMや一覧表などのアウトプットが変わります。 この考え方を運用に落とすと、次のようになります。

• フローを中心に情報を集約する…工程にリスク、統制、証跡を紐づける
• 必要な形で出力する…監査向け、改善向け、教育向けに一覧化する
• 更新を連動させる…フロー変更がRCMに波及する状態に近づける

リンクで【フロー】と【文書】を紐づける

運用を回すうえで効くのがリンクの設計です。 業務フローの各工程に対して、関連する文書や証跡の保存場所を紐づけます。 こうすると、RCMが求める「証跡はどこか」という問いに、迷わず答えやすくなります。

リンクで紐づけたい代表的な対象は次の通りです。

• 規程・手順書…その工程のルールを示す
• 帳票・テンプレ…入力と出力の標準を示す
• システム画面・マニュアル…操作と権限を示す
• 証跡の保存場所…ログ、承認履歴、台帳、文書管理のフォルダ

この紐づけがあると、変更が起きたときも「どこを直すべきか」が見えます。 つまり、更新の影響範囲を見える化できるため、RCMを保守しやすくなります。

逆にリンクがないと、変更のたびに「証跡はどこだっけ」という探索が発生し、更新が遅れます。 この遅れが積み重なるのが形骸化の入り口です。

一覧出力で【監査対応】と【改善】を回す

フローに情報を集約したら、次に重要なのが一覧出力です。 同じ情報でも、用途に応じて見せ方を変えると、運用が回りやすくなります。

一覧出力の典型パターンは次の2つです。

この設計が効く理由は、RCMを「監査の提出物」で終わらせず、改善にも使える状態にできるからです。 RCMが改善に使われると、現場側にとっても価値が出ます。 価値が出ると協力が得やすくなり、更新も回りやすくなります。

RCM運用で最終的に目指したいのは、フローとRCMと証跡がつながり、更新が自然に回る状態です。 ツールはその状態を作るための手段であり、導入の検討ポイントは「作れるか」ではなく保てるかになります。

【まとめ】RCM（リスクコントロールマトリクス）の作り方…業務フローと整合を取るコツ

RCMは「表を作る」より「フローと整合を保つ」ことが成功の分かれ目です。まず定型業務を業務フローで見える化し、工程ごとにリスクと統制、証跡を紐づけます。最後に抜け漏れと粒度のズレを潰し、変更が起きた時に更新できるルールと共有の仕組みまで設計すると、RCMは監査対応だけでなく改善にも活きる成果物になります。

• 業務フローが土台…工程単位でリスクと統制を置く
• 粒度を先に決める…定型から始め、例外は落とし所を作る
• 証跡までつなぐ…担当、実施タイミング、保存場所を明確にする
• 整合チェックを必ず実施…抜け漏れ、二重、ズレを潰す
• 更新と共有を運用に組み込む…フロー変更とRCM改訂を連動させる