文書管理システムの権限モデルを最初に設計する

文書管理では、同じユーザーでも文書の種類や状態によって操作できる範囲が変わります。閲覧、登録、編集、承認、差戻し、削除を単純な管理者フラグだけで扱うと、運用が始まってから例外が増えます。

組織変更や担当者変更があるため、個人単位の権限付与だけでは保守が難しくなります。一方で、部署単位だけでは一時的な担当や監査担当に対応しづらいことがあります。

文書管理では、ファイルそのものだけでなく、タイトル、サムネール、検索結果、更新履歴にも情報が含まれます。閲覧権限のないファイルが開けないだけでは不十分で、一覧や検索で存在が見えること自体が問題になる場合があります。

権限モデルは、ユーザー、所属、ロール、文書種別、文書状態、操作の組み合わせで考えます。まず粗いロールを定義し、必要な例外だけ追加権限として扱います。状態遷移と操作権限を同じ表で見られるようにするとレビューしやすくなります。

設計では、所有者、組織、フォルダ継承、個別共有、ロールを分けます。権限判定は画面ごとのif文ではなく、APIと検索の共通サービスとして実装し、なぜ許可または拒否されたかを説明できる形にします。

DBでは、文書本体、文書種別、状態履歴、権限付与、監査ログを分けます。APIでは操作ごとに権限チェックを行い、React画面では可能な操作だけを表示します。承認済み文書は直接更新せず、新しい版を作る設計にします。

PostgreSQLでは、documents、folders、memberships、document_acl、permission_eventsを分けます。ACLを都度再帰的に解決すると重くなるため、継承を展開したeffective_permissionsをキャッシュし、変更イベントで更新する構成も選択肢になります。

検証では、部署外閲覧、承認後編集、削除権限、退職者アクセス、代理担当のケースを確認します。権限マトリクスをテストデータ化すると、仕様変更時に漏れを見つけやすくなります。

検証では、直接URLアクセス、検索結果、プレビュー、ダウンロード、共有リンクを別々に確認します。権限を外した直後に検索結果へ残らないか、キャッシュやインデックスの遅延もテスト対象にします。

権限を細かくしすぎると管理画面が複雑になります。まずは業務上のリスクが高い操作を厳密にし、閲覧範囲や承認操作から優先して設計する方が現実的です。

権限を細かくすると柔軟になりますが、利用者にとって理解しづらくなります。単純化しすぎると例外運用が増えます。システム内部では細かく持ち、画面では代表的な権限セットとして見せる設計が扱いやすいです。

文書管理の品質は、検索やアップロード機能だけでは決まりません。権限と状態遷移を最初に設計することで、後からの監査や組織変更に耐えやすくなります。

文書管理の権限設計は、後から足すほど難しくなります。最初に判定対象と説明可能性を決めておくと、検索や共有が増えても安全性を保ちやすくなります。