安心して任せられるCMS権限 Drupalの3層ロール設計
CMSの権限設計は、設計書のなかで後回しになりやすい項目です。画面設計や機能要件と違って完成イメージを持ちにくく、運用が始まってから調整すればよいと判断されることもあります。ただし、公開後に事故が起きてから見直す場合は、影響範囲の調査から入ることになり、対応にも日数がかかります。
Drupalでコーポレートサイトを構築した案件では、ロールを3層に分け、制御しているのは公開と削除の2点でした。この制御は、Drupalが標準で備えているロールと権限の機能だけで組み立てています。
本記事では、Drupalの権限機能でできること、権限を与えるのではなく落とす発想で組み立てる考え方、そして発注側が事前に決めておくとよい項目について解説します。
目次
権限設計は、合意を設計書にしてから管理画面に入る
進め方としては、ディレクターがお客様とロールの仕様を詰め、その内容をCMS設計書に落とし、設計書をもとにエンジニアが管理画面でロールを作成するという順序になります。
ここで大事なのは、ロールの仕様がお客様との合意事項として設計書に存在してから実装に入る点です。権限は機能というより、組織の取り決めをシステムに反映する作業にあたります。誰が公開の判断をするのか、誰が削除の判断をするのかは、CMSの仕様ではなく運用体制の話です。合意のないまま実装に入ると、公開直前に、この人が公開できないのは困るという調整が発生し、リリース日程の見直しが必要になることもあります。
案件で用意した3層のロール構成
前述の案件で用意したロールは、次の3層です。
- フル権限：ほぼすべての操作にチェックが入っている。最上位管理者にあたる。
- 作業用：日常的な更新作業を行う担当者向け。
- 新人および外部用：新しく参加したメンバーや、外部の協力会社向け。
層を3つに絞っている点が、この構成の特徴です。部門ごと、コンテンツ種別ごとにロールを増やす設計も可能ですが、ロールが増えるほど、誰にどれを割り当てるかの判断に時間がかかります。まず3層で始め、運用しながら不足が明確になった時点で追加する進め方であれば、公開までに確認する項目を増やさずに済みます。
中間にあたる作業用のロールは、日常の更新をひと通り行える設定にしています。お知らせやページの作成と編集、メディアの登録、そして公開の操作までを含めます。ここに公開を残しておくと、日々の更新を最上位管理者の手を借りずに回せます。反対に、サイト構成に関わる設定変更やコンテンツタイプの追加はフル権限に集約します。日常業務は作業用で完結し、構成に触る操作だけがフル権限に集まるという分け方です。
落とすのは公開と削除の2点だけ
3層のうち、新人および外部用のロールで実際に落としているのは、次の2つです。
- 公開ができない。作成した内容はレビューを経て、上位の担当者が公開する。
- 削除ができない。誤操作によるコンテンツの消失を防ぐ。
一方で、コンテンツの作成は全員が可能です。書く行為は制限せず、外に出す行為と消す行為だけを止めています。新しく参加したメンバーにも初日から下書きを作ってもらえるため、公開に至る操作を限定したまま、作業に加わってもらえる構成です。制限を2点に絞ると、メンバーへの案内も短く済みます。下書きまでは自由に作ってよい、公開と削除は担当者に依頼する、という2行で伝えられます。
この2点に絞る根拠は、影響の非対称性にあります。作成や下書きの編集は、間違えても公開前に戻せます。しかし公開は外部への影響が即座に発生します。削除については、Drupalの標準機能では削除後のコンテンツを元に戻す機能がないため、バックアップからの復元など別途の対応が必要になります。取り返しのつきやすさで線を引くと、制限すべき箇所は自然と絞られます。
権限の設定は、操作項目ごとにチェックボックスを1つずつ入れていく形です。項目数は多いものの、この層に公開させるか、この層に削除させるかという2つの問いを持って臨めば、判断の基準は絞られます。
コンテンツタイプ単位で、作成できる範囲を分けられる
もう一段細かい制御として、コンテンツタイプごとに作成の可否を分けられます。コンテンツタイプはDrupalにおけるコンテンツの種別で、他のCMSではテンプレートに相当する概念です。
前述の案件では、複数種類のコンテンツタイプ（ページの種別）が定義されており、その単位でロール設定ができる状態でした。この粒度が使えると、たとえば次のような制御ができます。
- お知らせ系のページは各部門が作成できるが、企業情報にあたるページは広報部門のみが作成できる
- 一覧形式のページの新規作成は、サイト全体の構造に影響するため最上位管理者に限定する
複数の部門が同じCMSに入る運用では、部門が個別にページを増やし、サイト全体の構造が揃わなくなるというご相談もあります。この場合、編集権限ではなく作成権限を種別単位で絞ると、構造の統制を保ちながら、日常の更新は各部門に任せられます。ロールを部門ごとに増やさなくても、部門ごとの事情に応えられる打ち手です。更新できる範囲はデータ構造でも決まる面があり、あわせて検討すると設計の抜け漏れを防ぎやすくなります。
ワークフローを見直す前に、決めておくとよい項目
承認フローは、運用のなかで見直されることがあります。当初は作成者と公開者の2段階だったものを、レビュー担当を挟んだ3段階に変更する、といった変更です。
Drupalではこの変更に、各ロールがどの状態からどの状態へ遷移させられるかという設定で対応します。チェックボックス単位で指定できるため、実際の承認手順に沿った形で表現できます。一方で、確認すべき組み合わせは、ロールごとに許可する状態遷移のペアの数になります。3層のロールに4つの状態があり、状態間の遷移をひととおり確認する場合、組み合わせは十数パターンにのぼります。ロールが10個あれば、確認する組み合わせはその分だけ増えます。
そこで、発注側で事前に決めておくとよい項目は次の3点です。
- 承認は何段階にするか
- 各段階の判断を誰が行うか
- 部門ごとに手順を変える必要があるか
3つ目で部門ごとに分けたい要望が出た場合は、ロールを増やす前に、コンテンツタイプ単位の作成権限で表現できないかを検討する順序にすると、見直しのたびに確認する項目を増やさずに済みます。
引き継ぎに強い設計にするための確認項目
もう一つお伝えしたいのが、担当者が変わっても意図が残る形にしておくという観点です。数カ月に及ぶ構築案件でも、公開後の運用でも、担当者の異動や体制の変更は起こります。
そのときに困るのは、権限の設定意図が引き継がれない点です。なぜこのロールでこの操作を止めたのか、なぜこの担当者だけが公開できるのかという背景は、管理画面のチェックボックスからは読み取れません。設定値だけが残って意図が残らないと、後任は変更してよいかどうかを自分で判断できず、確認のやり取りが増えます。
有効なのは、CMS設計書のロール欄に、その操作を止めた理由を1行添えておくことです。外部委託先が含まれるため公開を制限、一覧形式のページの構成に影響するため作成を制限、といった記述で足ります。1行あるだけで、後任が変更の可否を判断する手がかりになります。あわせて、担当者の異動や委託先の変更が発生したときに権限の付与と停止を誰が行うかを決めておくことは、退任した担当者のアカウントが有効なまま残る状態を避けるために、事前に手当てしておける項目です。
設計書に書くべき最小項目
以上を踏まえると、CMS設計書のロール欄に必要な最小項目は次のようになります。
- ロール名（3層程度から開始）
- 各ロールの該当者（部門名または役割名）
- 公開の可否
- 削除の可否
- 作成できるコンテンツタイプの範囲
- ロールの付与と停止を行う担当者
この6項目が埋まっていれば、あとは管理画面の設定作業に進めます。前述の案件では、この範囲を追加開発なしで標準機能の設定だけで用意しました。検索を外部サービスに寄せた場合の役割分担もあわせて整理しておくと、権限設計との抜け漏れを防げます。
あわせて、ロールの一覧と各設定の意図を1枚にまとめた資料を納品物に含めておくと、後任の担当者はその1枚から現状を把握できます。管理画面を1つずつ開いて確認する手間が減るため、引き継ぎにかかる時間の削減にもつながります。
CMSの権限設計に関するよくある質問
ロールは部門ごとに細かく分けたほうがよいですか？
最初から細かく分けるより、3層から始めるほうが運用に乗せやすくなります。ロールが増えるほど割り当ての判断に時間がかかり、結果として全員に上位のロールが付与される状態になることもあります。まずフル権限・作業用・新人および外部用の3層で開始し、運用のなかで不足が明確になった項目だけを追加する順序が扱いやすくなります。
外部の制作会社に渡す権限は、どこまで絞るべきですか？
公開と削除を落とす構成が基準になります。作成と編集は許可し、外部への反映と消去の判断は自社側に残す形です。あわせて、契約終了時にアカウントを停止する担当者を決めておくと、権限が残り続ける状態を防ぎやすくなります。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
株式会社LYZONの社内ニュースを始め、デザインの知識やお役立ち情報など様々な情報を発信しています。
