この記事を読むメリット
- なぜ権限管理が必要なのか(やらないと何が起きるのか)を業務リスクの観点で理解できる
- ユーザー・ロール・権限の関係を「仕事の流れ」でイメージできる
- 実務でつまずきやすい「権限が足りない/多すぎる」場面と対処の勘所がわかる
「SAPの権限管理って、結局なにをどう設定しているの?」
言葉だけ聞くと難しく感じますが、やっていることは現実の会社とそっくりです。
社員証を配り(ユーザー)、職務に応じた鍵束を渡し(ロール)、その鍵が「どのドアを・どこまで」開けられるかを決める(権限)。
本記事では、架空の「サクラ商事」に配属された新人レイナがSAPを使い始めて一人前になるまでを追いながら、ユーザーと権限設定の全体像を業務目線で解説します。
それでは、ユーザーと権限管理について説明していくぞい!
この記事のポイント
なぜ「権限管理」が必要なのか? ― やらないと起きること
レイナの初日。先輩からこう言われます。
「SAPは“誰でも・なんでもできる”ようにはなっていないからね。あなたには購買の仕事に必要なところだけ開けておくよ」
もし全社員が何でもできてしまったら、どうなるでしょうか。
権限設定が無かったら…
- 経理の人が、勝手に発注を作れてしまう
- 新人が、操作ミスで他部署のデータを変更・削除してしまう
- 発注した本人が、その発注を自分で承認して、不正に支払いまで通せてしまう
こうしたリスクを防ぐのが権限管理です。基本は次の2つの考え方です。
- 最小権限の原則:その人の仕事に必要な権限“だけ”を渡す
- 職務分掌(SoD):「発注する人」と「承認する人」「支払う人」を分け、1人に集中させない
権限管理は“縛り”ではないのじゃ。
ミスと不正から会社と本人を守る仕組みなんじゃ!
全体像 ― 3つの主役を「会社の入館システム」で理解する
SAPの権限は、ざっくり3つの登場人物で成り立っています。現実の「オフィスビルの入館管理」に置き換えると一気にイメージできます。
| SAPの用語 | 役割 | 現実のたとえ |
|---|
| ユーザー | 誰がシステムを使うか | 社員証(本人を識別する) |
| ロール | その人が何をできるか(権限の束) | 職務に応じて渡される鍵束 |
| 権限オブジェクト/権限項目 | どのドアを・どこまで開けられるか | 鍵1本ごとの対応ドアと「開ける/見るだけ」の区別 |
この後、レイナがアカウントをもらい(ユーザー)→ 購買担当の鍵束を受け取り(ロール)→ 実際に発注作業をして「あれ、開かない!」とつまずく(権限の中身)、という順で見ていきます。
ユーザー ― 「誰が使うか」を登録する(T-CODE:SU01)
入社初日、レイナのSAPアカウントが作られます。これがユーザーの登録です。担当する管理者は、トランザクションコード SU01 で次のように作成します。
- SU01 を起動する
- ユーザー名を入力して新規作成する
- 氏名・メールアドレス・初期パスワードなどを入力する
- 購買担当に必要なロールを割り当てる
ユーザーにはいくつか種類があり、目的で使い分けます。レイナのような“人”が使うのはダイアログユーザーです。
| 種類 | 用途 | 例 |
|---|
| ダイアログユーザー | 人がログインして操作する | 購買担当のレイナ、経理担当 など |
| サービスユーザー | 複数人で共有して使う | 研修・デモ用アカウント |
| システムユーザー | システム間連携やバッチ処理 | 夜間バッチ、外部システム連携 |
| 参照ユーザー | 既存ユーザーの権限を共有する | 共通権限をまとめて参照させる |
私のアカウントは「ダイアログユーザー」なんですね。
そうじゃ。ちなみにユーザー情報はテーブルにも格納されておる。
仕組みを深掘りしたいなら、下の関連記事も読むとよいぞ!
あわせて読みたい
SAPユーザマスタに関するテーブル関連図(user table)を徹底解説!
この記事を読むメリット SAPユーザの情報をテーブルから検索できるようになります。 SAPに登録されているユーザ情報はテーブル検索できるのかしら? SAPシステム内のユ…
ロール ― 「職務に必要な権限の束」を渡す(T-CODE:PFCG)
アカウントだけでは、レイナはまだ何もできません。ここで渡されるのがロール=仕事に必要な権限をひとまとめにした“鍵束”です。
サクラ商事では、職務ごとにロールが用意されています。
- 購買発注 作成ロール:発注伝票を作れる
- 購買 照会ロール:発注内容を見るだけ(変更不可)
- 購買 承認ロール:購買依頼を承認できる
レイナは「購買担当」なので、作成ロール+照会ロールを受け取りました。ロールは管理者がトランザクションコード PFCG で作成・メンテナンスします。
ロール作成の流れ(PFCG)
- PFCG を起動する
- 新規ロール名を入力して「作成」する
- このロールで使えるトランザクション(例:ME21N=発注作成)を登録する
- 権限オブジェクトの値(購買組織や会社コードなど)を設定する
- 保存し、ユーザーに割り当てる
ポイントは「人に合わせて鍵を作る」のではなく、
「職務に合わせて鍵束を作り、それを人に配る」ことじゃ。担当者が増えても同じロールを配ればよいから、管理がぐっと楽になる!
権限の中身(ロール、権限オブジェクト、権限項目)
ロールをもらったレイナ。さっそく発注を作ろうと ME21N(購買発注の作成) を開いて入力し、保存ボタンを押すと……「権限がありません」。
なぜでしょう? ここで初めて、ロールの“中身”を分解して見る必要が出てきます。SAPの権限は次の3階層になっています。
① ロール(鍵束)
レイナが持つ「購買発注 作成ロール」。この中に、後述の権限オブジェクトと項目が詰まっています。ロールを構成する代表的な要素は次の3つです。
- トランザクションコード(T-code):呼び出せる機能。例 ME21N(発注作成)、FB01(財務伝票作成)
- 操作の種類(アクティビティ):作成(01)・変更(02)・照会(03)など、どこまで触れるか
- 組織レベル:どの会社・購買組織・支店のデータを扱えるか
② 権限オブジェクト(鍵1本=1つのドア)
権限オブジェクトは「このドアを開けてよいか」をチェックする単位です。たとえば ME21N を実行するとき、SAPは内部で次をチェックします。
- S_TCODE:そもそもその取引(ME21N)を起動してよいか
- M_BEST_EKO:購買発注で、その購買組織を扱ってよいか
S_TCODEは、トランザクションコードを実行するための“必須”権限オブジェクトじゃ!
③ 権限項目(鍵の“効く範囲”)
権限項目は、鍵が「どのドアの・どこまで」効くかを表す細かい設定です。レイナのケースを書き出すと、上の図のように S_TCODE:TCD=ME21N/M_BEST_EKO:アクティビティ=01(作成)、購買組織=1000 となります。
レイナのエラーの原因はここでした。
彼女のロールには購買組織1000しか設定されておらず、入力していた発注は購買組織2000(別拠点)だったのです。
鍵は持っていたけれど、“効く範囲”の外のドアを開けようとしていた、というわけです。
こういうとき便利なのが SU53。直前に「どの権限が足りずに弾かれたか」を表示してくれる。レイナはこれで「購買組織2000の権限がない」とすぐ分かったわけじゃ!
鍵は持っていても、“開けられるドアの範囲”まで決まっているんですね……!
補足:照会専用ユーザーを作るには?
「見るだけ」にしたい場合は、作成用の ME21N ではなく照会用の ME23N を渡し、アクティビティを 03(照会)に絞ります。これで「発注内容は見られるが、作成・変更はできない」ユーザーが作れます。
| やりたいこと | T-code | アクティビティ |
|---|
| 発注を作成する | ME21N | 01(作成) |
| 発注を変更する | ME22N | 02(変更) |
| 発注を見るだけ | ME23N | 03(照会) |
単体ロールと集合ロール ― 部署が大きくなったときの整理術
購買部に人が増えてきました。担当者A・B・C…とロールを1つずつ手で割り当てるのは大変ですし、付け忘れも起きます。そこで役立つのが単体ロールと集合ロールの使い分けです。両者の関係は「部品」と「完成品」に例えられます。
- 単体ロール(部品):1つの業務に必要な最小限の権限。
- 集合ロール(完成品):単体ロールを組み合わせた“職務パッケージ”。
具体例:購買部門の業務権限を設計する
- 単体ロールを用意する:ロールA=購買発注の作成(ME21N)/ロールB=購買依頼の承認(ME54N)/ロールC=購買レポートの閲覧(ME2N)
- 集合ロールにまとめる:「購買担当者」=ロールA+ロールC/「購買管理者」=ロールA+ロールB+ロールC
- 職務に応じて配る:一般担当のレイナ→「購買担当者」/チームリーダー→「購買管理者」
この方式のうれしいところ
- 配るのが楽:集合ロール1つで、必要な権限が一括で揃う
- 変更が一度で済む:集合ロールに単体ロールを足すだけで、その職務の全員に反映される
- 職務分掌を守りやすい:「発注(A)」と「承認(B)」を別ロールにしておけば、“発注した本人が承認する”危険な組み合わせを防げる
レイナが「購買担当者」止まりで承認の鍵(ロールB)を持っていないのは意地悪じゃない。発注者と承認者を分けることで、会社全体のチェック機能が働くんじゃ!
実務でよくある場面
最後に、運用で頻出するシーンを押さえておきましょう。
- 「権限がありません」と出た → SU53 で不足している権限を特定し、管理者にロール修正を依頼する
- 異動した → 旧部署の集合ロールを外し、新部署の集合ロールを付与(権限の“持ちすぎ”を防ぐ)
- 退職した → ユーザーをロック/無効化(アカウントを残したままにしない)
- 「誰がこの権限を持っている?」を調べたい → 権限情報システム SUIM で棚卸しする
- 棚卸し・監査対応
→ 不要な権限が残っていないか定期的に見直す(とくにSoD観点での重複チェック)
さいごに
本記事では、新人レイナの目線を借りて、SAPの「ユーザーと権限設定」を業務の流れで解説しました
ポイント振り返り
- ユーザー=誰が使うか/ロール=何ができるか/権限項目=どこまで効くか、の3点セット
- 基本思想は最小権限と職務分掌。ミスと不正から会社と担当者を守るための仕組み
- 規模が大きくなったら単体ロール+集合ロールで、配布も変更も一元管理
適切な権限設計は、システムの安全性を高めるだけでなく、日々の業務をスムーズに回すための土台になります。
とくに「単体ロールと集合ロールの使い分け」や「権限オブジェクト・権限項目の詳細設定」は、実際のプロジェクトで必ず役立つ知識になります。
「権限」って制限のことかと思っていましたが、安心して仕事を任せてもらうための仕組みなんですね!
その通りじゃ。今日学んだことを、運用・保守・開発の現場で活かしていくのじゃ!
本記事はこれで以上じゃ!