監査法人に「この発注、誰が承認しましたか」と聞かれて、SAPの画面をたどっていったら、発注を起票した本人が承認も押していた——J-SOX対応の現場で、こういう兼務が後から見つかるほど厄介なものはない。運用ルールでは「兼務しないこと」と書いてあっても、システムが物理的に許してしまえば、それは統制ではなく性善説だ。
CFOzine編集部がこの記事で言いたいのは一点に尽きる。職務分掌（SoD＝Segregation of Duties、互いに牽制し合うべき作業を別の人に分けること）は、運用ルールではなくSAPの権限ロールで物理的に分けて初めて統制になる、ということだ。そしてこの設計を初期に詰めておくかどうかで、その後のJ-SOX対応コストは数年にわたって効いてくる。
「運用で分ける」が一番高くつく
SoDを担保する方法は、大きく分けて二つある。一つは「発注した人は承認しないでください」と業務ルールで決め、運用で守る方法。もう一つは、発注を起票できる権限ロールと承認できる権限ロールを別々に作り、同じ人に両方を割り当てない方法だ。この二つは、導入の速さと毎年の監査コストが正反対になる。
前者は導入が速い。権限設計を作り込まなくても回り始める。だが代償は監査のたびに払うことになる。ルールで分けているだけだと、監査人は「本当に守られているか」を確かめるために、期中に処理された伝票をサンプル抽出して、起票者と承認者が別人かを一件ずつ突き合わせる。これが運用評価（手作業でのテスト）で、母集団が大きければサンプル件数も増え、毎年人手がかかる。さらに「兼務できてしまう状態」そのものが不備（デフィシエンシー）として指摘されれば、改善計画の提出と再テストが追いかけてくる。
後者、つまり権限で物理的に分けてあれば、話は変わる。同じ人に矛盾する権限が割り当たらないことをシステムが保証しているなら、それは自動化された統制として扱える。監査は「ロール設計が正しく組まれ、割当が管理されているか」を確認すれば足り、一件ずつの突合は原則として不要になる。J-SOXで自動統制が好まれるのは、人の注意力に依存せず、テストの効率も段違いだからだ。初期に権限で分ける投資をケチると、運用評価という形で毎年利息を払い続けることになる。
どの兼務を切るのか——SAPで効く「危ない組み合わせ」
抽象論では設計できない。実際にSAPで切るべき代表的なSoD抵触の組み合わせを、業務に即して挙げる。共通するのは、一人で「取引を作る側」と「実行・記録する側」をまたげてしまうという構図だ。
- 発注（購買）と支払（出金）：架空の取引先への発注から送金まで一人で完結できる。Purchase-to-Payで最も警戒される組み合わせ
- 仕入先マスタの登録・変更と支払：振込先口座を書き換えられる人が支払も押せると、正規の請求を自分の口座に付け替えられる
- 仕訳の起票（伝票入力）と承認・転記（ポスティング）：自分で入れた伝票を自分で確定でき、不正な仕訳が誰のチェックも受けず帳簿に載る
- 入金消込と売掛金マスタ／貸倒処理：消し込む人が貸倒も切れると、横領した入金を貸倒で隠せる
ここで効いてくるのが、起票と承認を「別のロール」に割るという発想だ。同じ購買業務でも、担当のロールと責任者のロールで作業を割り当て直す。
SAPの実装では、購買担当のロールは「発注の起票はできるが承認の権限は持たない」、購買責任者のロールは「起票はできず承認だけできる」というように、同じ業務でも作業を属性ごとにロールへ割り、矛盾するロールを一人に重ねないことで分掌を実現する。ここでさらに効いてくるのが、会社コードや購買組織といった組織単位での権限制御だ。別会社・別部門の伝票登録を権限エラーで弾けるよう設計しておけば、「分掌」に加えて「縄張り」も同時に守れる。
SAPの権限構造を分掌のために組む
SAPの権限は、トランザクションコードPFCGで作る権限ロールが土台になる。ロールには大きく、特定の作業に必要な権限をまとめた単一ロール（単体ロール）と、職種・職位に応じて単一ロールを束ねる複合ロール（集合ロール）がある。J-SOXを意識するなら、設計思想はこう置く——作業の最小単位で単一ロールを切り、職務分掌の境界を単一ロールの粒度に一致させる。
「発注起票」「発注承認」「支払実行」をそれぞれ別の単一ロールにしておけば、誰に何を割り当てたかが、そのまま「この人は発注を起票できるが支払はできない」という分掌の事実になる。逆に「購買ぜんぶ入り」のような粗い大ロールを一つ作ってしまうと、その中で起票と支払が混ざり、分掌の議論ができない。後から割るのは、運用中のユーザー全員の割当を組み替える作業になり、これが初期設計の手抜きが最も高くつく場面だ。
複数の会社コードや事業所で同じ業務をする場合は、派生ロール（親ロールから組織値だけを変えて子ロールを量産する仕組み）を使う。権限の中身（できる作業）は親で一元管理し、適用範囲（どの会社・どの拠点か）だけを子で振り分ける。分掌のロジックを親に集約できるので、組織が増えても設計の一貫性が崩れない。命名規則で「業務×作業×組織」が読めるようにしておくと、監査時に「このロールは何ができるロールか」を説明する手間が激減する。
抜け道を塞ぐ——例外と緊急権限の作法
権限で綺麗に割っても、現場は必ず例外を求めてくる。「月末の数日だけ、人が足りないので承認も触らせてほしい」。ここを場当たりで広げると、SoD設計は静かに崩れる。打ち手は二つある。
一つはルールセットによる抵触チェックだ。SAP GRC Access Control（アクセス権限の付与とSoDリスクを管理する仕組み）には、どのトランザクションの組み合わせが禁止かを定義したルールセットが標準で用意されており、自社の業務に合わせて調整できる。権限を割り当てる前に「この付与でSoD抵触が起きないか」を機械的にシミュレーションし、抵触するなら止める。これがあると、例外申請が来ても「何と何が抵触するか」が即座に見えるので、感覚ではなく根拠で判断できる。
もう一つが緊急時アクセス（ファイアファイターID）。どうしても一時的に強い権限が要る場面では、恒久的に権限を足すのではなく、申請・承認の上で時限的に貸し出す。鍵は、それを「回す」ことだ。
GRC界隈で「払い出した緊急権限が取り消されないまま放置される」ことがSoDリスクの典型と言われるのは、この事後の回収と点検が甘くなりがちだからだ。例外を恒久的な穴にせず、記録の残る一時的な貸出に変えることが、設計を守る最後の砦になる。
初期設計が「2027年の壁」と重なる理由
最後に、なぜ「今」これを詰めるべきかに触れておく。SAP ERP 6.0（いわゆるECC）のメインストリーム保守は2027年12月31日に終了し、延長保守でおおむね2030年まで（追加コストの目安として保守料率に2ポイント程度の上乗せ）とされている。後継のSAP S/4HANAは、少なくとも1リリースを2040年まで維持する方針が示されている。多くの会社がこの数年でS/4HANAへの移行に踏み切る。
移行は、権限ロールを設計し直す数少ない好機だ。ECC時代の継ぎ接ぎだらけのロールをそのまま持ち込むのではなく、SoDの境界を単一ロールの粒度に一致させ、組織展開は派生ロールに寄せ、緊急権限の作法まで含めて作り直せば、移行とJ-SOX対応の作り込みを一度で済ませられる。逆にここで「とりあえず動けばいい」を選ぶと、新しい基盤の上にまた兼務の温床を作り、数年がかりで運用評価の利息を払うことになる。
J-SOXの実施基準は2024年4月以降に始まる事業年度からおおむね15年ぶりの改訂が適用され、ITへの対応や不正リスク、経営者による統制の無効化への備えがあらためて強調されている。職務分掌は、その中核に位置する古くて新しいテーマだ。運用の張り紙ではなく、権限ロールという仕組みで分ける——初期設計でそこに一手間かけることが、監査で詰まらない会社と、毎年詰まる会社を分ける。
注：本記事はSAPの保守期限・J-SOX実施基準の一般的な枠組みを編集部が整理したものです。自社の適用範囲・評価対象・具体的なロール設計は、監査法人および導入パートナーと個別にご確認ください。制度の細部や保守の特例（RISE経由の延長等）は更新されることがあります。
