複数人で使うWordPressを作るとき、ユーザーを登録するだけでは運用できませんでした。同じサイトを使っていても、管理する人、記事を書く人、読む人では必要な操作が違います。さらに、同じ権限でも所属チームによって表示する情報や確認対象が変わります。
社内向けのWordPressでは、WordPress標準のroleと、業務上のグループ・チームを分けて持たせました。人数が多いためCSVで一括登録し、後から権限と所属を組み合わせて使える形へ育てました。
この記事では、ユーザー・権限・チームを一つにまとめず、それぞれの役割を分けて運用した考え方を整理します。
最初に「誰か」と「何ができるか」を分ける
WordPressユーザーは、ログインする人を識別する情報です。ログイン名、表示名、メールアドレスなどを持ちます。roleは、その人がWordPress上で何を操作できるかを決める権限のまとまりです。
一方、社内で使う「所属グループ」「チーム」「担当」は、WordPress標準の権限とは別の業務情報です。
| 情報 | 答えること | 例 |
|---|---|---|
| ユーザー | 誰がログインしているか | user001 |
| WordPress role | 何を操作できるか | 管理、投稿、閲覧 |
| グループ | どの業務領域に属するか | group-a |
| チーム | どの単位で確認するか | team-1 |
| 担当属性 | 業務上の役割があるか | 代表者、発行担当 |
この区別を先に決めると、「チームが変わっただけなのにWordPressの管理権限まで変わる」といった混乱を避けられます。
WordPress roleはサイト操作に使う
WordPress roleは、管理画面へ入れるか、投稿を作れるか、サイト設定を変更できるかといった操作権限に使いました。
- 管理する人:ユーザーやサイト設定を扱う
- 発信する人:必要な記事や文書を作る
- 利用する人:ログインして情報を読み、決められた操作を行う
業務グループごとに新しいroleを作る方法も考えられますが、所属が増えるたびに権限の種類が増えます。今回はサイト操作の権限をrole、業務上の分類を別のユーザー情報として持たせました。
これにより、同じ閲覧権限を持つ利用者でも、所属グループやチームに応じて表示や確認対象を変えられます。
グループとチームは業務の範囲に使う
グループは、利用者がどの業務領域に属するかを表します。チームは、その中で確認や集計を行う単位として使いました。必要な場合は代表者などの担当属性も別に持たせます。
一人の利用者を次のような層で考えます。
- 本人:WordPressユーザーIDで識別する
- サイト権限:roleで操作範囲を決める
- 所属範囲:グループで対象の情報を決める
- 確認単位:チームで状況をまとめる
- 担当:必要な業務操作を追加する
初期段階では、まずユーザーと所属を正しく登録するところまでにしました。特定文書の発行、チーム単位の確認、代理操作などの細かな条件は、実際の運用が見えてから追加しています。
多人数をCSVでそろえる
少人数なら管理画面から一人ずつ登録できます。しかし、人数が増えると、入力項目の揺れや登録漏れを見つけにくくなります。
そこで、CSVからユーザーを登録・更新する専用の取り込み機能を用意しました。CSVは、項目をカンマで区切った表形式のデータです。Excelなどで一覧を確認してから、WordPressへまとめて渡せます。
実際の取り込みでは、次の種類の項目を扱いました。
| 項目 | 用途 | ダミー例 |
|---|---|---|
| ログイン名 | ログイン時の識別 | user001 |
| 表示名 | 画面上の名前 | 利用者A |
| メール | WordPressのユーザー情報 | user001@example.invalid |
| role | サイト操作の権限 | subscriber |
| グループ | 業務上の所属 | group-a |
| チーム | 確認単位 | team-1 |
新規登録だけでなく、既存ユーザーの名前・所属・roleを更新できるようにしました。「登録なし」のように所属を明示的に外す値も扱える形にしています。
実データでは、表をそのまま読み込めなかった
ユーザー一覧をCSVへ整える過程では、複数の問題が見つかりました。
- 同じメールアドレスが複数行に入っている
- メールアドレスを持たない利用者がいる
- 数字から始まるログイン名の先頭0がExcelで消える
- 姓名の列が逆になっている
- 既存ユーザーの所属を更新する必要がある
WordPressではユーザーのメールアドレスが重複すると、そのまま登録できません。メールがない利用者については、実在のアドレスを推測せず、サイト内で重複しない管理用の値を作る処理を用意しました。
先頭0を含むログイン名は、Excelが数値として扱うと0が消えます。ログイン名は計算する数字ではないため、CSVを作る段階で文字列として扱う必要がありました。
インポート処理だけを作っても、元データが揃っていなければ正しく登録できません。重複・空欄・自動変換を先に確認することも、ユーザー管理の一部でした。
既存ユーザーは「追加」ではなく更新する
一括登録を何度か行うと、同じ利用者がすでにWordPressへ存在する場合があります。毎回新規ユーザーとして追加すると、重複したアカウントができます。
そこで、ログイン名などの識別項目で既存ユーザーを確認し、存在する場合は名前・role・所属情報を更新する流れにしました。存在しない場合だけ新規作成します。
| CSVの状態 | 処理 |
|---|---|
| 該当ユーザーがいない | 新規ユーザーを作る |
| 該当ユーザーがいる | 指定された項目を更新する |
| 必須値が不足 | 登録せず、対象行を確認する |
| 重複する値がある | 原因を直してから再実行する |
更新対象を明確にすると、所属変更のたびにアカウントを作り直す必要がありません。
登録後は、人数だけでなく組み合わせを確認する
インポートの完了表示だけでは、正しく運用できるか分かりません。ダミーではない実際の管理作業では、個人情報を外部へ出さず、WordPress管理画面の中で次を確認しました。
- 新規ユーザーが作成されている
- 既存ユーザーが重複せず更新されている
- 表示名とログイン名が想定どおりである
- WordPress roleが正しい
- グループとチームが別々に保存されている
- 所属なしとして扱う利用者が意図どおりになっている
- 対象ユーザーでログインし、必要な画面だけ操作できる
管理者の画面だけを見るのではなく、一般利用者のアカウントでも確認します。roleと所属の組み合わせによって、見える入口と可能な操作が変わるためです。
役割を分けたまま、業務フローへつなげる
ユーザー、role、グループ、チームを分けたことで、後から業務条件を追加しやすくなりました。
- roleで、発行や管理などのサイト操作を制限する
- グループで、対象となる情報の範囲を決める
- チームで、確認状況をまとめる
- 担当属性で、必要な操作を追加する
すべてをroleへ詰め込むのではなく、別の意味を持つ情報は別の項目として保存する。必要な画面で組み合わせて判定することで、運用変更へ対応しやすくなりました。
誰かをユーザーで識別し、何ができるかをroleで決め、どこに属するかをグループとチームで表す。
この分け方が、複数人で使うWordPressを業務フローへつなげる土台になりました。ユーザー登録を実際に進めた時系列は、社内ポータルのユーザーと権限を整理した記録でまとめています。